Three-tier app: web, app, DB. DB must be unreachable from the internet under any circumstance.
→Public subnets for web tier (ALB). Private subnets for app and DB tiers. DB security group allows traffic only from the app-tier security group (not from CIDR ranges).
Why: Subnet routing tables enforce reachability; security-group-to-security-group references encode least-privilege at the SG layer and survive IP changes.
Reference↗
EC2 instance needs to access S3. Avoid embedded credentials.
→IAM role attached via instance profile. SDK retrieves temporary credentials from IMDSv2.
Why: Long-lived access keys on instances are the #1 cause of credential leaks. Roles rotate automatically, never persisted.
Reference↗
Block SSRF attacks that try to read EC2 instance metadata.
→Enforce IMDSv2 (`HttpTokens=required`) at instance launch. Reject IMDSv1 unauthenticated requests.
Why: IMDSv2 requires a session token via PUT before the metadata endpoint responds; SSRF attacks that only do GETs are blocked.
Reference↗
Service A in Account A invokes Lambda in Account B. Least privilege.
→Resource-based policy on the target Lambda granting `lambda:InvokeFunction` to Account A's role principal. Caller assumes its own role and invokes directly — no role chaining needed.
Why: Resource policies are the simplest cross-account pattern for service-fronted resources (Lambda, S3, SNS, SQS, KMS).
Reference↗
Other AWS accounts need to upload to a central S3 bucket.
→Bucket policy granting `s3:PutObject` to external account principals. Add `bucket-owner-full-control` ACL requirement so the bucket owner retains control of objects.
Why: Without `bucket-owner-full-control` (or `BucketOwnerEnforced` Object Ownership), uploaded objects are owned by the writer account.
Reference↗
Prevent any S3 bucket in the org from being made public.
→Enable S3 Block Public Access at the account level (and Organizations-wide via SCPs). Overrides bucket-level ACLs and policies.
Why: Account-level setting wins over per-bucket settings — defense against accidental misconfiguration.
Reference↗
Developers must self-serve IAM roles but cannot grant beyond a defined max-permission set.
→Permission boundaries on the developer principal. Effective permissions = identity policy ∩ boundary.
Why: SCPs apply at the account/OU level; boundaries scope individual principals. Use boundaries for delegated admin patterns.
Reference↗
Restrict an OU to specific Regions for data-residency compliance.
→Service Control Policy in Organizations denying any action where `aws:RequestedRegion` is not in the allowed list.
Why: SCPs are the only mechanism that can deny actions the account itself permits. IAM cannot deny what an account-root could grant.
Reference↗
Workforce single sign-on across many AWS accounts; integrate with corporate IdP.
→AWS IAM Identity Center (formerly AWS SSO) with SAML/OIDC federation to the corporate IdP. Permission sets map to roles in member accounts.
Why: Identity Center is the canonical multi-account workforce identity. Cognito is for application end users, not employees.
Reference↗
Pick Cognito User Pool vs Identity Pool.
→User Pool = sign-up / sign-in / JWT issuance for app users. Identity Pool = exchange tokens for temporary AWS credentials. Most apps use both: User Pool authenticates, Identity Pool authorizes AWS access.
Reference↗
Add custom validation step to Cognito sign-in (e.g. allowlist email domain).
→Lambda triggers: Pre Sign-up, Pre Authentication, Define/Create/Verify Auth Challenge. Validate or reject in the Lambda.
Reference↗
Need full control over key rotation, deletion, and per-key audit trail.
→Customer-managed KMS key (CMK). AWS-managed keys (`aws/<service>`) are simpler but offer no key-policy control or visibility into individual key usage.
Why: CMKs let you scope access per key in CloudTrail, set key policies for cross-account use, and disable/schedule deletion.
Reference↗
Account B needs to decrypt S3 objects encrypted with Account A's CMK.
→Key policy on the CMK grants `kms:Decrypt` to Account B principals. Account B's IAM also needs `kms:Decrypt` on the key ARN. Both halves required.
Why: KMS cross-account requires explicit allow on both the key policy and the caller IAM identity (unlike most resource policies).
Reference↗
Encrypt data in `us-east-1`; decrypt in `us-west-2` after replication, without re-encrypting.
→KMS multi-region key. Primary in one Region, replica in another, both with the same key material and ID.
Why: Avoids the ciphertext re-wrap dance for cross-Region failover or DR.
Reference↗
Encrypt large objects without per-object KMS API calls dominating cost.
→Envelope encryption. KMS generates a data key (one API call); use the data key to encrypt the payload locally; store encrypted-data-key alongside the ciphertext.
Why: KMS is rate-limited and priced per request. Envelope pattern is the canonical way to encrypt data > a few KB.
Reference↗
Pick Secrets Manager vs SSM Parameter Store SecureString.
→DB credentials with automatic rotation, cross-account share, large secrets → Secrets Manager. Config flags, app settings, simple secrets, lowest cost → SSM Parameter Store.
Why: Secrets Manager has built-in rotation Lambdas for RDS/Aurora/DocumentDB/Redshift; Parameter Store has no native rotation but is free for Standard tier.
Reference↗
Rotate RDS password automatically every 30 days.
→Secrets Manager with managed rotation. Built-in Lambda template handles single-user rotation against the RDS endpoint. Apps fetch the secret at connect time (cached) — no app redeploy.
Reference↗
Mitigate Layer 7 HTTP flood without blocking legitimate spikes.
→AWS WAF rate-based rule (e.g. 2000 requests / 5 min per IP) on the ALB or CloudFront. Combine with managed rule groups for known-bad IPs.
Why: WAF rate rules track per-source-IP; auto-block when threshold exceeded; release after the window.
Reference↗
Mission-critical app needs DDoS cost-protection and 24×7 SRT support.
→AWS Shield Advanced on CloudFront / ALB / NLB / Global Accelerator. Includes cost protection (refunds for scaling spend during attack) + Shield Response Team access.
Why: Shield Standard is automatic and free; Advanced adds protections and SLA. CloudFront is always the recommended front door.
Reference↗
Pick security group vs NACL.
→Stateful, attach to ENI, allow-only → security group (default). Stateless, subnet-level, allow + explicit deny → NACL. Use NACLs for blanket deny rules (block IP ranges); SGs for everything else.
Why: NACLs evaluate inbound and outbound separately. SGs auto-allow return traffic.
Reference↗
EC2 in private subnet must reach S3/DynamoDB without NAT egress cost.
→VPC gateway endpoint for S3 and DynamoDB. Free, route-table entry, no NAT.
Why: Gateway endpoints are S3/DynamoDB only. Saves NAT data-processing charges and keeps traffic on the AWS backbone.
Reference↗
Private subnet must reach AWS service APIs (KMS, Secrets Manager, ECR, etc.) privately.
→VPC interface endpoint (PrivateLink) per service. ENI in your VPC, charged per hour + per GB.
Why: Interface endpoints work for almost every AWS service. Use to remove NAT egress for service calls.
Reference↗
SaaS provider exposes its in-VPC service to customer accounts privately, without VPC peering or maintaining customer routing.
→AWS PrivateLink endpoint service backed by an NLB. Customers create interface endpoints to consume.
Why: No CIDR overlap concerns, no peering meshing, one-way exposure (provider sees no customer traffic).
Reference↗
Connect 30+ VPCs across accounts and on-premises in a hub-and-spoke topology.
→AWS Transit Gateway. Single attachment per VPC; route tables segment traffic.
Why: Full-mesh peering requires N×(N-1)/2 connections. TGW scales linearly and supports cross-account via RAM.
Reference↗
Hybrid connectivity that needs predictable bandwidth, low latency, and encryption.
→Direct Connect with a Site-to-Site VPN over the DX (MACsec or IPsec). DX alone is unencrypted; VPN over DX is private + encrypted + low-jitter.
Why: Plain VPN over internet is cheap but has variable latency. DX alone is fast but plaintext at the link layer.
Reference↗
Continuous threat detection across VPC Flow Logs, DNS, CloudTrail, EKS audit, S3 data events.
→Amazon GuardDuty. Org-wide via Organizations delegated admin.
Why: Managed threat-detection. Findings into Security Hub or EventBridge for response automation.
Reference↗
Discover and classify PII / PHI in S3 buckets.
→Amazon Macie. ML-based sensitive-data discovery, S3-scoped, integrates with Security Hub.
Reference↗
Continuous CVE scanning for EC2, ECR images, Lambda functions.
→Amazon Inspector v2. Auto-discovers resources via Systems Manager Agent, scans against published CVEs.
Reference↗
Aggregate findings from GuardDuty, Inspector, Macie, IAM Access Analyzer into one dashboard.
→AWS Security Hub. CSPM with AWS Foundational Security Best Practices and CIS standards.
Reference↗
Enforce that all EBS volumes are encrypted; remediate non-compliant resources automatically.
→AWS Config rules (managed `encrypted-volumes`) + Systems Manager Automation runbook for remediation, triggered via Config remediation action.
Reference↗
Single tamper-proof audit log across all accounts in the org.
→Organization trail with log-file validation enabled, written to a central S3 bucket with bucket policy denying delete.
Why: Org trails auto-enable in all member accounts (current and future). Validation hashes prove logs weren't modified.
Reference↗
Multiple departments need scoped access to different prefixes in a shared S3 bucket.
→S3 Access Points — one per department, each with its own access policy and (optionally) VPC restriction.
Why: Cleaner than a sprawling bucket policy; access points have their own ARNs and DNS names.
Reference↗
PCI DSS workload — strict isolation from non-PCI accounts.
→Dedicated AWS account inside an Organizations OU with SCPs restricting service / region access. Separate VPC, KMS keys, IAM roles. Network Firewall or GWLB for egress inspection.
Why: Account boundary is the strongest blast-radius isolation in AWS.
Reference↗
Public TLS cert for `*.example.com` on ALB and CloudFront. Renew automatically.
→AWS Certificate Manager (ACM) public certificate with DNS validation in Route 53. Auto-renews 60 days before expiry.
Why: Free for use with AWS-integrated services. Email validation works but DNS validation is preferred for automation.
Reference↗