EC2 — Instances, AMIs, and Auto Scaling

Understanding EC2 Instance Types

EC2 instances are virtualized servers designed for specific workload profiles, such as compute-heavy, memory-intensive, or general-purpose tasks. Understanding the 'why' behind instance types is critical: they represent different physical hardware allocations on the underlying host. For example, 'c' series instances prioritize high-performance processors, while 'r' series emphasize large memory footprints for database caching. Selecting the right type prevents over-provisioning and ensures cost-efficiency. If your application crashes due to out-of-memory errors, you shift to a memory-optimized family; if it lags due to CPU bottlenecks, you switch to compute-optimized. By matching your application's resource fingerprint to the instance specification, you achieve optimal performance at the lowest possible cost. This logical mapping of requirements to hardware capabilities is the first step in designing a resilient cloud infrastructure.

# Example of identifying instance configuration using command line
aws ec2 describe-instance-types \
    --instance-types m5.large \
    --query "InstanceTypes[0].{CPU:VCpuInfo.DefaultVCpus, RAM:MemoryInfo.SizeInMiB}"

The Role of Amazon Machine Images (AMIs)

An Amazon Machine Image (AMI) acts as the blueprint for your instance, containing the operating system, file system permissions, and pre-installed software applications. Think of an AMI as a snapshot of a configured virtual machine. When you launch an instance, the system reads this blueprint to instantiate the volume structure. The reason we use AMIs is to achieve repeatable, immutable infrastructure. Instead of manually configuring a server every time, you bake your required environment—including security patches and runtime dependencies—into a custom AMI. This eliminates 'configuration drift,' where individual servers become unique snowflake environments that are impossible to troubleshoot. By treating your server configuration as a versioned image, you ensure that every instance launched is identical, predictable, and ready for service, which simplifies deployment pipelines and disaster recovery scenarios.

# Creating a custom AMI from an existing instance to use as a deployment baseline
aws ec2 create-image \
    --instance-id i-0abcdef1234567890 \
    --name "Production-Web-Server-v2" \
    --description "Hardened web server with security patches applied"

Bootstrapping Instances with User Data

While AMIs provide the static base, User Data allows you to perform dynamic configuration at runtime. User Data scripts are executed automatically when an instance starts for the first time. This is the crucial 'glue' that bridges the gap between a generic AMI and a specialized application server. By injecting variables or fetching secrets at boot, your architecture becomes flexible enough to adapt to its environment without human intervention. This mechanism is essential for scaling, as it allows new instances to automatically register themselves with load balancers or connect to persistent databases without manual setup. By keeping your AMIs 'thin' and using User Data for 'last-mile' configuration, you maintain a modular architecture where the base image rarely changes, but the behavior of your cluster remains highly customizable and responsive to environmental changes.

# A bash script provided in User Data to initialize a web server
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
echo "<h1>Hello from EC2</h1>" > /var/www/html/index.html

Auto Scaling Groups (ASG)

Auto Scaling Groups (ASG) manage the lifecycle of your EC2 instances to maintain the desired capacity and respond to fluctuating demand. An ASG works by monitoring health checks and performance metrics, automatically launching or terminating instances to match your defined criteria. The logic here is centered on elasticity: by automating the replacement of unhealthy nodes and the expansion of the fleet during traffic spikes, you ensure high availability without manual oversight. ASGs decouple your application state from the individual server instance, which is critical because cloud instances are inherently ephemeral. If an instance experiences a hardware failure, the ASG detects the failed health check and replaces it instantly with a fresh instance, ensuring that your application stays operational regardless of the underlying physical status of the hardware.

# Create an Auto Scaling Group to ensure constant capacity
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name WebServerGroup \
    --launch-template LaunchTemplateId=lt-0123456789,Version='$Latest' \
    --min-size 2 --max-size 10 --desired-capacity 3

Scaling Policies for Dynamic Demand

Scaling policies dictate when the ASG should add or remove instances, based on real-world triggers. Target Tracking policies are the industry standard: you define a goal, such as 'maintain CPU utilization at 50%,' and the system dynamically adjusts the instance count to keep performance within that target window. The reasoning behind this is predictive efficiency: instead of waiting for a manual alert to scale, the system monitors trends and adjusts resources proactively. By combining scaling policies with cooldown periods, you prevent the 'flapping' effect, where the system constantly adds and removes nodes in response to noise in the telemetry data. A well-tuned scaling policy balances cost and performance, ensuring you have exactly as much compute as you need to handle current request volumes, effectively optimizing your financial and operational overhead in real-time.

# Scaling policy to keep average CPU usage at 50%
aws autoscaling put-scaling-policy \
    --auto-scaling-group-name WebServerGroup \
    --policy-name CPU50Policy \
    --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{"TargetValue": 50.0, "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"}}'

Interview questions

All AWS interview questions →

Check yourself

Take the full AWS quiz →