What are Crossplane Providers and how do they connect to cloud platforms (AWS, GCP, Azure)?

Think of Crossplane Providers like adapter plugs you use when traveling internationally. Your laptop charger (your Kubernetes YAML) stays the same, but the adapter plug (Provider) translates the connection to work with the specific power outlet (cloud API) in each country. You need a different adapter for each country, and each adapter knows the exact pin configuration and voltage requirements. Similarly, each Crossplane Provider knows how to authenticate with and call the APIs of a specific cloud platform.

A Provider is a Crossplane package that bundles two things: a set of Custom Resource Definitions (CRDs) representing the cloud resources it can manage, and a controller that watches those CRDs and makes the corresponding API calls to the cloud platform. When you install provider-aws, it registers hundreds of CRDs in your cluster, including Bucket for S3, Instance for RDS, VPC for networking, and many more. The provider-aws controller then watches the Kubernetes API server for any resources of these types and translates create, update, and delete operations into AWS API calls. For the user-auth-service team that needs a DynamoDB table, they just create a Table resource in Kubernetes, and the AWS provider handles everything else.

Authentication is configured through a ProviderConfig resource, which tells the Provider how to authenticate with the cloud platform. For AWS, this could be static credentials stored in a Kubernetes Secret, an IAM Roles for Service Accounts (IRSA) configuration on EKS, or a cross-account assume role chain. For GCP, it might be a service account JSON key or Workload Identity Federation. For Azure, it could be a service principal or managed identity. The ProviderConfig is separate from the Provider installation itself, which means you can have multiple ProviderConfigs for the same Provider, each pointing to a different account or project. This is how platform teams manage multi-account setups where the payments-api infrastructure lives in a production AWS account and the checkout-service staging environment lives in a development account.

The Upbound marketplace hosts the official Providers maintained by the Crossplane community and Upbound. The most commonly used Providers are provider-aws (also called upbound/provider-aws), provider-gcp, and provider-azure, but there are also Providers for Helm, Kubernetes itself, SQL databases, and many other systems. Each Provider follows semantic versioning, and you can pin your Provider to a specific version to avoid unexpected changes. When you upgrade a Provider, it may introduce new CRDs or modify existing ones, so platform teams typically test Provider upgrades in a staging cluster before rolling them out to production where the order-processing-service and inventory-sync service depend on them.

A common beginner mistake is installing a monolithic Provider package that includes every CRD for a cloud platform. For AWS alone, this can mean over 900 CRDs, which consumes significant memory and CPU in the cluster. Modern best practice is to use Provider families, where you install only the specific resource groups you need. Instead of installing the full provider-aws, you install provider-aws-s3, provider-aws-rds, and provider-aws-ec2 separately. This reduces the resource footprint dramatically and speeds up cluster startup times, which is especially important when running Crossplane in smaller clusters that also host application workloads.