Task at hand
Using Launch Template with Auto Scaling Group (ASG) to launch EC2 instances into a VPC.
Tech stack
- AWS
- Terraform (0.11.15 with AWS provider v2.70.1)
Error encountered
Error creating Auto Scaling Group: ValidationError: You must use a valid fully-formed launch template. No default VPC for this user. GroupName is only supported for EC2-Classic and default VPC.
What it actually means
Let’s revisit what we are trying to do – our Auto Scaling Group uses Launch Template to launch EC2 instances into a VPC. The key is “into a VPC”.
- On the Launch Template configuration, we specify the security group names or IDs that allow access to the EC2 instances from an external network. To launch instances into a VPC, we have to use Security Group IDs, not the name. (Spoiler alert, this was our mistake.)
- On the Auto Scaling Group configuration, we specify the subnet IDs that we want the EC2 instance to be in. Implicitly, the subnets are part of a VPC.
So, AWS would check this logic:
VPC of subnets specified in Auto Scaling Group == VPC of the EC2 instance that the security group IDs are associated with in the Launch Template
In our case, we have provided security group names, instead of the IDs, in the first Launch Template we created. Thus, the error really means:
Since you gave us Security Group Names (instead of IDs) on the Launch Template, we assume you want to launch an EC2-Classic instance (that can be outside a VPC), or an EC2 instance into a default VPC. But you have neither an EC2-Classic instance nor a default VPC. So.... what do you want from us?!

Detour: “Wait, what? Can you launch instances NOT in a VPC?”
Yes, with EC2-Classic, which are only available in AWS accounts opened before December 2013. (Remember the mention of “EC2-Classic” in the error message?)
The EC2-Classic platform was introduced in the original release of Amazon EC2. If you created your AWS account after 2013-12-04, it does not support EC2-Classic, so you must launch your Amazon EC2 instances in a VPC.
AWS Documentation on EC2-Classic
But EC2-Classic is due to be retired in August 2022, so perhaps this message would not pop up ever again in a few months’ time!
Detour: “Wait, what? Don’t Security Groups act as firewall for EC2 Instances? Why is it named vpc_security_group_ids
?”
That’s right 🙂
Perhaps the naming reflects the sensible defaults / hierarchy decided by AWS, rather than what a Security Group meant to protect. When a VPC is created in AWS, by default the following are also created:
- Route Table
- This is implicit to a VPC to direct network traffic.
- DHCP options sets
- This is also implicit to a VPC.
- Network ACL
- This is normally coupled with subnets within the VPC. The default Network ACL is created as a fallback, and we cannot delete a default network ACL.
- Security Groups
- This is normally coupled with EC2 Instances (resource level). A default Security Group is created as a fallback, and we cannot delete a default Security Group. “Security groups act at the instance level, not the subnet level.“
Thus, when we create a Network ACL for a Subnet or Security Group for an EC2 Instance, we also need to specify the VPC ID.
(Of course there are more advanced setup such as VPC peering and its relevant setup for Security Groups, that is another topic.)
The fix (and gotchas)
Fix: Use vpc_security_group_ids
in Launch Template
This was an easy fix in the Terraform module to use vpc_security_group_ids
instead of security_group_names
.
Gotcha 1: Templates are versioned
Check that the Auto Scaling Group is using the correct version of the template.
If you always want to make the updated version of a template as the default version, use the option update_default_version
.
Gotcha 2: Force a complete roll out in Auto Scaling Group
In older days, when the template updates, instances rolled out by ASG remain the same. This was an awkward issue until AWS released Instance Refresh in 2020, and the feature instance_refresh
is available since Terraform AWS provider v3.22.