Amazon SOA-C02: Compute and Auto Scaling — Study Guide

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Part of the AWS SysOps Administrator Associate SOA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

This domain covers managing EC2 instances and Auto Scaling to deliver reliable, cost-effective compute capacity. It focuses on instance lifecycle operations, scaling strategies, load-balancer integration, placement for performance and resilience, and maintenance/termination behaviors that affect availability and state. Operational mastery means choosing the right instance types, launch configuration patterns, scaling policies, and health-check integration to meet SLAs while controlling cost.

EC2 instance lifecycle and management

EC2 lifecycle management starts at the point of launch configuration: use Launch Templates (aws ec2 create-launch-template / console) to capture AMI, instance type, IAM instance profile, user-data, network interfaces, EBS mapping, and metadata options; templates support versioning which makes immutable deploys straightforward. Immutable deploys use a new launch-template version (or new launch template) and either create a new Auto Scaling group or use ASG instance refresh to replace instances; avoid in-place upgrades of running instances when changes affect boot-time behavior or AMI-level patches.

Operational CLI/console patterns include aws ec2 run-instances –launch-template LaunchTemplateId=lt-xxx,Version=2 for one-off launches and aws autoscaling create-auto-scaling-group –launch-template LaunchTemplateId=lt-xxx,Version=’$Latest’ for ASG-driven launches. Decide between AMI baking (Packer/CodeBuild) and user-data startup scripts based on boot time: bake heavy dependencies into AMIs to reduce boot duration; use user-data for environment-specific wiring. For ephemeral storage, remember instance-store volumes are lost at termination; configure root and data volumes with DeleteOnTermination=false if you require persistence of EBS after instance termination.

Auto Scaling groups, policies, and lifecycle hooks

Auto Scaling Groups (ASGs) are configured with a launch template or launch configuration and control desired/min/max capacity across Availability Zones. Choose launch template + MixedInstancesPolicy for cost-optimized fleets that blend On-Demand and Spot with an instance type list; use instance weighting and capacity-optimized allocation strategies for predictable capacity. For deploys, prefer immutable patterns: create a new launch-template version and perform an ASG instance refresh or blue/green swap rather than reconfiguring existing instances.

Scaling policies are expressed as:

Target tracking (PolicyType=TargetTrackingScaling): set a predefined metric like ALB RequestCountPerTarget or ASG average CPU and a target value; ASG handles adjustments automatically.
Step scaling (PolicyType=StepScaling): define CloudWatch alarms that trigger specific adjustment steps (e.g., +2, +4) based on breach severity; useful for bursty workloads.
Simple scaling (legacy): single-step adjustments with cooldown; generally superseded by target tracking or step scaling.

Use lifecycle hooks (aws autoscaling put-lifecycle-hook –lifecycle-hook-name name –auto-scaling-group-name my-asg –lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING –heartbeat-timeout 300 –default-result ABANDON) to pause instance termination/launch. Lifecycle hooks allow you to drain connections, replicate state (to S3/RDS), or notify orchestration systems via SNS/SQS/Lambda before completion; always set HeartbeatTimeout and a default action to avoid stuck states.

Elastic Load Balancing types and health checks

Choose load balancer type by traffic pattern: Application Load Balancer (ALB) for HTTP/HTTPS with content-based routing and host/path rules; Network Load Balancer (NLB) for extreme performance and static IPs for TCP/UDP; Classic Load Balancer (CLB) only for legacy stacks. Create ALBs and target groups with aws elbv2 create-load-balancer and aws elbv2 create-target-group; register ASG targets by using the ASG’s target group association for automatic lifecycle health integration.

Health-check integration requires aligning ASG and ELB health checks: set ASG HealthCheckType to ELB (aws autoscaling update-auto-scaling-group –auto-scaling-group-name my-asg –health-check-type ELB –health-check-grace-period 300) so an instance is considered healthy only after the load balancer marks its target healthy. Health check types and implications:

ALB/NLB target group health check: supports HTTP/HTTPS/TCP and measures application-level readiness; recommended for web apps.
ASG health checks alone: use for simple host-level checks (e.g., EC2 status checks).
HealthCheckGracePeriod: give new instances time to boot, run user-data, and pass app-level checks.

Stickiness implications: ALB target group stickiness uses application cookie-based affinity (duration-based) which can improve session affinity but reduces even distribution and complicates rolling updates. NLB supports client IP affinity; use stickiness only when session state cannot be externalized.

Instance placement, capacity planning, and scaling metrics

Placement decisions affect latency and failure domains: placement groups offer cluster (low-latency network), spread (one instance per rack for critical instances), and partition (fault-isolated partitions) strategies. ASGs balance instances across AZs by default; prefer AZ-aware capacity planning to avoid single-AZ hotspots. For CLI: aws ec2 create-placement-group –strategy cluster|spread|partition.

Capacity planning considers instance types, purchasing options, and metrics:

Instance types: choose CPU/memory/network optimized families (M/C/R/T/D/I) based on workload; measure with representative load tests.
Purchasing: On-Demand for predictability, Reserved or Savings Plans for steady-state cost reductions, Spot for transient cost efficiency; use MixedInstancesPolicy for combining types and purchase options.
Scaling metrics: default ASG metrics use average CPU across group; prefer application-level metrics such as ALB RequestCountPerTarget or custom CloudWatch metrics (e.g., queue depth) for target tracking. Common patterns:
Use target tracking with ALB/request-count-per-target when you need a steady number of requests per instance.
Use step scaling for sudden, large spikes with defined recovery steps.
Consider Predictive Scaling for daily cyclical workloads.

Instance recovery, termination behavior, and maintenance

Plan for instance failures and maintenance by enabling automatic recovery for hardware issues (CloudWatch alarm with EC2 Recover action) and handling scheduled events (describe-instance-status). Configure instance-initiated-shutdown-behavior and EBS DeleteOnTermination flags to control volume lifecycle; use aws ec2 modify-instance-attribute –instance-id i-xxx –block-device-mappings to adjust.

Termination behavior in ASGs: ASG termination policies decide which instance to terminate first (Default: oldest launch configuration or instance health and AZ balancing heuristics). Important operational details:

Local state is ephemeral: instance-store volumes and in-memory caches are lost on termination. Do not assume replacement preserves local state; persist critical data to EBS (with appropriate snapshot/backup), S3, or external cache (ElastiCache).
Use lifecycle hooks to drain traffic and offload state before termination.
Use instance refresh or blue/green for maintenance to replace instances safely; aws autoscaling start-instance-refresh –auto-scaling-group-name my-asg –preferences file://prefs.json.

Common Pitfalls and Decision Criteria

Relying on default cooldowns and CPU-only metrics: choose metrics aligned to application behavior (ALB RequestCountPerTarget, queue depth); set cooldowns to accommodate startup time and HealthCheckGracePeriod to avoid oscillation.
Not using lifecycle hooks for graceful termination: without hooks, in-flight requests and local caches are lost; implement hooks with SNS/SQS/Lambda to drain and persist state.
Assuming instance replacement preserves local state: local instance-store and in-memory caches are ephemeral; design for stateless instances or replicate state to durable stores.
Overusing stickiness: stickiness increases uneven load distribution and complicates scaling and updates; prefer external session stores (ElastiCache, DynamoDB) for scale-out.
Ignoring AZ balancing and placement groups: placing too many instances in one AZ or cluster group can create single points of failure; use ASG multi-AZ distribution and appropriate placement-group strategies.
Misconfiguring health-check integration: ASG health-check-type must match ELB/target-group health checks and HealthCheckGracePeriod must be long enough for app initialization, otherwise healthy instances will be terminated.

Practical Problem: Use-Case Scenario

StreamingCo operates a video thumbnail API experiencing daily traffic spikes and uses local disk caches on EC2 instances; recently, scale-up has been slow and terminated instances lose cache leading to poor response times.

Migrate launch configuration into a Launch Template and bake a lightweight AMI with runtime dependencies; use aws ec2 create-launch-template and versioning for immutable deploys.
Configure an ASG with a MixedInstancesPolicy that lists several instance types and Spot + On-Demand allocation to balance cost and capacity.
Attach an ALB and use TargetTrackingScaling on the ALB RequestCountPerTarget metric with a HealthCheckGracePeriod set to the application’s bootstrap time.
Implement lifecycle hooks on ASG terminations to drain connections and run a Lambda/SNS flow to persist necessary cache keys to ElastiCache or S3 before termination.
Externalize session and cache state to ElastiCache or S3 and use placement groups/az-distribution to meet latency and fault-domain requirements.

Rationale: Using launch templates and immutable deploys reduces boot variability; ALB-targeted target tracking ties scaling to request load rather than CPU; lifecycle hooks prevent data loss on termination; externalizing cache removes dependence on ephemeral local state, enabling fast, safe scaling and lower cost through mixed instance/purchase strategies.

← Storage and Data Management · All domains · Databases and Caching →

Practice these questions → · Timed practice on ExamRoll.io →