Design High-Performing and Elastic Compute Solutions

Core Idea

Running on AWS doesn't automatically make a workload scalable — scalability/elasticity is a function of how you design, configure, and integrate the compute services, not an automatic property of the platform.

Three Forms of Compute

Instances (EC2), containers (ECS/EKS), functions (Lambda) — each trades off control, operational overhead, and scaling behavior differently.

Instances (EC2)

• Virtual servers; understanding virtualization is a genuine prerequisite, not just trivia.
• Instance families/sizes bundle CPU, memory, local storage type, network bandwidth, and special capabilities (SSD, GPU) differently — the exam expects you to reason about family fit, not memorize every type.
• EC2 is not inherently scalable — you must explicitly add Auto Scaling + Elastic Load Balancing to make it elastic.

Containers (ECS/EKS)

• ECS: AWS-native container orchestration; two launch types:
  • EC2 launch type: you control installation/configuration/management of the compute layer.
  • Fargate: serverless compute for containers — no EC2 management.
• EKS: run AWS-managed Kubernetes on EC2 instances.
• Integrate with Application Load Balancers for port mapping to containers.

Functions (Lambda)

• Lambda "extracts the execution environment from the code" — you supply a runtime (Python, Java, Node.js, etc.) and Lambda runs it without you provisioning an EC2 instance.
• Billed for execution duration; invoked on events; hard 15-minute execution ceiling.
• Workflow longer than 15 minutes → reach for AWS Step Functions instead.
• Lambda @ CloudFront pattern (Lambda@Edge-style): deploy Lambda to CloudFront edge locations for lower-latency, globally distributed execution.

Independent Scaling & Decoupling (cross-reference to Domain 2)

• This task statement explicitly reiterates decoupling via SQS and Elastic Load Balancing as part of making compute/application components scale independently.

Observability Drives Scaling Decisions

• CloudWatch metrics, alarms, dashboards are the foundation for EC2 Auto Scaling triggers — automation and remediation for scaling events hinge on alarms crossing a threshold for a sustained duration.
• Not all useful metrics are available by default — e.g., EC2 memory utilization is not a default CloudWatch metric; it requires a custom metric (agent-based) to track.
• Beyond CPU/memory: custom metrics you define, or load-balancer metrics like HealthyHostCount and SurgeQueueLength — the right scaling metric depends on the workload, so explore what's available per service before assuming CPU utilization is always the answer.

Elastic-by-Nature vs. Not

• Lambda is elastic and scalable by design — invoke it once or 100×/second with zero scaling configuration on your part.
• EC2 is explicitly not elastic by nature — this asymmetry is a recurring exam distinction: know which services need you to design for scale and which don't.

Choosing an EC2 Instance Type

• Start from the application's actual resource needs (compute, storage, networking) as stated in the scenario stem, then map to an instance family — you are not expected to memorize every instance type, but you must know how family choice affects performance/scalability.

Reference Architecture Pattern

• Backend web service on EC2 with highly variable usage, needs HA + elasticity → EC2 + Elastic Load Balancing + EC2 Auto Scaling is the default scalable pattern.

Compute Selection Meta-Skill

• Be comfortable choosing among EC2 vs. Lambda vs. containers for a given scenario, understanding the benefits/limitations of each rather than defaulting to one.

Exam Angle

Expect: "what metric would you use to trigger this scaling policy" (including the memory-metric trap), "which compute option needs the least scaling design effort" (Lambda), and family/instance-type selection questions keyed to a described workload profile (compute- vs. memory- vs. storage-optimized).

Practical Examples

Instance family selection: A video-encoding batch job that's almost purely CPU-bound → C-family (compute-optimized, e.g., c6i). An in-memory analytics engine (like SAP HANA or a big Redis dataset) needing huge RAM-to-vCPU ratios → R-family (memory-optimized, e.g., r6g). A data warehouse node needing massive local NVMe throughput → I-family (storage-optimized). Matching family to workload shape is usually the actual test, not memorizing exact vCPU counts.

ECS EC2 vs. Fargate: A team running hundreds of containers with very specific kernel-tuning and GPU requirements needs the EC2 launch type for ECS — they need to control the underlying instances. A team just shipping a stateless API container and not wanting to patch or size EC2 instances at all uses Fargate — they define CPU/memory per task and AWS handles the rest.

Lambda's 15-minute wall, and the fix: A nightly ETL job used to run in 8 minutes but as data grew it now needs 25 minutes — Lambda will hard-fail at 15. Two options: break the job into smaller Lambda-sized chunks orchestrated by AWS Step Functions, or move the job to a service without that ceiling, like AWS Batch or Fargate.

Lambda@Edge / CloudFront-integrated Lambda: A global news site wants to A/B test headlines and personalize content based on the visitor's country, with minimal added latency. Deploying the personalization logic as a Lambda function running at CloudFront edge locations means the logic executes physically close to each visitor instead of round-tripping to a single origin Region.

The missing memory metric: An ASG scaling policy is set on CPU utilization, but the app is actually getting killed by out-of-memory errors under load while CPU sits comfortably at 40%. Default CloudWatch EC2 metrics don't include memory — you have to install the CloudWatch agent to publish a custom mem_used_percent metric, then build the scaling policy on that instead.

ALB metrics for smarter scaling: An ASG scaling purely on average CPU can under-scale for an app where requests vary wildly in cost (some take 10ms, some take 2s). Scaling on the ALB's RequestCountPerTarget metric instead ties capacity directly to actual request load per instance, which better reflects real user-facing pressure than CPU alone.

EC2 vs. Lambda vs. containers, one scenario, three right answers depending on shape: A "resize an uploaded image" task — if it's triggered by occasional S3 uploads and finishes in seconds, Lambda (event-driven, pay-per-invocation, zero idle cost) is the natural fit. If it needs a specialized, hard-to-containerize legacy binary and runs continuously, EC2 with an ASG might be the fit. If it's a steady, moderate, containerizable workload with 24/7 traffic, Fargate balances operational simplicity against Lambda's per-invocation cost at that volume.