기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 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/) 블로그 게시물을 참조하세요.