When managing Auto Scaling Groups with Elastic Load Balancing, we often face this dilemma: How to modify configurations in our golden AMI without going through the entire AMI recreation cycle. The traditional approach creates operational overhead:

1. Launch instance from current AMI
2. SSH into instance and make configuration changes
3. Create new AMI from modified instance
4. Update Auto Scaling Group launch configuration
5. Deprecate old AMI

This process becomes particularly painful when dealing with frequent Tomcat configuration updates or application WAR file changes.

Here are several techniques to achieve configuration updates without AMI recreation:

1. User Data Scripts for Runtime Configuration

Modify your launch configuration to include user data scripts that fetch and apply configuration changes during instance launch:

#!/bin/bash
# Fetch latest Tomcat configuration from S3
aws s3 cp s3://my-config-bucket/tomcat/server.xml /opt/tomcat/conf/server.xml
systemctl restart tomcat

2. External Configuration Management

Implement a configuration management system that pulls updates after instance launch:

# Example using AWS Systems Manager
aws ssm get-parameter --name "/tomcat/prod/server.xml" --with-decryption \
--query "Parameter.Value" --output text > /opt/tomcat/conf/server.xml

3. EBS Volume Swap Technique

For more complex changes, you can attach the AMI's EBS volume to a running instance:

# Identify the snapshot ID from your AMI
aws ec2 describe-images --image-ids ami-12345678 --query "Images[0].BlockDeviceMappings[0].Ebs.SnapshotId"

# Create new volume from snapshot
aws ec2 create-volume --snapshot-id snap-1234567890abcdef0 --availability-zone us-east-1a

# Attach to running instance, modify, then create new snapshot
aws ec2 attach-volume --volume-id vol-1234567890abcdef0 --instance-id i-1234567890abcdef0 --device /dev/sdf

• Store all configurations outside AMIs (S3, Parameter Store, Secrets Manager)
• Use immutable infrastructure patterns where possible
• Implement canary deployments for configuration changes
• Monitor configuration drift across your fleet

If you absolutely need to modify the original AMI while keeping the same AMI ID (which isn't technically possible), consider:

# Deregister old AMI (after ensuring no instances use it)
aws ec2 deregister-image --image-id ami-12345678

# Create new AMI with identical name/tags
aws ec2 register-image --name "MyAppServer" --block-device-mappings [...]

Remember this approach has significant drawbacks and should only be used in exceptional cases.

---

When managing Auto Scaling Groups (ASGs) with Elastic Load Balancing (ELB), the traditional AMI update workflow becomes particularly painful:

Launch AMI instance → SSH configuration changes → Create new AMI → Update ASG launch template → Deregister old AMI

This process introduces several challenges:

• AMI ID changes require ASG launch template updates
• Version control becomes complex with multiple AMIs
• Rollback procedures are more difficult

1. User Data Scripts for Runtime Configuration

The most elegant solution is to move configuration out of the AMI and into user data:

#!/bin/bash
# Update Tomcat configuration during instance launch
sudo sed -i 's/MAX_THREADS=.*/MAX_THREADS=200/' /opt/tomcat/conf/server.xml
sudo systemctl restart tomcat

2. AWS Systems Manager (SSM) for Configuration Management

For more complex scenarios, use SSM to push configuration changes:

aws ssm create-document \
  --name "TomcatConfigUpdate" \
  --content file://tomcat_config.json \
  --document-type "Command"

# Sample JSON document:
{
  "schemaVersion": "2.2",
  "description": "Update Tomcat configuration",
  "parameters": {
    "ThreadCount": {
      "type": "String",
      "default": "200"
    }
  },
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "UpdateConfig",
      "inputs": {
        "runCommand": [
          "sed -i 's/MAX_THREADS=.*/MAX_THREADS={{ThreadCount}}/' /opt/tomcat/conf/server.xml",
          "systemctl restart tomcat"
        ]
      }
    }
  ]
}

3. Elastic Filesystem for Configuration

Mount configuration files from EFS:

# /etc/fstab entry
fs-12345678.efs.us-east-1.amazonaws.com:/tomcat-config /opt/tomcat/conf nfs defaults 0 2

For cases where AMI modification is unavoidable:

# Create new AMI and update launch template
aws ec2 create-image --instance-id i-1234567890abcdef0 --name "updated-tomcat-ami"

# Update ASG launch template version
aws ec2 create-launch-template-version \
  --launch-template-id lt-0123456789abcdef0 \
  --source-version 1 \
  --launch-template-data '{"ImageId":"ami-9876543210fedcba"}'

• Keep AMIs as minimal as possible
• Externalize all configuration
• Use tags for version tracking (e.g., "AppVersion=2.3.1")
• Implement automated cleanup of old AMIs

Remember: The goal isn't to avoid creating new AMIs entirely, but to minimize unnecessary AMI updates by separating configuration from infrastructure.