Engineering a multicloud future: Verily Workbench now supports AWS Skip to main content Solutions Pre The AI-native platform for precision health Lightpath Personalized care to help members manage their health Viewpoint A solution suite to accelerate clinical research Sightline Solutions to monitor and mitigate population-level disease Introducing Verily Me A personal, private companion to help members manage their health. Perspectives N of 1 seriesPrecision health blogPress releasesPublicationsTech blogWebinars N of 1 series A documentary series that highlights the promise of precision health View all perspectives About us Our storyCareersNewsLeadershipContact us Bringing the promise of precision health to everyone, every day. Invalid URL Invalid URL Invalid URL Tuesday, April 14, 2026 Perspectives / Tech Blog / Engineering a multicloud future: 
Verily Workbench now supports AWS Author John Czerkowicz Published Tuesday, April 14, 2026 Share Invalid URL Invalid URL Invalid URL 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. The challenge: Mapping abstractions to reality 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. Workbench's multicloud architecture: Compares GCP's 1:1 workspace-to-project mapping with AWS's shared Landing Zone approach for multiple software-defined workspaces within a single Pod (AWS Account). 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. Reimagining identity: From RBAC to ABAC 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 FeatureRBAC (Role-Based Access Control)ABAC (Attribute-Based Access Control)Primary CloudGCPAWSControl modelGoogle groups: Workbench manages static group memberships (e.g., adding a user to ws-12345-writers)Session tags: Workbench utilizes a secure role-chaining process. The Workspace Manager injects session tags (e.g., vwb-workspace-id) into temporary credentialsAuthorization mechanismIdentity-based: IAM policies bind permissions directly to the Google Group email addressTag-based: A central IAM policy compares tags. It effectively asks: "Does the resource's workspace ID match the user's session workspace ID?"External data accessDirect grant: The external data owner simply grants access to the Workbench Google Group email addressTwo-way trust: Users assume a specific "External Access" IAM role carrying session tags. External owners write fine-grained bucket policies that condition access on those specific tags Solving for external data access 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. PlatformGCPAWSCore mechanismDirect group grantsTwo-way trust handshakeIdentity usedWorkbench Google GroupsDedicated “Workbench external access” IAM RoleThe processThe external data owner simply grants access permissions to the specific Workbench Google Group email address.Users assume the dedicated IAM role. This role carries specific session tags that identify the user’s current workspace.Security granularityGroup-based: Access is strictly tied to group membership.Tag-based (fine-grained): External owners write bucket policies that condition access on specific tags (e.g., vwb-12345: "writer"). This ensures they share data only with a specific workspace, rather than trusting the entire Workbench account. Philosophy: Unify and diverge 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. The multicloud advantage 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. Ready for a deep dive? Get the complete architectural breakdown of Workbench's
AWS integration. Download the technical deep dive whitepaper Related articles Tech BlogEdition 6 Introducing FHIR AgentBench: A new standard for safe, trustworthy Health AI Verily created FHIR-AgentBench, a new benchmark that establishes the standard for accuracy and safety required to build and deploy safer, more reliable health AI systems. Tech BlogEdition 5 Elevating FHIR data quality: A multi-resource approach to comprehensive validation FHIR® (Fast Healthcare Interoperability Resources) is the backbone of modern clinical data pipelines, standardizing data exchange across healthcare systems. More from Verily Verily Pre Platform Verily Viewpoint Verily Lightpath protected by reCAPTCHA