Lesson 2.1: Compute and container orchestration architecture on AWS
Modern AWS application architecture requires deliberate selection of compute and orchestration models. The choice between Amazon EC2, container services such as Amazon ECS, and Kubernetes through Amazon EKS affects scalability, operational overhead, deployment strategy, and security boundaries. These decisions are not interchangeable. They directly influence how applications scale, how failures are handled, and how infrastructure is operated over time.
Amazon EC2 lifecycle and scaling behavior
Amazon EC2 provides virtual machine-based compute with full control over the operating system and runtime environment. Instances progress through a defined life cycle: pending, running, stopping, stopped, shutting-down, and terminated. This model offers maximum flexibility but also imposes responsibility for OS patching, runtime hardening, and application configuration. To handle variable workloads efficiently and ensure high availability, EC2 is typically combined with Auto Scaling and load balancing.
IAM instance roles attach temporary credentials to EC2 instances. These roles define what AWS resources the instance can access, eliminating the need for embedded credentials. If permissions are incorrectly scoped, applications fail at runtime with AccessDenied errors. This makes IAM configuration a critical part of compute design, not an afterthought.
Auto Scaling and dynamic capacity adjustment
Auto Scaling complements EC2 by automatically adjusting capacity based on demand. Scaling policies typically include:
- Target tracking, which maintains a metric such as CPU utilization
- Step scaling, which adjusts capacity in increments based on thresholds
- Scheduled scaling, for predictable workload patterns
The following command creates an Auto Scaling group with defined minimum, maximum, and desired capacities, associating it with specific subnets in a VPC.
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--min-size 2 --max-size 5 --desired-capacity 2 \
--vpc-zone-identifier "subnet-123,subnet-456"
Auto Scaling also automatically replaces unhealthy instances. This reinforces the need for stateless application design: any instance can be terminated and replaced at any time, so the application state must be externalized to databases, caches, or other persistent services.
Elastic Load Balancing (ELB) integration
Elastic Load Balancing integrates seamlessly with Auto Scaling to distribute traffic to healthy instances and maintain high availability. The type of ELB chosen affects routing capabilities, performance, and how EC2 instances receive traffic:
- Application Load Balancer (ALB) operates at Layer 7, supporting host-based and path-based routing, ideal for HTTP/HTTPS microservices.
- Network Load Balancer (NLB) operates at Layer 4, supports static IPs, and is designed for high-throughput or low-latency TCP workloads.
- Gateway Load Balancer (GWLB) enables transparent deployment of virtual appliances (firewalls, IDS/IPS) and integrates with EC2 workloads for inspection and security purposes.
EC2 instances in an Auto Scaling group register with an ALB, NLB, or GWLB,
which distributes incoming traffic according to routing rules. In the architecture diagram, the blue arrows represent client requests entering the ALB, while the orange arrows show load-balanced traffic and health checks flowing to the backend EC2 instances. The ALB ensures traffic is evenly distributed across healthy instances, demonstrating how load balancers play a central role in maintaining availability and supporting Auto Scaling.
Compute decisions at this layer determine operational control, scaling behavior, and failure recovery patterns. Together, EC2, Auto Scaling, and Elastic Load Balancing form a tightly integrated stack: EC2 provides the compute, Auto Scaling adapts capacity dynamically, and ELB ensures traffic is distributed efficiently, maintaining performance, resilience, and availability.
Container orchestration with Amazon ECS, EKS, and App Runner
Containers package applications with their dependencies, removing the need to manage full virtual machines per workload. AWS provides multiple options for container orchestration: Amazon ECS, Amazon EKS, and AWS App Runner.
Amazon ECS is a fully managed orchestration service tightly integrated with AWS. It supports two launch types:
- EC2 launch type, where containers run on EC2 instances that you manage
- Fargate launch type, where AWS manages the underlying infrastructure
Fargate reduces operational overhead by eliminating instance management. There is no need to patch or scale underlying hosts. The EC2 launch type provides more control and can be more cost-efficient at scale, but requires capacity planning and instance maintenance.
Task vs. Service
For ECS, the exam often asks about the difference between a task and a service:
- Task: A single running container instance based on a task definition.
- Service: Maintains the desired number of task instances, handles scaling, and integrates with load balancers.
Task roles vs Task execution roles
When deploying containers, roles define what AWS resources the tasks can access:
- Task role: Used by the running container to access AWS resources (e.g., reading from S3).
- Task execution role: Used by ECS to pull container images from ECR, write logs to CloudWatch, or fetch secrets from Secrets Manager.
The following command demonstrates running a Fargate task, which uses the task execution role for infrastructure access:
aws ecs run-task \
--cluster my-cluster \
--launch-type FARGATE \
--task-definition my-task
Amazon Elastic Container Registry (ECR) stores container images securely. ECS and EKS pull images from ECR during deployment. Image tagging strategies and immutability are important for predictable rollbacks, consistent deployments, and avoiding accidental overwrites.
Amazon EKS provides a managed Kubernetes control plane infrastructure. It enables Kubernetes-native architectures and compatibility with the broader ecosystem, including custom controllers, Helm charts, and advanced scheduling features. However, EKS introduces additional operational complexity, including cluster networking, node management, and version upgrades. Developers can also run EKS with Fargate, which removes the need to manage worker nodes.
This diagram shows an Application Load Balancer distributing incoming traffic to containerized applications hosted on EC2 instances across multiple Availability Zones. It highlights how container orchestration services (like ECS or EKS) logically group and manage these containers to provide scalable, highly available computing.
AWS App Runner is another option for deploying containers without managing infrastructure. App Runner automatically builds and deploys from source code or container images, handling scaling and HTTPS traffic. It is particularly useful for web applications or APIs where operational simplicity is prioritized.
Decision considerations
Selecting a compute model requires evaluating control, complexity, and scaling behavior.
- EC2 offers maximum flexibility and control but requires full infrastructure management.
- ECS simplifies container orchestration and integrates natively with IAM, ECS task and execution roles, and other AWS services.
- Fargate removes host management entirely, focusing only on application containers.
- EKS enables Kubernetes-based architectures but increases operational overhead. Developers can optionally use Fargate to avoid managing worker nodes.
- App Runner provides a fully managed environment for containerized web applications or APIs, minimizing operational effort and automatically handling scaling and HTTPS traffic.
Across all models, Elastic Load Balancing and Auto Scaling provide horizontal scaling and high availability, while stateless application design remains a foundational requirement, ensuring that compute instances or containers can be replaced without affecting application behavior.
Selecting the appropriate compute and orchestration model is an architectural decision. It must align with scaling requirements, operational responsibility, team expertise, and the desired level of control over the runtime environment, including the choice between managed and self-managed container orchestration.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
