AWS API Gateway EU Alternative 2026: Request Logs, CLOUD Act, and GDPR Compliance

Post #706 in the sota.io EU Compliance Series

AWS API Gateway is the front door to almost every serverless AWS application. When developers build REST or HTTP APIs backed by Lambda functions, DynamoDB, or ECS containers, API Gateway is typically the layer that receives requests from EU users, validates them, and routes them to backend services. It handles authentication, rate limiting, SSL termination, and request transformation. It also, by design, records information about every request that passes through it.

Those records — access logs, execution logs, usage plan data — sit under US jurisdiction via the CLOUD Act.

Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) compels US companies to produce data stored anywhere in the world when served a valid US government order. API Gateway deployed in eu-west-1 (Ireland) or eu-central-1 (Frankfurt) is AWS infrastructure controlled by a US entity. The location of the data center does not determine CLOUD Act applicability — the controlling entity's jurisdiction does.

For EU applications, every API request from every EU user generates an access log entry under US jurisdiction. The access log entry contains, at minimum, the user's IP address — which is personal data under GDPR. Depending on your access log format, it may also contain request paths with embedded user identifiers, query parameters with search terms or filter values, API key identifiers that map to specific customers, and request IDs that link to backend processing records.

What AWS API Gateway Stores Under US Jurisdiction

Access Logs: The IP Address Problem at Scale

API Gateway supports custom access logging to CloudWatch Logs or Kinesis Data Firehose. Access logs are the structured record of every API request: who sent it, when, from where, and what they requested.

A typical API Gateway access log entry using the $context variable set contains:

{
  "requestId": "$context.requestId",
  "ip": "$context.identity.sourceIp",
  "caller": "$context.identity.caller",
  "user": "$context.identity.user",
  "requestTime": "$context.requestTime",
  "httpMethod": "$context.httpMethod",
  "resourcePath": "$context.resourcePath",
  "status": "$context.status",
  "protocol": "$context.protocol",
  "responseLength": "$context.responseLength",
  "userAgent": "$context.identity.userAgent"
}

Every field here has GDPR implications for EU users:

• sourceIp: The user's IP address. Personal data under GDPR Art.4(1): an IP address is "an online identifier" that can identify a natural person, particularly when combined with timestamps and usage patterns.
• resourcePath: The API endpoint path. For REST APIs, paths often encode resource identifiers: /users/{userId}/orders, /documents/{documentId}, /profiles/{email}. If path parameters are logged literally (via $context.path rather than $context.resourcePath), user IDs and email addresses appear directly in the access log.
• caller / user: IAM principal identifiers for authenticated requests. For Cognito-authenticated APIs, this may include the Cognito user ID.
• userAgent: Browser and OS information. Personal data when combined with IP and timestamp (constitutes a browser fingerprint).

Access log entries are written to CloudWatch Logs. CloudWatch Log Groups default to Never expire retention. API Gateway access logs accumulate indefinitely under US jurisdiction unless you explicitly configure a retention policy.

Volume consideration: A moderately active API processing 1,000 requests/hour generates ~8.7 million access log entries per year. Each entry contains at least one IP address. For a GDPR Art.17 erasure request, finding and deleting all access log entries for a specific user's IP address (which changes over time, may be shared with other users via NAT, and is not stored elsewhere in correlation) is not feasible using CloudWatch's standard APIs.

Execution Logs: Full Request and Response Bodies

API Gateway execution logging (distinct from access logging) provides detailed debugging information: the complete request transformation chain, mapping template evaluations, integration request/response, and error details. Execution logs are written to CloudWatch Logs at /aws/api-gateway/[api-id]/[stage].

Execution logs can capture the full request body and response body when verbose logging is enabled (INFO level). For an API endpoint that accepts user profile updates — name, address, date of birth, preferences — the execution log contains the exact JSON payload of the personal data update, stored in CloudWatch under US jurisdiction.

This is the highest-severity GDPR risk in API Gateway logging. Access logs contain metadata (IP, path, timing). Execution logs can contain the full personal data payload — effectively a complete copy of every personal data operation performed via the API, stored indefinitely in CloudWatch.

AWS documentation notes that execution logging should be disabled or set to ERROR level in production due to cost and data volume. In practice, many teams enable INFO-level execution logging during development and forget to disable it before promoting to production. A GDPR audit that finds years of user data payloads in API Gateway execution logs is a critical finding.

API Keys and Usage Plans: Customer Identification Under US Jurisdiction

API Gateway supports API keys for client identification and usage plans for rate limiting and quota management. API key configurations — the key value, its description, any associated tags — are stored by API Gateway under US jurisdiction.

For B2B SaaS applications that issue API keys to customers, the API key database is a directory of your customers. Usage plan associations link API keys to plans, revealing which customers are on which service tier. Usage data — the number of requests made by each API key per day — is stored in API Gateway and accessible via the GetUsagePlanKey and GetUsage APIs.

For EU businesses that use API Gateway API keys as customer identifiers, this usage data falls under GDPR as customer account data. The processing of this data — which API key made how many requests, when, to which endpoints — is analytics on your customers' behavior, subject to GDPR Art.6 legal basis requirements.

Custom Domains and SSL Certificates: Infrastructure Configuration Under US Jurisdiction

Custom domain configurations in API Gateway (for example, mapping api.yourcompany.com to an API Gateway deployment) store:

• The domain name (which identifies your company)
• The SSL certificate ARN (referencing an ACM certificate)
• The base path mappings (which API deployments respond to which paths)
• Endpoint configuration metadata

ACM (AWS Certificate Manager) is where SSL certificates are stored and renewed. ACM is an AWS service under US jurisdiction. For mTLS (mutual TLS) authentication, the truststore bundle (containing client certificates for authenticating inbound connections) is stored in S3 and referenced by API Gateway — both under US jurisdiction.

WebSocket API Connection Data

For WebSocket APIs (API Gateway V2), API Gateway maintains the WebSocket connection registry: which connections are active, their connection IDs, and connection metadata. This data is stored transiently during the connection lifecycle but is accessible via the @connections API.

For real-time applications — chat, live dashboards, collaborative editing — WebSocket connection metadata can identify individual users connected at a given time. The mapping of connection IDs to user identities (typically stored in DynamoDB by the application) is a data processing activity under GDPR. API Gateway's side of this — the connection registry — is under US jurisdiction.

REST API vs HTTP API vs WebSocket API: GDPR Risk Comparison

HTTP API (API Gateway V2) does not support execution logging, which removes the full payload logging risk. For new API deployments, HTTP API is the lower-GDPR-risk option within API Gateway — though access logs and the US-jurisdiction issue remain.

EU-Native API Gateway Alternatives

Kong Gateway on Hetzner

Kong is the most widely deployed open-source API gateway. Self-hosted on Hetzner Cloud (German company, no US parent), Kong provides:

• HTTP routing, load balancing, SSL termination
• Authentication plugins: JWT, OAuth2, LDAP, HMAC, API key
• Rate limiting and quota management
• Request/response transformation
• Access logging to your own log infrastructure (stdout, file, or Kafka)
• Plugin ecosystem for 60+ integrations

Kong's access logs go to your own infrastructure — Loki, Elasticsearch, or a log file — under EU control. No data flows to US-controlled AWS services. SSL certificates are managed by your own cert-manager instance.

Deployment: Kong can run as a Docker Compose service or as a Kubernetes deployment (Kong Ingress Controller for Kubernetes environments). Hetzner Cloud provides the base infrastructure. A CPX21 instance (2 vCPU, 4GB RAM, €5.83/month) handles significant API traffic.

Use case fit: REST APIs, microservices API management, B2B API portals with API key management.

Traefik on Hetzner

Traefik is a cloud-native reverse proxy and API gateway with native Kubernetes integration. Deployed on Hetzner Cloud, Traefik provides:

• HTTP/HTTPS routing with automatic TLS via Let's Encrypt
• Middleware for authentication, rate limiting, headers manipulation, circuit breaking
• Access logging to stdout or files (JSON format, configurable fields)
• Metrics export to Prometheus
• Native Docker and Kubernetes service discovery

Traefik's access logs are configurable at the field level: you can exclude the IP address field from logs, or hash it before storage, to reduce GDPR exposure while retaining operational value. This field-level control is not available in API Gateway.

Use case fit: Kubernetes-native microservices, container-based deployments on Hetzner Cloud or Exoscale. Particularly strong for teams using Docker Compose or Kubernetes on EU infrastructure.

NGINX Unit or NGINX Plus (Self-Hosted)

NGINX Unit is a dynamic application server that can serve as an API gateway with routing, load balancing, and TLS termination. NGINX Plus adds advanced API management features. Self-hosted on Hetzner or OVHcloud, NGINX-based solutions keep all request data on EU infrastructure.

NGINX access logs use a configurable format. Teams can log only the fields necessary for operational purposes (HTTP method, response code, latency) without logging IP addresses or request paths containing user identifiers.

Use case fit: High-performance HTTP routing, static configuration environments, teams with existing NGINX expertise.

Caddy Server

Caddy is a modern web server with automatic HTTPS that can function as a reverse proxy and simple API gateway. Caddy's access logging format is configurable in JSON. For EU applications that need a lightweight API gateway without the operational complexity of Kong, Caddy provides a simple, maintainable alternative.

Use case fit: Smaller APIs, single-service deployments, teams that prioritize simplicity.

sota.io: Managed EU-Native Routing for API Backends

Applications deployed on sota.io receive EU-native reverse proxy routing as part of the platform. Container ports are exposed via the platform's routing layer — under EU jurisdiction, no CLOUD Act exposure. For API backends that are currently fronted by API Gateway, deploying the backend service on sota.io eliminates the API Gateway layer:

• Custom domains are configured on sota.io (EU-native certificate management)
• Request routing is handled by the EU-native platform
• Container-level access logs stay on EU infrastructure
• No usage plan or API key management through AWS

For teams using API Gateway purely as a routing and SSL termination layer (the majority of HTTP API use cases), sota.io provides equivalent functionality under EU jurisdiction with significantly simpler configuration.

GDPR Compliance Checklist for API Gateway

Immediate actions:

1. Check execution log levels: For all REST API stages, verify execution logging is set to OFF or ERROR (not INFO). In the API Gateway console: Stage → Logs/Tracing → CloudWatch Log Level. INFO level in production is a critical GDPR finding if any endpoints process personal data.

2. Set CloudWatch retention on access log groups: Find the Log Groups receiving API Gateway access logs (typically named after the API ID or stage). Set retention to the minimum period consistent with your security requirements (30-90 days for most APIs).

3. Review path parameter logging: If access logs include $context.path (actual path values) rather than $context.resourcePath (template path), check whether user IDs, email addresses, or other personal data appear in path parameters. Switch to $context.resourcePath or hash path parameters.

4. Audit API key associations: Document which API keys are associated with which customers in your Art.30 records. API keys are customer identifiers — their storage and the usage data associated with them requires a legal basis.

5. Document access log processing: GDPR Art.30 records must include IP address collection in access logs as a processing activity, the legal basis (typically legitimate interest for security/operational purposes), and the retention period.

Migration path to EU-native API gateway:

For REST API use cases (routing, SSL, authentication): deploy Kong or Traefik on Hetzner Cloud. The migration involves configuring routes to match your existing API paths, setting up JWT or API key authentication in Kong, and updating DNS to point to the new gateway.

For HTTP API use cases (simple routing to Lambda or container backends): the simpler option is to eliminate the gateway layer entirely. Deploy the backend as a container on sota.io or another EU-native platform with built-in routing and TLS, and expose it directly via the platform's domain or a custom domain.

Conclusion

AWS API Gateway's GDPR complexity comes from two sources: the access logs that record EU users' IP addresses and request patterns under US jurisdiction by default, and the execution logs that can capture full personal data payloads if verbose logging is enabled.

Both are solvable within AWS — configure retention policies, use HTTP API instead of REST API, set execution logging to ERROR level. But these mitigations address symptoms rather than the structural issue: every API request from every EU user touches AWS infrastructure controlled by a US company subject to the CLOUD Act, and the access log record of that request persists in CloudWatch under US jurisdiction.

EU-native API gateways — Kong on Hetzner, Traefik, or the routing layer of EU-native PaaS platforms — eliminate the CLOUD Act exposure at the cost of operational management. For teams already running Kubernetes on EU infrastructure, the marginal cost of adding Kong or Traefik is low. For teams that want zero operational overhead, EU-native managed platforms provide built-in routing under EU jurisdiction.

See Also

• AWS Lambda EU Alternative — Lambda is typically the backend behind API Gateway; both share the same CLOUD Act exposure and execution environment risk
• AWS CloudWatch EU Alternative — API Gateway access logs and execution logs flow into CloudWatch; the CloudWatch GDPR problem compounds the API Gateway risk
• AWS SQS EU Alternative — SQS is a common integration target for API Gateway Lambda backends processing async workloads
• AWS SNS EU Alternative — SNS fan-out is frequently combined with API Gateway for event-driven notification pipelines
• AWS Step Functions EU Alternative — Step Functions orchestrates multi-step workflows often triggered via API Gateway endpoints

Part of the sota.io AWS EU Alternative Series: AWS SQS · AWS SNS · AWS EventBridge · AWS Step Functions · AWS Lambda · AWS CloudWatch · AWS API Gateway