Amazon SAP-C02: Compute & Auto Scaling — Study Guide
Part of the AWS Solutions Architect Professional SAP-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
EC2 instance design, storage, and networking
Designing EC2 instances starts with matching workload characteristics to instance families, balancing vCPU, memory, network, and local storage. Choose compute-optimized (C), memory-optimized (R/X), storage-optimized (I/D), or GPU (P/G) types based on profiling. Leverage Nitro-based instances and ENA/SR-IOV for high network throughput and low latency. For latency-sensitive or high IOPS temporary data, consider instance store (ephemeral) on I3/I4 or Nitro SSDs; for durable block storage, use EBS with Provisioned IOPS (io2/io2 Block Express) and enable EBS encryption with KMS for key management. When instances are in VPCs behind Application Load Balancers, ensure internet-facing ALBs are placed in public subnets and targets reside in private subnets; misplacing ALBs or misconfiguring security groups is a common trap. Use Placement Groups (cluster for low-latency HPC, partition for large-scale distributed stateful systems, spread for fault isolation) to influence placement but accept trade-offs: cluster gives best performance but reduces AZ-level fault tolerance. For encrypted data in transit, use TLS terminating at the ALB or end-to-end TLS with NLB passthrough. Decision criteria weigh cost versus performance: denser instance types reduce cost but can increase blast radius and licensing costs; prefer right-sizing driven by CloudWatch, AWS Compute Optimizer, and load tests rather than rules of thumb.
Auto Scaling groups, policies, and lifecycle management
Auto Scaling Groups (ASGs) should be designed for elasticity, resilience, and cost efficiency using a combination of launch templates, mixed-instances policies, lifecycle hooks, and scaling policies. Use launch templates to version AMI, instance type overrides, EBS configurations, and user-data; mixed-instances with capacity-optimized Spot allocation or a diversified strategy reduces interruption risk and lowers cost. For scaling behavior, prefer target-tracking policies for predictable metrics (CPU, request count per target) and step-scaling when threshold-driven multi-stage actions are needed; predictive scaling can pre-provision capacity for known diurnal patterns. Implement lifecycle hooks to run custom initialization or drain tasks before termination; combine warm pools to reduce time-to-serve and scheduled scaling for business-hour baselines. Health checks should integrate ELB and EC2 health checks to avoid premature replacement. Watch for traps like scale-in churn caused by aggressive cooldowns, improper instance weighting in mixed ASGs, and not accounting for application warm-up. For stateful services, avoid rapid scale-in that loses in-memory caches; for cost vs resilience, Spot-backed capacity with On-Demand fallbacks offers savings but requires interruption handling, while 100% On-Demand maximizes predictability at higher cost.
Containers and orchestration: ECS, EKS, and Fargate choices
Choosing among Amazon ECS, EKS, and Fargate depends on operational model, control needs, and workload patterns. Fargate removes node management and is ideal for teams that prioritize operational simplicity, but it has higher per-vCPU pricing and ephemeral storage limits; it supports Fargate Spot for cost savings. ECS provides tight AWS integration and simplicity for customers who want container orchestration without Kubernetes complexity. EKS is appropriate when Kubernetes ecosystem, portability, or advanced scheduling is required; consider managed node groups or Self-Managed + Karpenter for dynamic right-sizing. Network limits (ENI/pod density) and CNI behavior influence pod density and node sizing; on EKS, IAM Roles for Service Accounts and EBS CSI for persistent volumes reduce credential sprawl and enable per-pod storage. For shared file systems, use EFS (NFS) or FSx (Lustre) depending on throughput and latency needs; avoid NFS-backed containers for high metadata operations—prefer EFS with throughput modes tuned to workload. Implement cluster autoscaler or Karpenter for node scaling and service auto scaling with ALB/ECS service metrics. Common traps include ignoring pod disruption budgets, underestimating Kubernetes control plane quota, and overprovisioning nodes rather than using bin-pack strategies—trade-offs between control, cost, and operational overhead should drive the selection.
Serverless compute patterns, Lambda constraints, and event-driven design
Serverless reduces operational overhead but requires architectural patterns that address concurrency, state, and downstream system limits. Lambda is excellent for short-lived, event-driven tasks, API backends via API Gateway or ALB, and asynchronous processing with SQS or SNS. Use Step Functions for orchestrating long-running workflows and DynamoDB or RDS Proxy for database access to mitigate connection storms. Be mindful of Lambda VPC cold-start overhead caused by ENI creation; mitigate with provisioned concurrency for latency-sensitive endpoints or use VPC endpoints and RDS Proxy to limit connections. Implement fan-out/fan-in via SNS + SQS, or Kinesis/MKS for ordered stream processing; use SQS dead-letter queues and idempotent handlers to manage retries and duplicates. Concurrency limits, reserved concurrency, and throttling should be planned to avoid cascading failures; design for backpressure using throttles, retries with jitter, and circuit breakers (API Gateway or custom). Cost-performance trade-offs are clear: Lambda is cost-effective for spiky, short-duration work, while Fargate or EC2 are better for sustained high-CPU or long-running tasks. Common traps include relying on synchronous retries that overload downstream systems, storing state in local /tmp expecting persistence, and not provisioning for cold starts in latency-critical flows.
Practical Problem: NovaTel Enterprise contact center migration
Scenario: NovaTel Enterprise operates a hybrid contact center with on-premises call routing and a Direct Connect to AWS. They run session brokers on EC2 in two Availability Zones and want to migrate to an AWS-managed contact center with high availability and predictable latency between on-premises PBX and cloud services.
Challenge: They need low-latency connectivity for SIP traffic, a scalable compute layer for voice handling that tolerates spot interruptions, and a DR strategy across Regions without increasing operational complexity.
Recommended Approach:
- Provision Amazon Connect for contact center functionality and use a Site-to-Site VPN or Direct Connect with an AWS Transit Gateway for low-latency SIP trunking, terminating at an NLB with TLS passthrough in front of session brokers.
- Run session-processing components as a mixed Auto Scaling Group with launch templates using capacity-optimized Spot plus On-Demand fallback, and use Placement Groups (spread) for fault isolation of critical brokers.
- For stateful call media that requires ephemeral low-latency storage, use instance store backed instances (Nitro) for media buffering and replicate session metadata to DynamoDB or ElastiCache with multi-AZ replication; employ RDS (Multi-AZ) or Aurora Global DB for persistent data with cross-Region read replicas for DR.
- Implement lifecycle hooks and warm pools to minimize cold-start of brokers, Route 53 weighted failover for cross-Region DR, and CloudWatch + SNS/SQS for alerting and automated failover runbooks.
Rationale: Using managed contact center services reduces operational burden while mixed ASGs with Spot optimize cost; isolating ephemeral media on instance stores preserves performance, and durable state replication to DynamoDB/ElastiCache plus multi-AZ RDS/Aurora provides resilience and rapid failover consistent with professional architecture best practices.
← Security · All domains · Storage →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →