Selecting the Appropriate Compute Platform

This guide explores the critical decision-making process for selecting AWS compute services during application migration and modernization, focusing on the trade-offs between control, operational overhead, and architectural patterns.

Learning Objectives

• Analyze application requirements to determine the optimal migration phase (Assess vs. Mobilize).
• Evaluate compute platforms (EC2, ECS, Fargate, Lambda) based on execution time, portability, and dependencies.
• Differentiate between migration strategies: Re-hosting, Re-platforming, and Re-architecting.
• Identify appropriate tools for assessment, such as the Migration Readiness Assessment (MRA) and Schema Conversion Tool (SCT).

Key Terms & Glossary

• AMI (Amazon Machine Image): A template that contains a software configuration (operating system, application server, and applications) required to launch an instance.
• MRA (Migration Readiness Assessment): A process used to evaluate an organization's readiness to move to the cloud and identify gaps.
• SCT (Schema Conversion Tool): A tool that automates the conversion of database schemas from one engine to another.
• Shared Responsibility Model: A security framework where AWS manages security of the cloud, while the customer manages security in the cloud (e.g., patching EC2 OS).
• Monolith: A software architecture where all components are interconnected and interdependent in a single service.

The "Big Idea"

Selecting the right compute platform is a balancing act between Operational Control and Management Overhead. Moving from EC2 to Lambda represents a shift from managing infrastructure to managing code, trading granular control for increased agility and cost-efficiency. The ultimate goal is to select the platform that minimizes disruption while maximizing the benefits of cloud-native features like auto-scaling and event-driven execution.

Formula / Concept Box

Hierarchical Outline

1. Migration Frameworks
   • Assess Phase: Analyzing complexity using MRA and SCT.
   • Mobilize Phase: Devising the migration plan.
2. Core Compute Offerings
   • Amazon EC2: IaaS offering for raw compute; requires manual OS management.
   • Amazon Lightsail: Simplified VPS for small-scale applications and websites.
3. Managed and Container Services
   • Elastic Beanstalk: PaaS for deploying web apps; supports Re-platforming.
   • Amazon ECS/EKS: Container orchestration for microservices; requires Docker packaging.
   • AWS Fargate: Serverless engine for containers; removes the need to manage EC2 nodes.
4. Serverless Computing
   • AWS Lambda: Event-driven, pay-per-execution; requires Re-architecting to microservices.

Visual Anchors

Compute Selection Decision Flow

Management vs. Control Spectrum

Definition-Example Pairs

• Re-hosting (Lift-and-Shift): Moving an application as-is to the cloud.
  • Example: Moving a legacy .NET monolith running on a physical server directly onto an Amazon EC2 Windows instance.
• Re-platforming (Lift-and-Reshape): Making minor adjustments to optimize for the cloud without changing core architecture.
  • Example: Moving a Java application to Amazon Elastic Beanstalk to automate scaling and patching while keeping the code largely the same.
• Re-architecting (Refactoring): Reimagining the application using cloud-native features.
  • Example: Decomposing a monolithic e-commerce site into individual AWS Lambda functions for "Order," "Payment," and "Shipping."

Worked Examples

Scenario: Migrating a Legacy .NET Monolith

The Challenge: A customer has a large .NET 4.5 application. They want to migrate to AWS with minimal disruption but wish to reduce management overhead eventually.

Step 1: Assessment Use the Migration Readiness Assessment (MRA) to determine organizational readiness and the Schema Conversion Tool (SCT) if a database is involved. Determine that the code is currently tightly coupled.

Step 2: Initial Migration (The "Quick Win") Select Amazon EC2 with a Windows AMI. This is a Re-host strategy.

[!NOTE] To improve availability here, use an Auto Scaling Group across multiple Availability Zones.

Step 3: Modernization Pathway Suggest moving to .NET Core and containerizing the application using Docker. Once containerized, it can be hosted on Amazon ECS or Fargate, achieving a Re-platform or Re-factor result with lower operational overhead.

Checkpoint Questions

1. If an application requires a custom kernel module that is not provided by AWS, which compute service must you use?
2. What is the maximum execution duration for a single AWS Lambda function invocation?
3. Which tool would you use to estimate the effort required to migrate a legacy database schema to AWS?
4. Why is Amazon Fargate often preferred over Amazon ECS on EC2 for containerized workloads?

▶Click to see answers

1. Amazon EC2 (It provides raw access to the OS).
2. 15 minutes.
3. AWS Schema Conversion Tool (SCT).
4. Fargate is serverless; it removes the need to manage, patch, and scale the underlying EC2 instances/clusters.

Muddy Points & Cross-Refs

• Lambda vs. Fargate for "Short" Tasks: While Lambda is the default for short tasks, Fargate is better if you have complex dependencies or require a specific Docker environment that exceeds Lambda's layer limits.
• ECS vs. EKS: Use ECS for "AWS-native" simplicity; use EKS (Kubernetes) if you require portability across other clouds or have existing Kubernetes expertise.
• Cost Pitfall: EC2 is paid for even when idle. Lambda is only paid for during execution. However, a high-volume, constant-traffic application might be cheaper on EC2/Fargate than Lambda due to the per-request cost.

Comparison Tables

Compute Platform Comparison

[!IMPORTANT] Always check the Shared Responsibility Model for each service. In EC2, you patch the OS; in Fargate/Lambda, AWS handles the underlying infrastructure patching.