기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# VPC와 VPC 연결
고객은 두 가지 VPC 연결 패턴을 사용하여 다중 VPC 환경을 설정할 수 있습니다. *하나는 다대다*, 다른 하나는 *허브 및 스포크*입니다. many-to-many 접근 방식에서는 각 VPC 간의 트래픽이 각 VPC 간에 개별적으로 관리됩니다. hub-and-spoke 모델에서는 모든 VPC 간 트래픽이 중앙 리소스를 통해 흐르며, 중앙 리소스는 설정된 규칙에 따라 트래픽을 라우팅합니다.
# VPC 피어링
두 VPCs 것입니다. 이 설정에서 연결은 VPCs 간의 전체 양방향 연결을 활성화합니다.이 피어링 연결은 VPCs 간의 트래픽을 라우팅하는 데 사용됩니다. 다른 계정과 AWS 리전의 VPCs도 함께 피어링할 수 있습니다. 가용 영역 내에 유지되는 VPC 피어링 연결을 통한 모든 데이터 전송은 무료입니다. 가용 영역을 통과하는 VPC 피어링 연결을 통한 모든 데이터 전송에는 표준 리전 내 데이터 전송 요금이 부과됩니다. VPCs 리전 간에 피어링되는 경우 표준 리전 간 데이터 전송 요금이 적용됩니다.
VPC 피어링은 point-to-point 연결이며 [전이적 라우팅](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#transitive-peering)을 지원하지 않습니다. 예를 들어 [VPC A와 VPC B 간에 그리고 VPC A와 VPC C 간에 VPC 피어링](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) 연결이 있는 경우 VPC B의 인스턴스는 VPC A를 통해 VPC C에 도달할 수 없습니다. VPC B와 VPC C 간에 패킷을 라우팅하려면 직접 VPC 피어링 연결을 생성해야 합니다.
규모에 따라 수십 또는 수백 개의 VPCs가 있는 경우 이를 피어링과 상호 연결하면 수백 또는 수천 개의 피어링 연결 메시가 발생할 수 있습니다. 많은 수의 연결을 관리하고 확장하기 어려울 수 있습니다. 예를 들어 VPCs이고 그 사이에 전체 메시 피어링을 설정하려는 경우 4,950개의 피어링 연결[`n(n-1)/2`]이 필요합니다. 여기서 `n`는 총 VPCs. VPC당 최대 125개의 활성 피어링 연결 [제한이](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html) 있습니다.
![\[VPC 피어링을 사용한 네트워크 설정을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/network-setup-vpc-peering.png)
VPC 피어링을 사용하는 경우 각 VPC에 온프레미스 연결(VPN 및/또는 Direct Connect)을 수행해야 합니다. 이전 그림과 같이 VPC의 리소스는 피어링된 VPC의 하이브리드 연결을 사용하여 온프레미스에 연결할 수 없습니다.
VPC 피어링은 한 VPC의 리소스가 다른 VPC의 리소스와 통신해야 하고, 두 VPCs의 환경이 모두 제어 및 보호되며, 연결할 VPCs 수가 10개 미만인 경우(각 연결의 개별 관리를 허용하기 위해) 가장 적합합니다. VPC 피어링은 다른 VPC 간 연결 옵션과 비교할 때 가장 낮은 전체 비용과 가장 높은 집계 성능을 제공합니다.
# AWS Transit Gateway
[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)는 타사 가상 어플라이언스를 프로비저닝할 필요 없이 VPCs와 온프레미스 네트워크를 완전 관리형 서비스로 연결하기 위한 허브 및 스포크 설계를 제공합니다. VPN 오버레이가 필요하지 않으며 고가용성 및 확장성을 AWS 관리합니다.
Transit Gateway를 사용하면 고객이 수천 개의 VPCs. 모든 하이브리드 연결(VPN 및 Direct Connect 연결)을 단일 게이트웨이에 연결하여 조직의 전체 AWS 라우팅 구성을 한 곳에서 통합하고 제어할 수 있습니다(다음 그림 참조). Transit Gateway는 라우팅 테이블을 사용하여 연결된 모든 스포크 네트워크 간에 트래픽이 라우팅되는 방식을 제어합니다. 이 hub-and-spoke 모델은 VPCs Transit Gateway 인스턴스에만 연결하여 연결된 네트워크에 액세스하기 때문에 관리를 간소화하고 운영 비용을 절감합니다.
![\[를 사용한 허브 및 스포크 설계를 보여주는 다이어그램 AWS Transit Gateway\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/hub-and-spoke-design.png)
Transit Gateway는 리전 리소스이며 동일한 내에서 수천 개의 VPCs를 연결할 수 있습니다 AWS 리전. 하이브리드 연결을 위해 단일 Direct Connect 연결을 통해 여러 게이트웨이를 연결할 수 있습니다. 일반적으로 지정된 리전의 모든 VPC 인스턴스를 연결하는 Transit Gateway 인스턴스를 하나만 사용할 수 있으며 Transit Gateway 라우팅 테이블을 사용하여 필요할 때마다 격리할 수 있습니다. Transit Gateway는 설계상 가용성이 높기 때문에 고가용성을 위해 추가 Transit Gateway가 필요하지 않습니다. 중복성을 위해 각 리전에서 단일 게이트웨이를 사용합니다. 그러나 잘못된 구성 블래스트 반경을 제한하고, 컨트롤 플레인 작업을 분리하며, 관리 ease-of-use 위해 여러 게이트웨이를 생성하는 유효한 사례가 있습니다.
Transit Gateway 피어링을 사용하면 고객은 동일하거나 여러 리전 내에서 Transit Gateway 인스턴스를 피어링하고 이들 간에 트래픽을 라우팅할 수 있습니다. VPC 피어링과 동일한 기본 인프라를 사용하므로 암호화됩니다. 자세한 내용은 [ AWS Transit Gateway 리전 간 피어링을 사용하여 글로벌 네트워크 구축](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-global-network-using-aws-transit-gateway-inter-region-peering/)을 참조하세요. [이제 AWS Transit Gateway가 리전 내 피어링을 지원합니다](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-transit-gateway-now-supports-intra-region-peering/).
조직의 Transit Gateway 인스턴스를 Network Services 계정에 배치합니다. 이를 통해 네트워크 서비스 계정을 관리하는 네트워크 엔지니어가 중앙 집중식으로 관리할 수 있습니다. Resource Access Manager(RAM)를 사용하여 AWS 동일한 리전 내 AWS Organization의 여러 계정에 걸쳐 VPCs를 연결하기 위한 Transit Gateway 인스턴스를 공유합니다.를AWS RAM 사용하면 리소스를 AWS Organization 내 AWS 계정또는 모든 AWS 와 쉽고 안전하게 공유할 수 있습니다. 자세한 내용은 [중앙 계정 블로그 게시물의 전송 게이트웨이에 대한 AWS Transit Gateway 연결 자동화를](https://aws.amazon.com/blogs/networking-and-content-delivery/automating-aws-transit-gateway-attachments-to-a-transit-gateway-in-a-central-account/) 참조하세요.
또한 Transit Gateway를 사용하면 Transit Gateway Connect를 사용하여 SD-WAN 인프라와 AWS 간에 연결을 설정할 수 있습니다. Transit Gateway Connect 연결은 동적 라우팅을 위한 BGP(Border Gateway Protocol)와 고성능을 위한 GRE(일반 라우팅 캡슐화) 터널 프로토콜을 함께 사용하여 Connect 연결당 최대 20Gbps의 총 대역폭을 제공합니다(Connect 연결당 최대 4개의 Transit Gateway Connect 피어). Transit Gateway Connect를 사용하면 VPC 연결 또는 연결을 통해 클라우드에서 실행되는 온프레미스 SD-WAN 인프라 또는 Direct Connect SD-WAN 어플라이언스를 기본 전송 계층으로 통합할 수 있습니다. 참조 아키텍처 및 자세한 구성은 [AWS Transit Gateway Connect를 사용한 SD-WAN 연결 간소화](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/)를 참조하세요.
# Transit VPC 솔루션
[전송 VPCs](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) VPCs 간 연결을 위한 허브 및 스포크 설계를 도입하여 VPC 피어링과 다른 방식으로 VPC 간에 연결을 생성할 수 있습니다. 전송 VPC 네트워크에서 하나의 중앙 VPC(허브 VPC)는 일반적으로 [IPsec](https://en.wikipedia.org/wiki/IPsec)을 통한 BGP를 활용하는 VPN 연결을 통해 다른 모든 VPC(스포크 VPC)와 연결됩니다. 중앙 VPC에는 VPN 오버레이를 사용하여 수신 트래픽을 대상으로 라우팅하는 소프트웨어 어플라이언스를 실행하는 [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/)(Amazon EC2) 인스턴스가 포함되어 있습니다. Transit VPC 피어링의 장점은 다음과 같습니다.
+ 전이적 라우팅은 오버레이 VPN 네트워크를 사용하여 활성화되어 허브 및 스포크 설계를 허용합니다.
+ 허브 전송 VPC의 EC2 인스턴스에서 타사 공급업체 소프트웨어를 사용하는 경우 고급 보안(계층 7 방화벽/침입 방지 시스템(IPS)/침입 감지 시스템(IDS))과 관련된 공급업체 기능을 사용할 수 있습니다. 고객이 온프레미스에서 동일한 소프트웨어를 사용하는 경우 통합 운영/모니터링 환경의 이점을 누릴 수 있습니다.
+ Transit VPC 아키텍처는 일부 사용 사례에서 필요할 수 있는 연결을 활성화합니다. 예를 들어 AWS GovCloud 인스턴스와 상용 리전 VPC 또는 Transit Gateway 인스턴스를 Transit VPC에 연결하고 두 리전 간에 VPC 간 연결을 활성화할 수 있습니다. 이 옵션을 고려할 때 보안 및 규정 준수 요구 사항을 평가합니다. 보안을 강화하기 위해이 백서의 뒷부분에 설명된 설계 패턴을 사용하여 중앙 집중식 검사 모델을 배포할 수 있습니다.
![\[가상 어플라이언스를 사용하는 전송 VPC를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/transit-vpc-virtual-appliances.png)
Transit VPC에는 인스턴스 크기/계열에 따라 EC2에서 타사 공급업체 가상 어플라이언스를 실행하는 데 드는 비용 증가, VPN 연결당 제한된 처리량(VPN 터널당 최대 1.25Gbps), 추가 구성, 관리 및 복원력 오버헤드(고객은 타사 공급업체 가상 어플라이언스를 실행하는 EC2 인스턴스의 HA 및 중복성을 관리할 책임이 있음)와 같은 자체적인 문제가 있습니다.
## VPC 피어링과 Transit VPC 및 Transit Gateway 비교
*표 1 - 연결 비교*
| 기준 | VPC 피어링 | 전송 VPC | 전송 게이트웨이 | PrivateLink | 클라우드 WAN | VPC Lattice |
| --- | --- | --- | --- | --- | --- | --- |
| 범위 | 리전/글로벌 | 리전 | 리전 | 리전 | 전 세계 | 리전 |
| 아키텍처 | 전체 메시 | VPN 기반 hub-and-spoke | 첨부 파일 기반 hub-and-spoke | 공급자 또는 소비자 모델 | 첨부 파일 기반, 다중 리전 | 앱 간 연결 |
| Scale | 활성 피어/VPC 125개 | 가상 라우터/EC2에 따라 다름 | 리전당 첨부 파일 5,000개 | 제한 없음 | 코어 네트워크당 5,000개의 연결 | 서비스당 VPC 연결 500개 |
| Segmentation | 보안 그룹 | 고객 관리형 | Transit Gateway 라우팅 테이블 | 분할 없음 | Segments | 서비스 및 서비스 네트워크 정책 |
| 지연 시간 | 가장 낮음 | VPN 암호화 오버헤드로 인한 추가 항목 | 추가 Transit Gateway 홉 | 트래픽은 AWS 백본에 유지되므로 고객은 다음을 테스트해야 합니다. | Transit Gateway와 동일한 데이터플레인 사용 | 트래픽은 AWS 백본에 유지되므로 고객은 다음을 테스트해야 합니다. |
| 대역폭 한도 | 인스턴스당 한도, 집계 한도 없음 | 크기/ 패밀리에 따라 EC2 인스턴스 대역폭 제한이 적용됩니다. | 최대 100Gbps(버스트)/연결 | 가용 영역당 10Gbps, 최대 100Gbps까지 자동 확장 | 최대 100Gbps(버스트)/연결 | 가용 영역당 10Gbps |
| 표시 여부 | VPC 흐름 로그 | VPC 흐름 로그 및 CloudWatch 지표 | Transit Gateway Network Manager, VPC 흐름 로그, CloudWatch 지표 | CloudWatch 지표 | Network Manager, VPC 흐름 로그, CloudWatch 지표 | CloudWatch 액세스 로그 |
| 보안 그룹 교차 참조 | 지원 | 지원되지 않음 | 지원되지 않음 | 지원되지 않음 | 지원되지 않음 | 해당 사항 없음 |
| IPv6 지원 | 지원 | 가상 어플라이언스에 따라 다름 | 지원 | 지원 | 지원 | 지원 |
# AWS PrivateLink
[AWS PrivateLink](https://aws.amazon.com/privatelink/)는 트래픽을 퍼블릭 인터넷에 노출하지 않고 VPCs, AWS 서비스 및 온프레미스 네트워크 간에 프라이빗 연결을 제공합니다. 로 구동되는 인터페이스 VPC 엔드포인트를 AWS PrivateLink사용하면 다양한 계정 및 VPCs에서 AWS 및 기타 서비스에 쉽게 연결하여 네트워크 아키텍처를 크게 간소화할 수 있습니다. 이를 통해 한 VPC(서비스 공급자)에 있는 서비스/애플리케이션을의 다른 VPCs(소비자) AWS 리전 에 비공개로 노출하려는 고객은 소비자 VPCs 시작할 수 있습니다. 예를 들어 프라이빗 애플리케이션이 서비스 공급자 APIs.
사용하려면 VPC에서 애플리케이션에 대한 Network Load Balancer AWS PrivateLink를 생성하고 해당 로드 밸런서를 가리키는 VPC 엔드포인트 서비스 구성을 생성합니다. 그런 다음 서비스 소비자가 서비스에 대한 인터페이스 엔드포인트를 생성합니다. 이렇게 하면 서비스를 대상으로 하는 트래픽의 진입점 역할을 하는 프라이빗 IP 주소를 사용하여 소비자 서브넷에 탄력적 네트워크 인터페이스(ENI)가 생성됩니다. 소비자와 서비스가 동일한 VPC에 있을 필요는 없습니다. VPC가 다른 경우 소비자 및 서비스 공급자 VPCs의 IP 주소 범위가 겹칠 수 있습니다. 다음 그림과 같이 인터페이스 VPC 엔드포인트를 생성하여 다른 VPCs의 서비스에 액세스하는 것 외에도 인터페이스 VPC 엔드포인트를 생성하여를 통해 [지원되는 AWS 서비스에](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) 비공개 AWS PrivateLink로 액세스할 수 있습니다.
Application Load Balancer(ALB)를 NLB의 대상으로 사용하면 이제 ALB 고급 라우팅 기능을와 결합할 수 있습니다 AWS PrivateLink. 참조 아키텍처 및 자세한 구성은 [Network Application Load Balancer Load Balancer 유형 대상 그룹을](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/) 참조하세요.
![\[다른 VPCs 및 AWS 서비스에 AWS PrivateLink 대한 연결을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/aws-privatelink.png)
Transit Gateway, VPC 피어링 및 중에서 선택하는 것은 연결에 AWS PrivateLink 따라 달라집니다.
+ **AWS PrivateLink** - 서비스 공급자 VPCs 또는 특정 서비스의 특정 서비스 또는 인스턴스 세트에 대한 하나 이상의 소비자 VPC 단방향 액세스를 허용하려는 클라이언트/서버가 설정된 AWS PrivateLink 경우 사용합니다 AWS . 소비자 VPC에 액세스할 수 있는 클라이언트만 서비스 공급자 VPC 또는 AWS 서비스의 서비스에 대한 연결을 시작할 수 있습니다. 이는 두 VPCs의 클라이언트와 서버에 중복 IP 주소가 있는 경우에도 좋은 옵션입니다.는가 서비스 공급자와 IP 충돌이 없도록 클라이언트 VPC 내에서 ENIs를 AWS PrivateLink 사용하기 때문입니다. VPC 피어링, VPN, Transit Gateway, Cloud WAN 및를 통해 AWS PrivateLink 엔드포인트에 액세스할 수 있습니다 AWS Direct Connect.
+ **VPC 피어링 및 Transit Gateway** - VPC 간에 계층 3 IP 연결을 활성화하려는 경우 VPCs 피어링 및 Transit Gateway를 사용합니다.
아키텍처에는 다양한 사용 사례를 충족하기 위해 이러한 기술이 혼합되어 있습니다. 이러한 모든 서비스를 서로 결합하고 운영할 수 있습니다. 예를 들어, API 스타일 클라이언트-서버 연결 AWS PrivateLink 처리, 리전 내에서 배치 그룹이 계속 필요하거나 리전 간 연결이 필요할 수 있는 직접 연결 요구 사항을 처리하기 위한 VPC 피어링, 대규모 VPCs 연결과 하이브리드 연결을 위한 엣지 통합을 간소화하기 위한 Transit Gateway가 있습니다.
# VPC 공유
VPCs 공유는 VPC 소유자가 팀 간의 네트워크 격리를 엄격하게 관리할 필요가 없지만 계정 수준 사용자 및 권한은 이어야 하는 경우에 유용합니다. [공유 VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)를 사용하면 여러 AWS 계정이 중앙에서 관리하는 공유 Amazon VPCs에서 애플리케이션 리소스(예: Amazon EC2 인스턴스)를 생성합니다. 이 모델에서 VPC(소유자)를 소유한 계정은 하나 이상의 서브넷을 다른 계정(참가자)과 공유합니다. 서브넷을 공유한 후 참여자는 공유된 서브넷의 해당 애플리케이션 리소스를 보고, 생성하고, 수정하고, 삭제할 수 있습니다. 참여자는 다른 참여자 또는 VPC 소유자에 속한 리소스를 보거나 수정하거나 삭제할 수 없습니다. 공유 VPCs의 리소스 간 보안은 보안 그룹, 네트워크 액세스 제어 목록(NACLs)을 사용하거나 서브넷 간의 방화벽을 통해 관리됩니다.
VPC 공유 이점:
+ 간소화된 설계 - VPC 간 연결에 대한 복잡성 없음
+ 관리VPCs 감소
+ 네트워크 팀과 애플리케이션 소유자 간의 업무 분리
+ IPv4 주소 사용률 향상
+ 비용 절감 - 동일한 가용 영역 내의 다른 계정에 속한 인스턴스 간에 데이터 전송 요금이 부과되지 않음
**참고**
서브넷을 여러 계정과 공유하는 경우 참가자는 IP 공간과 네트워크 리소스를 공유하므로 어느 정도 협력해야 합니다. 필요한 경우 각 참가자 계정에 대해 다른 서브넷을 공유하도록 선택할 수 있습니다. 참가자당 서브넷 1개를 사용하면 네트워크 ACL이 보안 그룹 외에도 네트워크 격리를 제공할 수 있습니다.
대부분의 고객 아키텍처에는 여러 VPCs 포함되며, 그 중 다수는 두 개 이상의 계정과 공유됩니다. Transit Gateway 및 VPC 피어링을 사용하여 공유 VPCs. 예를 들어 애플리케이션이 10개라고 가정해 보겠습니다. 각 애플리케이션에는 자체 AWS 계정이 필요합니다. 앱은 두 가지 애플리케이션 포트폴리오로 분류할 수 있습니다(동일한 포트폴리오 내의 앱은 유사한 네트워킹 요구 사항, 즉 '마케팅'의 앱 1\$15와 '판매'의 앱 6\$110으로 분류할 수 있습니다).
애플리케이션 포트폴리오당 하나의 VPC(총 2개의 VPCs)를 가질 수 있으며, VPC는 해당 포트폴리오 내의 다른 애플리케이션 소유자 계정과 공유됩니다. 앱 소유자는 앱을 각 공유 VPC에 배포합니다(이 경우 NACLs). 두 공유 VPCs는 Transit Gateway를 통해 연결됩니다. 이 설정을 사용하면 다음 그림과 같이 10개의 VPCs 할 수 있습니다.
![\[공유 VPC 설정 예제를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-shared-vpc.png)
**참고**
VPC 공유 참가자는 공유 서브넷에 모든 AWS 리소스를 생성할 수 없습니다. 자세한 내용은 VPC 공유 설명서의 [제한 사항](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) 섹션을 참조하세요.
VPC 공유의 주요 고려 사항 및 모범 사례에 대한 자세한 내용은 [VPC 공유: 주요 고려 사항 및 모범 사례](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-key-considerations-and-best-practices/) 블로그 게시물을 참조하세요.
# 프라이빗 NAT 게이트웨이
팀은 종종 독립적으로 작업하며 프로젝트에 대한 새 VPC를 생성할 수 있습니다.이 VPC에는 CIDR(클래스리스 도메인 간 라우팅) 블록이 중복될 수 있습니다. 통합을 위해 VPC 피어링 및 Transit Gateway와 같은 기능을 통해 달성할 수 없는 중복 CIDRs이 있는 네트워크 간 통신을 활성화하려고 할 수 있습니다. 프라이빗 NAT 게이트웨이는이 사용 사례에 도움이 될 수 있습니다. 프라이빗 NAT 게이트웨이는 고유한 프라이빗 IP 주소를 사용하여 겹치는 소스 IP 주소에 대해 소스 NAT를 수행하고 ELB는 겹치는 대상 IP 주소에 대해 대상 NAT를 수행합니다. Transit Gateway 또는 가상 프라이빗 게이트웨이를 사용하여 프라이빗 NAT 게이트웨이에서 다른 VPCs 또는 온프레미스 네트워크로 트래픽을 라우팅할 수 있습니다.
![\[프라이빗 NAT 게이트웨이의 설정 예제를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-private-nat-gateway.png)
위 그림은 VPC A와 B에 있는 라우팅 불가능한(중첩 CIDRs, `100.64.0.0/16`) 서브넷 2개를 보여줍니다. 이들 간에 연결을 설정하려면 VPC A`10.0.1.0/24`와 B에 각각 중복되지 않는/라우팅 가능한 보조 CIDRs(라우팅 가능한 서브넷 및 `10.0.2.0/24`)을 추가할 수 있습니다. 라우팅 가능한 CIDRs은 IP 할당을 담당하는 네트워크 관리 팀에서 할당해야 합니다. 프라이빗 NAT 게이트웨이는 IP 주소가 인 VPC A의 라우팅 가능한 서브넷에 추가됩니다`10.0.1.125`. 프라이빗 NAT 게이트웨이는 VPC A(`100.64.0.10`)의 라우팅할 수 없는 서브넷에 있는 인스턴스의 요청에 대해 프라이빗 NAT 게이트웨이의 ENI`10.0.1.125`인 로 소스 네트워크 주소 변환을 수행합니다. 이제 트래픽은 대상이 인 VPC B()의 Application Load Balancer(ALB`10.0.2.10`)에 할당된 라우팅 가능한 IP 주소를 가리킬 수 있습니다`100.64.0.10`. 트래픽은 Transit Gateway를 통해 라우팅됩니다. 반환 트래픽은 프라이빗 NAT 게이트웨이에서 연결을 요청하는 원래 Amazon EC2 인스턴스로 다시 처리됩니다.
온프레미스 네트워크가 승인된 IPs. 규정 준수에 따라 소수 고객의 온프레미스 네트워크는 고객이 소유한 승인된 IPs의 제한된 연속 블록을 통해서만 프라이빗 네트워크(IGW 없음)와 통신해야 합니다. 각 인스턴스에 블록과 별도의 IP를 할당하는 대신 프라이빗 NAT 게이트웨이를 사용하여 각 허용 목록에 있는 IP 뒤에 AWS VPCs에서 대규모 워크로드를 실행할 수 있습니다. 자세한 내용은 [프라이빗 NAT 솔루션으로 프라이빗 IP 소진을 해결하는 방법](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/) 블로그 게시물을 참조하세요.
![\[프라이빗 NAT 게이트웨이를 사용하여 온프레미스 네트워크에 승인된 IPs를 제공하는 방법을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/how-to-use-nat.png)
# AWS 클라우드 WAN
AWS Cloud WAN은 이전에 Transit Gateway, VPC 피어링 및 IPSEC VPN 터널을 사용하여 수행할 수 있었던 네트워크를 연결하는 새로운 방법입니다. 이전에는 하나 이상의 VPCs를 구성하고, 이전 방법 중 하나와 함께 연결하고, IPSEC VPN 또는 Direct Connect 를 사용하여 온프레미스 네트워크에 연결합니다. 네트워크 및 보안 태세 구성이 한 곳에 정의되어 있고 네트워크가 다른 위치에 정의되어 있어야 합니다. Cloud WAN을 사용하면 이러한 모든 구문을 한 곳에서 중앙 집중화할 수 있습니다. 정책에 따라 네트워크를 세분화하여 누가 누구와 대화할 수 있는지 결정하고 이러한 세그먼트를 통해 개발 또는 테스트 워크로드 또는 온프레미스 네트워크에서 프로덕션 트래픽을 격리할 수 있습니다.
![\[AWS Cloud WAN 연결을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/cloud-wan-diagram.png)
AWS Network Manager 사용자 인터페이스 및 APIs를 통해 글로벌 네트워크를 관리합니다. 글로벌 네트워크는 모든 네트워크 객체의 루트 수준 컨테이너이며, 코어 네트워크는 AWS에서 관리하는 글로벌 네트워크의 일부입니다. 코어 네트워크 정책(CNP)은 코어 네트워크의 모든 측면을 정의하는 단일 버전 정책 문서입니다. 첨부 파일은 코어 네트워크에 추가할 연결 또는 리소스입니다. 코어 네트워크 엣지(CNE)는 정책을 준수하는 연결의 로컬 연결 지점입니다. 네트워크 세그먼트는 기본적으로 세그먼트 내에서만 통신을 허용하는 라우팅 도메인입니다.
CloudWAN을 사용하려면:
1. AWS Network Manager에서 글로벌 네트워크 및 연결된 코어 네트워크를 생성합니다.
1. 세그먼트에 연결하는 데 사용할 세그먼트, ASN 범위 AWS 리전 및 태그를 정의하는 CNP를 생성합니다.
1. 네트워크 정책을 적용합니다.
1. 리소스 액세스 관리자를 사용하여 사용자, 계정 또는 조직과 코어 네트워크를 공유합니다.
1. 첨부 파일을 생성하고 태그를 지정합니다.
1. 코어 네트워크를 포함하도록 연결된 VPCs의 경로를 업데이트합니다.
Cloud WAN은 AWS 인프라를 전 세계에 연결하는 프로세스를 간소화하도록 설계되었습니다. 중앙 집중식 권한 정책을 사용하여 트래픽을 분할하고 회사 위치에서 기존 인프라를 사용할 수 있습니다. 또한 Cloud WAN은 VPCs, SD-WANs, Client VPNs, 방화벽, VPNs 및 데이터 센터 리소스를 연결하여 Cloud WAN에 연결합니다. 자세한 내용은 [AWS Cloud WAN 블로그 게시물을 참조하세요](https://aws.amazon.com/blogs/networking-and-content-delivery/category/networking-content-delivery/aws-cloud-wan/).
AWS Cloud WAN을 사용하면 클라우드 및 온프레미스 환경을 연결하는 통합 네트워크를 사용할 수 있습니다. 조직은 보안을 위해 차세대 방화벽(NGFWs)과 침입 방지 시스템(IPSs 사용합니다. [AWS Cloud WAN 및 Transit Gateway 마이그레이션 및 상호 운용성 패턴](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-cloud-wan-and-aws-transit-gateway-migration-and-interoperability-patterns/) 블로그 게시물은 단일 리전 및 다중 리전 네트워크를 포함하여 클라우드 WAN 네트워크에서 아웃바운드 네트워크 트래픽을 중앙에서 관리하고 검사하기 위한 아키텍처 패턴을 설명하고 라우팅 테이블을 구성합니다. 이러한 아키텍처는 안전한 클라우드 환경을 유지하면서 데이터와 애플리케이션을 안전하게 유지합니다.
Cloud WAN에 대한 자세한 내용은 [AWS Cloud WAN 블로그 게시물의 중앙 집중식 아웃바운드 검사 아키텍처를](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-outbound-inspection-architecture-in-aws-cloud-wan/) 참조하세요.
# Amazon VPC Lattice
Amazon VPC Lattice는 다양한 계정 및 가상 프라이빗 클라우드에서 서비스를 연결, 모니터링 및 보호하는 데 사용되는 완전관리형 애플리케이션 네트워킹 서비스입니다. VPC Lattice는 논리적 경계 내에서 서비스를 상호 연결하여 서비스를 효율적으로 관리하고 검색할 수 있도록 지원합니다.
VPC Lattice 구성 요소는 다음으로 구성됩니다.
+ **서비스** - 인스턴스, 컨테이너 또는 Lambda 함수에서 실행되는 애플리케이션 단위이며 리스너, 규칙 및 대상 그룹으로 구성됩니다.
+ **서비스 네트워크** - 서비스 검색 및 연결을 자동으로 구현하고 서비스 컬렉션에 공통 액세스 및 관찰성 정책을 적용하는 데 사용되는 논리적 경계입니다.
+ **인증 정책** - 요청 수준 인증 및 컨텍스트별 권한 부여를 지원하기 위해 서비스 네트워크 또는 개별 서비스와 연결할 수 있는 IAM 리소스 정책입니다.
+ **서비스 디렉터리** - 사용자가 소유하거나 AWS Resource Access Manager를 통해 사용자와 공유된 서비스에 대한 중앙 집중식 보기입니다.
VPC Lattice 사용 단계:
1. 서비스 네트워크를 생성합니다. 서비스 네트워크는 일반적으로 네트워크 관리자가 전체 액세스 권한을 가진 네트워크 계정에 상주합니다. 서비스 네트워크는 조직 내 여러 계정에서 공유할 수 있습니다. 공유는 개별 서비스 또는 전체 서비스 계정에서 수행할 수 있습니다.
1. VPCs 서비스 네트워크에 연결하여 각 VPC에 대해 애플리케이션 네트워킹을 활성화하면 다양한 서비스가 네트워크 내에 등록된 다른 서비스를 사용하기 시작할 수 있습니다. 보안 그룹은 트래픽을 제어하는 데 적용됩니다.
1. 개발자는 서비스 디렉터리에 채워지고 서비스 네트워크에 등록되는 서비스를 정의합니다. VPC Lattice에는 구성된 모든 서비스의 주소록이 포함되어 있습니다. 개발자는 블루/그린 배포를 사용하도록 라우팅 정책을 정의할 수도 있습니다. 보안은 인증 및 권한 부여 정책이 정의된 서비스 네트워크 수준과 IAM을 사용한 액세스 정책이 구현된 서비스 수준에서 관리됩니다.
![\[VPC Lattice 통신 흐름을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/vpc-lattice.png)
자세한 내용은 [VPC Lattice 사용 설명서](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html )에서 확인할 수 있습니다.