AWS SAP Specialty cheat sheet

AWS Organizations: SCPs set the maximum permissions for member accounts but grant nothing themselves; an action must be allowed by both the SCP and the identity/resource policy.

SCP evaluation: the effective permission is the intersection of every SCP in the path from root to account; a Deny at any level wins, and FullAWSAccess must remain attached or all actions are blocked.

Consolidated billing: all accounts roll up to the management account for volume discounts and Reserved Instance/Savings Plan sharing, but the management account should hold no workloads.

Cross-account access pattern: trust policy on the target role names the source account or role; the caller then needs sts:AssumeRole plus a role switch, and external IDs guard third-party access.

Resource control policies (RCPs) constrain resource-based access at the organization level, complementing SCPs which constrain principal-side permissions.

AWS Control Tower: landing zone = Log Archive + Audit accounts, OU structure, and guardrails; preventive guardrails are SCPs, detective guardrails are AWS Config rules.

VPC sharing via AWS RAM: the owner account controls subnets, route tables, and gateways; participants can deploy resources into shared subnets but cannot modify shared networking.

Centralized egress/inspection: Transit Gateway hub-and-spoke with a shared services VPC, or AWS Network Firewall in an inspection VPC, avoids per-VPC NAT gateways.

Identity federation: IAM Identity Center with permission sets assigned to groups and OUs is preferred over per-account IAM users; SAML/OIDC federation maps external identities to roles via sts:AssumeRoleWithSAML/WithWebIdentity.

Multi-AZ vs multi-Region: multi-AZ targets RTO in minutes with synchronous replication inside a Region; multi-Region (active-active or warm standby) targets Region-scale failure at higher cost and complexity.

RTO/RPO drive the DR strategy ladder: Backup & Restore (hours, RPO hours) < Pilot Light < Warm Standby < Multi-Site Active/Active (near-zero RPO).

Decoupling: SQS standard queues give at-least-once delivery and best-effort ordering; FIFO queues give exactly-once processing and strict order at lower throughput.

Event-driven: EventBridge for routing/filtering and SaaS integration; SNS for fan-out push; SQS for buffering. Use the idempotency key pattern for duplicate-safe consumers.

Compute selection: Lambda for short, event-driven, spiky workloads (15-minute max); Fargate for containers without server management; EC2 for steady, specialized, or long-running workloads.

Storage selection: S3 for object/static, EBS for block attached to one AZ, EFS for shared POSIX NFS across AZs, FSx for Windows/Lustre/NetApp/OpenZFS specialized needs.

Database selection: Aurora for high-throughput relational with read replicas and Global Database; DynamoDB for single-digit-ms key-value at any scale; Redshift for OLAP; ElastiCache for sub-ms caching.

Security by design: least-privilege IAM, KMS customer-managed keys with rotation, VPC endpoints (PrivateLink) to keep traffic off the internet, and Secrets Manager for credentials.

Well-Architected pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability; trade-offs must be documented per workload.

CloudWatch metrics are 1-minute basic / high-resolution down to 1 second; alarms support OK/ALARM/INSUFFICIENT_DATA states and composite alarms to reduce noise.

Auto Scaling policies: target tracking maintains a metric at a target (simplest, preferred); step scaling reacts to alarm breaches with tiered adjustments; scheduled scaling handles known traffic patterns.

Rightsizing signals: CloudWatch CPU/memory, Compute Optimizer recommendations, and Trusted Advisor checks; memory requires the CloudWatch agent because it is not a default metric.

Cost levers: Savings Plans for compute flexibility, Reserved Instances for specific instance families, Spot for fault-tolerant batch, S3 lifecycle transitions to cheaper storage classes.

AWS Config conformance packs and Security Hub standards give continuous compliance scoring; remediation via SSM Automation documents triggered by Config rules.

Observability: X-Ray for distributed tracing and service maps, CloudWatch Logs Insights for querying, and embedded metric format for custom metrics from logs.

Blue/green and canary deployments via CodeDeploy or Lambda aliases with weighted traffic; automatic rollback on CloudWatch alarm thresholds.

Performance tuning: ElastiCache read-through caching, Aurora reader endpoints, DynamoDB adaptive capacity and on-demand mode, and CloudFront for edge caching.

Resilience testing: AWS Fault Injection Service (FIS) runs controlled experiments; game days validate failover and runbooks before real incidents.

The 7 Rs: Retire, Retain, Rehost (lift-and-shift), Relocate (hypervisor-level, e.g., VMware Cloud on AWS), Replatform (lift-tinker-and-shift), Repurchase (SaaS), Refactor/Re-architect.

AWS Migration Hub tracks migrations across tools; Application Migration Service (MGN) replicates servers continuously and launches test/cutover instances for rehost.

Database Migration Service (DMS) with Schema Conversion Tool (SCT) handles heterogeneous migrations; DMS continuous replication (CDC) enables near-zero-downtime cutover.

Data transfer: Snowball Edge for large offline transfers, DataSync for online file/NFS/S3 movement with scheduling and verification, Storage Gateway for hybrid access.

Discovery and assessment: Migration Evaluator (TCO), Application Discovery Service (agentless/agent-based) to map dependencies before wave planning.

Wave planning: group applications by dependency and business priority; migrate low-risk, low-dependency apps first to build the landing zone and runbooks.

Modernization path: monolith to containers (ECS/EKS) to serverless; strangler-fig pattern peels functionality incrementally while the legacy system keeps running.

Cutover validation: compare row counts and checksums, run parallel verification, and keep rollback paths (snapshots, replication reversal) until sign-off.

Landing zone readiness precedes migration: accounts, networking, logging, and guardrails must exist before waves begin, or rework compounds.