Design High-Performing And Elastic Compute Solutions

Source: Dev.to

⚡ Domain 3: Design High‑Performing Architectures

📘 Task Statement 3.2

Designing High‑Performing and Elastic Compute Solutions is about choosing compute that:

• Performs well
• Scales automatically
• Avoids bottlenecks by decoupling components

Approach

1. Pick the compute runtime first – EC2 vs containers vs serverless.
2. Pick the scaling model – Auto Scaling vs event‑based scaling.
3. Tune performance – instance family / memory / concurrency / batching.

Knowledge

1️⃣ AWS Compute Services With Appropriate Use Cases

2️⃣ Distributed Computing Concepts Supported By Global Infrastructure & Edge Services

• Multi‑AZ architectures reduce impact of an AZ failure and enable scale‑out.
• Edge services reduce latency for end users.

Common Edge & Global Services

• CloudFront – caching and edge delivery.
• Global Accelerator – Anycast routing for TCP/UDP apps.

3️⃣ Queuing & Messaging Concepts (Pub/Sub)

4️⃣ Scalability Capabilities

• EC2 Auto Scaling – scales EC2 instances in an Auto Scaling Group (ASG).
• AWS Auto Scaling – provides scaling for multiple services (ECS, DynamoDB, Aurora replicas, etc.).

5️⃣ Serverless Technologies & Patterns

6️⃣ Orchestration of Containers

Amazon ECS (AWS‑native) concepts:

• Cluster → Service → Tasks
• Task definition is the blueprint.

Amazon EKS (Kubernetes) concepts:

• Cluster → Deployments → Pods

If Kubernetes is not required, ECS is usually simpler.

Skills

A️⃣ Decouple Workloads So Components Can Scale Independently

Decoupling Patterns

1. SQS between web tier and workers – buffers spikes, retries, DLQ.
2. SNS fan‑out to multiple consumers.
3. EventBridge for event‑driven integration.
4. Step Functions for orchestration when coordination is needed.

Frontend scales with traffic; workers scale with queue depth.

B️⃣ Identify Metrics & Conditions to Perform Scaling Actions

Common Scaling Signals

1. CPU / memory (EC2/ECS).
2. Request count / target response time (ALB target metrics).
3. Queue depth / age of oldest message (SQS‑based worker scaling).
4. Lambda concurrency / duration / throttles.
5. Custom CloudWatch metrics (business‑driven scaling, e.g., “jobs waiting”).

C️⃣ Select Appropriate Compute Options & Features to Meet Business Requirements

EC2 Instance Types

Other EC2 Options

• Spot Instances – fault‑tolerant workloads (batch, stateless, flexible).
• Graviton (Arm) – price/performance advantage.

D️⃣ Select the Appropriate Resource Type & Size to Meet Business Requirements

Lambda Memory

1. Memory also determines CPU allocation.
2. Increase memory when execution time is too slow (often improves performance).
3. Watch for throttles and concurrency limits.

Container Memory

1. Right‑size task/pod CPU and memory.
2. Scale task count rather than over‑sizing a single task (where possible).

Cheat Sheet

Recap Checklist ✅

• Workload is decoupled so components can scale independently (queues/events).
• Compute choice matches runtime needs (EC2 vs containers vs serverless).
• Scaling strategy is explicit (Auto Scaling, queue‑based, event‑based).
• Scaling metrics are chosen appropriately (CPU, requests, queue depth, concurrency).
• EC2 instances are selected by workload profile (compute/memory/storage/GPU).
• Lambda/container resources are right‑sized (memory, CPU, task count).

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 3.2.

You do not need to memorize them; use them to understand how to design high‑performing and elastic compute solutions.

Key Areas

• Compute services
• Scaling
• Decoupling and messaging
• Edge and global performance

🚀