SAP-C02 Cheat Sheet

Transit Gateway (TGW) is a regional Layer 3 hub-and-spoke router: each VPC, VPN, or Direct Connect gateway attaches once, and the hub routes between them, collapsing a full peering mesh into one attachment per VPC. It's the default answer for connecting dozens of VPCs and accounts plus on-premises in a single Region; reach for it instead of peering once the pairwise-mesh count becomes unmanageable. Per-Region scope is the catch: inter-Region reach needs TGW-to-TGW peering or Cloud WAN.

Trap Assuming a single Transit Gateway routes between VPCs in different Regions on its own, when a TGW is regional and inter-Region reach needs TGW peering or Cloud WAN.

Transit Gateway isolation lives in its route tables: give each environment its own TGW route table, then control which attachments associate to it and which propagate routes into it, analogous to VRFs. Default quotas bound the design: 20 route tables per TGW, 10,000 total routes across all of them, and 5,000 attachments per TGW.

Trap Assuming an attachment can sit in two route tables for selective isolation: each attachment associates to exactly one TGW route table; segmentation comes from propagation, not multi-association.

A Transit Gateway VPC attachment delivers up to 100 Gbps each direction per Availability Zone (and up to 7,500,000 packets/sec per AZ), so spreading an attachment's subnets across more AZs is how you scale aggregate throughput. A single TGW Connect (GRE) peer is capped at up to 5 Gbps; a Connect attachment holds up to 4 peers for up to 20 Gbps total, scaled with ECMP across the peers.

Trap Concentrating an attachment's subnets in one AZ and expecting more bandwidth, when the 100 Gbps cap is per-AZ so scaling throughput means spreading subnets across additional AZs.

Transit Gateways peer to other TGWs across Regions (and to a Cloud WAN core network edge) to form a multi-Region network, and TGW natively supports multicast, neither of which VPC peering offers. The cost: inter-Region TGW peering attachments are static-routing only and must be hand-built with route tables synchronized per Region, which is exactly the toil Cloud WAN automates.

Trap Expecting dynamic BGP route propagation across an inter-Region TGW peering attachment, when those attachments are static-routing only and need per-Region route tables synchronized by hand.

A Transit Gateway is shared to other accounts with AWS Resource Access Manager (RAM); the receiving account then creates its own VPC attachment to the central hub. This is the mechanism behind centralized-egress and shared-services hubs in a multi-account landing zone: one team owns the TGW, every spoke account attaches into it.

AWS Cloud WAN builds a managed global network from a single core network policy document: a declarative JSON that defines Regions, segments, and how attachments map to segments; AWS then provisions a core network edge (a TGW-like router) per Region and full-meshes them automatically. Choose it over self-managed multi-Region TGW peering when you want central policy, tag-based attachment-to-segment mapping, and one dashboard instead of synchronizing route tables by hand.

A Cloud WAN segment is a dedicated routing domain (AWS likens it to a globally consistent VRF or L3 IP VPN): by default only attachments in the same segment communicate, and AWS keeps that isolation consistent across every Region without you hand-synchronizing per-Region TGW route tables. You can peer an existing Transit Gateway into a Cloud WAN segment for incremental migration rather than a forklift cutover.

Trap Assuming attachments in different Cloud WAN segments can talk by default, when segments are isolated and cross-segment routing requires an explicit sharing action in the core network policy.

Direct Connect carries traffic over a VIF, and the type picks the destination: a private VIF reaches a VPC by private IP (or, via a Direct Connect gateway, virtual private gateways across accounts and Regions); a public VIF reaches all AWS public service endpoints by public IP; a transit VIF reaches Transit Gateways through a DX gateway. Pick the transit VIF when DX must feed a TGW hub rather than a single VPC.

Trap Using a public VIF to reach a private VPC subnet: a public VIF only advertises AWS public-service prefixes; private-IP VPC access needs a private or transit VIF.

Direct Connect is a private dedicated link but provides no encryption on its own. MACsec (Layer 2 encryption) is available only on 10, 100, and 400 Gbps dedicated connections, not on 1 Gbps dedicated and not on hosted connections; for a sub-MACsec or hosted link, run an IPsec Site-to-Site VPN over a DX public VIF to encrypt traffic in transit.

Trap Treating a Direct Connect circuit as encrypted because it's private: privacy is path isolation, not confidentiality; an eavesdropper on the link sees cleartext without MACsec or an overlay VPN.

A single DX circuit is one failure domain, so a resilient hybrid design backs DX with a Site-to-Site VPN (accelerated or ECMP) or a second DX at a different location. ECMP, which aggregates multiple tunnels for bandwidth and failover, requires the VPN to use dynamic (BGP) routing; it is not supported on static-route VPNs.

Trap Expecting ECMP aggregation across VPN tunnels with static routing, when ECMP needs dynamic BGP routing and is unsupported on static-route VPNs.

Direct Connect dedicated ports come in 1, 10, 100, and 400 Gbps; partner-provided hosted connections range from 50 Mbps to 25 Gbps. Reach for a hosted connection when you need a sub-1 Gbps committed link, since the smallest dedicated port is 1 Gbps and won't go lower.

Trap Ordering a dedicated port for a sub-1 Gbps link, when the smallest dedicated port is 1 Gbps and only a partner hosted connection goes below that.

Direct Connect SiteLink connects two DX points of presence directly over the AWS global backbone so site-to-site traffic takes the shortest path without hairpinning through an AWS Region. It's supported on transit VIFs and on private VIFs attached to a Direct Connect gateway, but not on a private VIF attached directly to a virtual private gateway, nor on public VIFs; a separate per-hour and data fee applies, and it isn't offered in GovCloud (US) or China Regions.

Trap Expecting SiteLink to work on a private VIF attached directly to a virtual private gateway, when it requires a Direct Connect gateway (or a transit VIF) and is unsupported on a VGW-attached private VIF or a public VIF.

AWS PrivateLink publishes a single service through an interface VPC endpoint (an ENI with a private IP in the consumer's subnet) backed by a VPC endpoint service that the provider fronts with a Network Load Balancer. Connectivity is unidirectional consumer-to-provider (the consumer initiates); when both sides must initiate full IP connectivity, use VPC peering or a Transit Gateway instead.

Trap Reaching for PrivateLink when the provider also needs to initiate connections back to the consumer: the endpoint is one-way, so bidirectional flows need peering or a TGW.

PrivateLink exposes only a service endpoint, not whole networks, so the consumer and provider VPCs may have overlapping or identical CIDR blocks, exactly the case where TGW and VPC peering both refuse to route. It's the standard way to share a service privately when address-space overlap is unavoidable and re-IPing isn't an option.

Trap Reaching for Transit Gateway or VPC peering to connect VPCs with overlapping CIDRs, when both refuse to route overlapping address space and PrivateLink is the way to share a single service across the overlap.

Gateway VPC endpoints exist only for Amazon S3 and DynamoDB and add no charge: they're prefix-list route-table entries with no ENI. Every other service uses an interface endpoint (PrivateLink), billed per hour per AZ plus per GB processed. Use a gateway endpoint to reach S3/DynamoDB privately without routing the traffic through a NAT gateway and paying NAT data-processing fees.

Trap Putting an interface endpoint in front of S3 purely to save money: S3 and DynamoDB have a free gateway endpoint, so a billed interface endpoint is only warranted when you specifically need private-IP/on-prem reachability the gateway endpoint can't give.

Route 53 Resolver endpoints connect VPC and on-premises DNS in two directions: inbound endpoints let on-premises resolvers query records in the VPC (private hosted zones), while outbound endpoints, paired with forwarding (resolver) rules, send matching VPC DNS queries out to on-premises corporate DNS. Full bidirectional name resolution across the hybrid boundary needs both endpoint types.

Trap Assuming an inbound endpoint lets the VPC resolve on-prem names: direction matters: inbound serves queries coming INTO the VPC; resolving on-prem names FROM the VPC needs an outbound endpoint plus a forwarding rule.

Transit Gateway and VPC peering cannot route between VPCs whose CIDR blocks match or overlap, so non-overlapping addressing has to be planned before you scale out accounts. When overlap is already unavoidable, expose the workload via PrivateLink or front it with NAT rather than re-IPing live VPCs.

Trap Planning to fix overlapping VPC CIDRs later with Transit Gateway routing, when neither TGW nor peering routes overlapping address space and the workaround is PrivateLink or NAT, not the hub itself.

VPC peering is a strictly one-to-one, non-transitive relationship: if A peers B and A peers C, B still can't reach C through A. You must add a direct B-to-C peering, and the per-pair route entries that go with it. That non-transitivity is the core reason a Transit Gateway hub scales better once you pass a handful of VPCs.

Trap Treating a peered hub VPC as a transit point so spokes reach each other through it: peering never forwards transitively; each spoke pair needs its own connection (or a TGW).

The default quota is 50 active VPC peering connections per VPC, adjustable up to a hard maximum of 125. Because each new VPC must peer with every existing one, the pairwise count grows quadratically and hits this ceiling well before a TGW hub would, another trigger to move to Transit Gateway.

A VPC peering connection won't let you use the peer VPC's internet gateway, NAT device, Site-to-Site VPN, Direct Connect, or gateway endpoint: edge-to-edge routing through a peer is unsupported. Centralized egress or shared on-prem connectivity therefore requires a Transit Gateway (or Cloud WAN), not peering.

Trap Centralizing internet egress through one peered VPC's NAT gateway: peers can't reach a neighbor's NAT, IGW, VPN, or DX, so shared egress needs a TGW/Cloud WAN hub.

For just two or three VPCs, VPC peering is simpler and carries no hourly hub charge, whereas a Transit Gateway adds a per-attachment hourly fee plus per-GB data-processing charges. Reserve the TGW hub for many-VPC or hybrid topologies where its operational simplicity outweighs the per-attachment cost.

Trap Standing up a Transit Gateway hub for two VPCs that only need to talk to each other: you pay attachment plus data-processing fees for routing peering would do free.

Centralized inspection through Transit Gateway (Network Firewall, Gateway Load Balancer, or third-party appliances in an inspection VPC) requires enabling appliance mode on the inspection VPC attachment. Appliance mode makes the TGW pick one network interface and Availability Zone via a flow hash and pin both forward and return traffic to that same AZ for the life of the flow (including flows whose source and destination are in different Regions) preventing the asymmetric routing that otherwise drops cross-AZ stateful connections. It's supported only on VPC attachments.

Trap Expecting symmetric return paths through a stateful inspection VPC without appliance mode: the TGW will otherwise hash forward and return flows to different AZs and the appliance drops the asymmetric half.

Network Firewall's stateful (Suricata) rules only evaluate traffic whose source falls inside the HOME_NET rule variable, which defaults to the CIDR of the VPC where the firewall endpoints are deployed. In a centralized inspection VPC behind Transit Gateway, spoke-VPC and on-premises traffic is silently ignored until you expand HOME_NET to include those CIDR ranges.

Trap Leaving HOME_NET at its default in a centralized inspection VPC: stateful rules then skip every spoke's traffic because its source falls outside the inspection VPC's own CIDR.

Before a Transit Gateway can be shared to your organization or specific OUs, you must enable sharing with AWS Organizations (RAM trusted access) from the management account; in-organization shares then grant access with no invitation to accept. The receiving account's VPC attachment still needs approval, though, unless 'Auto accept shared attachments' is enabled on the Transit Gateway itself.

Trap Assuming an in-organization RAM share auto-approves the spoke's VPC attachment, when the attachment still needs acceptance unless 'Auto accept shared attachments' is enabled on the TGW.

A complete org security posture needs two layers: preventive controls that block bad actions before they happen (SCPs, RCPs, AWS Firewall Manager) and detective services that surface what gets through (Amazon GuardDuty, AWS Security Hub, Amazon Macie, AWS Config, IAM Access Analyzer). A guardrail nobody monitors drifts unnoticed; a finding you cannot prevent recurs: SAP-C02 scenarios that name only one layer are usually incomplete.

Trap Treating GuardDuty or Security Hub as preventive controls that stop the offending action; detective services only surface findings, while SCPs, RCPs, or Firewall Manager are what actually block.

A permissions boundary is the IAM-level ceiling on a single user or role, the right tool to cap one delegated-admin or CI principal, where an org-wide SCP would over-reach. It only filters, never grants: the effective permissions are the intersection of the boundary and the identity-based policy, so the action must be allowed by the boundary, any SCP, and the identity policy together.

Trap Reaching for an SCP to restrict a single principal: an SCP filters every identity in the account, not one user or role.

GuardDuty, Security Hub, Macie, IAM Access Analyzer, AWS Config, and Firewall Manager each support registering a delegated administrator account. Run them from a dedicated Security or Audit member account so day-to-day administration happens outside the management account, in line with least privilege, and so the security tooling itself stays subject to the org's SCPs and RCPs.

Trap Operating org security services directly from the management account: it violates least privilege and the management account is exempt from SCPs and RCPs.

GuardDuty is a Regional service, so the same member account must be designated as delegated administrator in every Region you use it. Organization auto-enable is NEW (new member accounts only) or ALL (new and existing); choose ALL so every current and future member gets continuous threat detection without manual onboarding.

Trap Leaving auto-enable on NEW and assuming existing accounts are covered: NEW onboards only future members, so accounts already in the org stay unprotected.

A single GuardDuty delegated administrator can manage a maximum of 50,000 member accounts per Region; cross that and you receive a notification via CloudWatch, the Health Dashboard, and email. An organization can hold more than 50,000 accounts, but one delegated admin cannot cover them all in a single Region: the cap is the testable ceiling.

Security Hub runs control checks and produces a per-standard security score against standards including AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, NIST SP 800-53 Rev 5, and PCI DSS. Enabling a standard automatically enables all of its controls; you can then disable individual controls as needed.

Trap Assuming you opt into each control one by one; enabling a standard turns on all of its controls at once, and you disable the unwanted ones afterward.

Security Hub central configuration lets the delegated administrator write configuration policies that target OUs and accounts from one home Region, enabling Security Hub, standards, and controls across new and existing accounts while leaving chosen accounts self-managed. It replaces per-account, per-Region setup, which is the source of configuration drift in large orgs.

Trap Relying on local configuration to cover the whole org: local config only auto-enables new accounts in the current Region, never existing accounts or other Regions.

AWS Firewall Manager centrally enforces AWS WAF, AWS Shield Advanced, security-group, AWS Network Firewall, and Route 53 Resolver DNS Firewall policies across every account in the org, automatically applying protection to newly created and non-compliant resources. Use it for org-wide mandates such as 'AWS WAF on every ALB' that must hold as new accounts and resources appear.

Trap Assuming Firewall Manager only protects resources created after the policy; it also detects and remediates existing non-compliant resources across the org.

Firewall Manager evaluates and remediates resources through AWS Config, so AWS Config must be enabled in every account and Region a Firewall Manager policy scopes. Without it, Firewall Manager has no resource inventory to assess in that account and silently cannot enforce or remediate there: enabling Config is a documented prerequisite.

Trap Expecting a Firewall Manager policy to protect an account where AWS Config is off: it cannot evaluate resources there, so coverage gaps go unnoticed.

An IAM Access Analyzer with the AWS Organization as its zone of trust flags resources shared with principals outside the org (external-access findings) at no charge. A separate unused-access analyzer continuously reviews dormant roles, access keys, and passwords and is billed per IAM role or user analyzed per analyzer per month, so 'find unintended external sharing' is the free use, while 'clean up unused access' carries a cost.

Trap Assuming every IAM Access Analyzer analyzer is free: only external-access analysis is free; unused-access (and internal-access) analyzers are billed.

Amazon Macie runs automated sensitive-data discovery across Amazon S3, using machine learning and pattern matching to find PII, credentials, and financial data, and it reports each bucket's public-access and encryption posture. For 'locate unencrypted PII in S3 org-wide' scenarios, Macie is the answer: GuardDuty watches for threats and Config tracks configuration, but neither classifies object contents.

Trap Choosing GuardDuty or AWS Config to find sensitive data inside S3 objects: only Macie inspects and classifies object contents.

AWS Config records resource configuration and change history, and an organization Config aggregator plus organization Config rules and conformance packs give a single read-only, org-wide compliance view. Config requires its recorder enabled in each account, and it flags non-compliant resources rather than blocking them: pair it with an SCP or Firewall Manager when you actually need to prevent the drift.

Trap Expecting AWS Config to block non-compliant resources: Config detects and reports drift but never prevents the action.

An organization trail in AWS CloudTrail captures management (and optionally data) event API activity from the management account and every member account into a single S3 log-archive bucket, typically in a dedicated logging account. Member accounts can see the trail but cannot stop or alter it, giving tamper-resistant central audit logs that feed Security Hub and Config for org-wide detection.

Trap Stitching together a separate per-account trail in every member account: an organization trail logs all accounts into one bucket and members cannot disable it.

To inspect encrypted HTTPS payloads, AWS Network Firewall uses a TLS inspection configuration that decrypts traffic, runs it through the stateful rules, then re-encrypts it before forwarding. Outbound (egress) inspection requires importing a CA certificate into AWS Certificate Manager (Network Firewall uses it to generate the server certificate) while inbound uses a server certificate in ACM; scope settings control which flows are decrypted. Without TLS inspection you can only match unencrypted content or the TLS SNI.

Network Firewall's stateful engine is Suricata, so you can import Suricata-compatible IPS rulesets (e.g. Emerging Threats) directly for signature-based detection. Strict rule order evaluates rule groups by priority and rules in the exact sequence you define; pairing it with a 'Drop established' default action builds a default-deny posture where only explicitly allowed traffic passes.

Trap Assuming default (action) rule order honors your priorities literally: only strict order evaluates rules in your exact sequence; default order applies pass before drop before reject first.

IAM Access Analyzer custom policy checks use automated reasoning to validate policies before they ship in a pipeline: CheckNoPublicAccess flags resource policies that could grant public access, CheckAccessNotGranted fails when a policy permits a specified list of sensitive actions, and CheckNoNewAccess fails when an updated policy grants more access than a reference policy. Each call to check for new access is billed.

Trap Mixing up the checks and using CheckAccessNotGranted to compare a policy against a prior version; comparing new access to a reference policy is the job of CheckNoNewAccess.

When regulations require key material in FIPS 140 Level 3 validated hardware under your direct control (often with PKCS#11 support), back an AWS KMS custom key store with a CloudHSM cluster: keys are managed through the familiar KMS interface but generated and stored in HSMs you own and audit. A CloudHSM-backed key store supports only symmetric encryption KMS keys, not asymmetric keys, HMAC keys, imported key material, or automatic rotation.

Trap Planning to create asymmetric or HMAC KMS keys in a CloudHSM custom key store: it supports only symmetric (AES) encryption keys.

Security Hub cross-Region aggregation replicates findings, finding updates, insights, control statuses, and security scores from linked Regions into a single home (aggregation) Region, so the delegated administrator's home-Region console, EventBridge feed, and downstream integrations see every Region's findings at once instead of Region by Region. Updates flow both ways and the replication adds no cost.

Trap Reaching for central configuration to pull every Region's findings into one console; central configuration deploys settings org-wide, while cross-Region aggregation is what consolidates the findings themselves.

Deployment patterns trade rollback speed against cost. All-at-once is the cheapest and fastest but a bad release hits 100% of users at once and rollback is a second full deploy. Blue/green holds blast radius at 0% until cutover and rolls back instantly by flipping traffic back to the warm blue fleet, but you pay for two full environments during the window. Canary and linear expose a small slice first behind an alarm-gated abort. Rolling in-place needs no duplicate fleet, but it leaves mixed versions live and rolls back slowly batch by batch.

Trap Defaulting to blue/green as the universally best pattern, ignoring that all-at-once or rolling can be the right call when the workload is cost-sensitive and can tolerate slower recovery.

Blue/green stands up a parallel green environment running the new version and cuts traffic over at the load balancer or via Route 53 weighted DNS; because the old blue fleet keeps running, rollback is an immediate traffic flip with no redeploy. The cost is paying for two full identical environments during the cutover window, so it is the wrong fit for cost-sensitive, low-risk workloads that can tolerate a slower recovery.

Canary and linear both shift traffic gradually but differ in shape. A canary config shifts one small increment first (for example 10%), waits a fixed interval, then sends the remaining 90% all at once. A linear config shifts a fixed percentage on a repeating interval (for example 10% every minute) until 100%. Both give a CloudWatch-alarm window to auto-abort before the bad version reaches everyone; canary concentrates the observation in one early gate, linear distributes exposure across many equal steps.

Trap Treating canary as a gradual ramp to 100%, when after the single observation interval it sends the entire remaining 90% in one jump.

On the EC2/on-premises compute platform CodeDeploy does in-place batch deployment governed by a minimum-healthy-hosts value (the number or percentage of instances that must stay available), not traffic weighting. The three predefined configs are CodeDeployDefault.AllAtOnce, CodeDeployDefault.HalfAtATime, and CodeDeployDefault.OneAtATime; when none is specified CodeDeploy defaults to CodeDeployDefault.OneAtATime.

Trap Assuming CodeDeploy shifts EC2 traffic by percentage like it does for Lambda/ECS, when EC2 in-place is governed by minimum-healthy-hosts.

On the AWS Lambda compute platform CodeDeploy shifts traffic between function versions using alias weighting. Predefined configs include CodeDeployDefault.LambdaCanary10Percent5Minutes (with 10/15/30-minute variants), CodeDeployDefault.LambdaLinear10PercentEvery1Minute (with 2/3/10-minute variants), and CodeDeployDefault.LambdaAllAtOnce. Pre-traffic and post-traffic Lambda validation hooks can gate promotion before and after the shift.

Trap Assuming Lambda traffic shifting needs a load balancer or target group, when CodeDeploy moves it purely through weighted version aliases.

On the Amazon ECS compute platform CodeDeploy shifts traffic to a new task set using canary, linear, or all-at-once configs such as CodeDeployDefault.ECSCanary10Percent5Minutes and CodeDeployDefault.ECSLinear10PercentEvery1Minutes (the ECS linear name ends in "Minutes" plural where the Lambda equivalent ends in "Minute"). Weighted traffic shifting requires a weighted target group, so behind a Network Load Balancer only CodeDeployDefault.ECSAllAtOnce is supported.

Trap Specifying an ECS canary or linear config behind a Network Load Balancer, which supports only ECSAllAtOnce because it cannot do weighted target-group shifting.

CodeDeploy can automatically roll back^[4] when a deployment fails or when a monitoring threshold you set (a CloudWatch alarm in ALARM state) is met; the rollback redeploys the last known good revision as a brand-new deployment with its own ID, not a restore. Attach health alarms to every deployment so the platform reverts without a human in the loop.

AWS AppConfig^[5] deploys configuration and feature-flag changes to running applications so you can adjust production behavior without a full code deployment, decoupling feature releases from code releases. It is the right tool when behavior must change but the deployed artifact should not, and it reaches EC2, ECS, Lambda, and other compute through the AppConfig agent, Lambda extension, or the SDK/API.

Trap Pushing a full code redeploy just to toggle a feature flag, when AppConfig changes runtime behavior without touching the deployed artifact.

An AWS AppConfig deployment strategy uses a Linear or Exponential deployment type, a step percentage (the API calls it growth factor) setting how many callers each step targets, a deployment-time window over which the rollout is processed, and a final bake time. During the bake time AppConfig monitors the configured CloudWatch alarms after the change reaches 100% of targets and automatically rolls the configuration back if an alarm fires; AppConfig must be granted IAM permission to perform that rollback.

Trap Expecting AppConfig to keep monitoring for rollback after the bake time elapses, when its automatic alarm-driven rollback only covers the bake-time window.

Build the artifact once and promote that same immutable build through staging to production rather than rebuilding it at each stage. Rebuilding per environment risks shipping a different artifact to prod than the one that was tested, which defeats the entire purpose of a tested release path.

CodePipeline chains CodeBuild (build/test), CodeDeploy (release), and CloudFormation actions into stages, and a manual-approval action^[6] inserted between stages stops execution until someone with the right IAM permission approves or rejects (for example gating staging to production). A rejection or no response within seven days fails the action, giving a repeatable, reviewed, auditable change path instead of ad-hoc deploys.

A CloudFormation change set^[7] previews exactly which resources an update will add, modify, or delete (including which changes force a replacement) before anything is touched; nothing changes until you execute it. A change set does NOT guarantee the update will succeed (quotas, permissions, or non-updatable properties can still fail it), and executing one removes all other change sets associated with that stack.

Trap Treating a clean change set as a guarantee the update will succeed, when quotas, permissions, or non-updatable properties can still fail the execution.

Defining infrastructure as CloudFormation (or CDK/SAM, which synthesize to CloudFormation) makes environments reproducible and lets drift detection flag resources changed outside the template. Out-of-band console edits create drift that should be reconciled back into the template so the IaC stays authoritative; a half-managed stack where humans also click in the console loses that guarantee.

Trap Fixing a production issue with a quick console edit, creating drift that leaves the template no longer matching the live stack.

CloudFormation StackSets deploy a single template as stack instances into many accounts and Regions from one administrator account. A stack instance is a reference to a stack in a target account/Region and can exist even when its underlying stack failed to create (it records the failure reason). Updating the StackSet pushes the template change to all associated stack instances at once; you cannot selectively update the template for only some instances.

Trap Expecting to push a template update to only a subset of stack instances, when a StackSet update applies to all associated instances at once.

With service-managed permissions (integrated with AWS Organizations) StackSets create the required cross-account IAM roles for you and support automatic deployment, so any account later added to a target organizational unit inherits the baseline stack automatically. Self-managed permissions instead require you to create the cross-account roles yourself and target individual account IDs, with no auto-deploy to accounts added in the future.

Trap Choosing self-managed StackSets permissions when the requirement is automatic baseline deployment to future organization accounts, which only service-managed provides.

StackSet operation preferences give the incremental, fail-fast behavior you want from any production rollout: maximum concurrent accounts caps how many accounts deploy at once, failure tolerance (evaluated per Region) stops the operation once too many stacks fail in a Region, and Region concurrency is Sequential (default, one Region at a time in the deployment order) or Parallel. With Strict failure tolerance, maximum concurrent accounts can be at most one more than the failure-tolerance value.

Trap Reading failure tolerance as a global count across all Regions, when StackSets evaluate it per Region so the threshold applies separately in each one.

Canary, linear, and blue/green all assume the old and new versions can run side by side while traffic shifts between them. A backward-incompatible (schema-breaking) database migration violates this and breaks the still-running old version, so apply expand/contract migrations first to keep both versions readable, or accept a maintenance-window all-at-once cutover.

Trap Running a canary or blue/green cutover over a schema-breaking database migration, which breaks the old version still serving live traffic.

Publish a new launch template version carrying the updated AMI, then start an Auto Scaling group instance refresh to replace instances in rolling batches. MinHealthyPercentage sets the percentage of desired capacity that must stay in service before the refresh continues (default 90%), and MaxHealthyPercentage caps how far above desired capacity the group can scale while replacing (default 100%). Enable auto rollback wired to a CloudWatch alarm to revert on failure, and use skip matching so instances already on the desired configuration are left untouched.

Trap Updating only the Auto Scaling group's launch template and expecting running instances to pick up the new AMI, when existing instances need an instance refresh to be replaced.

RTO (Recovery Time Objective) is the maximum acceptable time to restore service after a disruption; RPO (Recovery Point Objective) is the maximum acceptable data loss, measured as a span of time before the disruption. The two are independent levers: continuous replication can drive RPO to near-zero while RTO stays high because servers still have to be turned on and scaled up before they serve traffic. Set both from business need, then choose the strategy that meets them.

Trap Assuming a near-zero RPO automatically buys a near-zero RTO: replicated data can sit on infrastructure that still needs minutes to come online.

AWS frames four DR strategies, cheapest/slowest to costliest/fastest: backup and restore, pilot light, warm standby, and multi-site active/active. Backup and restore lands RTO/RPO in hours; multi-site active/active reaches near-zero RTO for most disasters. Choose by the RTO/RPO the business actually requires against budget, since each step up the curve trades ongoing cost for faster recovery.

Trap Defaulting to multi-site active/active for every workload: it is the most complex and costly option, and many workloads are met far more cheaply by pilot light or warm standby.

Backup and restore is the lowest-cost strategy: it keeps only data backups (plus point-in-time recovery) in the recovery Region and, on disaster, redeploys infrastructure from CloudFormation/CDK IaC before restoring data from AWS Backup or snapshots. RTO is in hours because nothing is pre-running, so it fits workloads that can tolerate extended downtime. Restore is a control-plane operation, so periodically pre-restore to prove recovery is viable even if the control plane is degraded.

Trap Trusting an untested backup as a DR plan: restore is a control-plane action that can fail exactly when a Region is impaired, so unexercised backups may not restore when needed.

Pilot light replicates data live and provisions core infrastructure, but application servers are loaded and "switched off": they must be turned on and scaled out before they can serve traffic. This yields a low RPO with an RTO of tens of minutes at low ongoing cost, since only the data layer runs continuously. The defining line: pilot light cannot process requests until you act, which is exactly what separates it from warm standby.

Trap Treating pilot light as ready to serve traffic on failover: it cannot, because the application tier is off until you switch it on and scale it.

Warm standby keeps a scaled-down but fully functional copy of production always running in the recovery Region, handling traffic at reduced capacity, so failover only needs a scale-up: no servers to turn on. It buys a faster RTO than pilot light in exchange for higher steady-state cost. Raise DR-Region service quotas ahead of time so the scale-up to full production capacity is not throttled at the worst moment.

Trap Assuming the DR Region can scale to production capacity on demand, when default service quotas there cap the recovery scale-up and stall failover during the incident.

Pilot light and warm standby both keep a copy of primary assets in the DR Region, but the distinction AWS draws is operational: pilot light cannot process requests without additional action first (turn on servers, possibly deploy non-core infra, then scale), whereas warm standby handles traffic immediately at reduced capacity and only needs to scale up. Use the required RTO to choose: warm standby recovers faster but costs more to keep running.

Trap Assuming pilot light keeps a small fleet already serving traffic just like warm standby, when its compute is off until you act, so only warm standby handles requests immediately at reduced capacity.

Multi-site active/active serves production traffic from every Region it is deployed to, so there is no failover step: you simply route away from a failed Region. Hot standby is the active/passive variant: full capacity is pre-provisioned and statically stable in the standby Region, but only one Region takes traffic until cutover. Both are the highest-cost strategies and target near-zero RTO; AWS notes most teams that stand up a full second Region just run it active/active.

Trap Calling any two-Region deployment "active/active": if only one Region actually receives user traffic, it is hot standby (active/passive), not active/active.

The replication mechanism, not the strategy label, determines RPO. Continuous asynchronous replication (Aurora global database, DynamoDB global tables, S3 Cross-Region Replication) gives a near-zero RPO; periodic snapshots make RPO equal to the backup interval. A design labelled "warm standby" still carries an hours-long RPO if its data layer only snapshots: match the replication to the RPO you need.

Trap Inferring RPO from the DR strategy's name: a warm-standby compute tier paired with snapshot-only data still loses everything since the last snapshot.

Continuous replication copies corruption, accidental deletes, and malicious changes straight to the DR Region, so it cannot recover from a data disaster on its own. Pair replication with S3 versioning or point-in-time snapshots so you can roll back to a moment before the bad event. With S3 Cross-Region Replication, a delete with no version ID writes a delete marker in the source bucket only by default, shielding the replica from source-side deletions.

Trap Relying on cross-Region replication as your backup: it propagates corruption and deletions verbatim, leaving no clean point to recover from without versioning or snapshots.

An Amazon Aurora global database replicates from one primary to up to 10 read-only secondary Regions with cross-Region replication latency typically under one second, using dedicated storage-layer infrastructure that doesn't tax the database engine. On a Region outage you can promote a secondary to read/write in under a minute, and you can monitor each secondary's RPO lag. It supports write forwarding, but Backtrack is not supported on a global database.

Trap Expecting Aurora Backtrack to undo changes on a global database: Backtrack is unsupported there, so cross-Region promotion or snapshot copy is the recovery path.

Amazon DynamoDB global tables replicate across Regions and let any replica take reads and writes, fitting active/active write-local designs. The default multi-Region eventual-consistency (MREC) mode replicates within about a second and reconciles concurrent updates with last-writer-wins per item, giving an RPO equal to the replication delay. The strongly consistent multi-Region (MRSC) mode delivers RPO=0 but must be deployed in exactly three Regions within one region set.

Trap Assuming global tables give cross-Region strong consistency by default: the default MREC mode is eventually consistent (RPO > 0); RPO=0 requires the three-Region MRSC mode.

Standard S3 Cross-Region Replication is asynchronous with no time guarantee. S3 Replication Time Control (S3 RTC) replicates most new objects in seconds and is backed by an SLA to replicate 99.9% of objects within 15 minutes, emitting OperationMissedThreshold events and S3 Replication metrics when an object exceeds that 15-minute threshold. Use S3 RTC when a bounded, measurable S3 RPO is a compliance requirement rather than best-effort.

Trap Counting on plain S3 CRR for a guaranteed replication window: only S3 RTC carries the 15-minute SLA and missed-threshold events; standard CRR makes no timing promise.

Aurora Backtrack rewinds a cluster to an earlier point in time in place (Aurora MySQL only, up to 72 hours) and never moves data to another Region, so it is not a cross-Region DR mechanism and is unsupported on an Aurora global database. It is fast in-place recovery from logical errors; for Region-level recovery use an Aurora global database or a cross-Region snapshot copy instead.

Trap Choosing Aurora Backtrack to recover from a Region outage: it only rewinds the cluster in place (MySQL, 72h max), providing no copy in another Region.

AWS Backup schedules and monitors backups across services (EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx, Storage Gateway) from one place and can copy recovery points cross-Region and cross-account. Copying to a separate account is the key insider-threat and account-compromise defense: a compromised member account cannot delete a copy held in a different account. Pair cross-Region copy for Region resilience with cross-account copy for blast-radius isolation.

Trap Keeping every backup copy in the same account as production: an account compromise or insider can then delete the only copies; a cross-account copy survives that.

AWS Backup Vault Lock enforces WORM on a vault. Governance mode can be removed by users with sufficient IAM permissions; compliance mode has a cooling-off grace time (ChangeableForDays, minimum 3 days / 72 hours) during which it can still be changed, after which the vault and lock become immutable and cannot be deleted or altered by any user or by AWS while recovery points remain. You can set min/max retention, with a maximum of 36,500 days (~100 years).

Trap Expecting to remove a compliance-mode vault lock after its grace time: once ChangeableForDays elapses it is immutable to everyone, including AWS and the root user.

Resilient Region failover should use data-plane operations, which have higher availability design goals than control planes. Route 53 health-check DNS failover and ARC routing controls (on/off switches built on Route 53 health checks) are data-plane and stay available during an incident. Changing Route 53 weighted-record weights or a Global Accelerator traffic dial is a control-plane operation, so it is less resilient at exactly the moment you most need to fail over.

Trap Failing over by editing Route 53 record weights or a Global Accelerator traffic dial: those are control-plane changes that may be unavailable during the disaster; use data-plane ARC routing controls.

ARC safety rules are guardrails on routing-control state changes: an assertion rule can enforce that at least one routing control stays On to prevent a fail-open scenario, and a gating rule acts as a master on/off switch over a set of controls. Separately, ARC readiness checks continually monitor that the recovery Region's quotas, capacity, and routing stay aligned with production, but AWS says they are for ongoing preparation, not a primary failover trigger (and readiness check is no longer open to new customers).

Trap Using ARC readiness checks as the failover trigger: AWS states they verify steady-state alignment and should not be relied on to initiate recovery during a disaster.

AWS Elastic Disaster Recovery (DRS)^[9] continuously replicates server-hosted applications and databases into AWS at the block level using a low-cost staging-area subnet, following the pilot-light pattern. On failover it converts servers to boot natively on AWS and automatically launches a full-capacity environment, with recovery instances ready within minutes. It targets on-premises, other-cloud, or EC2-hosted workloads, not managed services such as RDS.

Trap Reaching for AWS DRS to protect managed services like RDS: DRS replicates server/EC2 block storage, so RDS and similar managed databases need their own DR (cross-Region replicas or snapshots).

DR readiness comes only from exercising it: run failover drills (GameDays), verify that restores from backup actually complete, and for active/active confirm that traffic routes away from a lost Region and the survivors absorb full load. Automate the failover steps even when a human initiates them, so recovery is a single deterministic action rather than an error-prone scramble under pressure.

DNS-based failover time is governed by record TTL plus health-check speed. Lower the TTL (commonly 60 seconds or less) so resolvers stop caching the old answer quickly, choose Route 53's fast 10-second health-check interval instead of the standard 30-second one, and reduce the failure threshold so an endpoint is marked unhealthy after fewer failed probes. A high TTL keeps sending users to the failed Region long after the health check has already flipped.

Trap Tuning only the health-check interval while leaving a high record TTL: resolvers keep serving the cached failed endpoint until the TTL expires, no matter how fast the check flips.

In a failover routing configuration, if Route 53 considers both the primary and secondary records unhealthy, it returns the primary record rather than no answer: it must return something, so it falls back to primary. This is why traffic can keep flowing to a failed primary even during an outage; to force a true cutover, make sure the secondary stays healthy (or rework the health-check association) so Route 53 has a healthy target to choose.

Trap Expecting Route 53 to stop answering when every endpoint is unhealthy: it returns the primary record instead, so an unhealthy secondary leaves users pinned to the dead primary.

For alias records pointing to ALBs/NLBs (including latency-based and weighted alias records), set Evaluate Target Health to Yes so Route 53 derives endpoint health from the load balancer's registered targets without a separate health check. When the closest Region's targets are all unhealthy, Route 53 backs out of that branch and routes to the next-best healthy Region automatically. With it set to No, Route 53 keeps sending traffic to the failing alias target.

Trap Leaving Evaluate Target Health set to No on alias records: Route 53 then routes to the alias target even when its underlying targets are all unhealthy, defeating automatic failover.

Route 53 health checkers run from outside the VPC and cannot reach private IP addresses, so for resources with only private IPs (or for any condition best expressed as a metric) create a CloudWatch alarm and a Route 53 health check that monitors that alarm's data stream. This also lets you fail over on application signals such as 5XX counts or response time, not just basic reachability. The CloudWatch alarm must live in the same account as the health check.

Trap Pointing a standard Route 53 endpoint health check at a private IP: the public health checkers can't reach it, so route via a CloudWatch-alarm health check instead.

Amazon Application Recovery Controller (ARC) routing controls are simple on/off switches wired to Route 53 DNS failover records, making failover and failback deliberate operator decisions rather than automatic flapping on a health check. Each ARC cluster is a data plane of redundant endpoints spread across five AWS Regions, so you can toggle controls during an incident without depending on a single Region's control plane.

Trap Letting an automatic health check flip Regions when you need a controlled cutover: health-check automation can flap; ARC routing controls keep failover and failback as deliberate operator actions.

Configure an RDS cross-Region read replica as a Multi-AZ deployment before a disaster, so that when you promote it to a standalone primary it is already Multi-AZ and highly available immediately, with no separate conversion step during recovery (otherwise modifying to Multi-AZ is an extra post-promotion action). Promotion is the standard low-RPO cross-Region DR cutover for RDS, paired with pointing the application at the new endpoint.

Trap Promoting a single-AZ cross-Region replica during a disaster and only then converting it to Multi-AZ: that conversion adds time and leaves the new primary without standby HA at the worst moment.

AWS Backup Audit Manager evaluates backup activity against controls in a framework; the "Last recovery point was created" control flags any resource whose most recent recovery point is older than a configured window (set in hours, 1–744, or days, 1–31), which is how you automatically detect a missed RPO. Report plans deliver scheduled compliance reports to an S3 bucket for auditors, and cross-account aggregation is available to a management or delegated administrator account.

Trap Assuming a backup plan alone guarantees RPO compliance: without the "last recovery point" control, a silently failed or skipped backup goes unnoticed until you need to restore.

An AWS Backup lifecycle moves recovery points to cold storage after a set number of days, but a backup must remain in cold storage for a minimum of 90 days, so the delete-after value must be at least the transition-to-cold days plus 90 (total retention of 90+ days is required to use cold storage at all). AWS Backup does not support cross-Region copies of recovery points already in a cold tier, so initiate any cross-Region copy before the point transitions to cold.

Trap Scheduling a cross-Region copy of a recovery point that has already moved to cold storage: AWS Backup can't copy cold-tier points across Regions, so the copy must happen before the cold transition.

S3 Replication copies objects but not the bucket's lifecycle configuration, and lifecycle actions on the source (such as expirations) are not applied to the destination: Amazon S3 even creates expiry delete markers on the source without replicating them. To keep source and destination consistent (matching transition and noncurrent-version expiration behavior), configure identical lifecycle policies on both buckets independently, or the replica accumulates versions and drifts from the source's retention.

Trap Assuming a source-bucket lifecycle policy also ages out the replica: lifecycle config and its actions don't replicate, so the destination must carry its own identical rules.

Amazon CloudWatch^[1] is the observability backbone: it collects metrics, evaluates alarms against thresholds, and renders dashboards, while CloudWatch Logs centralizes log storage and query. Improving operational excellence on an existing workload starts here: close observability gaps first so behavior is measurable before you change anything, since an alarm can also trigger an automated action, not just notify.

Trap Assuming a CloudWatch alarm can only send an SNS notification, when an alarm action can also invoke automated remediation such as an EC2 action, Auto Scaling, or an SSM Automation runbook.

A CloudWatch Logs metric filter^[3] matches a pattern in incoming log events (say ERROR or a status code) and publishes a numerical CloudWatch metric you can graph and alarm on. This is how you alert on something that lives only in logs and has no native metric. Filters are not retroactive: they only emit data points for events that arrive after the filter is created.

Trap Expecting a newly created metric filter to backfill a metric from log events that arrived before it existed, when filters only emit data points for events ingested after creation.

CloudWatch Logs Insights^[2] runs interactive queries across log groups to investigate incidents and pin down root cause. It complements metrics rather than replacing them: a metric tells you something is wrong, Logs Insights tells you why. It can identify potential causes and validate that a deployed fix worked.

Trap Reaching for Logs Insights to continuously alarm on a log pattern, when it is an interactive query tool, so a metric filter feeding an alarm is what drives ongoing alerting.

The CloudWatch embedded metric format (EMF)^[4] lets ephemeral resources like Lambda functions and containers write structured log events that CloudWatch automatically parses into custom metrics, generating metrics asynchronously without a synchronous metrics API call. The IAM consequence is the tell: you need logs:PutLogEvents but NOT cloudwatch:PutMetricData.

Trap Granting cloudwatch:PutMetricData for an EMF-based design: EMF writes through CloudWatch Logs, so that permission is neither required nor sufficient.

A CloudWatch composite alarm^[19] fires on a rule expression over other alarms using AND, OR, and NOT operators, so you page only when correlated conditions hold together (for example high CPU AND high latency) instead of on every child alarm. Reach for it to reduce alert fatigue without deleting the underlying alarms that still feed the rule.

Trap Suppressing noise by raising every individual alarm's threshold: that blinds you to real single-signal breaches; a composite alarm correlates them instead.

AWS X-Ray^[5] traces a request as it fans out across microservices and renders a service map (trace map) of client, front end, and backends, isolating which downstream call adds the latency or errors. Reach for X-Ray when per-service CloudWatch metrics can't explain end-to-end latency in a distributed application: it shows the path, not just per-component aggregates.

Trap Trying to localize a cross-service latency spike from per-service CloudWatch metrics alone: they don't reveal the request path the way a trace does.

A Systems Manager Automation runbook^[6] is an SSM document of type Automation (schema version 0.3) defining sequential steps that act on AWS resources and managed nodes, distinct from Command, Session, and Policy document types. AWS ships predefined runbooks and you can author custom ones, including aws:executeScript steps that run Python or PowerShell when no built-in action fits.

Trap Picking a Command document to orchestrate multi-step actions against AWS service APIs and resources, when Command runs scripts on managed nodes and orchestration across resources is what an Automation document does.

Systems Manager Automation is a supported EventBridge target^[6], so an EventBridge rule matching an event (alarm state change, finding, schedule) can invoke a runbook to remediate automatically with no servers to manage. This is the canonical event-driven auto-remediation pattern: the event is the trigger, the runbook is the fix.

Trap Inserting a Lambda function between EventBridge and the remediation step, when SSM Automation is a native EventBridge target, so the rule can invoke the runbook directly with no custom code.

AWS Config^[7] evaluates resources against rules and remediates noncompliant ones using AWS Systems Manager Automation documents, managed or custom. The distinction that gets tested: auto remediation fires the action automatically on noncompliance, whereas manual remediation needs an operator to start it. Config detects the drift from compliance; Automation is the mechanism that corrects it.

Trap Assuming every Config remediation fires automatically on noncompliance, when manual remediation requires an operator to start it, so only auto remediation corrects drift without human action.

Systems Manager Patch Manager^[8] scans managed nodes against a patch baseline (your definition of which OS and application patches are approved) and can scan-only or scan-and-install missing patches across a fleet. Schedule recurring patching through a maintenance window or a Quick Setup patch policy (the recommended method for multi-account, multi-Region patching), keeping the fleet compliant without manual work.

Trap Scripting recurring fleet patching with a one-off Run Command invocation, when a maintenance window or a Quick Setup patch policy is the mechanism that schedules and re-runs Patch Manager across the fleet.

Run Command^[9] runs a Command document across selected managed nodes once, on demand, for one-time tasks. State Manager^[10] uses associations to continuously enforce a desired configuration on a schedule (cron/rate). Keep the agent installed, re-apply settings, re-running to correct drift over time. The split that gets tested: one-shot execution versus ongoing desired-state enforcement.

Trap Reaching for Run Command to keep a fleet continuously configured: it runs once per invocation; State Manager associations are what re-converge drift on a schedule.

Systems Manager Session Manager^[11] gives interactive shell access to a managed node with no SSH keys, no bastion host, and no inbound ports open: access is governed by IAM policy instead. Sessions log to CloudWatch Logs or S3 for audit, replacing SSH/RDP for troubleshooting and letting you close inbound 22/3389 entirely.

Trap Standing up a bastion host plus inbound SSH to reach private instances: Session Manager removes the bastion, the open port, and the key pair at once.

Systems Manager Parameter Store^[12] stores configuration and secrets as String, StringList, or SecureString parameters, decoupling config from code; SecureString values are encrypted with AWS KMS. The boundary that gets tested: Parameter Store has no built-in secret rotation. When you need automatic rotation of database or API credentials, use AWS Secrets Manager instead.

Trap Choosing Parameter Store when the requirement is automatic credential rotation: it stores and encrypts but doesn't rotate; that's Secrets Manager's job.

Systems Manager OpsCenter^[13] aggregates operational issues as OpsItems with related resources, runbooks, and history, giving engineers one place to view, investigate, and resolve incidents instead of stitching signals across consoles. A CloudWatch alarm entering ALARM or an EventBridge event can auto-create an OpsItem, and each one surfaces Automation runbooks to remediate the issue directly.

Trap Reaching for Incident Manager to aggregate and track ongoing operational issues, when Incident Manager drives active incident response and on-call engagement and OpsCenter is the central catalog of OpsItems to investigate and resolve.

Amazon DevOps Guru^[14] applies machine learning to operational data and metrics to flag behavior that deviates from normal patterns, no manual threshold tuning. It emits reactive insights for an issue happening now and proactive insights predicting future issues, each with a recommendation. That fully-managed, learns-the-baseline angle is what distinguishes it from static CloudWatch alarms in a question.

Trap Hand-tuning static CloudWatch alarm thresholds to catch anomalous behavior: DevOps Guru learns the normal baseline and detects deviations without thresholds.

AWS Trusted Advisor^[15] inspects an account across cost optimization, performance, security, fault tolerance, service limits, and operational excellence. Basic and Developer plans expose only all Service Limits checks plus selected Security and Fault tolerance checks; the full check set and the Trusted Advisor API require a Business Support+ / Enterprise (or Unified Operations) plan. The support-plan gate is the commonly tested detail.

Trap Assuming a Basic or Developer plan unlocks the full Trusted Advisor check set or its API: those need Business Support+ / Enterprise.

The AWS Well-Architected Tool^[17] measures a workload against the framework pillars, including Operational Excellence, and surfaces identified risks plus best-practice recommendations to improve it. Use it to drive structured, repeatable improvement of an existing solution; custom lenses let you score against your own organizational standards beyond the AWS pillars.

Trap Reaching for Trusted Advisor to run a structured workload review against the Operational Excellence pillar, when that framework-based, pillar-scored review is the Well-Architected Tool's job and Trusted Advisor runs point-in-time best-practice checks.

AWS CloudFormation drift detection^[18] compares each deployed stack resource's actual property values against the template's expected values to surface manual, out-of-band changes (a resource is DRIFTED if a property was changed or deleted). It only reports the drift: pair it with State Manager or AWS Config remediation to automatically re-converge resources to the approved configuration.

Trap Expecting drift detection to fix the deviation: it only detects; correcting drift needs a stack update, Config remediation, or State Manager.

The AWS Health^[16] Dashboard gives ongoing visibility into events and scheduled changes that affect your specific AWS resources and account (maintenance, deprecations, operational issues), and is available to all customers at no cost. Route AWS Health events through EventBridge, also free for every customer, to automate notification or remediation as part of the ops-improvement loop.

Trap Watching the public Service Health Dashboard for issues that touch your own resources, when that page reports broad service status and AWS Health (your account-specific view) surfaces events scoped to your resources and account.

AWS Security Hub is the single pane of glass: it ingests GuardDuty, Inspector, Macie, and IAM Access Analyzer findings normalized into the AWS Security Finding Format (ASFF) and scores posture against standards like AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, NIST SP 800-53, and PCI DSS. It correlates and prioritizes findings from many sources but is not itself a threat detector: the detection happens in the services that feed it.

Trap Treating Security Hub as the detector that finds threats, rather than the aggregator that consolidates other services' findings.

Security Hub automation rules let the administrator account auto-update finding fields (severity, workflow status, notes) or suppress matching findings the moment they are ingested, before they flow on to EventBridge or a ticketing system. Rules apply across the admin account and all member accounts, and central configuration pushes standards and controls to OUs and accounts org-wide. The catch: a rule applies only in the Region where it is created, so org-wide action needs the rule replicated in every Region (e.g. via CloudFormation).

Trap Assuming one automation rule covers every Region: rules are Regional and must be recreated per Region.

Amazon GuardDuty continuously analyzes three always-on foundational sources at no extra cost (CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs) to surface active threats like compromised credentials, reconnaissance, and crypto-mining. CloudTrail S3 data events, EKS runtime, RDS login activity, Lambda network activity, and malware scanning are optional protection plans, not foundational. GuardDuty is detective and always-on; it reads logs and never changes configuration.

Trap Listing CloudTrail S3 data events as a foundational GuardDuty source: they require enabling the optional S3 Protection plan.

GuardDuty Malware Protection runs the agentless EBS-volume scan (automatically when a GuardDuty finding suggests compromise, or on demand) and can also scan objects on upload to S3. Amazon Inspector, by contrast, scans for software vulnerabilities (CVEs), not malware. When a question asks how to detect malware on a host, the answer is GuardDuty Malware Protection.

Trap Reaching for Amazon Inspector to detect malware on an instance: Inspector reports CVEs and network exposure, not malware.

Amazon Inspector automatically discovers and continuously scans EC2 instances, ECR container images, and Lambda functions for known CVEs and unintended network exposure, re-scanning whenever a package, patch, or newly published CVE changes the risk. There are no assessment scans to schedule and no agents to babysit. (The product is now just 'Amazon Inspector', the 'v2' suffix was dropped.)

Trap Scheduling periodic Inspector assessment runs: modern Inspector scans continuously and auto-rescans on change, with nothing to schedule.

Amazon Macie uses managed and custom data identifiers (ML plus pattern matching) to discover and classify sensitive data such as PII in Amazon S3, and it reports each bucket's public-access and encryption posture. Its scope is Amazon S3: it does not inspect RDS, DynamoDB, or EBS, so for sensitive data in those stores Macie is the wrong answer.

Trap Choosing Macie to classify sensitive data in RDS, DynamoDB, or EBS: Macie only analyzes Amazon S3.

IAM Access Analyzer external-access findings (public and cross-account access to your resources, found by automated reasoning on resource policies) carry no additional charge. Unused-access analysis, which flags unused roles, users, access keys, passwords, and permissions over a tracking window, is billed per IAM role or user analyzed per analyzer per month. It is neither entirely free nor entirely paid: the split is the testable point.

Trap Assuming all of IAM Access Analyzer is free: unused-access (and internal-access) analyzers are paid per resource analyzed.

To right-size existing permissions, pair IAM service/action last-accessed data and the account credential report (to expose unused permissions and stale credentials) with IAM Access Analyzer unused-access findings (to flag idle roles, users, keys, and passwords). Remove what is never exercised rather than guessing: last-accessed evidence is also what AWS recommends for refining over-broad SCPs.

Trap Trusting service last-accessed data to scope resource-level permissions, since it tracks access only at the service and action level, not per individual resource.

AWS Config rules detect non-compliant resources and can trigger an automatic remediation backed by an SSM Automation document (for example re-enabling S3 Block Public Access or revoking an open security-group rule) turning drift detection into self-healing without human action. Remediation always runs an SSM Automation document, so the fix is whatever that runbook does.

Trap Wiring a Config remediation action straight to a Lambda function, when Config remediation invokes an SSM Automation document, so a Lambda fix has to be wrapped in a runbook.

The prescribed automated-response pattern routes findings from Security Hub, GuardDuty, or Config through Amazon EventBridge rules to an AWS Lambda function or an SSM Automation document, so detection triggers a fix instead of a ticket. Favor this automated path over manual handling when a question contrasts automated remediation with human investigation.

AWS Systems Manager Patch Manager defines patch baselines, runs a Scan to report missing OS and application patches, or Scan-and-install to apply them, and surfaces fleet-wide patch compliance. It installs on a schedule via maintenance windows (or patch policies / on-demand Patch now), and is the SAP-C02 answer for fleet-wide patch compliance and remediation.

Trap Reaching for Amazon Inspector to remediate missing patches, since Inspector only reports vulnerabilities, while Patch Manager actually scans for and installs the patches.

Amazon Detective builds a behavior graph from its three core sources (CloudTrail logs, VPC Flow Logs, and ingested GuardDuty findings) so analysts can pivot from a GuardDuty or Security Hub finding to root cause and blast radius across up to a year of history (EKS audit logs and Security Hub findings are optional add-on source packages). It is for investigation after detection, never a replacement for GuardDuty's detection.

Trap Picking Detective to detect threats: it investigates and visualizes findings that GuardDuty (or another detector) already raised.

AWS Audit Manager continuously collects evidence from your AWS usage and maps it to prebuilt frameworks (CIS, PCI DSS, SOC 2, GDPR, HIPAA) to streamline audits and produce assessment reports. It produces audit-ready evidence: it does not detect threats or remediate, and it does not itself certify your compliance.

Trap Choosing Audit Manager to detect or block a security threat: it collects compliance evidence, not real-time detection or remediation.

GuardDuty, Inspector, Macie, and AWS Config are detective controls: they find and report a problem but cannot stop the action. To actually prevent it, reach for preventive guardrails: service control policies (SCPs) or resource control policies (RCPs) in AWS Organizations, or AWS Firewall Manager policies. An SCP never grants access; it sets the maximum permissions, so naming a detective service to 'block' or 'prevent' something is a wrong answer.

Trap Selecting GuardDuty, Macie, or Config to prevent or block an action: detective controls only report; use an SCP/RCP or Firewall Manager to block.

Enable cross-Region aggregation in the Security Hub delegated-admin account by designating a home (aggregation) Region and linking the others; findings, finding updates, insights, control compliance statuses, and security scores from linked Regions then surface in the home Region at no extra cost. Build the single downstream integration (e.g. an EventBridge rule to a SIEM) in the home Region so it sees all linked Regions. Automation rules stay Regional, so to act on findings everywhere you still replicate the rule in each Region.

Trap Expecting a home-Region automation rule to act on aggregated findings from every linked Region: aggregation centralizes the view, not rule execution.

Credential-related GuardDuty findings (Resource Type AccessKey, driven by global CloudTrail management events) replicate across Regions and look duplicated after Security Hub cross-Region aggregation. A GuardDuty suppression rule auto-archives new findings that match its criteria (and in a multi-account org only the GuardDuty administrator can create them). Create the suppression rules in every Region except the Security Hub home/aggregation Region, so the duplicates are archived elsewhere while the canonical finding stays visible in the home Region.

Trap Creating the suppression rule in the home/aggregation Region: that archives the copy you wanted to keep visible.

Automatic rotation of a KMS customer managed key generates new key material but retains all previous key material, so existing ciphertext stays decryptable and your data is not re-encrypted: rotation changes only the current key material, and to truly re-key data you must re-encrypt it yourself. The rotation period defaults to 365 days and is configurable, with on-demand rotation also available. Automatic rotation works only on symmetric keys with AWS_KMS-generated material; keys with imported (EXTERNAL) material can't auto-rotate and are rotated on demand after you import new material.

Trap Believing KMS key rotation re-encrypts existing data: it only swaps the current key material; old material is kept so prior ciphertext still decrypts.

A conformance pack is a collection of AWS Config rules and remediation actions deployed as one entity; as an organization conformance pack from the management or delegated-admin account, it enforces a baseline across all member accounts. Each member account needs a working Config recorder for its rules to evaluate, and the pack reports compliant only when every evaluated rule is compliant.

Trap Expecting conformance-pack rules to evaluate in a member account that has no Config recorder turned on.

AWS Config automatic remediation invokes an SSM Automation document using an AutomationAssumeRole that must already exist with the right permissions in each target account, including across an organization. Because remediation relies on the periodic compliance-data snapshot, a resource changed between snapshots can be remediated on stale data (auto-remediation can even fire on a now-compliant resource) and PutRemediationExceptions exempts specific resources.

Trap Assuming a single central AutomationAssumeRole works org-wide: the role must exist in every target account that gets remediated.

AWS Network Firewall's stateful engine can emit flow logs, alert logs, and TLS logs, each published to CloudWatch Logs, Amazon S3, or Amazon Data Firehose (formerly Kinesis Data Firehose) for monitoring and analysis (e.g. with Athena/QuickSight). Use AWS Firewall Manager to centrally create and enforce Network Firewall policies across every account and VPC in an organization rather than configuring each firewall by hand.

Trap Reaching for AWS WAF or Shield to filter VPC network traffic, since those guard application-layer and DDoS at the edge, while stateful VPC traffic inspection is Network Firewall's job.

The 7 Rs are the seven migration strategies AWS uses to decide each application's fate before any move runs: retire, retain, rehost, relocate, repurchase, replatform, and refactor/re-architect. They build on the 5 Rs Gartner identified in 2011, and portfolio assessment assigns one R per application across the estate.

Rehost ("lift and shift") moves an application to AWS without changing it to exploit cloud capabilities, for example, re-deploying an on-prem stack onto EC2. It is the fastest, lowest-effort path and the default when speed of exit beats optimization, since you can optimize or re-architect more easily once the workload already runs in the cloud.

Trap Treating rehost as the strategy that delivers cloud-native savings. It deliberately makes no optimizations; that's replatform or refactor.

Relocate ("hypervisor-level lift and shift") moves servers from an on-prem platform to a cloud service for that same platform, e.g. VMware workloads to VMware Cloud on AWS, without buying hardware, rewriting apps, or changing operations. It is the quickest path because the application's architecture is untouched; the contrast with rehost is that rehost re-deploys onto native EC2 while relocate preserves the source platform.

Trap Picking relocate when the target is native EC2. Once you re-deploy onto EC2 instances rather than a same-platform cloud service, that is rehost, not relocate.

Replatform ("lift, tinker, and shift" / "lift and reshape") moves the application to the cloud and adds some optimization to cut cost or gain managed-service benefits, but stops short of a rewrite. The canonical example is migrating a self-managed Oracle database to Amazon RDS for Oracle. Choose it when a small managed-service or licensing win is available without changing the core architecture.

Trap Choosing replatform when the database engine itself is being changed. Moving self-managed Oracle to RDS for Oracle is replatform, but converting Oracle to Aurora PostgreSQL re-architects the data layer and is refactor.

Repurchase ("drop and shop") replaces the application with a different product, typically swapping a traditional license for a SaaS model, for example, moving a CRM to Salesforce. Choose it when an equivalent SaaS exists and the custom application adds no differentiation worth maintaining infrastructure and licenses for.

Trap Calling a same-vendor license-to-SaaS swap a rehost. Replacing the product with a different offering (even a hosted version of the same app) is repurchase, not rehosting the existing binaries.

Refactor/re-architect rewrites the application to take full advantage of cloud-native features for agility, performance, and scalability, typically porting the operating system and database (e.g. on-prem Oracle to Amazon Aurora PostgreSQL). It delivers the most agility but is the most complex, expensive, and time-consuming of the 7 Rs, so it must be justified by strong business demand, and AWS advises against refactoring during a large migration, modernizing afterward instead.

Trap Choosing refactor as the default for a large migration. AWS recommends rehost/relocate/replatform at scale and modernizing after the move, because refactoring many apps at once is hard to manage.

Retire decommissions applications with no business value: discovery commonly flags "zombie" servers (under ~5% average CPU/memory) and "idle" ones (5–20% over 90 days, or no inbound connection for 90 days) as retire candidates. Retain keeps an app in the source environment for now (for compliance/data-residency, unresolved dependencies, a recent upgrade, or a pending SaaS release) and both are legitimate portfolio outcomes, not failures to migrate.

Trap Tagging a low-utilization but business-critical app as retire. Zombie/idle thresholds only flag candidates, but a still-needed app with constraints (compliance, dependencies) is retain, not retire.

AWS Migration Hub aggregates discovery data and migration status across applications into a single console, letting you track moves into any target Region from one place. You must choose a Migration Hub home Region before any write action, and all Application Discovery Service discovery and planning data is stored only in that home Region.

Trap Assuming discovery data lives in each migration's target Region. It is stored only in the single Migration Hub home Region, regardless of where workloads land.

AWS Application Discovery Service collects configuration, utilization, and dependency data about on-premises servers and databases and integrates with Migration Hub, where you group discovered servers into applications. You can export its performance and utilization data into a cost model and its server-to-server network connections to map dependencies for grouping.

Trap Reaching for Application Discovery Service to produce the migration cost business case. It collects raw on-prem inventory and dependency data, but Migration Evaluator is the service that builds the TCO/business case.

The Application Discovery Service Agentless Collector is an OVA appliance loaded into VMware vCenter that discovers all VMs and hosts and captures utilization (CPU, RAM, disk) without installing anything inside each guest. It cannot "look inside" a VM, so it does not see running processes or collect time-series data, and it is vCenter-only: it does not discover physical servers.

Trap Reaching for the Agentless Collector to inventory physical servers. It is vCenter-only; physical machines need the Discovery Agent or file-based import.

The Application Discovery Service Discovery Agent installs on each Windows or Linux server, including physical servers and not just VMware VMs, and additionally collects running processes, detailed time-series performance, and inbound/outbound network connections. Install it on the subset of servers where you need process-level dependency detail the Agentless Collector cannot provide.

Trap Assuming the Discovery Agent only works on VMware VMs like the Agentless Collector. The agent installs per-server on physical Windows/Linux hosts too and is how you cover non-VMware machines.

Pair the two discovery methods: the Agentless Collector inventories a large VMware estate quickly, while the Discovery Agent goes on the subset of servers needing process-level and time-series network-dependency data. Non-VMware physical servers require the agent (or file-based import) because the Agentless Collector is vCenter-only.

Trap Installing the Discovery Agent across the entire large VMware estate for breadth. The agentless OVA covers the whole estate quickly, and you reserve the per-server agent for the subset needing process-level depth.

AWS Migration Evaluator produces the total-cost-of-ownership business case that justifies a migration. It outputs Quick Insights (a fast projected Amazon EC2, EBS, and OS-license cost view over a one-year time frame) and a detailed Business Case report adding further cost models, Microsoft SQL Server license analysis, and Bring Your Own License (BYOL) modeling. It is the exam's answer for "justify migration spend" or "compare on-prem vs AWS cost."

Trap Using Application Discovery Service or Compute Optimizer to produce the migration cost business case. Discovery feeds raw data and Compute Optimizer rightsizes running AWS resources; Migration Evaluator is the dedicated TCO/business-case tool.

Migration Evaluator's collector is a single Windows Server VM using WMI, SNMP, vSphere, and T-SQL, no agents are deployed on the workloads, and you can instead supply existing inventory via flat files. It models x86 servers and attached block storage only; it does not support Solaris, AIX, other non-x86 devices, storage appliances, mainframes, or network devices.

Trap Picking Migration Evaluator to build a business case for an AIX, Solaris, or mainframe estate. Its collector models x86 servers and block storage only and cannot scope non-x86 platforms.

Migration Hub Strategy Recommendations analyzes server inventory, runtime environment, and application binaries (Microsoft IIS, Java Tomcat/JBoss), and, if you configure source access, source code and databases, to recommend a migration strategy of rehost, replatform, or refactor per application, each with a deployment destination, suggested tools, and an anti-pattern report. It is the service that names the strategy automatically rather than leaving you to assign each R by hand.

Trap Expecting Strategy Recommendations to also produce the cost business case. It names the per-app R (rehost/replatform/refactor) and tooling, while Migration Evaluator handles the TCO justification.

Sequence the portfolio by weighing business value against migration effort and risk: move high-value, low-effort, low-dependency applications first to prove the pattern and build momentum, then defer complex, tightly-coupled apps to later waves. Early wins de-risk the program before you tackle the hard, interdependent systems.

Trap Leading the program with the most complex, tightly-coupled flagship app for maximum impact. High-value low-effort apps go first to prove the pattern and de-risk before the hard interdependent systems.

Wave planning groups selected applications into batches (waves) migrated together, ordered by dependency, risk, and business priority. Dependency mapping from Application Discovery Service tells you which components are coupled, so tightly-linked applications move in the same wave and aren't split across separate cutovers.

Trap Sequencing waves purely by business priority and ignoring discovered dependencies. Splitting coupled components across cutovers breaks the application mid-migration.

Portfolio selection is discovery, assessment, the 7-Rs decision, TCO, and wave planning, deciding what to migrate and the strategy per app. The actual transfer (AWS Application Migration Service, AWS DMS, DataSync, Snow Family) is the separate migration-execution decision, so a "which tool moves the data" question belongs to execution, not selection.

Trap Answering a "which tool moves the servers/data" question with a selection service like Migration Evaluator or Strategy Recommendations. The actual transfer is execution (MGN, DMS, DataSync, Snow), a separate decision from selection.

Turning on data exploration (the StartContinuousExport API / Migration Hub console toggle) lands Discovery Agent data in an S3-backed Athena database, where predefined or custom SQL runs over process detail, server-to-server network connections, and time-series performance to find affinities for move groups. You can upload extra sources such as a CMDB export and connect Amazon QuickSight for BI reporting on the results.

Trap Expecting data exploration to query Agentless Collector output in Athena. It surfaces Discovery Agent data (process, network connections, time-series), which the agentless collector does not capture.

The AWS Schema Conversion Tool multiserver assessor takes a single CSV connections file of source database details plus candidate target engines and produces one aggregated CSV report. For each source-target pair it reports the percentage of code, storage, and syntax objects convertible automatically or with minimal change, plus a conversion-complexity score (1 = lowest to 10 = highest), the efficient way to choose the best target engine per database and build a prioritized roadmap before any conversion.

Trap Treating the SCT complexity score as a 1-to-10 scale where 1 is hardest. 1 is the lowest (easiest) conversion complexity and 10 is the highest.

Opt in to AWS Compute Optimizer from the Organizations management account and include all member accounts (this enables trusted access), then register a member account as the delegated administrator so rightsizing recommendations for every account are viewed and managed without using the management account day to day. The delegated admin sets recommendation preferences (such as enhanced infrastructure metrics) and member opt-in status, and can export recommendations to an S3 bucket as CSV for analysis in QuickSight.

Trap Opting in to Compute Optimizer from the delegated administrator account. The opt-in for the organization must happen from the management account, which then registers a member as delegated admin.