Cross Cloud Dependencies

This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
sxuereb devops tenant-scale 2025-07-21

Context

Cells will be running both on AWS and GCP cloud providers. This adds complexity since we have to provision a Cell on both cloud providers independently.

Decision

To provision a Cell in one cloud provider, we should not depend on the other cloud provider.

For example:

+Benefits of this separation:

  • Clean architecture: Our codebase will maintain clear separation between cloud providers.
  • Cost optimization: Eliminates cross-cloud ingress/egress costs.
  • Improved resiliency: If there is an outage on a single cloud provider, we can still operate Cells on the other provider.

Consequences

  • Data duplication: We will need to duplicate some data across clouds (Docker images, Helm charts), but this represents only a few GB of data.
  • Increased maintenance: Managing duplicate infrastructure components will require additional operational overhead.
  • Synchronization complexity: We must ensure consistency of artifacts across both cloud providers. This increases the risk of configuration drift between AWS and GCP environments which could result in difficult to debug issues or incidents.

Alternatives

Use one cloud provider as the primary source for shared resources (example; root CA in GCP only). This was rejected due to cross-cloud dependencies and potential single points of failure.

Last modified July 22, 2025: ADR: Cells Cross Cloud Dependencies (1d034b11)
View page source - Edit this page - please contribute. Creative Commons License