InfraGuard

InfraGuard scans AWS accounts across regions for common security misconfigurations and reports the findings through an API and alerts.

What it checks

S3 buckets (public access), EC2 instances (open SSH/RDP ports), NACL rules, load balancers, IAM users and roles (MFA, admin access), RDS (public access, encryption, backups), and CloudTrail setup.

How a scan runs

The API enqueues a scan in Redis and returns immediately. A worker picks it up, marks it running, runs the scanners, stores findings in PostgreSQL, sends alerts to Slack or Telegram, and marks the scan as successful. Each AWS service has its own scanner module with the same shape: fetch resources with boto3, apply checks, and emit findings with a resource, region, severity and status. Regions are scanned in parallel with a thread pool. Adding a new check means adding one module.

Failure handling

Execution is at-least-once. A failed scan is retried up to three times, with delays of 30, 60 and 120 seconds, before it is marked as failed. Because a retry can repeat work, findings are deduplicated by a hash at the database level, so a retry never creates duplicates. Findings are tracked through their lifecycle, from open to resolved. Only one scan runs at a time, and scans left stuck by a crashed worker are marked as failed instead of hanging forever.

Trade-offs

Allowing one scan at a time limits throughput but keeps consistency simple. There is no distributed locking: the design relies on database checks instead. Scanning many regions in parallel can run into AWS API rate limits, and scanning is batch-only, not real-time.

Stack

FastAPI · PostgreSQL · Redis (RQ) · SQLAlchemy · boto3 · Docker