AWS Lambda EU Alternative 2026: Serverless Functions, CLOUD Act, and the Execution Environment Problem

Post #685 in the sota.io EU Compliance Series

AWS Lambda has become the default serverless compute primitive for European developers. Event-driven functions, API backends, data transformation pipelines, scheduled jobs — Lambda abstracts away infrastructure management while offering pay-per-invocation pricing and seamless integration with every other AWS service.

AWS operates EU regions: eu-west-1 (Ireland), eu-central-1 (Frankfurt), eu-west-3 (Paris), eu-north-1 (Stockholm). Lambda functions deployed to these regions execute on servers physically located in Europe. Many European development teams treat this as sufficient compliance coverage.

It is not. Amazon Web Services, Inc. is incorporated in Delaware and headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) grants US authorities the power to compel US companies to disclose electronic communications and data stored anywhere in the world. A valid US government order — served on Amazon in Seattle — can reach your Lambda execution environment in Frankfurt: environment variables containing secrets, execution traces, event payloads, and the complete configuration of your serverless functions.

This is the same structural jurisdiction problem documented across the AWS service stack: AWS RDS, AWS S3, AWS DynamoDB. Lambda adds several dimensions that make the analysis more complex: execution environment exposure, Lambda@Edge edge compute jurisdiction, and the secrets management problem at the function level.

What AWS Lambda Knows About Your Application

Lambda functions are not stateless black boxes from an infrastructure perspective. AWS maintains substantial metadata and operational data around every function execution.

Environment Variables: The Secrets Problem

Lambda environment variables are the standard mechanism for passing configuration data to serverless functions: database connection strings, API keys, OAuth secrets, service credentials, encryption keys. AWS encrypts environment variables at rest using AWS KMS. This sounds protective. It is not protection against the CLOUD Act.

The encryption is managed by AWS KMS — a service operated by Amazon Web Services, Inc., the same US legal entity subject to CLOUD Act compulsion. A government order does not need to break encryption; it compels Amazon to use its own key management infrastructure to decrypt and produce the data. Your database passwords, API keys, and secrets stored as Lambda environment variables are reachable.

Under GDPR Art.32, controllers must ensure "appropriate technical and organisational measures" to protect personal data. Secrets management that depends on a US company's key management system does not constitute adequate protection when that company is subject to compelled disclosure laws that can override its own contractual commitments.

AWS X-Ray Tracing: Execution Traces as Personal Data

AWS X-Ray is the distributed tracing service integrated into Lambda. When X-Ray tracing is enabled — the default recommendation in AWS documentation and the setting required for AWS CloudWatch Application Insights — Lambda sends trace data to X-Ray after each invocation.

X-Ray traces include:

• Function invocation timestamps and duration
• Input event metadata and custom annotations
• Downstream service calls (database queries, HTTP requests, other Lambda invocations)
• Error messages and stack traces
• Any data explicitly logged via X-Ray segments

For Lambda functions that process user data — authentication events, profile updates, order processing, payment flows — X-Ray traces can contain personal data from the processed events. An authentication Lambda traces which user ID attempted login, from which IP, at what time, and whether the attempt succeeded. A payment Lambda traces transaction identifiers linked to natural persons.

X-Ray trace data is stored by AWS in your region. It is retained for 30 days by default. Every retained trace is accessible under CLOUD Act compulsion.

Lambda Invocation Logs: CloudWatch as the Default Audit Trail

Every Lambda function writes logs to Amazon CloudWatch Logs by default. AWS requires a CloudWatch Logs execution role to be attached to Lambda — without it, the function fails. This creates a mandatory dependency: Lambda execution logging is architecturally tied to CloudWatch, a service operated by AWS (US entity).

CloudWatch Logs for Lambda include:

• START/END/REPORT lines for every invocation
• All output from your console.log() / print() / logging framework calls
• Error messages and stack traces
• Cold start duration and memory utilization

Development teams regularly log request context, user identifiers, and processing results to CloudWatch. Production debugging requires it. This creates a rich dataset of personal data processing events stored in AWS infrastructure, subject to CLOUD Act compulsion.

The Lambda@Edge Problem: US Execution for EU Users

Lambda@Edge is the capability that fundamentally breaks the "EU region = EU jurisdiction" assumption for serverless architectures.

Lambda@Edge runs Lambda functions at CloudFront edge locations globally. When a user in Frankfurt accesses your application, a Lambda@Edge function may execute at the nearest CloudFront PoP — which might be in Frankfurt, but might equally be in Dublin, Amsterdam, or a US-based PoP depending on routing. The critical issue: Lambda@Edge functions are defined in us-east-1 and replicated globally by CloudFront.

The AWS documentation is explicit: Lambda@Edge functions must be created in the US East (N. Virginia) region. They are then propagated to edge locations. There is no mechanism to restrict Lambda@Edge execution to EU-only edge locations. CloudFront routing decisions are made by AWS infrastructure, not controlled by the application developer.

For applications using Lambda@Edge for:

• Authentication (JWT validation, cookie inspection)
• URL routing and redirects
• A/B testing
• Request/response transformation
• Bot detection

...the execution environment for these functions can be US-based infrastructure, processing EU personal data under US jurisdiction, regardless of your application's region selection.

CloudFront Functions: The Same Problem, Smaller Scale

CloudFront Functions are the lighter-weight alternative to Lambda@Edge. They have the same architectural characteristic: execution at CloudFront edge locations globally, with no EU-only execution guarantee, defined and managed from a US entity.

Lambda Layers: Supply Chain Jurisdiction

Lambda Layers are ZIP archives containing shared code, libraries, and runtimes that Lambda functions reference. AWS maintains public Lambda Layers for common runtimes and frameworks. Third-party vendors publish Lambda Layers for observability tools, security agents, and utility libraries.

Lambda Layers are hosted on AWS S3 infrastructure. When your Lambda function initializes in eu-central-1, it downloads Layer content from S3. The Layer data is served by AWS S3 — an AWS service subject to CLOUD Act. A government order targeting AWS could potentially include Layer content in its scope.

More practically: Lambda Layers from third-party vendors (Datadog, New Relic, Sentry) are hosted by those vendors on their own infrastructure, which may itself be US-based. An observability Layer injected into every Lambda invocation represents additional data flow to non-EU-controlled infrastructure.

EventBridge, SQS, SNS: The Serverless Integration Chain

Lambda functions rarely operate in isolation. Serverless architectures built on AWS typically use Lambda in combination with EventBridge (event routing), SQS (message queuing), and SNS (pub/sub notifications). Each of these services:

1. Is operated by Amazon Web Services, Inc. (US entity, CLOUD Act subject)
2. Stores event/message content and metadata
3. Has audit logging tied to CloudTrail (another AWS service with CLOUD Act exposure)

Event payloads flowing through EventBridge → Lambda → SQS chains may contain personal data at every hop. The entire chain is reachable under a CLOUD Act order that targets Amazon. Your application's data processing logic may be EU-resident, but the infrastructure routing and queuing that data is under US legal control.

GDPR Art.44-49: The Transfer Basis Problem

GDPR Chapter V requires a legal transfer mechanism for personal data transferred to third countries. The standard approach for AWS is Standard Contractual Clauses (SCCs) combined with a Transfer Impact Assessment (TIA).

SCCs do not disable the CLOUD Act. The CJEU Schrems II ruling (C-311/18) established that SCCs are valid only where the third country's law does not prevent the data importer from complying with its SCC obligations. US surveillance law — including the CLOUD Act — is precisely the category of law the CJEU identified as potentially invalidating SCCs.

For Lambda, this creates a specific problem: environment variables containing database credentials that, if disclosed, would give the US government access to your EU database. This creates an indirect exposure pathway where Lambda configuration acts as the breach point for the entire backend.

AWS SCCs and DPA commit Amazon to using "best efforts" and legal challenges before disclosure. They explicitly carve out "lawfully compelled" disclosures. The contractual protection against the CLOUD Act is a legal challenge mechanism, not a technical barrier.

EU-Native Serverless Alternatives

The CLOUD Act exposure described above is a consequence of AWS being a US-parent entity. The solution is serverless compute operated exclusively by European-headquartered companies.

Scaleway Serverless Functions (France)

Scaleway is headquartered in Paris, France. Scaleway Serverless Functions is a Function-as-a-Service platform deployed in Scaleway's EU data centers (Paris, Amsterdam, Warsaw). Functions execute in isolated containers, support Node.js and Python runtimes, and integrate with Scaleway's Object Storage, Managed Databases, and Messaging services.

Scaleway falls under French/EU jurisdiction. No CLOUD Act exposure. GDPR compliance is structural rather than contractual.

// Scaleway Serverless Function (Node.js)
module.exports.handle = async (event, context, callback) => {
  const body = JSON.parse(event.body || '{}');
  
  // Same programming model as Lambda
  const result = await processRequest(body);
  
  return {
    statusCode: 200,
    body: JSON.stringify(result),
  };
};

Scaleway Serverless Functions supports HTTP triggers, Scaleway Messaging (NATS/SQS-compatible) triggers, and scheduled invocations via CRON.

OVHcloud Functions (France)

OVHcloud is headquartered in Roubaix, France. OVHcloud Functions (currently in beta) provides serverless compute on OVHcloud's EU infrastructure. OVHcloud is the largest European cloud provider by infrastructure footprint, with data centers in France, Germany, Poland, and the UK.

OVHcloud's serverless offering supports Node.js, Python, and Go runtimes. Integration with OVHcloud Object Storage and managed services provides an AWS-equivalent integration story without the US jurisdiction problem.

Exoscale Serverless (Switzerland/Austria)

Exoscale is incorporated in Switzerland and operates data centers in Zurich, Vienna, Frankfurt, Geneva, and Munich. Exoscale's serverless compute offering (in public preview) provides function execution in Swiss/EU infrastructure under Swiss and EU data protection law.

Switzerland's Federal Act on Data Protection (revDSG) aligned with GDPR in 2023, making Switzerland an adequate country under GDPR Art.45. Combined with Exoscale's EU-only infrastructure and Swiss corporate structure, Exoscale offers one of the strongest jurisdiction profiles available.

Self-Hosted: Knative on EU Infrastructure

For organizations with Kubernetes infrastructure in EU data centers, Knative provides a serverless framework that runs on top of Kubernetes clusters you control.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: user-processor
  namespace: production
spec:
  template:
    spec:
      containers:
        - image: registry.example.com/user-processor:v1.2.0
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url

Knative on EU-hosted Kubernetes (Hetzner Cloud, Scaleway Kapsule, OVHcloud Managed Kubernetes) provides Lambda-equivalent event-driven compute with:

• Complete infrastructure control
• No US jurisdiction exposure
• Secrets managed by your Kubernetes Secret store or an EU-native vault
• No mandatory telemetry flowing to US infrastructure

The operational overhead is higher — you manage the Kubernetes cluster, Knative installation, and scaling configuration. For teams already running Kubernetes, the incremental cost is low.

OpenFaaS on EU Infrastructure

OpenFaaS (Functions as a Service) is an open-source serverless framework that runs on Kubernetes or Docker Swarm. OpenFaaS CE (Community Edition) is free; OpenFaaS Pro is a commercial product from OpenFaaS Ltd (UK entity, post-Brexit UK GDPR jurisdiction — verify adequacy status for your use case).

OpenFaaS supports any language via container images, provides a CLI and UI for function deployment, and integrates with standard Kubernetes tooling. Deployed on EU infrastructure, it provides complete jurisdiction control.

Migration Guide: Lambda to Scaleway Serverless Functions

The programming model is similar enough that migration from Lambda to Scaleway or OVHcloud is primarily a runtime and tooling change, not a logic rewrite.

// AWS Lambda handler
exports.handler = async (event) => {
  const userId = event.pathParameters?.userId;
  if (!userId) {
    return { statusCode: 400, body: JSON.stringify({ error: 'userId required' }) };
  }
  
  const user = await getUserFromDatabase(userId);
  return {
    statusCode: 200,
    body: JSON.stringify(user),
  };
};

// Scaleway Serverless Function — minimal changes
module.exports.handle = async (event, context, callback) => {
  const userId = event.queryStringParameters?.userId;
  if (!userId) {
    return callback(null, { statusCode: 400, body: JSON.stringify({ error: 'userId required' }) });
  }
  
  const user = await getUserFromDatabase(userId);
  return callback(null, {
    statusCode: 200,
    body: JSON.stringify(user),
  });
};

The handler signature differs slightly (Scaleway uses Node.js callback convention by default), but the business logic is identical. Environment variables work the same way; Scaleway's secrets management integrates with the function configuration.

For event-driven architectures, Scaleway Messaging (NATS-compatible) replaces SQS/SNS. Scaleway CRON triggers replace EventBridge scheduled rules. The integration story is complete without AWS dependencies.

Environment Variables: Replacing AWS KMS with EU-Native Secrets Management

If you need hardware-backed secrets management equivalent to AWS KMS + Lambda environment variable encryption, EU-native alternatives include:

• Infisical (open-source, self-hostable): Secrets management with dynamic secrets, versioning, and audit logs. No US parent company.
• HashiCorp Vault (self-hosted on EU infrastructure): The standard enterprise secrets management solution. Vault itself is open-source; the company (IBM-acquired) is US-based, but self-hosted deployments are under your control.
• Doppler EU (doppler.com): US company with EU data residency option — check current adequacy status.

For Kubernetes-based serverless (Knative, OpenFaaS), Kubernetes Secrets with encryption-at-rest configured to use an EU-hosted key management service provides equivalent functionality.

The Assessment Framework

Before selecting a serverless platform, assess the data flows your functions process:

1. What personal data flows through function payloads? User IDs, email addresses, behavioral data, payment identifiers.
2. What secrets are in environment variables? Database credentials, API keys, OAuth secrets — these expand CLOUD Act exposure to all connected services.
3. Are you using Lambda@Edge? If yes: you have US-execution exposure for EU user traffic, regardless of region selection.
4. What observability data flows to US services? X-Ray, CloudWatch, third-party APM Layers.
5. What is the blast radius of a CLOUD Act order? For Lambda: the order can reach function configuration, execution history, connected service credentials, and event data.

For applications processing special category data (healthcare, financial, legal, biometric) under GDPR Art.9, the risk profile of Lambda is particularly acute. Environment variables in a healthcare Lambda might contain credentials to patient databases. The CLOUD Act exposure is not just to the Lambda metadata — it is to everything those credentials unlock.

The Infrastructure Stack Alternative

The complete EU-native serverless stack:

Building on this stack eliminates the CLOUD Act exposure surface at the serverless compute layer. Combined with EU-native managed databases (AWS RDS alternative, DynamoDB alternative), the result is a complete application stack where no US company has jurisdiction over your data.

The Managed Platform Option

For development teams whose primary goal is to deploy applications without managing Kubernetes, Knative, or serverless infrastructure, sota.io provides a managed PaaS for containerized applications deployed exclusively on EU infrastructure. Containerized applications provide equivalent flexibility to Lambda with full infrastructure control and no US parent company in the trust chain.

Conclusion

AWS Lambda's serverless model offers genuine operational advantages. The jurisdiction problem is real and measurable: environment variables containing secrets reachable by CLOUD Act order, execution traces logging personal data processing events, Lambda@Edge functions executing on US infrastructure for EU users, and a logging architecture that mandatorily routes to CloudWatch (an AWS-operated service).

The mitigation options are not contractual — they are structural. Move serverless compute to EU-headquartered providers: Scaleway Functions, OVHcloud Functions, Exoscale. For teams with Kubernetes, Knative and OpenFaaS provide Lambda-equivalent capability on infrastructure you fully control.

The serverless abstraction is not the problem. Serverless on US infrastructure is. The abstraction works equally well on EU infrastructure, without the CLOUD Act risk surface that Lambda's deployment model introduces.

See also: AWS S3 EU Alternative · AWS RDS EU Alternative · AWS DynamoDB EU Alternative · Twilio EU Alternative