설명
기본 VPC를 여러 워크로드가 함께 사용하면 의도한 네트워크 격리와 접근 정책을 유지하기 어려울 수 있습니다. 기본 VPC에서도 경로와 보안 그룹을 제한할 수 있으므로, 기본 VPC 사용 자체가 공개 접근이나 취약성을 의미하지는 않습니다.
서브넷 이름이 아니라 실제 VPC 연결, 라우팅, 공개 주소와 보안 그룹을 기준으로 접근 범위를 확인해야 합니다.
잠재적 영향
- 서로 격리해야 할 워크로드가 같은 네트워크에 배치되면 불필요한 연결이 허용될 수 있습니다.
- 공개 주소, 인터넷 경로와 허용 규칙이 함께 있으면 인스턴스가 인터넷에서 접근 가능한 상태가 될 수 있습니다.
해결 방법
- 워크로드의 격리 요구에 맞는 VPC와 서브넷을 선택하고
SubnetId에 지정하세요. - 라우팅, 공개 주소 할당과 보안 그룹을 검토하여 필요한 연결만 허용하세요.
- 서브넷 변경의 인스턴스 교체 및 연결 영향을 변경 세트에서 확인하고 전환을 계획하세요.
예시
AMI와 서브넷 참조는 환경에 맞게 제공해야 합니다. DefaultSubnet과 PrivateSubnet이라는 이름만으로 실제 VPC나 라우팅 특성이 결정되지는 않습니다.
변경 전
yaml
Resources:
AppInstance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-79fd7eee
SubnetId: !Ref DefaultSubnet
DefaultSubnet이 가리키는 실제 서브넷과 네트워크 정책을 확인해야 합니다.
변경 후
yaml
Resources:
AppInstance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-79fd7eee
SubnetId: !Ref PrivateSubnet
검토한 서브넷을 선택합니다. 이 참조 변경만으로 공개 주소나 인터넷 경로가 제거되지는 않습니다.