Design Cost-Optimized Compute Solutions

Core Idea

Compute cost optimization = using the appropriate instances/resources for the workload. A well-architected workload uses managed services over self-maintained servers wherever that reduces cost, and selects pricing models deliberately rather than defaulting to On-Demand.

Pricing Models

On-Demand, Savings Plans, Reserved Instances, Spot Instances — plus (mentioned again in the wrap-up context) Dedicated Hosts, Dedicated Instances, Scheduled Instances, Capacity Reservations.

• Spot instances: best for workloads tolerant of a fleet where individual servers come and go — stateless web servers, batch processing, HPC, big data. Explicit fit test: can this workload absorb an instance disappearing mid-job?
• Savings Plans: the answer when you can't tolerate interruption but still want to save, and want flexibility to span EC2, Fargate, or Lambda under one commitment — this flexibility across compute types is the key differentiator from Reserved Instances.

Service Selection as a Cost Lever

Choosing the right service, not just the right instance, cuts cost: CloudFront to minimize data-transfer calls, Aurora/RDS to eliminate expensive third-party database licensing costs entirely.

Cost Evaluation Inputs

When selecting compute services, weigh: resource size/count, pricing model, and data transfer costs — the last one is easy to forget but material.

The Five Cost-Optimization Pillars (as applied to compute)

1. Right-sizing — first step; pick the cheapest instance family that still meets performance requirements (compute-optimized for batch processing vs. memory-optimized for large in-memory datasets, etc.).
2. Increase elasticity — pay only when resources are needed. Practical tactic: prefer more, smaller instances over fewer large ones so Auto Scaling can right-size the fleet to demand, including scaling to zero-ish during off-hours (commonly automated via a CloudFormation template + tagging strategy).
3. Match pricing model to usage pattern — see above.
4. Match storage to compute usage — right-size the storage attached to your compute environment (cross-referenced to the storage-cost lesson).
5. Continual improvement via monitoring — track CPU/RAM/storage utilization to catch over- or under-provisioned instances; CloudWatch for real-time metrics/alarms, Cost Explorer for cost-trend analysis, cost allocation tags for attribution, and regular review of infrastructure changes.

Hybrid Compute Cost Model

• AWS Outposts / Snowball Edge: right-sizing still applies, but the billing model is different — e.g., AWS managed services on Outposts are billed by instance-hour of the managed service itself, excluding the underlying EC2/EBS charges. Know this billing nuance; it's a specific exam trap.
• Edge computing (e.g., CloudFront, or IoT running business logic in remote/low-latency locations): the cost win is not running/managing a data center, full stop.

Load Balancer + Auto Scaling Integration (cost angle)

• After attaching a load balancer to an ASG, use ELB metrics (e.g., ALB's RequestCountPerTarget) to drive scaling decisions.
• Add ELB health checks to the ASG so unhealthy instances are automatically identified and replaced (avoiding wasted spend on unhealthy capacity).
• Alternative/complement: a CloudWatch alarm on healthy host count dropping below a threshold, for visibility even without automated replacement.
• Know the ALB / NLB / Gateway Load Balancer use-case and cost distinctions.

Exam Angle

Expect "interruption-tolerant batch job, minimize cost" → Spot; "no interruption tolerance but want EC2/Fargate/Lambda flexibility" → Savings Plans; Outposts billing-scope questions; and "least-overhead way to shut things down off-hours" pointing to tag-driven Auto Scaling + CloudFormation automation.

Practical Examples

Spot for the right workload: A genomics company runs a nightly batch job processing thousands of independent files — if a worker instance gets reclaimed mid-file, that one file just gets requeued and reprocessed by another worker. Running this fleet on Spot Instances can cut compute cost by up to 90% versus On-Demand, because the workload was specifically designed to tolerate interruption. Running their customer-facing API servers on Spot would be the wrong call — a mid-request interruption there directly hurts users.

Savings Plans vs. Reserved Instances: A company knows it will run roughly $10/hr of steady-state compute for the next year, but isn't sure yet whether that will be EC2, Fargate, or a mix as they migrate services to containers — Compute Savings Plans let them commit to the dollar amount and get the discount regardless of which compute type they actually use. If instead they know for certain it'll be m5.xlarge EC2 instances in us-east-1 for 3 years with no ambiguity, a Reserved Instance (or Instance Savings Plan) can offer a marginally better discount for that narrower commitment.

Right-sizing instance families to workload: A team defaulted every workload to m5 (general purpose) instances. An audit finds their batch video-transcoding job is CPU-bound with RAM to spare — switching those to c5 (compute-optimized) at a similar price point yields more usable CPU per dollar. Meanwhile their in-memory fraud-detection cache is memory-bound — switching those to r5 (memory-optimized) gets more RAM per dollar. Same total spend, better-matched capacity.

Elasticity as direct cost savings: A B2B SaaS app has near-zero traffic overnight and on weekends. Instead of running 10 fixed m5.large instances 24/7, they run an ASG of smaller m5.large→t3.medium-mixed capacity with a scheduled scaling policy that scales down to 2 instances outside business hours — cutting the compute bill by roughly 60% for the same peak-hour capacity.

Outposts billing nuance, concretely: A retailer runs an EKS cluster on an AWS Outposts rack in their own warehouse for low-latency inventory processing. They're billed for the Outposts capacity itself (a fixed subscription) and separately for the managed EKS control plane's usage-based charge — but they are not separately billed the standard EC2/EBS on-demand rates for instances running on that Outposts hardware, since that capacity was already paid for via the Outposts subscription.

ALB health checks avoiding wasted spend: An ASG has 5 instances, one of which is stuck in a bad state (app crashed, but the OS/EC2 health check still reports "healthy"). Without ELB health checks wired into the ASG, that broken instance keeps running (and billing) indefinitely while serving zero useful traffic. Configuring the ASG to use ELB health checks instead of just EC2 status checks means the ASG detects the app-level failure and replaces the instance automatically.