This document describes possible strategies for building and hosting the Exposure Notification Server components. You should use this information explore and compare trade-offs when making hosting decisions.
The Exposure Notifications Server can be deployed in the following environments:
- Fully self-hosted or on-premises
- Fully managed Google Cloud
- A combination of self-hosted and fully managed
For more details on each component, see the Server Functional Requirements.
The Exposure Notification Server has multiple components which can be categorized as compute and data. To understand deployment scenarios, you should look at the architecture of the server and data flow between servers and devices.
The Exposure Notification Server compute components have been designed to be stateless, scalable, and rely on data stored in a shared databased. This makes the compute components suited to deployment on serverless compute platforms.
Serverless platforms can scale down to zero during times of zero usage, which is likely if the Exposure Notification Server deployment covers a single or small number of countries. During times of high demand, serverless platforms can scale to meet demand.
| Purpose | Fully Hosted Google Cloud | Self-hosted, Google-managed | Self Hosted Kubernetes | |
| Data components | ||||
| Tracing key database | Stores anonymized exposure keys from devices identified as exposed | Google Cloud SQL (PostgreSQL) | PostgreSQL hosted with on-prem Kubernetes | PostgreSQL on Kubernetes |
| Tracing key batches storage | Storing batches of tracing keys that will be sent to devices. | Google Cloud Storage | Open Source Blobstore hosted with on-prem Kubernetes | Kubernetes hosted Open Source Blobstore (ie. min.io, rook). Could also use Redis and reconstruct batches |
| Certificate and key storage | Secure Storage for secrets such as signing, private keys, etc. | Secret Manager | Anthos GKE on Prem + KMS | HashiCorp Vault |
| Compute components | ||||
| Tracing key ingestion server | Ingestion of exposure keys from client devices. | Google Cloud Run | On-prem Kubernetes with Cloud Run for Anthos GKE on-prem | Kubernetes with Knative Serving |
| Exposure Reporting Server | Serves anonymous keys of exposed users | Google Cloud Storage + Google Cloud CDN | On-prem Kubernetes with Anthos GKE on-prem, Or Google Cloud CDN | Kubernetes with Knative Serving + Redis |
| Data deletion | Deletion of data that is older than a configured time limit. | Google Cloud Run | On-prem Kubernetes with Anthos GKE on-prem | Kubernetes, either a job or Knative Service |
| Batch tracing keys | Periodic DB queries to batch data for client consumption. Signing payloads for verification on device. | Google Cloud Run | On-prem Kubernetes with Anthos GKE on-prem | Kubernetes, either job or Knative Service |
| Periodic data batching and deletion | Used to control running of periodic jobs (deletion, batching) | Google Cloud Scheduler | Kubernetes Cronjobs | Kubernetes Cronjobs |
| Content delivery network | Distribution of keys to client devices | Google Cloud CDN | Third Party CDN, Redis + Server, or allow direct access to storage | Third Party CDN, Redis + Server, or allow direct access to storage |
| Optional components | ||||
| Federated ingestion | Ingestion of keys from other parties. | Google Cloud Run | On-prem Kubernetes with Anthos GKE on-prem | Kubernetes with Knative Serving |
| Federated acesss | Allows other parties/countries to retrieve data | Google Cloud Run | On-prem Kubernetes with Anthos GKE on-prem | Kubernetes with Knative Serving |
You can host all components of the Exposure Notification Server on-premises.
Deploying compute and data components on-premises allows you to have complete control of all components and deploy them in any location by using an on-premises Google Kubernetes Engine cluster. However, an on-premises deployment will require you to configure and maintain the underlying infrastructure, and ensure it is able to meet usage demands.
When the Exposure Notification Server is deployed on-premises, we recommend you deploy audit and access logging to the data and API endpoints. This is automatically available in the fully managed, and hybrid deployment scenarios.
The Exposure Notification Server supports either compute or data components to be hosted on-premises or on Google Cloud.
This example deployment has compute components running on Google Cloud Serverless products, with databases hosted on-premises. Alternatively, you could use an Anthos cluster to host compute components on premises, and have the data components hosted on Google Cloud as a fully managed service.
This example deployment hosts all components of the system on Google Cloud.
By using fully hosted components most of the service’s operation can be delegated to Google Cloud, which will provide audit and access logging of the data. For example, Cloud SQL will manage the infrastructure for a hosted PostgreSQL database.
This solution requires hosting within a Google Cloud location which may not exist in a location that permits use for all parts of the Exposure Notification Server architecture.