Amazon VPC 공유

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

VPC 공유의 이점:

• 간소화된 설계 - VPC 간 연결과 관련된 복잡성이 없습니다.

• 관리되는 VPC 수 감소

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

• IPv4 주소 활용도 향상

• 비용 절감 - 동일한 가용 영역 내의 서로 다른 계정에 속한 인스턴스 간에 데이터 전송 요금이 부과되지 않습니다.

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

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

애플리케이션 포트폴리오당 하나의 VPC(총 2개의 VPC)를 보유할 수 있으며, VPC는 해당 포트폴리오 내의 서로 다른 애플리케이션 소유자 계정과 공유됩니다. 앱 소유자는 앱을 각각의 공유 VPC(이 경우 NACL을 사용하는 네트워크 라우팅 세분화 및 격리를 위해 서로 다른 서브넷에 있음)에 배포합니다. 2개의 공유 VPC가 Transit Gateway를 통해 연결됩니다. 이 설정을 사용하면 VPC 10대를 연결해야 하는 상황에서 두 대만 연결할 수 있습니다(그림 6).

그림 6 - 예제 설정 - 공유 VPC

참고

VPC 공유 참가자는 공유 서브넷에서 모든 AWS 리소스를 생성할 수는 없습니다. 자세한 내용은 Amazon VPC 제한을 참조하세요.