SAA-C03 cheat sheet — every exam topic on one page

Design Secure Architectures

Designing Secure Access: IAM Best Practices, Roles, and AWS Organizations

• SCPs and RCPs never grant permissions — they cap the maximum; effective access is the intersection of SCPs, RCPs, boundaries, and IAM policies, and an explicit deny always wins.
• SCPs bind your principals (including member root users) wherever the resource lives, but never the management account or service-linked roles; RCPs bind your resources against any caller, including outsiders.
• Harden root (MFA, no keys), remove member root credentials centrally and use AssumeRoot for root-only tasks; enforce MFA with aws:MultiFactorAuthPresent (BoolIfExists for deny-unless-MFA) or aws:MultiFactorAuthAge.
• Anything running on AWS compute gets an IAM role (ECS application code uses the task role); workloads outside AWS use IAM Roles Anywhere — never stored access keys.
• Role switching replaces your permissions for the session; role chaining is capped at one hour; source identity is the immutable audit key; revoke active sessions to cut off issued credentials.
• Cross-account: assume a role for broad access or services without resource policies (EC2, RDS); use a resource-based policy when the caller must keep its own permissions.
• Third-party vendor access = cross-account role + a vendor-generated, per-customer external ID checked with sts:ExternalId — never shared access keys.
• Workforce across many accounts = IAM Identity Center (permission sets + account assignments) using the existing directory as identity source (AD Connector for on-premises AD); app customers = Cognito.
• Permissions boundaries cap delegated roles only when enforced: require iam:PermissionsBoundary on role creation and deny editing or removing the boundary.
• Control Tower = managed landing zone on Organizations: preventive controls block API actions (mainly SCPs), detective controls are Config rules, proactive controls are CloudFormation hooks; Account Factory vends governed accounts.

Securing Workloads: VPC Design, Security Groups vs NACLs, WAF and Shield

• A route table defines the subnet: internet gateway route = public, NAT route = private, neither = isolated; only internet-facing load balancers and zonal NAT gateways belong in public subnets.
• Zonal NAT gateways sit in a public subnet, one per AZ; a regional NAT gateway needs no public subnet and spans AZs; outbound-only IPv6 uses an egress-only internet gateway.
• Security groups are stateful and allow-only (NLB groups too); NACLs are stateless, ordered allow/deny, and need ephemeral-port return rules — and long deny lists in front of HTTP belong in a WAF IP set.
• Reference security groups by ID between tiers; across inter-Region peering, use the peer CIDR instead.
• Gateway endpoints (S3, DynamoDB) are free route-table entries; interface endpoints need private DNS (plus VPC DNS attributes) to be transparent; endpoint policies plus aws:SourceVpce stop exfiltration.
• Keep origins private: CloudFront VPC origins for internal ALBs/instances, OAC with the S3 REST endpoint; AWS Network Firewall filters egress by domain name with symmetric routing.
• Shield = layer 3/4 DDoS (Advanced adds response team, cost protection, L7 auto-mitigation with a web ACL); WAF = layer 7 on CloudFront/ALB/API Gateway, never an NLB — use scoped rate-based rules and AND/NOT logic.
• GuardDuty detects (delegated admin + auto-enable, EventBridge for response); Macie finds sensitive S3 data (automated discovery, custom data identifiers).
• Cognito user pool = app sign-up/sign-in and JWTs (no guests); identity pool = temporary AWS credentials and guest access; IAM Identity Center = workforce accounts and SaaS apps.
• Secrets Manager for rotation (alternating users for zero-downtime) and cross-account access (customer managed KMS key); Parameter Store for cheap config with path-scoped IAM; Direct Connect is private but not customer-encrypted — add VPN over it or MACsec.

AWS Data Security Controls: KMS Encryption, S3 Encryption, and Key Management

• Requirement mentions editing the key policy, independent decrypt control, disabling the key, a custom rotation schedule or cross-account use → customer managed KMS key; AWS managed keys allow none of those, and their requests are still billed.
• A key policy is the root of KMS access: IAM policies work only when it delegates to the account; name a role directly to keep IAM administrators out; split key administrators from key users; use kms:ViaService to limit use to one service; grants delegate without editing the policy and last until revoked or retired.
• "Single-tenant" or "exclusive HSM control" → CloudHSM (custom key store if native service integration is also needed); FIPS 140-3 Level 3 alone is already met by KMS; "AWS must never be able to decrypt" → client-side encryption with keys held outside AWS.
• S3: SSE-S3 for baseline; SSE-KMS with a customer managed key for audit and control; Bucket Keys to cut KMS request cost (new objects only, encryption context becomes the bucket ARN); DSSE-KMS for two layers.
• No in-place encryption for EBS or RDS: EBS creates an encrypted volume from a snapshot (directly or via an encrypted copy); RDS restores an encrypted snapshot copy, with DMS CDC to shrink downtime — never an encrypted replica of an unencrypted instance.
• ACM certificates are regional except CloudFront's, which live in us-east-1; ACM renews its own certificates only while DNS validation records remain, never imported ones; enforce TLS with redirects, CloudFront viewer/origin protocol policies, an explicit aws:SecureTransport Deny, and RDS force-SSL parameters.
• KMS rotation keeps old material and the key ID/alias: customer managed keys rotate automatically on a 90–2,560-day period or on demand; imported material rotates on demand after importing new material into the same key; only asymmetric, HMAC and custom-key-store keys need new-key-plus-alias.
• Retention and recovery: Object Lock compliance mode for "no one may delete"; NoncurrentVersionExpiration to really delete in versioned buckets; S3 Replication copies only new objects and skips SSE-KMS unless configured; AWS Backup plans with cross-account copies and Vault Lock compliance mode survive an account compromise; Macie finds sensitive data, GuardDuty watches access, Access Analyzer lists sharing.

Design Resilient Architectures

Scalable, Loosely Coupled Architectures: SQS, SNS, EventBridge, Step Functions

• A queue between tiers turns a traffic spike into a backlog: SQS plus a worker tier scaling on backlog per instance is the default spike-absorption redesign.
• SQS FIFO orders messages per message group (set the group ID to the entity whose order matters) and deduplicates sends within five minutes by deduplication ID; it does not prevent redelivery after a visibility timeout.
• Retention (default 4 days, up to 14) limits how long a queue can cover an outage; standard-queue DLQs need longer retention than the source, and DLQ redrive moves fixed messages back.
• With Lambda on SQS: visibility timeout at least six times the function timeout, partial batch responses, and the event source mapping's maximum concurrency (not reserved concurrency) to cap load.
• SNS-to-SQS fan-out gives every consumer its own durable buffer; SNS filters on attributes or body, SQS FIFO queues subscribe only to SNS FIFO topics, and EventBridge wins on AWS/SaaS sources, Step Functions targets, cross-account buses and replay.
• Step Functions orchestrates multi-step work; Express workflows stop at five minutes and support neither callbacks nor .sync, and Distributed Map handles millions of S3 items.
• Per-client throttles plus quotas are REST API usage plans; WAF rate-based rules block by rate, not quota. Fargate has no GPUs, privileged containers or per-host daemons.
• Match the lever to the bottleneck: target tracking (plus predictive for cycles, scheduled for known dates), NLB for non-HTTP or static IPs, caches with TTLs, CloudFront to cut origin load, Global Accelerator for static IPs and fast failover, read replicas or custom Aurora endpoints for reads, EFS for shared files.

AWS High Availability and Disaster Recovery: RTO, RPO, and the Four DR Levels

• High availability recovers quickly and may blip; fault tolerance never interrupts. A running hot standby still interrupts during switch-over; only load already shared across active instances does not.
• Static stability: to keep N instances after losing one of Z zones, run N × Z/(Z−1) spread evenly (6 needed = 9 across three zones or 12 across two).
• RPO is the data you can afford to lose, RTO is the downtime you can afford: extract both, diagnose which one is missed, then pick the cheapest strategy that meets them.
• The DR ladder trades cost for speed: backup and restore (hours) → pilot light (tens of minutes) → warm standby (minutes) → multi-site active-active (near zero). Copy AMIs and templates to the recovery Region in advance.
• RDS Multi-AZ DB instance: synchronous, automatic, standby NOT readable. Multi-AZ DB cluster: two readable standbys, faster failover. Read replicas: asynchronous, readable, promoted manually, then repoint DNS.
• Aurora Global Database has one writer Region even with write forwarding (switchover for planned moves, failover with data loss for outages); DynamoDB global tables are multi-active, eventual by default or strongly consistent across exactly three Regions.
• Match the ALB zones to the ASG zones, switch the ASG to ELB health checks, and keep replacement checks shallow so a database blip does not recycle the fleet.
• Route 53 failover = health check detection + record TTL; set Evaluate Target Health on alias records, base checks on CloudWatch alarms for business metrics, and remember a notify-only alarm fails nothing over.
• EBS (even Multi-Attach) is one AZ, instance store dies with the instance, EFS and S3 span AZs; S3 replication is forward-only (Batch Replication backfills) and versioning, not replication, defends against deletion.
• Ransomware-proof backups = cross-account copy into a vault with Vault Lock in compliance mode, with customer managed KMS keys for RDS, Aurora and EBS.
• Quotas are per Region: raise them in the standby Region ahead of time (quota request templates for new accounts), and answer throttling with exponential backoff and jitter.
• X-Ray needs tracing on the API Gateway stage plus Lambda active tracing; custom sampling rules catch rare errors, groups only filter what was recorded.

Design High-Performing Architectures

High-Performing Storage: S3 vs EBS vs EFS, Volume Types, and Hybrid Options

• Classify by access pattern first: mounted raw disk = EBS (block), shared directories across instances = EFS/FSx (file), API-accessed web-scale data = S3 (object).
• EBS ladder: gp3 by default (up to 80,000 IOPS and 2,000 MiB/s, single-digit-millisecond latency); io2 Block Express when IOPS exceed that or latency must be sub-millisecond; st1 for cheap sequential throughput; sc1 for cold data that must stay mounted. HDDs never boot.
• gp3 decouples performance from capacity, and Elastic Volumes changes type, IOPS and throughput in place with no downtime. RAID 0 adds IOPS, never a lower latency class.
• Multi-Attach is io1/io2 only, same AZ, cluster-aware file system: a shared block device, not a substitute for EFS.
• Instance store is the fastest storage EC2 can touch and vanishes on stop or failure; io2 Block Express is the durable, network-attached alternative when the data is not replicated elsewhere.
• EFS: Elastic throughput is the default for spiky or unknown load, Provisioned for steady known load; storage classes (Standard, IA, Archive) are the cost lever, and Archive needs Elastic throughput. One Zone is cheaper but lives and fails with one AZ.
• Windows/SMB/AD means FSx for Windows File Server (Multi-AZ to survive an AZ failure); FSx for OpenZFS is NFS only; HPC over S3 data means FSx for Lustre, scratch for short bursts.
• S3 by bottleneck: multipart and byte-range for size, Transfer Acceleration for distance (no caching), prefixes (re-key existing hot objects) and CloudFront for 503 Slow Down, S3 Express One Zone for same-AZ latency.
• Hybrid: Storage Gateway for ongoing access with a local cache (Tape Gateway archives to Glacier Deep Archive without changing backup jobs); DataSync for one-time or scheduled movement.
• Read the qualifier: under MOST cost-effective, pick the cheapest option that still meets every stated requirement; under MOST performant, meet the performance requirement first and treat cost as secondary.

Elastic Compute: Auto Scaling Policies, Lambda Tuning, and Compute Selection

• Pick the compute service by duration, trigger, and management appetite: event-driven and under 15 minutes = Lambda; containers with least overhead = Fargate; hardware control = EC2; queued heavy jobs = AWS Batch; named big-data frameworks = EMR, or EMR Serverless when no cluster should be chosen or kept running.
• Over 15 minutes rules out Lambda — container-image functions included; a named framework (Spark/Hadoop/Hive) means EMR; otherwise batch jobs mean AWS Batch (Spot for retryable work), and a scheduled container job is an ECS task on Fargate started by EventBridge Scheduler.
• Choose EC2 families by the bottleneck resource — C for CPU, R/X for memory, I/D for local storage I/O, P/G for accelerators, M as the balanced default; right-size with Compute Optimizer, which recommends types in both directions, unlike Trusted Advisor's idle-instance check.
• Lambda memory sets CPU: more memory can make a function faster and cheaper, but single-threaded code stops speeding up near 1,769 MB (one vCPU). Cold starts are fixed by provisioned concurrency (paid, always warm) or SnapStart (snapshot restore), never by memory.
• Target tracking is the default; step scaling = one alarm with step adjustments per breach range; simple scaling = one adjustment plus a cooldown; scheduled = known times (raise min/desired, not just max); predictive = recurring patterns, in forecast-and-scale mode.
• Default instance warmup keeps booting instances out of the metrics while counting their capacity; the health check grace period only delays health checks; warm pools (Stopped, Running, Hibernated) pre-initialize slow instances.
• Scale worker fleets on backlog per instance with a target of acceptable latency ÷ per-message processing time — raw queue length is not proportional to fleet size.
• Consumers on one SQS queue compete for messages; when every service must see every event, fan out through SNS to one queue per consumer. ECS vs EKS turns on a Kubernetes requirement; GPUs rule out Fargate, and a custom AMI rules out ECS Managed Instances.

High-Performing Databases: Aurora vs RDS, DynamoDB, DAX and ElastiCache

• Pick relational (RDS/Aurora) for ad hoc SQL and unplanned joins; DynamoDB supports ACID transactions, so transactions alone don't rule it out — unplanned query patterns do.
• Homogeneous migrations keep the engine; heterogeneous ones need DMS Schema Conversion or AWS SCT for schema and code, plus AWS DMS (full load + CDC) for the data. RDS to Aurora: create an Aurora read replica, then promote.
• Read replicas scale reads (asynchronous, readable, cross-Region capable); a Multi-AZ DB instance standby cannot serve reads, while a Multi-AZ DB cluster (MySQL/PostgreSQL) has two readable standbys.
• Aurora Replicas share the cluster volume, so lag is typically under 100 ms, behind one reader endpoint; Global Database replicates at the storage layer for sub-second cross-Region reads; Serverless v2 can scale to 0 ACUs and pause.
• DynamoDB: provisioned + auto scaling for steady traffic, on-demand for unpredictable or idle-then-bursty traffic — on-demand instantly handles up to double the previous peak, and warm throughput pre-warms for a known launch.
• Throttling with capacity to spare is a hot partition (each partition caps at about 3,000 RCU / 1,000 WCU); fix the key with high cardinality or write sharding. A throttled GSI also throttles base-table writes.
• A Query needs the index's partition key value, so the attribute you look up by must be the GSI's partition key; GSIs can be added any time, LSIs only at table creation.
• DAX is the microsecond, API-compatible cache for DynamoDB; ElastiCache fronts everything else — Valkey/Redis OSS for persistence, failover and sorted sets, Memcached for the simplest multi-threaded cache.
• Lazy loading + TTL caches only what is read; write-through keeps data fresh but can fill memory with unread items. RDS Proxy pools connections and speeds failover — unlike a bigger instance or reserved concurrency.

Scalable Networks: CloudFront vs Global Accelerator, Transit Gateway, ALB vs NLB

• CloudFront caches and accelerates HTTP content; Global Accelerator provides two static anycast IPs for TCP/UDP with near-instant cross-Region failover — protocol and static-IP requirements decide between them.
• ALB for HTTP routing (path/host rules, Lambda targets); NLB for TCP/UDP at extreme scale, Elastic IPs and client-IP preservation (default on for instance targets, off for IP targets on TCP/TLS); a TCP listener passes TLS through, a TLS listener terminates it; GWLB for inline third-party appliances.
• An ALB has no static IPs: put an NLB in front of it (an Elastic IP per AZ, routing unchanged) or Global Accelerator (one anycast IP set across Regions with fast failover).
• CloudFront VPC origins front an internal ALB, NLB (not TLS listeners) or EC2 in private subnets; the VPC still needs an attached internet gateway, and the CloudFront-VPCOrigins-Service-SG is the tight origin rule.
• Size VPC CIDRs for growth and keep every range non-overlapping; subnet and primary CIDRs cannot be resized, so IP exhaustion is fixed with a secondary CIDR and new subnets.
• Placement groups: cluster = lowest latency, one AZ (HPC); spread = max seven instances per AZ on distinct hardware (critical few); partition = failure-isolated groups for large distributed systems (Kafka, Hadoop).
• VPC peering is never transitive and has no edge-to-edge routing; Transit Gateway gives transitive, propagated, segmentable routing at the cost of attachment and per-GB charges and an extra hop, and neither tolerates overlapping CIDRs — PrivateLink does.
• Direct Connect buys consistent latency and bandwidth; VPN (even accelerated) stays internet-dependent. A VPN is the cheap automatic DX backup via BGP; a second DX at another location is the backup that matches the primary.
• Same-AZ placement minimizes latency and cross-AZ charges, but multi-AZ spread wins when availability is the priority; zone-local cache reads need a same-zone replica's node endpoint, not the reader endpoint; across Regions, Route 53 latency-based routing sends each user to the fastest Region.

Data Ingestion & Transformation: Kinesis, Glue, Athena, and Lake Formation

• Kinesis Data Streams = real-time with custom consumers, replay within the retention period (24 hours default, up to 365 days), and per-shard ordering via the partition key.
• Each shard takes 1 MB/s or 1,000 records/s of writes and serves 2 MB/s of reads; one partition key always maps to one shard, so a hot key needs a finer-grained key — not more shards or on-demand mode.
• Shared-throughput consumers split each shard's 2 MB/s; enhanced fan-out gives every consumer its own 2 MB/s per shard with low push latency.
• Amazon Data Firehose = managed near-real-time delivery with Lambda transforms and built-in Parquet/ORC conversion; it has no consumer interface, so the composite pattern is Data Streams for real-time readers with Firehose reading the stream to archive to S3. "Kafka" means Amazon MSK.
• Transfer selection: DataSync = one-time or scheduled copies (VPC service endpoint for private VIFs, task bandwidth limits); Storage Gateway = ongoing cached hybrid access; Transfer Family server = partners push, SFTP connector = you pull/push to their server. Snowball Edge is closed to new customers: online bulk = DataSync (plus a temporary Direct Connect hosted connection if bandwidth is short); offline = AWS Data Transfer Terminal or a Partner service.
• Secure ingestion: interface VPC endpoints with private DNS, plus a resource-policy Deny on aws:SourceVpce to make the stream or bucket reject other paths; Transfer Family VPC-hosted internet-facing endpoints give Elastic IPs and security groups.
• The Glue Data Catalog is the shared metastore for Athena, EMR, and Redshift Spectrum; Glue jobs are the serverless ETL default, with job bookmarks for incremental input and partitionKeys for prunable output. Lake Formation centralizes table/column permissions.
• Athena prunes only on table partitions, not prefixes — use partition projection or a crawler; columnar Parquet plus compression plus date partitions is the cost fix. Result reuse and CTAS are not layout fixes; QuickSight (Amazon Quick Sight) dashboards over Athena should usually use SPICE with a scheduled refresh.

Design Cost-Optimized Architectures

Cost-Optimized Storage: S3 Classes, Lifecycle Policies, and EBS Economics

• Price the whole bill — storage, retrievals, requests and minimum durations (IA 30 days, Glacier Instant/Flexible 90, Deep Archive 180) — before picking a class; the duration trap mainly keeps data that lives days to a couple of weeks in S3 Standard.
• Standard-IA vs Glacier Instant Retrieval: both read in milliseconds; data read about monthly favours Standard-IA, data read a few times a year favours Glacier Instant Retrieval's lower storage price despite its higher retrieval fee.
• One Zone-IA only for re-creatable or secondary-copy data; S3 Express One Zone is a costly performance class, never a cost saving.
• Unknown or changing access = S3 Intelligent-Tiering: no retrieval fees or minimum durations, objects under 128 KB not tiered, optional Archive Access (90+ days) and Deep Archive Access (180+ days) tiers need restores and count from last access, not creation.
• Versioned buckets need NoncurrentVersionExpiration (NoncurrentDays, NewerNoncurrentVersions); every upload bucket needs AbortIncompleteMultipartUpload; a bucket shown as Disabled has never been versioned.
• gp3 beats gp2 (3,000 IOPS / 125 MiB/s baseline at any size); Elastic Volumes can change type and grow but never shrink; st1/sc1 for cheap sequential throughput.
• Audit the leaks: unattached volumes, stale snapshots (DLM manages only its own; archive only long-kept snapshots — full copies, 90-day minimum, up to 72-hour restore), noncurrent versions, incomplete multipart uploads.
• Cheapest service by interface: S3 for object access, EBS for single-instance block, EFS (with lifecycle to IA) for shared Linux files, FSx for Lustre scratch linked to S3 for temporary HPC runs; elastic S3/EFS when capacity growth is unpredictable.
• AWS Backup: daily warm rules with short retention plus monthly rules moved to cold storage (retention at least 90 days beyond the move; EBS archive only from monthly-or-rarer rules).
• Move data in with DataSync (scheduled, throttled, verified), Transfer Family (SFTP into S3 or EFS) or Storage Gateway (S3 File Gateway stores native objects; Volume Gateway stores block volumes) — Snowball Edge is not available to new customers.
• Cost tools by job: activated tags (management account) attribute, Cost Explorer analyzes, Budgets alerts on actual or forecasted spend, CUR 2.0 via Data Exports gives line items, Cost Anomaly Detection flags the unexpected.

Cost-Optimized Compute: Spot vs Reserved vs Savings Plans, and Lambda vs EC2

• Layer the purchase mix: commitments sized to the steady baseline, On-Demand behind Auto Scaling for the variable layer, Spot (up to 90% off) for interruptible work — never commit to peak, never put un-interruptible work on Spot.
• Depth versus flexibility: Standard RIs and EC2 Instance Savings Plans go up to 72% but lock a family; Compute Savings Plans go up to 66% but follow usage anywhere, including Fargate and Lambda, which no EC2-only instrument covers.
• A commitment is one hourly amount billed every hour of the term: it cannot be scheduled, its flexibility moves the discount but not the bill, RIs are applied before Savings Plans — so right-size first and size the plan to the uncovered floor.
• Spot is safe only for stateless, retryable or checkpointable work, in an ASG mixed instances policy (On-Demand base, many types across AZs, price-capacity-optimized); on ECS, put the base on FARGATE and the larger weight on FARGATE_SPOT.
• Pick the cost tool by job: Compute Optimizer recommends, Cost Explorer analyzes (its purchase recommendations follow current usage), Budgets alerts, the CUR itemizes, and tags count only after activation in the management account; consolidated billing shares commitments by default.
• Pick compute by utilization: Lambda for low or spiky volume, EC2 with commitments for sustained load, Fargate for containers without cluster management — and Fargate bills the vCPU and memory a task requests.
• Match scaling to demand: target tracking for unpredictable load, scheduled actions for clock-predictable ramps with slow-starting instances, scheduled stop/start for non-production; hibernation (enabled at launch, Linux RAM under 150 GiB, encrypted EBS root) for intermittent instances with long warm-up.
• Offload and place wisely: CloudFront caching shrinks the origin; CloudFront Functions beat Lambda@Edge for simple high-volume viewer logic; Local Zones (AWS-run metro) vs Outposts (your premises) vs Wavelength (5G); one ALB for many HTTP services, NLB for UDP and static IPs, GWLB for inline appliances.

Cost-Optimized Databases: DynamoDB vs RDS, Aurora Serverless, and Caching

• Workload shape decides the pricing model: idle-heavy or unpredictable load belongs on serverless (Aurora Serverless v2, DynamoDB on-demand); steady 24/7 load belongs on provisioned capacity with a commitment.
• Engine choice is a cost lever: open-source engines carry no license fee, and Aurora's premium buys shared-storage replicas (up to 15 without duplicating storage) — pay it only when you use that.
• Aurora Serverless v2 at a 0-ACU minimum pauses when idle and bills only storage, but the first connection waits to resume (about 15 seconds, longer after a day); DynamoDB on-demand has no resume delay.
• Commitments discount every hour, idle ones included: Reserved Instances (3-year All Upfront is cheapest for a fixed, steady database), ElastiCache reserved nodes, or a 1-year no-upfront Database Savings Plan when flexibility matters — with a term that ends before the workload does.
• Right-size first, then commit; non-production databases can stop on a schedule (they restart after seven days), and an instance sized only for connections gets RDS Proxy and a smaller class.
• Repetitive reads plus staleness tolerance means a cache: ElastiCache, or DAX for DynamoDB (eventually consistent reads only, and lower provisioned reads to bank the saving); diverse or must-be-fresh reads mean a replica.
• DynamoDB provisioned capacity with auto scaling fits steady or predictable curves; auto scaling reacts in minutes, so spikes that arrive in seconds belong on on-demand. Standard-IA only helps storage-dominated tables.
• Backups have two dials: automated retention (1–35 days of point-in-time restore) and scheduled snapshot frequency and retention for the long tail; delete stale manual snapshots, and export query-only archives to S3 as Parquet (not restorable) with lifecycle to Glacier.
• Use purpose-built types: Timestream for InfluxDB for time series (LiveAnalytics is closed to new customers), Parquet on S3 with Athena or Redshift for columnar analytics.
• Heterogeneous migrations use SCT plus DMS full load and CDC; homogeneous ones skip conversion — Aurora read replicas for RDS to Aurora, native tools for the schema plus DMS for data (DMS creates only tables and primary keys).
• Storage levers: gp3 instead of unneeded provisioned IOPS (for MySQL, MariaDB and PostgreSQL, 400 GiB+ includes 12,000 IOPS), storage autoscaling instead of pre-allocation, and Aurora I/O-Optimized when I/O is 25%+ of spend.

Cost-Optimized Networking: NAT Gateways, VPC Endpoints, and Data Transfer

• Price the path before the fix: inbound is free, same-AZ private traffic is free, cross-AZ is charged both directions, cross-Region and internet egress are charged — the right answer moves traffic onto a free segment. Paid transfer tools (DataSync, Transfer Acceleration) only buy speed, never lower transfer cost.
• Gateway VPC endpoints for S3 and DynamoDB are free and remove NAT processing for that traffic — but only in the route tables they are associated with, and only for the VPC's own Region; interface endpoints for other services (ECR also needs the S3 gateway endpoint for layers) cost less than NAT only at volume.
• NAT gateways bill hourly plus per GB processed: a single shared NAT for cost-first environments, per-AZ NATs when availability is required. A regional NAT gateway is one ID that expands across AZs and is billed per active AZ plus per GB — simpler, not cheaper.
• A NAT instance is the cheap, self-managed option — built from a current AMI with IP forwarding on, the source/destination check off and the private route pointing at it; wrong whenever managed or highly available is stated.
• CloudFront cuts egress for cacheable content (edge caching, free origin fetch); Global Accelerator is a performance product with a per-GB premium, right for non-cacheable TCP/UDP traffic that needs static IPs or consistent latency.
• VPN is low fixed cost and quick to deploy; standard tunnels carry about 1.25 Gbps, Large Bandwidth Tunnels up to 5 Gbps, and ECMP across BGP VPNs scales further — both levers need a transit gateway. Direct Connect has fixed port costs, a lower per-GB rate at steady volume and weeks of lead time.
• VPC peering has no hourly or processing fees — cheapest for a few stable VPCs; Transit Gateway's per-attachment and per-GB fees buy transitive routing and manageability at scale; PrivateLink exposes one service to many VPCs.
• Throttle where it is cheapest: usage plans for per-client limits (best effort, not a hard cost cap), WAF rate-based rules per IP at the edge, CloudFront caching for repeats. Review existing workloads with Cost Explorer usage types, activated cost allocation tags and VPC Flow Logs before changing anything.