# 일반 VPC 피어링 연결 구성
이 섹션에서는 구현할 수 있는 두 가지 일반적인 유형의 VPC 피어링 구성에 대해 설명합니다.
+ **전체 VPC로 향하는 경로가 포함된 VPC 피어링 구성**: 이 구성에서는 각 VPC의 라우팅 테이블에 경로를 생성하여 피어 VPC로 향하는 모든 트래픽을 VPC 피어링 연결로 보냅니다. 이렇게 하면 한 VPC의 모든 리소스가 피어 VPC의 모든 리소스와 통신할 수 있으므로 관리가 간소화됩니다. 그러나 이는 또한 VPC 간의 모든 트래픽이 피어링 연결을 통해 흐르기 때문에 트래픽이 많으면 병목 현상이 발생할 수 있음을 의미합니다.
+ **특정 경로를 사용한 VPC 피어링 구성**: 또는 각 VPC의 라우팅 테이블에 피어 VPC의 특정 서브넷이나 리소스로만 트래픽을 보내는 세분화된 경로를 만들 수 있습니다. 이렇게 하면 피어링 연결을 통한 트래픽 흐름을 필요한 정도로만 제한할 수 있어 더 효율적일 수 있습니다. 하지만 통신이 필요한 피어 VPC에 새 리소스를 추가할 때마다 라우팅 테이블을 업데이트해야 하므로 유지 관리가 더 필요합니다.
최선의 접근 방식은 VPC 아키텍처의 규모와 복잡성, VPC 간에 예상되는 트래픽의 양, 보안 및 리소스 액세스와 관련된 조직의 요구 사항 등의 요인에 따라 달라집니다. 많은 기업이 일반적인 트래픽 패턴에는 광범위한 경로를 사용하고 더 민감하거나 대역폭 집약적인 사용 사례에는 특정 경로를 사용하는 하이브리드 접근 방식을 취합니다.
**Topics**
+ [전체 VPC에 대한 경로가 있는 VPC 피어링 구성](peering-configurations-full-access.md)
+ [특정 경로로 VPC 피어링 구성](peering-configurations-partial-access.md)
# 전체 VPC에 대한 경로가 있는 VPC 피어링 구성
라우팅 테이블이 피어 VPC의 전체 CIDR 블록에 액세스하도록 VPC 피어링 연결을 구성할 수 있습니다. 특정 VPC 피어링 연결 구성이 필요할 수 있는 시나리오에 대한 자세한 정보는 [VPC 피어링 연결 네트워킹 시나리오](peering-scenarios.md)을(를) 참조하세요. VPC 피어링 연결을 생성하고 사용하는 방법에 대한 자세한 내용은 [VPC 피어링 연결](working-with-vpc-peering.md) 단원을 참조하세요.
라우팅 테이블 업데이트에 대한 자세한 내용은 [VPC 피어링 연결을 위한 라우팅 테이블 업데이트](vpc-peering-routing.md) 단원을 참조하세요.
**Topics**
+ [함께 피어링된 두 개의 VPC](#two-vpcs-full-access)
+ [VPC 두 개와 피어링된 하나의 VPC](#one-to-two-vpcs-full-access)
+ [함께 피어링된 세 개의 VPC](#three-vpcs-full-access)
+ [서로 피어링된 여러 VPC](#many-vpcs-full-access)
## 함께 피어링된 두 개의 VPC
이 구성에서는 VPC A와 VPC B 간에 피어링 연결이 있습니다(`pcx-11112222`). VPC가 동일한 AWS 계정에 있으며 해당 CIDR 블록이 겹치지 않습니다.
![\[함께 피어링된 두 개의 VPC\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/two-vpcs-peered.png)
서로의 리소스가 필요한 2개의 VPC가 있을 때 이 구성을 사용할 수 있습니다. 예를 들어 회계 레코드에 VPC A를 설정하고, 재무 레코드에 VPC B를 설정하면 이러한 각 VPC에서 다른 VPC의 리소스에 제한 없이 액세스하게 할 수 있게 됩니다.
**단일 VPC CIDR**
피어 VPC의 CIDR 블록에 대한 트래픽을 VPC 피어링 연결로 보내는 경로로 각 VPC의 라우팅 테이블을 업데이트합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
**여러 IPv4 VPC CIDR**
VPC A와 VPC B에 IPv4 CIDR 블록이 여러 개 연결되어 있는 경우 피어 VPC의 일부 또는 모든 IPv4 CIDR 블록에 대한 경로로 각 VPC의 라우팅 테이블을 업데이트할 수 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
**IPv4 및 IPv6 VPC CIDR**
연결된 IPv6 CIDR 블록이 VPC A와 VPC B에 있는 경우 피어 VPC의 IPv4 블록과 IPv6 CIDR 블록 둘 다에 대한 경로로 각 VPC의 라우팅 테이블을 업데이트할 수 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
## VPC 두 개와 피어링된 하나의 VPC
이 구성에는 중앙 VPC(VPC A), VPC A와 VPC B 사이의 피어링 연결(`pcx-12121212`) 및 VPC A와 VPC C 사이의 피어링 연결(`pcx-23232323`)이 있습니다. 세 VPC 모두 동일한 AWS 계정에 있으며 해당 CIDR 블록이 겹치지 않습니다.
![\[VPC 두 개와 피어링된 하나의 VPC\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/one-vpc-peered-to-two.png)
VPC는 전이적 피어링 관계가 지원되지 않으므로 VPC B와 VPC C는 허브 VPC를 통해 서로 직접 트래픽을 전송할 수 없습니다. [함께 피어링된 세 개의 VPC](#three-vpcs-full-access)에 표시된 대로 VPC B와 VPC C 사이의 VPC 피어링 연결을 생성할 수 있습니다. 지원되지 않는 피어링 시나리오에 대한 자세한 내용은 [VPC 피어링 제한](vpc-peering-basics.md#vpc-peering-limitations)을 참조하세요.
다른 VPC에서 액세스해야 하는 중앙 VPC(예: 서비스 리포지토리)에 리소스가 있을 때 이 구성을 사용할 수 있습니다. 다른 VPC에서는 서로의 리소스를 액세스할 필요가 없으며 중앙 VPC의 리소스만 액세스하면 됩니다.
VPC당 하나의 CIDR 블록을 사용하여 이 구성을 구현하려면 다음과 같이 각 VPC의 라우팅 테이블을 업데이트합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
이 구성을 추가 VPC로 확장할 수 있습니다. 예를 들어 VPC A는 IPv4 및 IPv6 CIDR를 모두 사용하여 VPC B \$1 VPC G에 피어링되지만, 다른 VPC는 서로 피어링되지 않습니다. 이 다이어그램에서 선은 VPC 피어링 연결을 나타냅니다.
![\[VPC 두 개와 피어링된 하나의 VPC\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/one-to-many-vpcs.png)
다음과 같이 라우팅 테이블을 업데이트합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
## 함께 피어링된 세 개의 VPC
이 구성에서는 동일한 AWS 계정에 겹치지 않는 CIDR 블록이 있는 3개의 VPC가 있습니다. VPC는 다음과 같이 풀 메시로 피어링됩니다.
+ VPC A는 VPC 피어링 연결 `pcx-aaaabbbb`를 통해 VPC B와 피어링됩니다.
+ VPC A는 VPC 피어링 연결 `pcx-aaaacccc`를 통해 VPC C와 피어링됩니다.
+ VPC B는 VPC 피어링 연결 `pcx-bbbbcccc`를 통해 VPC C와 피어링됩니다.
![\[함께 피어링된 세 개의 VPC\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/three-vpcs-peered.png)
리소스를 서로 제한 없이 공유해야 하는 VPC가 있을 때 이 구성을 사용할 수 있습니다. 예를 들어 파일 공유 시스템으로 사용할 수 있습니다.
이 구성을 구현하려면 다음과 같이 각 VPC의 라우팅 테이블을 업데이트합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
VPC A와 VPC B에 IPv4 및 IPv6 CIDR 블록이 모두 있지만, VPC C에 IPv6 CIDR 블록이 없는 경우 다음과 같이 라우팅 테이블을 업데이트합니다. VPC A와 VPC B의 리소스에서는 VPC 피어링 연결을 통해 IPv6를 사용하여 통신할 수 있습니다. 그러나 VPC C에서는 IPv6를 사용하여 VPC A 또는 VPC B와 통신할 수 없습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
## 서로 피어링된 여러 VPC
이 구성에는 풀 메시 구성에서 피어링된 7개의 VPC가 있습니다. VPC가 동일한 AWS 계정에 있으며 해당 CIDR 블록이 겹치지 않습니다.
| VPC | VPC | VPC 피어링 연결 |
| --- | --- | --- |
| A | B | pcx-aaaabbbb |
| A | C | pcx-aaaacccc |
| A | D | pcx-aaaadddd |
| A | E | pcx-aaaaeeee |
| A | F | pcx-aaaaffff |
| A | G | pcx-aaaagggg |
| B | C | pcx-bbbbcccc |
| B | D | pcx-bbbbdddd |
| B | E | pcx-bbbbeeee |
| B | F | pcx-bbbbffff |
| B | G | pcx-bbbbgggg |
| C | D | pcx-ccccdddd |
| C | E | pcx-cccceeee |
| C | F | pcx-ccccffff |
| C | G | pcx-ccccgggg |
| D | E | pcx-ddddeeee |
| D | F | pcx-ddddffff |
| D | G | pcx-ddddgggg |
| E | F | pcx-eeeeffff |
| E | G | pcx-eeeegggg |
| F | G | pcx-ffffgggg |
서로의 리소스를 제한 없이 액세스할 수 있어야 하는 여러 VPC가 있을 때 이 구성을 사용할 수 있습니다. 예를 들어 파일 공유 네트워크로 사용할 수 있습니다. 이 다이어그램에서 선은 VPC 피어링 연결을 나타냅니다.
![\[풀 메시 구성의 VPC 7개.\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/full-mesh.png)
이 구성을 구현하려면 다음과 같이 각 VPC의 라우팅 테이블을 업데이트합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
모든 VPC에 IPv6 CIDR 블록이 연결되어 있는 경우 다음과 같이 라우팅 테이블을 업데이트합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-full-access.html)
# 특정 경로로 VPC 피어링 구성
서브넷 CIDR 블록, 특정 CIDR 블록(VPC에 여러 CIDR 블록이 있는 경우) 또는 피어 VPC의 특정 리소스에 대한 액세스를 제한하도록 VPC 피어링 연결에 대한 라우팅 테이블을 구성할 수 있습니다. 이 예시에서는 겹치는 CIDR 블록이 있는 최소 2개의 VPC로 중앙 VPC가 피어링됩니다.
특정 VPC 피어링 연결 구성이 필요한 시나리오의 예시는 [VPC 피어링 연결 네트워킹 시나리오](peering-scenarios.md) 단원을 참조하세요. VPC 피어링 연결을 사용하는 방법에 대한 자세한 내용은 [VPC 피어링 연결](working-with-vpc-peering.md) 섹션을 참조하세요. 라우팅 테이블 업데이트에 대한 자세한 내용은 [VPC 피어링 연결을 위한 라우팅 테이블 업데이트](vpc-peering-routing.md) 단원을 참조하세요.
**Topics**
+ [1개의 VPC에서 특정 서브넷에 액세스하는 VPC 2개](#one-to-two-vpcs-simple-hub)
+ [1개의 VPC에서 특정 CIDR 블록에 액세스하는 VPC 2개](#two-vpcs-peered-specific-cidr)
+ [2개의 VPC에서 특정 서브넷에 액세스하는 VPC 1개](#one-to-two-vpcs-specific-subnets)
+ [VPC 2개의 특정 인스턴스에 액세스하는 VPC 1개의 인스턴스](#one-to-two-vpcs-instances)
+ [가장 긴 접두사 일치를 사용하여 VPC 2개에 액세스하는 VPC 1개](#one-to-two-vpcs-lpm)
+ [여러 VPC 구성](#multiple-configurations)
## 1개의 VPC에서 특정 서브넷에 액세스하는 VPC 2개
이 구성에는 2개의 서브넷이 있는 중앙 VPC(VPC A), VPC A와 VPC B 사이의 피어링 연결(`pcx-aaaabbbb`) 및 VPC A와 VPC C 사이의 피어링 연결(`pcx-aaaacccc`)이 있습니다. 각 VPC는 VPC A의 서브넷 중 하나에 있는 리소스에만 액세스해야 합니다.
![\[VPC 1개에 속한 서브넷 2개로 피어링되는 VPC 2개\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/two-vpcs-to-two-subnets-one-vpc.png)
서브넷 1의 라우팅 테이블은 VPC 피어링 연결 `pcx-aaaabbbb`를 사용하여 VPC B의 전체 CIDR 블록에 액세스합니다. VPC B의 라우팅 테이블은 `pcx-aaaabbbb`를 사용하여 VPC A에 있는 서브넷 1의 CIDR 블록에 액세스합니다. 서브넷 2의 라우팅 테이블은 VPC 피어링 연결 `pcx-aaaacccc`를 사용하여 VPC C의 전체 CIDR 블록에 액세스합니다. VPC C 테이블의 라우팅 테이블은 `pcx-aaaacccc`를 사용하여 VPC A에 있는 서브넷 2의 CIDR 블록에 액세스합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)
이 구성을 여러 CIDR 블록으로 확장할 수 있습니다. VPC A와 VPC B에 IPv4 및 IPv6 CIDR 블록이 모두 있으며, 서브넷 1에는 연결된 IPv6 CIDR 블록이 있다고 가정하겠습니다. VPC 피어링 연결을 사용하여 IPv6를 통해 VPC A의 서브넷 1과 통신하도록 VPC B를 활성화할 수 있습니다. 이렇게 하려면 VPC B의 IPv6 CIDR 블록 대상이 있는 VPC A의 라우팅 테이블에 대한 경로와 VPC A에 있는 서브넷 1의 IPv6 CIDR 대상이 있는 VPC B의 라우팅 테이블에 대한 경로를 추가합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)
## 1개의 VPC에서 특정 CIDR 블록에 액세스하는 VPC 2개
이 구성에는 중앙 VPC(VPC A), VPC A와 VPC B 사이의 피어링 연결(`pcx-aaaabbbb`) 및 VPC A와 VPC C 사이의 피어링 연결(`pcx-aaaacccc`)이 있습니다. VPC A에는 각 피어링 연결에 대해 하나의 CIDR 블록이 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)
## 2개의 VPC에서 특정 서브넷에 액세스하는 VPC 1개
이 구성에는 1개의 서브넷이 있는 중앙 VPC(VPC A), VPC A와 VPC B 사이의 피어링 연결(`pcx-aaaabbbb`) 및 VPC A와 VPC C 사이의 피어링 연결(`pcx-aaaacccc`)이 있습니다. VPC B와 VPC C에는 각각 2개의 서브넷이 있습니다. VPC A와 VPC B 간의 피어링 연결은 VPC B의 서브넷 중 하나만 사용합니다. VPC A와 VPC C 간의 피어링 연결은 VPC C의 서브넷 중 하나만 사용합니다.
![\[서브넷 2개와 피어링되는 VPC 1개\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/one-to-two-vpcs-specific-subnets.png)
다른 VPC에서 액세스해야 하는 단일 리소스 집합(예: Active Directory 서비스)이 있는 중앙 VPC가 있을 때 이 구성을 사용합니다. 중앙 VPC에는 피어링할 VPC에 대한 모든 액세스 권한이 필요하지 않습니다.
VPC A의 라우팅 테이블은 피어링 연결을 사용하여 피어링된 VPC의 특정 서브넷에만 액세스합니다. 서브넷 1의 라우팅 테이블은 VPC A와의 피어링 연결을 사용하여 VPC A의 서브넷에 액세스합니다. 서브넷 2의 라우팅 테이블은 VPC A와의 피어링 연결을 사용하여 VPC A의 서브넷에 액세스합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)
### 응답 트래픽을 위한 라우팅
겹치거나 일치하는 CIDR 블록을 가진 여러 VPC와 피어링된 VPC가 있는 경우, 라우팅 테이블이 자신의 VPC에서 잘못된 VPC로 응답 트래픽을 전송하지 못하도록 구성되어 있는지 확인하세요. AWS에서는 패킷의 소스 IP를 확인하고 응답 패킷을 다시 소스로 라우팅하는 VPC 피어링 연결에서 유니캐스트 역경로 전달을 지원하지 않습니다.
예를 들어, VPC A는 VPC B 및 VPC C와 피어링됩니다. VPC B 및 VPC C에는 일치하는 CIDR 블록이 있으며, 해당 서브넷에는 일치하는 CIDR 블록이 있습니다. VPC B의 서브넷 2에 대한 라우팅 테이블은 VPC A 서브넷에 액세스하는 VPC 피어링 연결 `pcx-aaaabbbb`를 가리킵니다. VPC A 라우팅 테이블은 VPC CIDR로 향하는 트래픽을 피어링 연결 `pcx-aaaaccccc`에 보내도록 구성됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)
VPC B에 있는 서브넷 2의 인스턴스에서 VPC 피어링 연결 `pcx-aaaabbbb`를 사용하여 VPC A에 있는 Active Directory 서버에 트래픽을 보낸다고 가정하겠습니다. VPC A에서는 Active Directory 서버에 응답 트래픽을 보냅니다. 그러나 VPC A 라우팅 테이블은 VPC CIDR 범위 내의 모든 트래픽을 VPC 피어링 연결 `pcx-aaaacccc`에 보내도록 구성됩니다. VPC C의 서브넷 2의 경우 VPC B의 서브넷 2에 있는 인스턴스와 동일한 IP 주소가 있으면 VPC A의 응답 트래픽을 받습니다. VPC B의 서브넷 2에 있는 인스턴스에서는 VPC A에 대한 요청의 응답을 받지 않습니다.
이를 방지하기 위해 VPC B에 있는 서브넷 2의 CIDR로 VPC A 라우팅 테이블에 대한 특정 경로를 대상 겸 `pcx-aaaabbbb`의 대상으로 추가할 수 있습니다. 새 경로가 더 구체적이므로 서브넷 2 CIDR로 향하는 트래픽이 VPC 피어링 연결 `pcx-aaaabbbb`로 라우팅됩니다.
또는, 다음 예에서는 VPC A 라우팅 테이블에는 각 VPC 피어링 연결의 각 서브넷에 대한 경로가 있습니다. VPC A에서는 VPC B의 서브넷 2 및 VPC C의 서브넷 1과 통신할 수 있습니다. 이 시나리오는 VPC B 및 VPC C와 동일한 IP 주소 범위 내에 속하는 다른 서브넷으로 다른 VPC 피어링 연결을 추가해야 하는 경우에 유용합니다. 해당 특정 서브넷에 대한 다른 경로를 단하게 추가할 수 있습니다.
| 대상 주소 | 대상 |
| --- | --- |
| VPC A CIDR | 로컬 |
| 서브넷 2 CIDR | pcx-aaaabbbb |
| 서브넷 1 CIDR | pcx-aaaacccc |
그 대신, 사용 사례에 따라 다음과 같이 트래픽이 올바른 서버로 다시 라우팅되도록 VPC B에서 특정 IP 주소에 대한 경로를 생성할 수 있습니다(라우팅 테이블은 가장 긴 접두사 일치 항목을 사용하여 경로의 우선 순위를 지정함).
| 대상 주소 | 대상 |
| --- | --- |
| VPC A CIDR | 로컬 |
| 서브넷 2의 특정 IP 주소 | pcx-aaaabbbb |
| VPC B CIDR | pcx-aaaacccc |
## VPC 2개의 특정 인스턴스에 액세스하는 VPC 1개의 인스턴스
이 구성에는 1개의 서브넷이 있는 중앙 VPC(VPC A), VPC A와 VPC B 사이의 피어링 연결(`pcx-aaaabbbb`) 및 VPC A와 VPC C 사이의 피어링 연결(`pcx-aaaacccc`)이 있습니다. VPC A에는 각 피어링 연결에 대해 하나의 인스턴스가 있는 서브넷이 있습니다. 이 구성을 사용하여 특정 인스턴스에 대한 피어링 트래픽을 제한할 수 있습니다.
![\[VPC 2개의 인스턴스로 피어링되는 VPC의 인스턴스\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/one-to-two-vpcs-instances.png)
각 VPC 라우팅 테이블은 피어 VPC의 단일 IP 주소(더불어 특정 인스턴스)에 액세스하기 위해 관련 VPC 피어링 연결을 가리킵니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)
## 가장 긴 접두사 일치를 사용하여 VPC 2개에 액세스하는 VPC 1개
이 구성에는 1개의 서브넷이 있는 중앙 VPC(VPC A), VPC A와 VPC B 사이의 피어링 연결(`pcx-aaaabbbb`) 및 VPC A와 VPC C 사이의 피어링 연결(`pcx-aaaacccc`)이 있습니다. VPC B와 VPC C에 일치하는 CIDR 블록이 있습니다. VPC 피어링 연결 `pcx-aaaabbbb`를 사용하여 VPC A와 VPC B의 특정 인스턴스 사이에 트래픽을 라우팅합니다. VPC B와 VPC C에서 공유하는 CIDR IP 주소 범위로 향하는 다른 모든 트래픽은 `pcx-aaaacccc`를 통해 VPC C로 라우팅됩니다.
![\[가장 긴 접두사 일치 항목을 사용하여 피어링\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/one-to-two-vpcs-longest-prefix.png)
VPC 라우팅 테이블은 가장 긴 접두사 일치 항목을 사용하여 의도하는 VPC 피어링 연결에서 가장 구체적인 경로를 선택합니다. 다른 모든 트래픽은 그 다음 일치하는 경로를 통해 라우팅되며 여기서는 VPC 피어링 연결 `pcx-aaaacccc`입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)
**중요**
VPC B의 인스턴스 X가 아닌 인스턴스에서 VPC A에 트래픽을 보내는 경우 응답 트래픽이 VPC B 대신에 VPC C로 라우팅될 수 있습니다. 자세한 내용은 [응답 트래픽을 위한 라우팅](#peering-incorrect-response-routing) 섹션을 참조하세요.
## 여러 VPC 구성
이 구성에서는 중앙 VPC(VPC A)가 스포크 구성에서 여러 VPC와 피어링됩니다. 또한 풀 메시 구성에서 피어링된 VPC 3개(VPC X, Y, Z)도 있습니다.
VPC D에도 VPC X(`pcx-ddddxxxx`)와 VPC 피어링 연결이 있습니다. VPC A와 VPC X에 겹치는 CIDR 블록이 있습니다. 즉, VPC A와 VPC D 사이의 피어링 트래픽이 VPC D의 특정 서브넷(서브넷 1)으로 제한됩니다. 따라서 VPC D에서는 VPC A 또는 VPC X에서 요청을 받으면 올바른 VPC로 응답 트래픽을 보낼 수 있습니다. AWS에서는 패킷의 소스 IP를 확인하고 회신 패킷을 소스로 다시 라우팅하는 VPC 피어링 연결의 유니캐스트 역경로 전달이 지원되지 않습니다. 자세한 내용은 [응답 트래픽을 위한 라우팅](#peering-incorrect-response-routing) 단원을 참조하세요.
마찬가지로, VPC D와 VPC Z에 겹치는 CIDR 블록이 있습니다. VPC D와 VPC X 사이의 피어링 트래픽이 VPC D의 서브넷 2로 제한되며 VPC X와 VPC Z 사이의 피어링 트래픽이 VPC Z의 서브넷 1로 제한됩니다. 따라서 VPC X에서 VPC D 또는 VPC Z의 피어링 트래픽을 받으면 올바른 VPC로 응답 트래픽을 다시 보낼 수 있습니다.
![\[여러 피어링 구성\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/multiple-configurations.png)
VPC B, C, E, F 및 G의 라우팅 테이블에서는 VPC A의 전체 CIDR 블록에 액세스하는 관련 피어링 연결을 가리키고, VPC A 라우팅 테이블에서는 전체 CIDR 블록에 액세스하는 VPC B, C, E, F 및 G의 관련 피어링 연결을 가리킵니다. 피어링 연결 `pcx-aaaadddd`의 경우, VPC A 라우팅 테이블에서는 VPC D의 서브넷 1로만 트래픽을 라우팅하고 VPC D의 서브넷 1 라우팅 테이블에서는 VPC A의 전체 CIDR 블록을 가리킵니다.
VPC Y 라우팅 테이블에서는 VPC 와 VPC Z의 전체 CIDR 블록에 액세스하는 과련 피어링 연결을 가리키고, VPC Z 라우팅 테이블에서는 VPC Y의 전체 CIDR 블록에 액세스하는 관련 피어링 연결을 가리킵니다. VPC Z의 서브넷 1 라우팅 테이블에서는 VPC Y의 전체 CIDR 블록에 액세스하는 관련 피어링 연결을 가리킵니다. VPC X 라우팅 테이블에서는 VPC D의 서브넷 2와 VPC Z의 서브넷 1에 액세스하는 관련 피어링 연결을 가리킵니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/vpc/latest/peering/peering-configurations-partial-access.html)