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. We needed to bring more AWS services into that evidence path without creating a separate ingestion approach for each one.

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 describing the resource data, connectors that retrieved it, transformer logic that normalized it, and unit tests for the resulting behavior.

The important constraint was fitting the existing extractor framework. The compliance side needed a consistent way to consume each stream, but the resources themselves were different. Normalizing the data could not mean discarding the service-specific details that a control check would need.

Outcome

• New AWS resource streams joined automated evidence collection through the shared extractor framework.
• The compliance product could consume those streams through the bridge's existing extraction and transformation conventions.

I worked within the bridge's established architecture, extending its Go implementation to cover these resources. The judgment was in deciding what belonged in the common contract and what needed to remain specific to each AWS service.