Provisioning Multi-Region AWS Infrastructure with Crossplane

#kubernetes #aws #eks #crossplane #gitops #infrastructure

Originally published on Medium on 22 June 2026.

Crossplane multi-region AWS infrastructure diagram 1

Before we can deploy applications across multiple EKS clusters, we need the infrastructure to exist. That sounds obvious, but it is where many platforms become fragmented.

  • One team creates a VPC with Terraform.
  • Another team creates EKS clusters manually.
  • DNS records are created somewhere else.
  • IAM roles are patched during incidents.
  • A few resources are managed by scripts that only one person understands.

This works for a while, but it does not scale well. For a multi-region platform, we need infrastructure that is:

  • declarative
  • repeatable
  • reviewable
  • region-aware
  • safe to evolve
  • owned by the platform

In this architecture, Crossplane is the infrastructure provisioning layer. Crossplane runs in a management cluster and manages AWS resources through Kubernetes APIs.

The management cluster

Crossplane multi-region AWS infrastructure diagram 2

The management cluster is not where application workloads run. It is where the platform control plane lives.

A simplified management cluster may run:

  • Crossplane
  • Crossplane AWS provider
  • platform orchestration app
  • promotion engine
  • policy controllers
  • observability components

The target EKS clusters are separate.

  • management-cluster runs
    • platform control plane
  • prod-eu-west-1
    • runs application workloads
  • prod-eu-central-1
    • runs application workloads
  • prod-us-east-1
    • runs application workloads

This separation matters. The management cluster is responsible for creating and coordinating the platform. The target clusters are responsible for running workloads.

Crossplane as the AWS provisioning layer

Crossplane lets us represent cloud infrastructure as Kubernetes resources. Instead of thinking only in low-level AWS objects, we can create platform-level APIs.

For a regional EKS cluster, that might include:

  • VPC
  • public subnets
  • private subnets
  • route tables
  • EKS cluster
  • managed node groups
  • IAM roles
  • OIDC provider
  • security groups
  • KMS keys

The goal is not to expose every AWS detail to every team. The goal is to define reusable infrastructure products.

Example platform claim

An internal platform API may expose a simple claim like this:

apiVersion: platform.example.com/v1alpha1  
kind: RegionalCluster  
metadata:  
  name: prod-eu-west-1  
  namespace: platform  
spec:  
  region: eu-west-1  
  environment: production  
  clusterVersion: "1.32"  
  network:  
    cidr: 10.20.0.0/16  
  nodePools:  
    - name: general  
      instanceType: m7i.large  
      minSize: 3  
      maxSize: 20

This is the interface the platform wants to support. Application teams should not need to care how many AWS resources this creates. Platform engineers can evolve the underlying composition without changing the user-facing API every time.

Why compositions are useful

Crossplane compositions are useful because they let us package multiple resources into one higher-level unit. Instead of asking someone to create 20 different AWS resources correctly, we expose one platform resource. That gives us consistency.

Every production cluster can have:

  • the same tagging strategy
  • the same baseline IAM model
  • the same network layout
  • the same encryption defaults
  • the same observability integration
  • the same policy controls

The regions can still differ where necessary. For example:

  • prod-eu-west-1 may have larger node groups
  • prod-us-east-1 may have different availability zones
  • prod-eu-central-1 may start as passive

But the shape of the infrastructure remains consistent.

Crossplane and multi-region infrastructure

In a multi-region platform, Crossplane can provision each regional stack independently.

  • RegionalCluster/prod-eu-west-1
    • creates AWS resources in eu-west-1
  • RegionalCluster/prod-eu-central-1
    • creates AWS resources in eu-central-1
  • RegionalCluster/prod-us-east-1
    • creates AWS resources in us-east-1

This makes regional ownership clear. It also makes failure boundaries clearer. If there is a problem provisioning one region, it should not require changing every other region.

DNS and traffic resources

For multi-region applications, infrastructure is not only EKS. We also need traffic routing. Depending on the architecture, the platform may provision:

  • Route 53 records
  • weighted routing policies
  • latency-based routing policies
  • health checks
  • Global Accelerator endpoints
  • regional load balancers

Crossplane can help define these resources declaratively, but the important design decision is architectural:

  • Is the application active-active?
  • Is it active-passive?
  • Is traffic weighted?
  • Is failover automatic?
  • Is failover manually controlled?

The answer may differ by application. A stateless frontend may be active-active. A financial transaction service may be active-passive. A batch system may not need global traffic routing at all. The platform should support these patterns explicitly instead of pretending all applications are the same.

What Crossplane should not own

Crossplane should own infrastructure, but it should not own application release progression. It should not decide whether version 1.4.2 of payment-service is ready for production. It should not decide whether traffic should move from one application version to another. It should not replace the promotion engine. This separation keeps the architecture clean.

  • Crossplane: “Does the infrastructure exist?”
  • Flux: “Is the cluster reconciled to the desired state?”
  • Promotion engine: “Is this version allowed to move to the next target?”

GitOps for infrastructure

Even though Crossplane runs in Kubernetes, the desired state should still live in Git. A platform repository may look like this:

platform-infra/   
  regions/   
    eu-west-1/   
      cluster.yaml   
      network.yaml   
      dns.yaml   
    eu-central-1/   
      cluster.yaml   
      network.yaml   
      dns.yaml   
    us-east-1/   
      cluster.yaml   
      network.yaml  
      dns.yaml

Flux can reconcile this repository into the management cluster. Crossplane then reconciles the AWS resources.

That gives us a GitOps chain

Crossplane multi-region AWS infrastructure diagram 3

This pattern is powerful because infrastructure changes become pull requests.

  • A new region is a Git change.
  • A new cluster is a Git change.
  • A DNS policy change is a Git change.
  • An IAM policy update is a Git change.

That is exactly what we want.

Final thoughts

Crossplane gives the platform team a way to build infrastructure APIs. Instead of every team learning every AWS detail, the platform provides higher-level resources that are safe, repeatable, and region-aware. For multi-region EKS, this becomes the foundation. But infrastructure alone is not enough. Once the clusters exist, we need a way to continuously reconcile their Kubernetes state. That is where FluxCD comes in.

Previous in this series: Building a Multi-Region EKS Platform with Crossplane, FluxCD, and GitOps.