I'm building a tool that scans a live AWS account for misconfigurations, and testing the integration points has been harder than writing the detection logic. I want to avoid repeatedly calling real AWS from CI, but mocking every response can make the tests unrealistic. Moto works well for simple cases, though some checks involve multiple services—for example, cross-referencing an EC2 instance's security group with the ports it actually exposes. What approach has worked best for you: Moto, LocalStack, a disposable AWS test account, record-and-replay fixtures, or something else?
3 Answers
A combination tends to work well: use Moto for fast unit tests around individual API calls, then use LocalStack or a dedicated development environment for workflows that span multiple services. That gives you realistic integration coverage without sending every CI run to AWS.
If you need high confidence in AWS-specific behavior, keep a small disposable test account for a limited integration-test suite. Run those tests less frequently and use mocked or emulated services for the normal CI path. Tools such as ScoutSuite can also be worth studying if you’re implementing account-auditing checks, since they provide patterns for gathering and correlating AWS data.
For cases where setting up a whole simulated environment is too much, record-and-replay tools such as Placebo can capture boto3 interactions and replay them in tests. It’s useful when you need stable, realistic responses from a complicated sequence of calls, though it won’t catch behavior that depends on live service semantics.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically