Description
A production EC2 instance’s VPC and subnet must be clear to control security groups, routing and public access. Omitting a subnet can select a default subnet or cause creation to fail, depending on the environment. Current EC2 instances run inside VPCs, so omission must not be interpreted as running without a VPC.
Potential impact
- An instance may be placed in an unintended network or fail to launch.
- Security groups, routing and public IP settings may not match organizational access policies.
Remediation
- Select the intended subnet through
vpc_subnet_idin the creation task and verify its actual VPC membership. - Manage subnets, security groups, routing and public IP assignment together. Check isolation requirements between test and production networks as well.
Examples
These excerpts assume a collection supporting the historical amazon.aws.ec2 module. They require a real AMI, key, webserver security group in the target VPC and subnet. Both request public IP assignment, so neither demonstrates a private deployment.
Before
- name: EC2 인스턴스 생성
amazon.aws.ec2:
key_name: mykey
instance_type: t2.micro
image: "{{ ec2_image_id }}"
wait: yes
group: webserver
count: 3
assign_public_ip: yes
No subnet is specified, leaving selection to defaults and the environment. Check the resulting instance’s actual placement.
After
- name: EC2 인스턴스 생성
amazon.aws.ec2:
key_name: mykey
instance_type: t2.micro
image: "{{ ec2_image_id }}"
wait: yes
group: webserver
count: 3
vpc_subnet_id: subnet-29e63245
assign_public_ip: yes
This specifies the actual subnet ID to use. Check that subnet’s routing and security-group access scope too.