Multi-Cloud Strategy for Defence: Avoiding Vendor Lock-In in Military Systems

Single-cloud dependence is a strategic risk for defence systems that is analytically similar to single-vendor dependence in any other critical capability domain. When a defence programme's entire cloud infrastructure runs on one provider, that provider can exert leverage through pricing, service discontinuation, or contractual changes at programme renewal. Geopolitical developments can complicate or eliminate access to foreign-owned cloud infrastructure. A major cloud outage — AWS us-east-1 failures have affected large portions of the commercial internet — can degrade or eliminate defence operational capabilities that depend on that infrastructure.

Multi-cloud strategy addresses this strategic risk by distributing workloads across multiple providers, maintaining portability at the architecture level, and avoiding deep entanglement with proprietary cloud services that would make migration prohibitively expensive. This article examines how multi-cloud deployment patterns work, how cloud-agnostic Infrastructure-as-Code tools support portability, and how the compliance complexity of maintaining classification controls across providers is managed.

Strategic Risk of Single-Cloud Dependence

Geopolitical risk is the most distinctly defence-relevant risk in cloud provider dependence. The relationship between defence organisations and cloud providers is mediated by political and legal structures that can change. EU data sovereignty legislation (GDPR, national security exemptions, EUCS) creates ongoing legal uncertainty about the long-term legality of storing defence data on US-headquartered provider infrastructure. For defence programmes with 10–20 year lifecycles, a cloud architecture decision made today based on the current political and legal environment may become untenable within the programme's operational life.

Operational risk from outages is a more immediate concern. Major cloud providers experience significant outages: AWS us-east-1 outages in 2021 and 2023 disrupted large portions of the commercial internet for hours. Microsoft Azure has experienced multiple multi-hour global outages. For defence systems with availability requirements (a logistics management system that must support an active operation, a cyber situational awareness platform that must be operational during a threat response), dependence on a single cloud provider with no fallback capability is operationally unacceptable.

Price leverage is a commercial risk with strategic implications. Cloud providers can increase prices at contract renewal; switching costs on deeply entangled architectures make it difficult to respond. DoD's experience with the JEDI and JWCC cloud contract competitions reflected awareness of this risk — the multi-vendor structure of JWCC was explicitly intended to prevent single-vendor lock-in for DoD cloud workloads.

Multi-Cloud Deployment Patterns

Active-active split workloads distribute different workload types across different cloud providers based on each provider's comparative advantages: a defence programme might run classified applications on the provider with the strongest classified cloud accreditations, analytics and ML workloads on the provider with the best ML infrastructure, and collaboration tools on a third EU-sovereign provider for data residency reasons. This pattern extracts maximum value from each provider's strengths but requires careful application-level architecture to avoid data coupling between providers.

Primary-secondary disaster recovery runs production workloads on a primary provider with a warm standby environment on a secondary provider. The secondary environment is maintained at sufficient readiness to take over within a defined RTO (Recovery Time Objective) if the primary fails. This pattern is simpler operationally than active-active — the secondary environment is essentially a copy of the primary — but requires regular failover testing to verify that the secondary can actually take over under realistic conditions.

The appropriate pattern for a given defence programme depends on its availability requirements, operational criticality, and the classification level of its workloads. Programmes with extremely high availability requirements (mission-critical operational systems) may require active-active for the most critical services. Programmes with lower availability requirements but strong sovereignty concerns may adopt primary-secondary with the secondary on a EU-sovereign provider.

Cloud-Agnostic IaC: Terraform and Crossplane

Terraform (from HashiCorp, now a BSL-licensed product with an open-source fork at OpenTofu) is the standard Infrastructure-as-Code tool for cloud-agnostic resource provisioning. Terraform providers exist for all major cloud platforms (AWS, Azure, GCP, OVHcloud, and dozens of others), and Terraform configuration syntax is cloud-agnostic — the same Terraform configuration structure is used regardless of which provider is being provisioned. This means that an IaC engineer familiar with Terraform can work with any provider's resources without learning a provider-specific IaC language.

For multi-cloud architectures, Terraform's workspace and module system allows the same application infrastructure to be instantiated on different providers: a Terraform module for a "three-tier web application" can have provider-specific implementations (one for AWS, one for Azure, one for OVHcloud) that expose the same interface. The programme's infrastructure repository switches between provider implementations by changing the module source — the application-level configuration does not change.

Crossplane is a CNCF-graduated project that provides a Kubernetes-based control plane for cloud resource provisioning. Where Terraform is a CLI tool that manages infrastructure state in a declarative file, Crossplane runs as a Kubernetes controller and manages cloud resources as Kubernetes custom resources. The Crossplane Composition system allows cloud resource abstraction: a Composition defines a composite resource type (e.g., a "DefenceDatabase") that maps to provider-specific resources, allowing application teams to request a DefenceDatabase without knowing whether it is backed by AWS RDS, Azure Database for PostgreSQL, or an on-premises PostgreSQL instance.

Crossplane is particularly valuable for defence programmes adopting a platform engineering model: a central platform team manages the Crossplane compositions and provider configurations, and application teams consume cloud resources through self-service by applying standard Kubernetes manifests. The platform team maintains the provider-specific implementations and can switch or add providers without changing the interface exposed to application teams.

Data Portability: Open Formats and S3-Compatible Storage

Cloud vendor lock-in at the data layer — where data is stored in proprietary formats or services with no standard export mechanism — is the most difficult form of lock-in to escape. Avoiding it requires explicit data portability design:

S3-compatible object storage is the practical standard for cloud-agnostic data storage. Amazon S3's API has become the de facto standard for object storage, with S3-compatible APIs provided by Azure Blob Storage (via S3-compatible endpoint), GCP Cloud Storage, OVHcloud Object Storage, and on-premises solutions such as MinIO (widely used in air-gapped environments). Applications that use S3-compatible APIs for object storage can move between providers by changing the endpoint URL and credentials — the application code does not change.

Standard SQL over managed PostgreSQL-compatible databases avoids the lock-in of proprietary database services (Dynamo DB, Azure Cosmos DB, Google Spanner). PostgreSQL-compatible managed services are available on all major cloud platforms (AWS Aurora PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL, OVHcloud Managed PostgreSQL). Applications using standard SQL and the PostgreSQL protocol can migrate between providers with only configuration changes.

Compliance Complexity: Classification Controls Across Providers

The most significant operational challenge in multi-cloud defence architectures is maintaining classification controls consistently across multiple providers, each with different service capabilities, different compliance certifications, and different tools for implementing security controls.

Classification controls — access controls keyed to clearance level, audit logging of all access to classified data, encryption key management, data residency enforcement — must be implemented equivalently on each provider used for classified workloads. This means the compliance engineering team must understand the relevant tools and services on each provider, verify that the controls are correctly implemented and tested on each provider, and maintain equivalent compliance documentation across all providers. This is significantly more complex than maintaining controls on a single provider.

The practical approach is to build a provider-agnostic compliance layer: a set of Terraform/Crossplane modules and Kubernetes admission controller policies that implement the required compliance controls regardless of which cloud provider is provisioning the underlying resources. The compliance layer specifies: encryption at rest is required (and enforces it through storage class configuration), encryption key management must use customer-managed keys (and configures CMK policies on each provider), access logs must be forwarded to the SIEM (and configures audit log forwarding). The application team provisions infrastructure through this compliance layer, not directly against the provider API, ensuring that compliance controls cannot be bypassed.