You think your AWS CLI-style profiles are working the same in staging as they will in production. They aren’t. They never do. And unless you’re running real integration tests across those profiles, you’re shipping blind.
AWS CLI profiles let you switch between accounts and roles with ease. One command, a new identity, a new environment. But when your code depends on multiple profiles—especially with different access patterns, permissions, or regions—local tests won’t cut it. You need integration tests that run with the same credentials, the same policy boundaries, and the same execution paths your production workloads use.
The first step is mapping your AWS CLI config. Every [profile name] section should be real, active, and aligned with an IAM user or role in an account that matches your deployment. No placeholders. No disabled keys. Then, ensure each profile's credentials work in isolation before chaining them in your test suite.
For integration testing AWS CLI-style profiles, avoid building mocks for key AWS services. They hide latency differences, permission edge cases, and inter-profile trust relationships. Use actual AWS accounts, linked or separate, to expose real-world issues. Test switching between profiles within the same workflow—STS assume-role calls, cross-account S3 access, and Lambda invocations from different accounts—exactly as production does.