AWS Systems Manager EU Alternative 2026: Parameter Store Credentials, Session Transcripts, and the GDPR Problem

Post #731 in the sota.io EU Compliance Series

AWS Systems Manager (SSM) is the operational backbone of most AWS-hosted applications. It handles secrets distribution through Parameter Store, provides agentless shell access to EC2 instances via Session Manager, executes automation scripts across fleets with Run Command, enforces configuration standards through State Manager, and collects detailed infrastructure inventory. For teams running workloads on AWS, SSM is often treated as invisible infrastructure — it's there, it works, and nobody thinks about it.

That invisibility is a GDPR problem. SSM touches some of the most sensitive operational data in your environment: application credentials, administrative session recordings, complete infrastructure topology, and the configuration state of every system in your account. Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) allows US authorities to compel production of data from US companies regardless of where that data is stored. When that data includes your database passwords, admin session transcripts, and a complete inventory of your infrastructure, the compliance implications extend well beyond simple data residency.

This analysis examines six distinct GDPR exposure points in AWS Systems Manager that European development teams frequently overlook.

Parameter Store: Your Application Credentials Under US Jurisdiction

AWS Systems Manager Parameter Store is the standard AWS mechanism for storing application secrets: database connection strings, API keys, OAuth tokens, encryption keys, and service credentials. Parameter Store offers two storage tiers: Standard parameters (plaintext or KMS-encrypted) and SecureString parameters (always KMS-encrypted). Most production environments use SecureString for anything sensitive.

The encryption story sounds reassuring. SecureString parameters are encrypted with AWS Key Management Service — either an AWS-managed CMK or a customer-managed CMK. The data is encrypted at rest in AWS's managed infrastructure, and AWS does not provide the plaintext to unauthorized parties in normal operations.

The GDPR problem: Encryption under AWS KMS does not remove the credential from US jurisdiction. AWS KMS itself is operated by Amazon Web Services, Inc. under US law. When US authorities serve a CLOUD Act order on AWS, they are ordering a US company to produce data — and KMS decryption is an operation AWS can perform. AWS has published transparency reports documenting government data requests; the existence of this reporting mechanism confirms that the legal pathway for compelled disclosure exists.

For applications processing EU personal data, the credentials stored in Parameter Store frequently provide direct access to that data: database passwords for production databases containing user records, API keys for services processing EU user requests, encryption keys that protect EU user data at rest. A CLOUD Act order that compels disclosure of Parameter Store credentials is functionally equivalent to a CLOUD Act order for the underlying personal data itself.

Under GDPR Art. 5(1)(f), personal data must be protected using appropriate technical measures. Storing the access credentials to EU personal data in a system subject to compelled US government access raises questions about whether that technical protection is genuinely appropriate. The credential is a control plane artifact — but it is also the key to the data plane.

Session Manager: Your Admin Session Transcripts in CloudWatch

AWS Session Manager replaces SSH for EC2 instance access. It provides browser-based and CLI shell sessions to instances without requiring open inbound ports, SSH keys, or a bastion host. Sessions are initiated through the AWS console or AWS CLI, authenticated via IAM, and optionally logged to Amazon S3 and Amazon CloudWatch Logs.

Session logging is AWS's own recommended security practice: enabling session logging creates an audit trail of which IAM user or role accessed which instance and when. AWS Security Hub and compliance frameworks like PCI-DSS and SOC 2 often require this logging to be active.

The GDPR problem: Session transcripts are not mere metadata. A shell session transcript captures everything typed during an administrative session and (depending on logging configuration) everything displayed on the terminal. Administrative sessions on production systems frequently involve:

• Database queries that return rows containing personal data
• File operations on configuration files that reference personal data endpoints
• Log review commands that display personal data from application logs
• Service restart procedures that echo connection strings to stdout
• Debugging sessions where application state including user data is inspected

When these session transcripts are stored in CloudWatch Logs under US jurisdiction, the personal data that appears in terminal output has been processed by a US-controlled service. This is not a theoretical edge case: any ops team that has ever run SELECT * FROM users WHERE email = ? in a production database session has captured personal data in their session transcript.

CloudWatch Logs retains this data for a configurable period (default: indefinite). The entire history of your administrative access to production systems — with content — is stored in AWS's infrastructure and reachable via CLOUD Act order. Under GDPR Art. 32, appropriate security includes measures that prevent unauthorized access to systems processing personal data. Session transcripts stored under US jurisdiction create a secondary pathway to personal data that bypasses the access controls you've implemented on the production systems themselves.

Run Command: Command Output Stored Under US Custody

AWS Systems Manager Run Command allows you to execute scripts and shell commands across your entire EC2 fleet simultaneously. It's the standard mechanism for fleet-wide configuration changes, software installation, log collection, and operational automation. Run Command output — the stdout and stderr of your scripts — is stored in Amazon S3 and CloudWatch Logs.

For routine operations like installing packages or updating configuration files, Run Command output contains limited sensitive data. But operational reality is messier. Scripts that collect diagnostics, validate service health, or gather troubleshooting information regularly produce output containing:

• Service status output that includes connection strings from environment variables
• Log excerpts captured during health checks that contain request data
• Database connectivity tests that display connection metadata
• Certificate validation output that includes domain names and expiry details

The GDPR problem: Run Command output is stored in S3 and CloudWatch under AWS custody. The storage account is your AWS account — you own the data in the contractual sense — but AWS as a US entity is the infrastructure operator, and the CLOUD Act reaches this data. If a Run Command execution captures personal data in its output (directly or incidentally), that data is now in an AWS-managed store subject to US jurisdiction.

The GDPR Art. 28 framework requires that data processors only process personal data on documented instructions from the controller. AWS's DPA covers SSM's core operations. But the scope of what Run Command output captures in practice is determined by the scripts you run — AWS has no visibility into whether a particular script invocation produces personal data output. The compliance responsibility sits with you, and the infrastructure doesn't enforce the boundary.

SSM Inventory: Your Complete Infrastructure Topology Under AWS Custody

AWS Systems Manager Inventory collects detailed information about your managed instances and stores it in Amazon S3. When Inventory is configured — which AWS recommends for compliance and operational visibility — it regularly collects:

• Installed applications and versions across every instance
• Running processes and their command-line arguments
• Network configuration: interfaces, IP addresses, open ports, listening services
• Windows Registry entries and installed patches (for Windows instances)
• Custom inventory data that you define

The Inventory data is consolidated in an S3 bucket in your account and queryable through Systems Manager's built-in tools. AWS recommends enabling Inventory for all managed instances as part of security and compliance posture management.

The GDPR problem: Infrastructure inventory data is operational intelligence. Your complete inventory reveals the architecture of the systems processing EU personal data: which database versions are running on which instances, what services are listening on which ports, what software is deployed where. While inventory data is not personal data in the direct sense, it provides a roadmap for identifying and accessing the systems that store and process personal data.

More directly: running processes captured by Inventory include command-line arguments. On systems where applications load configuration from environment variables or pass connection strings as arguments, process inventory can capture credential fragments, endpoint URLs, or service identifiers that link to personal data stores.

Under GDPR's principle of data protection by design (Art. 25), the architecture of systems handling personal data should minimize exposure. Storing a complete topological map of your personal-data-processing infrastructure in a US-controlled service is not architecturally aligned with this principle.

State Manager: Your Compliance Posture Stored Centrally

AWS Systems Manager State Manager lets you define configuration policies — called Associations — that are continuously applied to your managed instances. An Association might enforce that SSM Agent is always running, that specific security patches are applied, that a particular software version is installed, or that a custom configuration file has specific contents.

State Manager records the compliance status of every Association on every instance: whether the configuration was successfully applied, when it was last checked, and what the current compliance state is. This compliance history is stored in Systems Manager and queryable through the console and API.

The GDPR problem: Compliance state data reveals which security configurations are present or absent on the systems processing EU personal data. An Association tracking whether encryption-at-rest is configured, whether audit logging is enabled, or whether specific security patches are applied provides indirect evidence about the security posture of personal-data-handling systems.

For regulated industries where specific technical controls are required for GDPR compliance (Art. 32 appropriate technical measures), the compliance posture of those controls being stored in a US-controlled service creates a secondary jurisdiction question: if a CLOUD Act order compels AWS to produce your compliance history, it could reveal gaps in your technical security measures before you've addressed them — information that could be damaging in a subsequent regulatory investigation.

Patch Manager: Patch Compliance Data and Vulnerability Windows

AWS Systems Manager Patch Manager automates the process of patching managed instances. It scans instances against configured patch baselines, identifies missing patches, and applies them on a schedule. Patch scan results — which patches are missing, which CVEs are unpatched, and for how long — are stored in Systems Manager and Amazon S3.

The GDPR problem: Patch compliance data is a vulnerability disclosure. Systems with unpatched CVEs that affect services processing EU personal data represent active risk. If patch compliance data stored under US custody is compelled by US authorities, it could reveal that systems handling EU personal data are running with known vulnerabilities — prior to those vulnerabilities being remediated. This creates a timing exposure where the compliance data accurately describes your current risk posture in a way that could be used against you in a breach investigation.

This is a narrower concern than the credential and session transcript issues above, but it illustrates a general principle: SSM's operational data is a live mirror of your security posture, and that mirror is held by a US-jurisdiction entity.

EU Alternatives to AWS Systems Manager

Each SSM capability has EU-deployable alternatives that keep operational data within EU jurisdiction.

Secrets Management (replacing Parameter Store):

HashiCorp Vault is the most widely deployed open-source secrets manager. Vault can be self-hosted on EU infrastructure, supports dynamic secrets (credentials generated on-demand and automatically expired), and provides comprehensive audit logging. Vault's Kubernetes integration (via the Vault Agent Injector or the Vault Secrets Operator) mirrors Parameter Store's functionality for containerized workloads while keeping all credential data in your EU-controlled infrastructure.

Infisical is an open-source secrets manager with a strong EU-deployment story. It offers a native Kubernetes operator, SDKs for most languages, and a self-hosted option that keeps all secrets within your infrastructure. Infisical's developer experience is close to Parameter Store, making migration straightforward.

Bitwarden Secrets Manager provides a secrets management tier alongside Bitwarden's password management. Bitwarden offers EU-hosted options and an on-premises deployment path.

Remote Access (replacing Session Manager):

Teleport is the leading open-source privileged access management platform. Teleport provides SSH, Kubernetes, and database access with session recording — critically, the session recordings are stored in your infrastructure, not a third-party US service. Teleport's EU deployment story is mature, with support for EU cloud regions for the hosted version and full self-hosted deployment for complete control.

JumpServer is an open-source bastion host and privileged access management platform. For teams that need a simpler replacement for Session Manager without the full Teleport feature set, JumpServer provides session recording, access control, and audit trails — all stored in your infrastructure.

Fleet Automation (replacing Run Command):

Ansible is the standard open-source fleet automation tool. Ansible playbooks run from your control plane, push operations to target instances, and store execution results in your infrastructure. There is no third-party service involved — run output stays in your environment.

Puppet and Chef provide configuration management with State Manager equivalents. Both support EU-hosted control planes and self-hosted deployment.

Infrastructure Inventory:

osquery is an open-source host introspection tool developed by Meta. It exposes OS state as SQL tables and can continuously stream inventory data to your chosen destination. Combined with a self-hosted log aggregation stack (Elasticsearch, ClickHouse, or Loki), osquery provides SSM Inventory's functionality without AWS custody.

The PaaS Alternative:

The architectural argument for SSM assumes that you're managing EC2 instances — patching them, accessing them, inventorying them. A EU-native PaaS like sota.io eliminates most SSM use cases by removing the need for instance management entirely. Container deployments on EU-sovereign infrastructure don't require Parameter Store (environment variables and EU-controlled secret injection), Session Manager (no OS-level access to manage), or Patch Manager (the platform handles underlying infrastructure patching).

GDPR Compliance Checklist

For teams continuing to use AWS SSM while mitigating compliance exposure:

• Parameter Store: Use customer-managed KMS keys and restrict key policies to minimum required IAM principals. Document the business necessity for storing each credential category in Parameter Store in your ROPA.
• Session Manager: If session logging is required for compliance, consider whether logs should be stored in an EU-jurisdiction system (self-managed S3 bucket with strict access controls) rather than CloudWatch. Evaluate whether session logging scope can be limited to session metadata rather than full transcript.
• Run Command: Audit your Run Command documents for scripts that may capture personal data in output. Implement output redirection for sensitive operations to avoid transcript storage.
• Inventory: Review the data categories collected and disable collection of data types (process command lines, specific file paths) that may capture sensitive operational data.
• All SSM data: Ensure your AWS DPA explicitly covers Systems Manager data categories, that you have an EU-jurisdiction transfer mechanism (SCCs) in place, and that your ROPA documents SSM as a processor for the relevant data categories.

The deeper fix is architectural: SSM's GDPR exposure is a consequence of running on EC2 and depending on AWS for operational tooling. EU-sovereign infrastructure that handles patching, secrets, and access management at the platform level removes these compliance questions from the application team's scope.

Conclusion

AWS Systems Manager is a well-designed operational platform that solves real problems. But for European applications processing personal data, SSM creates a cluster of GDPR exposure points that are structurally difficult to fully remediate within the AWS ecosystem: credentials in US-jurisdiction HSMs, session transcripts capturing personal data, infrastructure topology under AWS custody, and compliance state stored centrally.

The EU-native alternatives — Vault, Infisical, Teleport, Ansible, osquery — are mature, widely deployed, and can replicate SSM's functionality within EU-controlled infrastructure. For new projects, the cleaner path is a EU-native PaaS that makes most SSM capabilities unnecessary by design.

The EU cloud sovereignty trend is accelerating. AWS has launched the European Sovereign Cloud (announced January 2026) in response, but many SSM capabilities are not yet available in the ESC regions, and the parent-company jurisdiction question is not resolved by a regional boundary. EU-based alternatives remain the cleaner compliance answer for 2026.