결국 클라우드 포메이션으로 강제로 공부하게 되는 부분을 설명하다 보니 하나의 설명이 되어 가고 있어서 별도 글로 작성한다.
VPC와 서브넷
AWS의 가장 기본이 되는 VPC, Subnet, 라우팅 테이블 등 일부 내용의 설명
아래 그림은 VPCs and Subnet 이라는 문서에서 나온 그림이며, 이해하고 나면 정말 설명을 잘 해놨다는 생각이 든다.
하지만 이해 하기 전에는 대체 무슨 소리를 하는지 알기 어렵다.
정말 친절하게도 이런 그림을 그려놨다. 배포된 자원을 약간 글로 풀어보면
- VPC
- 서브넷1
- 인스턴스 1A
- 프라이빗 IPv4 사용
- Elastic IP 연결
- 인스턴스 1B
- 프라이빗 IPv4 사용
- IPv6 사용
- 서브넷2
- 인스턴스 2A
- 프라이빗 IPv4 사용
- 서브넷3
- 인스턴스 3A
- 프라이빗 IPv4 사용
- 외부 VPN 연결
이렇게 풀어도 설명이 쉽지가 않아서 하나하나 설명을 해보면...
퍼블릭 서브넷과 프라이빗 서브넷
먼저 위 내용에서 이해할 첫번째는 서브넷1은 퍼블릭 서브넷이고, 서브넷2,3은 프라이빗 서브넷이다.
그 둘의 차이는 퍼블릭 서브넷은 외부에서 직접 IP를 찍어서 들어올 수 있는 서브넷이고, 프라이빗 서브넷은 다른 자원(Load balancer,Proxy 등)을 통하지 않으면 들어올 수 없다.
서브넷1-퍼블릭 서브넷
그래서 퍼블릭 서브넷인 서브넷1은 외부에서 Elastic IP나 IPv6 주소로 직접 접근이 가능하고, 나가는 것도 Default routing(0.0.0.0/0, ::/0)이 있기 때문에 가능하다.
하지만 그 대상이 igw-id 인데, 이 id는 일반 네트워크에서 사용하는 IP가 아니라 aws의 자원id이고, 이는 아래에서 다시 설명하겠다.
서브넷2-프라이빗 서브넷
VPC내 프라이빗 서브넷만 생성하면 완벽히 단절된 네트워크를 만들 수 있다.
이 서브넷에서 인터넷으로 연결하려면 NAT 기능을 사용해야하는데, NAT Gateway를 예로 들면 Elastic IP가 필요하고 퍼블릭 서브넷에 생성해야 한다.
그래서 보통 집이나 회사에서 사용하는 것처럼 외부에 노출되지 않고 인터넷이 가능한 프라이빗 서브넷을 aws에 생성하려면 퍼블릭 서브넷과 프라이빗 서브넷을 동시에 만들어야 한다.
결론적으로 위 그림에서 서브넷2의 경우 NAT 역할을 하는 NAT 역할을 해주는 자원이 없어 1A,1B 인스턴스가 NAT 역할을 해주지 않으면 2A의 인스턴스는 인터넷으로 나갈 수 없다.
서브넷3-프라이빗 서브넷+VPN
그런데, 서브넷3은 또 다르다. 서브넷3은 Default Routing 경로가 vgw-id로 지정되어 있는데, vgw-id는 VPN 연결을 사용했을 때 붙일 수 있는 게이트웨이다.
서브넷3은 해당 VPC로 가는 트래픽을 제외하면 나머지는 VPN을 통해 회사로 흘러 가기 때문에 인터넷이 가능한지 결과를 알 수가 없다.
만약 회사 VPN 장비에 VPN을 통해 들어온 트래픽이 인터넷이 가능하게 연결되어 있다면 인터넷이 가능할 수도 있다.
AWS 관리형 VPN
AWS에서 회사와 VPN 연결을 생성하려면 회사에 AWS에서 제공하는 VPN과 연결 할 수 있는 장비나 서버가 필요하다. 장비가 있다면...
1. VGW(Virtual Private Gatway)를 생성하고,
2. Customer Gateway를 생성한 뒤,
3. VPN Connection으로 이 둘을 연결해서,
4. 나온 데이터를 회사의 VPN 장비에 설정하면 연결이 맺어진다.
이렇게 연결을 맺은 뒤 해당 서브넷에 필요한 라우팅을 vgw-id로 추가해 주면 된다.
이 역시 일반 네트워크에서 사용하는 IP가 아니라 aws의 자원id이다.
VPC deep-dive
VPC에 대해 좀 더 깊게 들어가보면 정말 머리가 아파오는데, 좀 필요한 몇몇 내용을 설명해 보자면 라우터, 인터넷 연결 동작 정도가 있고, IPv6는 이 글을 쓰게 된 계기라 그정도만 보겠다.
VPC 라우터
위 서브넷의 차이는 라우터에 있는데, 라우터를 직접 설정을 하거나 볼 수는 없고, VPC 생성시 같이 생성된다. 라우팅 테이블만 변경 할 수 있다.
라우터를 설명하는 이유는 위의 Default Routing을 보면 대상이 igw-id이다.
서브넷을 만들면 라우터에 연결되며, VPC 내에 있는 서브넷들은 라우터를 통해 연결되고, 라우터를 통해서만 인턴세 게이트웨이로 갈 수 있다.
인터넷 연결
이를 좀 더 쉽게 설명한 자료를 찾아보면 VPC with Public and Private Subnets (NAT)를 찾을 수 있는데, 그나마 좀 이해하기 쉽다.
퍼블릭 서브넷 -> 라우터 -> IGW -> 인터넷
프라이빗 서브넷 -> 라우터 -> 퍼블릭 서브넷의 NAT Gateway -> 라우터 -> IGW -> 인터넷
이러한 형태로 나가게 된다.
아마존에서 사용하는 퍼블릭IP에 대해 조금만 더 알아보면 인터넷 게이트웨이의 문서를 찾아보면 퍼블릭IP는 인터넷 게이트웨이에 설정되고, 인스턴스에 직접 퍼블릭 IP를 할당하는게 아닌 Internet Gateway에서 1:1 NAT를 해주고 있는 것을 짐작할 수 있다.
중간에 그려진 라우터는 리소스에서는 찾아볼 수 없고, VPC가 생성되면 하나의 라우터를 가지고 있다고 생각하면 되고, 서브넷에 라우팅 테이블이 정의되고 수정이 가능한데, 이러한 라우팅 정보를 조정할 수 있다.
(라우팅 테이블도 자원으로 관리되어 하나의 라우팅 테이블을 다수의 서브넷에 붙일 수도 있다.)
IPv6
원래의 목적이었던 IPv6를 알아보면 IPv6는 기본적으로 할당되지 않는 것으로 보면 된다.
기본 VPC에는 IPv6 서브넷이 존재하지 않지만, IPv6 CIDR Block을 할당하면 된다. 하지만 이는 AWS CLI나 SDK로 제공된다.
VPC를 새로 생성하면 IPv6 Cidr block을 설정할 수 있게 된다.
VPC 대시보드에서의 VPC 생성
여기서 주의할점은 VPC 대시보드와 VPCs에서 생성하는 것이 같아 보이지만 다르다.
아무튼 VPC 대시보드에서 VPC 생성를 누르면 일부 템플릿에서 세트에서 선택이 가능하고 CIDR을 할당하지 않거나 사용자 지정 IPv6 CIDR 블록 설정이 가능하다. 앞의 cidr 블럭이 xxxx인 이유는 aws에서 가진 IPv6 서브넷을 할당하게 된다.
마무리
원래 글의 목적인 IPv6로 마무리를 하자면 IPv6가 내부까지 들어오는 것보다 좀 더 의미 있는 아키텍처는 내부는 프라이빗 IPv4로 구성하고, 외부 서비스를 로드밸런서로 연결해서 IPv6(Dualstack)를 로드 밸런서 까지만 연결하는 구성이 가장 좋을 것 같다.
