Amazon EC2 Architecture Patterns and Design Decisions – SAP-C02 Study Guide

Purpose of This Lesson

Amazon EC2 architecture questions often describe a workload requirement and ask for the most appropriate combination of instance configuration, networking, placement, resiliency, or pricing model. The key is to map the requirement to the EC2 feature that directly addresses it without adding unnecessary complexity.

This guide covers common EC2 patterns for bootstrapping, high-performance computing, burst capacity, static IP failover, private-subnet access, placement groups, and enhanced networking.

Key Concepts

EC2 User Data for First-Boot Configuration

EC2 user data allows a script or cloud-init configuration to run when an instance launches. It is commonly used to:

• Install packages
• Configure services
• Write configuration files
• Register an instance with another system
• Perform lightweight initialization tasks

For a short Linux shell script, place the script in the instance’s user data. The EC2 user data size limit is approximately 16 KB before encoding considerations. Larger or more complex bootstrap logic should be stored in Amazon S3 or managed through AWS Systems Manager rather than embedded directly in user data.

User data is primarily a launch-time mechanism. It should not be treated as a general-purpose configuration-management system for ongoing drift correction.

Cluster Placement Groups and HPC

A cluster placement group places instances close together within a single Availability Zone. This is intended for workloads that require:

• Very low network latency
• High network throughput
• Frequent communication between compute nodes
• Tightly coupled processing

Typical examples include tightly coupled High Performance Computing (HPC), scientific simulations, and distributed applications with intensive east-west traffic.

Elastic Fabric Adapter (EFA) provides an operating-system-bypass capability designed for supported HPC and machine learning workloads. A common architecture is:

• Select an EFA-supported EC2 instance type
• Launch the instances in the same Availability Zone
• Use a cluster placement group
• Configure the application and operating system for EFA

This pattern prioritizes node-to-node performance over Availability Zone-level resilience. A single-AZ cluster placement group is not appropriate when the primary requirement is cross-AZ fault tolerance.

Combining Reserved Capacity with Spot Capacity

A workload with a predictable baseline and occasional bursts can use multiple purchasing options:

Workload portion	Suitable option	Reason
Stable, continuously required baseline	Reserved Instances or Savings Plans	Lower cost for predictable usage commitment
Interruptible, temporary burst capacity	Spot Instances	Deep discounts in exchange for possible interruption
Unpredictable or noninterruptible demand	On-Demand Instances	Flexibility and no long-term commitment

Spot Instances are suitable only when the application can tolerate interruption, replacement, or reduced capacity. They should generally be used for stateless workers, queued jobs, batch processing, or horizontally scalable components rather than irreplaceable stateful nodes.

Elastic IP Address Failover

An Elastic IP address is a static public IPv4 address allocated to an AWS account in a Region. It can be associated with an EC2 instance and then reassociated with a replacement instance when a failure occurs.

A failover design can use automation to:

1. Detect an instance failure.
2. Start or select a replacement instance.
3. Disassociate the Elastic IP from the failed instance if necessary.
4. Associate it with the replacement instance.
5. Validate application health.

This pattern is useful for a single-instance application that cannot immediately be placed behind a load balancer. However, an Elastic IP does not make the application highly available by itself. The application still experiences interruption during detection, replacement, and reassociation.

For a scalable web application, an Application Load Balancer or Network Load Balancer with multiple targets is usually a better design than relying on an Elastic IP failover process.

Private Subnets and Redundant Internet Egress

Instances in private subnets can initiate outbound IPv4 connections through a NAT gateway in a public subnet. The private subnet route table must direct internet-bound traffic to the NAT gateway, while the NAT gateway’s public subnet route table directs traffic to an internet gateway.

For high availability across multiple Availability Zones, deploy a NAT gateway in each Availability Zone and route each private subnet to the NAT gateway in the same Availability Zone. This avoids dependence on a single-AZ NAT gateway and also helps avoid unnecessary cross-AZ data transfer charges.

A typical design is:

• Private subnet in AZ-A routes 0.0.0.0/0 to NAT gateway in AZ-A.
• Private subnet in AZ-B routes 0.0.0.0/0 to NAT gateway in AZ-B.
• Each NAT gateway is deployed in a public subnet.
• Public subnet route tables point to an internet gateway.

NAT gateways provide outbound connectivity initiated from private resources. They do not provide unsolicited inbound internet access to instances in private subnets.

Bastion Hosts for SSH Administration

A bastion host, or jump host, is an EC2 instance in a public subnet that provides an administrative entry point to instances in private subnets. Engineers connect to the bastion host and then use SSH to connect to the private instances.

Security controls should include:

• Restricting inbound SSH to approved corporate or VPN source IP ranges
• Allowing SSH from the bastion security group to the private-instance security group
• Using key-based authentication or an approved identity solution
• Applying operating system patching and logging to the bastion
• Avoiding broad access such as 0.0.0.0/0 on TCP port 22

For many modern environments, AWS Systems Manager Session Manager is preferable because it can provide shell access without exposing SSH or deploying a public bastion host. If a question specifically requires SSH from remote locations and does not offer Session Manager as an option, a bastion host is the conventional answer.

Spread Placement Groups

A spread placement group places instances on distinct underlying hardware. It is intended to reduce the chance that a hardware failure affects multiple instances at the same time.

Use a spread placement group when the principal requirement is minimizing correlated hardware failure, especially for a small number of critical instances. Instances are distributed across separate racks and associated infrastructure where possible.

Spread placement groups have capacity limitations. A common constraint is a maximum of seven running instances per Availability Zone per spread placement group, although other service and instance-specific limits may apply. This makes spread placement groups more appropriate for small, critical fleets than for large-scale horizontal deployments.

Enhanced Networking with ENA

Enhanced networking provides higher packet-per-second performance, higher bandwidth, and lower latency than traditional virtual network interfaces. Modern EC2 instance types generally use the Elastic Network Adapter (ENA) for this capability.

To use ENA enhanced networking:

• Select an instance type that supports ENA.
• Use an AMI with the appropriate ENA driver or module.
• Confirm that ENA support is enabled for the instance.
• Verify the operating system and driver version during image creation or migration.

Many AWS-provided Linux AMIs already include the required ENA support. Custom or older AMIs may require driver installation and configuration.

Enhanced networking is distinct from EFA. ENA improves general-purpose network performance, while EFA is designed for specialized low-latency HPC and distributed computing workloads.

Nitro-Based Instances and Near Bare-Metal Performance

The AWS Nitro System provides dedicated hardware and a lightweight virtualization model that enables high performance and reduced virtualization overhead. Nitro-based instance types can provide performance close to bare metal for many workloads.

When a scenario requires high network performance or EFA, select an instance type that explicitly supports the required feature. Do not assume that every Nitro instance supports EFA. Verify the instance family’s EFA compatibility and the workload’s software requirements.

Exam-Relevant Takeaways

• Use EC2 user data for short, first-boot scripts; remember the roughly 16 KB limit.
• Use a cluster placement group in one Availability Zone for tightly coupled HPC workloads that need low latency between instances.
• EFA requires supported instance types and workload configuration; it is not interchangeable with standard ENA enhanced networking.
• Use Reserved Instances or Savings Plans for predictable baseline usage and Spot Instances for interruptible bursts.
• An Elastic IP can be remapped programmatically to a failover instance, but it does not eliminate failover interruption.
• For redundant private-subnet internet access, use NAT gateways across Availability Zones and route each private subnet to a local NAT gateway.
• A bastion host enables SSH access to private instances, but Systems Manager Session Manager is often a more secure operational alternative.
• Use spread placement groups to reduce correlated hardware failures for small, critical fleets.
• ENA support depends on both the instance type and the AMI or operating system driver configuration.
• Nitro improves virtualization performance, but EFA support must still be checked per instance type.

Architecture Decision Guide

Requirement	Recommended EC2 pattern	Important qualification
Short Linux configuration script at launch	EC2 user data	Keep the payload within the approximately 16 KB limit
Tightly coupled HPC nodes	Same-AZ cluster placement group with EFA-supported instances	Optimizes latency, but reduces AZ-level isolation
Predictable workload with occasional bursts	Reserved Instances or Savings Plans for baseline plus Spot for burst	Burst workers must tolerate interruption
Static public IP must move after instance failure	Elastic IP with automated reassociation	Recovery includes detection and reassociation delay
Private instances need redundant outbound IPv4 internet access	NAT gateway per AZ with local private-subnet routes	NAT gateways incur hourly and data-processing charges
SSH access to private instances	Bastion host in a public subnet	Prefer Session Manager where SSH is not mandatory
Minimize correlated hardware failures	Spread placement group	Limited scale per AZ; useful for small critical fleets
Higher general-purpose network performance	ENA-enabled instance and AMI	Verify drivers and instance support
Near bare-metal virtualization performance	Suitable Nitro-based instance	Nitro does not automatically imply EFA support

Common Exam Traps

• Choosing a cluster placement group for fault isolation: Cluster placement groups optimize proximity and network performance. They do not spread instances across separate hardware for failure isolation.
• Using one NAT gateway for all Availability Zones: This creates a dependency on one AZ and may introduce cross-AZ traffic. For resilient designs, use one NAT gateway per AZ.
• Treating an Elastic IP as a high-availability solution: An Elastic IP only provides address remapping. It does not provide health checks, load balancing, or zero-downtime failover.
• Using Spot Instances for mandatory capacity: Spot capacity can be interrupted. Keep critical baseline capacity on a more reliable purchasing model.
• Assuming all AMIs support enhanced networking automatically: The instance type, AMI, driver, and operating system configuration must all support ENA.
• Assuming all Nitro instances support EFA: EFA is available only on specific supported instance types and requires compatible software.
• Selecting a bastion host when the requirement is simply secure administration: If Session Manager is available and SSH is not explicitly required, it may eliminate public administrative exposure.
• Using spread placement groups for a large fleet: Their per-AZ capacity constraints make them unsuitable for many-instance deployments compared with other scaling and placement strategies.

Real-World Engineer Notes

• Prefer immutable AMIs, EC2 Image Builder, or Systems Manager automation when initialization becomes complex. Large user data scripts are harder to test and troubleshoot.
• Store bootstrap logs and application initialization status so failed launches can be diagnosed through automated replacement workflows.
• Design Spot workloads around interruption notifications, checkpointing, queues, and graceful draining.
• If an Elastic IP is part of failover automation, make reassociation idempotent and include health validation before directing traffic to the replacement.
• NAT gateway resiliency should be evaluated alongside cost. For private workloads that only need access to AWS services, VPC endpoints can reduce NAT traffic and processing charges.
• A bastion host is itself a production security boundary. Limit its access, patch it, monitor it, and avoid using it as a general-purpose workload server.
• Placement groups are not a substitute for application-level resilience. Critical applications should still use replication, health checks, automated recovery, and tested failure procedures.

Quick Reference Summary

• User data: Short launch-time automation; approximately 16 KB limit.
• Cluster placement group: Same-AZ proximity for low-latency, high-throughput node communication.
• EFA: Specialized interface for supported HPC and distributed workloads.
• Reserved capacity: Cost-effective for predictable baseline usage.
• Spot: Cost-effective for interruptible, flexible workloads.
• Elastic IP: Static IPv4 address that can be reassociated during failover.
• NAT gateway: Outbound IPv4 internet access for private subnets; deploy per AZ for resilience.
• Bastion host: SSH jump point into private subnets; Session Manager is often preferable.
• Spread placement group: Separates instances across underlying hardware to reduce correlated failures.
• ENA: Enhanced general-purpose networking.
• Nitro: High-performance EC2 virtualization platform; verify EFA support separately.

Flashcards

1. Q: What is EC2 user data commonly used for?

A: Short launch-time initialization scripts and configuration, such as installing packages or starting services.

1. Q: What approximate size limit applies to EC2 user data?

A: Approximately 16 KB before encoding considerations.

1. Q: Which placement group is suited to tightly coupled HPC workloads?

A: A cluster placement group, normally within a single Availability Zone.

1. Q: What does EFA provide?

A: Specialized low-latency, high-performance networking for supported HPC and distributed workloads.

1. Q: How should predictable baseline EC2 capacity and interruptible bursts be priced?

A: Use Reserved Instances or Savings Plans for the baseline and Spot Instances for suitable burst capacity.

1. Q: What EC2 feature allows a static public IPv4 address to move to a replacement instance?

A: An Elastic IP address.

1. Q: How should private subnets obtain resilient outbound IPv4 internet access?

A: Deploy NAT gateways in multiple AZs and route each private subnet to a NAT gateway in its local AZ.

1. Q: What is the purpose of a bastion host?

A: To provide a controlled administrative jump point for connecting to instances in private subnets.

1. Q: Which placement group reduces the risk of correlated hardware failures?

A: A spread placement group.

1. Q: What does ENA enable?

A: Enhanced general-purpose EC2 networking with higher throughput and packet-per-second performance.

1. Q: Does every Nitro instance support EFA?

A: No. EFA support must be verified for the specific instance type.

1. Q: Why is one NAT gateway shared across all AZs a potential design problem?

A: It creates a single-AZ dependency and can incur cross-AZ data transfer when other AZs use it.

Practice Questions

Question 1

A research company runs a tightly coupled MPI workload across 32 EC2 instances. The instances exchange large volumes of data and require the lowest possible network latency. Which architecture is most appropriate?

A. Deploy the instances across multiple AZs in a spread placement group.
B. Deploy the instances in one AZ using a cluster placement group and EFA-supported instance types.
C. Deploy the instances across multiple AZs behind an Application Load Balancer.
D. Deploy the instances in a partition placement group without enhanced networking.

Correct answer: B

Explanation: A cluster placement group keeps instances physically close within one AZ, while EFA supports specialized low-latency communication. Spreading nodes across AZs prioritizes resilience but introduces network latency and is not optimal for tightly coupled HPC.

Question 2

A production application requires 20 EC2 instances continuously and needs an additional 10 instances during occasional weekly bursts. The burst processing can tolerate interruption. Which purchasing strategy is most cost-effective?

A. Use On-Demand Instances for all 30 instances.
B. Use Spot Instances for all 30 instances.
C. Use Reserved Instances or a Savings Plan for the baseline and Spot Instances for burst capacity.
D. Use Dedicated Hosts for the baseline and On-Demand Instances for bursts.

Correct answer: C

Explanation: The always-running baseline is suitable for a commitment-based discount. Interruptible burst capacity is a good candidate for Spot Instances, provided the application can replace interrupted workers.

Question 3

EC2 instances run in private subnets in three Availability Zones. They require outbound internet access, and the solution must remain available if one AZ fails. Which design should be selected?

A. Deploy one NAT gateway in a single public subnet and route all private subnets to it.
B. Deploy one NAT gateway per AZ and route each private subnet to the NAT gateway in the same AZ.
C. Assign public IP addresses to all instances.
D. Place an internet gateway directly in each private subnet.

Correct answer: B

Explanation: NAT gateways provide outbound IPv4 access for private subnets. Deploying one per AZ avoids a single-AZ dependency and reduces cross-AZ traffic. Internet gateways attach to the VPC, not directly to subnets.

Question 4

A company has four critical EC2 instances. A hardware failure affecting one rack must not affect the other instances. The company does not need to deploy a large fleet. Which feature should be used?

A. Cluster placement group
B. Spread placement group
C. Auto Scaling group in one subnet
D. Dedicated tenancy for the VPC

Correct answer: B

Explanation: Spread placement groups place instances on distinct underlying hardware to reduce correlated hardware failure. Cluster placement groups optimize proximity and network performance instead.

Question 5

An operations team needs to administer EC2 instances in private subnets from corporate offices using SSH. Which architecture directly satisfies the stated requirement?

A. A bastion host in a public subnet with restricted inbound SSH access
B. An internet gateway attached to each private subnet
C. A NAT gateway that accepts inbound SSH connections
D. An Elastic IP assigned to every private instance

Correct answer: A

Explanation: A bastion host provides a controlled SSH jump point into private instances. NAT gateways support outbound connections initiated from private subnets and do not provide inbound SSH access. In a real deployment, Session Manager may be preferable when direct SSH is not mandatory.