Centralizing Partner File Exchange Across AWS Accounts

Ampity deployed one Transfer Family SFTP endpoint that writes partner files directly into business-unit S3 buckets, with account-specific access policies and central...

[Problem] Partners needed one entry point without combining account ownership

The customer had business units operating in separate AWS accounts. Partners needed to deliver files, but running a separate SFTP server for each business unit created additional infrastructure and administration. Consolidating the entry point could simplify that arrangement, provided it did not also collapse the destination accounts' storage and access boundaries.

Ampity deployed a new hub-and-spoke file-exchange platform using AWS Transfer Family. The hub supplied the SFTP endpoint. Files were written directly to S3 buckets in the destination business-unit accounts. The source describes this as a new platform deployment, not a migration of every file-processing application into the hub.

This public account keeps the customer unnamed. It covers partner file arrival, access mapping, object ownership and transfer visibility. The customer's application runtime and forecasting pipeline were separate workstreams. Their services, tests and outcomes are not added to this file-exchange case.

[Decision] Centralize the endpoint, keep storage in the receiving accounts

A single endpoint and a single storage account are different design decisions. This implementation centralized the first while retaining distributed storage ownership. Transfer users mapped to logical home directories pointing into destination-account buckets, with IAM roles and bucket policies enabling the required access.

The file did not first rest in a hub bucket and then get copied to its final destination. The documented design wrote it into the receiving business unit's bucket. That avoided adding an undocumented staging or replication step to the public architecture.

AWS documents how Transfer Family logical directories map the paths users see to storage locations. A logical path is not a replacement for IAM or bucket-policy authorization. In this case, both the mapping and the cross-account permissions were part of the delivery.

[Boundary] Access mapping, authorization and ownership must agree

The hub's Transfer role needed access to the relevant destination path. The destination bucket policy had to permit that access. Object ownership then had to leave the receiving account able to read the uploaded file. Successful SFTP authentication alone would not prove any of those downstream conditions.

The diagram separates the endpoint account from the destination accounts. It shows the direct storage relationship and the controls described by the source. It does not depict all network routes, key policies or partner-specific permissions. Those details belong in the implementation configuration and access review.

[Delivery] Configure both sides before testing the transfer

Ampity defined the cross-account role and policy relationships, configured destination bucket policies, provisioned the central endpoint and mapped users to the appropriate cross-account paths. The source also records KMS encryption, VPC and security-group configuration, Route 53 and Terraform provisioning.

End-to-end validation checked connectivity and confirmed that files were accessible from the destination accounts. This was a stronger acceptance check than confirming that an external client could establish an SFTP session. The receiving account needed to use the file after upload.

The account does not provide the complete negative-access test matrix. It should not be read as proof that every unauthorized prefix, key-policy failure or interrupted transfer was tested. Those are useful acceptance scenarios for a new deployment, but they are not additional tests attributed to this engagement.

[Result] One endpoint with direct delivery and central logs

The delivered platform gave partners a central entry point while leaving destination files in the appropriate business-unit accounts. The source records the ownership configuration and end-to-end accessibility checks, along with central logging of authentication attempts and transfers.

A historical summary reports consolidation savings but does not include a complete cost baseline or measurement period. This revision therefore describes the delivered operating change without repeating a percentage-saving claim. It also removes the older assertion of a measured availability level, since the manuscript does not supply its observation window.

Consolidating an endpoint changes the operational concentration of the service. It does not eliminate endpoint administration, partner onboarding, permission reviews or the need to plan recovery. Those responsibilities still require named owners.

[Review] Acceptance checks for another deployment

Before adopting this pattern, use a partner-by-destination access matrix. For every allowed route, establish the expected login identity, logical path, destination bucket and prefix, encryption permissions and receiving-account reader. Record both a successful upload and a successful destination read against the intended configuration.

Then check a denied route: a partner should not gain access to another business unit merely because both use the same endpoint. Test what operators see when a write is denied, a key is unavailable or a transfer stops partway through. Agree how the receiving application recognizes a complete file before consuming it.

Those checks are recommendations for a future implementation. The delivered case establishes the central endpoint, direct cross-account placement, ownership work and destination accessibility validation. Discuss a partner file-exchange requirement.