AWS Amplify EU Alternative 2026: Multi-Layer GDPR Risk and CLOUD Act Exposure

Post #715 in the sota.io EU Compliance Series

AWS Amplify is marketed as a unified platform for building full-stack applications. The marketing obscures a critical architectural reality: Amplify is not a single service. It is an orchestration layer that provisions and connects CloudFront, Amazon Cognito, Amazon Pinpoint, AWS AppSync, Amazon S3, and Amazon DynamoDB — each a distinct US-jurisdiction service, each processing a different category of your EU users' personal data, each independently subject to CLOUD Act compelled disclosure.

When you build on Amplify, you are not dealing with one data processor. You are dealing with six, bound together by a developer-facing abstraction that makes the individual services invisible — until you need to assess your GDPR obligations.

A GDPR data protection impact assessment (DPIA) for an Amplify-based application is, in effect, six DPIAs in one: one for each AWS service in the stack. Each service has its own data flows, its own retention policies, its own subprocessor chain, and its own US surveillance law exposure. The Amplify SDK makes it easy to build EU-targeting applications on this stack. It makes it very difficult to understand what that stack is actually doing with your users' data.

The Amplify Stack: What You Actually Deploy

When you run amplify init and configure a standard Amplify project with auth, API, storage, and analytics, you provision:

Each of these services is a separate US-controlled data processor. Each generates its own category of personal data. Each is subject to CLOUD Act compelled disclosure independently of the others. When a US government agency issues a CLOUD Act order targeting your application's data, they can target any or all of these services with separate requests.

Layer 1: Amplify Hosting (CloudFront + S3)

Amplify Hosting uses Amazon CloudFront as the CDN and Amazon S3 as the origin storage. The GDPR implications of CloudFront for EU deployments are documented in the existing AWS CloudFront EU Alternative analysis: every HTTP request from your EU users is evaluated at CloudFront edge locations, IP addresses and request metadata are logged under US jurisdiction, and CLOUD Act compelled disclosure applies to CloudFront access logs.

For Amplify Hosting specifically, there is an additional layer: server-side rendering (SSR) deployments use AWS Lambda functions (via Lambda@Edge or CloudFront Functions) to render pages. Lambda execution logs in CloudWatch contain request context — headers, cookies, user identifiers passed in the request — for every SSR render. These are standard CloudWatch logs, subject to all CloudWatch data processing considerations.

Amplify Hosting also provides custom domain support through Amazon Route 53 and certificate management through AWS Certificate Manager. DNS query logs and certificate issuance records constitute infrastructure metadata that, while less sensitive than content logs, contribute to the overall data footprint under US jurisdiction.

Layer 2: Amplify Auth (Amazon Cognito)

Amazon Cognito is the authentication and user management service behind Amplify Auth. It stores:

• User pool records: Username, email address, phone number, custom attributes, account creation timestamp, last login timestamp, and multi-factor authentication configuration for every registered user.
• Identity pool tokens: Temporary AWS credentials issued to authenticated users, correlating user identity to downstream AWS resource access.
• Authentication logs: Successful and failed authentication attempts, including IP address, user agent, and timestamp.
• Password reset tokens: Time-limited tokens sent via email or SMS, stored in Cognito until used or expired.
• Social identity provider federation data: If you enable Google, Facebook, or Apple sign-in through Cognito, the mapping between your Cognito user and their external identity is stored in Cognito.

Under GDPR, all of these constitute personal data. Authentication logs are particularly sensitive: a log of every login attempt, including failed attempts, combined with IP addresses, reveals user behavior patterns and potentially sensitive inferences (login at unusual hours, login from unexpected locations).

The CLOUD Act exposure for Cognito is straightforward. Cognito user pools are stored in AWS's infrastructure in the region you specify. An AWS eu-central-1 Cognito user pool is physically located in Frankfurt. It is operated by Amazon Cognito, a service of AWS Inc., a US company. The CLOUD Act requires AWS to preserve and disclose this data on US government demand regardless of physical location.

A US government CLOUD Act order targeting your Cognito user pool would yield: a complete list of your application's registered users with their email addresses, phone numbers, account creation dates, last login dates, and login history. This is the most sensitive data category in most consumer-facing applications, and it is stored in a system fully accessible to US authorities.

Cognito Advanced Security Features

If you enable Cognito Advanced Security Features (compromised credential detection, adaptive authentication), Cognito collects additional behavioral data:

• Device fingerprint data for authenticated sessions
• Geographic IP analysis for anomaly detection
• Risk scores assigned to authentication events

This extends Cognito's data collection from identity data to behavioral profiling — automated processing of personal data to evaluate personal aspects of natural persons within the meaning of GDPR Article 4(4). The risk score assigned to a user's login attempt is a form of automated profiling, derived from personal data (IP address, device fingerprint, behavioral patterns), subject to GDPR Article 22 if it triggers automated decisions (blocking the login attempt).

Layer 3: Amplify Analytics (Amazon Pinpoint)

Amazon Pinpoint is AWS's customer engagement platform. Amplify Analytics uses Pinpoint to collect behavioral event data. When you instrument your Amplify application with analytics, Pinpoint receives:

• Session events: App launch, session start, session end, session duration.
• Custom events: Any events you define with Analytics.record() — page views, button clicks, feature interactions, conversion events.
• User attributes: Any demographic or behavioral attributes you set with Analytics.updateEndpoint() — user-defined segments, custom properties, subscription status.
• Endpoint data: Pinpoint's model for a "device" is called an endpoint. Each endpoint has an address (device token for push, email address, phone number for SMS), an OptOut status, demographic data (model, manufacturer, OS, locale), and location data (city, region, country, postal code) derived from IP geolocation.

This data profile is comprehensive behavioral surveillance data under GDPR. Pinpoint is designed for targeting — the purpose of the platform is to segment users and deliver personalized communications based on behavioral criteria. That purpose is precisely what GDPR Article 4(4) defines as profiling: "automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person."

Pinpoint's data model is organized around persistent endpoints. An endpoint persists across sessions, accumulating behavioral event history. For authenticated users, you can associate multiple endpoints (mobile device, web browser, email address) with a single user ID. This creates a cross-device behavioral profile of each user, stored in Pinpoint's US-jurisdiction storage.

If you use Pinpoint for push notifications, email campaigns, or SMS, Pinpoint stores communication opt-in/opt-out status, delivery timestamps, click-through events, and conversion attribution. This is marketing communication data with GDPR implications beyond analytics: it triggers ePrivacy Directive consent requirements and GDPR Article 6(1)(a) consent as a lawful basis.

A CLOUD Act order targeting your Pinpoint project would yield the complete behavioral event history, user attribute profiles, and communication engagement data for your entire EU user base.

Layer 4: Amplify API — AppSync and API Gateway

Amplify supports two API types: GraphQL (via AWS AppSync) and REST (via Amazon API Gateway). Both have distinct personal data implications.

AWS AppSync (GraphQL)

AWS AppSync provides managed GraphQL APIs with real-time subscriptions. AppSync logs in CloudWatch contain:

• Request logs: Every GraphQL operation — query name, variables, resolver execution trace, response data (optionally).
• Subscription data: For real-time subscriptions, AppSync maintains WebSocket connections per user. Connection metadata (user identity, endpoint, subscription filter variables) is stored in AppSync's connection management layer.
• Resolver logs: If you enable field-level logging, AppSync logs the data returned by each resolver — which may include personal data from your DynamoDB tables or other data sources.

GraphQL resolver logs are particularly sensitive. A query like { user(id: "xyz") { email, profile, orders { amount, date } } } executed with field-level logging on generates a CloudWatch log entry containing the user's email, profile data, and order history. This is real personal data, logged automatically to a US-jurisdiction service.

AppSync also supports subscriptions — real-time push updates to connected clients. Subscription filter variables (the criteria a user subscribes to) reveal what the user is interested in monitoring. In an e-commerce application, a subscription filter might be { orderId: "order-123" }, revealing the user's purchase. In a collaboration tool, subscription topics reveal document access patterns. This behavioral data persists in AppSync's connection layer under US jurisdiction.

Amazon API Gateway (REST)

Amazon API Gateway access logs in CloudWatch contain HTTP request metadata: method, path, query string, source IP, user agent, response status, and latency. If you configure API Gateway to log request payloads, full POST body content — which may contain personal data in form submissions — appears in CloudWatch logs.

API Gateway also provides usage plans and API keys for rate limiting. If you associate API keys with users, API Gateway's usage data reveals per-user request volumes and patterns under US jurisdiction.

Layer 5: Amplify Storage (Amazon S3)

Amplify Storage uses Amazon S3 with a structured key prefix pattern to organize user-uploaded content. The default Amplify storage structure uses:

public/      → Files accessible to any authenticated user
protected/   → Files readable by any authenticated user, writeable only by the owner
private/     → Files accessible only to the authenticated user who uploaded them

The key point for GDPR is that S3 contains your users' uploaded files — documents, images, profile photos, medical records in healthcare applications, financial documents in fintech applications. The content of these files depends entirely on your application, but for most user-facing applications, S3 storage contains some of the most sensitive personal data in the system.

S3 access logs record: bucket name, time, requester identity (Cognito user ID or IAM principal), operation, key (file path), HTTP status, bytes transferred, and total request time. If S3 access logging is enabled, these logs create a record of who accessed which file at what time — behavioral data derived from file access patterns.

For applications that handle special categories of personal data under GDPR Article 9 (health data, biometric data, genetic data), Amplify Storage may be directly relevant to the heightened protection requirements. A health application storing medical images in Amplify Storage is storing special category data in US-jurisdiction S3, with all associated CLOUD Act exposure.

Layer 6: Amplify DataStore (Amazon DynamoDB)

Amplify DataStore provides a local-first data sync mechanism backed by AWS AppSync and Amazon DynamoDB. From a GDPR perspective, DynamoDB's implications are straightforward: it stores your application's data model, which typically includes records directly associated with user identities.

DynamoDB Stream records (if enabled) capture every item change in the table — inserts, updates, deletes — with before and after states. Streams are used for event-driven architecture patterns (triggering Lambda on data changes) but they also create a change log of user data modifications. Stream records are retained for 24 hours in DynamoDB's infrastructure under US jurisdiction.

CLOUD Act Compound Risk: Six Independent Subpoena Targets

Each AWS service in the Amplify stack is independently subject to CLOUD Act compelled disclosure. A US government agency targeting an Amplify-based application can issue six separate CLOUD Act orders — one per service — each yielding a different category of personal data:

The compound risk is not merely additive. Each service covers a different dimension of user behavior. Cognito establishes identity. Pinpoint maps behavior over time. AppSync reveals interaction patterns. S3 exposes content. DynamoDB reveals application-state data. Together, they constitute a comprehensive surveillance capability over your EU user base — not as a designed surveillance system, but as an incidental consequence of building on a US-controlled PaaS stack.

GDPR Article 28: The Amplify DPA Chain

Each AWS service in the Amplify stack requires its own Article 28 Data Processing Agreement. AWS provides a unified DPA through its Service Terms that covers all AWS services — but this creates a false sense of completeness. The AWS DPA governs AWS's obligations as your data processor. It does not limit what US law requires of AWS separately.

The subprocessor chain for an Amplify application extends beyond AWS. AWS AppSync resolver integrations may invoke AWS Lambda functions, which execute in AWS-managed container environments. Amazon Pinpoint's email delivery uses Amazon Simple Email Service (SES) and third-party delivery networks. Cognito's SMS MFA uses Amazon SNS and SMS gateway partners. Each of these creates a downstream subprocessor relationship requiring Article 28 coverage that extends beyond the primary AWS DPA.

Amplify's developer experience abstracts all of this away. The Amplify CLI provisions resources automatically, the Amplify SDK makes API calls transparently. The simplicity of the developer experience is inversely proportional to the complexity of the resulting GDPR compliance posture.

EU Alternatives: A Full Amplify Replacement Stack

The good news is that every component of the Amplify stack has a viable EU-sovereign replacement. The replacement is not a single service — Amplify is not a single service — but a composed stack of EU-native services that replicates Amplify's functionality without US-jurisdiction data processing.

Amplify Hosting → sota.io

sota.io is a European PaaS that provides the hosting and deployment infrastructure that Amplify Hosting offers, operating on EU-sovereign infrastructure without AWS CloudFront in the traffic path. For frontend applications, sota.io handles:

• Static site hosting and CDN distribution from EU infrastructure
• Server-side rendering deployments
• Custom domain configuration
• CI/CD pipeline integration

The critical difference: your EU users' HTTP traffic does not pass through any US-controlled CDN layer. Access logs stay in EU-controlled storage. There is no CloudFront, no CloudFront Functions, no Lambda@Edge — none of the associated US-jurisdiction data flows.

For applications that are currently deployed on Amplify Hosting, migration to sota.io involves updating build configuration and DNS. The application code itself does not change.

Amplify Auth (Cognito) → Supabase Auth or Keycloak

Supabase Auth with EU region: Supabase provides hosted authentication with a dedicated EU region (Frankfurt). User data, session tokens, and auth logs stay in EU-controlled infrastructure. Supabase Auth supports email/password, magic link, OAuth providers, phone/SMS MFA, and Row Level Security integration. The Supabase DPA is specifically designed for GDPR compliance with EU data residency commitments.

For Amplify-based applications, the Supabase JavaScript client (@supabase/supabase-js) is API-compatible with patterns established by @aws-amplify/auth. JWT-based auth flows integrate with the same frontend patterns.

Keycloak (self-hosted): For organizations that require complete control over authentication infrastructure, Keycloak deployed on EU-based servers (Hetzner, OVH, Scaleway) provides enterprise-grade identity management. Keycloak supports SAML 2.0, OpenID Connect, LDAP/Active Directory federation, and social login — comparable to Cognito's feature set. Self-hosting eliminates third-party data processor relationships entirely.

Amplify Analytics (Pinpoint) → Plausible Analytics or PostHog EU

Plausible Analytics: Plausible is a GDPR-native analytics platform founded in the EU (Estonia). It collects minimal behavioral data without cookies, stores data on EU infrastructure, and requires no consent banner under ePrivacy Directive guidance for many use cases. For the event tracking use cases that Pinpoint covers, Plausible's custom event API provides a privacy-preserving alternative.

PostHog EU Cloud: PostHog offers a EU Cloud deployment with data stored in Frankfurt. PostHog provides session replay, funnel analysis, feature flags, and A/B testing — covering the product analytics use cases that Pinpoint supports. PostHog's EU Cloud is governed by German data protection law and processed under an appropriate EU DPA.

Self-hosted Matomo: For organizations requiring complete analytics sovereignty, Matomo self-hosted on EU infrastructure eliminates all third-party data flows. Matomo covers web analytics, event tracking, and campaign attribution without any US data processor involvement.

Amplify API (AppSync) → Hasura or PostgREST

Hasura: Hasura provides a managed GraphQL engine that can be deployed on EU infrastructure. Hasura connects to your PostgreSQL database and auto-generates a GraphQL API from your schema, including real-time subscriptions via WebSockets. Deployed on Hetzner or OVH, Hasura provides AppSync-equivalent functionality — queries, mutations, subscriptions, authorization rules — with query logs staying in EU-controlled infrastructure.

PostgREST: For REST API use cases, PostgREST is a lightweight Haskell server that generates a REST API from a PostgreSQL schema. Combined with Nginx for SSL termination and Kong or Traefik for API management, PostgREST provides the REST API functionality of API Gateway without US data processor involvement.

Amplify Storage (S3) → Hetzner Object Storage or MinIO

Hetzner Object Storage: Hetzner provides S3-compatible object storage with storage locations in Germany and Finland. For applications using Amplify Storage, migration involves updating the storage endpoint from S3 to Hetzner Object Storage. The AWS SDK's S3 client and the official @aws-sdk/client-s3 accept custom endpoint configuration, enabling drop-in bucket replacement.

MinIO self-hosted: For complete storage sovereignty, MinIO provides S3-compatible object storage deployable on any EU infrastructure. MinIO supports the full S3 API surface including presigned URLs, multipart upload, and bucket policies — enabling Amplify Storage client code to work with minimal modification.

Amplify DataStore (DynamoDB) → Supabase Database or PostgreSQL

Supabase Database (EU region): Supabase provides managed PostgreSQL with real-time subscriptions via WebSocket — equivalent to Amplify DataStore's sync functionality. Supabase's real-time engine allows clients to subscribe to database changes with filtering — the same pattern Amplify DataStore uses for offline-first sync. The EU Frankfurt region keeps all application data under EU-controlled infrastructure.

Self-hosted PostgreSQL: For maximum control, PostgreSQL self-hosted on Hetzner or OVH provides the relational data layer without any cloud-provider data processor relationship. Tools like Hasura, PostgREST, or custom API layers connect the database to frontend clients.

A Complete EU Amplify Replacement Architecture

A full Amplify replacement stack using EU-sovereign services:

Layer               AWS Amplify              EU Alternative
─────────────────────────────────────────────────────────────
Hosting/CDN         Amplify Hosting          sota.io
Auth                Amazon Cognito           Supabase Auth (EU) / Keycloak
Analytics           Amazon Pinpoint          Plausible / PostHog EU
GraphQL API         AWS AppSync              Hasura on Hetzner
Storage             Amazon S3                Hetzner Object Storage / MinIO
Database            Amazon DynamoDB          Supabase DB (EU) / PostgreSQL

Every component in the right column processes EU user data exclusively in EU-controlled infrastructure. No CLOUD Act exposure. No US-jurisdiction data processors. Complete GDPR sovereignty.

The stack is deployable today. All components are production-ready, actively maintained, and well-documented. The primary migration effort is code-level: replacing AWS SDK calls with equivalent client libraries and updating configuration to point at EU endpoints.

Migrating from AWS Amplify

Phase 1: Map Your Current Amplify Usage

Before migrating, identify which Amplify features your application uses:

# List all Amplify categories configured in your project
cat amplify/backend/amplify-meta.json | jq '.providers, (.[] | keys)'

# Check which Amplify services are actually called in your code
grep -r "from '@aws-amplify" src/ | grep -v node_modules | \
  awk -F"'" '{print $2}' | sort -u

This reveals whether you are using auth, analytics, API, storage, DataStore, or combinations. Each category requires separate migration planning.

Phase 2: Extract Amplify Configuration

Amplify's configuration is stored in aws-exports.js (or amplifyconfiguration.json for Gen 2). Audit each configuration key to understand which services are active:

# Show current Amplify endpoint configuration
cat src/aws-exports.js | grep -E "endpoint|region|userPoolId|identityPoolId|pinpointAppId"

Each key maps to a specific AWS service. aws_user_pools_id and aws_cognito_identity_pool_id → Cognito. aws_mobile_analytics_app_id → Pinpoint. aws_appsync_graphqlEndpoint → AppSync. aws_user_files_s3_bucket → S3. Map each key to its EU replacement endpoint.

Phase 3: Migrate Authentication First

Auth migration is typically the highest-priority because it gates access to all other services. The Supabase JavaScript client provides equivalent patterns:

// Amplify Auth (before)
import { Auth } from 'aws-amplify';
const user = await Auth.signIn(email, password);
const session = await Auth.currentSession();

// Supabase Auth (after)
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(EU_SUPABASE_URL, ANON_KEY);
const { data, error } = await supabase.auth.signInWithPassword({ email, password });
const { data: { session } } = await supabase.auth.getSession();

Migrate users from Cognito to Supabase using Cognito's user export API. Cognito can export user pool data as a CSV. Supabase's admin API allows bulk user import. Plan for a password reset flow — Cognito does not export password hashes in a format Supabase can use directly.

Phase 4: Migrate Analytics

For Pinpoint-instrumented applications:

// Amplify Analytics (before)
import { Analytics } from 'aws-amplify';
Analytics.record({ name: 'pageView', attributes: { page: '/dashboard' } });

// Plausible (after) — add script tag to index.html
// window.plausible('pageView', { props: { page: '/dashboard' } });

// PostHog EU (after)
import posthog from 'posthog-js';
posthog.init(POSTHOG_KEY, { api_host: 'https://eu.posthog.com' });
posthog.capture('pageView', { page: '/dashboard' });

Phase 5: Migrate Storage

S3-compatible storage allows direct SDK substitution:

// Amplify Storage (before)
import { Storage } from 'aws-amplify';
await Storage.put('profile/avatar.jpg', file, { contentType: 'image/jpeg' });
const url = await Storage.get('profile/avatar.jpg');

// Hetzner Object Storage via AWS SDK with custom endpoint (after)
import { S3Client, PutObjectCommand, GetObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client({
  endpoint: 'https://fsn1.your-objectstorage.com', // Hetzner FSN1 endpoint
  region: 'eu-central',
  credentials: { accessKeyId: ACCESS_KEY, secretAccessKey: SECRET_KEY },
  forcePathStyle: true,
});
await s3.send(new PutObjectCommand({ Bucket: BUCKET, Key: 'profile/avatar.jpg', Body: file }));

Phase 6: Decommission AWS Resources

After migration validation, remove Amplify-provisioned resources to eliminate ongoing US-jurisdiction data processing:

# Remove all Amplify backend resources
amplify delete

# Verify no residual Cognito data
aws cognito-idp delete-user-pool --user-pool-id eu-central-1_XXXXXXXX

# Delete Pinpoint application
aws pinpoint delete-app --application-id XXXXXXXXXXXXXXXXXXXXXXXX

# Delete AppSync API
aws appsync delete-graphql-api --api-id XXXXXXXXXXXXXXXXXX

Data retention requirements under GDPR may prevent immediate deletion. Document the deletion schedule in your ROPA (Records of Processing Activities) and complete deletion within the retention period defined in your privacy policy.

See Also

This post is part of the sota.io AWS EU Alternative series:

• AWS CloudFront EU Alternative 2026 — CDN edge processing and EU user traffic under US jurisdiction
• AWS Security Hub EU Alternative 2026 — Security posture management and CLOUD Act risk
• AWS WAF EU Alternative 2026 — Web traffic inspection and GDPR compliance
• AWS GuardDuty EU Alternative 2026 — Threat detection under US jurisdiction
• AWS Lambda EU Alternative 2026 — Serverless compute and execution log exposure

Summary: AWS Amplify orchestrates six distinct AWS services — CloudFront, Cognito, Pinpoint, AppSync, S3, and DynamoDB — each processing different categories of your EU users' personal data under US jurisdiction and CLOUD Act compelled disclosure. A complete EU-sovereign replacement stack exists: sota.io for hosting, Supabase Auth EU for identity, Plausible or PostHog EU for analytics, Hasura on EU infrastructure for GraphQL, Hetzner Object Storage for files, and Supabase Database EU for application data. Each component is production-ready and provides equivalent functionality to its Amplify counterpart without US extraterritorial jurisdiction risk.