VPC 공유

VPC 공유는 팀 간 네트워크 격리를 VPC 소유자가 엄격하게 관리할 필요는 없지만 계정 수준의 사용자 및 권한은 엄격하게 관리해야 하는 경우에 유용합니다. 공유 VPC를 사용하면 여러 AWS 계정이 중앙에서 관리되는 공유 Amazon VPC에 애플리케이션 리소스 (예: Amazon EC2 인스턴스) 를 생성합니다. 이 모델에서는 VPC를 소유한 계정 (소유자) 이 하나 이상의 서브넷을 다른 계정 (참여자) 과 공유합니다. 서브넷을 공유한 후 참여자는 공유된 서브넷의 해당 애플리케이션 리소스를 보고, 생성하고, 수정하고, 삭제할 수 있습니다. 참여자는 다른 참여자 또는 VPC 소유자에 속한 리소스를 보거나 수정하거나 삭제할 수 없습니다. 공유 VPC의 리소스 간 보안은 보안 그룹, 네트워크 액세스 제어 목록 (NACL) 을 사용하거나 서브넷 간 방화벽을 통해 관리됩니다.

VPC 공유의 이점:

• 단순화된 설계 — VPC 간 연결에 대한 복잡성 없음

• 관리되는 VPC 수가 적음

• 네트워크 팀과 애플리케이션 소유자 간의 직무 분리

• IPv4 주소 활용도 향상

• 비용 절감 — 동일한 가용 영역 내에서 서로 다른 계정에 속하는 인스턴스 간 데이터 전송 요금 없음

참고

서브넷을 여러 계정과 공유하는 경우 참가자는 IP 공간과 네트워크 리소스를 공유하므로 참여자가 어느 정도 협력해야 합니다. 필요한 경우 각 참가자 계정마다 다른 서브넷을 공유하도록 선택할 수 있습니다. 참가자당 하나의 서브넷을 통해 네트워크 ACL은 보안 그룹 외에도 네트워크 격리를 제공할 수 있습니다.

대부분의 고객 아키텍처에는 여러 VPC가 포함되며, 이들 중 다수는 둘 이상의 계정과 공유됩니다. Transit Gateway 및 VPC 피어링은 공유 VPC를 연결하는 데 사용할 수 있습니다. 예를 들어 애플리케이션이 10개라고 가정해 보겠습니다. 각 애플리케이션에는 자체 AWS 계정이 필요합니다. 애플리케이션은 두 개의 애플리케이션 포트폴리오로 분류할 수 있습니다 (동일한 포트폴리오 내의 애플리케이션은 네트워킹 요구 사항이 비슷합니다. '마케팅'의 경우 앱 1~5, '세일즈'의 경우 앱 6—10).

애플리케이션 포트폴리오당 VPC 하나 (총 VPC 2개) 를 가질 수 있으며, VPC는 해당 포트폴리오 내의 여러 애플리케이션 소유자 계정과 공유됩니다. 앱 소유자는 각각의 공유 VPC (이 경우 NACL을 사용한 네트워크 경로 분할 및 격리를 위해 서로 다른 서브넷) 에 앱을 배포합니다. 두 개의 공유 VPC는 Transit Gateway를 통해 연결됩니다. 이 설정을 사용하면 다음 그림과 같이 10개의 VPC를 연결해야 했던 것을 단 2개로 줄일 수 있습니다.

예제 설정 — 공유 VPC

참고

VPC 공유 참여자는 공유 서브넷에서 모든 AWS 리소스를 생성할 수 없습니다. 자세한 내용은 VPC 공유 설명서의 제한 섹션을 참조하십시오.

VPC 공유의 주요 고려 사항 및 모범 사례에 대한 자세한 내용은 VPC 공유: 주요 고려 사항 및 모범 사례 블로그 게시물을 참조하십시오.