AWS에서의 라우터는 AWS에 있는 Gateway와 네트워크 대역대의 길을 정의해줍니다.
여기서 먼저 AWS Cloud에서 Private과 Public에 대한 정의를 말씀드리면,
Public은 자신의 IP 대역(CIDR, Subnet)이 Internet Gateway와 라우팅이 되어 있을 경우 Public 하다라고 이야기하며,
Private의 경우에는 IGW와 라우팅이 되어 있지 않은 경우를 말합니다.
따라서 Private Subnet이다 라고 하면, 외부 인터넷에서 접속 할 수가 없는 상태인 것이죠.
아래 예제를 보시면서 라우팅이 어떻게 구성되는지 보겠습니다.
위의 예제를 보시면 VPC는 기본적으로 Private 구성되기 때문에
먼저, 172.16.0.0/16의 대역대는 VPC local을 향하도록 지정합니다.
즉, AWS VPC안에 있는 Private Network가 서로 통신이 가능하도록 하는 것 입니다.
또한 모든 대역대를 의미하는 0.0.0.0/0 대역이 Internet Gateway를 향하도록 지정하여 인터넷 통신을 가능하게 합니다.
마지막으로 vgw와 같이 192.168.100.0/24 대역대가 virtual private gateway를 향하도록 하여
외부의 다른 VPN 혹은 DX를 통해 이어진 IP 대역이 vgw를 통해 네트워크 통신이 가능하도록 할 수 있습니다.
그렇다면, Private Network에 있는 서버들은 인터넷과의 통신을 해야할 때, 어떻게 해야할까요?
패치나, 새로운 라이브러리를 다운받는 다던지 AWS 서비스가 인터넷에 있기 때문에 통신이 되어야 할 것입니다.
이럴 경우 AWS의 NAT를 사용하시면 됩니다.
기본적으로 NAT는 Network Address Translation이라는 의미로 말 그대로 네트워크 주소를 변환시켜 주는 것입니다.
예를 들면 CIDR가 같아서 통신이 어려울 경우 NAT를 구성하여 통신할 수 있는 것이죠.
하지만, AWS의 NAT GW는 위와 같은 용도의 서비스는 아닙니다.
Private한 네트워크 대역이 NAT GW가 가지는 Public IP(EIP)로 주소를 변환 시켜 인터넷 통신을 해줄 수 있게 하는 용도입니다.
따라서 다음과 같이 구성하여 Private한 서버들이 인터넷을 사용할 수 있습니다.
Route Table을 보시면, Public Subnet은 Internet gateway와 라우팅이 되어 있고,
Private 서브넷은 Internet gateway와 라우팅이 되어 있지 않아 인터넷과 통신을 할 수 없는 상태입니다.
하지만 NAT Gateway와 라우팅을 함으로써, Private 서브넷에 있는 서버들의 통신을 NAT GW로 보내고,
NAT GW는 Public하게 라우팅이 되어 있기 때문에 자신의 Public IP를 가지고 IGW를 통해 인터넷 통신을 하고
응답을 각 서버에 다시 보내주게 됩니다.
이러한 역할을 해주는 것이 AWS의 NAT GW이며, 이에 알맞는 라우팅 구성 또한 할 수 있어야합니다.
그렇다면, 이쯤에서 꼭 AWS 서비스를 하기 위해서 꼭 인터넷 망을 통해야 하는 것인지 의문이 드실 수 있습니다.
S3와 DynamoDB와 Private한 통신을 하고 싶으시다면, VPC Endpoints를 사용하시면 되고,
그 외의 서비스는 Private Link를 통해서 Private하게 통신을 하실 수 있습니다.
먼저, VPC Enpoints의 예시를 한번 보도록 하겠습니다.
VPC Endpoint는 Gateway Type이기 때문에, 위와 같이 라우팅을 해주셔야하며,
정책을 가지고 특정 S3 버킷에만 통신을 하게 한다던지, 혹은 특정 IP 대역만 통신할 수 있게 설정하실 수도 있습니다.
만약 보안 정책상 Security Group의 Outbound를 모두 오픈하지 못하여 S3와 통신이 제대로 하기 힘들 경우
위와 같은 구성을 통해 해결하실 수 있는 것입니다.
다음은 Private Link에 대해서 보도록 하겠습니다.
VPC EndPoint를 사용하지 못하는 S3, DynamoDB를 제외한 서비스들은
Private Link로 구성하게 되면 VPC 내부망 통신을 할 수 있습니다.
구성이 가능한 서비스는 위와 같으며, Inferface Type으로 ENI - DNS를 통해 접근하기 때문에
라우팅 테이블 설정이 필요하지 않습니다. 단, Security Group이나 NACL 설정 부분은 체크할 필요가 있겠습니다.
제약사항에 대해서는 AWS 공식 다큐에서 상세하게 제공하고 있으므로,
위의 링크를 참조하시는게 가장 좋을 것 같습니다.
제가 생각하기에 구성에서 꼭 검토해야 할 점은 다음과 같습니다.
1. 각 인터페이스 엔드포인트에서 가용 영역당 1개의 서브넷만 선택할 수 있습니다.
2. 인터페이스 엔드포인트를 통해 모든 가용 영역에서 서비스를 사용할 수 없을 수 있습니다. 지원되는 가용 영역을 확인하려면 describe-vpc-endpoint-services 명령을 사용하거나 Amazon VPC 콘솔을 사용하십시오. 자세한 정보는 인터페이스 엔드포인트 생성 단원을 참조하십시오.
3. 서브넷에 대한 네트워크 ACL이 트래픽을 제한하는 경우 엔드포인트 네트워크 인터페이스를 통해 트래픽을 보내지 못할 수 있습니다. 서브넷의 CIDR 블록에서 주고 받는 트래픽을 허용하는 적절한 규칙을 추가해야 합니다.
4. 엔드포인트는 동일 리전에서만 지원됩니다. VPC와 다른 리전의 서비스 간에 엔드포인트를 만들 수 없습니다.
5. VPC 간에 또는 서비스 간에 엔드포인트를 전송할 수 없습니다.
6. VPC당 만들 수 있는 엔드포인트 수는 제한이 있습니다. 자세한 내용은 VPC 엔드포인트 단원을 참조하십시오.
다음 게시글에서는 VPC Peering, Transit Gateway, VPN, Direct Connect 까지 간단하게 어떤 서비스이며, 어떠한 구성을 가지는지 알아보도록 하겠습니다.
'AWS Intro > AWS Network Intro' 카테고리의 다른 글
| AWS Network Intro - Elastic Load Balancer (1) | 2020.01.21 |
|---|---|
| AWS Network Intro - Security Group, NACL, EIP, Route53 (0) | 2020.01.20 |
| AWS Network Intro - VPC Peering, Transit Gateway, VPN, Direct Connect (0) | 2020.01.19 |
| AWS Network Intro - CIDR, Subnet (1) | 2020.01.19 |
| AWS Network Intro - VPC, AZ, Region (0) | 2020.01.19 |
