AWS Certified Advanced Networking - Specialty (ANS-C01)

오답입니다. Transit gateway는 주로 VPC와 온프레미스 네트워크 간 라우팅을 단순화하고 확장합니다. 동일한 VPC 내의 특정 EC2 기반 어플라이언스에 도달해야 하는 트래픽에 대해 처리량을 본질적으로 증가시키거나 지연 시간을 줄이지 않습니다. 경우에 따라 추가 홉과 추가 처리를 유발할 수 있습니다. TGW는 멀티 VPC 아키텍처에 적합하며, 단일 인스턴스 어플라이언스 성능을 높이기 위한 선택은 아닙니다.

오답입니다. Placement group(cluster/spread/partition)는 EC2 인스턴스들이 서로에 대해 어떻게 배치되는지에 영향을 주어 인스턴스 간 지연 시간/처리량을 개선하거나 장애 격리를 제공하도록 설계되었습니다. 온프레미스에서 단일 EC2 인스턴스로의 WAN/VPN 경로를 개선하지는 않습니다. 트래픽이 데이터 센터에서 오기 때문에, placement group은 이 특정 병목에 거의 또는 전혀 도움이 되지 않습니다.

오답입니다. 여러 ENI를 연결하면 네트워크 세그멘테이션, 어플라이언스 설계 패턴, 또는 IP/인터페이스 수 증가에는 도움이 될 수 있지만, 단일 트래픽 흐름에 대해 대역폭을 자동으로 집계하지는 않습니다. EC2 네트워크 성능은 주로 인스턴스 타입/크기와 enhanced networking에 의해 결정됩니다. 더 높은 처리량을 위해서는 보통 여러 ENI에 의존하기보다 인스턴스를 스케일 업하거나 여러 어플라이언스를 스케일 아웃합니다.

각 account에서 EC2에 cron 기반 스크립트를 실행하는 방식은 상당한 관리 오버헤드(instance, patching, IAM, scheduling, scaling)를 유발합니다. 5분 간격은 즉시 탐지가 아니며 정책 위반이 지속될 수 있습니다. RDS에 로깅하는 것은 비용과 관리를 추가하며, 여전히 기본 제공 컴플라이언스 보고를 제공하지 않습니다. 이 접근 방식은 운영적으로 무겁고 AWS managed 거버넌스 패턴과 맞지 않습니다.

Lambda는 서버 관리를 줄이지만, 옵션은 “프로그래밍 방식으로 확인”이라고 설명하여 이벤트 기반 탐지보다는 polling을 의미합니다. polling은 여전히 즉시성이 없고 scheduling 및 custom 상태 저장이 필요합니다. account별 OpenSearch는 비용이 크고 운영이 복잡하며, AWS Config가 제공하는 직관적인 컴플라이언스 이력 및 감사 뷰를 제공하지 않습니다. SAM은 배포에 도움이 되지만 거버넌스/보고는 여전히 custom입니다.

GuardDuty는 위협 탐지 서비스이며 NAT gateway 생성에 대한 표준 finding type을 제공하지 않습니다(언급된 finding type은 일반적인 GuardDuty taxonomy가 아닙니다). 설령 이벤트를 캡처하더라도 S3에 런타임 로그를 저장하는 것은 rule 평가 및 타임라인을 갖춘 컴플라이언스 이력과 동일하지 않습니다. 또한 이 옵션은 AWS Config보다 컴플라이언스 거버넌스에 덜 신뢰할 수 있는 방식으로 서비스를 혼합합니다.

옵션 B는 두 개의 10 Gbps 연결만 사용하며, 각 Direct Connect location당 하나씩이고 각각 다른 라우터에 종단됩니다. 대역폭은 충분하지만, 이 설계는 location당 회선이 하나뿐이므로 단일 회선 장애가 발생하면 해당 location을 통한 모든 연결이 사라집니다. 이는 4개 연결 설계보다 회선 수준 복원력이 낮으며, 회선 장애를 견뎌야 한다는 요구 사항에도 덜 부합합니다. 최대 복원력을 위한 AWS 모범 사례는 여러 location과 라우터에 걸쳐 여러 연결을 사용하는 것입니다.

옵션 C는 총 4 Gbps를 제공하는 4개의 1 Gbps 연결을 제공하지만, 이는 정상 운영 중에만 가능합니다. 단일 회선에 장애가 발생하면 사용 가능한 대역폭은 3 Gbps로 떨어지며, 더 이상 4 Gbps 전송 요구 사항을 충족하지 못합니다. 마찬가지로 라우터 하나에 장애가 발생하고 두 개의 회선이 해당 라우터에 연결되어 있다면 2 Gbps만 남습니다. 따라서 이 옵션은 가용성 관점에서는 복원력이 있지만, 지정된 장애 시나리오 동안 필요한 처리량을 유지하지는 못합니다.

옵션 D는 2개의 1 Gbps 연결만 제공하므로 최대 총 처리량은 2 Gbps입니다. 이는 장애를 고려하기 전에도 명시된 4 Gbps 피크 트래픽 요구 사항을 충족하기에 부족합니다. 또한 회선 하나 또는 라우터 하나를 잃으면 용량은 더 줄어듭니다. 이 옵션은 대역폭과 복원력 요구 사항을 모두 충족하지 못합니다.

오답입니다. Internet Key Exchange (IKE)는 IPsec VPN 터널(Site-to-Site VPN)에 사용되며 MACsec에는 사용되지 않습니다. MACsec은 Layer 2 encryption(802.1AE)이며 IKE로 키를 협상하지 않습니다. 여기서 IKE를 선택하는 것은 MACsec과 IPsec 기반 encryption 솔루션을 혼동한 전형적인 사례입니다.

오답입니다. 기존 LAG에서 MACsec encryption mode를 구성하면 중단 위험이 있습니다. encryption 활성화는 양쪽 끝이 일관되게 구성되어야 하며, 불일치 시 링크 드롭이 발생할 수 있습니다. 또한 기존 회선/포트가 MACsec을 지원하지 않으면 이 단계로는 요구 사항을 충족할 수 없습니다. 문제는 최소 다운타임을 강조하므로, 병렬 MACsec 지원 LAG를 선호합니다.

오답입니다. MACsec은 궁극적으로 물리 링크에서 동작하지만, AWS에서 MACsec 구성은 일반적으로 연결 또는 LAG 구성 단위에서 관리되며, 기본 단계로 각 멤버별로 별도의 “mode” 구성을 요구하는 방식이 아닙니다. 최소 다운타임의 시험 관점 접근은 새 MACsec 지원 LAG를 구축하고 이를 구성하는 것이지, 기존 멤버 연결에 대해 부분적으로 변경을 시도하는 것이 아닙니다.

오답입니다. source 서비스를 호스팅하는 프로덕션 account의 security group은 이 시나리오에서 mirrored packet의 무작위 손실을 설명하지 못합니다. security group 문제는 일반적으로 간헐적인 packet 누락보다는 특정 트래픽 패턴, port 또는 protocol에 대한 결정적인 차단을 유발합니다. 또한 Traffic Mirroring은 VPC data plane의 source ENI에서 발생하므로, 설명된 증상은 일반적인 source 측 security group 문제와 일치하지 않습니다. target 경로의 security control이 잘못되었다면, 실패는 무작위라기보다 일관되게 발생할 가능성이 더 높습니다.

오답입니다. IAM policy는 control plane을 통해 traffic mirror session, target 및 filter를 누가 생성, 수정 또는 삭제할 수 있는지를 제어합니다. mirroring이 이미 활성화되어 동작 중인 이후에는 IAM이 mirrored packet의 runtime 전달에 관여하지 않습니다. 따라서 IAM policy 구성 오류는 일반적으로 설정이나 변경을 막을 뿐, 활성 session에서 산발적인 packet loss를 유발하지는 않습니다. 이 선택지는 provisioning 권한과 data-plane 동작을 혼동하고 있습니다.

오답입니다. Network Load Balancer에는 Traffic Mirroring 설계에서 무작위 packet loss를 설명할 수 있는 문서화된 'warm-up delay' 특성이 없습니다. NLB는 자동으로 scale하도록 설계되었으며, 일부 오래된 AWS load balancing 맥락에서 보였던 classic pre-warming 우려와 관련이 없습니다. downstream target capacity 문제는 분석 시스템에 영향을 줄 수 있지만, NLB warm-up delay에 대한 구체적인 설명은 기술적으로 오해의 소지가 있습니다. 이 문제에서는 AWS 문서화된 mirroring best-effort 동작과 source/ENI capacity 한계가 그럴듯한 설명입니다.

가장 운영 효율적인 방식이 아닙니다. DynamoDB 기반 Lambda updater는 커스텀 자동화, IAM role, 오류 처리, 그리고 모든 계정에 대한 배포 및 유지 관리를 필요로 합니다. function이 실패하거나 잘못 구성되면 운영 오버헤드와 드리프트 가능성이 생깁니다. 동작은 가능하지만, 중앙에서 CIDR allow list를 관리하도록 설계된 네이티브 VPC 구성 요소를 사용하는 것보다 확장성이 떨어지고 덜 우아합니다.

이 선택지는 prefix list가 변경될 때마다 security group을 업데이트하기 위해 EventBridge와 Lambda를 추가하므로, 사용자 지정 orchestration과 운영 오버헤드를 다시 도입하게 되어 덜 효율적입니다. Prefix list가 선택된 추상화라면, 목표는 지원되는 곳에서 이를 직접 사용하는 것이어야지 security group rule을 다시 작성하도록 코드를 트리거하는 것이어서는 안 됩니다. 또한 필요한 cross-account 공유 메커니즘이 빠져 있으므로, multi-account 중앙 관리 요구 사항을 완전히 해결하지 못합니다.

옵션 A와 유사하게, 운영 부담이 더 큰 커스텀 자동화 접근 방식입니다. CIDR을 S3에 저장하고 Lambda를 실행하여 계정 간 security group을 업데이트하려면 계정별 배포, cross-account permission, 그리고 장애 및 동시성에 대한 견고한 처리가 필요합니다. AWS RAM을 통해 공유되는 managed prefix list를 사용하는 것만큼 효율적이거나 확장 가능하지 않습니다. 이 방식은 해당 사용 사례를 위해 목적에 맞게 설계되어 있습니다.

오답입니다. Transit Gateway로의 정적 라우팅 VPN은 일반적으로 동적(BGP) VPN과 같은 ECMP 로드 셰어링 기능을 제공하지 않으며 운영 측면에서 취약합니다(수동 route 관리 및 덜 우아한 failover). 여러 tunnel이 존재하더라도 BGP 기반 ECMP가 없으면 집계 대역폭을 늘리기 위한 신뢰할 수 있는 active/active 트래픽 분산을 보통 달성할 수 없습니다.

오답입니다. VPN acceleration(가능한 경우)은 AWS 글로벌 네트워킹을 활용하여 성능 특성(예: 지연/jitter)을 개선할 수 있지만, 여러 병렬 VPN 연결과 ECMP처럼 집계 처리량을 근본적으로 확장하지는 못합니다. 요구 사항은 가용성을 희생하지 않고 집계 VPN 대역폭을 늘리는 것이며, acceleration만으로는 로드 셰어링을 위한 병렬 경로가 추가되지 않습니다.

오답입니다. EC2에서 자체 관리 소프트웨어 VPN appliance를 운영하면 운영 오버헤드가 증가하고 새로운 병목 및 가용성 우려(인스턴스 sizing, scaling, patching, failover 설계)를 초래할 수 있습니다. 또한 관리형 TGW VPN 접근 방식에서 벗어나며, 복잡한 HA pair 및 라우팅 설계를 구축하지 않으면 “고가용성” 요구 사항을 충족하지 못할 수 있습니다. 이 문제는 TGW를 통해 여러 VPC로 VPN 처리량을 확장하는 것을 요구하며, 이는 관리형 VPN + ECMP로 가장 잘 충족됩니다.

오답입니다. AWS Site-to-Site VPN은 개별 원격 사용자용 Client VPN이 아니라 네트워크 간 연결(예: 온프레미스와 VPC)을 위한 것입니다. 사용자를 Site-to-Site VPN으로 마이그레이션하려면 새로운 customer gateway 디바이스/구성이 필요하며 지리적 위치 문제를 직접 해결하지도 못합니다. 또한 Client VPN 라우팅을 조정하는 것에 비해 서비스 중단과 운영 변경이 큽니다.

오답입니다. Client VPN endpoint security group에서 0.0.0.0/0 아웃바운드 규칙을 제거해도 지리적 위치 문제를 유발하는 라우팅 문제는 해결되지 않습니다. 오히려 VPN 클라이언트에서 내부 리소스(및 필요할 수 있는 AWS 서비스)로의 정상적인 아웃바운드 연결을 깨뜨릴 가능성이 높아 불필요한 중단을 초래합니다. 지리적 위치는 SG 규칙이 아니라 egress 경로/IP에 의해 결정됩니다.

오답입니다. 다른 VPC에서 Client VPN endpoint를 삭제하고 재생성하는 것은 매우 중단이 큽니다(새 endpoint, association, authorization rules, 클라이언트 구성 업데이트 필요). egress IP 범위를 바꿔 지리적 위치가 달라질 수는 있지만, 근본 원인(인터넷 트래픽이 AWS를 통해 라우팅되는 풀 터널)을 해결하지 못합니다. split-tunnel과 라우트 변경이 최소 중단 해결책입니다.

오답입니다. Route 53 Resolver는 "*"를 catch-all forwarding 도메인으로 사용하지 않으며, 올바른 catch-all은 "."입니다. 또한 corp.global.internal에 대해 Route 53 Resolver를 대상으로 하는 사용자 정의 system rule을 사용하는 방식으로 private hosted zone resolution을 구성하지 않습니다. Private hosted zone은 연결된 VPC에 대해 자동으로 resolution되며, forwarding rule은 Route 53 Resolver 자체가 아니라 outbound endpoint를 통해 외부 DNS 서버를 대상으로 합니다.

오답입니다. forwarding rule은 "Route 53 Resolver"를 외부 DNS 대상처럼 지정할 수 없으며, forwarding rule은 outbound endpoint를 통해 도달 가능한 대상 IP 주소를 지정해야 합니다. 또한 outbound endpoint를 대상으로 하는 "." system rule은 유효한 Route 53 Resolver 구성 요소가 아닙니다. 이 선택지는 private hosted zone이 resolution되는 방식과 outbound forwarding rule이 정의되는 방식을 모두 잘못 이해하고 있습니다.

오답입니다. "."에 대한 forwarding rule만 있으면 일치하지 않는 모든 쿼리를 온프레미스 DNS resolver로 보낼 수 있지만, 이 선택지는 corp.global.internal에 대해 요구되는 특정 처리를 제공하지 않습니다. 또한 Resolver rule이 transit gateway attachment와 연결된다고 잘못 설명하고 있는데, 실제로 Resolver rule은 VPC와 연결됩니다. 더 구체적인 corp.global.internal rule이 없으면 이 설계는 모든 VPC에서 split-resolution 요구 사항을 명시적으로 충족하지 못합니다.

각 VPC의 VGW로 private VIF를 사용하는 DXGW는 온프레미스-to-VPC 연결을 제공할 수 있지만, 계정/Regions 전반에서 모든 VPC를 서로 효율적으로 상호 연결하는 방법을 제공하지 않습니다. VPC-to-VPC 도달성을 위해서는 VPC peering, VPN 또는 TGW 같은 추가 구성 요소가 필요합니다. 또한 4개 링크에 대한 ECMP는 핵심 이슈가 아니며, 아키텍처가 “모든 VPC 상호 연결” 요구 사항을 깔끔하게 충족하지 못합니다.

이 옵션은 TGW가 Regional 서비스이므로 eu-west-3와 eu-central-1에 걸친 “단일 TGW”를 가질 수 없기 때문에 틀립니다. 또한 “inter-Region LAG”는 지원되는 Direct Connect 개념이 아닙니다(LAG는 단일 DX location 내에서만 해당). DXGW + transit VIF로 TGW에 연결하는 원칙 자체는 맞지만, 단일 TGW의 multi-Region 전제가 설계를 무효화합니다.

이 옵션은 VGW에 사용되는 private VIF 기반 DXGW 연결과, transit VIF가 필요한 TGW 연결을 혼합하고 있어 틀립니다. 또한 “inter-Region LAG”는 유효한 AWS DX 기능이 아닙니다. TGW를 추가하더라도 설명된 연결 모델은 잘못되었거나 불완전하며, 적절한 multi-Region 복원력과 분리를 갖춘 전체 VPC 도달성을 명확히 달성하지 못합니다.

NLB origins와 Route 53 weighted routing을 사용하는 CloudFront distributions는 일부 트래픽 전환을 제공할 수 있지만, CloudFront는 NLB 뒤의 임의의 애플리케이션 프로토콜에 대한 일반적인 TCP/UDP 프런트 도어로 의도되지 않았습니다. 또한 weighted DNS는 DNS 해석 이후에도 트래픽이 퍼블릭 인터넷을 통과하므로 jitter/first-byte latency를 본질적으로 최소화하지 못합니다. 이 옵션은 TCP/UDP 및 jitter 요구 사항을 가장 잘 충족하지 못하는 방식으로 서비스를 혼합하고 있습니다.

S3 Transfer Acceleration은 edge locations를 사용하여 Amazon S3로의 업로드/다운로드를 가속하는 기능일 뿐이며, EC2/NLB 기반 multi-tier 애플리케이션의 프런트 도어 역할을 하지 못하고 NLB endpoints로의 TCP/UDP listener 라우팅도 제공하지 않습니다. 또한 애플리케이션 스택의 단계적 롤아웃을 위한 필요한 multi-Region traffic dials도 제공하지 않습니다. 서비스가 요구 사항과 맞지 않습니다.

CloudFront origin groups는 주로 origin failover(기본/보조)를 위한 것이며, 일반적인 TCP/UDP 애플리케이션 트래픽보다는 HTTP/HTTPS 콘텐츠 전송에 초점이 맞춰져 있습니다. Route 53 latency routing은 사용자를 더 낮은 지연의 Regions로 스티어링할 수 있지만, Global Accelerator traffic dials처럼 롤아웃 비율을 정밀하게 제어할 수 없고, AWS backbone을 통한 라우팅만큼 jitter/first-byte latency를 효과적으로 줄이지도 못합니다.

오답입니다. AWS managed prefix lists는 Direct Connect를 통한 AWS에서 온프레미스로의 route advertisement를 허용하는 데 사용되는 기능이 아닙니다. 또한 이 선택지는 여전히 단일 aggregate가 아니라 두 개의 개별 CIDR 항목을 사용하므로, 개념적으로도 항목 하나 제한을 해결하지 못합니다. 광고되는 route에 영향을 주려면 엔지니어는 managed prefix list가 아니라 DXGW allowed prefix list를 수정해야 합니다.

오답입니다. 10.0.32.0/21과 10.0.40.0/21을 Direct Connect gateway allowed prefix list에 직접 추가하려면 별도의 항목 두 개가 필요합니다. 문제에서는 allowed prefix list에 항목 하나만 더 추가할 수 있다고 명시하고 있으므로, 이 선택지는 제시된 제약 조건을 충족할 수 없습니다. prefix 자체는 유효한 AWS route이지만, 이 접근 방식은 규모 제한 요구 사항을 충족하지 못합니다.

오답입니다. CIDR 10.0.32.0/20은 올바른 aggregate이지만, AWS managed prefix lists는 Direct Connect gateway에서 온프레미스로의 route advertisement를 제어하지 않습니다. Managed prefix lists는 route tables 및 security groups 같은 VPC 리소스를 위한 재사용 가능한 CIDR 집합이지, DXGW BGP filtering용이 아닙니다. 따라서 요약 경로를 거기에 배치해도 문제에서 묻는 실제 문제를 해결할 수 없습니다.

오답입니다. Amazon CloudFront는 주로 HTTP/HTTPS를 위한 CDN이며 NLB 오리진으로의 범용 UDP 가속 경로를 제공하지 않습니다. CloudFront가 웹 전달을 위해 특정 TCP 기반 오리진을 앞단에 둘 수는 있지만, 독점 UDP 센서 프로토콜을 프록시하도록 설계되지 않았습니다. UDP 가속과 static anycast 인그레스를 위해서는 Global Accelerator가 적절한 AWS 서비스입니다.

오답입니다. Route 53 failover routing은 active-passive이며 기본 endpoint가 비정상(unhealthy)일 때 가용성을 제공하기 위한 것입니다. 지연 시간을 최적화하지 않으며, 기본 endpoint가 정상인 상태에서 발생하는 간헐적 패킷 손실을 해결하지 못합니다. 또한 “패킷이 드롭됨”은 Route 53이 플로우 단위로 감지할 수 있는 것이 아니며, DNS failover는 UDP 텔레메트리 스트림에 비해 거칠고 느립니다.

오답입니다. ENA를 통한 enhanced networking은 패킷이 인스턴스에 도달한 이후에 EC2 네트워크 성능(더 높은 bandwidth, 더 낮은 latency, 더 높은 PPS)을 개선합니다. 설명된 문제는 남아시아에서 us-west-2로 공용 인터넷을 통해 전송되는 과정에서, 트래픽이 AWS에 도착하기 전에 발생하는 패킷 손실입니다. ENA는 장거리 경로의 신뢰성을 실질적으로 개선하거나 인터넷 라우팅 관련 손실을 줄이지 못합니다.

이 옵션은 기본 ALB listener rule이 path-pattern 또는 source-ip와 같은 조건을 포함하도록 수정될 수 없기 때문에 잘못되었습니다. 기본 rule은 항상 무조건적이며, 모든 더 높은 priority rules가 확인된 후에만 평가됩니다. 또한 조건이 일치하지 않을 때 management target group으로 전달한다고 설명하는데, 이는 원하는 동작과 반대입니다. group-level stickiness는 이 잘못된 listener-rule 설계를 해결하지 못합니다.

이 옵션은 ALB listener rules가 X-Forwarded-For header를 검사하는 대신 native source-ip 조건을 사용해야 하므로 잘못되었습니다. X-Forwarded-For는 여러 주소를 포함할 수 있으며, ALB listener rule matching을 위한 의도된 access-control primitive가 아닙니다. 요구 사항은 specifically on-premises source CIDR ranges로 액세스를 제한하는 것이며, 이는 ALB가 직접 지원합니다. group-level stickiness는 유용할 수 있지만, 여기의 트래픽 매칭 방식은 기술적으로 부적절합니다.

이 옵션은 모든 요청을 web app target group으로 전달하면 /management path가 management target group으로 라우팅되지 못하므로 잘못되었습니다. 또한 stickiness를 비활성화하라고 하는데, 이는 management application의 stateful 특성과 충돌합니다. 올바른 ALB 구성에는 /management를 위한 특정한 더 높은 priority rule과 나머지 모든 것에 대한 별도의 기본 action이 필요합니다. 이 옵션은 필요한 listener-rule 조합을 구현하지 않습니다.

오답입니다. VPC Flow Logs는 네트워크 흐름 메타데이터(소스/대상 IP, 포트, 프로토콜, bytes, action)를 제공하지만 패킷 페이로드를 포함하지 않습니다. 콘텐츠 검사는 패킷 사본(L2/L3/L4 및 페이로드 가시성)이 필요하며, flow logs로는 이를 제공할 수 없습니다. 또한 flow logs는 S3/CloudWatch로 비동기 전달되므로 실시간 검사나 검사 계층이 전체 트래픽을 수신하는지 검증하는 데 적합하지 않습니다.

오답입니다. Amazon Kinesis Data Firehose는 지원되는 VPC Traffic Mirroring 타깃이 아니며, S3, Redshift 또는 OpenSearch 같은 대상으로 스트리밍 레코드를 전달하도록 설계되었습니다. 실시간 콘텐츠 검사를 위한 원시 패킷 미러링 용도가 아닙니다. 개념적으로도 패킷을 Firehose 레코드로 변환하면 콘텐츠 검사에 필요한 네트워크 트래픽의 완전한 충실도를 보존할 수 없습니다.

명시된 요구 사항에는 부적합합니다. Gateway Load Balancer (GWLB)는 GENEVE 캡슐화를 사용하여 보안 어플라이언스를 통해 inline으로 트래픽을 조향하는 데 사용되며, 즉 원래 트래픽이 목적지에 도달하기 전에 어플라이언스를 통해 라우팅됩니다. 문제는 원래 흐름을 방해하지 않고 단일 노드 어플라이언스로 트래픽 사본을 투명하게 전송하는 솔루션을 요구하므로, GWLB가 아니라 Traffic Mirroring에 해당합니다.

TGW는 VPC-to-VPC 확장성을 개선하지만, TGW와 SD-WAN transit VPC 사이에 Site-to-Site VPN을 사용하는 경우 여전히 VPN tunnel 구성을 기반으로 하며, 설계에 따라 더 수동적인 라우팅(static route 또는 제한적인 동적 동작)이 필요할 수 있습니다. 동작은 가능하지만, SD-WAN 통합을 위해 목적에 맞게 설계되고 BGP 기반의 동적 route 교환을 제공하는 TGW Connect에 비해 운영 오버헤드가 가장 낮지는 않습니다.

VPC peering은 이 사용 사례에 대해 확장성이 좋지 않습니다: non-transitive(허브를 구축하려 할 때의 핵심 제한)이며, VPC 수가 증가할수록 많은 peering 연결을 관리해야 하고, peer당 route table entry가 증가합니다. 또한 현재 모델 대비 운영 오버헤드를 본질적으로 줄이지 못하며 route table 확장 문제를 다시 유발할 수 있습니다.

이는 서로 맞지 않는 두 가지 확장 접근 방식을 혼합합니다: VPC 연결에 VPC peering(비전이적이며 대규모에서 운영 부담이 큼)을 사용하고, SD-WAN 통합에는 TGW Connect를 사용합니다. SD-WAN 통합이 개선되더라도 VPC-to-VPC 및 VPC-to-hub 연결은 여전히 peering의 확장/관리 제한을 겪게 되므로, 전체 요구 사항을 가장 적은 운영 오버헤드로 충족하지 못합니다.

오답입니다. 2 Gbps router에서 더 긴 prefix(더 구체적인 route)를 광고하면, 덜 선호되는 것이 아니라 오히려 2 Gbps 경로가 더 선호됩니다. longest-prefix match는 BGP attribute 비교보다 먼저 적용되기 때문입니다. 이는 트래픽을 2 Gbps connection으로 유도하여 요구 사항과 반대가 됩니다. more-specific route는 일반적으로 트래픽을 끌어들이는 데 사용되며, 링크의 선호도를 낮추는 데 사용되지 않습니다.

오답입니다. 5 Gbps router에서 덜 구체적인 route를 광고하면, 2 Gbps router가 동일 목적지에 대해 더 구체적인 route를 계속 광고하는 경우 일반적으로 5 Gbps 경로의 선호도가 낮아집니다. AWS는 더 구체적인 prefix(아마도 2 Gbps 링크에서 온 것)를 매칭하여 그쪽으로 트래픽을 보낼 것입니다. 이는 5 Gbps connection을 우선 사용하려는 목표를 훼손합니다.

오답입니다. 5 Gbps router에서 AS_PATH를 prepend하면 5 Gbps 경로가 AWS 입장에서 덜 매력적으로 되어, AWS가 2 Gbps connection을 선호하게 됩니다. 이는 원하는 동작과 반대입니다. AS_PATH prepending은 primary(5 Gbps)가 가장 선호되도록, backup/secondary 경로(2 Gbps)에 적용해야 합니다.

오답입니다. ALB의 internal DNS name으로의 CNAME은 apex가 아닌 이름(예: app.example.com)에서만 동작할 수 있습니다. 요구 사항은 https://example.com (apex)입니다. DNS는 SOA/NS record와 충돌하므로 zone apex에서 CNAME을 허용하지 않습니다. Route 53 Alias는 ALB 같은 AWS 리소스에 대해 apex 매핑을 가능하게 하려고 존재합니다.

오답입니다. Resolver outbound endpoint는 VPC 내 리소스가 on-premises에 호스팅된 DNS 이름을 resolve해야 할 때(VPC-to-on-prem) 사용합니다. 이 문제는 반대로 on-prem 클라이언트가 Route 53의 private hosted zone을 resolve해야 합니다. 따라서 outbound가 아니라 inbound endpoint가 필요합니다.

오답입니다. 172.31.0.2 (AmazonProvidedDNS)는 VPC 내부 인스턴스가 사용하도록 의도된 VPC resolver 주소입니다. VPN/Direct Connect를 통해 on-premises 네트워크에서 범용 DNS 서버처럼 사용하도록 설계되지 않았으며, on-prem에서 이를 대상으로 forwarding하는 방식은 지원되는 접근이 아닙니다. 하이브리드 DNS에는 Route 53 Resolver endpoint가 지원되는 메커니즘입니다.

오답입니다. Direct Connect virtual interface는 VLAN tagging이 필요하므로 VLAN trunking을 비활성화하는 것이 목표가 아닙니다. 중요한 요구 사항은 라우터 subinterface가 VIF 구성과 일치하는 올바른 802.1Q VLAN tag를 전달하는 것입니다. trunking 또는 VLAN tagging을 끄면 일반적으로 VIF를 수정하는 것이 아니라 오히려 망가뜨리게 됩니다.

오답입니다. ARP table에서 AWS endpoint의 MAC address entry를 확인하는 것은 DOWN transit VIF에 대한 주요하거나 가장 신뢰할 수 있는 문제 해결 단계 중 하나가 아닙니다. 더 적절한 확인 항목은 물리 optical signal, VLAN tag, 그리고 subinterface의 point-to-point IP/subnet 구성입니다. ARP 관찰은 부수적일 수 있지만, 문서화된 기본 확인 항목과 비교하면 최선의 정답 선택지는 아닙니다.

오답입니다. TCP port 179는 BGP에서 사용되지만, 엔지니어는 Amazon peer IP에조차 ping할 수 없습니다. 이는 문제가 BGP session 계층보다 아래에 있을 가능성이 높다는 뜻입니다. TCP 179 port가 차단되면 BGP 수립은 방해하겠지만, VLAN과 IP connectivity가 그 외에는 올바른 경우 peer IP 자체에 도달하지 못하는 현상을 일반적으로 설명하지는 못합니다. 따라서 이는 이 시나리오에서 가장 먼저 수행할 세 가지 문제 해결 단계 중 하나가 아닙니다.