[AWS] VPC 생성
AWS 서비스를 사용하기 위해서는 VPC 구성이 선행되어야 한다. 우리 프로젝트에서는 다음과 같은 구조로 VPC를 구성하고자 한다.
고가용성을 위해 3개의 가용 영역에 걸쳐 VPC를 생성하고 각각의 AZ에 public과 private 서브넷을 하나씩 만들었다.
VPC 생성 과정에 필요한 옵션과 개념을 하나씩 살펴보자.
VPC 생성 리소스 옵션
-
VPC만(VPC only) : VPC라는 껍데기만 만들어지는 옵션으로, 이후에 서브넷, 인터넷 게이트웨이, 라우팅 테이블 등 VPC가 실제로 동작하기 위해 필요한 모든 구성 요소를 하나하나 만들어야 한다.
-
VPC 등(VPC and more) : VPC를 만들고, 그 안에 퍼블릭/프라이빗 서브넷, 인터넷 게이트웨이, NAT 게이트웨이, 라우팅 테이블까지 모두 자동으로 만들어서 올바르게 연결하는 VPC 생성 마법사
Subnets
public과 private으로 나눈 이유는 보안 때문인데,
-
Public Subnet은 인터넷과 직접 통신이 가능한 대역으로 NAT 게이트웨이나 관리자 접속을 위한 Bastion Host 등 인터넷 통신이 필요한 최소한의 자원을 배치하는 공간
-
Private Subnet은 인터넷에서 직접 접근할 수 없는 대역으로 MSK, EKS, Redis, RDS 등 외부로부터 보호되어야 할 모든 핵심 서비스들을 배치하는 공간
Routing Tables
라우팅 테이블은 각각의 서브넷 안의 인스턴스가 통신하기 위한 길을 안내하는 내비게이션 역할을 한다.
위처럼 VPC를 구성하면 총 5개의 라우팅 테이블이 생성되는데 각각은 다음과 같은 역할을 한다.
1. 기본 라우팅 테이블 (rtb-0d1eab796fdd3d7f9)
어떤 서브넷이든 특정 라우팅 테이블과 명시적으로 연결되지 않았을 때 사용하는 라우팅 테이블 (VPC 생성 마법사를 통해 서브넷을 생성한 경우에는 보통 별도의 라우팅 테이블이 만들어지고 그곳에 연결됨)
2. Public 라우팅 테이블 (fms-pipeline-cym-rtb-public)
public 서브넷들의 인터넷 경로를 제어하는 라우팅 테이블로 public 서브넷들이 인터넷 게이트웨이(IGW)로 나가는 경로를 정의한다.
3. Private 라우팅 테이블
private 서브넷들의 경로를 제어하는 라우팅 테이블로 NAT 게이트웨이와 S3 엔드포인트로 나가는 경로를 정의한다.
Network Connections
NAT 게이트웨이 : 1개의 AZ에서
NAT 게이트웨이는 Private Subnet에 있는 서비스들이 외부 인터넷으로 나갈 때(예: 소프트웨어 패키지 다운로드) 사용되는 관문으로, 하나의 AZ에만 배치하거나, VPC를 구성하는 모든 가용 영역에 하나씩 배치할 수 있다.
- '1개의 AZ에서' 선택 시
- 👍장점 : NAT 게이트웨이는 시간당 요금과 데이터 처리 요금이 발생하는데, 1개만 생성하므로 비용이 절약됩니다.
- 👎단점 : 해당 NAT 게이트웨이가 위치한 1개의 가용 영역(AZ)에 장애가 발생하면, 모든 Private Subnet에서 일시적으로 인터넷 접속이 불가능해집니다. (고가용성 ⬇️)
반대로 AZ당 1개를 선택할 경우 비용이 많이 들지만 가용성을 높일 수 있다.
⇒ 프로젝트 초기 및 개발 단계에서는 '1개의 AZ에서'를 선택하는 것이 비용 효율적인 좋은 선택
VPC 엔드포인트 : S3 게이트웨이
S3 게이트웨이는 VPC 내부의 서비스가 S3와 통신할 때 공용 인터넷을 거치지 않고 AWS 내부의 Private 네트워크를 통해 직접 연결되도록 하는 통로로, 활성화 시 다음과 같은 장점을 가진다.
- 보안 강화: 데이터가 AWS 네트워크를 벗어나지 않아 안전
- 성능 향상: 인터넷을 경유하는 것보다 더 안정적이고 빠른 속도를 기대할 수 있다.
- 비용 절감: VPC 엔드포인트를 통한 S3 데이터 전송은 데이터 전송 요금이 부과되지 않는다. (NAT 게이트웨이를 통하면 요금 발생)
⇒ S3 게이트웨이를 활성화하는 것은 보안과 성능을 위한 좋은 선택
라우팅 테이블 규칙
실제로 public, private 라우팅 테이블은 각각 다음과 같은 규칙으로 구성된다.
Public RTB
해당 라우팅 테이블의 규칙들은 명시적으로 연결된 3개의 서브넷 안에 있는 모든 자원에 동일하게 적용된다.
✨ 라우팅 테이블은 항상 더 구체적인 규칙(숫자가 더 큰 CIDR)부터 확인한다!
규칙 1 : 10.0.0.0/16 -> local
-
대상 (Destination):
10.0.0.0/16
생성한 VPC의 전체 IP 주소 범위 (VPC 내부의 모든 IP 주소) -
타겟 (Target):
local
데이터를 VPC 외부로 보내지 말고 "VPC 내부망 안에서 해결하라" 는 의미
⇒ "만약 데이터의 목적지가 우리 VPC 내부(10.0.x.x)라면, 굳이 밖으로 나가지 말고 내부적으로 전달해라."
이 규칙 덕분에 Public Subnet과 Private Subnet에 있는 서비스들이 서로 통신할 수 있다.
규칙 2 : 0.0.0.0/0 → igw-0b502...
-
대상 (Destination):
0.0.0.0/0
1번 규칙(10.0.0.0/16)의 대상에 해당하지 않는 "모든 외부 IP 주소"
즉, 인터넷을 의미하는 특수한 주소 -
타겟 (Target):
igw-0b502...
igw(인터넷 게이트웨이)는 VPC가 외부 인터넷과 통신할 수 있는 유일한 출입문
⇒ "만약 데이터의 목적지가 VPC 외부(인터넷)라면, 인터넷 게이트웨이로 보내라."
이 규칙이 있기 때문에 Public Subnet에 있는 자원들이 인터넷과 직접 통신할 수 있다.
Private RTB
규칙1 : pl-61a54008 → vpce-06466d...
- 대상 (Destination):
pl-61a54008
pl-61a54008은 AWS가 직접 관리하고 최신으로 유지해주는 도쿄 리전의 Amazon S3 서비스가 사용하는 모든 공식 IP 주소 목록 (즉, 도쿄 리전의 Amazon S3 서비스)
- 타겟 (Target):
vpce-06466d97604d4f34d
VPC를 생성할 때 옵션으로 선택했던 S3 게이트웨이 엔드포인트의 실제 ID
이 엔드포인트는 VPC와 S3 서비스를 Public 인터넷을 통하지 않고 AWS 내부의 Private 네트워크로 안전하게 연결해주는 '비밀 통로' 역할을 한다.
⇒ "S3로 가는 모든 트래픽은 인터넷(NAT 게이트웨이)을 거치지 말고, VPC 내부에 만들어진 S3 전용 비밀 통로로 보내라"
이 규칙 덕분에 보안 강화, 비용 절감, 성능 향상의 이점을 얻을 수 있다.
pl: 접두사 목록(Prefix List)의 약자로, pl이 붙으면 단일 IP 주소가 아닌 수십-수백 개의 IP 주소 범위들을 모아놓은 목록 또는 그룹을 의미한다.vpce: VPC Endpoint의 약자
규칙2 : 10.0.0.0/16 -> local
규칙3 : 0.0.0.0/0 → nat-0fb978...
-
대상 (Destination): 0.0.0.0/0
1번 규칙의 대상에 해당하지 않는 "모든 외부 IP 주소" -
타겟(Target) :
nat-0fb978...
VPC를 생성할 때 옵션으로 생성한 NAT 게이트웨이의 실제 ID
이 엔드포인트는 Private Subnet에 속하는 서비스들이 외부와 통신하기 위해 공인 IP 주소로 변환되기 위해 거쳐야하는 NAT 게이트웨이를 의미한다.
DNS 옵션
-
DNS 확인(Resolution) 활성화: VPC 내부에서 도메인 이름을 IP 주소로 변환하는 기능을 활성화한다. 이것이 꺼져 있으면 VPC 내의 모든 서비스가 사실상 인터넷을 포함한 어떤 도메인 주소로도 통신할 수 없게 되므로 필수적인 옵션
-
DNS 호스트 이름(Hostnames) 활성화: VPC 내에 생성되는 EC2 인스턴스 등에 ip-10-0-1-123.ap-northeast-2.compute.internal과 같은 DNS 호스트 이름을 자동으로 할당해주는 기능
특히 MSK, RDS, ElastiCache와 같은 AWS의 많은 관리형 서비스들은 IP 주소뿐만 아니라 이 DNS 호스트 이름을 기반으로 동작하기 때문에 이 옵션을 켜지 않으면 나중에 MSK 클러스터에 접속하는 등 여러 작업에서 문제가 발생할 수 있다.
