기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 인터넷으로의 중앙 집중식 송신
다중 계정 환경에 애플리케이션을 배포하면 많은 앱에 아웃바운드 전용 인터넷 액세스가 필요합니다(예: 라이브러리, 패치 또는 OS 업데이트 다운로드). IPv4 및 IPv6 트래픽 모두에 대해 이를 달성할 수 있습니다. IPv4의 경우 NAT 게이트웨이(권장) 형식의 네트워크 주소 변환(NAT) 또는 모든 송신 인터넷 액세스를 위한 수단으로 Amazon EC2 인스턴스에서 실행되는 자체 관리형 NAT 인스턴스를 통해 이를 달성할 수 있습니다. 내부 애플리케이션은 프라이빗 서브넷에 상주하는 반면, NAT 게이트웨이 및 Amazon EC2 NAT 인스턴스는 퍼블릭 서브넷에 상주합니다.
AWS에서는 NAT 게이트웨이를 사용하는 것이 좋습니다. NAT 게이트웨이는 가용성과 대역폭이 향상되고 관리하는 데 필요한 노력이 줄어들기 때문입니다. 자세한 내용은 [NAT 게이트웨이와 NAT 인스턴스 비교를 참조하세요](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html).
IPv6 트래픽의 경우 외부 트래픽은 외부 전용 인터넷 게이트웨이를 통해 각 VPC를 분산 방식으로 벗어나도록 구성하거나 NAT 인스턴스 또는 프록시 인스턴스를 사용하여 중앙 집중식 VPC로 전송하도록 구성할 수 있습니다. IPv6 패턴은에서 설명합니다[IPv6에 대한 중앙 집중식 송신](centralized-egress-for-ipv6.md).
**Topics**
+ [중앙 집중식 IPv4 송신에 NAT 게이트웨이 사용](using-nat-gateway-for-centralized-egress.md)
+ [중앙 집중식 IPv4 송신을 AWS Network Firewall 위해에서 NAT 게이트웨이 사용](using-nat-gateway-with-firewall.md)
+ [중앙 집중식 IPv4 송신을 위해 Amazon EC2 인스턴스와 함께 NAT 게이트웨이 및 Gateway Load Balancer 사용](using-nat-gateway-and-gwlb-with-ec2.md)
+ [IPv6에 대한 중앙 집중식 송신](centralized-egress-for-ipv6.md)
# 중앙 집중식 IPv4 송신에 NAT 게이트웨이 사용
NAT 게이트웨이는 관리형 네트워크 주소 변환 서비스입니다. 모든 스포크 VPC에 NAT 게이트웨이를 배포하면 배포하는 모든 NAT 게이트웨이에 대해 시간당 요금을 지불하기 때문에 비용이 많이 들 수 있습니다([Amazon VPC 요금](https://aws.amazon.com/vpc/pricing/) 참조). NAT 게이트웨이를 중앙 집중화하는 것은 비용을 절감하는 실행 가능한 옵션일 수 있습니다. 중앙 집중화하려면 다음 그림과 같이 네트워크 서비스 계정에서 별도의 송신 VPC를 생성하고, 송신 VPC에 NAT 게이트웨이를 배포하고, 모든 송신 트래픽을 Transit Gateway 또는 CloudWAN을 사용하여 스포크 VPCs에서 송신 VPC에 있는 NAT 게이트웨이로 라우팅합니다.
**참고**
Transit Gateway를 사용하여 NAT 게이트웨이를 중앙 집중화하면 모든 VPC에서 NAT 게이트웨이를 실행하는 분산형 접근 방식에 비해 추가 Transit Gateway 데이터 처리 요금이 부과됩니다. VPC에서 NAT 게이트웨이를 통해 방대한 양의 데이터를 전송하는 일부 엣지의 경우 전송 게이트웨이 데이터 처리 요금을 방지하기 위해 NAT를 VPC에 로컬로 유지하는 것이 더 비용 효율적인 옵션일 수 있습니다.
![\[분산된 고가용성 NAT 게이트웨이 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/decentralized-ha-nat-gateway.png)
![\[Transit Gateway를 사용하는 중앙 집중식 NAT 게이트웨이를 보여주는 다이어그램(개요)\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-nat-gateway-tg.png)
![\[Transit Gateway를 사용하는 중앙 집중식 NAT 게이트웨이를 보여주는 다이어그램(라우팅 테이블 설계)\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/nat-gateway-tg-rt.png)
이 설정에서 스포크 VPC 연결은 라우팅 테이블 1(RT1)과 연결되고 라우팅 테이블 2(RT2)로 전파됩니다. 두 VPC가 서로 통신하지 못하도록 하는 [블랙홀](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) 경로가 있습니다. VPCs VPC 간 통신을 허용하려면 RT1에서 `10.0.0.0/8 -> Blackhole` 라우팅 항목을 제거할 수 있습니다. 이렇게 하면 전송 게이트웨이를 통해 통신할 수 있습니다. 또한 스포크 VPC 연결을 RT1에 전파할 수 있으며(또는 하나의 라우팅 테이블을 사용하고 모든 것을 여기에 연결/ 전파할 수 있음), Transit Gateway를 사용하여 VPCs 간에 직접 트래픽 흐름을 활성화할 수 있습니다.
모든 트래픽이 송신 VPC를 가리키도록 RT1에 정적 경로를 추가합니다. 이 정적 경로로 인해 Transit Gateway는 송신 VPC의 ENIs를 통해 모든 인터넷 트래픽을 전송합니다. 송신 VPC에 들어오면 트래픽은 이러한 Transit Gateway ENIs가 있는 서브넷 라우팅 테이블에 정의된 경로를 따릅니다. 서브넷 라우팅 테이블에 모든 트래픽이 동일한 가용 영역의 각 NAT 게이트웨이를 가리키는 경로를 추가하여 교차 가용 영역(AZ) 트래픽을 최소화합니다. NAT 게이트웨이 서브넷 라우팅 테이블에는 다음 홉으로 인터넷 게이트웨이(IGW)가 있습니다. 반환 트래픽이 다시 흐르도록 하려면 모든 스포크 VPC 바인딩 트래픽을 Transit Gateway로 다음 홉으로 가리키는 고정 라우팅 테이블 항목을 NAT 게이트웨이 서브넷 라우팅 테이블에 추가해야 합니다.
## 높은 가용성
고가용성을 위해서는 둘 이상의 NAT 게이트웨이(각 가용 영역에 하나씩)를 사용해야 합니다. NAT 게이트웨이를 사용할 수 없는 경우 영향을 받는 NAT 게이트웨이를 통과하는 해당 가용 영역에서 트래픽이 삭제될 수 있습니다. 한 가용 영역을 사용할 수 없는 경우 해당 가용 영역의 NAT 게이트웨이와 함께 Transit Gateway 엔드포인트가 실패하고 모든 트래픽이 다른 가용 영역의 Transit Gateway 및 NAT 게이트웨이 엔드포인트를 통해 흐릅니다.
## 보안
원본 인스턴스의 보안 그룹, Transit Gateway 라우팅 테이블의 블랙홀 경로, NAT 게이트웨이가 위치한 서브넷의 네트워크 ACL에 의존할 수 있습니다. 예를 들어 고객은 NAT Gateway 퍼블릭 서브넷(들)의 ACLs 사용하여 소스 또는 대상 IP 주소를 허용하거나 차단할 수 있습니다. 또는이 요구 사항을 충족하기 AWS Network Firewall 위해 다음 섹션에 설명된 중앙 집중식 송신에 NAT Gateway를와 함께 사용할 수 있습니다.
## 확장성
단일 NAT 게이트웨이는 각 고유 대상에 할당된 IP 주소당 최대 55,000개의 동시 연결을 지원할 수 있습니다. 할당량 조정을 요청하여 최대 8개의 할당된 IP 주소를 허용하여 단일 대상 IP 및 포트에 440,000개의 동시 연결을 허용할 수 있습니다. NAT 게이트웨이는 5Gbps의 대역폭을 제공하고 100Gbps로 자동 확장됩니다. Transit Gateway는 일반적으로 로드 밸런서 역할을 하지 않으며 여러 가용 영역의 NAT 게이트웨이 간에 트래픽을 균등하게 분산하지 않습니다. Transit Gateway를 통한 트래픽은 가능한 경우 가용 영역 내에 유지됩니다. 트래픽을 시작하는 Amazon EC2 인스턴스가 가용 영역 1에 있는 경우 트래픽은 송신 VPC의 동일한 가용 영역 1에 있는 Transit Gateway 탄력적 네트워크 인터페이스에서 흐르고 탄력적 네트워크 인터페이스가 있는 서브넷 라우팅 테이블에 따라 다음 홉으로 흐릅니다. 전체 규칙 목록은 Amazon Virtual Private Cloud 설명서의 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)를 참조하세요.
자세한 내용은 [ AWS Transit Gateway를 사용하여 여러 VPCs](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/).
# 중앙 집중식 IPv4 송신을 AWS Network Firewall 위해에서 NAT 게이트웨이 사용
아웃바운드 트래픽을 검사하고 필터링하려면 중앙 집중식 송신 아키텍처에 AWS Network Firewall을 NAT 게이트웨이와 통합할 수 있습니다. AWS Network Firewall 는 모든 VPCs. 전체 VPC에 대한 계층 3-7 네트워크 트래픽에 대한 제어 및 가시성을 제공합니다. URL/도메인 이름, IP 주소 및 콘텐츠 기반 아웃바운드 트래픽 필터링을 수행하여 가능한 데이터 손실을 중지하고, 규정 준수 요구 사항을 충족하고, 알려진 맬웨어 통신을 차단할 수 있습니다.는 알려진 잘못된 IP 주소 또는 잘못된 도메인 이름으로 향하는 네트워크 트래픽을 필터링할 수 있는 수천 개의 규칙을 AWS Network Firewall 지원합니다. 또한 오픈 소스 규칙 세트를 가져오거나 Suricata 규칙 구문을 사용하여 자체 침입 방지 시스템(IPS) 규칙을 작성하여 AWS Network Firewall 서비스의 일부로 Suricata IPS 규칙을 사용할 수 있습니다. AWS Network Firewall 또한 AWS 파트너에서 제공하는 호환 규칙을 가져올 수 있습니다.
검사가 포함된 중앙 집중식 송신 아키텍처에서 AWS Network Firewall 엔드포인트는 송신 VPC의 전송 게이트웨이 연결 서브넷 라우팅 테이블의 기본 라우팅 테이블 대상입니다. 스포크 VPCs와 인터넷 간의 트래픽은 다음 다이어그램과 AWS Network Firewall 같이를 사용하여 검사합니다.
![\[AWS Network Firewall 및 NAT 게이트웨이를 사용한 중앙 집중식 송신을 보여주는 다이어그램(라우팅 테이블 설계)\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-rt.png)
Transit Gateway를 사용하는 중앙 집중식 배포 모델의 경우 AWS는 여러 가용 영역에 엔드포인트를 AWS Network Firewall 배포할 것을 권장합니다. 이전 다이어그램과 같이 고객이 워크로드를 실행 중인 각 가용 영역에 방화벽 엔드포인트가 하나 있어야 합니다. 는 방화벽 서브넷 내의 소스 또는 대상에서 오는 트래픽을 검사할 수 없으므로 방화벽 서브넷 AWS Network Firewall 에는 다른 트래픽이 포함되어서는 안 됩니다.
이전 설정과 마찬가지로 스포크 VPC 연결은 Route Table 1(RT1)과 연결되며 Route Table 2(RT2)로 전파됩니다. 블랙홀 경로는 두 VPCs가 서로 통신할 수 없도록 명시적으로 추가됩니다.
RT1에서 모든 트래픽이 외부 VPC를 가리키는 기본 경로를 계속 사용합니다. Transit Gateway는 모든 트래픽 흐름을 송신 VPC의 두 가용 영역 중 하나로 전달합니다. 트래픽이 송신 VPC의 전송 게이트웨이 ENIs 중 하나에 도달하면 해당 가용 영역의 AWS Network Firewall 엔드포인트 중 하나로 트래픽을 전달하는 기본 경로에 도달합니다. AWS Network Firewall 그러면는 기본 경로를 사용하여 NAT 게이트웨이로 트래픽을 전달하기 전에 설정한 규칙에 따라 트래픽을 검사합니다.
이 경우 연결 간에 트래픽을 전송하지 않으므로 Transit Gateway 어플라이언스 모드가 필요하지 않습니다.
**참고**
AWS Network Firewall 는 네트워크 주소 변환을 수행하지 않습니다.이 함수는를 통한 트래픽 검사 후 NAT 게이트웨이에서 처리됩니다 AWS Network Firewall. 반환 트래픽은 기본적으로 NATGW IPs로 전달되므로이 경우에는 수신 라우팅이 필요하지 않습니다.
Transit Gateway를 사용하므로 여기에서 NAT 게이트웨이 앞에 방화벽을 배치할 수 있습니다. 이 모델에서 방화벽은 Transit Gateway 뒤의 소스 IP를 볼 수 있습니다.
단일 VPC에서이 작업을 수행하는 경우 동일한 VPC의 서브넷 간 트래픽을 검사할 수 있는 VPC 라우팅 개선 사항을 사용할 수 있습니다. 자세한 내용은 [VPC 라우팅 개선 사항이 AWS Network Firewall 포함된의 배포 모델 블로그 게시물을 참조하세요](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/).
## 확장성
AWS Network Firewall 는 트래픽 부하에 따라 방화벽 용량을 자동으로 확장하거나 축소하여 안정적이고 예측 가능한 성능을 유지하여 비용을 최소화할 수 있습니다. AWS Network Firewall 는 수만 개의 방화벽 규칙을 지원하도록 설계되었으며 가용 영역당 최대 100Gbps 처리량까지 확장할 수 있습니다.
## 주요 고려 사항
+ 각 방화벽 엔드포인트는 약 100Gbps의 트래픽을 처리할 수 있습니다. 더 높은 버스트 또는 지속적인 처리량이 필요한 경우 [AWS 지원팀](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html)에 문의하십시오.
+ Network Firewall과 함께 AWS 계정에 NAT 게이트웨이를 생성하도록 선택하면 표준 NAT 게이트웨이 처리 및 시간당 사용 [요금이](https://aws.amazon.com/network-firewall/pricing/) 방화벽에 대해 청구되는 GB당 처리 및 사용 시간과 함께 one-to-one로 면제됩니다.
+ Transit Gateway AWS Firewall Manager 없이를 통해 분산 방화벽 엔드포인트를 고려할 수도 있습니다.
+ 순서에 따라 네트워크 액세스 제어 목록과 마찬가지로 방화벽 규칙을 프로덕션으로 이동하기 전에 테스트합니다.
+ 심층 검사를 위해서는 고급 Suricata 규칙이 필요합니다. 네트워크 방화벽은 수신 및 송신 트래픽에 대해 암호화된 트래픽 검사를 지원합니다.
+ `HOME_NET` 규칙 그룹 변수는 상태 저장 엔진에서 처리할 수 있는 소스 IP 범위를 정의했습니다. 접근한 중앙 집중식를 사용하여 Transit Gateway에 연결된 모든 VPC CIDRs을 추가해야 처리할 수 있습니다. `HOME_NET` 규칙 그룹 변수에 대한 자세한 내용은 [Network Firewall 설명서를](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html) 참조하세요.
+ Transit Gateway 및 송신 VPC를 별도의 Network Services 계정에 배포하여 업무 위임에 따라 액세스를 분리하는 것이 좋습니다. 예를 들어 네트워크 관리자만 Network Services 계정에 액세스할 수 있습니다.
+ AWS Network Firewall 이 모델에서의 배포 및 관리를 간소화하기 위해를 사용할 수 AWS Firewall Manager 있습니다. Firewall Manager를 사용하면 중앙 위치에서 생성한 보호를 여러 계정에 자동으로 적용하여 다양한 방화벽을 중앙에서 관리할 수 있습니다. Firewall Manager는 Network Firewall에 대한 분산 배포 모델과 중앙 집중식 배포 모델을 모두 지원합니다. 자세한 내용은 블로그 게시물 [How to deploy AWS Network Firewall by using AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/)를 참조하세요.
# 중앙 집중식 IPv4 송신을 위해 Amazon EC2 인스턴스와 함께 NAT 게이트웨이 및 Gateway Load Balancer 사용
AWS Marketplace 및의 소프트웨어 기반 가상 어플라이언스(Amazon EC2)를 종료점 AWS Partner Network 으로 사용하는 것은 NAT 게이트웨이 설정과 유사합니다. 이 옵션은 고급 계층 7 방화벽/침입 방지/감지 시스템(IPS/IDS)과 다양한 공급업체 제품의 심층 패킷 검사 기능을 사용하려는 경우에 사용할 수 있습니다.
다음 그림에서는 NAT 게이트웨이 외에도 Gateway Load Balancer(GWLB) 뒤에 있는 EC2 인스턴스를 사용하여 가상 어플라이언스를 배포합니다. 이 설정에서 GWLB, Gateway Load Balancer 엔드포인트(GWLBE), 가상 어플라이언스 및 NAT 게이트웨이는 VPC 연결을 사용하여 Transit Gateway에 연결된 중앙 집중식 VPC에 배포됩니다. 스포크 VPCs는 VPC 연결을 사용하여 Transit Gateway에도 연결됩니다. GWLBEs 라우팅 가능한 대상이므로 Transit Gateway에서 GWLB 뒤의 대상으로 구성된 가상 어플라이언스 플릿으로 이동하는 트래픽을 라우팅할 수 있습니다. GWLB는 bump-in-the-wire 역할을 하며 모든 계층 3 트래픽을 타사 가상 어플라이언스를 통해 투명하게 전달하므로 트래픽의 소스 및 대상에 보이지 않습니다. 따라서이 아키텍처를 사용하면 Transit Gateway를 통해 통과하는 모든 송신 트래픽을 중앙에서 검사할 수 있습니다.
트래픽이 VPCs으로 흐르고이 설정을 통해 다시 흐르는 방법에 대한 자세한 내용은 [AWS Gateway Load Balancer 및를 사용하는 중앙 집중식 검사 아키텍처 AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)를 참조하세요.
Transit Gateway에서 어플라이언스 모드를 활성화하여 가상 어플라이언스를 통해 흐름 대칭을 유지할 수 있습니다. 즉, 양방향 트래픽은 흐름 수명 동안 동일한 어플라이언스와 가용 영역을 통해 라우팅됩니다. 이 설정은 심층 패킷 검사를 수행하는 상태 저장 방화벽에 특히 중요합니다. 어플라이언스 모드를 활성화하면 대칭을 유지하기 위해 트래픽이 올바른 어플라이언스로 돌아가도록 하는 소스 네트워크 주소 변환(SNAT)과 같은 복잡한 해결 방법이 필요하지 않습니다. 자세한 내용은 [Gateway Load Balancer 배포 모범 사례를](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) 참조하세요.
송신 검사를 활성화하기 위해 Transit Gateway 없이 분산 방식으로 GWLB 엔드포인트를 배포할 수도 있습니다. [AWS Gateway Load Balancer 소개: 지원되는 아키텍처 패턴 블로그 게시물에서이 아키텍처 패턴](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/)에 대해 자세히 알아보세요.
![\[Gateway Load Balancer 및 EC2 인스턴스를 사용한 중앙 집중식 송신을 보여주는 다이어그램(라우팅 테이블 설계)\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-gwlb-and-ec2.png)
## 높은 가용성
AWS는 가용성을 높이기 위해 Gateway Load Balancer 및 가상 어플라이언스를 여러 가용 영역에 배포할 것을 권장합니다.
Gateway Load Balancer는 상태 확인을 수행하여 가상 어플라이언스 장애를 감지할 수 있습니다. 비정상 어플라이언스의 경우 GWLB는 새 흐름을 정상 어플라이언스로 다시 라우팅합니다. 기존 흐름은 대상의 상태에 관계없이 항상 동일한 대상으로 이동합니다. 이렇게 하면 연결 드레이닝이 가능하고 어플라이언스의 CPU 급증으로 인한 상태 확인 실패를 수용할 수 있습니다. 자세한 내용은 블로그 게시물 [Gateway Load Balancer 배포 모범 사례의 섹션 4: 어플라이언스 및 가용 영역 장애 시나리오 이해를 참조하세요](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/). Gateway Load Balancer는 Auto Scaling 그룹을 대상으로 사용할 수 있습니다. 이 이점은 어플라이언스 플릿의 가용성과 확장성을 관리하는 데 따른 부담을 덜어줍니다.
## 장점
Gateway Load Balancer 및 Gateway Load Balancer 엔드포인트는 로 구동 AWS PrivateLink되므로 퍼블릭 인터넷을 통과할 필요 없이 VPC 경계 간 트래픽을 안전하게 교환할 수 있습니다.
Gateway Load Balancer는 가상 보안 어플라이언스의 관리, 배포, 확장에 대한 차별화되지 않은 부담을 제거하여 중요한 사항에 집중할 수 있도록 하는 관리형 서비스입니다. Gateway Load Balancer는 고객이를 사용하여 구독할 수 있도록 방화벽 스택을 엔드포인트 서비스로 노출할 수 있습니다[AWS Marketplace](https://aws.amazon.com/marketplace). 이를 서비스형 방화벽(FWaaS)이라고 하며, 간소화된 배포를 도입하고 BGP 및 ECMP를 사용하여 여러 Amazon EC2 인스턴스에 트래픽을 분산할 필요가 없습니다.
## 주요 고려 사항
+ 어플라이언스는 GWLB와 통합하려면 [Geneve](https://datatracker.ietf.org/doc/html/rfc8926) 캡슐화 프로토콜을 지원해야 합니다.
+ 일부 타사 어플라이언스는 SNAT 및 오버레이 라우팅([2암 모드](https://networkgeekstuff.com/networking/basic-load-balancer-scenarios-explained/))을 지원할 수 있으므로 비용 절감을 위해 NAT 게이트웨이를 생성할 필요가 없습니다. 그러나이 모드는 공급업체 지원 및 구현에 따라 달라지므로이 모드를 사용하기 전에 원하는 AWS 파트너에게 문의하세요.
+ [GWLB 유휴 제한 시간을](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#idle-timeout) 기록해 둡니다. 이로 인해 클라이언트에 연결 제한 시간이 발생할 수 있습니다. 클라이언트, 서버, 방화벽 및 OS 수준에서 제한 시간을 조정하여 이를 방지할 수 있습니다. 자세한 내용은 [Gateway Load Balancer 배포 모범 사례](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) 블로그 게시물의 *섹션 1: TCP 연결 유지 또는 제한 시간 값 조정*을 참조하세요.
+ GWLBE는 로 구동 AWS PrivateLink되므로 AWS PrivateLink 요금이 적용됩니다. [AWS PrivateLink 요금 페이지에서](https://aws.amazon.com/privatelink/pricing/) 자세히 알아볼 수 있습니다. Transit Gateway에서 중앙 집중식 모델을 사용하는 경우 TGW 데이터 처리 요금이 적용됩니다.
+ 네트워크 관리자만 Network Services 계정에 액세스할 수 있는 것과 같이 별도의 Network Services 계정에 Transit Gateway 및 송신 VPC를 배포하여 업무 위임에 따라 액세스를 분리하는 것이 좋습니다.
# IPv6에 대한 중앙 집중식 송신
중앙 집중식 IPv4 송신이 있는 듀얼 스택 배포에서 IPv6 송신을 지원하려면 다음 두 패턴 중 하나를 선택해야 합니다. IPv4
+ 분산형 IPv6 송신을 사용하는 중앙 집중식 IPv4 송신 IPv6
+ 중앙 집중식 IPv4 송신 및 중앙 집중식 IPv6 송신
다음 다이어그램에 표시된 첫 번째 패턴에서는 외부 전용 인터넷 게이트웨이가 각 스포크 VPC에 배포됩니다. 송신 전용 인터넷 게이트웨이는 수평적으로 확장되고 중복되며 가용성이 높은 게이트웨이로, VPC 내의 인스턴스에서 IPv6를 통한 아웃바운드 통신을 허용합니다. 인터넷이 인스턴스와 IPv6 연결을 시작하는 것을 방지합니다. 송신 전용 인터넷 게이트웨이에는 요금이 부과되지 않습니다. 이 배포 모델에서 IPv6 트래픽은 각 VPC의 외부 전용 인터넷 게이트웨이에서 흐르고, IPv4 트래픽은 배포된 중앙 집중식 NAT 게이트웨이를 통해 흐릅니다.
![\[중앙 집중식 IPV4 송신 및 분산형 아웃바운드 전용 IPv6 송신을 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-egress-and-decentralized-outbound-ipv6.png)
다음 다이어그램에 표시된 두 번째 패턴에서는 인스턴스의 송신 IPv6 트래픽이 중앙 집중식 VPC로 전송됩니다. 이는 NATIPv6-to-IPv66 네트워크 접두사 변환(NPTv6)을 사용하거나 프록시 인스턴스 및 Network Load Balancer를 사용하여 수행할 수 있습니다. NAT66 이 패턴은 아웃바운드 트래픽에 대한 중앙 집중식 트래픽 검사가 필요하고 각 스포크 VPC에서 수행할 수 없는 경우에 적용됩니다.
![\[NAT 게이트웨이 및 NAT66 인스턴스를 사용한 중앙 집중식 IPv6 송신을 보여주는 다이어그램입니다. NAT66\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv6-egress-using-nat-gateways.png)
![\[프록시 인스턴스 및 Network Load Balancer를 사용하여 중앙 집중식 IPv4 및 IPv6 송신을 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-and-ipv6-egress.png)
[AWS의 IPv6 백서](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/advanced-dual-stack-and-ipv6-only-network-designs.html)에서는 중앙 집중식 IPv6 송신 패턴을 설명합니다. IPv6 송신 패턴은 특별한 고려 사항, 샘플 솔루션 및 다이어그램과 함께 [듀얼 스택 IPv4 및 IPv6 VPCs에 대한 중앙 집중식 아웃바운드 인터넷 트래픽](https://aws.amazon.com/blogs/networking-and-content-delivery/centralizing-outbound-internet-traffic-for-dual-stack-ipv4-and-ipv6-vpcs/) 블로그에서 자세히 설명합니다.