01 Compute & scalingEC2 · ASG · ECS · EKS · Lambda · API GW · Beanstalk · Outposts

• Mixed On-Demand + SpotOnly a launch template can provision across multiple instance types mixing purchase options. Trap launch configuration cannot; launch configs are also immutable — create a new one to change.
• ASG default termination policyOrder: 1) rebalance across AZs, 2) oldest launch template/config, 3) closest to next billing hour. AZ-balance step comes before everything else.
• ASG can terminate SpotSpot instances in an ASG are replaced like any other. Trap "ASG cannot terminate a Spot instance" — it can.
• ASG scaling policy — CPUTarget tracking for a steady CPU target. Step scaling for stepped response; scheduled action for predictable monthly/weekly peaks.
• ASG scaling on queue backlogTarget tracking on custom backlog-per-instance metric — AWS-prescribed for queue depth. Alternative: scale EC2 workers directly on ApproximateNumberOfMessagesVisible.
• Patching an ASG instancePut it in Standby, or suspend ReplaceUnhealthy, so ASG doesn't kill it mid-patch.
• ALB deregistration delayDrains in-flight requests during scale-in (ALB deregistration delay is the connection-draining knob, not ASG cooldown).
• Cross-zone LBALB: on by default, free. NLB: off by default, paid inter-AZ traffic. Turning off cross-zone = potential imbalance but cheaper.
• Why an ASG won't terminate an unhealthy instanceReasons: cooldown, standby, protected-from-scale-in, or health-check-grace-period not elapsed. ASG can terminate Spot.
• EC2 auto-recovery (CloudWatch)Applies only to an impaired running instance. Cannot recover a terminated one. Recovered instance keeps its public IPv4.
• EC2 HibernateSaves RAM to root EBS → restores in-memory state on start. Trap a golden AMI cannot preserve warm state.
• Golden AMI + user dataBake dependencies into an AMI to cut boot time. User data runs only on first boot, as root.
• EC2 tenancy precedenceVPC tenancy=dedicated overrides launch template tenancy. Every instance in the VPC becomes dedicated regardless.
• Dedicated Instances vs Dedicated HostsBoth single-tenant. Dedicated Instances = cheaper single-tenant. Dedicated Hosts only when you need socket visibility or BYOL (server-bound licences).
• Cluster placement groupLow-latency 10 Gbps networking in one AZ, for HPC/tight-coupled workloads.
• Spread placement groupDifferent underlying hardware, capped at 7 instances per AZ.
• Partition placement groupDistributed workloads (HDFS, Cassandra) — up to 7 partitions/AZ, isolated fault domains.
• Instance store vs EBSInstance store: ephemeral high random IOPS, lost on stop/terminate — use with app-level replication (e.g. NVMe scratch, HDFS). io2 Block Express: persistent high IOPS.
• Instance profile countExactly one instance profile per EC2 instance. Cannot attach a second role — combine permissions into one role. Basis for SSM Default Host Management Configuration.
• AZ IDs across accountsYour us-east-1a and mine may map to different physical AZs. Use AZ ID (e.g. use1-az1) to align across accounts.
• EIP + EBS billed while stoppedStopped EC2 still bills for attached EBS volumes and any unassociated Elastic IPs. Compute clock stops; storage does not.
• Root volume DeleteOnTerminationTrue by default for root, false for additional volumes. Change per volume in the block-device mapping.
• Spot FleetPersistent request keeps target capacity across interruptions. Fault-tolerant/batch use cases. Complements RIs for baseline + On-Demand for burst.
• RI baseline + Spot burstSteady load → RIs (or Compute Savings Plans). Variable/interruptible remainder → Spot. Don't leave burst on On-Demand.
• Compute Savings Plans vs RIsCompute SP is flexible across instance type, family, Region, OS, tenancy. RIs lock to one type in one Region → wrong when stem mentions multiple types/Regions.
• RIs don't fix over-provisioningUnder highly variable demand, RIs reduce the rate but not the count. Use ASG target tracking for the actual waste.
• Right-sizing toolCost Explorer rightsizing + Compute Optimizer recommendations.
• RunInstances "QUOTA EXCEEDED"A Service Quotas limit (vCPUs/family), not an ASG setting. Raise the quota.
• Lambda: memory is the CPU leverMemory scales CPU proportionally. Timeout is a ceiling, not a performance dial. Layers hold shared code and libs across functions.
• Lambda cost modelCost = GB-seconds × invocations. More memory can lower the bill when duration drops proportionally — right-size, cut I/O wait, don't over-provision blindly.
• Lambda + VPCRuns in a VPC via ENIs. Concurrency alarms sit on function-level metrics.
• Cross-account S3 from LambdaExecution role grants permissions and the bucket policy must grant to that role. Both required across accounts.
• SNS → Lambda quotaDelivery is subject to the account's Lambda concurrency quota — throttled invocations lost unless DLQ is set.
• Lambda + DynamoDB serverless splitStem asks for processing AND storage: Lambda processes, DynamoDB stores. Don't answer with two stores and no processor.
• Lambda vs Fargate for bursty microserviceSingle Python module, bursty traffic, minimal ops → Lambda + API Gateway. Don't reach for containers.
• Replace idle ASG with LambdaShort infrequent jobs → Lambda beats a barely-used ASG on both cost and simplicity.
• API Gateway HTTP API JWTNative OIDC JWT authorizer on HTTP APIs — no Lambda authorizer required.
• API Gateway REST vs WebSocketWebSocket for bidirectional persistent connections (chat, live feeds).
• API Gateway resource policyRestrict source IP CIDRs at the API level. Complements IAM and Cognito auth.
• API Gateway usage plans + API keysRate limiting per consumer. API keys are for tracking/throttling, not authorization.
• API Gateway spike absorptionFront with API Gateway; buffer with SQS or Kinesis; async processing behind.
• Cognito for API Gateway authCognito User Pool for built-in user management with sign-up/sign-in. Identity Pool is only for AWS-credential exchange, not auth.
• Zero-idle-cost computeFargate + Aurora Serverless is the only stack that drops to zero when idle. ALB+ASG+RDS keeps ≥1 instance and ≥1 DB running. Beanstalk always provisions ≥1 EC2 + ALB.
• Beanstalk mythsTrap no "deployment caching" feature exists. Boot-time reduction comes from a golden AMI, not a Beanstalk flag.
• Beanstalk + RDS + DMSFastest lift-and-shift for a desktop DB: DMS to RDS Multi-AZ, app on Beanstalk.
• ECS launch typesFargate = serverless, pay per task vCPU/memory. EC2 launch type = you manage the container-instance fleet.
• ECS on Fargate + EFSPersistent shared storage across tasks — mount EFS in the task definition.
• ECS task role vs instance roleLeast privilege = task role (per-container). Instance role is a broader fallback used by the container agent.
• ECS + SQS-driven scalingScalable container processing past Lambda's 15-min limit → Fargate + SQS.
• EventBridge SchedulerCron replacement — invoke Lambda or run containers on a schedule.
• EKS IRSAIAM Roles for Service Accounts — assign IAM roles per K8s ServiceAccount, no node-wide credentials.
• Amazon MQManaged AMQP/MQTT/STOMP broker — pick over SQS when the app speaks those protocols (e.g. EKS Fargate with AMQP).
• Outposts + EKS AnywhereData residency: keep the K8s control plane on-prem, use AWS-managed hardware.

02 S3core · classes · lifecycle · security · edge

• Transfer Acceleration scopeClient uploads over the internet only; bills only when it actually accelerates. Trap NOT a bucket-to-bucket copy mechanism. Inbound transfer to S3 is free.
• TA + multipart uploadCombine for large global uploads. Multipart parallelises; TA edges the upload through CloudFront POPs.
• Cross-Region bulk copyOne-time job → s3 sync or S3 Batch Replication. Ongoing → CRR. TA does not copy bucket-to-bucket.
• Strong read-after-writeS3 is strongly consistent for read-after-write and read-after-overwrite/delete. No stale reads.
• Request-rate scalingPer prefix: 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD per second. Split hot workloads across key prefixes.
• Bucket policy vs IAM policyBucket policy grants account- AND user-level access, including cross-account. IAM policy only reaches principals inside your own account.
• Bucket policy needs PrincipalResource-based policies must include a Principal element. IAM identity policies don't.
• Access PointsPer-prefix / per-application access with its own policy. Simpler than a monster bucket policy.
• Object-level ARN for DeleteObjects3:DeleteObject requires the object-level ARN (arn:.../bucket/*), not the bucket ARN.
• Versioning + MFA DeleteGuards against accidental delete. MFA Delete blocks permanent version deletion without a token.
• Object LockRetention applies per object version. Compliance mode: cannot be shortened or removed, even by root — combine with Organization CloudTrail for audit.
• Object ownership after cross-account writeDefault: uploader keeps ownership. Force bucket-owner via Object Ownership: bucket-owner-enforced (disables ACLs).
• One Zone-IAOK when data is re-creatable. Enforces 30-day minimum + 128 KB minimum + retrieval fees → wrong for <30-day transient staging.
• Standard-IAKnown infrequent access (30-day min, retrieval fee). Cheaper than Standard when access is known-infrequent.
• Intelligent-TieringAutomatic tiering when access pattern is unknown or changing. Per-object monitoring fee. Trap waste when pattern is already stated ("twice a year") → use Standard-IA.
• Glacier Instant RetrievalArchive class with millisecond retrieval. For long retention with occasional 2-hour access target.
• Glacier Deep ArchiveCheapest, 12-hour retrieval. Use with Snowball ingest + lifecycle transition for cold archives.
• Standard for transient stagingIntermediate query results deleted in days → Standard is cheaper than IA once you factor min-duration + retrieval fees.
• Lifecycle transitions are directionalStandard-IA → Intelligent-Tiering is valid. Intelligent-Tiering → Standard is invalid. Check the arrow direction.
• Common lifecycleStandard → Standard-IA (30d) → Glacier Instant Retrieval / Flexible → Deep Archive.
• SSE-S3AWS-managed keys, unique data key per object. Trap "encryption context" is KMS AAD, not S3 key derivation.
• SSE-KMSCustomer-controlled key permissions with AWS-rotated CMK. Enables audit via CloudTrail, disable/re-enable. Yearly automatic rotation is logged.
• SSE-CCustomer supplies the key on every request. Use when the key must stay on-prem.
• S3 replication of SSE-KMSRequires KMS keys in both source and destination Regions plus kms:Decrypt and kms:Encrypt permissions on the replication role.
• Share encrypted snapshot / KMS grantSharing an encrypted RDS snapshot cross-account requires sharing the KMS key too (grant to target account).
• S3 Event NotificationsTrigger Lambda / SQS / SNS / EventBridge on object create/delete. Event-driven processing without polling.
• S3 events replace nightly batchS3 event → SQS → Lambda beats a nightly Spot batch on both latency and cost.
• S3 presigned URLsTime-limited signed URLs offload private file downloads from a web server.
• Static site + CloudFrontS3 static site fronted by CloudFront — cache assets, cut S3 request cost.
• CloudFront OACOrigin Access Control locks an S3 origin. Bucket policy must match — allow CloudFront service principal only.
• CloudFront OAI + WAFLegacy pattern: OAI for S3 restriction + WAF IP match on the distribution.
• Security LakeCentralises security logs from AWS + partners into an S3 data lake in OCSF format.
• Redshift UNLOAD cross-accountBucket owner needs full control on the objects — set Object Ownership or use ACL=bucket-owner-full-control.
• S3 vs EFS vs EBS costS3 Standard is the cheapest per GB. EFS mid. EBS billed provisioned regardless of use.
• S3 for HA doc storeCross-AZ shared storage: S3 Standard beats EBS snapshots/RAID for availability and simplicity.
• NFS re-platformStore files on S3 Standard-IA, metadata/search index in DynamoDB. Cheaper than EFS + RDS.
• S3 as static outage backupRoute 53 failover routing to an S3 website endpoint keeps a landing page up during outages.
• Snowball for bulk ingestSnowball/Snowball Edge for petabyte-scale offline transfer to S3 → lifecycle to Glacier Deep Archive.
• Transfer Family SFTPManaged SFTP/FTPS/FTP into S3 with per-vendor IAM roles + event-driven processing on new keys.

03 EBSvolume types · encryption · ModifyVolume

• ModifyVolume constraintCan expand only, cannot shrink. Trap "reduce the size of the underutilized volumes" is not an operation.
• io2 → gp3, no downtimeVolume-type change is the live cost lever on the same ModifyVolume API.
• gp3 baseline IOPS3,000 IOPS included free regardless of size. For a fixed 1,000 IOPS requirement, 50 GiB gp3 beats Provisioned IOPS on cost.
• io1 / io2Provisioned IOPS SSD for consistent high random IOPS. io2 Block Express: highest IOPS/GB, sub-ms latency, up to 256K IOPS.
• HDD typesst1 — throughput-optimized (big data, logs). sc1 — cold, cheapest cold storage.
• EBS encryption scopeEncryption covers volume, in-transit between instance and volume, and snapshots. New volumes from encrypted snapshots stay encrypted.
• DeleteOnTermination defaultTrue for root volume, false for additional. Change per-volume in block-device mapping.
• Cross-Region AMI copyCopying an AMI also copies the backing EBS snapshot. Destination holds AMI + snapshot.
• Encrypted snapshot copySnapshot copy is where you can change encryption state — enable encryption on the copy operation.
• Multi-Attach limitsio1/io2 Multi-Attach limited to 16 Nitro instances in the same AZ. For 10–50 instances shared R/W → use EFS.

04 EFS · FSx · Storage Gateway · DataSyncshared file storage & hybrid

• EFS access controlMount-target traffic controlled by security groups, not NACLs. Plus IAM policy for API actions.
• EFS cross-RegionReachable from another Region across inter-Region VPC peering. No copy to S3 needed.
• EFS cross-accountEFS file system policies grant cross-account mount access (paired with peering + SG).
• EFS mount targets per AZOne mount target per AZ for HA. Instance mounts the local AZ's target.
• EFS throughput modeBursting scales with stored size — a file system capped at 1 TB bursts low. Highest throughput on small FS → Provisioned Throughput.
• EFS performance modeGeneral Purpose default. Max I/O for very parallel/big data workloads that tolerate slightly higher per-op latency.
• EFS Standard-IAInfrequently accessed shared files. Lifecycle policy auto-tiers idle files after N days.
• EFS is NFSv4For fully-managed shared NFSv4 across EC2 — the default choice against FSx for Windows or File Gateway.
• FSx for Windows File ServerOnly choice for SMB + Windows ACLs and AD integration. Supports DFS namespaces / DFSR replacement.
• FSx for LustreHPC hot data with S3 backing. Sub-ms latency, GB/s throughput. Use for parallel workloads over S3 data.
• FSx for ONTAPMulti-protocol SMB and NFS, snapshots, dedup, tiering. Enterprise NetApp features on AWS.
• FSx or File Gateway for Windows-compatible cloudBoth viable. FSx is native SMB. File Gateway keeps a local SMB share backed by S3.
• Storage Gateway — File GatewayKeeps NFS/SMB share on-premises backed by S3 with a local cache. Right when workload must keep its local file interface.
• Storage Gateway — Volume CachedPrimary copy in S3, frequently-accessed cached locally. Fits "only recent logs held locally".
• Storage Gateway — Volume StoredPrimary copy on-premises, snapshotted to S3.
• Storage Gateway — Tape GatewayPresents an iSCSI VTL to backup software, backed by S3 Glacier.
• DataSyncOnline transfer to S3, EFS, or FSx. Run over Direct Connect for high-throughput one-time NFS migration.
• Migrate NFS in vs keep on-premEFS + DataSync moves data into AWS. File Gateway leaves it on-prem, backed by S3.

05 RDS & AuroraHA · replicas · encryption · storage · Serverless

• Encrypt an existing RDSSnapshot → copy snapshot with encryption enabled → restore from encrypted copy. Cannot encrypt a live instance, a standby, or via replica — state doesn't change across replica/standby.
• Encrypt future backupsSame route — new encrypted instance restored from encrypted snapshot copy. Future backups inherit encryption.
• RDS Multi-AZSynchronous replication to standby in another AZ. Automatic failover. Standby not readable.
• Multi-AZ engine upgradeApplied to primary and standby simultaneously → both go down. Multi-AZ does not spare the outage.
• Multi-AZ vs read replicaMulti-AZ = HA (sync, failover). Read replica = read scaling (async, promotable).
• Read replica for reportingIsolate long-running reporting queries from the writer with a read replica.
• Cross-Region read replicaCross-Region DR when the engine must not change. Data-transfer charges apply.
• RDS storage auto-scalingNative checkbox on RDS MySQL/PostgreSQL/MariaDB. Trap don't migrate to Aurora just to get it.
• RDS ProxyPools connections — fixes connection exhaustion. Trap API Gateway throttling slows requests but pools nothing.
• Isolate RDS from internetPrivate subnets + DB subnet group + SG that references the app-tier SG only.
• RDS SSL/TLSData in transit via SSL. Download the RDS root cert and set rds.force_ssl or engine equivalent.
• RDS CustomOracle/SQL Server with OS access, custom scripts and installs, while keeping managed Multi-AZ and backups.
• Secrets Manager RDS rotationNative scheduled rotation for RDS credentials — no custom Lambda.
• Aurora Global Database — readsLow-latency regional reads globally, one primary Region for writes.
• Aurora Global Database — writesWrite forwarding still routes writes to the single primary Region. Active-passive with a convenience.
• Aurora Global DR RPO/RTO≈ 1 s RPO, ≈ 1 min RTO. Choose for tight Multi-Region relational DR.
• Cross-Region replica when engine must stayRDS cross-Region read replica + manual promotion. Aurora Global changes engine — excluded if "no engine change".
• Aurora ReplicasSub-second replica lag. Reader endpoint load-balances. Aurora Auto Scaling adds/removes replicas on CPU/connections.
• Aurora MySQL Multi-AZ replicasMulti-AZ replicas for read scaling; failover targets are the replicas themselves.
• Aurora ServerlessOLTP with idle periods where compute cost must drop to zero. v2 scales per second.
• Babelfish scopeHandles the T-SQL surface on Aurora PostgreSQL. Schema and data still need SCT + DMS.
• Which tier actually needs HAS3, DynamoDB are already HA — the single-instance RDS is the point of failure. Move to Multi-AZ.

06 DynamoDB · DocumentDB · ElastiCache · Neptunekey-value · document · cache · graph

• DynamoDB Global TablesTrue active-active writes across Regions. Choose over Aurora Global when both Regions must serve writes.
• DynamoDB on-demand modeFlash-sale spikes → on-demand capacity mode. Trap don't insert an SQS queue between callers and DDB.
• DAXMicrosecond in-memory cache in front of DDB. Least-overhead read-latency cut and hot-item throttling fix — beats bolt-on ElastiCache or more RCUs.
• DynamoDB PITRPoint-in-time recovery to any second in the last 35 days. Correct answer to accidental corruption.
• DynamoDB TTL + GSIGSI for multiple search keys; TTL for automatic expiry (telemetry with 1-month lifetime, package tracking).
• DynamoDB VPC endpointGateway endpoint (S3 & DynamoDB only). Keeps DDB traffic off the public network.
• DynamoDB for stateless ASGExternalise HTTP session state to DDB to make ASG members stateless.
• DynamoDB geohash GSIHigh-volume telemetry / geo queries: geohash partition key on a GSI.
• DynamoDB for unstructured profileSchemaless key-value/document store, scales to millions of items. Not relational or graph.
• DocumentDB IAM scopeIAM governs AWS-level actions (create/modify cluster). DocumentDB has no IAM database authentication — DB connection uses username/password.
• ElastiCache HIPAAElastiCache (Redis/Memcached) is HIPAA-eligible for in-memory caching of PHI.
• ElastiCache offloads RDS readsRead-heavy patterns → cache read-through/lazy-load.
• Redis or DAX for leaderboardsSorted-set operations → Redis. Purely DDB backend → DAX.
• Cache-aside vs write-throughCache-aside (lazy loading) for aggregations that depend on all writes — TTL controls staleness. Write-through for "never serve stale" per-key values.
• NeptuneManaged graph DB for relationship/traversal queries (Gremlin/openCypher/SPARQL).

07 VPC internalsendpoints · SGs · NACLs · NAT · sharing

• Gateway VPC endpointsExist only for S3 and DynamoDB. Free. Attach to route tables. Removes NAT data charges for that traffic.
• Interface VPC endpoint (PrivateLink)ENI-backed endpoint for most other AWS services (SQS, SSM, Secrets Manager, ...). Billed per hour + per GB.
• VPC endpoint policyRestrict which resources/actions the endpoint permits — e.g. prevent S3 exfiltration to buckets outside your account.
• Private connectivity to in-Region servicesVPC endpoint, not NAT/IGW. Traffic stays on the AWS network.
• Security groups are statefulReturn traffic implicitly allowed. Reference other SG IDs for tier isolation.
• NACLs are statelessRules evaluated in order; return traffic needs its own rule. Subnet-level.
• SG allowed sourcesSG rules accept: CIDR, another SG ID, or a prefix list. Not usernames.
• SG chaining across tiersALB SG → web SG → app SG → DB SG. Each rule references the previous tier's SG ID, not a CIDR — least privilege that survives autoscaling.
• Bastion SGBastion SG admits only the corporate CIDR. Private web servers admit SSH only from bastion SG.
• NAT gateway HAOne NAT gateway per AZ with per-AZ route tables. AZ-independent egress; a single NAT gateway in one AZ is a single point of failure and cross-AZ data charge.
• NAT gateway for private-subnet patchingPlace NAT gateway in a public subnet; private subnets route 0.0.0.0/0 to it.
• NAT instance vs NAT gatewayNAT instance can serve as bastion / port-forward and can be modified. NAT gateway is managed, HA, higher bandwidth. Prefer NAT gateway unless port-forwarding is required.
• S3 gateway endpoint saves NAT $S3 traffic through the gateway endpoint bypasses NAT data-processing charges entirely.
• Default route targetTarget for 0.0.0.0/0 is the internet gateway (or NAT/TGW/VGW). Not the subnet the route table is attached to.
• Peering — CIDRsNon-overlapping CIDRs enforced at create time. After creation, the missing step is route table entries in both VPCs.
• Peering scaleOne peering = two VPCs. 10 VPCs → near-mesh; use Transit Gateway. Only TGW route tables can segment.
• VPC sharing (RAM)Shares one or more subnets, not a whole VPC. Cheaper than TGW — no attachment fee, no data processing.
• Private hosted zone prerequisitesVPC must have enableDnsHostnames AND enableDnsSupport on. Without both, PHZ does not resolve.
• Two-tier SG patternWeb SG: 80/443 from 0.0.0.0/0. DB SG: 3306 from web SG only.

08 Transit Gateway · PrivateLink · Direct Connect · VPN · Directory Service

• Shared services VPCBehind a Transit Gateway hub, not a full-mesh peering rebuild.
• 10-VPC connectivity + inspectionTransit Gateway + Network Firewall. Peering + firewall works for 2–3 VPCs but does not scale or segment.
• TGW over Direct ConnectTransit VIF + Direct Connect Gateway to reach a TGW from on-prem.
• Direct Connect basicsDedicated private link. Cuts data-egress cost vs internet. Not encrypted by default.
• Encrypted DXDirect Connect + Site-to-Site VPN over it = encrypted, low-latency private path.
• DX failover on a budgetSite-to-Site VPN as the backup, not a second DX link.
• DX max resilienceConnections at multiple DX locations, not multiple VIFs on one link. Different fibre paths.
• Site-to-Site VPN componentsVirtual Private Gateway (AWS side) + Customer Gateway (on-prem). IPsec tunnels between them.
• VPN throughput ceiling1.25 Gbps per connection. Exceed via ECMP over Transit Gateway with multiple VPN attachments.
• VPN CloudHubHub-and-spoke over VGW connecting multiple branch offices via IPsec.
• PrivateLink vs peeringPrivateLink exposes one service, one-way. Peering opens bidirectional access to the whole CIDR.
• PrivateLink for cross-account serviceProvider fronts a service with an NLB, publishes as a VPC endpoint service. Consumers get an interface endpoint. Scales to thousands of consumer accounts.
• PrivateLink from private subnetInterface endpoint → hits the service without NAT/IGW.
• Managed Microsoft AD vs AD ConnectorManaged Microsoft AD is a real directory in the VPC. AD Connector is only a proxy — no directory in AWS.
• Separate DC from public webUse Managed Microsoft AD (or dedicated DC EC2) inside a private subnet; AD Connector cannot serve as the directory itself.
• AD Connector + IAM Identity CenterFederate AWS console access to on-prem AD without a directory copy in AWS.

09 Edge · DNS · Global Accelerator · Load BalancingCloudFront · Route 53 · ALB · NLB

• Blue/green under DNS cachingMobile clients cache DNS aggressively → Global Accelerator traffic dial (anycast IPs, no DNS). Route 53 weighted routing is DNS-based and gets defeated by caches.
• Global Accelerator use casesNon-HTTP or UDP workloads; regional NLBs with fast failover; dynamic API traffic that CloudFront can't cache; static anycast IPs for allow-listing.
• GA vs CloudFrontGA for non-HTTP + non-cacheable dynamic + UDP. CloudFront for cacheable HTTP.
• GA vs S3TAUploads/downloads straight to S3 → S3 Transfer Acceleration. GA fronts compute endpoints, not buckets.
• Route 53 alias at zone apexDNS forbids CNAME at the zone apex → Route 53 alias record. For a subdomain pointing at an external hostname → CNAME (PTR is reverse DNS).
• Route 53 failoverPrimary + secondary records with health checks. Combine with S3 static or a warm standby in another Region.
• Route 53 geolocation vs CloudFront geo restrictionGeolocation routing serves different endpoints by user location. Geo restriction blocks countries at the CloudFront edge.
• Route 53 Resolver — outbound endpointForward DNS from VPC to on-prem resolvers.
• Route 53 Resolver — inbound endpointAllow on-prem clients to resolve private hosted zones in the VPC. Hybrid DNS = inbound + outbound.
• CloudFront custom originTakes the origin's own domain or IP. Trap pointing at a Route 53 record adds a hop and is not how it's configured.
• CloudFront cache keyForward Authorization header (or specific headers/cookies/query strings) into the cache key to differentiate per-user cache entries.
• CloudFront to cut S3 request costCache popular objects at edge — origin sees fewer GET requests.
• CloudFront for traffic spikeImmediate relief for a viral media spike: point CloudFront at the existing site as origin, cache assets.
• Cognito on the edgeALB has native Cognito User Pool auth. CloudFront does not — would need Lambda@Edge.
• Geo blocking placementCloudFront geo restriction only when CF is in the path. Bare ALB → WAF geo-match rule on the ALB.
• ACM certs on EC2ACM public certs cannot be installed on EC2 — only on ELB, CloudFront, API Gateway. For end-to-end TLS with EC2 as termination, use a self-managed cert.
• Cross-AZ transfer costCross-AZ data transfer costs money. AZ-affinity routing keeps flows local.
• ALB — content-based routingPath, host, header, query-string, method — routes at L7 to target groups across AZs.
• ALB health checksTwo things fail: bad health-check path/port or SG blocking the ALB.
• NLB targetsNLB routes to the target's primary private IP of the primary ENI. Preserves source IP.
• ALB deregistration delayDrains long-lived connections during scale-in / deploy — set the seconds to your longest request.

10 IAM & SCProles · policies · Organizations · STS

• IAM instance profileEC2 assumes a role via instance profile — never store long-lived AWS credentials on an instance.
• Cross-account accessTrust policy in target account allows source account principals to assume a role there. sts:AssumeRole in source. Cross-account audit role lives in the audited account.
• Permissions boundaryAttaches to a user or role only. IAM groups cannot carry one. Caps what the identity can be granted.
• SCP exemptionsDoes not affect service-linked roles (SLRs are exempt on purpose). Does not restrict the management account root.
• SCP for preventionOnly an SCP prevents a call like RunInstances. Budget actions fire at ~80% spend with up to 24 h lag — reactive.
• SCP disable CloudTrailDeny cloudtrail:StopLogging / DeleteTrail at OU level for developer accounts.
• aws:SourceIp meaningThe caller's IP — where the API request originates. Not the instance's own public IP.
• ec2:Region conditionRestrict actions to specific Regions via IAM condition. Combine with aws:SourceIp for defence in depth.
• Object-level ARN for DeleteObjectResource-level actions need object-level ARN (bucket/*). Bucket ARN alone is insufficient.
• Least-privilege Lambda roleScope Action to only the API calls used + Resource to the specific ARN — not *.
• Bucket policy needs PrincipalResource-based policies require a Principal element. IAM identity policies don't.
• Cross-account S3 access"User-level AS WELL AS account-level" → bucket policy. IAM in your account cannot grant to external principals.
• Read-only bucket + objectsGrant both bucket-level (ListBucket) and object-level (GetObject) — different ARNs.
• Root user securityStrong password + hardware MFA + no access keys. CloudTrail on. MFA for all privileged users.
• EKS IRSAIAM Roles for Service Accounts — pod-level IAM, no node-wide creds.
• ECS task roleTask role is the least-privilege boundary for containers (not the container-instance role).
• IAM Identity CenterFederated SSO for AWS accounts + business apps. Replaces AWS SSO branding.
• Instance profile for DynamoDBEC2 accesses DDB via role → instance profile. Never embed credentials in AMIs or user data.

11 KMS · Shield · WAF · Cognito · Macie · Config · GuardDuty · SSM

• KMS automatic rotationYearly automatic rotation on CMKs is logged in CloudTrail. Satisfies "must be rotated every year" without a manual process.
• KMS CMK controlsCustomer-managed key → rotation, audit, disable/re-enable, key policy for cross-account grants.
• Encryption contextAdditional authenticated data on KMS calls. It does not derive per-object keys, and is not a per-object secret.
• KMS AccessDenied on DynamoDBDDB uses a KMS CMK — key policy must grant DDB's caller. Trap DDB table resource policies were added later; check current docs before assuming they don't exist.
• SSE-KMS on S3Customer controls key permissions; AWS rotates the CMK. Right choice when compliance requires customer-controlled access with AWS-managed rotation.
• Shield Standard vs AdvancedStandard is free (L3/L4 always on). Advanced adds L7 protection, cost protection, and the DDoS Response Team.
• Shield Advanced billingTrap no Savings Plan for Shield Advanced. Subscription fee charged once per Organization under consolidated billing.
• DDoS layer coverageL3/L4 volumetric → Shield Advanced on CloudFront/GA/ELB. L7 → WAF.
• WAF capabilitiesIP sets, rate limiting, geo match, managed rules (SQLi, XSS, OWASP). Deploy on CloudFront, ALB, API Gateway.
• Cognito on API GatewayCognito User Pool with built-in user management + MFA for mobile apps.
• Macie scopeDiscovers sensitive data in Amazon S3 only. Does not scan RDS. Reports findings — does not mask or replace.
• De-identify RDS extractGlue DataBrew recipes mask/replace values. Macie only reports.
• GuardDuty data sourcesVPC Flow Logs, CloudTrail management + data events, Route 53 DNS logs. EKS, RDS, S3, malware protection add-ons.
• GuardDuty vs Macie vs InspectorGuardDuty = threat detection. Macie = S3 sensitive-data discovery. Inspector = EC2/ECR/Lambda vulnerability scanning.
• AWS ConfigResource configuration history + compliance. Managed rules include ACM cert expiry. Off-the-shelf, no scripting.
• Config conformance packsDeploy a bundle of Config rules + remediation across an Organization for org-wide governance.
• SSM Parameter Store secure stringsCheap secure config + KMS + CloudTrail audit. Fits API-key storage for Lambda.
• SSM Default Host Management ConfigurationTurn on org-wide; grants the SSM role. Recall: one instance profile per EC2 — cannot add a second.
• CloudFormation StackSetsDeploy stacks across accounts and Regions from a central account.
• CloudFormation + weighted routingImmutable deployments: stand up a parallel stack, shift traffic gradually with Route 53 weighted records.

12 SQS · SNS · Step Functions · Amazon MQ · EventBridge

• Standard → FIFO migrationCannot convert. Delete and recreate with .fifo suffix.
• FIFO throughput300 msg/s unbatched; up to 3,000 msg/s with batching (10 messages/batch × 300). High-throughput mode goes higher per partition.
• FIFO message group IDOrdering is per MessageGroupId — same group = strict order; different groups process in parallel.
• FIFO + DLQ + connection poolExactly-once + ordered + DLQ protects a downstream connection pool from poison messages.
• SQS "priority"No priority attribute — FIFO included. Express priority structurally: one queue per class, consumer polls higher-priority first.
• SQS long pollingWaitTimeSeconds up to 20 s. Cuts empty ReceiveMessage costs and idle Lambda invocations.
• SQS DLQRedrive policy after N receive attempts. Isolates poison messages for inspection.
• SQS decouple fast/slowBuffer between fast producer and slow consumer — producer never blocks.
• Long-running workFree load balancer from long-running report generation → async via SQS + workers.
• Scale workers on queue depthASG on ApproximateNumberOfMessagesVisible or backlog-per-instance target tracking.
• Kinesis vs SQS for orderingPer-user ordering across multiple consumers with replay → Kinesis Data Streams. SQS FIFO orders per group but consumes off the queue.
• SNS fan-outOne publish → multiple SQS queues / Lambda / HTTPS subscribers.
• SNS → Lambda concurrencyDelivery limited by account Lambda concurrency quota. Configure DLQ on the subscription.
• Step Functions orchestrationNative per-state Retry (exponential backoff) + Catch handle flaky APIs. Don't replace with SQS.
• Amazon MQManaged AMQP/MQTT/STOMP broker (RabbitMQ, ActiveMQ). Pick when the app speaks those protocols.
• EventBridge SchedulerCron replacement. Invoke Lambda or run containers on schedule; integrates with hundreds of targets.
• Connection bufferingSQS in front of RDS absorbs bursts; pair with RDS Proxy for the connection side.

13 Kinesis · Athena · Glue · Redshift · ML services

• Kinesis Data StreamsCustom real-time processing with retention (default 24 h, up to 365 days). Order preserved per partition key. Replay-capable.
• Enhanced fan-outDedicated 2 MB/s per consumer via HTTP/2 push. Use when many consumers each need low latency.
• Kinesis Data FirehoseManaged near-real-time delivery to S3, Redshift, OpenSearch, Splunk. Handles buffering, compression, format conversion.
• Real-time API feedKinesis Data Analytics on the stream serves real-time. Athena on S3 is batch — one storage hop too slow.
• Fastest access to fresh eventsQuery the stream in flight (KDA) — don't wait for Firehose → S3 → Athena.
• DMS as S3 → Kinesis bridgeDMS supports the pair natively. Trap don't wire EventBridge + Lambda.
• AthenaServerless SQL over S3. Pay per TB scanned. Right choice for infrequent SQL over a data lake with zero infra.
• Athena on huge lakesColumnar (Parquet/ORC) + partition on filtered columns. Oversized single objects hurt parallelism as much as tiny ones.
• Redshift SpectrumQuery historical data in S3 directly from Redshift — no load.
• GlueServerless Spark ETL + Data Catalog. Compression + partitioning for cost.
• Glue DataBrewVisual data prep + recipes. Masking, cleaning, de-identifying — no code.
• CloudWatch metric filterMetric filter over the CloudTrail log group + alarm — native. Don't stream to Kinesis to derive metrics.
• NeptuneGraph relationships — fraud, knowledge graphs, recommendations. Not for tabular queries.
• Textract + ComprehendTextract extracts text from PDFs/scans; Comprehend does entity/sentiment/language.
• Polly with lexiconsText-to-speech with custom pronunciations via lexicons (Textract is the wrong service).

14 Migration & data transfer

• SCT + DMSSCT converts schema (heterogeneous — commercial → open-source). DMS moves data. Both needed on select-TWO for heterogeneous migrations.
• DMS continuous replicationFull load + CDC to keep target in sync. Sources include RDS/EC2 DBs; targets include Redshift, RDS, DynamoDB, Kinesis, S3.
• DMS with Beanstalk lift-and-shiftDesktop DB → RDS Multi-AZ via DMS; app on Elastic Beanstalk for minimal cutover.
• Snowball / Snowball EdgePetabyte-scale offline transfer to S3. Follow up with lifecycle to Glacier Deep Archive.
• DataSyncOnline transfer to S3/EFS/FSx. Over Direct Connect for high-throughput NFS.
• Transfer FamilyManaged SFTP/FTPS/FTP endpoint into S3 with per-vendor IAM roles.
• Cross-Region AMI copyCopying an AMI to another Region also copies the backing snapshot — destination holds AMI + snapshot.

15 Cost & managementOrganizations · pricing · governance

• Compute Savings Plans vs RIsCompute SP is flexible across instance type, family, Region, OS, tenancy. RIs lock to one type in one Region.
• RIs vs target trackingRIs reduce rate, not count. Variable demand → target-tracking policy.
• Spot for interruptibleFault-tolerant / batch / bursty work. Spot Fleet with persistent request keeps target capacity.
• Aurora Serverless for infrequent DBDev DB used minutes a week → Aurora Serverless (or stop/start scheduling). RIs need continuous use.
• Cost attributionCost Categories (split-charge) + Tag Policies. CloudTrail is an audit log, not cost attribution.
• Right-size by $ impactEC2 right-size + off-hours schedule dwarfs freeing two idle EIPs (~$393/mo vs ~$7/mo). Biggest lever wins.
• Cost Explorer + Compute OptimizerCost Explorer for rightsizing recommendations; Compute Optimizer for per-instance-type suggestions.
• ACM cert expiry monitoringAWS Config managed rule for imported ACM cert expiry — off-the-shelf, zero scripting.
• Cost Anomaly DetectionML-based anomaly alerts. Pairs with SCP prevention for spend guardrails.
• Budget alerts vs SCPsBudgets alert (reactive, up to 24 h lag). SCP prevents the call.
• Data-transfer cost cutterDirect Connect cuts internet-egress cost for high-volume data warehouse traffic.
• Well-Architected ToolFramework review across 6 pillars. Use to structure the org's Config/Trusted Advisor findings.

16 Disaster recovery

• DR ladder RTOsBackup & Restore: hours. Pilot Light: 20–45 min (provisions from scratch, DB replicated). Warm Standby: minutes (scaled-down running copy). Multi-Site Active/Active: seconds.
• "15-minute RTO + lowest cost"Warm Standby — Pilot Light fails the RTO. Check RTO before picking the cheapest rung.
• "30-minute RTO on a budget"Pilot Light — meets RTO and beats Warm Standby on cost.
• Pilot Light identifierMinimal core (DB replicated, AMIs ready) with everything else off. Scaled up on failover.
• Multi-Region relational DR (tight)Aurora Global Database — ≈1s RPO, ≈1min RTO.
• Cross-Region same-engine DRRDS cross-Region read replica + manual promotion (Aurora Global would change engine).
• Static outage pageRoute 53 failover to S3 static website — cheapest keep-the-lights-on option.
• Which tier needs HAS3, DynamoDB, Lambda are already HA. Single-instance RDS is the point of failure.