VPC 연결과 하이브리드

VPC 피어링 — 두 VPC를 일대일로 잇는다

VPC 피어링 연결은 두 VPC 사이의 네트워킹 연결이며, 연결된 VPC의 리소스는 같은 네트워크 안에 있는 것처럼 통신합니다. VPC 사용 설명서는 두 가지를 명시합니다 — "피어링된 VPC 사이의 트래픽은 퍼블릭 인터넷을 절대 거치지 않는다"는 것과, 피어링이 게이트웨이나 VPN 연결이 아니라 기존 VPC 인프라를 사용하므로 "통신의 단일 장애점이나 대역폭 병목이 없다"는 것입니다.

연결 대상은 내 VPC끼리, 다른 계정의 VPC와, 다른 리전의 VPC와 모두 가능합니다. 요청자 VPC 소유자가 요청을 보내고 수락자 VPC 소유자가 수락해야 활성화되며, 요청은 7일 뒤 만료됩니다.

전이 라우팅이 되지 않는다

이것이 피어링의 결정적 제약입니다. VPC 피어링 안내서의 서술을 그대로 옮기면 "VPC 피어링 연결은 두 VPC 사이의 일대일 관계"이고 "전이적 피어링 관계는 지원되지 않는다", 그리고 "직접 피어링되지 않은 VPC와는 어떤 피어링 관계도 갖지 않는다"입니다.

구체적인 예도 문서가 들어 줍니다 — VPC A와 VPC B가 피어링되어 있고 VPC A와 VPC C도 피어링되어 있어도, VPC B에서 VPC A를 거쳐 VPC C로 트래픽을 보낼 수 없습니다. VPC B와 VPC C를 통신시키려면 그 둘 사이에 별도의 피어링 연결을 만들어야 합니다.

결과적으로 VPC가 N개일 때 모두를 잇는 데 필요한 연결은 N(N-1)/2개가 됩니다. 4개면 6개, 10개면 45개입니다. 연결마다 양쪽 라우팅 테이블에 경로를 넣어야 하므로 관리 대상은 그보다 더 빠르게 늘어납니다.

엣지 투 엣지 라우팅도 되지 않는다

전이성 제약은 게이트웨이에도 그대로 적용됩니다. VPC 피어링 안내서가 나열하는 항목은 다음과 같습니다.

"공용 서비스 VPC에 NAT 게이트웨이 하나를 두고 다른 VPC들이 피어링으로 공유한다"는 설계는 성립하지 않습니다. 이 요구를 실제로 푸는 것이 Transit Gateway입니다.

그 밖의 제약

• CIDR이 겹치면 피어링을 만들 수 없습니다. IPv4든 IPv6든 일치하거나 겹치면 안 되고, CIDR 블록이 여러 개일 때 그중 하나라도 겹치면 겹치지 않는 블록만 쓸 생각이어도 만들 수 없습니다.
• 두 VPC 사이에 동시에 두 개 이상의 피어링 연결을 둘 수 없습니다.
• 피어 VPC의 Amazon DNS 서버에 질의할 수 없습니다.
• 리전 간 피어링에서는 피어 VPC의 보안 그룹을 참조하는 규칙을 만들 수 없고, MTU가 1,500바이트로 제한되어 점보 프레임을 쓸 수 없습니다. 같은 리전 안의 피어링은 점보 프레임을 지원합니다.

AWS Transit Gateway — 허브로 바꾼다

Transit Gateway는 VPC와 온프레미스 네트워크를 상호 연결하는 허브입니다. 각 네트워크는 Transit Gateway에 연결(attachment)을 하나씩 만들고, Transit Gateway가 그 사이의 라우팅을 담당합니다. 연결이 N개면 관리 대상도 N개입니다 — 피어링의 N(N-1)/2와 대비되는 지점이 여기입니다.

연결 유형

VPC, Site-to-Site VPN, Direct Connect 게이트웨이, 다른 Transit Gateway와의 피어링, 그리고 Connect 연결을 붙일 수 있습니다. VPN을 붙이려면 고객 게이트웨이를 만들고 VPN 연결을 만들 때 Transit Gateway를 지정합니다.

라우팅 테이블 — 연결과 전파

Transit Gateway를 만들면 기본 라우팅 테이블이 함께 만들어지고, 그것이 기본 연결(association) 라우팅 테이블이자 기본 전파(propagation) 라우팅 테이블이 됩니다. 두 용어의 의미가 다릅니다.

라우팅 테이블을 여러 개 만들면 네트워크를 분리(세그먼트)할 수 있습니다. 개발 VPC들을 한 라우팅 테이블에, 운영 VPC들을 다른 라우팅 테이블에 연결하면 같은 Transit Gateway를 쓰면서도 두 환경이 서로 도달하지 못하게 만들 수 있습니다. 피어링으로는 이런 정책 계층을 만들 수 없습니다.

Transit Gateway끼리도 피어링할 수 있고, 이때는 정적 경로만 지원됩니다. 리전을 넘는 대규모 구성에서 쓰입니다.

무엇을 고를 것인가

VPC 엔드포인트 — 게이트웨이와 인터페이스 SAA 빈출

VPC 엔드포인트는 VPC와 AWS 서비스 사이에 프라이빗 연결을 만드는 장치입니다. Amazon S3나 Amazon DynamoDB 같은 서비스는 VPC 밖에 있으므로 기본 경로로는 인터넷 게이트웨이나 NAT 게이트웨이를 거쳐야 하는데, 엔드포인트를 만들면 그 경로를 쓰지 않고 AWS 네트워크 안에서 처리됩니다.

유형은 두 가지이고, 구현 위치가 근본적으로 다릅니다.

게이트웨이 엔드포인트 — 라우팅 테이블에 붙는다

게이트웨이 엔드포인트는 Amazon S3와 Amazon DynamoDB만 지원합니다. VPC 엔드포인트를 만들 때 라우팅 테이블 ID를 지정하면, 선택한 각 라우팅 테이블에 AWS가 소유한 서비스 접두사 목록(prefix list)을 대상으로, 게이트웨이 엔드포인트를 타깃으로 하는 경로가 자동으로 추가됩니다. 하나의 라우팅 테이블에 S3용 경로와 DynamoDB용 경로를 함께 둘 수 있습니다.

AWS PrivateLink 문서는 게이트웨이 엔드포인트에 추가 요금이 없다고 명시합니다 — 시간당 요금도 데이터 처리 요금도 붙지 않습니다. 그리고 게이트웨이 엔드포인트는 AWS PrivateLink를 사용하지 않습니다. PrivateLink는 인터페이스 엔드포인트 쪽의 기술입니다.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.ap-northeast-2.s3 \
  --route-table-ids rtb-0aaaaaaaaaaaaaaa1 rtb-0bbbbbbbbbbbbbbb2

인터페이스 엔드포인트 — 서브넷 안에 ENI를 만든다

인터페이스 엔드포인트는 AWS PrivateLink로 동작합니다. 지정한 서브넷마다 엔드포인트 네트워크 인터페이스가 만들어지고 그 서브넷의 주소 범위에서 프라이빗 IP 주소를 받습니다. 이 네트워크 인터페이스는 요청자 관리형이어서 계정에서 볼 수는 있지만 직접 관리하지는 않습니다.

여기서 게이트웨이 엔드포인트와 갈리는 두 가지가 나옵니다.

• 보안 그룹을 붙일 수 있습니다. 엔드포인트 네트워크 인터페이스에 보안 그룹을 연결하며, 지정하지 않으면 VPC의 기본 보안 그룹이 붙습니다. 엔드포인트가 VPC 안의 실제 네트워크 인터페이스이기 때문에 가능한 일입니다.
• 프라이빗 DNS로 이름을 가로챌 수 있습니다. 프라이빗 DNS 이름을 켜면 프라이빗 호스팅 영역이 만들어지고, 그 서비스의 기본 퍼블릭 DNS 이름이 엔드포인트 네트워크 인터페이스의 프라이빗 IP로 해석됩니다. 애플리케이션 코드나 SDK 설정을 바꾸지 않아도 경로가 바뀌는 이유가 이것입니다. 다만 VPC의 DNS 호스트 이름과 DNS 확인이 모두 켜져 있어야 하고, 만들어지는 DNS 레코드는 프라이빗이라 외부에서는 해석되지 않습니다.

인터페이스 엔드포인트는 대부분의 AWS 서비스를 지원하고, 다른 계정이 제공하는 서비스에도 연결할 수 있습니다. 서비스 제공자는 Network Load Balancer 앞에 엔드포인트 서비스를 만들고 소비자가 인터페이스 엔드포인트로 접속하는 구조입니다. Gateway Load Balancer 앞에 만들면 소비자는 Gateway Load Balancer 엔드포인트로 접속합니다.

두 유형 비교

엔드포인트 정책

두 유형 모두 엔드포인트 정책을 붙일 수 있습니다. 이것은 리소스 기반 정책이며, 지정하지 않으면 서비스에 대한 전체 접근을 허용하는 기본 정책이 붙습니다. "엔드포인트를 만들었으니 안전하다"가 성립하지 않는 이유가 여기 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyApprovedBuckets",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::example-app-reports/*",
        "arn:aws:s3:::example-app-artifacts/*"
      ]
    }
  ]
}

반대 방향도 있습니다. 버킷 정책에서 aws:SourceVpce 조건 키로 특정 엔드포인트를 통한 요청만 허용하면, 같은 버킷에 인터넷 경로로 들어오는 요청을 차단할 수 있습니다. 데이터 유출 통제(data perimeter)를 세울 때 쓰는 조합입니다.

"데이터가 인터넷을 거치면 안 된다" SAA 빈출

이 한정어는 SAA에서 정답을 결정하는 대표적인 신호입니다. 프라이빗 서브넷의 인스턴스가 Amazon S3에 접근한다고 할 때 후보 경로는 셋인데, 조건을 만족하는 것과 만족하지 않는 것이 갈립니다.

둘 다 조건을 만족한다면 무엇으로 가를까요. 추가 조건을 보고 고릅니다.

• 대상이 S3나 DynamoDB뿐이고 VPC 안에서만 접근한다면 게이트웨이 엔드포인트가 단순하고 추가 요금이 없습니다.
• 온프레미스나 다른 VPC에서도 그 서비스에 프라이빗하게 닿아야 한다면 인터페이스 엔드포인트입니다. 게이트웨이 엔드포인트는 VPC 라우팅 테이블에만 붙으므로 VPC 밖에서는 쓸 수 없습니다.
• 대상이 S3와 DynamoDB가 아닌 다른 AWS 서비스라면 선택지는 인터페이스 엔드포인트뿐입니다.

NAT 게이트웨이 비용을 엔드포인트로 줄인다

같은 변경이 비용 문항에서도 정답이 됩니다. VPC 사용 설명서의 요금 페이지는 NAT 게이트웨이에 대해 프로비저닝되어 사용 가능한 시간마다 요금이 부과되고, 트래픽의 출발지나 목적지와 무관하게 게이트웨이를 통과한 데이터 양에 따라 데이터 처리 요금이 부과된다고 설명합니다.

그런데 프라이빗 서브넷의 워크로드가 만드는 아웃바운드 트래픽 중 상당 부분은 인터넷이 아니라 Amazon S3나 DynamoDB로 갑니다 — 로그 업로드, 아티팩트 내려받기, 백업이 전부 그렇습니다. 이 트래픽을 게이트웨이 엔드포인트로 옮기면 NAT 게이트웨이를 통과하는 데이터 자체가 사라지고, 게이트웨이 엔드포인트에는 추가 요금이 붙지 않습니다.

aws ec2 modify-vpc-endpoint \
  --vpc-endpoint-id vpce-0123456789abcdef0 \
  --add-route-table-ids rtb-0aaaaaaaaaaaaaaa1 rtb-0bbbbbbbbbbbbbbb2

온프레미스와 잇기 — VPN과 Direct Connect

Site-to-Site VPN — 인터넷 위의 암호화 터널

Site-to-Site VPN은 온프레미스 네트워크와 VPC를 IPsec 터널로 잇습니다. 구성 요소는 세 가지입니다.

가상 프라이빗 게이트웨이 대신 Transit Gateway에 붙일 수도 있습니다. VPC가 여러 개인 환경에서는 이쪽이 표준입니다 — VPC마다 VPN을 따로 만들지 않아도 되기 때문입니다.

라우팅은 두 가지 중에서 고릅니다. 고객 게이트웨이 장비가 BGP를 지원하면 동적 라우팅을 쓰고, 지원하지 않으면 정적 라우팅을 쓰면서 우리 네트워크의 IP 접두사를 직접 입력합니다. AWS 문서는 BGP가 견고한 활성 상태 감지를 제공하므로 첫 터널이 끊겼을 때 두 번째 터널로의 장애 조치를 돕는다고 설명합니다 — 동적 라우팅을 권하는 근거가 이것입니다.

AWS Direct Connect — 전용 회선

Direct Connect는 온프레미스와 AWS를 전용 네트워크 연결로 잇습니다. 인터넷을 거치지 않으므로 대역폭이 일정하고 지연이 예측 가능합니다. 회선 위에는 가상 인터페이스(virtual interface, VIF)를 만들어 씁니다.

Direct Connect 게이트웨이는 전역 리소스이며, 여러 리전이나 여러 계정의 VPC 또는 Transit Gateway에 하나의 연결로 도달할 수 있게 해 줍니다. "리전마다 회선을 따로 끌어야 하는가"라는 질문의 답이 여기 있습니다.

무엇을 고를 것인가

둘은 배타적이지 않습니다. Direct Connect를 주 경로로 두고 Site-to-Site VPN을 백업으로 두는 조합이 표준 구성입니다 — 회선 장애가 났을 때 즉시 인터넷 경로로 넘어갈 수 있기 때문입니다. 문제문에 "Direct Connect 장애에 대비"가 보이면 이 조합이 답입니다.

AWS Outposts — AWS를 데이터센터 안으로

AWS Outposts는 AWS가 관리하는 인프라를 고객의 시설에 설치해 같은 API와 도구로 운영할 수 있게 합니다. 폼 팩터는 두 가지입니다 — 서버와 스위치, 전원 선반을 포함한 랙(rack) 형태와, 표준 랙에 장착하는 서버(server) 형태입니다. 공간이나 용량 요구가 작은 현장에는 서버 형태를 씁니다.

Outposts는 항상 홈 리전(부모 리전)에 연결됩니다. 그 연결을 서비스 링크라고 하며, Outpost가 홈 리전과 통신할 때 사용하는 암호화된 VPN 연결의 집합입니다. 온프레미스 네트워크와의 통신은 랙 형태에서 제공되는 로컬 게이트웨이(local gateway)가 담당합니다.

고르는 기준은 단순합니다. "온프레미스에 남아야 하는 요구(지연, 데이터 레지던시, 로컬 시스템 의존)가 있는데 AWS API와 운영 방식은 그대로 쓰고 싶다"면 Outposts입니다. 단지 온프레미스와 연결만 하면 되는 경우에는 Direct Connect나 VPN이 맞고, Outposts는 과합니다.

같은 계열의 선택지로 특정 대도시권의 지연을 줄이는 AWS Local Zones와 통신 사업자 네트워크 안의 AWS Wavelength가 있습니다. 셋의 구분은 1장 로컬 존과 Wavelength 존에 정리해 두었습니다.

흔한 오해

시험 포인트 정리

이 장은 보안 아키텍처 설계(30%)와 비용 최적화 아키텍처 설계(20%)에 함께 걸치며, 하이브리드 연결은 고성능 아키텍처 설계(24%)의 과제 진술 3.4에도 등장합니다.

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 이 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 3장 · VPC 네트워킹 기초 라우팅 테이블과 NAT 게이트웨이의 기본 동작을 다시 확인합니다. 이 장의 엔드포인트 판단이 그 위에 얹힙니다. 기본개념 · SAA 최우선
• 2장 · IAM과 자격 증명 엔드포인트 정책과 버킷 정책은 모두 리소스 기반 정책입니다. 결합 규칙을 알아야 경로 통제가 완성됩니다. 기본개념 · SAA 최우선
• 실습 10 · VPC 엔드포인트로 S3 비공개 접근 게이트웨이 엔드포인트와 인터페이스 엔드포인트를 직접 만들어 경로가 어떻게 바뀌는지 확인합니다. 실습 예제
• 케이스 6 · 데이터 전송 요금이 예산을 넘겼다 NAT 게이트웨이와 리전 간 전송이 만드는 비용 구조를 뜯어보고 엔드포인트로 되돌리는 순서를 따라갑니다. 아키텍처 케이스
• 네트워크 빠른참조 VPC 연결 옵션 매트릭스를 한 화면에 모았습니다. 피어링·Transit Gateway·엔드포인트·VPN·Direct Connect를 나란히 비교합니다. 빠른참조
• 한정어 키워드 사전 "must not traverse the internet"를 포함해 정답을 결정하는 한정어와 그것이 가리키는 서비스를 정리했습니다. 시험 대비 · 최우선

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

• Amazon VPC 사용 설명서 — VPC 피어링으로 VPC 연결 — 피어링 트래픽이 퍼블릭 인터넷을 거치지 않는다는 서술, 게이트웨이나 VPN이 아니어서 단일 장애점과 대역폭 병목이 없다는 서술
• Amazon VPC 피어링 안내서 — 피어링 기본 — 일대일 관계이며 전이적 피어링을 지원하지 않는다는 서술, 엣지 투 엣지 라우팅 제약 목록(인터넷 게이트웨이·NAT 장치·VPN·Direct Connect·게이트웨이 엔드포인트), CIDR이 겹치면 만들 수 없다는 제약, 리전 간 피어링의 보안 그룹 참조 불가와 MTU 1,500바이트
• Amazon EC2 API 레퍼런스 — CreateVpcPeeringConnection — 수락자 VPC가 다른 계정·다른 리전에 있을 수 있다는 점, CIDR이 겹치면 상태가 실패가 된다는 점, 요청이 7일 뒤 만료된다는 점
• AWS Transit Gateway — 동작 방식 — 연결 유형과 허브 앤 스포크 라우팅 구조
• AWS Transit Gateway — 라우팅 테이블 — 연결과 전파의 구분, 라우팅 테이블을 여러 개 만들어 네트워크를 분리하는 방법, 피어링 연결이 정적 경로만 지원한다는 점
• Amazon EC2 API 레퍼런스 — CreateTransitGateway — 기본 라우팅 테이블이 기본 연결·전파 라우팅 테이블이 된다는 서술
• AWS PrivateLink — 게이트웨이 엔드포인트 — 게이트웨이 엔드포인트가 Amazon S3와 DynamoDB에 대한 연결을 제공한다는 점, 서비스 접두사 목록을 대상으로 하는 경로가 선택한 라우팅 테이블에 자동 추가된다는 점, 추가 요금이 없다는 점, 게이트웨이 엔드포인트는 AWS PrivateLink를 사용하지 않는다는 점
• AWS PrivateLink — Amazon S3용 게이트웨이 엔드포인트 — S3 게이트웨이 엔드포인트의 구성과 라우팅
• AWS PrivateLink — Amazon DynamoDB용 게이트웨이 엔드포인트 — DynamoDB 게이트웨이 엔드포인트의 구성
• AWS PrivateLink — 인터페이스 VPC 엔드포인트로 AWS 서비스 접근 — 지정한 서브넷마다 엔드포인트 네트워크 인터페이스가 만들어지고 서브넷 주소 범위의 프라이빗 IP를 받는다는 점, 요청자 관리형이라는 점, 보안 그룹을 지정하지 않으면 VPC 기본 보안 그룹이 붙는다는 점, 프라이빗 DNS 이름을 쓰려면 VPC의 DNS 호스트 이름과 DNS 확인을 켜야 한다는 점
• AWS PrivateLink — 인터페이스 엔드포인트 구성 — 프라이빗 DNS 이름이 퍼블릭 서비스 엔드포인트로 향하는 요청을 VPC 엔드포인트로 해석시킨다는 서술
• Amazon VPC 사용 설명서 — AWS 관리형 접두사 목록 — 게이트웨이 엔드포인트 경로의 대상이 되는 AWS 소유 접두사 목록
• Amazon EC2 API 레퍼런스 — CreateVpcEndpoint — 엔드포인트 유형의 기본값이 Gateway라는 점, 게이트웨이 엔드포인트는 라우팅 테이블 ID를, 인터페이스 엔드포인트는 서브넷 ID와 보안 그룹을 받는다는 점, 정책을 지정하지 않으면 전체 접근을 허용하는 기본 정책이 붙는다는 점, 프라이빗 DNS가 프라이빗 호스팅 영역을 만든다는 점
• Amazon EC2 API 레퍼런스 — CreateVpcEndpointServiceConfiguration — 엔드포인트 서비스를 Network Load Balancer 또는 Gateway Load Balancer 앞에 만든다는 점
• Amazon VPC 사용 설명서 — NAT 게이트웨이 요금 — 프로비저닝된 시간마다, 그리고 트래픽의 출발지·목적지와 무관하게 통과한 데이터 양에 따라 요금이 부과된다는 서술
• AWS Site-to-Site VPN 사용 설명서 — 개요 — 각 VPN 연결이 터널 두 개를 포함하며 동시에 사용해 가용성을 높일 수 있다는 점, 고객 게이트웨이와 가상 프라이빗 게이트웨이의 역할
• AWS Site-to-Site VPN 사용 설명서 — 정적 라우팅과 동적 라우팅 — BGP 지원 여부로 동적과 정적을 고른다는 점, BGP의 활성 상태 감지가 두 번째 터널로의 장애 조치를 돕는다는 점
• Amazon EC2 API 레퍼런스 — CreateCustomerGateway — 고객 게이트웨이 장비의 외부 인터페이스에 고정 IP가 필요하다는 점과 BGP ASN
• AWS Direct Connect 사용 설명서 — 가상 인터페이스 — 프라이빗 VIF는 프라이빗 IP로 VPC에, 퍼블릭 VIF는 퍼블릭 IP로 AWS 퍼블릭 서비스에, 전송 VIF는 Direct Connect 게이트웨이에 연결된 Transit Gateway에 접근한다는 서술
• AWS Direct Connect 사용 설명서 — MACsec — 전용 연결에서의 MAC 보안 암호화 옵션
• Amazon VPC 연결 옵션 백서 — AWS Direct Connect — Direct Connect가 기본적으로 암호화되지 않는다는 점, 10/100 Gbps 전용 연결에서는 MACsec을 쓰고 1 Gbps 이하에서는 VPN 터널을 얹는다는 점, Direct Connect 게이트웨이가 여러 리전·계정의 VPC나 Transit Gateway에 도달하는 전역 리소스라는 점
• AWS Outposts 사용 설명서 — Outposts란 — 랙과 서버 두 폼 팩터, AWS 인프라를 고객 시설에서 운영한다는 개념
• AWS Outposts 사용 설명서 — 동작 방식 — 서비스 링크가 홈 리전과의 암호화된 VPN 연결 집합이라는 서술, 로컬 게이트웨이가 온프레미스 네트워크와의 통신을 담당한다는 서술