Design cost-optimized architectures

Cost principles

• Pay for what you use: elastic scaling, serverless and on-demand pricing beat provisioned peak capacity that sits idle.
• Commit for what is predictable: Savings Plans and Reserved Instances for steady baseline load.
• Right-size and tier: smaller instances, cheaper storage classes, shorter retention.
• Watch data transfer: it is the quiet cost behind many designs.
• Measure and attribute: tags, budgets, alerts.
• Requirements differ by class of workload. Production needs Multi-AZ and headroom; non-production can use single AZ, smaller sizes, Spot and a schedule that stops it outside working hours. Spending production money on dev and test is a common wrong answer.

Compute costs

EC2 purchase options

• All Upfront gives the biggest discount, then partial, then no upfront. A 3-year term beats 1-year. A regional RI applies across AZs with flexibility in size; a zonal RI reserves capacity in one AZ.
• Savings Plans and RIs are billing constructs. Nothing changes on the instance. Cover the baseline with commitments, handle the variable part with On-Demand and the interruptible part with Spot.
• Spot design: diversify instance types and AZs, use the price-capacity-optimized allocation strategy, handle the interruption notice (checkpoint, drain), and use Spot for task nodes in EMR, ECS/EKS worker nodes, Batch and Auto Scaling mixed instances groups with an On-Demand base. A job that can’t be interrupted or a database primary is not a Spot candidate.
• Spot Block/Defined duration is gone. For interruptible batch jobs: SQS queue + Spot workers is the classic cheap pattern.
• Savings Plans vs RIs for the exam: if the question mentions Fargate or Lambda, or changing instance families, the answer is Compute Savings Plans. If it says one instance type for a fixed period, any of the committed options fit, with RIs also covering RDS, ElastiCache and Redshift (Savings Plans don’t).

Instance family, size and generation

• Pick the family that matches the bottleneck: compute (C), memory (R/X), storage (I/D), general (M/T). Paying for memory-optimized when the app is CPU-bound wastes money.
• Pick the size from measured use. AWS Compute Optimizer analyses CloudWatch metrics and recommends smaller sizes, other families, Graviton, EBS volume types and Lambda memory. Install the CloudWatch agent to give it memory data. Trusted Advisor flags idle and low-utilisation instances.
• Newer generations and Graviton (Arm) instances give better price-performance, usually around 20% cheaper for compatible workloads. T-family burstable instances suit low average CPU and use credits.
• Virtualization: Nitro-based instances give better value for the money than older Xen types.

Scaling and utilisation

• Auto Scaling removes idle capacity at night and adds it on demand. Use scheduled scaling for predictable cycles, target tracking for variable load, and Instance Scheduler or an EventBridge schedule to stop non-production instances overnight and on weekends (about 65% savings for office hours only).
• Vertical scaling (larger instance) is simple but needs a restart and wastes capacity; horizontal scaling (more instances) matches cost to load.
• EC2 hibernation saves RAM to EBS so instances stop (no compute charge, you pay for EBS and Elastic IP) and resume with state quickly. Good for dev machines and slow-warming apps. Stopped instances don’t pay compute, but their EBS volumes still cost.
• Terminate idle and unattached resources: unassociated Elastic IPs, idle load balancers, unattached EBS volumes, old snapshots.

Serverless and containers

• Lambda bills per request and per GB-second, with a free tier and no idle cost. It is cheapest for spiky, infrequent or event-driven work. A constant, heavy, long-running load can be cheaper on EC2 or Fargate with commitments. Tune memory to the cheapest point (more memory is sometimes cheaper if the run time drops proportionally), and use ARM (Graviton) functions for lower price.
• Fargate bills per vCPU and memory per second, with no idle servers. ECS/EKS on EC2 is cheaper at high steady utilisation when nodes are packed, especially with Spot and Reserved pricing. Fargate Spot gives a discount for interruptible tasks.
• Containers raise density, so more apps share fewer instances. Microservices let each part scale and be sized separately.
• Elastic Beanstalk, Lightsail, App Runner: no extra charge for Beanstalk itself, you pay for the resources it creates.
• Edge and distributed compute: process data near its source to avoid sending it back. CloudFront Functions / Lambda@Edge run logic at the edge, AWS Outposts keeps compute on premises for low latency or data residency (paid per rack, not a saving tool), Snowball Edge and Local Zones process data at remote sites. Wavelength is for 5G edge apps.
• Load balancers: choose by need. ALB (layer 7, routing, most web apps), NLB (layer 4, static IP, extreme performance, TCP/UDP), GWLB (appliances). One ALB can host many services using host and path rules, which is cheaper than one load balancer per service. Charges are hourly plus capacity units (LCUs).
• Hybrid compute: Outposts and Snowball Edge cost more than cloud regions, so they fit only when there is a latency, residency or connectivity requirement.

Storage costs

S3 storage classes

• Lifecycle rules move objects between classes after N days and expire objects, noncurrent versions, incomplete multipart uploads and delete markers. Typical chain: Standard → Standard-IA at 30 days → Glacier at 90 → Deep Archive at 180 → expire. You can’t transition to Standard-IA before 30 days in Standard, and small objects (under 128 KB) cost more in IA classes.
• Intelligent-Tiering is the answer to “access pattern unknown or unpredictable” with no retrieval fees. A known pattern with clear cold data is cheaper with a lifecycle rule.
• Versioned buckets keep growing: add a lifecycle rule for noncurrent versions. Abort incomplete multipart uploads with a lifecycle rule, since the parts are billed.
• S3 Storage Lens and Storage Class Analysis show access patterns. Requester Pays buckets make the downloader pay for requests and transfer, for sharing big datasets, and the requester must be authenticated.
• Batch uploads and larger objects lower request charges (PUT requests cost per thousand). Combine small files, use multipart for big ones, and use S3 Select / Athena with Parquet and partitions to read less data.
• S3 Glacier retrieval and requests cost money, so avoid pulling archives back often.

EBS, EFS and FSx

• gp3 is cheaper than gp2 for the same capacity, and lets you set IOPS and throughput without buying more storage. Move gp2 to gp3 for a quick saving. st1/sc1 (HDD) are far cheaper per GB for sequential, throughput-driven data. io2 is justified only for sustained high IOPS needs.
• Delete unattached volumes, old snapshots (incremental, so the first is large and later ones small) and unused AMIs. Use Data Lifecycle Manager to enforce retention, and the EBS Snapshots Archive tier for rarely used snapshots (cheaper, 24 to 72 hour restore, 90-day minimum).
• You pay for provisioned EBS size, not used size, so right-size volumes. EBS can grow online, but can’t shrink.
• EFS: use lifecycle management to move files not touched for N days to IA or Archive classes (up to ~90% cheaper), and One Zone classes where Multi-AZ isn’t needed. Elastic throughput suits spiky use; provisioned throughput costs extra when over-provisioned.
• FSx: FSx for Windows supports data deduplication and HDD storage for cheaper capacity; Lustre scratch is cheapest for temporary HPC. Choose the file service by workload: don’t run Windows file shares on EFS, don’t pay for FSx if S3 is enough.
• Storage auto scaling (RDS storage autoscaling, DynamoDB auto scaling, EFS and S3 elasticity) avoids over-provisioning up front.
• Instance store is included in the instance price, making it the cheapest storage for temporary data.

Data movement and hybrid storage costs

Data into AWS from the internet is free. Compare transfer time and cost against available bandwidth: a 1 Gbps link moves about 10 TB per day.

Backups

Use AWS Backup plans with lifecycle (move to cold storage, expire). Back up on the schedule the RPO requires, and keep only the retention the policy requires. Long retention with frequent snapshots of large databases adds up. Cross-Region copies also add transfer and storage costs, so copy only what DR needs.

Database costs

• Pick the database by data shape: key-value at scale → DynamoDB, relational → RDS/Aurora, columnar analytics → Redshift (or Athena on S3 for occasional queries), time series → Timestream, graph → Neptune, documents → DocumentDB, in-memory → ElastiCache. A purpose-built database costs less than forcing the wrong one.
• Engine and licence: PostgreSQL/MySQL on RDS or Aurora avoid commercial licence fees. Moving off Oracle/SQL Server with SCT + DMS (heterogeneous) cuts licensing. BYOL and License Manager help when you must keep licences.
• Backups and retention: automated backup storage up to the database size is free, retention beyond that or manual snapshots is billed. Choose a snapshot frequency and retention that match RPO and compliance, then delete old manual snapshots. Data retention policies (TTL, archiving cold rows to S3 and querying with Athena) keep expensive databases small.
• Capacity planning: provisioned capacity units, instance classes, and storage should match measured demand. Too much headroom is waste, too little costs outages.
• Read-heavy apps: add replicas or cache. Write-heavy apps: scale up, partition, or use DynamoDB.

Network costs

Data transfer pricing

• Keep chatty components in the same AZ if availability allows, use private IPs, and replicate across Regions only what DR needs.
• CloudFront reduces origin load and egress, so caching static and cacheable dynamic content is both faster and cheaper. Price classes limit edge locations to cheaper areas.
• Global Accelerator adds a premium per GB. Use it for the static IPs and failover, not to save money.
• Compress responses, resize images, and cache at API Gateway or CloudFront.

NAT, endpoints and VPC design

• A NAT gateway costs per hour plus per GB processed. Heavy S3 or DynamoDB traffic through NAT is expensive, so add a gateway endpoint (free) and keep that traffic off NAT. Interface endpoints cost hourly per AZ, so use them when NAT data charges outweigh them or privacy demands.
• One NAT gateway per AZ gives availability and avoids cross-AZ data charges. A single shared NAT gateway is cheapest and fine for non-production, but it is a single point of failure and adds cross-AZ charges. A NAT instance is cheaper at very low volume, but needs management and has limited bandwidth.
• A regional NAT gateway mode that serves all AZs from one resource now exists, trading some control for simplicity.
• VPC peering has no hourly charge (you pay data transfer across AZs/Regions). Transit Gateway charges per attachment per hour and per GB processed, worth it when the mesh would otherwise be large. PrivateLink charges hourly per endpoint and per GB.
• Route 53: alias queries to AWS resources are free, other queries and hosted zones cost. Don’t confuse DNS routing with data transfer cost.

Connectivity and bandwidth

• Bandwidth allocation: choose a Direct Connect port speed (1, 10 or 100 Gbps dedicated, hosted from 50 Mbps) and number of VPN tunnels to match need. A VPN tunnel carries up to about 1.25 Gbps, and ECMP across several VPNs on a Transit Gateway adds bandwidth. Over-provisioning ports costs money, under-provisioning slows transfers.
• Throttling strategy: protect backends and control cost with API Gateway throttling and usage plans, WAF rate-based rules, SQS buffering to flatten bursts, and Lambda reserved concurrency. Flattening a spike into a queue means a smaller fleet can serve it.
• Review existing workloads for network savings: VPC Flow Logs, Cost Explorer filtered by usage type (DataTransfer-*, NatGateway-Bytes), and Trusted Advisor.

Cost visibility and governance

• Multi-account billing: use separate accounts per team or environment, and Organizations for a single payer. Tag everything (project, owner, environment) and activate tags for chargeback.
• Put alarms on spend (Budgets) before surprises, not after.