AWS VPC, 제대로 이해하기 1
VPC 학습을 위해 데모 VPC, 서브넷, 라우팅 테이블 인터넷 게이트웨이 등을 구성하는 것이 본 포스팅의 목표입니다.
Background:: Public IP vs. Private IP
Public IP: 공인 IP. 인터넷이 사용자를 찾을 수 있도록 사용자를 식별하는 역할
Private IP: 사설 IP. 사설 네트워크에서 다른 장치와 안전하게 연결하기 위한 역할
공인 사설 나누는 이유는 무엇일까요?
공인 IP 주소와 사설 IP 주소가 모두 할당되는 이유는 장치 수에 비해 IP 주소가 충분하지 않기 때문입니다.
사설 IP 주소의 수는 공인 IP 주소의 수보다 훨씬 적습니다.
각 사설 네트워크에서만 사용되기에 여러 네트워크에서 IP 주소가 중복되더라도 문제가 없기 때문입니다.
Internet Assigned Numbers Authority (IANA)
IANA는 현재 ICANN이 관리하는 인터넷 할당 번호 관리기관의 약자로, IP 주소나 최상위 도메인 등을 관리하는 단체입니다. IANA는 사설private (LAN) 및 공용 public (Internet) 주소를 사용하기 위해 IPv4 주소의 특정 블록을 설정했습니다.
사설 IP(IPv4)는 아래 값들로 설정되어야 합니다.
10.0.0.0 - 10.255.255.255 (10.0.0.0/8) in big networks
172.16.0.0 - 172.31.255.255 (172.16.0.0/12) AWS default VPC in that range
192.168.0.0 - 192.168.255.255 (192.168.0.0/16) e.g. home networks
이외의 모든 IP 주소는 Internet 상에서 Public 입니다.
VPC
Virtual Private Cloud(VPC)
: 클라우드 내 가상의 사설 네트워크 환경
각 개인이나 기업이 클라우드를 사용할 때, 다른 그룹의 네트워크와 어떻게 구분할 수 있을까요?
가령, '개발 환경'과 '운영 환경'을 따로 두고, 각 다수의 클라우드 서비스를 여러 리전에 걸쳐 설정한다고 가정해봅시다.
이 때, 각 환경의 클라우드 서비스들을 그룹처럼 묶어 라벨을 붙여둔다고 생각해보세요.
각 그룹을 구분하기 용이할 뿐만 아니라, 서로 격리된 환경으로 만들어주죠.
VPC가 바로 이렇게 클라우드 상에서 논리적으로 격리된 공간으로 프로비저닝(사용할 수 있게 설정)하고,
정의한 가상 네트워크에서 클라우드 컴퓨팅 리소스를 사용할 수 있게 만듭니다.
* 참고로, 이렇게 하나의 인프라를 생성하고 설정하는 프로세스를 '프로비저닝provisioning'이라고 부릅니다. provision의 의미가 '무엇의 사용을 위해 공급되는 행위'임을 생각해보면, 클라우드에서 프로비저닝한다는 의미는 '사용하고자 하는 환경을 위해 준비 및 공급'한다는 의미로 생각하면 되겠죠.
한 글자씩 살펴보면 다음과 같습니다.
V - Virtual: 가상의, 가상화된 하드웨어에서 동작하는 가상화된,
P - Private: 사설의, 특정 유저 만을 위해 리소스를 외부로 부터 보호하고 있는,
C - Cloud: 클라우드. 물리적인 서버를 자체적으로 갖지 않아도 서버를 사용/관리/삭제하도록 제공된 컴퓨팅 환경
AWS VPC
단일 AWS Region에 여러 VPC를 가질 수 있습니다.
Region당 최대 5개까지 가능한데 엄격히 제한하지 않기 때문에(soft limit) 더 늘릴 수 있습니다.
여러 개의 VPC를 구분하는 방법은 CIDR를 정의하여 서로 다른 IP 대역을 갖게 만드는 것입니다.
CIDR를 처음 들으셨다면 CIDR, 어렵지 않게 이해하기를 참고하시길 바랍니다.
VPC 범위
하나의 AWS VPC가 가질 수 있는 범위를 알아보도록 하겠습니다.
VPC는 하나 당 최대 5개의 CIDR를 가질 수 있으며, 다음과 같은 범위를 가질 수 있습니다.
- VPC CIDR의 최소 크기: /28. 즉, $2^4 = 16$개
oooooooo.oooooooo.oooooooo.ooooxxxx/28 → $2^4 = 16$
- VPC CIDR의 최대 크기: /16. $2^{16} = 65,536$개
oooooooo.oooooooo.xxxxxxxx.xxxxxxxx/16 → $2^{16} = 65,536$
VPC는 사설 리소스이기 때문에 사설 IPv4 범위만 허용됩니다.
사설 IP 대역의 A, B, C 클래스로 나누는 바로 그 대역에 해당합니다.
✔️ 10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
✔️ 172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
✔️ 192.168.0.0 – 192.168.255.255 (192.168.0.0/16)
위의 대역 중에서 어떤 범위를 선택해야 할지에 대해서는 원하는 대로 할당할 수 있지만
VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의해야 합니다.
서로 다른 Public IP를 연결할 때 ⚠️ 각 그룹에서 사용하던 내부 VPC 혹은 CIDR IP 주소가 다른 네트워크의 IP 주소 범위와 겹치면 안되기 때문입니다.
Default VPC
모든 EC2 인스턴스는 VPC 위에서 동작합니다.
하지만, EC2 인스턴스를 사용한 적은 있어도 VPC 관리를 해본 적없는 분들도 있을 것입니다.
모든 새로운 AWS 계정에는 Default VPC를 가지는데, EC2 인스턴스가 생성될 때 특정 서브넷을 지정하지 않는 한 Default VPC에 실행되기 때문에 모르는 상태라도 EC2를 사용할 수 있었던 것입니다.
모든 EC2 인스턴스는 IPv4 DNS를 Public한 형태와 Private한 형태로 동시에 갖습니다. 여기에, Default VPC는 Internet Connectivity(연결성)을 가지기 때문에 EC2 인스턴스가 생성되고 인터넷에서 바로 연결할 수 있는 것입니다.
Name 값이 - 으로 지정되어 있는 VPC를 확인할 수 있는데, 이게 바로 default VPC입니다.
Default VPC의 IPv4 CIDR 블록을 확인해보면 172.31.0.0/16 인데요.
범위를 확인해보면 다음과 같습니다.
First IP가 172.31.0.0, Last IP가 172.31.255.255 인 것을 확인할 수 있습니다.
0.0 ~ .255.255까지 가능하니까 사용 가능한 호스트 개수는 $2^{16}$ 인 65,536 개가 됩니다. ($2^{8+8}$)
Subnets
공용 및 사설 서브넷을 어떤 방식으로 형성하는지 살펴볼게요.
서브넷이란 VPC 내부에 있는 IPv4 주소의 부분 범위입니다.
AWS는 Subnet을 처음 생성할 때, IP 주소 범위의 가장 첫 네 개와 마지막 한 개를 미리 예약합니다.
즉, 사용 가능한 IP 범위 내에서 가장 숫자가 작은 IP 4개와 가장 숫자가 큰 IP 1개, 총 5개를 선점한다는 의미입니다.
예를 들어 CIDR 가 10.0.0.0/24 일때, AWS가 미리 예약한 IP 주소는 아래와 같습니다.
✔️ 10.0.0.0 – Network Address
✔️ 10.0.0.1 – Reserved by AWS for the VPC router, VPC 라우터용
✔️ 10.0.0.2 – Reserved by AWS for mapping to Amazon-provided DNS, Amazon 제공 DNS에 매핑
✔️ 10.0.0.3 – Reserved by AWS for future use, 당장 사용되진 않지만 나중에 필요할지 모르니까 예약
✔️ 10.0.0.255 – Network Broadcast Address. AWS does not support broadcast in a VPC, therefore AWS reserves this address, 네트워크 브로드캐스트 주소로, AWS는 VPC에서 브로드캐스트를 지원하지 않기 때문에 AWS가 해당 IP를 예약
예약된 IP 주소는 사용이 불가하고, EC2 인스턴스에 IP로 할당되지 못합니다.
서브넷 IP 설정 주의점
위를 응용하자면, EC2 인스턴스 서브넷에서 IP 주소 29개가 필요할 때 /27 서브넷은 사용하지 못합니다.
/27 IP 주소는 32개를 사용할 수 있기 때문에, 예약된 IP 주소 다섯 개를 제외하면 27개만 남기 때문입니다.
따라서 만약, 29개의 서브넷 IP 주소가 필요하다면 64개를 제공하는 /26으로 설정해야 합니다.
예약된 IP 주소 다섯 개를 제거하면 59개가 되므로 충분히 사용할 수 있습니다.
정리하자면, 29개의 서브넷 IP가 필요할 때:
- /27 : $2^5 = 32$ IP Address, 32 - 5 = 27 < 29
- /26 : $2^6 = 64$ IP Address, 64 - 5 = 59 > 29
Integrating
분리된 환경을 사용하다 보면, 특정 서비스나 특정 환경을 연결 시켜야 할 필요가 생길 수 있습니다.
가령, AWS 클라우드 환경과 기업의 온프레미스 환경(프라이빗 자체 데이터 센터)을 연결하여 데이터 처리를 하고 싶을 수 있겠죠.
AWS에서 타 서비스나 환경 간의 연결은 다음의 세 가지 방법을 사용할 수 있습니다.
- AWS PrivateLink
- VPC Peering
- AWS Transit Gateway
위의 서비스로 AWS 네트워크를 프라이빗하게 연결합니다. 하나씩 알아보겠습니다.
AWS PrivateLink
AWS PrivateLink는 VPC와 AWS 서비스 간의 프라이빗 연결 private connectivity 를 제공합니다.
사용하는 네트워크 트래픽은 공용 인터넷을 통해 이동하지 않으므로 무차별 대입 및 분산 공격 denial-of-service (DDoS) 공격에 노출되는 것과 같은 외부 위협의 위험이 줄어듭니다.
두 당사자가 인터넷 게이트웨이 없이도 개인 연결을 설정할 수 있는 방법을 제공합니다.
연결된 두 대상은 인터넷상의 위협으로부터 격리된 프라이빗 VPC를 배포할 수 있습니다.
VPC Peering
VPC 피어링 연결은 프라이빗 IPv4/IPv6 주소로 두 개의 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 네트워킹 연결입니다.
서로 다른 VPC가 통신하려면 VPC 피어링을 활성화해야 하고, 동일한 네트워크에 속해야 VPC의 인스턴스가 서로 통신할 수 있기 때문입니다. 즉, 목적은 VPC가 모두 같은 네트워크에서 작동하도록 만들기 위함이죠.
사용자의 자체 VPC 또는 다른 AWS 계정의 VPC와 VPC 피어링 연결을 만들 수 있습니다.
VPC는 상이한 리전에 있을 수 있습니다. (리전 간 VPC 피어링 연결이라고도 합니다)
VPC 피어링의 특징 중 알아야 할 것이 몇 가지 있는데요.
먼저, VPC 네트워크 CIDR가 겹치면 안됩니다. 연결 시 CIDR가 겹치면 통신 불가하기 때문입니다.
그리고, 두 VPC 간에 발생하며 전이되지 않는다(NOT transitive)는 것입니다.
NOT transitive, 전이 불가
전이가 불가능하는 것이 어떤 의미일까요?
분리된 환경의 VPC A, B, C가 있다고 해봅시다.
A -⭕️-> B: A와 B는 Peering 연결 생성 -> 통신 가능 상태
B -⭕️-> C: B와 C는 Peering 연결 생성 -> 통신 가능 상태
A -❌-> C: A와 C의 VPC 피어링 연결을 활성화해야 둘이 통신 가능
⚠️ 또한 VPC 피어링이 있을 때 활성화, VPC 서브넷 상의 Root Table을 업데이트해서 EC2 인스턴스가 서로 통신할 수 있게 해야 합니다.
VPC Peering은 가능 다른 계정 간, 리전 간(Cross Account / Cross Region)에도 가능합니다.
동일 리전의 계정 간 Peered VPC에서 보안 그룹을 참조할 수도 있습니다.
Peering CIDR이나 IP를 소스로 가질 필요가 없고 보안 그룹을 참조할 수도 있습니다.
AWS Transit Gateway
AWS 네트워크 토폴로지는 꽤 복잡해질 수 있습니다.
하지만, 위의 두 서비스(PrivateLink, VPC Peering)은 여러 VPC를 연결하기에 꽤 복잡한 작업이 필요합니다.
Transit Gateway를 사용하면 네트워크 토폴로지를 간소화하고 다수의 VPC 간의 복잡한 피어링 관계를 피할 수 있습니다.
전이적 피어링 연결(transitive peering)을 통해 VPC 수천 개와 온프레미스 데이터 센터(Site-to-Site VPN)를 연결할 수 있죠.
여러 네트워크 환경이 스타형의 Hub-Spoke(허브와 스포크) 형식으로 연결될 수 있습니다.
AWS에서 유일하게 IP 멀티캐스트를 지원하는 서비스이기도 합니다.
Transit Gateway를 사용하여 타사 서비스를 통합하면 다음과 같은 이점이 있습니다.
- VPC와 타사 네트워크 간의 양방향 트래픽 지원
- 모든 유형의 IP 트래픽 지원 (TCP 및 UDP 모두)
- VPC와 타사 네트워크 사이에 중앙 집중식 트래픽 검사 지점을 배포
- 통합에 관련된 VPC 수가 변경됨에 따라 손쉽게 확장 가능
Transit Gateway 솔루션을 사용할 때의 단점은 다음과 같습니다.
- 이 옵션은 일반적으로 다이렉트 피어링 옵션보다 더 비쌈
- 겹치는 CIDR 블록은 지원 X
- 완벽한 제어를 유지 / 구성 요소 공유 최소화를 위해 자주 사용되지 않음
Endpoints
VPC 내 AWS 서비스에 액세스하려면 엔드포인트를 사용합니다.
만약, Private Subnet에 있는 EC2가 VPC 외부와 통신하려면 어떻게 해야 할까요?
기본적으로 모든 AWS 서비스는 퍼블릭 인터페이스이므로 공개적으로 열려 있려 있습니다.
아래 그림에서 보이듯이 말이죠.
트래픽이 VPC에서 AWS 서비스로 이동할 수 있도록 VPC에 인터넷 게이트웨이를 추가해야 합니다.
VPC Endpoint
VPC Endpoint의 종류에는 Interface Endpoint와 Gateway Endpoint가 있습니다.
하나 씩 확인해보도록 하겠습니다.
Interface Endpoint
AWS Interface Endpoint는 AWS PrivateLink를 사용하여 VPC를 AWS 서비스에 연결합니다.
이 경우 인터넷 게이트웨이를 사용하지 않고 서비스를 VPC에 있는 것처럼 이용할 수 있습니다.
ENI 프로비저닝한 형태로, ENI는 VPC의 Private IP 주소이자 AWS의 엔트리 포인트가 됩니다.
참고로, ENI가 있으므로 반드시 보안 그룹을 연결해야 합니다.
VPC 엔드포인트를 사용하면 AWS PrivateLink와 통합된 AWS 서비스에 비공개로 액세스할 수 있습니다.
이 경우 인터넷 게이트웨이를 사용하지 않고도 애플리케이션 스택의 모든 계층을 구축하고 관리할 수 있습니다.
특징을 정리하면 다음과 같습니다.
- AWS의 PrivateLink 기반
- AWS 서비스들에 접근할 때 Internet Gateway, NAT Gateway의 필요 X
- 인터페이스 VPC 엔드포인트는 TCP를 통한 트래픽만 지원
- AWS PrivateLink 리소스에는 할당량이 있음
- 대부분의 AWS 서비스를 지원
- 청구 요금은 시간 단위 또는 처리되는 데이터 GB 단위
Gateway Endpoint
특이하게도 게이트웨이를 프로비저닝한 형태입니다.
게이트웨이는 반드시 라우팅 테이블의 대상이 되어야 합니다.
게이트웨이 엔드포인트를 사용하면 VPC용 인터넷 게이트웨이 또는 NAT 디바이스가 없어도 Amazon S3 및 DynamoDB에 안정적으로 연결할 수 있습니다. 게이트웨이 엔드포인트는 AWS PrivateLink를 활성화하지 않습니다.
게이트웨이 엔드포인트 사용에 따르는 추가 요금은 없습니다.
특징을 정리하면 다음과 같습니다.
- IP 주소를 사용하거나 보안 그룹을 사용하지 않고 라우팅 테이블의 대상이 될 뿐
- 라우팅 테이블 액세스일 뿐이므로 자동으로 확장
- Amazon S3와 DynamoDB 두 가지 사용 가능
- 무료
- 확장성이 더 높음 (라우팅 테이블만 수정하면 되기 때문에 Interface Endpoint보다 용이)