Chapter 4

Design Cost-Optimized Architectures

AWS Certified Solutions Architect – Associate (SAA-C03) Study GuideBased on the official AWS SAA-C03 exam objectives

Designing a system that works is only half the job of a Solutions Architect. The other half — the half that decides whether your architecture survives contact with the real world — is making sure it doesn't cost a fortune to run. AWS makes it remarkably easy to launch infrastructure: a few clicks and you have servers, databases, and storage humming away. But that same frictionless ease means bills can grow silently. A forgotten development server left running, a NAT Gateway quietly charging by the hour and by the gigabyte, an old database snapshot accumulating storage fees month after month — these are the kinds of things that turn a $200 monthly estimate into a $2,000 surprise.

Cost optimization is its own design discipline. It is not something you bolt on after the architecture is done; it is a constraint you design against from the beginning, the same way you design for availability or security. The exam tests exactly this mindset. For SAA-C03, the "Design Cost-Optimized Architectures" domain carries 20% of the exam's weight, and its questions rarely ask "which service is cheapest in isolation." They ask which combination of pricing models, storage classes, and architecture patterns delivers a required workload at the lowest total cost — which means you need to understand not just prices, but how usage patterns interact with pricing.

The good news is that the principles are learnable and the math is straightforward. Every AWS service charges along a small set of dimensions — time running, data stored, data transferred, requests made — and each service gives you a cheaper path if you're willing to commit, be flexible, or accept a constraint. This chapter walks through those trade-offs service by service, starting from first principles, then going deep enough that you can work the exam's cost-comparison questions with confidence.

EC2 Pricing Models: Pay Only for What You Need — and Less for What You Can Predict

Compute is usually the biggest line item in a cloud bill, so it's also where the biggest savings hide. EC2 offers four main pricing models, and the exam loves to test whether you can match each one to the right workload pattern. The trick is to think about two questions for every workload: how long will it run, and how tolerant is it of interruption?

On-Demand: Maximum Flexibility, Maximum Price

On-Demand is the default. You pay per second (with a 60-second minimum) for every second an instance is running, with no commitment and no upfront payment. Stop the instance and the meter stops — you don't pay for stopped instances (though attached EBS volumes still charge you, a classic exam trap).

On-Demand is the right choice for workloads you can't predict: spiky web traffic, short-term development and testing, proof-of-concept builds, and any workload where the freedom to start and stop at any moment is worth paying full price for. The exam describes this as "unpredictable workloads" or "short-term workloads that cannot be interrupted."

Reserved Instances and Savings Plans: Commit to Save

If a workload runs predictably — say, a baseline of web servers that are up 24/7, or a database primary that never stops — you're leaving money on the table by paying On-Demand. AWS rewards commitment with steep discounts, and it offers two mechanisms for this.

Reserved Instances (RIs) are a commitment to a specific instance family in a specific region for one or three years. You reserve, for example, 10 m6i.large instances in us-east-1, and you get up to 72% off the On-Demand price for any usage matching that reservation. RIs come in flavors: Standard (biggest discount, but you can't change the instance family), Convertible (smaller discount, but you can swap instance families during the term), and Scheduled (for recurring windows of time). The billing applies automatically to matching running instances — you don't have to "attach" a reservation to anything.

Savings Plans are the newer, more flexible cousin. Instead of committing to a specific instance type, you commit to a dollar amount of compute spend per hour ($/hour) for one or three years, and you get comparable discounts (up to 72%). There are two types you must know for the exam:

• Compute Savings Plans apply across EC2, Fargate, and Lambda, in any region and any instance family. Maximum flexibility, slightly smaller maximum discount.
• EC2 Instance Savings Plans apply only to EC2 in a chosen region and instance family. Less flexible, bigger discount.

Payment options add another dimension: All Upfront (pay everything on day one, biggest discount), Partial Upfront (pay some now, the rest monthly), and No Upfront (pay monthly, smallest discount). The exam sometimes asks which payment option maximizes savings — the answer is always All Upfront, since AWS gives its best price to the customer who removes all payment risk.

Spot Instances: Up to 90% Off for Interruption-Tolerant Workloads

Spot Instances are AWS's spare capacity, sold at a discount of up to 90% off On-Demand. The catch: AWS can reclaim ("interrupt") a Spot Instance with a two-minute warning when it needs the capacity back. This single fact drives every exam question about Spot.

The two-minute warning arrives through the instance metadata service and as a CloudWatch event, so a well-built application can checkpoint its work, drain in-flight requests, and shut down gracefully. Suitable workloads are anything that can be interrupted and resumed or retried: batch processing jobs, big-data and analytics (EMR, Spark), containerized workloads that scale horizontally, CI/CD build agents, image and video rendering, and stateless web servers behind a load balancer that can lose a node without losing a user session.

Unsuitable workloads are the mirror image: databases, stateful applications, anything with long-running transactions that can't checkpoint, and workloads with strict latency or availability SLAs.

A practical pattern the exam favors: run your baseline on Reserved Instances or Savings Plans and let Spot handle the peaks — for example, an Auto Scaling group with a mix of On-Demand/Reserved base capacity and Spot overflow. You get the reliability of committed capacity and the cheap price of spare capacity.

When you do use Spot at scale, don't request a single instance type in a single AZ — that's the configuration most likely to be interrupted. Use a Spot Fleet or an EC2 Auto Scaling group with a diversified allocation strategy across multiple instance types, sizes, and Availability Zones, and prefer the capacity-optimized allocation strategy, which launches instances from the pools with the most available spare capacity. The exam's "minimize Spot interruptions" answer is always diversification plus capacity-optimized allocation — it doesn't eliminate interruptions, but it dramatically reduces their frequency.

Dedicated Hosts: For Licensing and Compliance, Not Savings

Dedicated Hosts are physical servers allocated entirely to you. They're the most expensive option per unit of compute, and you don't choose them to save money — you choose them for software licensing (BYOL scenarios where a license is tied to physical cores or sockets, like certain Windows Server, SQL Server, or Oracle licenses) and for compliance requirements that demand single-tenant hardware. Don't confuse them with Dedicated Instances, which are also single-tenant but allocated at the instance level rather than giving you visibility into the physical host.

S3 Storage: Pay for the Tier Your Data Actually Deserves

S3's pricing has three main dimensions: storage (per GB-month, varying by storage class), requests (per thousand PUT/GET/LIST operations), and data transfer out (to the internet). Storage class selection is where the exam focuses, because it's pure architecture: matching data's access pattern to the cheapest class that still meets its retrieval requirements.

The Storage Classes, From Hot to Frozen

• S3 Standard is the default: millisecond access, 99.999999999% (11 nines) durability, data replicated across at least three Availability Zones. Use it for frequently accessed data — active website assets, hot application data.
• S3 Intelligent-Tiering automatically moves objects between a frequent-access tier and an infrequent-access tier (plus optional archive tiers) based on observed access patterns, with no retrieval fees and no operational overhead. It charges a small monthly per-object monitoring fee. This is the exam's favorite answer for "unpredictable or changing access patterns" — you don't have to guess, and you don't pay retrieval penalties when you're wrong.
• S3 Standard-IA (Infrequent Access) costs less per GB than Standard but charges a retrieval fee per GB. Break-even math: it's cheaper only if you access the data rarely. It also has a 30-day minimum storage duration — delete earlier and you're billed for 30 days anyway. Use for backups, disaster-recovery files, and long-lived data accessed a few times a month.
• S3 One Zone-IA is ~20% cheaper than Standard-IA but stores data in a single AZ. Durability drops to 99.5% against AZ loss. Only for data you can recreate or afford to lose — thumbnails, transcoded media, secondary copies.
• S3 Glacier Instant Retrieval is for archive data accessed about once a quarter, with millisecond retrieval. Think medical images or news archives you might pull occasionally.
• S3 Glacier Flexible Retrieval (formerly just "Glacier") offers minutes-to-hours retrieval (expedited, standard, bulk options) at lower storage cost. Classic archive: compliance records, old project data.
• S3 Glacier Deep Archive is the cheapest storage in AWS, for data accessed once or twice a year at most, with retrieval in hours. Regulatory archives, tape-replacement backups.

Lifecycle Policies: Automate the Descent

A lifecycle policy transitions objects between classes (or expires/deletes them) based on age or prefixes, and it's how you stop paying Standard prices for data nobody touches. A classic pattern: objects land in Standard, transition to Standard-IA after 30 days, to Glacier Flexible after 90 days, to Deep Archive after 180 days, and expire after 7 years for compliance. Lifecycle transitions are asynchronous and free of request-charge surprises at scale, and the exam expects you to reach for lifecycle policies whenever a question describes data aging through access phases.

Two traps to remember: minimum storage durations (30 days for Standard-IA/One Zone-IA, 90 days for Glacier Flexible, 180 days for Deep Archive) mean transitioning too aggressively can cost more, and S3 charges per transition request — trivial at human scale, worth knowing at billions-of-objects scale.

S3 Request and Transfer Costs

PUT/GET request charges are small but real at scale — a chatty application doing millions of tiny reads can spend more on requests than storage. Batching, CloudFront caching in front of S3 (which also cuts data-transfer costs), and S3 Select (retrieve only the bytes you need from an object) all reduce this. Also remember: data transfer into S3 is free, and transfer from S3 to CloudFront is free — you only pay for transfer out to the internet or across regions (replication charges apply per replicated GB).

For fleet-wide visibility, S3 Storage Lens aggregates storage metrics across all your accounts and buckets — total bytes, object counts, and breakdowns by storage class — so you can spot the buckets still sitting in Standard that should have tiered down months ago. The exam mentions Storage Lens in "gain organization-wide visibility into S3 usage" scenarios.

EBS: Right-Size the Volume, Then Automate the Snapshots

EBS pricing is refreshingly simple: you pay for provisioned capacity (per GB-month), not used capacity, plus IOPS and throughput beyond the baseline on some volume types. That "provisioned, not used" detail is the source of most EBS waste — a 1 TB volume holding 100 GB of data bills you for 1 TB.

gp3 vs gp2: The Exam's Favorite Volume Swap

gp2 (General Purpose SSD, previous generation) bundles performance with size: you get 3 IOPS per GB, so a bigger volume automatically means more IOPS. gp3 (current generation) decouples them: a baseline of 3,000 IOPS and 125 MiBps throughput regardless of size, and you pay only ~20% less per GB than gp2 while provisioning extra IOPS/throughput independently when you need them.

The exam point is direct: gp3 is cheaper than gp2 at the same size and lets you scale performance independently, so "migrate gp2 to gp3" is the right answer whenever a question asks how to cut EBS costs without losing performance. The one caveat: gp3 is the default for new volumes, so the question will usually describe an existing gp2 fleet or a volume whose IOPS were achieved by over-provisioning size.

For completeness: io2/io1 volumes are for IOPS-intensive databases needing guaranteed high IOPS and durability; st1/sc1 are throughput-optimized HDD volumes for big-data and log processing where cost per GB matters more than IOPS. And always match the volume to the workload — running a database on gp2 when it needs io2's consistent IOPS is a performance bug, not a saving.

Snapshots and Data Lifecycle Manager

EBS snapshots are incremental — each snapshot stores only changed blocks — but old snapshots of deleted volumes, and snapshots nobody will ever restore, accumulate real charges. Amazon Data Lifecycle Manager (DLM) automates snapshot (and EBS-backed AMI) lifecycle: take snapshots on a schedule, retain the last N, delete the rest. The exam loves DLM because it's the "automated, least-operational-overhead" answer to any snapshot-retention requirement, and it also supports cross-account and cross-region snapshot copying for DR.

Data Transfer: The Hidden Tax on Architecture

Data transfer is the cost dimension architects most often forget, because it doesn't appear in any service's headline price. AWS charges for data leaving its network (to the internet), moving between regions, and moving between Availability Zones — while data moving within an AZ, into AWS, and between many services in the same region is free. Three patterns dominate the exam.

NAT Gateway vs VPC Endpoints

A NAT Gateway lets instances in private subnets reach the internet (for patches, API calls, downloads). It charges per hour (~$0.045) plus per GB processed (~$0.045/GB). A fleet pulling gigabytes of updates, container images, or S3 data through a NAT Gateway pays that per-GB tax on every byte.

VPC gateway endpoints (for S3 and DynamoDB) are free and route traffic privately without touching the internet. VPC interface endpoints (PrivateLink, for most other AWS services) charge per hour plus per GB, but still less than NAT Gateway data-processing rates and without the internet exposure. The exam pattern is unmistakable: "EC2 instances in private subnets access S3/DynamoDB; reduce data transfer costs" → add a gateway VPC endpoint. The NAT Gateway stays for genuinely internet-bound traffic, but S3 and DynamoDB traffic bypasses it entirely.

Cross-AZ and Cross-Region Transfer

Traffic between AZs costs ~$0.01/GB in each direction. That sounds trivial until a chatty multi-AZ application moves terabytes between nodes daily — suddenly it's hundreds of dollars a month. Mitigations the exam expects: keep data transfer within an AZ where the design allows (while preserving multi-AZ redundancy for the data that needs it), use zonal rather than cross-zone load balancing where appropriate, and be aware that services like RDS Multi-AZ standby replication and ALB cross-zone traffic generate these charges invisibly.

Traffic between regions costs ~$0.02/GB. Cross-region replication, multi-region active-active designs, and inter-region VPC peering all incur it. The exam won't ask you to eliminate legitimate DR replication, but it will test whether you know the charge exists — "which design minimizes data transfer costs" favors same-region architectures when requirements allow.

CloudFront: Pay Less to Serve More

CloudFront, AWS's CDN, actually reduces data-transfer costs: transfer from S3 or EC2 to CloudFront is free, and CloudFront's per-GB price to viewers is lower than S3/EC2 direct-to-internet rates, with further discounts at higher volumes. Caching at edge locations also cuts origin request charges. The exam framing: "serve static/dynamic content to global users at lowest cost" → CloudFront in front of S3 (or an ALB/EC2 origin). Bonus: CloudFront also improves latency, so it's often the rare answer that's both cheaper and better.

RDS: Stop Paying for Database You Don't Use

Databases are sticky — once running, nobody wants to touch them — which makes them prime candidates for quiet overspending. The exam tests four RDS/Aurora levers.

Right-size with Graviton. RDS supports Graviton (ARM-based) instance classes (e.g., db.r6g vs db.r6i), which deliver up to ~20% better price-performance. Switching an RDS instance class to its Graviton equivalent is usually a few clicks with a compatible engine version — the exam's "reduce RDS cost with minimal effort" answer.

Aurora Serverless v2 scales capacity in fine-grained increments up and down to zero-ish based on actual load, paying per ACU-second. For variable, intermittent, or unpredictable database workloads, it beats a provisioned instance sized for peak. (Note: exam questions distinguish this from the older Serverless v1 — v2 is the current recommendation for most variable workloads.)

Stop idle instances. RDS instances can be stopped (up to 7 days at a time before auto-start) — perfect for dev/test databases that sit idle nights and weekends. Stopped instances bill only for storage. The exam's phrasing: "development database used only during business hours" → stop it on a schedule (EventBridge + Lambda, or RDS's own scheduling).

Reserved Instances for RDS work like EC2 RIs: 1- or 3-year commitments on steady-state database capacity for up to ~60%+ off. And don't forget storage: Aurora's storage auto-scales and you pay per GB-month used, while RDS provisioned storage bills for allocated size — another "provisioned vs used" trap.

DynamoDB: On-Demand vs Provisioned — Know Your Traffic Shape

DynamoDB offers two capacity modes, and choosing wrong is expensive in either direction.

On-demand charges per read/write request (per million request units). Zero capacity planning, scales instantly, perfect for unpredictable, spiky, or new workloads — but at steady high throughput, the per-request price adds up fast.

Provisioned charges per unit of read/write capacity per hour (RCU/WCU), whether you use it or not. For predictable, steady traffic, it's dramatically cheaper — and Auto Scaling adjusts provisioned capacity within bounds you set, while Reserved Capacity (1- or 3-year commitments) discounts it further.

Don't forget DynamoDB Standard-IA table class for infrequently accessed data (cheaper storage, pricier reads/writes) and TTL + old-data deletion — paying to store data nobody reads is waste in any database.

Lambda and Serverless: Pay Per Invocation, Watch the Knobs

Lambda pricing is beautifully simple: you pay per request ($0.20 per million) plus compute time measured in GB-seconds (memory allocated × duration). Two cost levers matter:

1. Right-size memory. Lambda allocates CPU proportionally to memory, so more memory often means shorter duration. The cheapest configuration is frequently not the smallest memory — AWS's own guidance and the exam both point to testing with Lambda Power Tuning (an open-source step-functions tool) to find the memory size that minimizes GB-seconds.
2. Architecture choices. Long-running, high-throughput, always-on workloads are usually cheaper on EC2/Fargate than Lambda — Lambda's per-invocation model shines for event-driven, spiky, or idle-mostly workloads. The exam asks you to recognize when "serverless" is the expensive answer: a function invoked millions of times per minute doing sustained compute is a container or EC2 job wearing a Lambda costume.

Related serverless notes: Fargate charges per vCPU/GB-second — right-size task definitions and use Fargate Spot (up to 70% off) for interruption-tolerant containers. API Gateway charges per million requests — caching at the gateway or CloudFront in front of it cuts repeated backend invocations.

One more Lambda cost lever worth knowing: Provisioned Concurrency keeps functions initialized and ready, eliminating cold starts — but you pay for it per GB-second whether the function is invoked or not. It's a performance feature, not a savings feature, and the exam sometimes uses it as a distractor in cost-optimization questions. Only enable it where cold-start latency actually matters, and prefer it on the newest function versions with the smallest memory that meets your latency target.

Graviton: Free Performance (Almost)

AWS Graviton processors (ARM-based, designed by AWS) deliver up to 40% better price-performance than comparable x86 instances across EC2, RDS, ElastiCache, and more. For most Linux workloads — web servers, microservices, databases, caches — switching instance types (e.g., m6i → m6g) requires no code changes for interpreted languages and common runtimes, just a compatible AMI and a quick test cycle.

Cost Visibility and Governance: You Can't Optimize What You Can't See

Everything so far assumes you know where the money goes. These tools give you that visibility, and the exam tests each one's specific role.

AWS Cost Explorer visualizes spend: filter and group by service, region, tag, or account, view daily/monthly trends, and get rightsizing recommendations for EC2. It's retrospective and analytical — "where did the money go?"

AWS Budgets is proactive: set budgets (cost, usage, or RI/Savings Plan utilization), and get alerted (email, SNS, or automated actions via Budget Actions) when spend approaches a threshold. The exam's "notify the team when monthly spend exceeds $X" answer is always Budgets, not Cost Explorer.

Cost and Usage Report (CUR) is the raw, granular billing dataset delivered to S3 — every line item, every hour. It's what you feed into Athena or QuickSight for custom analysis. The exam mentions it when a question needs "detailed, granular billing data" or programmatic analysis.

AWS Compute Optimizer uses machine learning on CloudWatch metrics to recommend optimal EC2 instance types, EBS volumes, Lambda memory sizes, and ECS task sizes — flagging over-provisioned resources and estimating savings. It's the exam's answer to "identify underutilized resources automatically" or "get rightsizing recommendations without manual analysis."

Cost Allocation Tags are the governance layer: tag resources by project, team, environment, or cost center (Environment: Production, Project: Phoenix), activate the tags in the Billing console, and Cost Explorer breaks spend down by tag. The exam tests two facts: tags must be activated to appear in billing reports, and a consistent tagging strategy (often enforced with Tag Policies in Organizations or Service Control Policies) is the prerequisite for chargeback/showback.

Building Cost-Awareness Into the Design Process

Individual savings are satisfying, but the architects who consistently deliver cheap systems share a set of habits that go beyond any single service. These habits show up on the exam as scenario questions about process and governance rather than prices.

Estimate before you build. The AWS Pricing Calculator lets you model a full architecture — instances, storage, transfer, requests — before launching anything. The exam occasionally references it as the correct "estimate costs before deployment" answer. Just as important is revisiting the estimate: set a calendar reminder to compare actual Cost Explorer spend against the estimate 30 and 90 days after launch, because real traffic patterns always differ from the spreadsheet.

Tag everything at creation. Cost allocation only works if tags exist from day one. Enforce it with Tag Policies in AWS Organizations (define allowed tag keys and values) and back it with automation — for example, an EventBridge rule that flags or stops untagged resources. The exam's governance questions ("ensure all resources are tagged for cost tracking") point at Tag Policies and SCPs, not manual audits.

Choose managed over self-managed where the math works. Running your own database, cache, or message broker on EC2 means paying for the instances 24/7 plus your own operational time. Managed services (RDS, ElastiCache, SQS) price in the operations — and with serverless variants (Aurora Serverless v2, SQS's pure pay-per-request model) you often pay less overall because you stop paying for idle capacity. The exam tests this as "reduce operational overhead AND cost": managed serverless usually wins for variable workloads.

Design for scale-to-zero where possible. The cheapest resource is one that doesn't exist when idle. Event-driven patterns — S3 events triggering Lambda, SQS buffering work for auto-scaled consumers, Aurora Serverless v2 scaling down — mean you pay per unit of work rather than per hour of existence. When a question describes intermittent or bursty workloads, "scale to zero" thinking leads you to the serverless or auto-scaled answer.

The Cleanup Habit: Kill the Zombies

A surprising share of real AWS bills is pure waste — resources that serve no traffic but bill every hour. Build a cleanup habit (or better, automate it), and know this checklist cold for the exam:

• Idle Elastic Load Balancers. An ALB/NLB costs ~$0.0225/hour plus LCU charges whether or not traffic flows. Use Cost Explorer or Trusted Advisor to find load balancers with no healthy targets or near-zero request counts, and delete them.
• Unattached Elastic IPs. An Elastic IP attached to a running instance is free; an unattached one costs ~$0.005/hour. They accumulate when instances are terminated without releasing the address. Audit regularly.
• Old EBS snapshots and AMIs. Snapshots of long-deleted volumes, and AMIs (plus their backing snapshots) from retired application versions. DLM retention policies handle snapshots; deregister stale AMIs and delete their snapshots.
• Unattached EBS volumes. Volumes left behind after instance termination ("available" state, no attachment) bill for full provisioned size. Find them by filtering for unattached volumes and snapshot-then-delete.
• Idle NAT Gateways and VPC endpoints. A NAT Gateway in a dev VPC with no traffic still bills hourly. Interface endpoints bill hourly too.
• Old RDS snapshots and stopped instances. Manual RDS snapshots persist until deleted; stopped instances still bill for storage.
• CloudWatch Logs without retention. Log groups default to never expire — set retention policies or pay to store logs forever.

Don't rely on human memory for any of this. The mature pattern is scheduled automation: an EventBridge rule that runs weekly, invoking a Lambda function that snapshots-then-deletes unattached volumes older than 30 days, releases unattached Elastic IPs, and reports idle load balancers to an SNS topic for a human to confirm before deletion. Destructive actions get a human confirmation step; safe, obviously-dead resources get cleaned automatically. The exam rewards this "automated with least operational overhead" framing whenever a question asks how to continuously control waste rather than doing a one-time cleanup.

The deeper lesson of this chapter is a design habit: every architecture decision has a price tag, and the cheapest correct answer is the one that matches the pricing model to the usage pattern — commitments for the predictable, Spot for the interruptible, tiers for the aging, serverless for the spiky, and nothing at all for the idle. On the exam, when two designs both meet the requirements, the question is really asking: which usage pattern did the scenario describe, and which pricing model rewards it? Answer that, and the cost-optimized choice picks itself.

End-of-Chapter Test

1. A company runs a fleet of EC2 instances 24/7 for its baseline web traffic. Usage is stable and predictable, but the company occasionally changes instance families as application requirements evolve. Which pricing option provides the GREATEST discount while retaining flexibility across instance families? A) On-Demand Instances B) Standard Reserved Instances C) Compute Savings Plans D) Spot Instances

2. A media company needs to transcode thousands of video files overnight. The batch jobs can be checkpointed and resumed, and they are tolerant of interruptions of up to a few minutes. Which EC2 pricing model should the solutions architect recommend to minimize cost? A) On-Demand Instances B) Spot Instances C) Dedicated Hosts D) Reserved Instances with All Upfront payment

3. An application stores 30 TB of compliance records that are accessed once or twice a year. Retrieval within 12 hours is acceptable. Which S3 storage class is MOST cost-effective? A) S3 Standard-IA B) S3 Intelligent-Tiering C) S3 Glacier Flexible Retrieval D) S3 Glacier Deep Archive

4. A startup's application generates user uploads with highly unpredictable access patterns — some files are accessed daily, others are never opened again. The startup wants to minimize storage costs without building custom tiering logic or paying retrieval fees when access patterns change. Which solution meets these requirements? A) Store all objects in S3 Standard and write a Lambda function to move old objects to Glacier B) Use S3 Intelligent-Tiering C) Store all objects in S3 One Zone-IA D) Store all objects in S3 Standard-IA with a 30-day lifecycle rule

5. A company runs EC2 instances in private subnets that download 8 TB of data per month from S3. The traffic currently flows through a NAT Gateway, generating significant data-processing charges. What is the MOST cost-effective change that eliminates these charges for S3 traffic? A) Replace the NAT Gateway with a NAT instance B) Add a gateway VPC endpoint for S3 C) Move the instances to public subnets D) Add an interface VPC endpoint for S3

6. A database administrator notices that several gp2 EBS volumes were deliberately over-provisioned to very large sizes solely to obtain enough IOPS for a database workload. The database needs the same IOPS but the company wants to reduce storage costs. What should the solutions architect recommend? A) Convert the volumes to io2 B) Convert the volumes to gp3 with independently provisioned IOPS C) Convert the volumes to st1 D) Take more frequent snapshots to reduce volume size

7. A development team runs an RDS for MySQL database that is used only during business hours (8 hours per day, weekdays). The database is currently running 24/7 on an On-Demand instance. Which combination of actions MOST reduces cost with minimal effort? (Select the best single answer.) A) Convert to Aurora Serverless v2 B) Purchase a 3-year Reserved Instance C) Schedule the instance to stop outside business hours D) Migrate to DynamoDB on-demand

8. A DynamoDB table handles a steady, predictable 2,000 writes per second around the clock. The table is currently using on-demand capacity mode and the bill is very high. What is the MOST cost-effective change? A) Switch to provisioned capacity mode with auto scaling B) Enable DynamoDB Streams C) Switch the table class to Standard-IA and keep on-demand mode D) Add a DAX cluster

9. A solutions architect needs to automatically identify over-provisioned EC2 instances and receive specific instance-type recommendations based on historical utilization. Which AWS service provides this capability? A) AWS Cost Explorer B) AWS Budgets C) AWS Compute Optimizer D) AWS Cost and Usage Report

10. A company wants to be notified by email when its forecasted monthly AWS spend exceeds $5,000, and to automatically stop development EC2 instances if spend exceeds $6,000. Which service meets these requirements? A) AWS Cost Explorer with rightsizing recommendations B) AWS Budgets with Budget Actions C) AWS Trusted Advisor D) AWS Compute Optimizer

11. A finance team needs to attribute AWS costs to individual product teams for chargeback purposes. Resources are already tagged with a Team tag. What must be done before the tags appear in billing reports? A) Nothing; tags appear automatically B) Activate the tags as cost allocation tags in the Billing console C) Enable AWS Config rules for tagging D) Create an SCP that enforces the tags

12. During a cost review, an architect discovers several Elastic IP addresses, an Application Load Balancer with no registered targets, and EBS volumes in the "available" state. Which statement about these resources is correct? A) They incur no charges because they are not serving traffic B) Only the load balancer incurs charges; unattached EIPs and available volumes are free C) All of them incur charges and should be released or deleted if unused D) They incur charges only in regions outside us-east-1

Answer Key

1. C — Compute Savings Plans offer up to 72% off like RIs but apply across instance families, regions, EC2, Fargate, and Lambda — the flexibility the scenario requires. Standard RIs lock to an instance family.

2. B — Checkpointable, interruption-tolerant batch work is the textbook Spot use case, saving up to 90% versus On-Demand. Reserved Instances don't fit a nightly batch pattern well, and Dedicated Hosts are for licensing/compliance.

3. D — Data retrieved once or twice a year with hours of retrieval tolerance is exactly what S3 Glacier Deep Archive is priced for — the cheapest S3 storage class.

4. B — S3 Intelligent-Tiering automatically moves objects between access tiers with no retrieval fees and no custom logic, which is precisely designed for unpredictable access patterns.

5. B — A gateway VPC endpoint for S3 is free and routes S3 traffic privately, bypassing the NAT Gateway's per-GB processing charge entirely. NAT instances still charge for data transfer, and public subnets are a security regression.

6. B — gp3 decouples IOPS from volume size, so you can shrink the volume to the data's actual size and provision only the IOPS needed — cutting cost versus gp2, where IOPS required over-provisioning size.

7. C — Stopping the instance outside business hours eliminates compute charges for ~128 of 168 weekly hours; only storage bills while stopped. This beats Reserved Instances for a part-time workload and requires no migration.

8. A — Steady, predictable throughput is far cheaper on provisioned capacity (optionally with Reserved Capacity) than on-demand's per-request pricing; auto scaling handles minor variation without over-provisioning.

9. C — Compute Optimizer uses machine learning on CloudWatch metrics to recommend optimal EC2 instance types, EBS volumes, and Lambda memory sizes. Cost Explorer analyzes spend but doesn't generate rightsizing recommendations.

10. B — AWS Budgets supports forecast-based alerts (email/SNS) and Budget Actions that can automatically stop EC2 instances when a threshold is breached. The other services analyze or recommend but don't act.

11. B — Cost allocation tags must be activated in the Billing console before they appear in Cost Explorer and billing reports; tagging alone is not enough.

12. C — Unattached Elastic IPs, idle load balancers, and unattached ("available") EBS volumes all bill hourly/by provisioned size regardless of traffic. Releasing/deleting unused ones is a core cleanup action.