AWS Academy Cloud Architecting — Module 4: Adding a Compute Layer

Module Objective: Add a compute layer to a cloud architecture using Amazon EC2, and make informed decisions about AMIs, instance types, storage, and purchasing options.

Builds on Module 3: The compute layer is where application logic runs, reading from and writing to the storage layer already in place.

Architectural Need for Compute

A storage-only architecture can serve static content, but any dynamic behavior — processing user input, running application logic, connecting to a database — requires a compute layer. Amazon EC2 is the most direct, IaaS-level way to add one.

🔵 Note Not every architecture needs EC2 specifically — Modules 10 and 13 introduce alternatives like Elastic Beanstalk and AWS Lambda — but EC2 is the baseline this course builds the compute layer on first.

Choosing an AMI to Launch an EC2 Instance

The Amazon Machine Image chosen at launch determines the starting operating system, pre-installed software, and configuration of every instance built from it — making it one of the first and most consequential compute decisions.

AMI Source	Consideration
AWS-provided AMI	Maintained and patched by AWS; a safe, well-documented starting point
AWS Marketplace AMI	Pre-configured commercial software, often with an additional software licensing cost
Community AMI	Shared by other AWS users; convenient, but should be vetted before production use
Custom AMI	Built from an existing, configured instance; ensures consistency across every instance launched from it

✅ Tip — Custom AMIs Support Consistency at Scale Once an instance is configured the way an application needs, creating a custom AMI from it — and using that AMI in an Auto Scaling group's launch template (Module 9) — keeps every new instance identically configured.

Selecting an EC2 Instance Type

Instance type selection is a direct application of matching the instance family (general purpose, compute optimized, memory optimized, and so on) to the actual resource profile the workload needs — reviewed in AWS Academy Cloud Foundations and applied here to a real design decision.

⚠️ Warning — Right-Sizing Is Ongoing, Not One-Time An instance type chosen at launch isn't permanent — architects regularly revisit instance type based on observed CloudWatch metrics (Module 9) rather than treating the initial choice as final.

Using User Data to Configure an Instance

EC2 user data is a script or set of commands passed to an instance at launch time, letting it configure itself automatically — installing software, applying settings, or joining a cluster — without manual intervention after boot.

🔵 Note User data runs once at first boot by default. It's a lightweight alternative to baking every configuration into a custom AMI, and the two approaches are often combined.

Adding Storage to an EC2 Instance

An EC2 instance typically needs at least a root volume for the operating system, and often additional volumes for application data — decisions that connect directly back to the block storage concepts (Amazon EBS) from AWS Academy Cloud Foundations.

Storage Option	Use
Amazon EBS root volume	Persistent storage for the operating system, surviving stop/start cycles
Additional EBS volumes	Separate persistent storage for application data, databases, or logs
Instance store	Temporary, high-performance storage physically attached to the host, lost when the instance stops

⚠️ Warning — Instance Store Is Ephemeral Data on instance store volumes doesn't survive a stop, terminate, or underlying hardware failure — it's suited only to temporary data such as caches or buffers, never anything that must persist.

EC2 Pricing Options and Design Considerations

Choosing among On-Demand, Reserved, Savings Plans, and Spot purchasing options — reviewed in AWS Academy Cloud Foundations — becomes an architectural decision here, made per workload based on predictability and fault tolerance.

Beyond pricing, other compute design considerations include placement across Availability Zones for resilience, and whether the workload is stateless (easy to scale horizontally) or stateful (requiring more careful design).

✅ Tip — Stateless Is Easier to Scale A stateless compute layer — one that doesn't store session data locally on the instance — can be scaled horizontally and replaced freely, which is why later modules on elasticity (Module 9) and decoupling (Module 12) favor stateless designs.

Key Terms for Module 4

user data: A script passed to an EC2 instance at launch to automatically configure it
custom AMI: An Amazon Machine Image built from a pre-configured instance, ensuring consistency across future launches
instance store: Temporary, high-performance storage physically attached to an EC2 host, lost when the instance stops
stateless compute: A compute design that doesn't store session data locally, making it easier to scale and replace instances

Review Questions

What decision does choosing an AMI make on behalf of every instance launched from it?
How does EC2 user data differ from baking configuration into a custom AMI, and when might both be used together?
Why is data on an EC2 instance store considered ephemeral, and what kind of data belongs there?
Why do later modules on elasticity and decoupling favor a stateless compute design?