Last reviewed: May 2026
A scannable reference of architectural patterns the SAA-C03 exam tests. Read top-to-bottom, or jump to a section.
Three-tier app: web, app, DB. DB must be unreachable from the internet under any circumstance.
Public subnets for web tier (ALB). Private subnets for app and DB tiers. DB security group allows traffic only from the app-tier security group (not from CIDR ranges).
Why: Subnet routing tables enforce reachability; security-group-to-security-group references encode least-privilege at the SG layer and survive IP changes.
EC2 instance needs to access S3. Avoid embedded credentials.
IAM role attached via instance profile. SDK retrieves temporary credentials from IMDSv2.
Why: Long-lived access keys on instances are the #1 cause of credential leaks. Roles rotate automatically, never persisted.
Block SSRF attacks that try to read EC2 instance metadata.
Enforce IMDSv2 (`HttpTokens=required`) at instance launch. Reject IMDSv1 unauthenticated requests.
Why: IMDSv2 requires a session token via PUT before the metadata endpoint responds; SSRF attacks that only do GETs are blocked.
Service A in Account A invokes Lambda in Account B. Least privilege.
Resource-based policy on the target Lambda granting `lambda:InvokeFunction` to Account A's role principal. Caller assumes its own role and invokes directly - no role chaining needed.
Why: Resource policies are the simplest cross-account pattern for service-fronted resources (Lambda, S3, SNS, SQS, KMS).
Other AWS accounts need to upload to a central S3 bucket.
Bucket policy granting `s3:PutObject` to external account principals. Add `bucket-owner-full-control` ACL requirement so the bucket owner retains control of objects.
Why: Without `bucket-owner-full-control` (or `BucketOwnerEnforced` Object Ownership), uploaded objects are owned by the writer account.
Prevent any S3 bucket in the org from being made public.
Enable S3 Block Public Access at the account level (and Organizations-wide via SCPs). Overrides bucket-level ACLs and policies.
Why: Account-level setting wins over per-bucket settings - defense against accidental misconfiguration.
Developers must self-serve IAM roles but cannot grant beyond a defined max-permission set.
Permission boundaries on the developer principal. Effective permissions = identity policy ∩ boundary.
Why: SCPs apply at the account/OU level; boundaries scope individual principals. Use boundaries for delegated admin patterns.
Restrict an OU to specific Regions for data-residency compliance.
Service Control Policy in Organizations denying any action where `aws:RequestedRegion` is not in the allowed list.
Why: SCPs are the only mechanism that can deny actions the account itself permits. IAM cannot deny what an account-root could grant.
Workforce single sign-on across many AWS accounts; integrate with corporate IdP.
AWS IAM Identity Center (formerly AWS SSO) with SAML/OIDC federation to the corporate IdP. Permission sets map to roles in member accounts.
Why: Identity Center is the canonical multi-account workforce identity. Cognito is for application end users, not employees.
Pick Cognito User Pool vs Identity Pool.
User Pool = sign-up / sign-in / JWT issuance for app users. Identity Pool = exchange tokens for temporary AWS credentials. Most apps use both: User Pool authenticates, Identity Pool authorizes AWS access.
Add custom validation step to Cognito sign-in (e.g. allowlist email domain).
Lambda triggers: Pre Sign-up, Pre Authentication, Define/Create/Verify Auth Challenge. Validate or reject in the Lambda.
Need full control over key rotation, deletion, and per-key audit trail.
Customer-managed KMS key (CMK). AWS-managed keys (`aws/<service>`) are simpler but offer no key-policy control or visibility into individual key usage.
Why: CMKs let you scope access per key in CloudTrail, set key policies for cross-account use, and disable/schedule deletion.
Account B needs to decrypt S3 objects encrypted with Account A's CMK.
Key policy on the CMK grants `kms:Decrypt` to Account B principals. Account B's IAM also needs `kms:Decrypt` on the key ARN. Both halves required.
Why: KMS cross-account requires explicit allow on both the key policy and the caller IAM identity (unlike most resource policies).
Encrypt data in `us-east-1`; decrypt in `us-west-2` after replication, without re-encrypting.
KMS multi-region key. Primary in one Region, replica in another, both with the same key material and ID.
Why: Avoids the ciphertext re-wrap dance for cross-Region failover or DR.
Encrypt large objects without per-object KMS API calls dominating cost.
Envelope encryption. KMS generates a data key (one API call); use the data key to encrypt the payload locally; store encrypted-data-key alongside the ciphertext.
Why: KMS is rate-limited and priced per request. Envelope pattern is the canonical way to encrypt data > a few KB.
Pick Secrets Manager vs SSM Parameter Store SecureString.
DB credentials with automatic rotation, cross-account share, large secrets → Secrets Manager. Config flags, app settings, simple secrets, lowest cost → SSM Parameter Store.
Why: Secrets Manager has built-in rotation Lambdas for RDS/Aurora/DocumentDB/Redshift; Parameter Store has no native rotation but is free for Standard tier.
Rotate RDS password automatically every 30 days.
Secrets Manager with managed rotation. Built-in Lambda template handles single-user rotation against the RDS endpoint. Apps fetch the secret at connect time (cached) - no app redeploy.
Mitigate Layer 7 HTTP flood without blocking legitimate spikes.
AWS WAF rate-based rule (e.g. 2000 requests / 5 min per IP) on the ALB or CloudFront. Combine with managed rule groups for known-bad IPs.
Why: WAF rate rules track per-source-IP; auto-block when threshold exceeded; release after the window.
Mission-critical app needs DDoS cost-protection and 24×7 SRT support.
AWS Shield Advanced on CloudFront / ALB / NLB / Global Accelerator. Includes cost protection (refunds for scaling spend during attack) + Shield Response Team access.
Why: Shield Standard is automatic and free; Advanced adds protections and SLA. CloudFront is always the recommended front door.
Pick security group vs NACL.
Stateful, attach to ENI, allow-only → security group (default). Stateless, subnet-level, allow + explicit deny → NACL. Use NACLs for blanket deny rules (block IP ranges); SGs for everything else.
Why: NACLs evaluate inbound and outbound separately. SGs auto-allow return traffic.
EC2 in private subnet must reach S3/DynamoDB without NAT egress cost.
VPC gateway endpoint for S3 and DynamoDB. Free, route-table entry, no NAT.
Why: Gateway endpoints are S3/DynamoDB only. Saves NAT data-processing charges and keeps traffic on the AWS backbone.
Private subnet must reach AWS service APIs (KMS, Secrets Manager, ECR, etc.) privately.
VPC interface endpoint (PrivateLink) per service. ENI in your VPC, charged per hour + per GB.
Why: Interface endpoints work for almost every AWS service. Use to remove NAT egress for service calls.
SaaS provider exposes its in-VPC service to customer accounts privately, without VPC peering or maintaining customer routing.
AWS PrivateLink endpoint service backed by an NLB. Customers create interface endpoints to consume.
Why: No CIDR overlap concerns, no peering meshing, one-way exposure (provider sees no customer traffic).
Connect 30+ VPCs across accounts and on-premises in a hub-and-spoke topology.
AWS Transit Gateway. Single attachment per VPC; route tables segment traffic.
Why: Full-mesh peering requires N×(N-1)/2 connections. TGW scales linearly and supports cross-account via RAM.
Hybrid connectivity that needs predictable bandwidth, low latency, and encryption.
Direct Connect with a Site-to-Site VPN over the DX (MACsec or IPsec). DX alone is unencrypted; VPN over DX is private + encrypted + low-jitter.
Why: Plain VPN over internet is cheap but has variable latency. DX alone is fast but plaintext at the link layer.
Continuous threat detection across VPC Flow Logs, DNS, CloudTrail, EKS audit, S3 data events.
Amazon GuardDuty. Org-wide via Organizations delegated admin.
Why: Managed threat-detection. Findings into Security Hub or EventBridge for response automation.
Discover and classify PII / PHI in S3 buckets.
Amazon Macie. ML-based sensitive-data discovery, S3-scoped, integrates with Security Hub.
Continuous CVE scanning for EC2, ECR images, Lambda functions.
Amazon Inspector v2. Auto-discovers resources via Systems Manager Agent, scans against published CVEs.
Aggregate findings from GuardDuty, Inspector, Macie, IAM Access Analyzer into one dashboard.
AWS Security Hub. CSPM with AWS Foundational Security Best Practices and CIS standards.
Enforce that all EBS volumes are encrypted; remediate non-compliant resources automatically.
AWS Config rules (managed `encrypted-volumes`) + Systems Manager Automation runbook for remediation, triggered via Config remediation action.
Single tamper-proof audit log across all accounts in the org.
Organization trail with log-file validation enabled, written to a central S3 bucket with bucket policy denying delete.
Why: Org trails auto-enable in all member accounts (current and future). Validation hashes prove logs weren't modified.
Multiple departments need scoped access to different prefixes in a shared S3 bucket.
S3 Access Points - one per department, each with its own access policy and (optionally) VPC restriction.
Why: Cleaner than a sprawling bucket policy; access points have their own ARNs and DNS names.
PCI DSS workload - strict isolation from non-PCI accounts.
Dedicated AWS account inside an Organizations OU with SCPs restricting service / region access. Separate VPC, KMS keys, IAM roles. Network Firewall or GWLB for egress inspection.
Why: Account boundary is the strongest blast-radius isolation in AWS.
Public TLS cert for `*.example.com` on ALB and CloudFront. Renew automatically.
AWS Certificate Manager (ACM) public certificate with DNS validation in Route 53. Auto-renews 60 days before expiry.
Why: Free for use with AWS-integrated services. Email validation works but DNS validation is preferred for automation.
Production RDS database with sub-minute failover.
RDS Multi-AZ deployment (or Multi-AZ DB Cluster). Synchronous replication to standby; automatic failover via DNS endpoint switch.
Why: Multi-AZ is for HA, not read scaling. Read replicas are for scaling reads (and async; potential lag).
Pick Aurora vs RDS for a new MySQL/PostgreSQL workload.
Aurora for higher throughput, faster failover, up to 15 read replicas, Global Database, Serverless v2. RDS for older engines (MariaDB, Oracle, SQL Server) or simpler/cheaper deployments.
Why: Aurora storage is shared across replicas (no replica lag from storage). Failover < 30s typical.
Active-passive multi-Region database with < 1s replication lag and < 1 min RTO.
Aurora Global Database. Storage-level replication to up to 5 secondary Regions; promote a secondary to primary in disaster.
Why: Replication uses dedicated infrastructure; cross-Region lag typically < 1s. Read replicas in remote Regions for low-latency local reads.
Variable / unpredictable database load with periods of idle.
Aurora Serverless v2. Scales in 0.5 ACU increments; sub-second scale events; no full pause but very low minimum.
Why: v2 keeps the connection open during scale events (unlike v1). Pay per ACU-second.
Single-digit ms reads + writes in 3+ Regions, with last-writer-wins replication.
DynamoDB Global Tables. Multi-active replication with last-writer-wins conflict resolution.
Why: Active-active in every Region; no leader. Use when application-level conflict tolerance is acceptable.
Recover a DynamoDB table to a specific point in the last 35 days after accidental delete.
Enable Point-in-Time Recovery (PITR). Restore creates a new table at the chosen second.
Route traffic to primary Region; fail over to secondary on health check failure.
Route 53 failover routing policy. Active health check on the primary endpoint; secondary record serves when primary is unhealthy.
Why: Application-layer health check (HTTP path) catches partial failures TCP probes miss.
Send each user to the lowest-latency healthy Region.
Route 53 latency-based routing. Health-check each endpoint; Route 53 returns the lowest-latency healthy answer per query.
Canary rollout: send 10% to v2, 90% to v1.
Route 53 weighted routing. Two records same name, different targets, weights 10 and 90.
EC2 instances take 3 minutes to initialize; scale-out is too slow during traffic spikes.
Auto Scaling warm pool. Pre-initialized instances kept stopped (cheaper) ready to start in seconds.
Why: Cold launch + bootstrap is the long pole. Warm pool moves that work off the critical path.
On scale-in, drain in-flight work and persist logs before instance terminates.
Auto Scaling lifecycle hook in `Terminating:Wait`. Hook publishes to SNS/EventBridge; handler completes drain and calls `complete-lifecycle-action`.
Cut compute cost on a non-critical fleet that tolerates interruption.
ASG with mixed-instances policy: base capacity on On-Demand, additional capacity on Spot, multiple instance types and AZs for diversification.
Why: Diversifying across instance types reduces Spot interruption risk vs single-pool.
Pick ALB vs NLB.
HTTP/HTTPS, path/host routing, WAF integration, OIDC auth → ALB. TCP/UDP/TLS at extreme scale, static IP per AZ, lowest latency, preserve client source IP → NLB.
Insert a third-party security appliance fleet in line for traffic inspection across VPCs.
Gateway Load Balancer (GWLB) with appliance fleet as targets. Traffic encapsulated via GENEVE; transparent insertion via routing.
Poison messages keep failing handlers and re-queueing.
SQS Dead-Letter Queue. Configure `maxReceiveCount` on the source queue; messages exceeding the count move to the DLQ for inspection.
Strict ordering and exactly-once processing per message group.
SQS FIFO queue with content-based deduplication or explicit `MessageDeduplicationId`. Use `MessageGroupId` for parallel ordered groups.
Why: Standard SQS is at-least-once with no ordering guarantee. FIFO has lower throughput unless using high-throughput mode.
Async Lambda fails on downstream timeout - capture failed events for replay.
Lambda Destinations: configure failure destination as SQS / SNS / EventBridge / another Lambda. Success destinations also supported.
Why: Cleaner than DLQ on the function: destinations get the full event + response payload; DLQs only get the trigger event.
Multi-step workflow needs per-task retry with exponential backoff and error catch.
AWS Step Functions Standard workflow. `Retry` block with `IntervalSeconds`, `MaxAttempts`, `BackoffRate`. `Catch` block routes specific errors to a recovery state.
CloudFront origin (S3 or ALB) fails - fall back to a secondary origin without DNS changes.
CloudFront origin group with primary + secondary. Configure failover criteria (4xx/5xx codes). CloudFront retries against secondary.
Centralize backups across EBS, RDS, DynamoDB, EFS, FSx with one retention policy.
AWS Backup with backup plans + resource selection by tag. Cross-account / cross-Region copy supported. Vault Lock for compliance immutability.
Ransomware-resistant backups: even an admin cannot delete before retention.
AWS Backup Vault Lock in compliance mode. WORM enforcement; even root can't shorten retention.
Pick a DR pattern by RPO/RTO requirement.
Backup & Restore: RPO hours, RTO hours, cheapest. Pilot Light: RPO mins, RTO 10s of mins. Warm Standby: RPO seconds, RTO minutes. Multi-Site Active-Active: RPO ~zero, RTO seconds, most expensive.
Replicate critical bucket cross-Region for DR with sub-15-min RPO.
S3 Cross-Region Replication (CRR) with S3 Replication Time Control (RTC). 99.99% of objects in 15 min.
Why: Standard CRR is best-effort. RTC adds an SLA + replication metrics in CloudWatch.
Protect S3 objects from accidental delete and ransomware overwrite.
Enable S3 Versioning + MFA Delete + Object Lock (governance or compliance mode) on critical buckets.
Why: Versioning preserves overwrites/deletes; Object Lock blocks deletion before retention; MFA Delete adds a second factor for permanent removal.
Global app needs zero-RTO failover across two Regions.
Active-active across Regions: Global Accelerator or Route 53 latency routing for ingress; DynamoDB Global Tables / Aurora Global Database for data; cross-Region replication for object stores.
TCP/UDP traffic with low jitter to nearest healthy Region; static anycast IPs.
AWS Global Accelerator. Two anycast IPs; routes to nearest endpoint over the AWS backbone.
Why: Better than Route 53 latency for non-HTTP. Faster failover (anycast) + static IP allow-listing.
Lambda processes orders from SQS - message may be delivered twice.
Idempotency: store request hash in DynamoDB with TTL; PUT-IfNotExists on every retry. Or use FIFO queue with deduplication.
Voluntary pod evictions (node drain, cluster autoscaler) take down all replicas of a deployment.
Kubernetes PodDisruptionBudget specifying `minAvailable` or `maxUnavailable`. Cluster respects it during voluntary disruptions.
Pick an S3 storage class.
Frequent access → Standard. Unknown access pattern → Intelligent-Tiering. 30+ day infrequent → Standard-IA. Single-AZ acceptable, infrequent → One Zone-IA. Archive, ms retrieval → Glacier Instant. Archive, mins → Glacier Flexible. Archive, hours, cheapest → Glacier Deep Archive.
Mixed-access bucket with unpredictable patterns; auto-optimize cost.
S3 Intelligent-Tiering. Monitors access; auto-moves objects across tiers (Frequent / Infrequent / Archive Instant / Archive / Deep Archive). No retrieval fees.
Why: Tiny per-object monitoring fee, but cheaper than guessing wrong. Default for unknown patterns.
Upload large objects (> 100 MB) reliably and fast over the internet.
S3 Multipart Upload (parallel parts) + S3 Transfer Acceleration (CloudFront edge ingestion).
Why: Parallel parts saturate bandwidth; Transfer Acceleration offloads the WAN hop to the AWS backbone.
Pick EBS volume type.
General-purpose, default → gp3 (3000 baseline IOPS, 125 MB/s; tunable). High IOPS database → io2 Block Express. Big-data sequential throughput → st1. Cold archive → sc1. Boot volumes → gp3.
Why: gp3 decoupled IOPS/throughput from size; cheaper than gp2 at equivalent perf.
Multiple EC2 instances must read+write the same block volume.
EBS Multi-Attach with io2 / io1 (Nitro instances only). Concurrent attach to up to 16 instances in the same AZ.
Why: Application must coordinate writes (cluster filesystem). EFS is the default for shared file access; Multi-Attach is for clustered DBs that need block.
Pick a shared file system.
POSIX-compliant Linux NFS, multi-AZ, auto-scaling → EFS. Windows SMB / AD-integrated → FSx for Windows. HPC, Lustre, S3-linked → FSx for Lustre. NetApp ONTAP features (snapshots, NetApp tooling) → FSx for ONTAP. ZFS → FSx for OpenZFS.
EFS - pick throughput mode.
Variable workload, scales with size → Bursting. Predictable high throughput → Provisioned. Burst-sensitive but want elastic spend → Elastic (default for new file systems, scales automatically).
On-premises file/block/tape backup that integrates with S3 / Glacier.
AWS Storage Gateway: File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI → S3 + EBS snapshots), Tape Gateway (VTL → Glacier).
Static assets + API responses with global users; reduce origin load.
CloudFront with appropriate cache policy. Long TTLs for static; cache-key includes only essential headers/query strings. Use Origin Shield for high-cardinality origins.
Why: Cache hit ratio drives both performance and cost. Wrong cache key (e.g. include all headers) destroys hit rate.
Manipulate request/response at the edge.
Lightweight, viewer-side, sub-ms (header rewrites, redirects, A/B) → CloudFront Functions. Heavier, Node.js / Python, longer compute, network access → Lambda@Edge.
Pick ElastiCache Redis vs Memcached.
Replication, persistence, pub/sub, sorted sets, Multi-AZ failover → Redis. Multi-threaded, simple key/value, horizontal sharding only → Memcached.
Redis session store needs HA with auto-failover across AZs.
ElastiCache for Redis replication group with Multi-AZ + automatic failover enabled. Primary in one AZ, replicas in others.
DynamoDB read latency from microseconds; cache without app changes.
DynamoDB Accelerator (DAX). In-VPC managed cache; same DynamoDB SDK; transparent read-through.
Why: ElastiCache requires app-level cache logic. DAX is drop-in for DynamoDB.
Pick a cache strategy.
Lazy loading (cache miss → fetch + populate): simple, only caches what's requested. Write-through (write to cache + DB on update): cache always fresh, but extra writes. TTL: bound staleness on either pattern.
Pick a compute platform.
Sub-15-min event-driven, sub-second scale, no infra → Lambda. Long-running containers, no node management → Fargate. Custom kernel, GPU, persistent state, cheapest sustained → EC2.
Lambda Java cold-start hurting p99 latency.
Lambda SnapStart (Java, Python, .NET). Snapshot of initialized runtime restored on invoke; up to 10× faster cold start.
Predictable burst load; cold starts unacceptable.
Provisioned Concurrency. Pre-warmed environments ready to invoke at any throughput. Combine with Application Auto Scaling for scheduled scale-up.
Why: Costs more than on-demand but eliminates cold start. Not needed for steady traffic where provisioned-concurrency utilization stays high naturally.
Pick API Gateway type.
Full feature set (request validation, transformations, API keys, usage plans) → REST API. Lower cost, lower latency, JWT/OIDC native, simpler → HTTP API. Real-time bidirectional → WebSocket API.
Mobile/web app needs GraphQL with real-time subscriptions backed by DynamoDB / Lambda.
AWS AppSync. Managed GraphQL, WebSocket subscriptions, fine-grained authz via Cognito / IAM / Lambda authorizers.
Pick Kinesis Data Streams vs Firehose vs Managed Service for Apache Flink vs MSK.
Custom consumers, ms latency, replay, multi-consumer fan-out → Data Streams. Just deliver to S3/Redshift/OpenSearch with buffering → Firehose. Stream processing (windows, joins) → Managed Service for Apache Flink. Kafka-compatible → MSK.
Athena queries scan terabytes; cost / time excessive.
Partition the data by query predicate (date, region). Convert to Parquet/ORC columnar format. Use partition projection to avoid catalog round-trips.
Why: Athena charges per-TB scanned. Columnar + partitioning often cuts cost 10-100×.
Query data sitting in S3 from Redshift without loading it.
Redshift Spectrum. External schema over Glue Data Catalog; Spectrum nodes scan S3 and stream results back to the cluster.
Choose DynamoDB capacity mode.
Unpredictable / spiky / new workloads → On-demand. Steady, predictable, hot - and cost-sensitive → Provisioned with auto-scaling. Switch modes at most once per 24 hours.
Query DynamoDB by an attribute that isn't the partition key.
Global Secondary Index (GSI) for queries on different partition key. Local Secondary Index (LSI) for alternate sort key on same partition key (LSI must be created at table-create time).
DynamoDB session table grows unbounded; sessions expire after 24h.
DynamoDB TTL on a numeric epoch attribute. DynamoDB deletes expired items asynchronously, no write capacity charged.
HPC workload needs lowest possible inter-node latency.
Cluster placement group: instances in the same AZ on the same physical rack. Up to 10 Gbps single-flow.
Why: Spread placement → max isolation (HA); Partition → big-data (Hadoop, Cassandra); Cluster → tightest latency.
Pick EC2 purchase option for a steady 24×7 fleet.
Compute Savings Plan (1y or 3y) - 66% off list, flexible across instance family, size, OS, tenancy, Region. RIs only when you need capacity reservation.
Why: Savings Plans dominate RIs for most cost-only use cases (more flexible, same discount).
Pick Compute Savings Plan vs EC2 Instance Savings Plan vs SageMaker Savings Plan.
Compute SP: max flexibility (covers EC2, Fargate, Lambda) - best default. EC2 Instance SP: family-locked, deeper discount. SageMaker SP: SageMaker-only.
Use Spot for cost savings on tolerant workloads.
Spot via ASG mixed-instances policy with capacity-optimized allocation strategy + multiple instance types. Handle 2-min interruption notice via instance metadata.
Why: capacity-optimized picks pools least likely to be reclaimed. Multiple types diversify pool risk.
Have unused Reserved Instances after migration.
Sell on the Reserved Instance Marketplace (Standard RIs only). Or convert via Convertible RIs to a different family.
Why: Convertible RIs trade slightly less discount for the right to swap.
Cut compute cost without architecture rewrite.
Migrate to Graviton (ARM64) instances. ~20% cheaper, ~40% better price-perf for many workloads. Requires multi-arch container images or recompiled binaries.
Lambda functions where the runtime supports ARM.
Set architecture to `arm64` (Graviton). 20% cheaper per ms than x86, often faster. Requires arch-compatible native deps.
Lambda cost too high; runtime CPU-bound.
Increase memory (which scales CPU and network proportionally). Use Lambda Power Tuning (Step Functions tool) to find the sweet spot - often higher memory is faster AND cheaper.
Logs and old objects accumulate in S3 Standard.
S3 Lifecycle rules: transition to IA after 30d, Glacier Flexible after 90d, Deep Archive after 180d, expire after retention. Combine with Intelligent-Tiering for unknown patterns.
Visualize S3 spend across accounts; find optimization candidates.
S3 Storage Lens. Org-wide dashboard with usage, activity, cost-saving recommendations. Advanced metrics tier for prefix-level breakdown.
NAT Gateway data-processing fees dominate the bill.
Replace AWS-service traffic with VPC Endpoints (gateway for S3/DynamoDB; interface for everything else). Move workloads needing internet egress to public subnets only when necessary.
Why: NAT Gateway charges per GB processed even for AWS-service traffic. Endpoints eliminate that path.
Cut data transfer costs.
Same-AZ, same-VPC = free. Cross-AZ = $0.01/GB each way. Cross-Region = expensive. Egress to internet = most expensive but free via CloudFront for cacheable content. Always egress via CloudFront when possible.
CloudWatch Logs costs spiraling.
Set explicit retention (default is "Never expire"). Export old logs to S3 + Glacier. Use Logs Insights only on warm data. Filter at agent (don't ship debug logs in prod).
Find right-sizing candidates across EC2, Auto Scaling Groups, EBS, Lambda.
AWS Compute Optimizer. Reads CloudWatch metrics + ML, recommends downsizing or switching family. Free for org-wide opt-in.
Detect unexpected spend spikes proactively.
AWS Cost Anomaly Detection (within Cost Explorer). ML-based monitors per service / linked account / cost category. Alerts via SNS / email.
Stop runaway spend in a sandbox account.
AWS Budgets with action: at 80% threshold, run an SNS notification; at 100%, attach a deny SCP / IAM policy via Budgets Action.
Chargeback by team or product without separate accounts.
Cost allocation tags. Activate user-defined tags in Billing console; surface in Cost Explorer + CUR. Combine with `aws:CreatedBy` for identity attribution.
Dev/test EC2 instances run 24×7 - only used 9-to-5.
AWS Instance Scheduler (CloudFormation-deployed Lambda). Tag instances with schedule names; runs cron-like start/stop. Or just `aws:autoscaling:scheduledActions` on dev ASGs.
Why: ~70% reduction on dev compute spend with off-hours stop.
Dev RDS instance idle nights/weekends.
Stop the RDS instance (single-AZ; up to 7 days, then auto-starts). Or Aurora Serverless v2 with min ACU = 0.5 (no full stop, but minimal cost when idle).
Container fleet cost optimization.
Steady, high utilization → ECS on EC2 (with Spot/Savings Plans) - cheapest. Spiky / short-lived / no node mgmt → Fargate. Fargate Spot is 70% off Fargate for tolerant workloads.
Reduce S3 / EC2 egress to internet.
Front with CloudFront. Origin → edge transfer is free; edge → user is cheaper than direct EC2/S3 egress at scale. Enable compression + appropriate TTLs.
Migrate 100 TB from on-prem NFS to S3.
AWS DataSync agent on-prem; scheduled transfer to S3. Encrypted, integrity-checked, rate-limited. Snowball Edge for 100 TB+ or low bandwidth.
Move > 1 PB from on-prem to AWS; bandwidth too slow for online transfer.
AWS Snow Family. Snowball Edge Storage Optimized (80 TB) for typical; multiple devices in parallel for 100s of TB. Snowmobile is retired - use multi-Snowball for petabyte scale.
Production RDS / ElastiCache / OpenSearch / Redshift running 24×7.
Reserved Instances for managed databases (no Savings Plan equivalent for these services). 1y or 3y; partial-upfront usually best NPV.
Quick low-effort cost wins across the account.
AWS Trusted Advisor cost checks: idle load balancers, low-utilization EC2, unattached EBS, underutilized RDS, idle Redshift. Free tier limited; full set with Business / Enterprise Support.