AWS Strategy: Selecting the Appropriate Container Hosting Platform

Choosing the right container hosting environment is a critical task for a Solutions Architect. It involves balancing operational overhead, flexibility, and architectural requirements such as portability and persistence.

---

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between Amazon ECS and Amazon EKS based on orchestration needs.
• Evaluate the benefits of AWS Fargate as a serverless data plane.
• Select a hosting platform based on migration strategies (Re-host, Re-platform, Re-factor).
• Identify constraints regarding execution time and storage persistence for containerized workloads.

---

Key Terms & Glossary

• Orchestration: The automated arrangement, coordination, and management of computer systems, middleware, and software.
• Control Plane: The "brains" of the orchestration service that manages where containers run and monitors their health.
• Data Plane: The actual infrastructure (EC2 instances or Fargate) where the containerized applications execute.
• Serverless: A cloud computing execution model where the provider manages the allocation of machine resources.
• Re-platforming: Moving an application to the cloud with some optimizations to take advantage of cloud capabilities without changing the core architecture.

---

The "Big Idea"

The core challenge of container hosting in AWS is finding the "Sweet Spot" between Operational Control and Management Abstraction. If you need deep customization of the Kubernetes ecosystem, you choose EKS. If you want a native, AWS-opinionated experience, you choose ECS. If you want to eliminate server management entirely, you layer Fargate on top of either.

---

Formula / Concept Box

Selection Logic Table

---

Hierarchical Outline

• Container Orchestration Services
  • Amazon ECS (Elastic Container Service): Opinionated, highly integrated with AWS services (IAM, CloudWatch).
  • Amazon EKS (Elastic Kubernetes Service): Standard Kubernetes; compatible with open-source tools; higher learning curve.
• Compute Data Planes
  • EC2 Instances: Customer-managed; requires patching; supports persistent EBS volumes.
  • AWS Fargate: AWS-managed; serverless; no persistent disk by default (requires EFS/S3).
• Modernization Strategies
  • Re-host: Low scope change; use Lightsail or EC2.
  • Re-platform: Medium scope; use Elastic Beanstalk or ECS.
  • Re-factor/Re-architect: High scope; use Lambda or microservices on EKS/ECS.

---

Visual Anchors

Decision Flowchart

Architectural Layers

\begin{tikzpicture} \draw[thick, fill=blue!10] (0,3) rectangle (6,4) node[midway] {\textbf{Orchestration (Control Plane)}}; \draw[dashed] (0,2.8) -- (6,2.8); \draw[thick, fill=green!10] (0,1.5) rectangle (2.8,2.5) node[midway] {\textbf{EC2 (Managed)}}; \draw[thick, fill=orange!10] (3.2,1.5) rectangle (6,2.5) node[midway] {\textbf{Fargate (Serverless)}}; \node at (3,1) {\textbf{Data Plane Options}}; \draw[<->] (1.4,2.5) -- (1.4,3); \draw[<->] (4.6,2.5) -- (4.6,3); \end{tikzpicture}

---

Definition-Example Pairs

• Portability: The ability to move applications across different environments without code changes.
  • Example: Using Amazon EKS allows a company to move their Kubernetes YAML manifests from an on-premises data center to AWS with minimal modification.
• Ephemeral Storage: Temporary storage that is deleted when the container stops.
  • Example: A process running on AWS Fargate may download a zip file to /tmp, but that file is lost once the Fargate task completes.
• Event-Driven Compute: Compute that triggers in response to specific system actions.
  • Example: A user uploads an image to S3, which triggers an AWS Lambda container to resize the image automatically.

---

Worked Examples

Problem 1: The Heavyweight Monolith

A company has a legacy Java application. They want to move to AWS quickly but want to start using containers to simplify their deployment pipeline. They do not have Kubernetes expertise.

• Solution: Amazon ECS with EC2 Launch Type.
• Reasoning: ECS provides a lower learning curve than EKS. Using EC2 instances (rather than Fargate) allows them to use EBS volumes for any legacy file-writing requirements the monolith might have.

Problem 2: The Bursting Microservice

A startup has built a new microservice that processes data in bursts. They want to pay only for what they use and do not want to manage any server patching.

• Solution: AWS Fargate (integrated with ECS).
• Reasoning: Fargate is serverless, meaning they pay per vCPU/Memory per second. It removes the operational overhead of managing the host OS.

---

Checkpoint Questions

1. Which service is best suited for a team that relies heavily on standard Kubernetes open-source tools?
2. What is the maximum execution time for a containerized workload running on AWS Lambda?
3. Why might a developer choose EC2 over Fargate for an ECS cluster regarding data storage?
4. What is the difference between Re-hosting and Re-platforming in the context of Amazon Lightsail vs Elastic Beanstalk?

---

Muddy Points & Cross-Refs

[!WARNING] The Fargate Persistence Trap: One of the most common mistakes on the exam is assuming Fargate supports standard EBS volume attachments. It does NOT. For persistent storage in Fargate, you must use Amazon EFS (Elastic File System) or S3.

• EKS Learning Curve: While powerful, EKS requires managing kubectl, node groups, and potentially complex IAM-to-Kubernetes RBAC mappings. If your team is small, ECS is usually the safer choice.
• Lambda Containers: Remember that while Lambda supports container images, it is still subject to the 15-minute timeout and event-driven invocation model.

---

Comparison Tables

Feature Comparison: ECS vs. EKS

Compute Comparison