Part 11. VPC로 네트워크 설계하기

728x90

SMALL

 

VPC

VPC는 Virtual Private Cloud의 약자로 AWS에서 논리적으로 생성하는 독립적인 네트워크를 말한다. VPC안에 여러 서브넷을 만들 수 있는데 서브넷이라 함은 네트워크 내부의 네트워크이다. 서브넷은 네트워크를 보다 효율적으로 만드는데 서브넷을 통해 네트워크 트래픽은 불필요한 라우터를 통과하지 않고 더 짧은 거리를 이동하여 대상에 도달할 수 있다. 

 

VPC안에 구성할 수 있는 서브넷은 퍼블릭 서브넷과 프라이빗 서브넷이 있다. 

 

퍼블릭 서브넷

퍼블릭 서브넷은 외부와의 자유로운 통신이 가능한, 외부 인터넷 구간과 직접적으로 통신할 수 있는 공공 네트워크이다.

프라이빗 서브넷

프라이빗 서브넷은 외부에서 직접 접근할 수 없는 네트워크이다. 프라이빗 서브넷에 실제 서버가 동작하게끔 설정하고 외부에서 이곳으로 직접 접근이 불가능하게 한 후 퍼블릿 서브넷을 통해 외부에서 요청이 들어오면 퍼블릿 서브넷과 프라이빗 서브넷 사이에 연결을 하여 통신한 후 프라이빗 서브넷에서 필요한 요청 데이터를 NAT Gateway를 통해 요청에 응답하게 설계할 수 있다.

 

이 개념을 이해하려면 직접 VPC, Public Subnet, Private Subnet, NAT Gateway 등 만들어보기로 하자.

 

 

설계할 네트워크 전체 그림은 다음과 같다.

 

 

VPC 생성

AWS Console에 'VPC'를 검색해서 나오는 서비스를 클릭한다.

 

메인 화면 좌측 사이드바에 Virtual private cloud 섹션에 'Your VPCs'를 클릭해서 우측 상단 'Create VPC' 클릭

 

VPC Name tag와 CIDR을 설정 후 나머지는 기본값으로 설정한 다음 'Create VPC'를 클릭

 

생성한 VPC 확인

 

 

이렇게 VPC가 생성됐으면 VPC에서 사용될 서브넷을 총 6개를 만든다. 그중 2개는 Public 나머지 4개는 Private으로 설정한다.

가용영역을 둘로 나누어서 AZ1에는 Public Subnet 1개, Private Subnet 2개로 만들고 AZ2는 Public Subnet 1개, Private Subnet 2개로 하여 전체 VPC에 두 개의 가용영역이 있고 그 각각의 가용영역에 Public 1, Private 2 서브넷을 각각 가지는 그림으로 만든다. 

 

 

Subnet 생성

VPC 메인 화면에서 좌측 Subnets을 클릭하고 나온 화면의 우측 상단 'Create subnet' 클릭

 

서브넷 생성 화면에서 서브넷이 들어갈 VPC를 선택하는데 방금 만든 VPC를 선택

 

첫 번째 서브넷을 만들자. AZ-a에 public subnet을 만든다. 서브넷의 대역은 10.1.1.0/26으로 설정한다.

 

 

서브넷 추가를 위해 'Add new subnet'을 클릭해서 또 다른 서브넷을 만든다. AZ-C에 생성될 퍼블릭 서브넷이다. 대역은 10.1.1.64/26으로 설정한다.

 

지금까지가 퍼블릭 서브넷을 만드는 내용이었다. 각 AZ에 한 개씩 퍼블릭 서브넷이 있고 각 AZ에 이제 프라이빗 서브넷 2개씩을 할당할 것. 또 서브넷을 만들자. 

 

이제 프라이빗 서브넷이다. AZ-a에 10.1.1.128/27 대역으로 한 개를 생성한다.

 

AZ-c에 같은 APP용 프라이빗 서브넷을 만들자. 대역은 10.1.1.160/27이다.

 

AZ-a에 DB용 프라이빗 서브넷을 생성하자. 대역은 10.1.1.192/27이다.

 

마지막으로 AZ-c에 DB용 프라이빗 서브넷을 생성한다. 대역은 10.1.1.224/27이다.

 

이렇게 총 6개의 서브넷을 만들고 최종적으로 'Create subnet'을 클릭하자. 총 6개의 서브넷이 생성됨을 확인할 수 있다.

 

 

 

인터넷 게이트웨이 생성

이제 인터넷 게이트웨이를 생성해 보자. 인터넷 게이트웨이는 VPC가 인터넷과 통신할 수 있도록 해준다. 

인터넷 게이트웨이를 생성하려면 Virtual Private Cloud 섹션에 Internet gateways를 선택하자.

 

우측 상단 'Create internet gateway'를 클릭해서 만들자. Name tag를 입력하고 생성을 끝마치면 된다.

 

생성하고 나면 인터넷 게이트웨이 메인 화면에서 우측 상단 'Actions' 셀렉트 박스가 있다. 거기에 Attach to VPC를 클릭해서 만든 VPC와 인터넷 게이트웨이를 연결하자.

 

위에서 만든 VPC와 연결을 하면 된다.

 

 

라우팅 테이블 생성

라우팅 테이블은 VPC 내 서브넷들이 특정 IP로 향할 때 어디로 가야 하는지에 대한 정보를 저장하고 있는 것으로 생각하면 된다.

우선 만들면서 이해하면 더 빠를 것 같다.

 

마찬가지로 VPC > Virtual private cloud > Route tables로 이동하자. 우측 상단의 Create route table을 클릭해서 생성하면 된다.

Name과 VPC를 설정한 후 생성하면 끝난다. 지금 생성하는 라우트 테이블은 Public Subnets을 위한 라우트 테이블이다.

 

하나 더 생성한다. 이번엔 Private Subnets을 위한 라우트 테이블이다. 이름만 'my-private-route'로 달리 생성하자.

그렇게 되면 방금 만든 두 개의 라우트 테이블이 있다. 

public route는 public subnet을 위함이다. public subnet은 외부와 통신이 가능해야 한다. 그래서 외부와의 통신을 하기 위한 인터넷 게이트웨이를 만들었고, public route에게 해당 인터넷 게이트웨이를 알려줘야 한다. 그 작업을 위해 my-public-route 내부로 들어가자. 하단 Routes 탭에 Edit routes를 클릭하면 된다. 여기 설정된 기본 라우트 탭은 라우트 테이블을 만들면서 연결한 VPC가 기본으로 테이블에 등록되어 있다.

즉, 10.1.0.0/16은 로컬과의 통신을 하면 된다는 뜻이고 여기서 설정할 0.0.0.0/0은 외부로 나갈 인터넷 게이트웨이와 통신을 하게 설정하면 된다.

 

즉, 최종 public-route는 다음과 같은 설정값을 가진다.

이 뜻은 이 public route에 할당된 서브넷들은 VPC 내부(10.1.0.0/16)에서는 VPC 내부적으로 통신을 하고 그 외 모든 목적지(0.0.0.0/0)는 인터넷 게이트웨이와 통신을 할 것이라는 의미가 된다. 

 

private route는 VPC 내부와 밖에서는 안으로 들어오지 못하게 하고 안에서 밖으로는 나갈 수 있어야 하기 때문에 NAT Gateway가 필요하다. NAT Gateway는 내부에서 외부로 나가는 것만 허용한다. 그래서 private route에 등록할 NAT Gateway를 먼저 만들어보자.

 

NAT Gateway 생성

NAT Gateway란 무엇일까?

 

퍼블릭 서브넷과 프라이빗 서브넷이 공존할 때 프라이빗 서브넷은 인터넷과 통신이 불가능한 네트워크 공간이고 퍼블릭은 인터넷과 통신이 가능한 네트워크 공간이다. 이때 프라이빗 서브넷은 말 그대로 프라이빗하게 즉, 보안에 있어 취약하면 안 되는 민감한 데이터를 다루는 곳이어야 한다. 예를 들면 데이터베이스가 있는 곳. 자, 데이터베이스를 프라이빗 서브넷에 위치한 EC2에 설치해 보자. 여기서 의문이 생긴다.

근데 인터넷과 통신이 안되는데 어떻게 설치를 하지?

 

그렇다. 인터넷과 통신이 불가능한데 설치를 할 수 있을 리 없다. 즉, 이 프라이빗 서브넷일지라도 인터넷과의 통신이 필요한 경우가 더러 있는데 이럴 때 인터넷과 통신을 가능하게 해주는 녀석이 바로 NAT Gateway이다. 

 

위 그림에서 Private subnet App A에서 인터넷과 통신을 하고 싶으면 인터넷과 통신할 수 있는 Public subnet A에 있는 NAT Gateway에게 트래픽을 알려야 한다. 그래서 흐름은 다음과 같다.

중요!
1. Private subnet App A에서 인터넷(ex: 211.158.2.3)으로 요청을 보낸다.
2. Private subnet App A에 매핑된 route table을 보니 로컬로 등록된 IP가 아닌 IP들은 전부 NAT Gateway를 향한다.
3.  NAT Gateway로 트래픽을 보낸다.
4. NAT Gateway는 받은 트래픽을 실제 요청지를 저장한 후 다시 Router로 보낸다. Router는 Public subnet A에 매핑된 route table을 확인한다.
5. 확인해 보니 0.0.0.0/0은 Intenet Gateway로 향하고 있다. Internet Gateway로 트래픽을 보낸다.
6. 인터넷으로의 요청에 대한 응답을 Internet Gateway가 받았다. 받으면 이 응답을 Router가 받아서 route table을 확인한다. 응답받을 곳은 NAT Gateway 이므로 NAT Gateway로 향한다.
7. NAT Gateway로 응답을 받고 이 녀석이 저장해 둔 원래 요청지인 Private subnet App A로 다시 응답을 보낸다.
8. Router는 응답을 보낼 주소를 route table에서 찾는다. 찾아보니 Private subnet App A를 가르키고 있다. 해당하는 곳으로 응답을 보낸다.

이 흐름이 NAT Gateway를 통한 Private subnet이 인터넷과 통신하는 방법이다. 이 흐름을 보니 왜 NAT Gateway가 Public subnet에 존재하는지 더 명확하게 알 수 있었다. 인터넷과 통신을 하기 위해서는 Public subnet에 매핑된 route table을 참조해야하기 때문이다.

 

Public subnet에 매핑된 route table은 0.0.0.0/0이 Internet Gateway를 향하고 있고 Private subnet에 매핑된 route table은 0.0.0.0/0이 NAT Gateway를 향하고 있기 때문이다.

 

프라이빗 서브넷의 인스턴스가 다른 VPC, 온 프레미스 네트워크 또는 인터넷의 서비스에 연결하는 데 사용할 수 있는 가용성이 뛰어난 관리형 NAT(Network Address Translation) 서비스를 말한다.

 

NAT Gateway는 두 가지 유형이 있다.

• 퍼블릭: 프라이빗 서브넷의 인스턴스는 퍼블릭 NAT Gateway를 통해 인터넷에 연결할 수 있지만 인터넷으로부터 원치 않는 인바운드 연결을 수신할 수 없다. 
• 프라이빗: 프라이빗 서브넷의 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다.

 

NAT Gateway를 생성해 보자. VPC > Virtual private cloud > NAT gateways로 들어와서 'Create NAT gateway'를 클릭하자.

 

생성 화면에서 NAT gateway settings 섹션에 Name, Subnet을 설정한다. Subnet은 이 NAT Gateway가 어디에(어떤 Subnet) 위치할 것인지에 대한 설정이다. 생성한 퍼블릭 서브넷 A에 위치시킬 것이고 '탄력적 IP 할당' 버튼을 클릭해서 Elastic IP를 할당시킨다.

Elastic IP를 NAT gateway에 할당하면 NAT gateway의 이 Elastic IP를 소스 IP로 사용해서 인터넷 게이트웨이로 트래픽을 보낼 수 있고 VPC 외부로 내보낼 수 있게 된다.

 

이렇게 설정하고 하단 'Create NAT gateway' 버튼을 클릭해서 NAT gateway를 생성한다. 그러면 생성한 NAT gateway가 리스트에 노출됨을 확인한다. 

 

이제 이 NAT gateway를 프라이빗 라우트 테이블에 연결해 주자. 그러면 프라이빗 서브넷에서 외부로 나갈 수 있게 설정하는 것.

Route tables 화면에 생성한 'my-private-route'를 선택하고 Routes 탭에서 'Edit routes'를 클릭한다.

 

기본 설정인 10.1.0.0/16은 VPC 대역이다. 즉 VPC 대역은 로컬로 라우팅을 한다는 의미이고 그 외 모든 대역(0.0.0.0/0)은 NAT gateway로 타겟을 설정한다는 의미가 된다.

 

이제 이 설정대로 움직일 서브넷들을 각 라우트 테이블에 연결해 주면 된다. public route에는 퍼블릭 서브넷들을, private route에는 프라이빗 서브넷들을 연결해주면 된다.

 

'my-public-route'를 선택하고 하단 Subnet associations에 'Edit subnet associations'를 클릭한다.

 

서브넷 선택 화면에서 퍼블릭 서브넷들을 선택하고 저장한다.

 

다음은 my-private-route를 선택하고 서브넷을 연결한다. 여기에는 프라이빗 서브넷들은 선택하면 된다.

 

 

 

EC2 인스턴스 생성

이제 Public subnet A에 EC2 인스턴스를 만들어보자. 이 인스턴스는 Bastion(요새, 보루 즉 거쳐가는 곳을 의미) Host라는 개념으로 보면 된다. 여기를 통해서 AWS DevOps 유저가 직접 접근하여 Private subnet에 있는 EC2 인스턴스에 들어갈 수 있게 될 것.

 

 

Security group 생성

AWS Console에 EC2를 검색해서 EC2 Instances로 들어가자. 그래서 새로운 EC2 인스턴스를 만든다. 그러나 인스턴스를 만들기 전 한 가지 먼저 진행할 부분이 있는데 '보안 그룹' 생성을 먼저 하자. Security group을 생성해서 만들 EC2에 해당 보안 그룹을 적용할 것인데 이는 이 인스턴스에 SSH로 접속하는 인바운드 규칙을 만들기 위함이다. 위 큰 그림에서 볼 수 있듯 'AWS DevOps 유저는 Public subnet A에 있는 EC2에 직접 접근할 수 있어야 한다. 그것을 허용하게 하는 보안 그룹을 생성할 것이다.

 

EC2 > Network & Security > Security Groups에 들어가서 'Create security group'을 클릭하자.

 

생성하는 화면에서 Security group name, Description, VPC에 값을 지정한다. VPC는 위에서 만든 VPC를 선택한다.

하단 인바운드 규칙에서는 AWS DevOps 유저가 오로지 현재 본인 만이라고 가정하고 SSH 접속 허용 IP를 My IP로 할당하자.

 

그리고 생성하기를 누르면 리스트에 방금 만든 보안그룹이 보인다.

 

Bastion Host(EC2) 생성

이제 인스턴스를 생성해 보자. 생성 화면에서 인스턴스의 Name을 설정한다. 그리고 OS Image는 Amazon Linux를 사용한다.

 

Key pair는 새로 생성을 해도 되고 기존에 사용했던 key pair가 있으면 그대로 사용해도 된다. 지금은 새로 만들어 사용한다.

 

Network settings는 위에서 만든 VPC와 서브넷은 Public Subnet A로 설정하고 보안 그룹은 방금 막 만든 보안그룹으로 세팅한다.

 

나머지 값은 그대로 둔 채 생성을 한다. 인스턴스 리스트에 생성한 인스턴스가 잘 보인다.

 

Elastic IP를 생성한 EC2에 할당

이제 Elastic IP를 방금 생성한 EC2에 할당한다. Network & Security > Elastic IPs로 가서 우측 상단 Allocate Elastic IP address를 클릭한다.

 

모든 값은 기본값으로 두고 하단 'Allocate' 버튼을 누르면 방금 생성한 Elastic IP가 나오고 그 녀석을 선택해서 방금 만든 EC2에 할당한다.

 

EC2에 잘 할당됐는지 확인하기 위해 Instances로 가서 방금 만든 EC2에 저 Elastic IP가 잘 할당됐는지 확인해 보자. 생성한 EC2를 선택하면 하단에 정보가 나오는데 Public IPv4 주소를 보면 방금 생성한 Elastic IP가 잘 할당됐음을 확인할 수 있다.

 

 

Private Subnet App A의 인스턴스에 할당할 보안 그룹 생성

위 전체 네트워크 설계 그림에서 보면 Bastion Host(Public Subnet A의 EC2)에서 Private Subnet App A에 있는 인스턴스에 접속할 수 있는 상태이다. 이러기 위해서는 Private Subnet App A에 보안 그룹을 할당해서 Bastion Host로부터 SSH로 들어오는 인바운드 규칙을 할당해줘야 한다. 이 작업을 해주자.

 

EC2 > Network & Security > Security Groups > Create security group

 

Name, Description, VPC를 설정해 주고 (VPC는 위에서 만든 VPC) 인바운드 규칙에 SSH로 들어오는 것들 중 허용하는 소스는 위에서 Bastion Host에 할당한 보안 그룹만 할당한다. 즉 Bastion Host에 SSH로 접속 가능한 호스트는 이 Private Subnet App A의 인스턴스에도 SSH로 접속이 가능하다는 의미가 된다.

생성이 잘 됐으면 Private Subnet App A에 생성할 EC2를 만들자.

 

Private Subnet App A EC2 생성 

 

Name을 적절히 설정해주고 OS Image는 Amazon Linux, 그 외 다 기본값으로 설정하고 Key pair는 위에서 만든 EC2에 사용한 것을 그대로 사용한다.

 

Network settings는 VPC는 위에서 만든 VPC, Subnet은 Private Subnet App a, Security group은 방금 만든 보안 그룹을 선택하고 생성을 완료한다.

 

생성이 완료되면 인스턴스 리스트에 잘 보이면 된다.

 

 

Copy file over SSH

이렇게 생성이 다 됐으면 Bastion Host에서 Private EC2에 SSH로 접속이 가능해야 한다. 보안 그룹을 그렇게 세팅했으니까. 

근데 여기서 한 가지 더 해줄 작업이 있는데 보안 그룹은 Bastion Host로부터 SSH로 접속 가능하게 인바운드 규칙을 만들었는데 그때 사용할 Key pair는 그대로 같은 Key pair를 사용했기 때문에 Bastion Host에 접속할 키를 Bastion Host에도 저장해놔야 한다. 그러기 위해 로컬에서 SSH를 이용해서 다른 서버로 파일을 카피하는 명령어로 .pem키를 우선적으로 보내자.

scp -i <path-to-local-private-ssh-key> <path-to-local-file> <server-user@server-ip-address>:<path-to-destination-folder>

 

위 명령어로 로컬 파일을 SSH를 통해 다른 서버에 복사할 수 있다. 본인의 경우는 다음과 같이 실행했다.

scp -i my-ec2-keypair.pem ./my-ec2-keypair.pem ec2-user@43.200.54.122:/home/ec2-user

 

그리고 EC2(Bastion host)에 들어가서 확인

 

 

Connect 'Public Subnet A EC2' to 'Private Subnet App A EC2' via SSH

이제 진짜 Bastion host에서 private EC2에 접속해 보자. 우선 Private EC2의 Private IPv4 Address를 확인하자.

 

Bastion host에 들어간 후 다음 명령어로 private EC2에 들어가 보자. 당연히 다음처럼 명령어를 사용하려면 .pem 파일이 있는 경로에서 실행해야 한다.

ssh -i my-ec2-keypair.pem ec2-user@10.1.1.156

 

그러면 이와 같이 정상적으로 접속이 됐음을 확인할 수 있다.

 

들어와서 한 가지 더 확인할 게 있다. 바로 NAT gateway를 통해 내부에서 외부로 통신이 가능한지를 확인하는 것. 다음 명령어를 통해 외부 인터넷으로 통신이 가능한지 확인해 보자.

curl -v www.google.com

 

결과는 다음처럼 200 OK가 나와야 한다. 

 

 

OpenVPN을 이용해 Bastion Host 대신 Private Subnet EC2에 접속해 보기

위 전체 네트워크 설계 그림에서 변경되는 부분이다.

 

Public subnet A에는 OpenVPN용 EC2가 만들어질 예정이다. 그리고 그 OpenVPN을 통해서 Private EC2에 접속해 보자.

 

 

OpenVPN EC2 만들기

Name은 my-openvpn-ec2로 설정한다.

 

OS Image는 'openvpn'으로 검색

 

보이는 화면에서 AWS Marketplace AMIs에 가장 상위에 있는 OpenVPN Access Server 이미지를 선택한다.

 

나머지 설정은 그대로 하고 Key pair는 위에서 사용한 그대로 사용한다. 

 

이제 Network settings은 VPC는 위에 만든 VPC, Subnet은 public subnet A, 보안 그룹은 기본으로 설정된 보안 그룹 그대로 가져가되, 아래 규칙은 모두 My IP로만 가능하게 변경하자. 아래 사진 말고 더 있다. 나오는 거 전부 My IP로 선택.

 

 

이렇게 설정한 다음 생성해서 EC2를 만든다. 이렇게 만들었으면 Elastic IP를 이 EC2에 할당해줘야 한다. Elastic IP는 생성하고 할당하는 것까지 위에서 해봤으니 그대로 하면 된다. 할당했으면 EC2에 그 할당된 IP를 확인하여 SSH로 접속한다. 본인의 경우 Elastic IP는 다음과 같다. 접속 유저명은 'openvpnas'로 한다.

ssh -i my-ec2-keypair.pem openvpnas@3.34.163.7

 

접속하면 이러한 OpenVPN 설정 화면이 노출된다.

 

모두 기본값 설정으로 적용하고 설정이 완료되면 다음처럼 Admin URL이 보인다.

 

이 경로로 접속해 보자. 접속하면 다음처럼 경고 화면이 나오는데 '안전하지 않음'으로 접속하면 된다.

 

그러하면 드디어 이러한 화면이 나온다.

 

로그인하기 위해 유저 정보를 가져와야 하는데 기본값은 최초 OpenVPN 설정하는 부분에서 알려준다.

 

유저명은 'openvpn' 패스워드는 'aPlXOBiWw0RL'로 되어있다. 이렇게 로그인해 보자.

이렇게 로그인이 잘 되고 'Agree'를 클릭

로그인이 되면 좌측 USER MANAGEMENT > User Permissions에 들어가서 유저를 새로 만들어보자.

 

자동 로그인 설정과 패스워드를 입력하고 저장하자.

 

 

이제 이 유저로 로그인이 잘 되는지 Admin 패널이 아닌 일반 URL로 들어가서 로그인해 보자.

 

Sign In을 클릭하면 다음 화면이 나온다.

 

위 화면에서 OpenVPN Connect for all Platforms 섹션에서 본인의 OS에 맞게 설치를 하자.

본인의 경우 macOS라 다음처럼 보인다. 활성화 버튼을 토글 하면 Connect가 된다.

 

이제 OpenVPN으로 Public Subnet의 EC2에 접속이 되어 있는 상태이므로 로컬에서 Private Subnet App A의 EC2 인스턴스로 SSH로 바로 접속이 되는지 확인해 보자. 그러나 그전에, 위에서는 설정 안 한 게 있는데 OpenVPN EC2는 Bastion host랑은 다른 EC2이기 때문에 이 OpenVPN EC2를 생성했을 때 적용한 보안 그룹 또한 Private EC2에 인바운드 규칙으로 할당해줘야 한다.

 

Security Groups > my-private-ec2-sg에서 인바운드 규칙에 다음처럼 OpenVPN EC2를 생성했을 때 만든 보안 그룹을 추가한다. 

 

 

이제 접속해 보자.

EC2 > Instances에서 my-private-ec2의 private IP를 복사한 후 ssh로 접속해 보자.

ssh -i my-ec2-keypair.pem ec2-user@10.1.1.156

 

OpenVPN Connect를 하고 나면 로컬에서 다이렉트로 접근이 가능해진다.

 

당연히 위에서 테스트 한 Private EC2라서 NAT gateway를 통해 외부로 통신이 가능하다.

 

 

VPC Peering

이제 한 발 더 나아가서 Region이 다른 VPC간 Peering을 통해 서로 통신이 가능하도록 만들어보자.

그림은 다음과 같다.

서울과 도쿄에 있는 VPC간 Peering을 해서 서로 통신이 가능하게 해보자.

 

 

도쿄에서 VPC 생성

우선 Region을 Tokyo로 변경하자.

우측 상단 Region을 선택해서 원하는 Region으로 변경할 수 있다. 그리고 VPC를 만들어보자. 

 

생성 화면에서 VPC settings에 'VPC and more'를 선택하면 좀 더 템플릿 느낌으로 VPC와 그 외 Subnet, Network, Route tables등을 만들어준다.

 

여기서 추가 설정을 해주자. 우선 VPC IPv4 CIDR을 192.168.10.0/24로 설정한다.

 

그 다음 AZ는 2개, Public subnets 2개, Private subnets 2개, NAT gateway는 생성하지 않고, VPC endpoint도 생성하지 않는다.

 

그 외 나머지는 전부 기본 설정으로 하고 생성을 마친다. 생성이 끝나면 리스트에서 확인할 수 있다.

 

도쿄에서 EC2 인스턴스 생성

이제 EC2 인스턴스를 생성해보자. Name은 my-tokyo-private-ec2로 설정하고 Amazon Linux 이미지를 사용한다.

 

여기서는 서버에 직접 접근하지는 않을거니까 Key pair 생성도 생략한다.

 

네트워크는 방금 만든 도쿄의 VPC와 private subnet-1을 선택하면 된다.

 

그리고 생성 버튼을 누르면 키페어 없이 생성하는게 맞냐는 안내 팝업이 뜨는데 맞다고 해주고 생성을 진행하자.

 

 

보안 그룹 인바운드 규칙 수정

이제 생성된 인스턴스에 적용된 보안 그룹을 수정해야 한다. 서울에서 들어올 수 있게 서울 대역을 허용해주자.

 

 

VPC Peering connection

이제 도쿄 VPC에 피어링을 걸어보자. VPC > Virtual private cloud > Peering connections에서 우측 상단 'Create peering connection'을 클릭

 

Peering connection settings에서 로컬 VPC는 도쿄니까 도쿄의 VPC를 선택하고 연결할 VPC는 일단 내 계정의 다른 지역을 선택해서 서울을 선택하고 서울의 내가 가지고 있는 특정 VPC ID를 입력해주면 된다. 그리고 생성하자.

 

생성하고 나면 다음처럼 상단에 서울 지역으로 가서 이 요청을 수락해야한다라는 안내 토스트가 나온다.

 

서울의 피어링 연결로 가서 요청 대기중인 녀석을 수락해주자.

 

이제 거의 끝났다. 이제 확인만 해보면 되는데 SSH로 서울의 EC2 인스턴스 내부로 들어가자. 그러나 그 전에, 서울의 라우트 테이블에서 프라이빗 용 라우트 테이블에 도쿄 IP를 추가해줘야한다. 반대로도 마찬가지.

 

 

 

서울에서 도쿄로 Ping 날려보기

이제 모든 준비가 끝났다. 위에서 OpenVPN을 커넥트하면 로컬에서 바로 프라이빗 EC2 인스턴스에 SSH로 접속이 가능하다. 접속한 후 도쿄의 EC2 인스턴스 Private IPv4 Address로 핑 명령어를 입력하자.

ping 192.168.10.134

이처럼 핑을 날려서 잘 받으면 된다. 

 

 

결론 

VPC를 최초 생성해 보는것에 시작해서 AZ별 서브넷을 구축하고 퍼블릭 서브넷과 프라이빗 서브넷을 각각의 가용영역에 만들어서 퍼블릭 서브넷은 인터넷 게이트웨이에 프라이빗 서브넷은 NAT 게이트웨이에 연결하여 외부로 통신할 수 있게 하고 그 정의를 라우트 테이블에 해보았다. 더 나아가서 퍼블릭 서브넷에 EC2 인스턴스(Bastion host)를 만들어서 로컬에서 이 곳으로 접근하고 이 곳에서 프라이빗 서브넷에 있는 EC2에 접근하는것을 해보았고 그 과정에서 필요했던 보안 그룹 설정도 만들어보았다. 더 나아가서 Bastion Host에 접근해서 또 다른 EC2에 접근하는 게 아닌 OpenVPN EC2 인스턴스를 만들어서 이 인스턴스가 프라이빗 EC2에 연결할 수 있게 설정하고 로컬에서 OpenVPN을 이용해서 다이렉트로 프라이빗 서브넷의 EC2 인스턴스에 접속할 수 있게도 해보았다. 더 나아가서 서로 다른 Region에 VPC끼리 Peering을 해서 서울에서 도쿄로 통신하는 것까지.