AWS managed policies are fine. Don’t spend days crafting least-privilege policies when your team is 3 people and you’re iterating daily. Use PowerUserAccess (no IAM admin) for developers.
Skip Identity Center until you have 5+ engineers. Below that, IAM users with MFA and forced credential rotation is pragmatic. The setup cost of Identity Center + IdP isn’t worth it for 2-3 people.
One AWS account is fine. Multi-account is best practice but overkill when you’re pre-revenue. Add a second account (prod) when you have paying customers.
Set up Identity Center now. You’ve delayed long enough. Connect to Google Workspace or Okta (whichever your company already uses).
Separate prod account. If you haven’t done this yet, do it before your next compliance audit.
Use Access Analyzer. Generate policies from CloudTrail activity to replace overly broad managed policies. Takes 30 minutes, saves you in your SOC2 audit.
Permission boundaries for senior devs who need to create IAM roles (for Lambda, ECS). Prevents accidental privilege escalation.
AdministratorAccess for the founding engineer is OK at seed stage. The blast radius is one account with no customers. Velocity matters more than least privilege when you’re proving the idea works. Add guardrails when you add the 4th engineer.
Don’t implement SCPs until you have 3+ accounts. SCPs on a single-account org do nothing useful but add debugging complexity.
Managed policies > custom policies until SOC2. Your custom policies will have bugs. AWS managed policies are tested and maintained. Switch to custom when compliance requires it or when you need to restrict specific resources.
Skip IAM Access Analyzer findings in dev accounts. Cross-account access in your dev account is not a security incident. Focus Access Analyzer on prod only.