Designing Stateless, Scalable Compute with Amazon EC2 and EC2 Instance Types

EC2 Fundamentals and the Instance Lifecycle

EC2 Instance Families and Use-Case Matching

Stateless vs Stateful Architectures on EC2

AMIs, User Data, and Configuration Management

Designing a Stateless Web Tier Across Multiple AZs

Using User Data to Bootstrap a Stateless EC2 Instance

Here is a practical example of user data for a stateless web server. It installs a simple web app, pulls configuration from SSM Parameter Store, and serves static content from S3. In real environments you would polish security and error handling, but the pattern is exam-relevant.

```bash

#!/bin/bash

Update packages

yum update -y

Install AWS CLI and web server

yum install -y awscli httpd

Enable and start Apache

systemctl enable httpd

systemctl start httpd

Retrieve app config from SSM Parameter Store (requires IAM role)

APP_CONFIG=$(aws ssm get-parameter \

--name "/myapp/config" \

--with-decryption \

--query "Parameter.Value" \

--output text \

--region ${AWS_REGION})

echo "${APP_CONFIG}" > /var/www/html/config.json

Sync static assets from S3 bucket (stateless pattern)

aws s3 sync s3://myapp-static-assets/ /var/www/html/ \

--region ${AWS_REGION}

Simple health check page

echo "OK" > /var/www/html/health.html

```

Key exam takeaways:

• User data often installs agents, pulls configuration, or fetches static assets.
• Durable data (like user uploads) should still be written directly to S3 from the application, not stored on the EC2 root disk.
• The instance must have an IAM role with permissions to read SSM parameters and S3 objects.

This approach keeps the instance replaceable. If Auto Scaling launches a new instance, it will run the same user data, pull the same configuration, and join the fleet with consistent behavior.

Scaling EC2 with Elastic Load Balancing and AWS Auto Scaling

Design Exercise: Fix the Non-Scalable Architecture

Consider this scenario and think through how you would redesign it using the principles in this module.

Current design (problematic)

• A single `m5.large` EC2 instance in one AZ runs a PHP web app.
• Users upload profile pictures; the app stores them on `/var/www/uploads`.
• PHP sessions are stored in the local file system.
• The instance uses a public IP, and Route 53 points directly to it.
• During traffic spikes, the instance CPU reaches 100%, and the site becomes slow or unavailable.
• When the instance is replaced for patching, users lose their sessions and sometimes their images.

Your task

1. Identify at least three design flaws in the current setup.
2. Sketch a new design that:

• Uses a stateless EC2 tier.
• Survives the loss of one AZ.
• Scales with traffic.

1. For each change, explain briefly which AWS service you would use and why.

Hints

• Think about where sessions and uploaded files should live.
• Think about how traffic should reach your app.
• Think about how new instances should be configured.

Pause for a minute and write down your answers. Then compare mentally with this outline:

• Use an ALB + multi-AZ Auto Scaling group of smaller instances.
• Store files in S3 and sessions in ElastiCache or DynamoDB.
• Use an AMI and user data for consistent configuration.

On the actual exam, you will often need to “fix” a similar design by moving state out of EC2 and introducing ELB + Auto Scaling.

Quiz 1: Instance Families and Stateless Design

Test your understanding of instance families and stateless patterns.

Quiz 2: AMIs, User Data, and Auto Scaling

Check how well you understand configuration patterns for EC2 fleets.

Key Term Review: EC2 and Stateless Design

Flip through these cards to reinforce core concepts from this module.

Cost, Performance, and Exam Strategy for EC2 Designs