설명
기본 VPC는 빠른 시작에 편리하지만 운영 리소스의 네트워크 경계를 의도적으로 설계해야 합니다. 기본 VPC에서도 라우팅과 보안 그룹을 제어할 수 있으므로 그 사용만으로 공개 접근이나 보안 취약성을 의미하지는 않습니다. 실제 서브넷, 공개 IP와 접근 규칙을 함께 확인하세요.
잠재적 영향
- 테스트와 운영 리소스가 의도하지 않게 같은 네트워크 경계에 놓일 수 있습니다.
- 서브넷과 라우팅 정책을 확인하지 않으면 조직의 접근 통제나 격리 요구를 충족하지 못할 수 있습니다.
해결 방법
- 별도 격리가 필요하면 운영 VPC와 서브넷을 준비하고
vpc_subnet_id로 지정하세요. 변수 이름이 아니라 실제 서브넷의 VPC 소속을 확인하세요. - 라우팅, 보안 그룹과 공개 IP 할당을 함께 검토하고 필요한 연결만 허용하세요. VPC를 바꾸는 것만으로 인스턴스가 비공개로 전환되지는 않습니다.
예시
과거 amazon.aws.ec2 모듈을 지원하는 컬렉션을 전제로 한 발췌입니다. 실제 AMI와 해당 VPC 범위 안의 겹치지 않는 서브넷 CIDR을 입력하세요. VPC 조회 결과, 키와 접근 규칙은 별도로 준비해야 합니다.
변경 전
yaml
- name: 기본 VPC에 서브넷 생성
amazon.aws.ec2_vpc_subnet:
state: present
vpc_id: "{{ defaultVPC.vpcs.0.id }}"
cidr: "{{ ec2_subnet_cidr }}"
tags:
Name: Database Subnet
register: my_subnet
- name: EC2 인스턴스 생성
amazon.aws.ec2:
key_name: mykey
instance_type: t2.micro
image: "{{ ec2_image_id }}"
wait: yes
count: 3
vpc_subnet_id: "{{ my_subnet.subnet.id }}"
assign_public_ip: yes
기본 VPC에 서브넷을 먼저 만든 뒤 그 ID로 인스턴스를 배치합니다. 조직의 격리 요구에 맞는지 확인해야 합니다.
변경 후
yaml
- name: 별도 VPC에 서브넷 생성
amazon.aws.ec2_vpc_subnet:
state: present
vpc_id: "{{ myVPC.vpcs.0.id }}"
cidr: "{{ ec2_subnet_cidr }}"
tags:
Name: Database Subnet
register: my_subnet2
- name: EC2 인스턴스 생성
amazon.aws.ec2:
key_name: mykey
instance_type: t2.micro
image: "{{ ec2_image_id }}"
wait: yes
count: 3
vpc_subnet_id: "{{ my_subnet2.subnet.id }}"
assign_public_ip: yes
별도로 관리하는 VPC를 선택합니다. 두 예시 모두 assign_public_ip: yes이므로 공개 IP와 실제 접근 경로도 검토하세요.