Cloud
Guardrails

Aggressively use accounts as your permissions and blast radius boundary.

When designing your account structure and connectivity for all your cloud applications.

Prevent public bucket exposure by enabling public access block.

Always applies

Rotate IAM access keys where IAM users are still required

To IAM users

Enable access logs for all load balancers.

When using ELB / ALB / NLB

Limit the creation of new IAM users, and prefer using IAM roles when possible.

Always

Avoid time windows that are potentially sensitive (night/weekend/holidays) for making changes to critical resources.

Always

Configure CloudTrail to log to a bucket in a central account with specific prefixes based on the application or role sending them.

Always

Require DynamoDB to have a backup enabled for DR.

To all important data in DynamoDB

Require approval of changes for accounts or regions with sensitive infrastructure.

Companies should have a multi-account and/or multi-region strategy before adopting this

Avoid Cloudfront AllowedMethods beyond GET HEAD and OPTIONS.

Possibly mitigated by Cloudfront domain validation

Use an account per region to avoid having a single account take down your application.

When you need extremely high availability application setup

Restrict OIDC integrations so you don't have backdoor or rogue access.

Always

Centralize identities into a single account.

Companies that have a multi-account strategy should generally adopt this pattern

Enforce naming conventions for storage buckets with a unique prefix to avoid collisions.

Always

Require TTL on CloudWatch logs

All scaled usage of CloudWatch

Limiting engineers' access to production environments by managing infrastructure through Infrastructure as Code (IaC), enforcing identity-based changes, multi-party approval, MFA, and security linting helps ensure accountability, consistency, and reduces security risks.

Applies when a robust IaC CI/CD workflow is in place

Service owners don't need admin permissions, and should be given a minimal set of permissions as-necessary (e.g. read-only).

When service teams own their accounts

Avoid throttling issues from multiple AWS describe calls by fostering solutions that collect data once, share it across tools, and store it in a centralized system like AWS Config or a data warehouse for efficient reporting.

Always

When designing your account structure and connectivity for all your cloud applications.