US-West is live: inside our second US data residency region

As of May 5th, our US-West region is in general availability. Customers can now designate their workspace to run in US-East (our original region, in AWS us-east-1) or US-West (the new region, in AWS us-west-2). This post covers why we built it, the architecture trade-offs we made, and what changes in practice for customers who want to use it.

Why a second US region

Three drivers, in order of weight.

Blast-radius isolation. Our most common customer concern about single-region deployments isn’t latency — it’s correlated failure. When you store regulated data in a single cloud region, a regional outage takes down both your production path and your ability to recover from that outage. The data isn’t gone, but it’s inaccessible, and for customers with time-sensitive transfer workflows — healthcare clearinghouses, financial services settlement processes, government contractor submissions — even hours of inaccessibility is a compliance and contractual exposure.

A second region solves this by allowing customers to designate their workspace to a region such that their data has no dependency on the availability of the other region. We’re not selling synchronous cross-region replication — we’ll explain why in the next section — but we are providing true blast-radius isolation: a failure in US-East has no path to affecting a US-West workspace.

Customer-driven data residency. Several customers have contractual or regulatory requirements that specify where their data must reside within the United States. State-level data residency requirements in certain regulated sectors specify geographic boundaries more granular than “United States.” Defense contractor customers with specific data handling requirements have sometimes needed to demonstrate that data does not transit certain network paths. A second US region gives us the ability to honor these requirements with architectural specificity, not just policy assertions.

Latency for western-geography customers. The honest answer is that this is the smallest of the three drivers but it’s real. Customers headquartered on the West Coast or in Mountain time zones who are exchanging files primarily with other western-geography organizations see meaningfully better upload and download latency when their workspace is in US-West. For large file transfers — the 500 MB radiology files and multi-gigabyte transaction datasets our customers routinely move — 40–60 ms of round-trip improvement compounds across multi-part upload flows into noticeable wall-clock time reduction.

The architecture: region pairing without cross-region replication

The design question we spent the most time on was whether to build synchronous cross-region replication — the pattern where data written in one region is immediately mirrored to the other, giving you an active-active or active-passive failover capability.

We decided against it, for a reason that’s directly relevant to regulated workloads: cross-region replication creates data residency ambiguity. If a customer designates their workspace to US-West with the requirement that their data remain in specific geographic bounds, and we automatically replicate that data to US-East for disaster recovery purposes, we’ve undermined the data residency guarantee. The customer needs to know that “US-West” means the data actually stays there.

The architecture we built instead provides blast-radius isolation through regional independence: each region is a fully self-contained deployment with its own storage, compute, key management, and control plane. Workspaces are assigned to exactly one region at creation time. Data written to a workspace does not leave that region. Backup and recovery for each region uses storage within the same region.

The trade-off is that this is not an automatic failover architecture. If US-West goes down, US-West customers experience an outage. We’re honest about this. What we can promise is that a US-West outage has no effect on US-East customers, and vice versa — the failure domains are fully isolated.

For customers who need both data residency guarantees and multi-region redundancy, we support a workspace-per-region configuration: primary operational workflows in US-West, a separate workspace in US-East for backup or redundant workflows. This requires deliberate configuration by the customer and explicit acknowledgment that data will exist in both regions. We don’t do it automatically.

The control plane — authentication, workspace management, billing — runs in a separate, multi-region deployment with different availability characteristics from the data plane. A regional data-plane outage does not affect the control plane.

Key management. Each region has its own AWS KMS infrastructure. Encryption keys for US-West workspaces are generated and stored in US-West KMS. The key material does not replicate to US-East. For customers using customer-managed KMS keys (our BYOK feature), the external KMS must be reachable from US-West; we recommend configuring an AWS KMS key in us-west-2 for US-West workspaces.

DNS and traffic routing. We use regional endpoints (us-west.send-securely.com and the existing us-east.send-securely.com) with workspace-level routing at the API layer. The customer-facing URL for downloads and API access resolves to the workspace’s home region. There is no latency-based or health-based traffic routing between regions — routing is deterministic based on workspace assignment.

What changes for customers

New workspaces. Starting today, new workspaces can select US-West at creation time. The default remains US-East for accounts where no preference is specified.

Existing workspaces. Existing workspaces remain in US-East. Migration to US-West is available but requires explicit opt-in — it is not automatic. Migration involves creating a new US-West workspace, transferring configuration, and moving any data you want to retain in the new region. We have migration tooling in the admin console and documentation for the migration path. Contact support to initiate.

Per-workspace residency override. Enterprise plan accounts can set a default region for new workspaces at the account level via the admin API. This is useful for organizations that want all workspaces to default to US-West without manually specifying at each workspace creation. The override applies to new workspaces only and does not migrate existing workspaces.

SFTPconnections. SFTP endpoints are region-specific. If you’re running SFTP integrations pointing at the existing endpoint, those continue to reach US-East workspaces. US-West workspaces have a distinct SFTP endpoint hostname. Update your SFTP partner and system configurations after migration.

Compliance documentation. We’ve updated our SOC 2 readiness documentation scope to include US-West. Our HIPAA Business Associate Agreement, FedRAMP-ready documentation, and NIST 800-171 mapping materials are updated to cover both regions. The trust portal reflects the updated scope.

Migration path

For organizations that need to migrate an existing workspace from US-East to US-West, the process is:

1. Create a new workspace in US-West via the admin console.
2. Export workspace configuration (transfer policies, access controls, integrations, webhook endpoints) from the US-East workspace using our export API.
3. Import configuration to the US-West workspace.
4. Validate the configuration in the new workspace with test transfers.
5. Update all integration endpoints — SFTP hostnames, API base URLs, webhook delivery URLs — to point to the US-West workspace.
6. Cut over production traffic.
7. Archive or delete the US-East workspace.

We’re not aware of a migration that breaks anything in production if the configuration export/import is complete. The primary failure mode is an integration that points to the old workspace endpoint after cutover — which is why step 5 is the most important and most time-consuming part.

The average migration time for a workspace with a moderate number of integrations is two to three days of coordinated configuration work. For workspaces with many SFTP partners, allow additional time for partner coordination (see our MFT migration playbook from March for guidance on partner outreach).

US-West is live now. If you have questions about residency requirements, migration, or KMS configuration for the new region, the support team is ready.