Amazon ANS-C01: Transit Gateway 및 네트워크 토폴로지 — 학습 가이드
다음의 일부입니다: AWS Advanced Networking Specialty ANS-C01 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
핵심 개념
AWS Transit Gateway(TGW)는 Amazon VPC, VPN, Direct Connect 게이트웨이 및 다른 Transit Gateway 간의 라우팅을 중앙에서 관리하는 리전별 네트워크 트랜짓 허브입니다. 가장 간단하게 말해, TGW는 라우팅 플레인 역할을 합니다. 연결(attachment)을 생성하고(예: VPC의 경우 EC2 API 호출인 CreateTransitGatewayVpcAttachment, 어플라이언스의 경우 CreateTransitGatewayAttachment, 피어링의 경우 CreateTransitGatewayPeeringAttachment 사용) 하나 이상의 Transit Gateway 라우팅 테이블에 연결(associate)하고 전파(propagate)하여 해당 연결들이 라우팅을 교환하는 방식을 제어합니다. TGW의 라우팅 테이블은 TGW가 여러 가상 라우터(VRF)처럼 작동할 수 있도록 하는 격리 및 세분화 기본 요소를 제공합니다. 각 연결에 대해 어떤 TGW 라우팅 테이블과 연결(associate)할지(AssociateTransitGatewayRouteTable 사용), 그리고 어떤 연결의 라우팅을 어떤 테이블로 전파(propagate)할지(라우팅 테이블 전파 설정 사용) 결정합니다. TGW는 소스 연결이 연결된 모든 라우팅 테이블에서 최장 접두사 일치(longest-prefix match)를 기반으로 패킷을 전달하므로, 연결/전파 경계를 신중하게 설계하여 허브 앤 스포크(hub-and-spoke), 분할된 허브(segmented hub) 또는 부분 메시(partial mesh)를 구현합니다.
Transit Gateway 피어링은 TGW 간에 암호화된 프라이빗 리전 간 또는 계정 간 경로를 생성하며, 트래픽 흐름을 활성화하려면 여전히 라우팅 테이블 구성이 필요합니다. 요청자 측에서 CreateTransitGatewayPeeringAttachment로 피어링을 생성한 다음 수락자 측에서 AcceptTransitGatewayPeeringAttachment를 실행합니다. 그 후 피어링 연결이 사용되도록 적절한 TGW 라우팅 테이블에 라우팅을 추가해야 합니다. 피어링은 전이적(transitive)이지 않습니다. 즉, 명시적인 피어링 및 라우팅 테이블 매핑이 허용하지 않는 한 트래픽은 TGW-B를 통해 TGW-A에서 TGW-C로 흐르지 않습니다. TGW는 또한 CreateTransitGatewayConnect API로 생성되는 Connect 연결을 지원하여 SD-WAN 또는 서드파티 어플라이언스에 대한 고성능 연결을 제공합니다. 이는 캡슐화(GRE, VXLAN)와 특수 장치로의 높은 처리량 전달을 가능하게 합니다.
주요 서비스 및 구성
CreateTransitGatewayVpcAttachment를 사용하여 VPC 연결을 구성하고 필요한 연결 옵션을 설정해야 합니다. 예를 들어, 네트워크 어플라이언스로 트래픽을 전달하는 VPC 연결에 ApplianceModeSupport를 활성화하면 TGW가 어플라이언스로 트래픽을 보낼 때 원래 목적지를 유지합니다. 연결을 생성한 후 CreateTransitGatewayRouteTable을 사용하여 기본 라우팅 테이블 외에 추가 TGW 라우팅 테이블을 생성하고, AssociateTransitGatewayRouteTable을 호출한 다음 선택한 연결에 대해 전파를 활성화하여 해당 접두사가 라우팅 테이블에 나타나도록 합니다. 멀티캐스트 사용 사례의 경우, CreateTransitGatewayMulticastDomain으로 멀티캐스트 도메인을 생성한 다음, 참여할 연결에 대해 AssociateTransitGatewayMulticastDomain을 사용하고, RegisterTransitGatewayMulticastGroupMembers 및 RegisterTransitGatewayMulticastGroupSources를 사용하여 그룹 멤버십과 소스를 설정합니다. 멀티캐스트 도메인은 유니캐스트 라우팅 테이블과 별개이며 VPC 및 어플라이언스 전반에 걸친 IGMP 스타일 그룹 전송에 필요합니다.
글로벌 토폴로지 가시성 및 정책 적용을 위해서는 AWS Transit Gateway Network Manager(AWS Network Manager의 일부)를 사용합니다. Network Manager에서 Global Network를 생성하고(콘솔 또는 networkmanager:CreateGlobalNetwork 사용) Transit Gateway를 등록하여 리전 및 온프레미스 연결 전반에 대한 남북(north/south) 관점의 뷰를 확보합니다. Network Manager는 자동화된 성능 모니터링, 코어-주변부 시각화, 라우팅 분석을 제공하며, CloudWatch 지표와 VPC flow logs를 수집하여 TGW 연결 및 VPN/Direct Connect 링크와 연관시킬 수 있습니다. AWS Resource Access Manager(RAM)와의 통합을 통해 CreateResourceShare 및 적절한 주체(principal) 연결을 사용하여 중앙에서 관리되는 TGW를 다른 AWS 계정과 공유할 수 있습니다. TGW 옵션인 AutoAcceptSharedAttachments를 설정하거나 프로그래밍 방식으로 수락을 관리해야 한다는 점을 기억하십시오.
설계 패턴과 트레이드오프
단일 Transit Gateway로 구현된 허브 앤 스포크 토폴로지는 다중 VPC, 다중 계정 아키텍처에서 가장 일반적인 패턴입니다. 이는 연결을 중앙 집중화하고, 라우팅 전파를 단순화하며, 공유 서비스, 보안 어플라이언스, 온프레미스 연결을 통합할 수 있게 해주기 때문입니다. 하나 이상의 TGW 라우팅 테이블을 사용하여 비즈니스 단위 간의 세분화(segmentation)를 제공하십시오. 즉, 스포크를 스포크 전용 라우팅 테이블에 연결하고, 공유 서비스 프리픽스는 이를 필요로 하는 테이블에만 전파합니다. 이러한 중앙 집중화의 트레이드오프는 트래픽에 대한 단일 병목 지점이 될 수 있고, 잘못된 구성에 대한 단일 장애 영향 반경(blast radius)이 될 수 있다는 점입니다. TGW를 통과하는 대규모 East-West 트래픽 흐름은 신중한 트래픽 엔지니어링, 고성능 어플라이언스를 위한 Connect 연결(attachment) 배포, 또는 트래픽을 로컬로 유지하기 위한 리전별 TGW 배치가 필요할 수 있습니다.
풀 메시(TGW 간의 쌍방향 피어링 또는 다수의 VPC 피어링 링크)는 직접적인 연결을 제공하고 특정 트래픽 패턴에 대해 중앙 허브에 대한 의존도를 줄여주지만, 링크 수가 증가함에 따라 운영 복잡성이 증가하고 여러 관리 도메인에 걸쳐 보안 정책을 적용하기 어렵게 만듭니다. Transit Gateway 피어링(CreateTransitGatewayPeeringAttachment + AcceptTransitGatewayPeeringAttachment)은 AWS 글로벌 네트워크를 통해 암호화된 리전 간 백본 연결을 허용하며, 리전별 격리와 일부 공유 서비스를 함께 사용하고 싶을 때 유용합니다. 하지만 라우팅 테이블 매핑을 명시적으로 관리해야 하며 피어링은 전이성(transitive)이 없다는 점을 받아들여야 합니다. 패턴을 결합할 수도 있습니다. 리전별로 허브 앤 스포크 TGW를 구성하고 허브 간 피어링을 통해 리전 간 트래픽을 처리하는 방식은 확장성, 지연 시간, 장애 도메인 간의 균형을 맞추는 데 효과적입니다.
온프레미스 네트워크를 통합할 때는 Direct Connect 연결(association) 기능을 사용하여 Direct Connect Gateway를 TGW에 연결합니다(Direct Connect에서 프라이빗 가상 인터페이스(private virtual interface)를 구성하고 Direct Connect 콘솔 또는 API를 통해 TGW와의 연결(association)을 생성). 동적 라우팅을 위해 경로 기반 VPN(BGP over IPSec)을 사용할지, 아니면 엄격하게 제어되는 흐름을 위해 정적 라우팅을 사용할지 고려하십시오. 어플라이언스 기반 검사 및 상호 TLS(mTLS) 종료 사용 사례의 경우, 클라이언트와 백엔드 간에 종단 간 암호화가 필요하다면 중앙 어플라이언스에서 TLS를 종료하지 마십시오. 대신 애플리케이션 계층(예: EKS의 파드)에서 TLS를 종료하고, TGW 라우팅을 사용하여 Proxy Protocol로 클라이언트 IP를 보존하는 ALB 또는 Network Load Balancer를 통해 트래픽을 전달하거나, ALB의 X-Forwarded-For 헤더를 사용하십시오.
일반적인 실수와 결정 기준
TGW가 암시적 세분화를 제공한다고 가정하는 것은 일반적인 운영상의 실수입니다. 실제로는 그렇지 않습니다. 어떤 연결(attachment)이 어떤 접두사(prefix)에 도달할 수 있는지 제어하려면 라우팅 테이블을 명시적으로 생성 및 연결하고 전파(propagation)를 활성화해야 합니다. 또 다른 흔한 실수는 보안 그룹과 NACL을 잘못 구성하는 것입니다. TGW는 라우팅만 처리하므로 모든 VPC 보안 그룹과 NACL은 여전히 적용되며, 의도된 엔드투엔드 연결에 맞게 조정되어야 합니다. 상태 저장(stateful) 보안 그룹은 인스턴스나 로드 밸런서에서 평가된다는 점을 예상해야 합니다. ALB에서 TLS 종료 시 클라이언트 IP 보존이 필요하다면 ALB의 X-Forwarded-For를 활성화하고, Network Load Balancer의 경우 대상 유형을 IP로 사용하고 필요에 따라 프록시 프로토콜(proxy-protocol)을 사용하여 소스 IP를 보존해야 합니다.
확장 결정은 종종 트래픽 양과 관리 경계에 따라 달라집니다. 단일 TGW를 통해 많은 고처리량 흐름을 중앙 집중화하면 성능 및 장애 복구가 복잡해질 수 있습니다. 고대역폭 어플라이언스 링크에는 Transit Gateway Connect 연결을 사용하고, 격리를 위해 피어링된 여러 TGW를 고려하며, Network Manager를 사용하여 포화 상태를 모니터링하고 경보를 발생시키세요. 항상 연결, 라우팅 테이블, 멀티캐스트 도메인 수에 대한 소프트 리밋을 검토하고, 기본 할당량에 의존하기보다는 필요한 경우 증설을 요청해야 합니다.
실제 문제: 사용 사례 시나리오
회사: Atlas Financial Services. 과제: Atlas는 us-east-1에 있는 10개의 사업부 VPC를 중앙 공유 서비스 VPC에 연결하고, 사업부와 공유 서비스 간에 최소 권한 네트워크 액세스를 강제하며, 향후 수십 개의 사업부로 확장할 수 있어야 합니다. 또한, 때때로 Direct Connect 링크를 포화시키는 트래픽 급증 문제를 해결하기 위해 사업부별 트래픽 사용량을 분석할 수 있어야 합니다.
접근 방식 (번호순): 1.
undefined
를 사용하여 리전별 Transit Gateway를 프로비저닝하고,
undefined
를 사용하여 각 사업부별로 전용 Transit Gateway 라우팅 테이블과 공유 서비스용 라우팅 테이블을 하나씩 생성합니다. 이를 통해 VPC 피어링이 폭발적으로 증가하는 문제 없이 단위별 세분화가 가능합니다. 2.
undefined
를 통해 각 사업부 VPC를 연결하고
undefined
를 사용하여 단위별 라우팅 테이블에 연결합니다. 공유 서비스 VPC를 연결하고 공유 서비스 라우팅 테이블에만 연결합니다. 3. 전파를 선택적으로 활성화합니다. 각 사업부 연결이 자체 라우팅 테이블로 전파되도록 하고, 공유 서비스 연결이 해당 접두사를 별도의 공유 서비스 테이블로 전파하도록 합니다. 그런 다음 각 단위의 라우팅 테이블에 허용된 접두사에 대해 공유 서비스 연결을 가리키는 정적 경로를 추가하여, 단위 접두사를 공유 서비스 테이블로 전파하지 않음으로써 최소 권한을 강제합니다. 4. AWS RAM(
undefined
)을 사용하여 TGW를 다른 AWS 계정과 공유합니다. 이렇게 하면 새 사업부를 추가하는 작업이 VPC 연결 및 라우팅 테이블 연결로 단순화되어 관리 오버헤드를 최소화할 수 있습니다. 5. 트래픽 사용량 분석 및 문제 해결을 위해 TGW 및 관련 VPC에서 Flow Logs를 활성화하고, AWS Network Manager(
undefined
및 TGW 등록)에 TGW를 온보딩하여 토폴로지를 시각화하고 대역폭을 모니터링합니다. TGW Flow Logs와 CloudWatch 지표를 상호 연관시켜 어떤 연결이 Direct Connect 포화의 원인인지 식별합니다. 6. 예측 가능한 피크 시간대에 Direct Connect 용량이 포화되면 Direct Connect Gateway를 생성하고 TGW에 Direct Connect 연결을 사용합니다. 사업부별 경로 태깅을 구현하고, 필요한 경우 Direct Connect 게이트웨이에서 라우팅 정책(온프레미스 BGP 커뮤니티 또는 경로 필터)을 구성하여 단위별 트래픽을 제한하거나 조정합니다.
AWS의 논리적 근거: 단위별 라우팅 테이블과 함께 TGW를 사용하면 강력한 세분화를 제공하고, 더 많은 단위가 추가될 때 피어투피어 복잡성 없이 선형적으로 확장됩니다. AWS RAM으로 TGW를 공유하면 계정 간 관리가 최소화됩니다. 선택적 전파 및 정적 경로 항목은 라우팅 평면에서 최소 권한을 강제하는 반면, 보안 그룹과 NACL은 인스턴스 수준에서 액세스를 강제합니다. Flow Logs와 Network Manager를 함께 사용하면 어떤 연결 또는 사업부가 Direct Connect를 포화시키는지 정확히 찾아낼 수 있는 가시성을 확보할 수 있으므로, Atlas는 문제가 되는 단위에 대해 할당량 제어를 적용하거나 용량 증설을 요청할 수 있습니다.
← 하이브리드 연결: VPN 및 Direct Connect · 모든 도메인 · DNS 및 Route 53 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →