Amazon SAP-C02: 네트워킹 및 하이브리드 연결 — 학습 가이드

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

VPC 아키텍처 및 세분화 패턴

VPC 토폴로지 설계는 영향 반경(blast-radius) 관리와 예측 가능한 라우팅에서 시작됩니다. 소규모 배포 환경에서는 여러 서브넷과 엄격한 보안 그룹을 갖춘 단일 VPC가 효율적일 수 있지만, 팀과 애플리케이션이 성장함에 따라 단일 VPC 패턴은 취약해집니다. 리소스 할당량, 팀 간 거버넌스, ‘시끄러운 이웃(noisy neighbors)’ 문제로 인해 운영 리스크가 증가합니다. 팀별 다중 VPC 또는 팀별 계정 모델은 격리 수준과 IAM 경계를 개선합니다. AWS Organizations를 사용하여 팀별로 계정을 분리하고, DNS, 로깅, 자격 증명(identity)을 위한 공유 서비스 계정을 사용하세요. VPC 간 연결을 위해 VPC 피어링은 간단하고 지연 시간이 짧지만, 전이적(transitive) 라우팅을 지원하지 않으며 대규모 환경에서는 운영 부담이 큽니다. Transit Gateway(TGW)는 ‘전송(transit) VPC’ 패턴을 대체합니다. TGW는 수천 개의 연결(attachment)을 지원하고, 라우팅 테이블을 중앙 집중화하며, 멀티캐스트 또는 허브 앤 스포크 패턴을 단순화합니다. PrivateLink(인터페이스 VPC 엔드포인트)는 서비스를 인터넷에 노출하지 않고 서비스 수준의 격리를 가능하게 하며, 이는 계정 간 마이크로서비스에 매우 중요합니다. 흔한 함정으로는 세분화를 위해 보안 그룹에만 의존하는 것(보안 그룹은 상태 저장(stateful) 방식이며 east-west 트래픽 필터링에는 너무 광범위함), NACL의 상태 비저장(stateless) 동작을 잊는 것, CIDR 할당 계획을 세우지 않는 것(CIDR 중복은 피어링과 DX 연결을 방해함) 등이 있습니다. 결정은 비용과 관리 용이성 사이의 균형에 따라 달라집니다. TGW는 연결 비용이 발생하지만 피어링별 복잡성을 줄여주고, 다중 계정 격리는 랜딩 존 오버헤드를 증가시키지만 영향 반경을 줄여줍니다. 구성 변경(drift)을 방지하려면 항상 CIDR 계획, 라우팅 전파 규칙, 공유 서비스의 소유권을 문서화해야 합니다.

하이브리드 연결, 라우팅 및 복원력

하이브리드 연결 방식 선택은 처리량, 지터, 지연 시간 및 일관된 퍼블릭 이그레스(egress) 주소 지정에 따라 결정됩니다. AWS Direct Connect(DX) 프라이빗 VIF는 대규모의 꾸준한 트래픽 흐름에 대해 인터넷 VPN에 비해 예측 가능한 대역폭과 낮은 이그레스 비용을 제공합니다. 여러 리전으로 확장하려면 Direct Connect Gateway를 사용하거나, 중앙 집중식 라우팅을 위해 Transit Gateway에 연결하세요. Site-to-Site VPN(BGP를 사용하는 관리형 IPsec)은 빠른 설정을 위해 또는 DX에 대한 복원력 있는 백업으로 사용됩니다. 비대칭 라우팅을 피하려면 적절한 ASN과 라우팅 우선순위로 BGP를 구성해야 합니다. 주요 라우팅 함정으로는 온프레미스와 클라우드 CIDR의 중복, TGW에서의 부적절한 라우팅 전파, 피어링된 VPC 간의 전이적 라우팅을 가정하는 것 등이 있습니다. MTU와 단편화(fragmentation)는 VPN 트래픽을 중단시킬 수 있으므로, 경로 MTU(path MTU)를 테스트하고 장치에서 MSS를 조정해야 합니다. 다중 리전 환경에서는 여러 위치에 active/active DX를 구성하거나 DX와 VPN 장애 조치(failover)를 결합하는 방안을 고려하세요. 장단점: 전용 DX 연결은 비용이 더 많이 들지만 지터와 이그레스 요금을 줄여줍니다. VPN은 더 저렴하고 간단하지만 높은 처리량에서는 안정성이 떨어집니다. 예측 가능한 장애 조치를 위해 두 개의 독립적인 터널, 별도 위치에 있는 이중화된 DX 연결, 경로 선택 및 제한을 제어하기 위한 명시적인 TGW 라우팅 테이블을 사용하여 아키텍처를 설계해야 합니다.

DNS, PrivateLink 및 서비스 연결 패턴

DNS는 하이브리드 및 다중 계정 네트워킹의 핵심입니다. VPC 범위의 이름 확인을 위해서는 Route 53 Private Hosted Zone을 사용하고, 온프레미스와 AWS DNS 간의 조건부 전달을 활성화하려면 Route 53 Resolver 인바운드/아웃바운드 엔드포인트를 사용하세요. 이를 통해 내부 이름은 프라이빗 IP로 확인되고 퍼블릭 레코드는 전역적으로 유지되는 스플릿 호라이즌(split-horizon) DNS를 지원할 수 있습니다. PrivateLink(인터페이스 엔드포인트)는 트래픽을 퍼블릭 인터넷으로 라우팅하지 않고 AWS 서비스 또는 SaaS 파트너에 대한 프라이빗한 ENI 기반 연결을 제공합니다. 이는 더 저렴하고 ENI 대신 라우팅 테이블을 사용하는 S3 및 DynamoDB용 게이트웨이 엔드포인트와 대조됩니다. PrivateLink는 서비스가 VPC CIDR 충돌에 노출되는 것을 방지하고, 서비스 수락 정책을 통해 계정 간 소비자(consumer)를 지원합니다. 흔한 실수로는 모든 소비자 VPC에 프라이빗 호스팅 영역을 연결하는 것을 잊거나, 온프레미스 도메인에 대한 Route 53 Resolver 규칙을 생성하지 않거나, 엔드포인트별 ENI의 IP 사용량을 과소평가하는 것 등이 있습니다. 결정 기준: 높은 처리량의 S3/DynamoDB 액세스에는 NAT 비용을 피하기 위해 게이트웨이 엔드포인트를 선호하고, 더 엄격한 보안이 필요한 API 엔드포인트나 서드파티 서비스에 대한 프라이빗 액세스가 필요할 때는 인터페이스 엔드포인트를 사용하세요. DNS 지연 시간을 모니터링하고 변경 관리를 통해 TTL을 설정하여 장애 조치 동작을 관리하세요.

이그레스, NAT 설계, 보안 제어 및 운영 방식

이그레스 아키텍처는 비용, 감사 가능성, 서드파티 통합에 영향을 미칩니다. NAT Gateway는 프라이빗 서브넷을 위해 관리형 고가용성 IPv4 이그레스를 제공하며 AZ별로 자동 확장됩니다. NAT Instance는 처리량이 낮은 경우 더 저렴하지만, 운영 유지보수와 장애 조치 스크립팅이 필요합니다. 전용 이그레스 VPC를 Transit Gateway에 연결하여 이그레스를 중앙 집중화하면 일관된 아웃바운드 IP, 검사 지점, 단순화된 정책을 강제할 수 있지만, 헤어핀 라우팅과 잠재적인 대역폭 병목 현상이 발생할 수 있습니다. IPv6의 경우 Egress-Only Internet Gateway를 사용합니다. 감사 및 퍼블릭 인바운드 자격 증명 제거를 위해 SSH 배스천을 AWS Systems Manager Session Manager로 교체하십시오. Session Manager는 SSH 포트를 열지 않고 SSM 에이전트를 통해 작동합니다. 고급 필터링 및 DPI를 위해서는 TGW 뒤에 AWS Network Firewall 또는 서드파티 어플라이언스를 배포합니다. 비용 대비 성능 트레이드오프: NAT Gateway는 사용하기 쉽지만 GB당 요금이 추가됩니다. S3 이그레스 및 NAT 비용을 줄이려면 VPC 엔드포인트를 사용하십시오. 운영상의 함정으로는 트래픽 문제 해결을 위한 VPC Flow Logs를 활성화하지 않거나, 데이터 유출을 가능하게 하는 광범위한 이그레스 규칙을 남겨두거나, 의도치 않게 수명 주기 작업을 차단하는 SCP 또는 IAM 정책을 사용하는 것 등이 있습니다. 최소 권한 원칙을 적용하고 분석을 위해 모든 것을 중앙 계정에 로깅하십시오.

실용적인 문제: Acme Financial Services — 서드파티 화이트리스팅을 위한 중앙 집중식 예측 가능 이그레스

시나리오: Acme Financial Services는 두 개의 AWS 리전에 걸쳐 여러 애플리케이션 VPC를 운영하고 있으며, 이 VPC들은 Transit Gateway로 연결되어 있고 Direct Connect 및 VPN을 통해 온프레미스 데이터 센터와도 연결되어 있습니다. 여러 개별 계정의 애플리케이션들이 단일 퍼블릭 CIDR 블록의 요청만 허용하는 파트너 API를 호출해야 합니다.

과제: 모든 리전의 애플리케이션 VPC를 위해 예측 가능한 단일 퍼블릭 CIDR 블록을 갖춘 고가용성의 감사 가능한 이그레스 경로를 제공하면서, 지연 시간과 운영 오버헤드를 최소화해야 합니다.

권장 접근 방식:

BYOIP(Bring Your Own IP)를 사용하여 퍼블릭 IPv4 CIDR을 AWS로 가져오고, 해당 CIDR에서 이그레스 주소로 사용할 Elastic IP를 할당합니다.
각 리전에 여러 AZ에 걸쳐 NAT Gateway가 있는 중앙 집중식 이그레스 VPC를 구축합니다. 해당 NAT Gateway에 BYOIP Elastic IP를 연결하고 이그레스 VPC를 Transit Gateway에 연결합니다.
모든 애플리케이션 VPC가 0.0.0.0/0 트래픽을 이그레스 VPC 연결(attachment)로 라우팅하도록 TGW 라우팅 테이블을 업데이트하고, 경로 전파 및 AZ 간 상태 확인 기반 장애 조치를 활성화합니다. 필요한 경우 온프레미스 라우팅이 로컬 이그레스를 선호하도록 구성합니다.
아웃바운드 필터링을 위해 이그레스 VPC에 Network Firewall 또는 관리형 IDS를 배포하고, VPC Flow Logs 및 CloudWatch 경보를 활성화하며, DNS 전달이 필요한 경우 Route 53 Resolver를 사용합니다.

근거: TGW와 NAT Gateway를 통해 이그레스를 중앙 집중화하고 BYOIP로 가져온 IP 공간을 사용하면, 고가용성과 중앙 집중식 모니터링을 유지하면서 화이트리스팅을 위한 예측 가능한 CIDR을 확보할 수 있습니다. 이 방식은 운영 단순성, 보안 제어, 단일 퍼블릭 CIDR에 대한 파트너의 요구 사항 간에 균형을 맞춥니다.

← 조직 복잡성 및 다중 계정 전략 · 모든 도메인 · 보안 →

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