Engineering a multicloud future: 
Verily Workbench now supports AWS

Biomedical research is inherently collaborative — data flows between academic institutions, pharmaceutical companies, and healthcare systems, each with its own cloud infrastructure. To enable this work, platforms must meet researchers where they are

Verily Workbench, built on Pre, has historically leveraged the native architecture of Google Cloud Platform (GCP). Many research teams have infrastructure investments in other cloud providers. To reach a wider audience, we’ve evolved Workbench to support AWS.

Today, we explore the engineering philosophy and technical architecture behind our latest milestone: support for Amazon Web Services (AWS) within Workbench. Researchers can now use Workbench’s governance, analysis, and collaboration capabilities with AWS infrastructure and specialized services.

This architecture required reimagining how we handle identity and isolation. We’ve outlined the core concepts below. Full engineering specifications, including our multicloud resource model and the 'cloud sync' mechanisms for IAM, are detailed in our technical deep dive whitepaper.

Workbench is a Trusted Research Environment (TRE). This infrastructure enables biomedical researchers to securely manage sensitive government-funded datasets while maintaining mandatory compliance. Learn more about the value of Workbench.

Workbench is built on hierarchical concepts: Organizations, Pods, and Workspaces that manage tenancy, billing, and resource lifecycles. These concepts naturally map to GCP's architecture, e.g., where each Workspace corresponds to a GCP Project.

The core engineering challenge is maintaining a secure, consistent TRE experience across multiple cloud providers, each with distinct native architectures and operational models. Translating these concepts to AWS required fundamentally rethinking our backend infrastructure.

Core concepts

• Organizations: Top-level entities that represent institutional boundaries and administrative domains
• Pods: Link cloud resource consumption (such as storage and compute costs) to a specific billing profile (e.g., a grant or department budget)
• Workspaces: Secure containers for data, code, and tools
• Resources: Computing, storage, and analytical services provisioned within workspaces

These concepts are cloud-agnostic in theory, but implementation varies across cloud providers.

GCP approach

On GCP, the mapping is straightforward. A Pod maps to a GCP Billing Account, while a Workspace maps 1:1 to a GCP Project. This provides built-in resource encapsulation: deleting a workspace also deletes the associated project and all its controlled resources.

AWS approach

AWS does not offer a direct equivalent to the ephemeral GCP Project, and creating a new AWS Account for every workspace is not scalable. To solve this, Verily engineered a “Landing Zone” architecture:


• The Pod (AWS Account): A Workbench Pod maps to a single AWS Account

• The Landing Zone: Within that account, Infrastructure as Code (Terraform) deploys shared regional infrastructure, including VPCs, subnets, and NAT gateways

• The Workspace (software-defined): Workspaces are not separate accounts. Instead, resources such as EC2 instances are provisioned in the shared Landing Zone. Isolation is enforced through software-defined boundaries like Security Groups and IAM policies, not account boundaries.

A true multicloud platform must reconcile conflicting identity models. While both cloud providers support hybrid approaches, Workbench utilizes these distinct models to align with each platform's native strengths.

Identity model comparison

Research often requires access to data residing in external accounts owned by other institutions (“Referenced Resources”). The engineering approach here diverges to respect cloud-native patterns.

Our core philosophy for multicloud is to unify the experience where it adds value, but diverge where needed to show the unique power of each cloud.

We unify foundational elements such as object storage and virtual machines, ensuring code remains portable. We also expose specialized, platform-native services as first-class resources. This lets researchers using Workbench on AWS leverage Amazon HealthOmics, while those on GCP can use BigQuery, without being limited to a lowest-common-denominator feature set.

By abstracting the control plane and respecting each cloud provider’s unique architecture, we provide a consistent Trusted Research Environment that enables researchers to take advantage of cloud-specific tooling if desired.

Our AWS integration is a testament to Verily's commitment to quality engineering, delivering a robust control plane that transparently handles cloud-native complexities like Landing Zones and ABAC. Researchers are empowered with a secure, consistent environment, fully equipped with the expected features, that dramatically accelerates evidence generation regardless of where the data resides.