AWS Config EU Alternative 2026: Compliance Auditing, CLOUD Act, and GDPR

Post #710 in the sota.io EU Compliance Series

AWS Config includes a ready-made GDPR Conformance Pack. It contains 27 managed rules that check whether your AWS environment meets GDPR requirements: S3 encryption enabled, RDS not publicly accessible, CloudTrail logging active, access keys rotated. Your compliance team can point to a dashboard showing green checkmarks.

Here is the paradox: the tool proving your GDPR compliance is itself a GDPR problem.

AWS Config is operated by Amazon Web Services Inc. (US), subject to the CLOUD Act (18 U.S.C. § 2713). It continuously records every configuration change across your AWS resources — IAM policies, security group rules, S3 bucket permissions, RDS configurations, Lambda deployments. This creates a complete operational map of your data processing infrastructure, stored in US-controlled infrastructure, accessible to US law enforcement through a National Security Letter or FISA order.

Your GDPR compliance documentation lives in a service that can be compelled without your knowledge or consent.

What AWS Config Actually Records

AWS Config runs a configuration recorder that captures the complete state of every supported AWS resource type whenever it changes. For a typical production environment, this includes:

Identity and Access Management:

• Every IAM policy document (including the policy JSON with all permissions)
• Every IAM role trust relationship
• Every IAM user, group, and access key metadata
• Every service control policy in AWS Organizations

Network Configuration:

• Every security group rule (inbound and outbound, ports, CIDR ranges)
• Every VPC, subnet, route table, and network ACL configuration
• Every VPC endpoint (which services your VPCs connect to)
• Every Transit Gateway and VPC peering configuration

Data Storage:

• Every S3 bucket configuration (ACLs, bucket policies, encryption settings, versioning)
• Every RDS instance configuration (engine version, parameter groups, subnet groups, encryption state, master username)
• Every DynamoDB table configuration (billing mode, encryption, stream settings)

Compute:

• Every EC2 instance configuration (instance type, AMI, security groups, IAM instance profile, user data hash)
• Every Lambda function configuration (runtime, handler, environment variable names, VPC settings, IAM role)
• Every ECS cluster and service configuration

This is not just metadata. This is the complete operational blueprint of your data processing infrastructure. And every change to every resource is captured in a time-series history that AWS Config maintains indefinitely (by default, or until your specified retention period).

The CLOUD Act Exposure: More Than You Think

The immediate CLOUD Act concern is obvious: a US company holds your configuration data. But the depth of the exposure is worth examining carefully.

Configuration History = Operational Intelligence

A CLOUD Act order for your AWS Config data would yield:

1. Complete IAM history: Every permission change, every role creation, every policy modification. An investigator can reconstruct exactly who had access to what at any point in time — including access to personal data stored in your systems.

2. Data store configurations: Exact RDS instance configurations, including whether encryption was enabled and when it was enabled. S3 bucket policies showing which principals had access to which prefixes.

3. Network topology history: When was a security group opened? When was a VPC endpoint removed? When did you add encryption at rest?

4. Remediation trail: If you used Config Remediation to fix a compliance gap, Config records what was wrong and when it was fixed.

For an investigation into your data handling practices — a GDPR enforcement action, a breach investigation, a regulatory audit — this data is exactly what an investigator would want. Under CLOUD Act, US authorities can compel AWS to produce it.

The National Security Letter Problem

Unlike standard law enforcement requests that require court orders, National Security Letters (NSLs) can compel disclosure without judicial review and include a gag order preventing AWS from notifying you. Your complete infrastructure configuration history could be shared with US intelligence agencies without your knowledge.

This is not a GDPR-compliant data processing arrangement. GDPR Article 44 prohibits transfers of personal data to third countries without adequate protections — and your configuration data, which maps your personal data processing infrastructure, falls within scope.

The GDPR Conformance Pack Paradox

AWS Config's GDPR Conformance Pack evaluates rules like:

When Config evaluates these rules, it reads your resource configurations and stores evaluation results — including compliance findings — in AWS Config (US jurisdiction). Your compliance gaps (the RDS instance without encryption, the S3 bucket with public access) are recorded in US-controlled infrastructure before your DPO knows about them.

There is no Config rule for: "Is your configuration recorder a US company with CLOUD Act obligations?"

The GDPR Conformance Pack has a deliberate blind spot for the compliance of the compliance tool itself.

Multi-Account Config Aggregators: Centralized Risk

Like GuardDuty Organizations, AWS Config supports multi-account Aggregators that pull configuration data from all member accounts into a central aggregator account:

Management Account (Config Aggregator)
├── Account A (eu-west-1): All resource configurations
├── Account B (eu-central-1): All resource configurations
└── Account C (ap-southeast-1): All resource configurations

A single CLOUD Act order against the management account yields the complete configuration history for your entire AWS organization — all accounts, all regions, all resource types.

For enterprises with dozens of AWS accounts, this represents a complete operational map of every system that processes EU personal data, centralized in a single US-controlled location.

Config Remediation: Trust Boundary Concerns

AWS Config Remediation Actions execute code in your account to fix compliance issues automatically. When you configure automatic remediation:

1. Config detects a non-compliant resource
2. Config triggers an SSM Automation document (managed by AWS)
3. The automation executes API calls in your account
4. Config records the remediation result

The entity evaluating your GDPR compliance (AWS Config) is also the entity with code execution authority in your account (via SSM Automation). For GDPR-regulated workloads, this means your compliance enforcement mechanism is operated by a party subject to CLOUD Act compelled disclosure.

If Config is compelled to produce records, the remediation history — what was wrong, when it was fixed, what code ran to fix it — is part of that production.

Config Advanced Queries: PII in Resource Metadata

Config Advanced Queries use SQL to interrogate your resource inventory:

SELECT
  configuration.dbInstanceIdentifier,
  configuration.masterUsername,
  configuration.endpoint.address,
  configuration.storageEncrypted
FROM
  AWS::RDS::DBInstance
WHERE
  configuration.storageEncrypted = false

These queries and their results are processed by AWS Config. The problem is that resource identifiers and tags frequently contain PII or sensitive metadata:

• rds-prod-eu-user-profiles (contains "user" — identifies the data subject scope)
• s3-eu-healthcare-records-2026 (clearly identifies data category)
• lambda-process-patient-data (identifies special category data processing)
• Resource tags like DataClassification: GDPR-Sensitive or DPAReference: contract-123

When Config queries this metadata, it processes data that maps your GDPR Article 30 Records of Processing Activities. That mapping is then stored under US jurisdiction.

EU Alternatives to AWS Config

1. Steampipe + steampipe-mod-aws-compliance (Recommended for Quick Migration)

Steampipe is an open-source SQL query engine for cloud APIs. The AWS Compliance mod includes pre-built GDPR checks.

# Install Steampipe
sudo /bin/sh -c "$(curl -fsSL https://steampipe.io/install/steampipe.sh)"

# Install AWS plugin
steampipe plugin install aws

# Run GDPR benchmark
steampipe check benchmark.gdpr

# Run specific check
steampipe check control.s3_bucket_default_encryption_enabled

Deploy Steampipe on an EC2 instance in eu-central-1 or eu-west-1. The tool runs locally, queries AWS APIs from your EU network, and stores results in a local PostgreSQL database you control. No configuration data leaves your infrastructure.

Steampipe vs. AWS Config:

2. CloudQuery (Open Source Cloud Asset Inventory)

CloudQuery transforms cloud APIs into queryable relational databases. Deploy it in EU infrastructure, sync to a PostgreSQL database in eu-central-1, and query with standard SQL.

# cloudquery.yml
kind: source
spec:
  name: aws
  path: cloudquery/aws
  version: "v25.0.0"
  destinations: ["postgresql"]
  spec:
    regions:
      - eu-west-1
      - eu-central-1
    tables:
      - aws_iam_policies
      - aws_iam_roles
      - aws_s3_buckets
      - aws_rds_instances
      - aws_ec2_security_groups
      - aws_lambda_functions

kind: destination
spec:
  name: postgresql
  path: cloudquery/postgresql
  spec:
    connection_string: "postgresql://user:pass@eu-postgres.internal:5432/compliance"

Run CloudQuery as a scheduled job on an EC2 instance in the EU region. Your configuration inventory lives in a PostgreSQL database you control, never leaving EU jurisdiction.

CloudQuery supports incremental syncs, giving you a change history equivalent to AWS Config's time-series recording — hosted entirely in your infrastructure.

3. Open Policy Agent (OPA) for Continuous Compliance

OPA provides policy evaluation without any cloud dependency. Use it as a Kubernetes admission controller or in CI/CD pipelines to enforce compliance rules before resources are deployed.

# policies/gdpr_compliance.rego
package aws.gdpr

import future.keywords.if
import future.keywords.in

# Deny unencrypted RDS instances
deny[msg] if {
  input.type == "aws_db_instance"
  not input.values.storage_encrypted
  msg := sprintf(
    "RDS instance '%v' must have encryption enabled (GDPR Art. 32)",
    [input.values.identifier]
  )
}

# Deny S3 buckets without encryption
deny[msg] if {
  input.type == "aws_s3_bucket"
  count([e | e := input.values.server_side_encryption_configuration[_]; e]) == 0
  msg := sprintf(
    "S3 bucket '%v' must have default encryption (GDPR Art. 32)",
    [input.values.bucket]
  )
}

# Deny public S3 buckets
deny[msg] if {
  input.type == "aws_s3_bucket_acl"
  input.values.acl == "public-read"
  msg := sprintf(
    "S3 bucket '%v' must not be publicly accessible (GDPR Art. 25 - Data Protection by Design)",
    [input.values.bucket]
  )
}

OPA evaluates policies locally. No configuration data is sent anywhere. Integrate with Terraform via Conftest:

# Evaluate Terraform plan against GDPR policies
terraform plan -out=tfplan
terraform show -json tfplan | conftest test --policy policies/ -

4. Prowler (Open Source AWS Security Assessments)

Prowler is a comprehensive AWS security assessment tool with built-in GDPR compliance checks. Run it entirely within your AWS account in an EU region.

# Install Prowler
pip install prowler

# Run GDPR compliance checks
prowler aws --compliance gdpr_aws \
  --region eu-central-1 \
  --output-formats json-ocsf html \
  --output-directory /opt/compliance-reports/

# Run specific service checks
prowler aws --service s3 rds iam \
  --compliance gdpr_aws \
  --region eu-west-1

Prowler runs as a CLI tool from any EC2 instance in the EU. Schedule it via EventBridge Scheduler in eu-central-1 and store reports in an S3 bucket with SSE-KMS encryption in your EU account.

Prowler covers 400+ checks across AWS services, with specific GDPR mappings for each finding.

5. Wazuh SCA (Security Configuration Assessment)

Wazuh (mentioned in our GuardDuty and CloudTrail posts) also provides Security Configuration Assessment capabilities. The SCA module evaluates system and cloud configurations against CIS benchmarks and custom policies.

For AWS-native configuration assessment, combine Wazuh SCA with a Steampipe or CloudQuery data feed — Wazuh handles alerting and incident correlation, while Steampipe/CloudQuery handles the compliance data collection.

Migration Strategy: AWS Config → EU-Native Compliance

Phase 1: Audit Current Usage (1-2 days)

Before migrating, understand what you are actually using:

# List all active Config rules
aws configservice describe-config-rules \
  --region eu-central-1 \
  --query 'ConfigRules[*].{Name:ConfigRuleName,Source:Source.Owner}'

# List Conformance Packs
aws configservice describe-conformance-packs \
  --region eu-central-1

# Check remediation configurations
aws configservice describe-remediation-configurations \
  --config-rule-names $(aws configservice describe-config-rules \
    --query 'ConfigRules[*].ConfigRuleName' --output text)

Export the complete list of rules and map each one to its Prowler check ID or Steampipe control.

Phase 2: Parallel Deployment (2-4 weeks)

Deploy Steampipe or CloudQuery in eu-central-1 alongside AWS Config. Run both for 2-4 weeks to validate that your EU-native stack produces equivalent findings.

Use this period to:

• Tune alert thresholds
• Build custom OPA policies for organization-specific requirements
• Train your security team on the new tooling

Phase 3: Cutover and Config Disablement

Once parity is validated:

1. Disable the Config recorder in EU regions (this stops new configuration snapshots)
2. Export existing Config history to S3 in EU region for archive purposes
3. Delete Config rules and Conformance Packs
4. Schedule Prowler via EventBridge in eu-central-1
5. Deploy CloudQuery for continuous configuration inventory
6. Document the new compliance stack in your Article 30 Records of Processing Activities

# Disable Config recorder
aws configservice stop-configuration-recorder \
  --configuration-recorder-name default \
  --region eu-central-1

# Delete all Config rules before disabling
aws configservice delete-config-rule \
  --config-rule-name "s3-bucket-server-side-encryption-enabled"

The Article 30 Irony

GDPR Article 30 requires controllers to maintain Records of Processing Activities (RoPA) — documentation of what personal data you process, where, with what safeguards. AWS Config is essentially a technical RoPA: a machine-readable, time-series record of your data processing infrastructure and its security controls.

The irony is complete: the technical system you use to document GDPR compliance is itself the GDPR compliance gap.

Your Article 30 records should document where your AWS Config data is processed (US), under what legal basis (Article 6(1)(f) legitimate interests?), and what the transfer mechanism is (AWS DPA, SCCs). Most organizations using AWS Config for GDPR compliance monitoring have not done this analysis.

The EU-native alternatives in this guide let you build a compliance monitoring stack where the monitoring infrastructure itself is GDPR-compliant — where your compliance records live in your jurisdiction, under your control, not accessible to foreign law enforcement.

Summary

The clearest migration path: CloudQuery (for continuous configuration inventory with change history, equivalent to AWS Config's core capability) combined with OPA/Conftest (for policy enforcement in CI/CD) and Prowler (for periodic compliance reporting). Deploy all three in eu-central-1. Your compliance monitoring stack is then entirely under EU jurisdiction, with no CLOUD Act exposure.

Running AWS Config in EU regions? sota.io provides EU-native managed PaaS — deploy your workloads on infrastructure that is jurisdictionally clean from day one, without navigating CLOUD Act exposure for each AWS service you adopt.