AWS Transfer Family EU Alternative 2026: Managed SFTP/FTPS/AS2 for PII Files and GDPR Under the CLOUD Act
Post #749 in the sota.io EU Compliance Series
AWS Transfer Family is Amazon's managed file transfer service. It provides fully managed SFTP (SSH File Transfer Protocol), FTPS (FTP over TLS), FTP, and AS2 (Applicability Statement 2) endpoints that connect external clients to AWS S3 buckets and EFS file systems. Organizations use Transfer Family to replace on-premises SFTP servers, enable B2B file exchange with partners, and build automated file ingestion pipelines — without managing server infrastructure.
Transfer Family is heavily used for personal data file transfers. HR departments use it to exchange employee records with payroll processors via SFTP. Healthcare organizations use it to transfer clinical data files between systems. Financial services firms use AS2 connectors to exchange bank reconciliation files, ACH payment data, and settlement records with counterparties. Retail organizations use it to ingest customer transaction exports from partner systems. In each case, the files being transferred contain personal data — and Transfer Family manages both the transfer protocol layer and the storage destination.
The structural GDPR problem: AWS Transfer Family's service management layer — the server endpoint configurations, user authentication records, SSH key material, transfer activity logs, and AS2 partner profiles — is stored in AWS-managed infrastructure under US jurisdiction. The service is operated by Amazon.com, Inc., a US company subject to CLOUD Act compelled disclosure. A CLOUD Act demand targeting an organization's Transfer Family deployment would yield the organizational file transfer architecture: which users and partners have SFTP access, which files have been transferred when, and the technical configuration of B2B data exchange relationships.
What AWS Transfer Family Actually Does
Transfer Family decouples the managed file transfer protocol layer from the underlying storage. Clients connect to a Transfer Family server endpoint using standard SFTP/FTPS/FTP clients or AS2-capable EDI systems. Transfer Family authenticates the connection (via SSH keys, username/password through an identity provider, or AS2 certificates), then routes file operations (uploads, downloads, directory listings) to the mapped S3 bucket or EFS filesystem.
Transfer Family server endpoints can be public (accessible from the internet with a custom domain via Route 53 Resolver) or VPC-hosted (accessible only from within a VPC or via AWS Direct Connect). Custom identity providers integrate with existing directory systems: AWS Directory Service (Microsoft Active Directory), LDAP-compatible directories, or custom Lambda functions that validate credentials against an existing user database.
Transfer Family Workflows automate post-upload processing: a file uploaded by an SFTP user triggers a workflow that copies the file to a processing bucket, adds metadata tags, decrypts the payload, or invokes a Lambda function to start a downstream processing pipeline. Workflows define the operational file processing logic that runs after each file transfer event.
Transfer Family AS2 Connectors implement the AS2 protocol for EDI-style B2B file exchange. AS2 provides message signing (using X.509 certificates) and encryption for file exchange with business partners. The connector configuration stores the trading partner profile: the partner's AS2 ID, their public certificate, MDN (Message Disposition Notification) settings, and the S3 destination for received files.
GDPR Exposure Point 1: Managed SFTP Server Configuration as Personal Data Infrastructure Map
AWS Transfer Family server configurations — the endpoint settings, VPC placement, security group associations, custom hostname mappings, and user permission structures — constitute a map of the organization's personal data transfer infrastructure. Each configured server represents a channel through which personal data moves between the organization and external parties.
For a healthcare organization, the Transfer Family configuration reveals: which SFTP servers handle clinical data exchange, which VPC subnets host the servers (indicating which internal networks can access clinical data), and which IAM roles govern file landing zone access in S3. For a financial organization, the configuration reveals: which SFTP servers handle payment file ingestion, which AS2 connectors communicate with banking counterparties, and which S3 buckets serve as landing zones for financial personal data.
Under GDPR Art. 30 (Records of Processing Activities), organizations must document the technical means through which personal data is transferred. The Transfer Family server configuration is an operational implementation of that documentation — it defines the technical channels for personal data transfers. Storing this configuration in AWS-managed service state creates CLOUD Act exposure for the organization's complete personal data transfer infrastructure map.
Under GDPR Art. 46, transfers of personal data to third countries must be protected by appropriate safeguards — Standard Contractual Clauses, Binding Corporate Rules, or adequacy decisions. When personal data is transferred via an AWS Transfer Family SFTP server, the organizational party receiving the data is not the only CLOUD Act-exposed entity: the Transfer Family service configuration itself, describing the transfer relationship, is under US jurisdiction regardless of where the data files ultimately land.
GDPR Exposure Point 2: Service-Managed SSH Public Keys and User Identity Mapping
AWS Transfer Family's service-managed authentication stores SSH public keys for SFTP users directly in the Transfer Family service state. Each Transfer Family user account holds one or more SSH public keys that authorize SFTP connections from the key holder's SFTP client.
The SSH public key material stored in Transfer Family is not sensitive in isolation — public keys are, by definition, public. But the mapping of public keys to Transfer Family user accounts, to IAM roles, and to S3 home directories constitutes identity infrastructure documentation. The user list reveals who has SFTP access to the organization's file transfer infrastructure: which individuals, which service accounts, which partner organizations.
For organizations transferring personal data — HR departments, healthcare providers, financial firms — the Transfer Family user list maps which external parties have authorized access to personal data file landing zones. A payroll provider's SFTP service account appearing in Transfer Family user configuration reveals the existence of a data processing relationship between the organization and that payroll provider. Under GDPR Art. 30, this relationship should be documented in the Records of Processing Activities.
Under CLOUD Act, a demand for Transfer Family user configuration would yield: all authorized SFTP users and their associated IAM roles and S3 home directories, all stored SSH public keys and their associated user accounts, and the permission boundaries applied to each user. For a healthcare organization, this constitutes a disclosure of which systems and external parties are authorized to access clinical data via SFTP — organizational intelligence that should remain under the data controller's control.
# SFTPGo: EU-hosted SFTP server with equivalent user management
# All user configs, SSH keys, and access logs stored in YOUR infrastructure
# Create SFTPGo user with S3-compatible storage backend (MinIO, EU-hosted)
curl -X POST https://sftpgo.eu.internal/api/v2/users \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"username": "hr_payroll_partner",
"status": 1,
"home_dir": "/payroll",
"filesystem": {
"provider": 1,
"s3config": {
"bucket": "eu-payroll-landing",
"endpoint": "https://minio.eu.internal",
"region": "eu-central-1",
"access_key": "internal-key",
"access_secret": "internal-secret"
}
},
"public_keys": ["ssh-rsa AAAA... payroll-partner-key"],
"permissions": {"/": ["list", "upload"]}
}'
# User config stored in YOUR PostgreSQL (EU-hosted), not in AWS Transfer Family
# SSH public key stored in YOUR database, not in AWS service state
GDPR Exposure Point 3: Transfer Activity Logs as Personal Data Processing Records
AWS Transfer Family logs all file transfer events to Amazon CloudWatch. Each log entry records the SFTP/FTPS session details: the authenticated username, client IP address, session start and end times, and file operations performed (file uploaded: filename, file size, S3 destination; file downloaded: filename, source S3 path; directory listing: path).
For organizations using Transfer Family to transfer personal data files, these CloudWatch logs constitute records of personal data processing events. A log entry showing that user hr_payroll uploaded employee_records_2026_Q1.csv to s3://landing-zone/payroll/ at timestamp T is a record that personal data (employee records) was processed at a specific time by a specific authorized user. A log entry showing that user healthcare_partner downloaded patient_discharge_records.pgp reveals that special category health data (GDPR Art. 9) was transferred to an external party at a specific time.
Under GDPR Art. 5(1)(e) (storage limitation), personal data must not be retained longer than necessary for processing purposes. Transfer Family CloudWatch logs retain transfer activity records with configurable retention periods — but the default retention does not automatically align with GDPR storage limitation requirements. Organizations must actively configure CloudWatch log retention to match their GDPR data retention policies.
Under CLOUD Act, CloudWatch logs for Transfer Family activity — regardless of whether they are treated as "personal data" in the organization's GDPR documentation — are stored in AWS CloudWatch under US jurisdiction and subject to compelled disclosure. For healthcare organizations, Transfer Family CloudWatch logs could reveal patterns of patient data transfer activity. For financial organizations, they could reveal the timing and volume of payment file processing. This operational intelligence should be under the data controller's jurisdictional control.
GDPR Exposure Point 4: Transfer Family Workflows as Encoded GDPR Processing Logic
Transfer Family Workflows define automated processing steps triggered by file upload events. A workflow configuration might specify: after upload, copy the file to s3://processed/, apply tag {data-category: pii, consent-required: true}, invoke Lambda function validate-consent-status, and on successful validation, move the file to s3://consented-data/. If validation fails, move the file to s3://quarantine/ and send an SNS notification.
This workflow encodes GDPR processing logic: files containing personal data are tagged with classification metadata, validated for consent status before processing, and quarantined if consent validation fails. The operational GDPR compliance logic — consent checking, classification tagging, quarantine routing — is defined in the Transfer Family Workflow configuration under AWS jurisdiction.
Under GDPR Art. 32 (security of processing), technical and organizational measures must ensure a level of security appropriate to the risk. The workflow configuration that implements consent checking and data classification is itself a security measure: it prevents unconsented personal data from entering the processing pipeline. Storing this security measure's configuration in US-jurisdiction AWS service state creates the same structural paradox as AWS Lake Formation's row-level filter expressions — the GDPR compliance mechanism is exposed to the jurisdiction it is designed to provide protection from.
# EU-native equivalent: SFTPGo event actions for post-upload processing
# Workflow config stored in YOUR SFTPGo instance, not in AWS
sftpgo_event_action = {
"name": "gdpr_pii_workflow",
"type": 1, # HTTP action type
"options": {
"http_config": {
"endpoint": "https://workflow.eu.internal/api/process-upload",
"method": "POST",
"headers": [{"key": "Content-Type", "value": "application/json"}],
"body": '{"path": "{{.VirtualPath}}", "user": "{{.Name}}", "size": {{.FileSize}}}',
"timeout": 30
}
}
}
sftpgo_event_rule = {
"name": "pii_upload_trigger",
"trigger": {"type": 1}, # File upload trigger
"conditions": {
"fs_events": ["upload"],
"name": {"pattern": ["*.csv", "*.pgp", "*.xml"]},
},
"actions": [{"name": "gdpr_pii_workflow"}]
}
# All workflow definitions stored in YOUR SFTPGo PostgreSQL database
# CLOUD Act has no reach to your EU-hosted SFTPGo instance
GDPR Exposure Point 5: AS2 Connector Partner Profiles as B2B Relationship Documentation
AWS Transfer Family AS2 Connectors implement the AS2 protocol for secure B2B file exchange. An AS2 connector configuration stores the complete trading partner profile: the partner's AS2 identifier, their X.509 public certificate (used to encrypt outbound files for the partner and verify inbound file signatures), MDN settings (signed vs. unsigned acknowledgment, synchronous vs. asynchronous MDN), and the S3 destination bucket for received files.
AS2 trading partner profiles constitute organizational documentation of B2B data exchange relationships. For a financial services firm, the AS2 connector configuration reveals: which banking counterparties exchange payment files with the organization, what encryption certificates those counterparties use, and which S3 buckets receive their financial data transfers. For a healthcare organization, AS2 connector configurations may reveal which health information exchange (HIE) partners or payer organizations exchange clinical data files.
Under GDPR Art. 28, sub-processor relationships and data sharing with processors require documented agreements. B2B file exchange partners receiving personal data are processors or sub-processors in the GDPR sense if they process the data on the controller's behalf. The AS2 connector configuration documents these processing relationships at the technical level: it names the processing partners, specifies the encryption used for data transfers, and maps the data flow from the connector to the S3 landing zone.
Under CLOUD Act, a demand for Transfer Family AS2 connector configurations would yield the organization's complete B2B personal data exchange architecture: all trading partners, the encryption certificates used for data exchange, and the S3 destinations where partner-transferred data lands. For financial organizations, this constitutes disclosure of the complete payment data exchange ecosystem. For healthcare organizations, it reveals the clinical data sharing partner network.
GDPR Exposure Point 6: Custom Hostname and TLS Certificate Configuration Under SFTP Standards
AWS Transfer Family supports custom domains: organizations can configure their Transfer Family SFTP endpoint to appear as sftp.company.eu rather than the default AWS endpoint. Custom hostname configuration requires a TLS/SSL certificate for FTPS endpoints, stored in AWS Certificate Manager (ACM) under US jurisdiction.
The combination of custom hostname configuration and TLS certificate storage reveals the organization's file transfer endpoint topology. A custom SFTP hostname sftp.company.eu associated with a Transfer Family endpoint documents that the organization operates managed SFTP infrastructure on AWS. The ACM certificate for that hostname — its public certificate, validity period, and associated hostname — is stored in AWS ACM under US jurisdiction.
Under GDPR's accountability principle (Art. 5(2)), data controllers must be able to demonstrate compliance with data protection principles. The technical infrastructure documentation — where SFTP endpoints are hosted, what TLS certificates secure them, what network paths personal data takes during file transfer — is part of the compliance evidence that controllers should maintain under their own jurisdictional control.
For organizations transferring special category data (health records, financial records, data revealing trade union membership) via SFTP, the endpoint configuration and TLS certificates are part of the Art. 32 security of processing documentation. Storing this security infrastructure documentation in US-jurisdiction AWS services creates CLOUD Act exposure for the organization's file transfer security architecture.
EU-Native Alternatives to AWS Transfer Family
The managed SFTP, FTPS, and AS2 capabilities of AWS Transfer Family are available in fully open-source and self-hostable form, deployable on EU-jurisdiction infrastructure.
SFTPGo is the most comprehensive open-source alternative to AWS Transfer Family. It provides managed SFTP, FTPS, FTP, WebDAV, and HTTP endpoints with a full REST API for user management, event action workflows, and storage backend configuration. SFTPGo supports pluggable storage backends: local filesystem, S3-compatible storage (MinIO on EU-hosted hardware), Google Cloud Storage, and Azure Blob Storage. User management, SSH key storage, transfer activity logging, and event workflows are all maintained in a self-hosted PostgreSQL database.
# Deploy SFTPGo on sota.io EU-native PaaS
# sota.io runs in Frankfurt — no CLOUD Act jurisdiction
# docker-compose.yml for SFTPGo on sota.io
version: "3.8"
services:
sftpgo:
image: drakkan/sftpgo:latest
ports:
- "2022:2022" # SFTP
- "2121:2121" # FTP
- "8080:8080" # REST API + Web UI
environment:
- SFTPGO_DATA_PROVIDER__DRIVER=postgresql
- SFTPGO_DATA_PROVIDER__NAME=sftpgo
- SFTPGO_DATA_PROVIDER__HOST=postgres
- SFTPGO_DATA_PROVIDER__USERNAME=sftpgo
- SFTPGO_DATA_PROVIDER__PASSWORD=${SFTPGO_DB_PASSWORD}
- SFTPGO_HTTPD__BINDINGS__0__ENABLE_WEB_ADMIN=true
- SFTPGO_HTTPD__BINDINGS__0__ENABLE_WEB_CLIENT=true
volumes:
- sftpgo-data:/srv/sftpgo
postgres:
image: postgres:16-alpine
environment:
- POSTGRES_DB=sftpgo
- POSTGRES_USER=sftpgo
- POSTGRES_PASSWORD=${SFTPGO_DB_PASSWORD}
volumes:
- pgdata:/var/lib/postgresql/data
# All user configs, SSH keys, transfer logs stored in YOUR PostgreSQL
# Deploy on sota.io for EU-jurisdiction managed SFTP without AWS dependency
OpenSSH SFTP Server is the baseline EU-native SFTP option. The OpenSSH SFTP subsystem (configured via Subsystem sftp /usr/lib/openssh/sftp-server) runs on any EU-hosted Linux server. With chroot jails for user home directories, authorized_keys file management, and rsyslog-based transfer logging, OpenSSH provides compliant SFTP file transfer with all configuration and logs under your control. The limitation compared to Transfer Family is operational: user management requires manual SSH key file management rather than a REST API, and there is no native S3 backend (though s3fs-fuse or rclone can map S3-compatible storage to SFTP home directories).
GoFTP (GoAnywhere MFT) is a commercial managed file transfer platform with EU deployment options. GoAnywhere provides SFTP, FTPS, FTP, AS2, and HTTPS endpoints with a graphical workflow designer for post-transfer processing. It supports EU-only on-premises or cloud deployment. For organizations needing AS2 B2B capabilities equivalent to Transfer Family AS2 Connectors, GoAnywhere's AS2 module is the most functionally comparable option in the EU-hosted commercial space.
Axway SFTP and Cleo Integration Cloud provide enterprise MFT capabilities including AS2 B2B protocol support with EU deployment options. These are appropriate for large enterprise deployments with complex EDI trading partner networks requiring AS2 with signed and encrypted message exchange.
Stalwart and Caddy with SFTP plugins cover simpler SFTP use cases at lower operational overhead than SFTPGo, though with fewer management API capabilities.
A complete EU-native managed file transfer architecture:
# EU-native file transfer: SFTPGo + MinIO + PostgreSQL on sota.io
# Replaces: Transfer Family + S3 + CloudWatch
# SFTPGo transfer event logging (equivalent to CloudWatch activity logs)
# but stored in YOUR PostgreSQL — not in AWS CloudWatch
# Configure SFTPGo transfer log to structured JSON in PostgreSQL
sftpgo_config = {
"common": {
"upload_mode": 0,
"actions": {
"execute_on": ["upload", "download", "delete"],
"execute_sync": ["upload"],
"hook": "https://audit.eu.internal/sftp-event"
},
"transfer_log": {
"max_size": 10485760,
"log_file": "/var/log/sftpgo/transfers.log"
}
},
"data_provider": {
"driver": "postgresql",
"name": "sftpgo_prod",
"host": "postgres.eu.internal",
"port": 5432,
"username": "sftpgo",
"password": "${DB_PASSWORD}",
"sslmode": "require"
}
}
# Transfer logs in YOUR PostgreSQL — no CloudWatch, no CLOUD Act
# Audit hook posts to YOUR SIEM in EU jurisdiction
# AS2-equivalent B2B file exchange with Mendelson AS2 (open-source)
# https://sourceforge.net/projects/mec-as2/
# Stores partner certificates and MDN configs in YOUR embedded database
# Deploy Mendelson AS2 on sota.io for EU-jurisdiction AS2 B2B exchange
The Art. 32 Security of Processing Argument
GDPR Art. 32 requires that data controllers and processors implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. For organizations transferring personal data files via SFTP or AS2, the security measures required under Art. 32 include: encryption in transit (satisfied by SFTP/FTPS/AS2), access control (SSH key management, certificate-based authentication), and logging and monitoring (transfer activity records).
AWS Transfer Family satisfies the technical requirements of Art. 32 for personal data file transfers — it provides encrypted transfer protocols, managed authentication, and activity logging. The Art. 32 gap is jurisdictional: the security infrastructure (authentication configuration, access logs, workflow definitions) is implemented in US-jurisdiction AWS services subject to CLOUD Act.
The Art. 32 requirement for "appropriate technical and organizational measures" extends to the security of the security infrastructure itself. SSH key management, transfer activity logging, and workflow configuration are security measures — they should be implemented with the same jurisdictional protection applied to the personal data they protect. A CLOUD Act-accessible log of who transferred which personal data files undermines the confidentiality protections that Art. 32 requires.
Self-hosted SFTPGo on EU-jurisdiction infrastructure closes this Art. 32 gap: the authentication configuration, transfer logs, and workflow definitions are stored in your EU-hosted PostgreSQL database, under your jurisdictional control, with no CLOUD Act exposure pathway.
NIS2 and Managed File Transfer for Critical Infrastructure
NIS2-regulated entities using managed file transfer for operational data exchange — energy companies exchanging grid configuration files, healthcare providers transferring clinical data, financial firms exchanging payment files — face NIS2 supply chain security requirements (Article 21(2)(d)) that apply to their file transfer service providers.
Transfer Family is an AWS-managed service: AWS manages the server infrastructure, authentication backend, and logging pipeline. Under NIS2's supply chain security requirements, an energy company using Transfer Family to exchange operational data with grid operators must assess AWS as a supply chain component. NIS2's emphasis on resilience and avoidance of supply chain dependencies relevant to operational security extends to the file transfer layer.
For critical infrastructure operators under NIS2, self-hosted SFTPGo or OpenSSH SFTP server on EU-owned infrastructure eliminates the supply chain dependency on AWS for file transfer operations. The file transfer service is operated by the entity itself, eliminating the external supply chain exposure that NIS2 Article 21(2)(d) requires assessment of.
Summary
AWS Transfer Family's GDPR exposure under CLOUD Act spans six structural characteristics: server endpoint configurations map the organization's personal data transfer infrastructure under US jurisdiction, service-managed SSH key storage in Transfer Family reveals authorized SFTP user identity mappings, CloudWatch activity logs record personal data file transfer events under US jurisdiction, Transfer Family Workflows encode GDPR processing logic (consent checking, data classification) in AWS-managed configuration, AS2 Connector partner profiles document B2B personal data exchange relationships under CLOUD Act reach, and custom hostname and TLS certificate storage documents the file transfer security architecture in US-jurisdiction ACM.
All six exposures share the same root: AWS Transfer Family's management plane — the configuration, authentication, logging, and workflow layer — is stored in AWS-managed US-jurisdiction infrastructure. The service that manages personal data file transfers manages that process under CLOUD Act reach.
SFTPGo on EU-jurisdiction infrastructure provides equivalent managed SFTP, FTPS, FTP, and WebDAV capabilities with complete control over authentication configuration, transfer activity logs, and event workflow definitions. For AS2 B2B exchange, open-source Mendelson AS2 or commercial GoAnywhere MFT provide AS2 protocol support with EU deployment. All configuration, SSH keys, transfer logs, and partner profiles remain in your EU-jurisdiction database, without CLOUD Act exposure.
Deploying SFTPGo on sota.io's EU-native PaaS in Frankfurt provides the operational environment for GDPR-aligned managed file transfer: encrypted SFTP/FTPS endpoints, REST API user management, and event-driven workflow configuration — all managed and logged entirely within EU jurisdiction.
Part of the sota.io EU Compliance Series — practical GDPR analysis for developers deploying on AWS.
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.