AWS Compliance Data Bridge

Overview

Some compliance evidence depends on cloud-resource state: which resources exist, how they are configured, and whether the configuration can support a control check. The harder product question was whether new resource streams could join the evidence path without creating one-off ingestion code for every service.

I extended a Go-based compliance data bridge so AWS resource evidence could flow through shared extractors and transformers.

What I built

I added AWS extractors and transformers for DocumentDB, RDS, EKS, and GuardDuty. The work covered JSON schemas, connector wiring, transformer logic, and unit tests.

The important constraint was fitting the existing extractor framework. Each resource stream needed to produce a shape the compliance side could consume without special casing every service. That meant keeping the data contract clear enough for automated evidence collection, while still preserving the details that made each AWS resource type useful.

Scope

The scope was deliberately narrow: extend the bridge in Go and keep the additions inside the existing framework. Schemas described the resource shape, connectors pulled the source data, transformers normalized it, and tests made the contract explicit.

Outcome

• New AWS resource streams joined automated evidence collection through the shared extractor framework.
• Schema, connector, transformer, and test work kept the additions reviewable instead of becoming one-off ingestion paths.
• The project gave Automated Compliance another source path for cloud-resource evidence.

The technical lesson was mostly about restraint. The bridge already had a framework; my job was to extend it in the shape it wanted instead of inventing a parallel path for each AWS service.