AWS Compute Services: EC2, Elastic Beanstalk, and Beyond

This guide explores the spectrum of compute options on AWS, ranging from the full control of Infrastructure-as-a-Service (IaaS) with EC2 to the simplified management of Platform-as-a-Service (PaaS) with Elastic Beanstalk and Lightsail.

Learning Objectives

• Evaluate the trade-offs between control and operational overhead across EC2, Elastic Beanstalk, and Lightsail.
• Identify modernization opportunities using AWS Graviton processors for improved price-performance.
• Compare various deployment strategies supported by Elastic Beanstalk, such as blue/green and rolling updates.
• Select the appropriate compute platform based on application complexity and team expertise.

Key Terms & Glossary

• IaaS (Infrastructure as a Service): A cloud model where the provider offers raw compute, storage, and networking; the user manages the OS and runtime (e.g., Amazon EC2).
• PaaS (Platform as a Service): A cloud model where the provider manages the underlying infrastructure and OS, allowing users to focus on application code (e.g., AWS Elastic Beanstalk).
• AWS Graviton: Custom-built ARM64-based processors designed by AWS to deliver up to 25% better performance and better price-efficiency for cloud workloads.
• Blue/Green Deployment: A strategy that reduces downtime by running two identical production environments ("Blue" and "Green") and switching traffic between them.
• Refactoring: The process of modifying application source code to take advantage of cloud-native features or different CPU architectures like Graviton.

The "Big Idea"

In AWS, compute selection is a spectrum of abstraction. On one end, Amazon EC2 provides the ultimate flexibility but requires high operational effort (patching, scaling, etc.). On the other end, Elastic Beanstalk and Lightsail trade that granular control for "speed to market" and reduced management. Modernizing isn't just about moving to the cloud; it's about choosing the right level of abstraction and the right hardware (like Graviton) to optimize costs and performance.

Formula / Concept Box

Hierarchical Outline

1. Amazon EC2 (Infrastructure Control)
   • Full Control: Access to OS, kernel, and hardware configurations.
   • Modernization: Refactoring for ARM64 (Graviton) for 25% better performance.
   • Instance Classes: General purpose (M), Compute-optimized (C), Memory-optimized (R), and Burstable (T).
2. Managed Compute Platforms
   • Amazon Lightsail: Simplified "VPS" experience for SMBs and simple web apps.
   • AWS Elastic Beanstalk: PaaS for web applications (Java, .NET, Node.js, Python, etc.).
     • Handles provisioning (EC2, ASG, ELB, RDS).
     • Supports Docker for non-native runtimes.
3. Deployment & Automation
   • AWS CodeDeploy: Automates deployments across EC2, Lambda, and On-premises.
   • AWS App Runner: High abstraction for containerized web APIs/apps.

Visual Anchors

The Compute Abstraction Spectrum

Elastic Beanstalk High-Level Architecture

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, rounded corners, minimum width=3cm, minimum height=1cm, align=center}]

% Nodes \node (user) [draw=none] {User Traffic}; \node (elb) [below of=user] {Elastic Load Balancer}; \node (asg) [below of=elb, dashed, inner sep=10pt] {Auto Scaling Group}; \node (ec2_1) [below of=elb, xshift=-1.5cm, yshift=-0.5cm, minimum width=1cm] {EC2}; \node (ec2_2) [below of=elb, xshift=1.5cm, yshift=-0.5cm, minimum width=1cm] {EC2}; \node (s3) [right of=elb, xshift=2cm] {Amazon S3$Source Code)}; \node (rds) [below of=asg] {Amazon RDS$Database)};

% Connections \draw[->, thick] (user) -- (elb); \draw[->] (elb) -- (ec2_1); \draw[->] (elb) -- (ec2_2); \draw[<->, dashed] (s3) -- (elb); \draw[->] (ec2_1) -- (rds); \draw[->] (ec2_2) -- (rds);

\end{tikzpicture}

Definition-Example Pairs

• Burstable Performance (T-series): Instances that provide a baseline level of CPU performance with the ability to burst above that baseline.
  • Example: A small blog that has low traffic most of the day but spikes when a new post is shared on social media.
• Managed Service: A service where AWS handles the maintenance, patching, and scaling of the underlying infrastructure.
  • Example: Elastic Beanstalk automatically patches the Amazon Linux OS underlying your Java application.
• Operational Overhead: The time and resources required to manage the infrastructure rather than the core business logic.
  • Example: Manual SSH access to 50 EC2 instances to update security patches vs. using a managed environment.

Worked Examples

Scenario: Modernizing a .NET 5 Legacy Application

Goal: Migrate a legacy .NET application to AWS while reducing costs and management burden.

1. Selection: Choose AWS Elastic Beanstalk as the platform. It natively supports .NET on Linux.
2. Architecture: Select Graviton3 (m6g) instance types.
3. Refactoring: Ensure the .NET code is compatible with ARM64 architecture (common with .NET 5/6+).
4. Deployment: Use the eb init and eb deploy commands from the Beanstalk CLI to push the code.
5. Strategy: Configure Blue/Green deployment to ensure that the production site remains live while the new Graviton-based environment is tested.

Checkpoint Questions

1. What is the primary benefit of choosing Graviton-based EC2 instances over standard x86 instances?
2. If an application requires a specific runtime not natively supported by Elastic Beanstalk, how can a developer still use the service?
3. Which AWS service is specifically designed for small businesses to deploy simple websites without needing to understand cloud terminology?
4. What is the difference between an "In-place" deployment and a "Blue/Green" deployment in terms of risk?

▶Click to see answers

1. Up to 25% better performance and a significantly better price-to-performance ratio.
2. By packaging the application and its dependencies into a Docker container.
3. Amazon Lightsail.
4. In-place deployment modifies existing instances and can cause downtime; Blue/Green creates a new environment, allowing for zero downtime and safer rollbacks.

Muddy Points & Cross-Refs

• Beanstalk vs. App Runner: It can be confusing which to pick. Rule of thumb: If you need access to the underlying EC2 instances for custom agents or specific OS tweaks, use Beanstalk. If you want a purely "serverless" container experience for a web API, use App Runner.
• Lightsail vs. EC2: Lightsail uses EC2 under the hood, but it's a "walled garden." You cannot easily move a Lightsail instance into your main VPC without a specific export process.
• Refactoring for Graviton: Not all code works on ARM64. Low-level C++ or specialized assembly may need significant work, whereas high-level languages (Python, Java, JS) usually work out of the box.

Comparison Tables