Use the Upbound Official Provider Family for AWS, Azure, and GCP (2026)

The Upbound Official Provider Family for AWS, Azure, and GCP is the easiest way to manage your cloud infrastructure across multiple providers.

Let’s see it in action. Imagine you want to provision a simple S3 bucket in AWS and a GCS bucket in GCP. With the Upbound provider family, you can define this in a single Composed Composition.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: aws-gcp-bucket-composition
  labels:
    provider: aws-gcp
spec:
  compositeTypeRef:
    apiVersion: example.crossplane.io/v1alpha1
    kind: XBucket
  resources:
    - name: aws-s3-bucket
      base:
        apiVersion: s3.aws.upbound.io/v1beta1
        kind: Bucket
        spec:
          forProvider:
            region: us-east-1
      patches:
        - fromFieldPath: spec.parameters.bucketName
          toFieldPath: metadata.name
        - fromFieldPath: spec.parameters.bucketName
          toFieldPath: spec.forProvider.bucket
    - name: gcp-gcs-bucket
      base:
        apiVersion: storage.gcp.upbound.io/v1beta1
        kind: Bucket
        spec:
          forProvider:
            location: US
      patches:
        - fromFieldPath: spec.parameters.bucketName
          toFieldPath: metadata.name
        - fromFieldPath: spec.parameters.bucketName
          toFieldPath: spec.forProvider.bucketName

Now, when you create an XBucket custom resource, Crossplane, using the AWS and GCP providers, will provision both an S3 bucket and a GCS bucket.

apiVersion: example.crossplane.io/v1alpha1
kind: XBucket
metadata:
  name: my-shared-bucket
spec:
  parameters:
    bucketName: my-unique-bucket-name-12345

This XBucket resource acts as an abstraction. It doesn’t directly manage cloud resources. Instead, it defines the desired state for a logical "bucket" that can be implemented by different cloud providers. The Composition then translates this abstract XBucket into concrete AWS Bucket and GCP Bucket resources.

The mental model here is Composition. You define an abstract CompositeResourceDefinition (XRD) that represents a logical service (like XBucket). Then, you write Compositions that specify how to provision one or more managed cloud resources from different providers to fulfill that abstract definition. The Upbound Official Provider Family provides the building blocks – the managed resources for AWS, Azure, and GCP – that your Compositions can use.

Think of it like this: your application developers define XBuckets without needing to know the specifics of AWS S3 or GCP GCS. Your platform engineering team defines the Compositions that map XBuckets to the actual cloud resources, ensuring compliance, security, and cost controls are applied consistently. The providers are the translators, turning Crossplane’s desired state into API calls to AWS, Azure, or GCP.

The key benefit is abstraction and portability. You can define your infrastructure in a provider-agnostic way and then choose which provider (or providers) should implement it through your Compositions. Need to switch from AWS to GCP for new buckets? You don’t change your application code; you update your Compositions.

When you define a CompositeResourceDefinition (XRD), you’re essentially creating a new custom resource type in your Kubernetes cluster. For instance, the XBucket XRD might look like this:

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xbuckets.example.crossplane.io
spec:
  group: example.crossplane.io
  names:
    kind: XBucket
    plural: xbuckets
  versions:
  - name: v1alpha1
    served: true
    referenceable: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              parameters:
                type: object
                properties:
                  bucketName:
                    type: string

This tells Kubernetes about the XBucket kind. The Composition then binds this abstract XBucket to concrete cloud resources. The patches section is where the magic happens, mapping fields from the XBucket’s spec.parameters to the spec.forProvider of the underlying managed resources.

The Upbound Official Provider Family is designed to be comprehensive and idiomatic. This means the managed resources within these providers closely mirror the native cloud services. For example, an s3.aws.upbound.io/v1beta1.Bucket resource will have spec.forProvider.bucket and spec.forProvider.region fields that directly correspond to AWS S3 bucket naming and region. Similarly, storage.gcp.upbound.io/v1beta1.Bucket will have spec.forProvider.bucketName and spec.forProvider.location.

A common pitfall is assuming the provider names map directly to Kubernetes resources. While they often do, the apiVersion and kind are crucial. Always refer to the provider’s documentation for the exact API versions and resource kinds you need to use in your Compositions.

The ability to define multi-cloud infrastructure using a single abstraction, like XBucket, is incredibly powerful for building resilient and portable cloud-native applications. You define your intent once, and Crossplane, guided by your Compositions and powered by the provider family, handles the rest.

You’ll next want to explore how to make these Compositions more dynamic and reusable using Composition Functions.