AWS EC2 Launch Templates: Master Versions, Parameters & Network Control — Lab 2026

Introduction

If you’ve ever manually launched EC2 instances and thought “there has to be a better way,” you’re about to discover exactly that. EC2 Launch Templates are one of those AWS features that seem simple on the surface but fundamentally change how you think about infrastructure deployment once you truly understand them.

This lab teaches you how to create, version, and manage EC2 Launch Templates from scratch. You’ll configure AMIs, instance types, network settings, and user data — then launch instances using specific template versions. By the end, you’ll understand why Launch Templates are non-negotiable for production AWS environments.

Who is this lab for? Anyone moving beyond manual EC2 launches. Whether you’re preparing for AWS certification, building your first Auto Scaling Group, or transitioning from ClickOps to infrastructure automation, this lab gives you the foundational skills you need.

The Cattle vs. Snowflakes Reality

Here’s the mental model that separates junior engineers from senior architects: a manually launched EC2 instance is a snowflake — unique, fragile, and impossible to reproduce consistently. A Launch Template creates cattle — repeatable, replaceable, and predictable. Production AWS runs on cattle, not snowflakes. Every time you manually configure an instance, you’re creating technical debt that will bite you during your next scaling event or disaster recovery scenario.

Why Launch Templates Replaced Launch Configurations

Something that trips up a lot of engineers: AWS still shows Launch Configurations in the console, but they’re essentially deprecated. I’ve watched teams spend weeks building automation around Launch Configurations only to hit limitations that Launch Templates solved years ago.

Launch Templates support versioning, mixed instance types, Spot configurations, and network interface specifications that Launch Configurations simply cannot handle. AWS has made Launch Templates mandatory for newer Auto Scaling features, and honestly, that should tell you everything about where to invest your learning time.

The Auto Scaling Warning You Need to Hear Now

If you plan to use Auto Scaling Groups later and you get Launch Templates wrong now, your scaling events will fail silently — often under load. I’ve seen production systems crash during traffic spikes because the ASG couldn’t launch new instances due to misconfigured Launch Templates. The error messages are cryptic, the debugging is painful, and it always happens at 2 AM. Get this foundation right, and you’ll thank yourself later.

Common Beginner Mistakes I See Constantly

Two patterns cause about 80% of Launch Template headaches for beginners. First, engineers modify running instances directly instead of updating the template and relaunching. This creates configuration drift that becomes a nightmare during scaling events. Second, version confusion leads to teams launching instances from outdated templates because nobody set the default version correctly.

Both mistakes stem from the same root cause: treating Launch Templates like documentation rather than the single source of truth for your instance configuration.

Lab Overview

In this hands-on lab, you’ll build an EC2 Launch Template from scratch, create multiple versions with different configurations, and launch instances using both default and specific versions.

What you’ll build:

• A complete EC2 Launch Template with AMI, instance type, key pair, and network configuration
• Version 1 with baseline settings
• Version 2 with modified instance type and user data
• EC2 instances launched from both template versions

Skills you’ll gain:

• Creating and configuring Launch Templates through the AWS Console
• Managing template versions and setting defaults
• Configuring VPC, subnet, and security group associations
• Implementing a consistent tagging strategy
• Launching instances from specific template versions

Real-world applications: Auto Scaling Groups require Launch Templates. Spot Fleet configurations depend on them. Mixed instance policies, capacity reservations, and placement groups all integrate through Launch Templates. If you’re doing anything beyond single-instance deployments, you’ll use this knowledge daily.

Prerequisites

Before starting this lab, ensure you have:

• An active AWS account with console access
• IAM permissions for EC2 (at minimum: ec2:CreateLaunchTemplate, ec2:RunInstances, ec2:DescribeLaunchTemplates)
• Basic EC2 knowledge (understanding of AMIs, instance types, and key pairs)
• An existing VPC with at least one subnet (the default VPC works perfectly for this lab)
• A security group that allows SSH access (port 22) from your IP
• An EC2 key pair for instance access

Step-by-Step Hands-On Lab

Step 1: Navigate to Launch Templates

Open the AWS Console and navigate to EC2 → Launch Templates in the left sidebar under “Instances.” Click Create launch template to begin.

Why this matters: Launch Templates live under the EC2 service but operate independently from running instances. This separation is intentional — templates define what instances should look like, not the instances themselves.

What you should see: A form with collapsible sections for template name, AMI, instance type, key pair, network settings, storage, and advanced details.

Step 2: Configure Base Template Settings

Enter the following base configuration:

Launch template name: web-server-template

Template version description: Baseline configuration with t2.micro

Auto Scaling guidance: Check the box for “Provide guidance to help me set up a template that I can use with EC2 Auto Scaling.” This enables validation warnings that catch common misconfigurations.

Application and OS Images (AMI): Click “Quick Start” and select Amazon Linux 2023. Note the AMI ID — you’ll reference this later when troubleshooting.

Instance type: Select t2.micro (Free Tier eligible). For production, you’d choose based on workload requirements, but t2.micro works perfectly for learning.

Key pair: Select your existing key pair from the dropdown. If you don’t have one, create it now — you cannot add a key pair after instance launch.

Common misconfiguration: Skipping the key pair because “I’ll add it later.” You won’t. The instance will launch without SSH access, and you’ll terminate it five minutes later.

Step 3: Configure Network Settings

Expand the Network settings section and configure:

Subnet: Select a specific subnet from your VPC. Choose a public subnet if you want to SSH into the instance directly.

Firewall (security groups): Select “Select existing security group” and choose a security group that allows SSH (port 22) from your IP address.

Why this matters: Network settings in Launch Templates cascade to every instance launched from that template. Getting this wrong means every Auto Scaling event launches instances into the wrong subnet or with missing security group rules.

What you should see: Your selected subnet’s Availability Zone and CIDR block displayed below the dropdown.

Common misconfiguration: Selecting a private subnet but expecting public SSH access. If your subnet doesn’t have an Internet Gateway route, your instances won’t be reachable from the internet regardless of security group rules.

Step 4: Add Resource Tags

Expand the Resource tags section and add the following tags:

Check both “Tag instances” and “Tag volumes” for each tag. This ensures consistent tagging across all resources created from this template.

Why this matters: I once spent three hours tracking down orphaned EBS volumes because the original Launch Template only tagged instances. When those instances terminated, the volumes remained — untagged and invisible to our cost allocation reports.

Step 5: Create Launch Template (Version 1)

Review your configuration and click Create launch template.

What you should see: A success message with your template ID (format: lt-xxxxxxxxxxxxxxxxx) and a link to view the template.

Navigate to EC2 → Launch Templates and verify your template appears with Version 1 as the default.

Step 6: Create Version 2 with Modified Configuration

Select your template and choose Actions → Modify template (Create new version).

Source template version: Select Version 1 as your starting point.

Template version description: Updated to t2.small with custom user data

Instance type: Change from t2.micro to t2.small.

Advanced details → User data: Add the following bootstrap script:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Launched from Launch Template Version 2</h1>" > /var/www/html/index.html

Click Create launch template version.

Why this matters: Version 2 now differs from Version 1 in two ways: instance size and user data. This is exactly how production versioning works — you iterate on configurations while maintaining the ability to roll back.

Step 7: Set Default Version

Select your template, choose Actions → Set default version, and select Version 2.

What you should see: The “Default version” column now shows “2” for your template.

Common misconfiguration: Forgetting this step and wondering why Auto Scaling keeps launching the old configuration. The default version is what gets used when no version is explicitly specified.

Step 8: Launch Instance from Default Version

Select your template and click Actions → Launch instance from template.

Leave the source template version as “Default” and configure:

Number of instances: 1

Review the summary showing your Version 2 configuration (t2.small with user data) and click Launch instance.

Step 9: Launch Instance from Specific Version

Repeat the launch process, but this time:

Source template version: Select “1” explicitly

This launches a t2.micro instance without the user data script — demonstrating how you can override the default version when needed.

What you should see: Two running instances — one t2.small (from default Version 2) and one t2.micro (from explicitly selected Version 1).

Real Lab Experiences: Architect Insights

Let me share what actually happens in production environments because textbook knowledge only gets you so far.

The version drift disaster: A team I worked with had an Auto Scaling Group running beautifully for months. Then someone updated the Launch Template with a new AMI but forgot to update the default version. The ASG kept launching instances from the old version. When they finally noticed, half their fleet was running outdated software with known vulnerabilities. Version management isn’t optional — it’s a security requirement.

The “just change the instance” trap: Junior engineers often SSH into running instances and install software manually. This works until the Auto Scaling Group terminates that instance and launches a fresh one from the template. The new instance has none of those manual changes. I’ve seen production outages caused by this exact pattern — an “improved” instance gets terminated during a scaling event, and suddenly the application breaks because dependencies are missing.

My advice before you touch production: Treat Launch Templates as immutable. Never modify a version after instances are running from it. Create a new version instead. This gives you a clear audit trail and makes rollback trivial. Also, always test user data scripts in isolation before adding them to templates. A syntax error in user data means your instance launches but your application doesn’t start — and debugging why requires console access or instance metadata inspection.

Validation & Testing

After launching both instances, verify your configuration:

Console verification: Navigate to EC2 → Instances. Select each instance and check the Details tab. Look for “Launch template” — it shows the template ID and version used.

Instance type confirmation: Verify one instance shows t2.micro and the other shows t2.small under “Instance type.”

User data verification: SSH into the t2.small instance and run:

curl http://localhost

You should see: <h1>Launched from Launch Template Version 2</h1>

The t2.micro instance (Version 1) won’t have httpd running because that version had no user data.

Metadata verification: From either instance, query the instance metadata:

curl http://169.254.169.254/latest/meta-data/instance-type

This confirms the instance type matches your Launch Template version.

Troubleshooting Guide

Wrong Launch Template version used: Check if the default version is set correctly. Navigate to Launch Templates, select your template, and verify the “Default version” column. For Auto Scaling Groups, also check the ASG’s Launch Template version setting — it can override the template default.

Security groups not applied: Verify the security group exists in the same VPC as your selected subnet. Cross-VPC security group references fail silently. Run:

aws ec2 describe-security-groups --group-ids sg-xxxxxxxxx

Confirm the VPC ID matches your subnet’s VPC.

Subnet mismatch errors: If you see “The subnet ID ‘subnet-xxx’ does not exist,” your template references a subnet in a different region or the subnet was deleted. Update the template with a valid subnet ID.

Missing tags on instances: Verify you checked “Tag instances” in the Resource tags section. Tags with only “Tag volumes” selected won’t appear on EC2 instances.

User data not executing: Check /var/log/cloud-init-output.log on the instance for errors. Common causes: missing shebang (#!/bin/bash), incorrect line endings (Windows CRLF instead of Unix LF), or script syntax errors.

sudo cat /var/log/cloud-init-output.log | tail -50

Auto Scaling failures: If ASG launches fail, check the Activity history. Common Launch Template issues include: invalid AMI (deleted or wrong region), instance type not available in the selected Availability Zone, or insufficient capacity for the requested instance type.

AWS Best Practices: Solutions Architect Level

Security: Treat Launch Templates as infrastructure code. Store them in version control (using CloudFormation or Terraform), review changes through pull requests, and never edit templates directly in the console for production workloads. Apply least-privilege IAM — teams should have permission to launch from templates but not modify them.

Reliability: Pin Auto Scaling Groups to specific Launch Template versions rather than using “Latest” or “Default.” This prevents unexpected configuration changes during scaling events. When updating, create a new version, test it with a single instance, then update the ASG.

Cost Optimization: Use Launch Templates to enforce instance type standards. By controlling which instance types appear in templates, you prevent developers from accidentally launching expensive instances. Combine with Spot configurations in the same template for significant savings.

Operational Excellence: Implement a naming convention that includes purpose and environment: {app}-{component}-{env}-template. Add a ManagedBy tag indicating whether the template is managed manually or through IaC.

Tagging Strategy: At minimum, tag with: Name, Environment, Owner, CostCenter, and ManagedBy. Propagate tags to both instances and volumes. This enables accurate cost allocation and simplifies resource identification during incidents.

AWS Interview Questions: EC2 Launch Templates

These questions appear regularly in AWS Solutions Architect, DevOps Engineer, and SysOps Administrator interviews. Understanding the reasoning behind each answer matters more than memorization.

Question 1: What is the difference between EC2 Launch Templates and Launch Configurations?

Strong Answer: Launch Templates are the modern replacement for Launch Configurations with several critical advantages. Launch Templates support versioning, allowing you to iterate on configurations while maintaining rollback capability. They support multiple instance types in a single template (essential for mixed instance Auto Scaling policies), Spot instance configurations, and dedicated host placement. Launch Configurations are immutable — any change requires creating a new configuration entirely. AWS has made Launch Templates mandatory for newer Auto Scaling features like mixed instances policies and capacity rebalancing. For any new infrastructure, Launch Templates are the only sensible choice.

Why interviewers ask this: They want to know if you understand AWS’s evolution and whether you’ll build infrastructure using current best practices or legacy patterns.

Question 2: How do Launch Template versions work, and when would you use a specific version versus the default?

Strong Answer: Each Launch Template can have multiple versions, with one designated as the default. When you launch an instance or configure an Auto Scaling Group without specifying a version, AWS uses the default. You’d use a specific version when you need predictable, immutable deployments — for example, pinning an Auto Scaling Group to version 5 ensures that scaling events always launch identical instances, even if someone creates version 6 later. You’d use the default version for development environments where you want automatic adoption of the latest configuration. In production, I always recommend pinning to specific versions and updating ASGs deliberately after testing.

Why interviewers ask this: Version management directly impacts deployment reliability. This question reveals whether you’ve dealt with production scaling issues.

Question 3: An Auto Scaling Group keeps launching instances with outdated configurations. How would you troubleshoot this?

Strong Answer: I’d start by checking three things. First, which Launch Template version is the ASG configured to use — it might be pinned to an old version rather than using default or latest. Second, if it’s set to use the default version, I’d verify which version is actually marked as default in the Launch Template. Third, I’d check if there’s a mixed instances policy overriding the base template settings. The CLI command aws autoscaling describe-auto-scaling-groups shows the exact Launch Template version the ASG uses. I’d also review the ASG’s activity history to confirm which template version recent launches used.

Why interviewers ask this: This is a real production scenario. They want to see your debugging methodology and whether you understand the relationship between ASGs and Launch Templates.

Question 4: How would you implement a blue-green deployment strategy using Launch Templates?

Strong Answer: I’d create a new Launch Template version with the updated AMI or configuration (the “green” version). Then I’d create a new Auto Scaling Group using this version, let it scale up and pass health checks, and shift traffic using a load balancer — either by updating target group weights or switching listener rules. Once validated, I’d scale down the old ASG. The key is never modifying the existing template version — immutability ensures I can roll back by simply shifting traffic back to the original ASG. I’d also keep the old ASG running (scaled to zero) for at least 24 hours before deletion in case issues appear later.

Why interviewers ask this: Deployment strategies reveal your operational maturity. They’re checking if you understand immutable infrastructure principles.

Question 5: What happens if a Launch Template references an AMI that no longer exists?

Strong Answer: Instance launches fail immediately. The ASG’s activity history shows a “launching failed” event with an error indicating the AMI doesn’t exist. This is particularly dangerous because the failure only manifests during scaling events — your current instances keep running, but no new ones can launch. I’ve seen this cause outages when teams deleted “old” AMIs without checking which Launch Templates referenced them. Best practice is to never delete AMIs until you’ve verified no Launch Templates or ASGs reference them, and to implement AMI lifecycle policies that account for template dependencies.

Why interviewers ask this: AMI management is a common operational gap. This question tests whether you’ve experienced (and learned from) this failure mode.

Question 6: How do you handle sensitive data like database passwords in Launch Template user data?

Strong Answer: Never put secrets directly in user data — it’s stored unencrypted and visible to anyone with EC2 describe permissions. Instead, I’d have the user data script retrieve secrets at boot time from AWS Secrets Manager or Parameter Store (with SecureString). The instance needs an IAM role with permission to access those specific secrets. This way, the Launch Template contains only the retrieval logic, not the secrets themselves. For additional security, I’d use VPC endpoints for Secrets Manager to keep traffic off the public internet.

Why interviewers ask this: Security practices in automation reveal whether you’ll create vulnerabilities at scale. This is often a follow-up if your earlier answers mentioned user data.

Frequently Asked Questions (FAQs)

What This Lab Unlocks Next

If you skip Launch Templates and jump straight into Auto Scaling Groups, you’ll end up fighting configuration drift, broken scaling events, and unpredictable deployments. This lab is not optional — it’s foundational. Every concept you learned here directly applies to Auto Scaling, Spot Fleet, and capacity management.

You’ve now built an EC2 Launch Template from scratch, created multiple versions with different configurations, and launched instances from both default and specific versions. These skills form the foundation for everything that follows — Auto Scaling Groups, Spot Fleet configurations, and immutable infrastructure patterns all depend on properly configured Launch Templates.

The key takeaways: treat templates as your source of truth, version everything, and never manually modify running instances when you should be updating templates instead.

Related Resources:

• AWS Launch Templates Documentation
• Auto Scaling with Launch Templates

Related post: EC2 Security Groups Deep Dive

Related post: User Data and Bootstrapping Guide