한 회사에 20개의 서비스 팀이 있으며, 각 팀은 자체 AWS 계정에 있고 각 VPC는 192.168.0.0/22를 사용합니다. 서비스는 ALB 뒤의 EC2 인스턴스에서 실행되며 현재 공용 인터넷을 통해 통신합니다. 보안 부서에서는 이제 모든 교차 서비스 트래픽이 인터넷을 통하지 않고 사설 네트워킹을 통해 HTTPS를 사용하도록 요구합니다. 이 솔루션은 각 팀에 필요한 변경 사항을 최소화해야 합니다. 어떤 접근 방식이 이러한 요구 사항을 충족할까요?

정답은 AWS PrivateLink를 사용하여 서비스 간 통신을 프라이빗하게 유지하고 인터넷을 통하지 않도록 하는 것입니다. 각 마이크로서비스 VPC에 NLB를 생성하고, PrivateLink를 통해 엔드포인트 서비스를 노출하면 다른 계정의 서비스가 VPC 엔드포인트를 통해 해당 서비스에 비공개로 액세스할 수 있습니다. 각 팀은 기존 ALB와 EC2 인스턴스를 유지하면서 NLB를 추가하고 VPC 엔드포인트 DNS 이름을 사용하도록 통신을 업데이트하기만 하면 되므로 각 팀에 필요한 변경 사항이 최소화됩니다. 오답: 새 계정 및 VPC를 생성하고 공유 서브넷에 NLB 및 EC2를 시작하도록 지시하는 것은 각 팀의 아키텍처에 상당한 변경을 요구하며, 기존 서비스의 재배포가 필요할 수 있습니다. VPC 피어링은 20개 팀 간에 N(N-1)/2개의 피어링 연결이 필요하므로 관리 복잡성이 매우 높습니다. 또한, IP 주소 중복 문제(192.168.0.0/22 사용)로 인해 직접적인 피어링이 불가능합니다. Transit Gateway를 사용하는 것은 복잡성을 줄일 수 있지만, 여전히 IP 주소 중복 문제를 해결해야 하며, PrivateLink만큼 각 팀의 변경 사항을 최소화하지 못합니다. PrivateLink는 IP 주소 중복 문제를 자동으로 처리합니다.