aws-cloudlisted

# AWS Cloud Patterns Pick the lightest service that meets the SLA and the lowest-blast-radius IAM policy that gets the job done. AWS rewards restraint — the default footgun is over-provisioning, the second is wide-open IAM. ## When to Activate - Designing AWS infrastructure (IaC or console) - IAM policy review or scoping a new role - Picking between Lambda / Fargate / EC2 / App Runner - S3 access patterns (signed URLs, lifecycle, replication, classes) - RDS / Aurora connection pooling, IAM auth, failover - Diagnosing CloudWatch logs/metrics, X-Ray traces - Bill spikes or pre-launch cost review ## IAM: Least Privilege The two rules that prevent 90% of incidents: 1. **No wildcards in `Action` AND `Resource` together.** Pick one to scope. 2. **Roles, not access keys.** Every long-lived key is a future leak. ```json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/uploads/*" }] } ``` - Use **IAM Identity Center (SSO)** for humans, **IAM roles** for workloads. - For local dev: `aws configure sso` + short-lived creds (`aws sso login`). - For CI: OIDC trust policy → no static keys in GitHub Actions. - **Permissions Boundaries** cap what a role can ever do, regardless of attached policies. Use them on developer-managed roles. - Run **IAM Access Analyzer** before merging policy changes — it surfaces external access and unused permissions. ## S3 Patterns ```pytho