AWS Launch Configuration in Terraform: Definition, Lifecycle and Production Patterns

Launch configurations are the original Terraform resource for defining the immutable launch parameters that an Amazon EC2 Auto Scaling Group uses to create new instances. The aws_launch_configuration resource maps directly to the AWS EC2 Launch Configuration API and is used when an Auto Scaling Group is configured with launch_configuration = aws_launch_configuration.as_conf.name. Because launch configurations cannot be updated after creation by the Amazon Web Service API, Terraform must destroy and recreate them on change, which drives a specific set of lifecycle patterns, naming strategies, and integration rules with aws_autoscaling_group.

Core resource purpose and deprecation context

Provides a resource to create a new launch configuration, used for autoscaling groups.

The provider documentation states:

!> WARNING: The use of launch configurations is discouraged in favor of launch templates. Read more in the AWS EC2 Documentation.

The aws_launch_configuration resource is listed with subcategory Auto Scaling, layout aws, pagetitle AWS: awslaunch_configuration, description Provides a resource to create a new launch configuration, used for autoscaling groups.

This means any new design should evaluate aws_launch_template first, while existing production stacks still rely on launch configurations for backward compatibility and for scenarios where immutable launch definitions are acceptable.

Supported arguments and attributes

The following arguments are supported:

• name
• name_prefix
• image_id
• instance_type
• iaminstanceprofile
• key_name
• security_groups
• spot_price

Attributes exposed by the resource include:

• name
• account_id
• region

The documentation notes:

In Terraform v1.5.0 and later, use an import block to import launch configurations using the name. For example:
hcl import { to = aws_launch_configuration.example identity = { name = "example" } }

Using terraform import, import launch configurations using the name. For example:
bash % terraform import aws_launch_configuration.example example

Argument table

Immutable nature and the createbeforedestroy requirement

Launch Configurations cannot be updated after creation with the Amazon Web Service API. In order to update a Launch Configuration, Terraform will destroy the existing resource and create a replacement.

In order to effectively use a Launch Configuration resource with an AutoScaling Group resource, it's recommended to specify createbeforedestroy in a lifecycle block.

Example pattern from the provider documentation:

```hcl
data "awsami" "ubuntu" {
mostrecent = true
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
}
filter {
name = "virtualization-type"
values = ["hvm"]
}
owners = ["099720109477"] # Canonical
}

resource "awslaunchconfiguration" "asconf" {
nameprefix = "terraform-lc-example-"
imageid = data.awsami.ubuntu.id
instancetype = "t2.micro"
lifecycle {
createbefore_destroy = true
}
}

resource "awsautoscalinggroup" "bar" {
name = "terraform-asg-example"
launchconfiguration = awslaunchconfiguration.asconf.name
minsize = 1
maxsize = 2
lifecycle {
createbeforedestroy = true
}
}
```

With this setup Terraform generates a unique name for your Launch Configuration and can then update the AutoScaling Group without conflict before destroying the previous Launch Configuration.

Either omit the Launch Configuration name attribute, or specify a partial name with name_prefix.

-> Note When using awslaunchconfiguration with awsautoscalinggroup, it is recommended to use the name_prefix (Optional) instead of the name (Optional) attribute. This will allow Terraform lifecycles to detect changes to the launch configuration and update the autoscaling group correctly.

Naming strategies and auto scaling integration

Name management is critical because Auto Scaling Groups reference a launch configuration by name.

• name - Optional. The name of the launch configuration. If you leave this blank, Terraform will auto-generate a unique name.
• name_prefix - Optional. Creates a unique name beginning with the specified prefix. Conflicts with name.

The recommended production pattern is to avoid hard coding name and use name_prefix together with lifecycle { create_before_destroy = true }. This allows Terraform to create a new configuration with a new unique name, update the Auto Scaling Group to point to it, and then safely destroy the old configuration.

An example with explicit name:

hcl resource "aws_launch_configuration" "as_conf" { name = "web_config" image_id = data.aws_ami.ubuntu.id instance_type = "t2.micro" }

And an example with auto-generated name:

```hcl
resource "awslaunchconfiguration" "asconf" {
imageid = "${data.awsami.ubuntu.id}"
instancetype = "m4.large"
spotprice = "0.001"
lifecycle {
createbefore_destroy = true
}
}

resource "awsautoscalinggroup" "bar" {
name = "terraform-asg-example"
launchconfiguration = "${awslaunchconfiguration.asconf.name}"
}
```

Spot instance pricing support

Launch configurations can set the spot instance pricing to be used for the Auto Scaling Group to reserve instances.

Simply specifying the spot_price parameter will set the price on the Launch Configuration which will attempt to reserve your instances at this price. See the AWS Spot Instance documentation for more information or how to launch Spot Instances with Terraform.

Usage:

hcl resource "aws_launch_configuration" "as_conf" { image_id = "${data.aws_ami.ubuntu.id}" instance_type = "m4.large" spot_price = "0.001" lifecycle { create_before_destroy = true } }

AMI lookup and instance definition

A typical definition starts with a data source for the AMI.

hcl data "aws_ami" "ubuntu" { most_recent = true filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"] } filter { name = "virtualization-type" values = ["hvm"] } owners = ["099720109477"] # Canonical }

This is combined with required arguments:

• imageid = data.awsami.ubuntu.id
• instance_type = "t2.micro"

Optional arguments include:

• iaminstanceprofile
• key_name
• security_groups

The provider documentation lists the supported arguments as name, nameprefix, imageid, instancetype, iaminstanceprofile, keyname, security_groups.

Launch templates as the modern alternative

The reference material for production-ready launch templates shows the contrast:

hcl data "aws_ami" "al2023" { most_recent = true owners = ["amazon"] filter { name = "name" values = ["al2023-ami-*-x86_64"] } filter { name = "virtualization-type" values = ["hvm"] } }

hcl resource "aws_launch_template" "app" { name_prefix = "app-" description = "Launch template for application servers" image_id = data.aws_ami.al2023.id instance_type = "t3.medium" lifecycle { create_before_destroy = true } vpc_security_group_ids = [ aws_security_group.app.id, aws_security_group.monitoring.id, ] iam_instance_profile { name = aws_iam_instance_profile.app.name } user_data = base64encode(templatefile("${path.module}/scripts/bootstrap.sh", { environment = var.environment app_version = var.app_version })) tag_specifications { resource_type = "instance" tags = { Name = "app-server" Environment = var.environment } } tag_specifications { resource_type = "volume" tags = { Name = "app-server-volume" Environment = } } }

Let's walk through creating production-ready launch templates in Terraform.

Start with the essentials: AMI, instance type, security groups, and an instance profile.

The key differences are mutable updates, support for userdata, tagspecifications, and more granular network configuration. Launch configurations remain relevant for legacy stacks.

Terraform workflow context

You can use Terraform to create and manage your infrastructure as code. In this tutorial, you will use Terraform to provision an EC2 instance on Amazon Web Services (AWS). EC2 instances are virtual machines running on AWS and a common component of many infrastructure projects.

To provision your infrastructure, you will write configuration to define your provider and instance, set environment variables for your AWS credentials, initialize a new local workspace, and then apply your configuration to create your instance.

To follow this tutorial you will need:

• The Terraform CLI (1.2.0+) installed.
• The AWS CLI installed.
• An AWS account and associated credentials that allow you to create resources in the us-west-2 region, including an EC2 instance, VPC, and security groups.

The tutorials in this collection use resources that qualify under the AWS free tier. We are not responsible for any charges that you may incur. Remember to complete the Destroy infrastructure tutorial later in this collection to remove the infrastructure you create while following these tutorials.

Create a new directory for the Terraform configuration you will use in this tutorial.
bash $ mkdir learn-terraform-get-started-aws
Change into the directory.
bash $ cd learn-terraform-get-started-aws

Terraform configuration files are plain text files in HashiCorp's configuration language, HCL, with file names ending with .tf

This workflow applies equally when defining launch configurations for Auto Scaling Groups.

Practical list of considerations before committing

• Decide whether launch configuration or launch template is appropriate. New designs should prefer launch templates.
• Use name_prefix not name to enable safe replacement.
• Always add lifecycle { createbeforedestroy = true } to both launch configuration and autoscaling group.
• Use a data source for AMI lookup with most_recent = true and owners filter.
• Define spot_price only when spot usage is intended.
• Reference security_groups as IDs, not names.
• Pair with awsautoscalinggroup using launchconfiguration = awslaunchconfiguration.asconf.name.

Conclusion

The awslaunchconfiguration resource in Terraform provides a direct mapping to AWS EC2 Launch Configurations for Auto Scaling Groups. Its defining constraint is immutability: the AWS API does not allow updates, so Terraform must destroy and recreate the resource on any change. That constraint drives the recommended pattern of using nameprefix instead of a fixed name, enabling Terraform to generate a new unique name on each replacement, and coupling createbefore_destroy lifecycle blocks on both the launch configuration and the autoscaling group to avoid downtime and naming conflicts.

The supported arguments are narrow compared to launch templates: name, nameprefix, imageid, instancetype, iaminstanceprofile, keyname, securitygroups, and spotprice. Spot pricing can be set via spotprice, which instructs the Auto Scaling Group to attempt to reserve instances at that price. AMI selection is typically done with a data.awsami lookup with most_recent and filters, as shown in the Ubuntu Canonical example.

Import support exists for existing launch configurations using the name as identifier, either via terraform import or import blocks in Terraform v1.5+. The provider explicitly warns that the use of launch configurations is discouraged in favor of launch templates, which support mutable updates, userdata, tag specifications, and richer networking. For existing production stacks, the safe migration path is to keep the createbeforedestroy and nameprefix pattern, ensure autoscaling group references are updated before destroying the prior configuration, and plan migration to awslaunchtemplate for new workloads.

Sources

1. docs.w3cub.com terraform providers aws r launch configuration
2. oneuptime.com blog post 2026-02-23 create launch templates for auto scaling in terraform
3. github.com hashicorp terraform-provider-aws website docs r launch configuration
4. developer.hashicorp.com terraform tutorials aws get started aws create