Amazon SAA-C03: 네트워킹 및 연결성 — 학습 가이드

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

VPC 설계 및 CIDR 계획

모든 VPC는 CIDR 블록으로 시작하며, 생성 시에 내린 결정은 피어링, Transit Gateway 연결, 하이브리드 연결에 연쇄적인 영향을 미칩니다. 기본 CIDR은 /16에서 /28 사이여야 하고, RFC 1918 공간에서 선택해야 하며, 피어링하거나, Transit Gateway를 통해 라우팅하거나, Direct Connect 또는 VPN을 통해 연결하려는 어떤 네트워크와도 겹치지 않아야 합니다. CIDR 중복은 하이브리드 설계가 실패하는 가장 흔한 원인입니다. AWS는 주소 공간을 공유하는 두 네트워크 간에 라우팅할 수 없기 때문입니다. Transit Gateway는 연결을 수락하더라도 전파(propagation)가 실패하거나 트래픽을 조용히 블랙홀 처리합니다.

VPC의 주소 공간이 부족해져도 다시 구축할 필요는 없습니다. 최대 4개의 보조 IPv4 CIDR 블록을 연결할 수 있습니다(기본적으로 총 5개까지 더 넓은 풀에서 추가 범위를 연결할 수 있으며, 할당량 증가를 통해 확장 가능). 보조 블록은 동일한 RFC 1918 범위 또는 100.64.0.0/10 공유 주소 공간에서 가져올 수 있으며, 이는 10.0.0.0/8이 모두 소진되었거나 통신사급 NAT(carrier-grade NAT) 공간이 필요할 때 유용합니다. 보조 CIDR을 사용하면 기존 워크로드의 IP를 재할당하지 않고도 EKS 파드 네트워킹이나 새로운 티어(tier)와 같은 확장을 위해 새 서브넷을 구성할 수 있습니다.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

견고한 설계는 미래 성장을 위해 /17 또는 /18을 예약하고, 서브넷 경계를 가용 영역(Availability Zone)에 맞추며(티어당 AZ별 /20이 일반적인 패턴), 인터페이스 엔드포인트, NAT 게이트웨이, 로드 밸런서가 소비하는 ENI를 위한 여유 공간을 남겨둡니다.

VPC는 리전(regional) 단위의 구조이며, 각기 단일 AZ에 속하는 서브넷으로 분할됩니다. ‘퍼블릭’과 ‘프라이빗’의 구분은 순전히 라우팅 결정에 따릅니다. 퍼블릭 서브넷은 Internet Gateway를 가리키는 0.0.0.0/0 → igw-xxxx 라우팅을 가지는 반면, 프라이빗 서브넷은 기본 라우팅이 없거나 0.0.0.0/0을 NAT 디바이스로 지정합니다. 퍼블릭 서브넷의 인스턴스는 인바운드 연결을 위해 퍼블릭 IP 또는 Elastic IP도 필요합니다. IGW는 프라이빗 IP와 퍼블릭 IP 간에 1:1 NAT를 수행합니다.

NAT 게이트웨이, NAT 인스턴스, IPv6 송신

프라이빗 서브넷에서 아웃바운드 전용 IPv4 인터넷 액세스를 위해서는 NAT 게이트웨이가 올바른 기본 요소입니다. 관리형 NAT 게이트웨이는 자동으로 45–100 Gbps까지 확장되고, 고유한 목적지당 55,000개의 동시 연결을 지원하며, AWS에 의해 패치되고, 해당 AZ 내에서 고가용성을 가집니다. NAT 게이트웨이는 시간당 및 처리된 GB당 요금이 부과됩니다.

NAT 인스턴스—소스/대상 확인(source/destination check)이 비활성화된 자체 관리형 EC2—는 레거시 방식입니다. 단일 인스턴스의 처리량에 의해 제한되고, 장애 조치를 위해 스크립트를 작성해야 하며, 지속적인 부하 상태에서는 병목 현상이 발생합니다. 이는 커스텀 필터링과 같은 비정형적인 요구에만 적합하며, 그런 경우에도 보통 Gateway Load Balancer 어플라이언스가 더 나은 선택입니다.

표준적인 고가용성 패턴은 AZ당 하나의 NAT 게이트웨이를 해당 AZ의 퍼블릭 서브넷에 배치하고, AZ별로 별도의 프라이빗 라우팅 테이블을 두어 기본 라우팅이 로컬 NAT 게이트웨이를 가리키도록 하는 것입니다.

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

여러 AZ에 걸쳐 공유되는 단일 NAT 게이트웨이를 배포하는 것은 두 가지 이유로 함정이 될 수 있습니다. 첫째, 단일 장애 지점(single point of failure)이 됩니다. AZ 하나에 장애가 발생하면 모든 프라이빗 서브넷의 아웃바운드 연결이 중단됩니다. 둘째, 다른 AZ의 인스턴스에서 오는 모든 패킷이 AZ 경계를 넘어가므로, NAT 게이트웨이 처리 비용에 더해 AZ 간 데이터 전송 요금(현재 양방향 각각 $0.01/GB)이 발생합니다. 수백 TB의 아웃바운드 트래픽을 처리하는 워크로드에서는 이 비용이 추가 NAT 게이트웨이 비용을 훨씬 초과합니다. 두 번째로 흔한 잘못된 구성은 NAT 게이트웨이 자체를 프라이빗 서브넷에 배치하는 것입니다. 이 경우 IGW로 가는 경로가 없어 작동하지 않습니다.

IPv6의 경우 모든 IPv6 주소가 전역적으로 라우팅 가능하므로 NAT가 필요하지도 않고 사용할 수도 없습니다. 원치 않는 인바운드 트래픽을 차단하면서 아웃바운드 전용 IPv6를 허용하려면, **송신 전용 인터넷 게이트웨이(egress-only internet gateway)**를 연결하고 프라이빗 서브넷에서 ::/0을 이 게이트웨이로 라우팅하십시오. 일반 IGW는 양방향이므로 인스턴스를 외부에 노출시키게 됩니다.

VPC 엔드포인트: 게이트웨이 vs. 인터페이스

VPC 엔드포인트는 VPC와 AWS 서비스 간의 트래픽을 AWS 백본에 유지하여 인터넷, NAT 게이트웨이, 인터넷 게이트웨이를 완전히 우회합니다. 근본적으로 다른 두 가지 구현 방식이 있으며, 이 둘을 혼동하는 것은 가장 흔한 아키텍처 실수 중 하나입니다.

게이트웨이 엔드포인트는 Amazon S3와 DynamoDB에만 존재합니다. 이는 라우팅 테이블 항목으로, 엔드포인트 자체를 대상으로 하는 접두사 목록(예: us-east-1의 S3에 대한 pl-63a5400a)입니다. ENI, DNS 변경, 시간당 비용, 보안 그룹이 없습니다(액세스는 라우팅 테이블과 엔드포인트 정책으로 제어됩니다). 라우팅 기반이므로 VPC 내부의 리소스에만 작동합니다. Direct Connect를 통해 S3에 연결하는 온프레미스 네트워크는 이를 사용할 수 없습니다.

인터페이스 엔드포인트(AWS PrivateLink)는 서브넷에 배치되는 프라이빗 IP를 가진 ENI이며, AZ별 시간당 요금과 GB당 요금이 부과됩니다. SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS 등 거의 모든 다른 서비스와 엔드포인트 서비스로 게시된 서드파티 서비스에서 작동합니다. 인터페이스 엔드포인트는 프라이빗 DNS를 지원하여, 퍼블릭 서비스 호스트 이름을 엔드포인트의 프라이빗 IP로 확인하도록 재정의하므로 SDK나 CLI의 코드 변경이 필요 없습니다. ENI 기반이므로 보안 그룹이 적용됩니다.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

비용 논리가 중요합니다. 기본적으로 프라이빗 서브넷에서 퍼블릭 AWS 서비스로 나가는 모든 트래픽은 NAT 게이트웨이를 통과하며 GB당 약 $0.045의 비용이 발생합니다. 매일 1TB를 S3로 푸시하는 컨테이너화된 워크로드의 경우, NAT 게이트웨이 경로와 게이트웨이 엔드포인트 간의 차이는 월 수천 달러에 달합니다. 인터페이스 엔드포인트는 대규모 NAT 이그레스를 대체하거나 규정 준수 요건상 인터넷 라우팅이 금지될 때 가치가 있습니다.

함정: 게이트웨이 엔드포인트에 보안 그룹 연결 시도(ENI가 없음), 게이트웨이 엔드포인트가 온프레미스에서 연결 가능하다고 가정(불가능함 - 인터페이스 엔드포인트 또는 EC2 → S3 게이트웨이 엔드포인트 → 별도 DX 경로의 하이브리드 패턴 사용), 인터페이스 엔드포인트에서 프라이빗 DNS를 비활성화하고 수정되지 않은 SDK 호출이 작동할 것으로 예상(인터넷을 통해 퍼블릭 엔드포인트로 연결되어 엔드포인트의 목적을 완전히 무력화시킴), 게이트웨이 엔드포인트를 생성하고 프라이빗 서브넷의 라우팅 테이블 연결을 잊는 경우(트래픽이 조용히 퍼블릭 경로를 계속 사용함), 게이트웨이 엔드포인트가 없는 서비스(예: KMS)에 게이트웨이 엔드포인트를 사용하려는 시도(S3와 DynamoDB만 해당됨).

VPC 간 연결: 피어링 vs. Transit Gateway

VPC 피어링은 동일하거나 다른 계정, 동일하거나 다른 리전의 두 VPC 간의 일대일, 비전이적(non-transitive) Layer 3 연결입니다. 트래픽은 AWS 백본을 통과하며 대역폭 병목 현상이 없고 시간당 요금이 없습니다. 교차 AZ 또는 리전 간 데이터 전송에 대해서만 비용을 지불합니다. 피어링을 제한하는 두 가지 속성이 있습니다: (1) **비전이적(non-transitive)**입니다. 즉, A가 B와 피어링되고 B가 C와 피어링되어도 A는 B를 통해 C에 도달할 수 없습니다. (2) CIDR 범위가 겹치지 않아야 합니다. N개의 VPC를 풀 메시로 연결하려면 각 연결의 양방향에 라우팅 테이블 수정이 필요한 N(N-1)/2개의 피어링이 필요합니다. 30개의 VPC인 경우 435개의 피어링이 됩니다. 피어링이 수백 개의 VPC로 확장될 것으로 기대하는 것은 함정입니다.

**Transit Gateway (TGW)**는 리전별 클라우드 라우터입니다. 각 VPC, VPN 또는 Direct Connect 게이트웨이는 *연결(attachment)*이며, TGW 라우팅 테이블은 어떤 연결이 어떤 접두사에 도달할 수 있는지 제어합니다. 이를 통해 O(n²)의 메시 구조를 O(n)의 연결 구조로 변환하고, 보안 VPC가 모든 VPC 간 트래픽을 검사하는 방화벽을 호스팅하는 허브 앤 스포크 토폴로지를 구현할 수 있습니다. TGW는 전이적 라우팅을 지원하고, VPN 및 Direct Connect 게이트웨이 연결을 기본적으로 종단하며, Resource Access Manager를 통해 AWS Organizations 전체에서 공유될 수 있어 중앙 네트워킹 팀이 라우팅을 제어하고 워크로드 계정은 VPC를 소유할 수 있습니다. TGW는 연결당 시간당 요금과 처리된 데이터 GB당 약 $0.02의 비용이 추가됩니다.

리전 간 연결을 위해서는 TGW 피어링을 사용하여 AWS 글로벌 백본을 통해 다른 리전의 TGW들을 암호화된 트래픽으로 연결합니다. 리전당 하나의 TGW를 메시 또는 허브 디자인으로 피어링합니다. 이는 리전 간 VPC 피어링이 다시 야기하는 리전 간 N-제곱 문제를 방지합니다.

라우팅 테이블 관리는 여기서 가장 간과하기 쉬운 치명적인 문제입니다. 피어링 연결이나 TGW 연결을 생성하는 것만으로는 아무 일도 일어나지 않습니다. 양쪽 VPC의 서브넷 라우팅 테이블에 pcx- 또는 tgw- 대상을 가리키는 명시적인 CIDR 라우팅이 추가되고 보안 그룹이 해당 트래픽을 허용해야 합니다. 소리 없는 연결 실패는 거의 항상 누락된 라우팅이나 잘못된 소스 CIDR을 참조하는 보안 그룹의 암시적 거부(implicit deny)로 귀결됩니다.

하이브리드 연결: Site-to-Site VPN과 Direct Connect 비교

Site-to-Site VPN과 Direct Connect 사이의 선택은 한편으로는 빠른 배포 속도와 내장된 암호화, 다른 한편으로는 일관된 낮은 지연 시간, 전용 대역폭, 예측 가능한 처리량 사이의 트레이드오프입니다.

Site-to-Site VPN은 고객 게이트웨이(온프레미스 라우터)와 Virtual Private Gateway 또는 Transit Gateway 사이에 두 개의 IPsec 터널을 설정합니다. 각 터널의 최대 속도는 약 1.25Gbps입니다. 트래픽은 네트워크 계층에서 암호화되며, TLS와 결합하면 네트워크 및 세션 계층의 암호화 요구 사항을 충족합니다. 공용 인터넷을 통과하므로 지연 시간과 지터가 가변적이지만, 몇 분 안에 사용할 수 있고 시간당 비용이 저렴합니다. 즉각적인 연결이 필요하거나, 대역폭 요구량이 적거나, 백업 경로로 사용할 때 적합합니다.

**Direct Connect (DX)**는 온프레미스 라우터에서 AWS Direct Connect 로케이션까지 전용 광섬유 연결(1, 10 또는 100Gbps)을 제공합니다. 공용 인터넷을 우회하여 일관된 지연 시간과 더 높은 처리량을 제공합니다. DX의 이그레스(egress) 요금은 인터넷 이그레스보다 훨씬 저렴하여, 하루에 수백 기가바이트를 이동할 때 중요합니다. 프로비저닝에는 교차 연결(cross-connect), LOA, BGP 구성 등으로 몇 주가 걸립니다.

여기에는 두 가지 주요 함정이 있습니다. 첫째, Direct Connect만으로는 트래픽이 암호화되지 않습니다. 프라이빗 회선은 암호학적으로 보호된 채널이 아닙니다. DX를 통해 암호화 요구 사항을 충족하려면 그 위에 Site-to-Site VPN을 계층화하거나, 지원되는 전용 포트에서 MACsec을 사용하여 Layer-2 암호화를 사용해야 합니다. 둘째, 순수 DX 연결만으로는 여러 VPC로 라우팅되지 않습니다. 프라이빗 VIF는 단일 VPC에 연결된 단일 Virtual Private Gateway에 연결됩니다. 여러 VPC, 특히 여러 계정과 리전에 걸쳐 연결하려면 transit VIF를 통해 Transit Gateway와 연결된 Direct Connect Gateway를 사용하고, 각 VPC를 TGW에 연결해야 합니다.

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

표준적인 프로덕션 패턴은 두 개의 DX 로케이션에 있는 두 개의 DX 연결을 별도의 고객 라우터에 종단시키고, Site-to-Site VPN을 자동 BGP 장애 조치(failover)로 사용하는 것입니다. BGP AS-path prepending 또는 MED는 DX가 활성 상태일 때 트래픽을 DX로 유도하고, DX에 장애가 발생하면 BGP가 DX 경로를 철회하고 VPN이 인계받습니다.

로드 밸런서: ALB, NLB, GWLB

ALB는 7계층 로드 밸런서로, 호스트 및 경로 기반 라우팅, WebSocket, 리디렉션, 쿠키 기반 고정 세션 등 HTTP 시맨틱을 이해합니다. MQTT, 원시 TCP, UDP를 통한 syslog, SMTP 등 HTTP가 아닌 프로토콜에는 적합하지 않습니다. ALB는 시간이 지남에 따라 변경되는 IP를 사용하는 DNS 기반 주소 지정을 사용하며, Elastic IP를 할당할 수 없습니다. 클라이언트가 대상 IP를 화이트리스트에 등록해야 하는 경우 ALB 단독으로는 부적합합니다. EIP가 있는 NLB를 사용하거나, Global Accelerator의 고정된 애니캐스트 IP 두 개를 ALB 앞에 배치해야 합니다. ‘ALB DNS를 한 번만 확인하고 방화벽 규칙에 IP를 고정하면 된다’는 생각은 함정입니다. AWS는 예고 없이 IP를 변경합니다.

NLB는 4계층 로드 밸런서로, 초당 수백만 개의 플로우로 확장할 수 있습니다. 기본적으로 실제 클라이언트 소스 IP를 보존하며(대상이 실제 클라이언트를 볼 수 있음), AZ당 고정 Elastic IP를 할당할 수 있고, 처리량이 높은 TCP/UDP 워크로드를 처리합니다. 과거에는 NLB 자체에 보안 그룹을 지원하지 않아 클라이언트 CIDR을 대상의 SG에서 직접 허용해야 했습니다. AWS가 2023년에 선택적 NLB 보안 그룹을 추가했지만, 많은 설계에서는 여전히 기존 방식을 가정합니다.

표준적인 외부 공개 패턴은 다음과 같습니다:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

백엔드에서 CIDR 대신 ALB의 보안 그룹을 소스로 참조하는 것이 최소 권한 패턴이며, ALB의 ENI에서 시작되는 상태 확인 트래픽을 자동으로 포함합니다. ALB 자체는 최소 두 개 AZ의 퍼블릭 서브넷(IGW로 라우팅)에 위치하고, 대상은 프라이빗 서브넷에 위치합니다. 인터넷 경계 ALB를 프라이빗 서브넷에 배치하는 것은 전형적인 잘못된 구성입니다. 대상 등록은 성공하지만 클라이언트가 접근할 수 없습니다.

**Gateway Load Balancer (GWLB)**는 타사 가상 어플라이언스(방화벽, IDS/IPS, DPI)를 투명하게 삽입하기 위해 특별히 제작되었습니다. 3계층에서 작동하며, UDP 6081에서 GENEVE 캡슐화를 사용하여 모든 IP 프로토콜을 전달합니다. 트래픽은 **GWLB 엔드포인트(GWLBe)**를 통해 GWLB에 도달합니다. GWLBe는 서브넷에 위치하며 라우팅 테이블에 대상으로 나타나는 인터페이스 엔드포인트입니다.

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

엔드포인트는 PrivateLink를 통해 GWLB로 패킷을 전달하고, GWLB는 플로우 고정성(flow stickiness)을 사용하여 어플라이언스 집합 전체에 로드 밸런싱을 수행하므로 플로우의 양방향 트래픽이 동일한 어플라이언스에 도달합니다. 허브 앤 스포크(hub-and-spoke) 검사 설계에서, 스포크 VPC는 TGW에 연결되며, TGW의 라우팅 테이블은 동서(east-west) 트래픽이 대상 VPC에 도달하기 전에 검사 VPC(GWLB 및 어플라이언스 포함)를 통과하도록 강제합니다. 인그레스(Ingress) 검사는 IGW에서 웹 티어로 가는 트래픽이 먼저 GWLBe를 통과하도록 리디렉션하는 엣지 라우팅 테이블을 사용합니다.

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

이는 중앙 집중식, 교차 계정 검사를 위한 올바른 해답입니다. EC2, 사용자 지정 라우팅 테이블 해킹, 장애 조치 스크립트로 직접 구현하는 것은 GWLB가 기본적으로 제공하는 기능을 재발명하는 것과 같습니다.

소비자-제공자 간 서비스를 위한 PrivateLink

PrivateLink는 AWS 서비스용 인터페이스 엔드포인트를 지원하는 것 외에도, 서드파티나 다른 AWS 계정이 게시한 서비스에 대한 프라이빗 연결을 활성화합니다. 제공자는 서비스를 NLB 뒤에 배치하고 VPC 엔드포인트 서비스를 생성합니다. 소비자는 자신의 VPC에 이를 대상으로 하는 인터페이스 엔드포인트를 생성합니다.

중요한 방향성 규칙: 연결은 항상 소비자에서 제공자 방향으로 시작됩니다. 제공자는 소비자의 VPC로 연결을 시작할 수 없습니다. 트래픽은 인터넷을 거치지 않으며, (피어링처럼 제공자 VPC 전체가 아닌) 특정 대상 서비스에만 도달할 수 있고, 양측에 엔드포인트 IP만 노출되므로 CIDR 중첩 문제가 발생하지 않습니다. 이는 소비자 VPC에 IGW, VPN, Direct Connect가 없는 SaaS나 벤더 데이터베이스 액세스 패턴에 대한 정석적인 해답입니다. VPC 피어링은 전체 CIDR 범위를 노출하고 IP가 중첩되지 않아야 하며, TGW 연결은 광범위하게 라우팅하고, 인터넷을 통한 퍼블릭 API는 프라이빗하지 않습니다.

Global Accelerator와 Route 53

AWS Global Accelerator는 전 세계 AWS 엣지 로케이션에서 광고되는 두 개의 정적 애니캐스트 IPv4 주소를 할당합니다. 클라이언트 트래픽은 가장 가까운 엣지로 진입하여 AWS 백본을 타고 가장 가까운 정상 상태의 리전 엔드포인트(ALB, NLB, EIP 또는 EC2)로 전달됩니다. 이는 두 가지 문제를 한 번에 해결합니다: ALB 앞단의 정적 IP(화이트리스팅 문제 해결), 그리고 공용 인터넷을 단축하여 전 세계에 분산된 사용자의 지터/지연 시간 감소. 이는 CloudFront(콘텐츠 캐싱)가 적용되지 않는 오리진으로의 캐시 불가능한 TCP/UDP 트래픽을 가속화합니다.

Route 53은 다른 문제, 즉 DNS 수준의 트래픽 조향을 해결합니다. Global Accelerator는 데이터 플레인 자체에 영향을 미치지만, Route 53은 DNS 해석에만 영향을 미치며, 그 이후 TCP 연결은 해석된 IP가 있는 곳으로 향합니다. 이 둘은 자주 결합되어 사용됩니다. 예를 들어, Route 53 별칭 레코드가 리전별 ALB 앞에 있는 Global Accelerator를 가리키는 방식입니다.

Route 53 라우팅 정책:

지연 시간 기반과 지리적 위치 기반은 자주 혼동됩니다. 지연 시간 기반은 사용자가 체감하는 RTT를 최소화하고, 지리적 위치 기반은 지연 시간과 관계없이 데이터 상주를 강제합니다. 다중 리전 장애 조치는 기본 리소스에 대한 상태 확인이 필요합니다. 별칭 레코드는 AWS 전용 기능으로, 쿼리 비용 없이 ALB, NLB, CloudFront, S3 웹사이트, API Gateway 엔드포인트로 직접 해석되며, CNAME과 달리 Zone Apex(영역 최상위)에서도 작동합니다.

Route 53 Resolver는 VPC 내부에서 .2 주소(VPC CIDR 기준 + 2)를 통해 DNS 쿼리에 응답합니다. 하이브리드 DNS의 경우, 인바운드 엔드포인트는 온프레미스 리졸버가 AWS의 프라이빗 호스팅 영역을 쿼리할 수 있게 하고, 아웃바운드 엔드포인트와 전달 규칙은 VPC 리소스가 온프레미스 이름을 해석할 수 있게 합니다. 이것들이 없으면 EC2 인스턴스는 corp.internal을 해석할 수 없고 온프레미스 서버는 db.prod.internal을 해석할 수 없습니다. 이는 애플리케이션이 환경 간 조회를 시작할 때만 드러나는 미묘한 장애 지점입니다. 인터페이스 엔드포인트는 SDK 호출이 엔드포인트 ENI로 전달되도록 프라이빗 DNS 활성화가 필요합니다. 이 옵션이 없으면 호출은 여전히 인터넷을 통해 퍼블릭 엔드포인트로 도달하여 목적을 무의미하게 만듭니다.

보안 그룹, NACL, 그리고 최소 권한

보안 그룹은 상태 저장(stateful) 방식이므로 반환 트래픽이 자동으로 허용되며, ENI 수준에서 작동합니다. NACL은 상태 비저장(stateless) 방식이며 서브넷 경계에서 작동합니다. NACL의 모든 TCP 규칙은 명시적인 인바운드 및 아웃바운드 규칙을 필요로 합니다. 클라이언트는 임시 포트 범위에서 소스 포트를 선택하므로, 반환 방향 규칙은 1024–65535 포트를 허용해야 합니다 (Linux는 기본적으로 32768–60999를 사용하며, 더 넓은 범위는 Windows 및 기타 스택을 포함합니다). 이 임시 반환 규칙을 잊는 것은 SYN은 완료되지만 응답에서 멈추는 연결 문제의 전형적인 원인입니다.

계층 간 최소 권한을 위해서는 보안 그룹 규칙이 CIDR이 아닌 다른 보안 그룹 ID를 참조해야 합니다. 이는 Auto Scaling에 따라 확장 가능하며 깨지기 쉬운 IP 화이트리스트를 피할 수 있습니다:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACL은 대략적인 영향 범위를 제어하는 수단이며, 보안 그룹을 대체하지 않습니다. 보안 그룹 변경 없이 “심층 방어"를 위해 NACL을 강화하면, 상태 비저장 반환 트래픽이 조용히 삭제되기 때문에 NAT 게이트웨이를 통한 yum/apt 업데이트와 같은 아웃바운드 시작 흐름이 깨지는 경우가 많습니다. 결론적으로 라우팅 테이블이 도달 가능성을 결정합니다. 즉, 허용 범위가 넓은 보안 그룹이라도 라우팅 테이블에 대상에 대한 항목이 없으면 트래픽을 전달할 수 없으며, 반대로 게이트웨이 엔드포인트는 S3 접두사 목록 라우트가 워크로드가 호스팅된 서브넷의 라우팅 테이블에 실제로 설치되어 있을 때만 효과적입니다.

결정 참고 자료

← 데이터 전송 및 마이그레이션 · 모든 도메인 · 콘텐츠 전송 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →