Phase 4: Infrastructure as Code & Cloud

Providers & Multi-Cloud Resources

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're a super-smart robot builder, and you have a big list of incredible things you want to create online, like a new website for your favorite game, or a special place for your pictures to live. You're great at planning and know exactly what you want the final thing to look like. But here’s the tricky part: there are many different companies that provide the actual building materials and land online, like Amazon (which has something called AWS), Microsoft (with Azure), and Google (with Google Cloud Platform). Each of these companies has its own special way of doing things and its own unique types of building blocks.

This is where "Providers" come in! Think of a Provider as a special instruction manual or a unique tool that teaches your robot builder how to work with one specific type of material or one specific online company's products. If you want to build part of your website using Amazon’s materials, your robot builder needs the "AWS Provider" manual. This manual tells your robot exactly how to talk to Amazon’s services, what commands to use, and how to fit all their specialized building blocks together. If you decide to use Google’s materials for another part of your project, you'll need the "Google Provider" manual. Each Provider is like a translator, turning your general building plans into the specific actions that particular online service understands, almost like a secret handshake (which in grown-up terms is called an API, or Application Programming Interface).

Now, sometimes you might want to build not just one fantastic online world, but two very similar ones – maybe one for testing out new ideas, and another, perfect one for everyone to see. Or perhaps you want to build two different parts of your website using Amazon's materials, but one part needs to be in a server farm far away, like in Europe, and another closer to home in North America. Your robot builder can still handle this! You'd still use your "AWS Provider" manual, but you'd simply tell it, "For the testing world, use the Amazon materials from this specific online location," and "For the public world, use the Amazon materials from that other specific online location."

So, when you're planning your online creations with your robot builder, you choose which special Provider manuals you need. This means you can mix and match materials from different online companies, or even use the same company’s materials in different ways or places, all from your single set of plans. It’s like being able to build incredible structures using LEGOs, wooden blocks, and magnetic tiles all together, each with its own special set of instructions for your master builder!

Terraform is incredibly powerful, but it's just an engine. To actually do anything – whether creating an EC2 instance, configuring an Azure Resource Group, or deploying a Kubernetes service – it needs a way to communicate with the specific platform's API. This is the role of Providers. A Terraform provider is essentially a plugin that understands how to interact with a particular service, translating your declarative configuration into API calls. Common providers include aws, azurerm, google (for GCP), kubernetes, helm, and many others. You declare which providers your configuration will use, often specifying details like the cloud region or authentication credentials, and Terraform then downloads and uses these plugins to manage your infrastructure.

In many real-world scenarios, you'll need to manage resources across multiple environments or regions within the same cloud provider. For example, you might have separate AWS accounts for development and production, or need to deploy resources to both us-east-1 and eu-west-1. To handle multiple instances of a single provider within one configuration, Terraform uses Provider Aliases. By giving a provider block a unique alias (e.g., aws.dev or aws.eu), you can define separate configurations for each instance. When you declare a resource, you then explicitly tell Terraform which aliased provider instance to use, ensuring your resources are provisioned in the correct account or region.

Moving beyond different instances of the same cloud, Terraform truly excels in Multi-Cloud Resource management. This means provisioning and orchestrating resources across different cloud providers within the same Terraform configuration – imagine an application server on AWS EC2 talking to a database on Azure SQL, or a hybrid setup using GCP for analytics while your main infrastructure runs on AWS. Terraform supports this seamlessly; you simply declare and configure all the necessary providers (aws, azurerm, google) side-by-side in your root module. Each resource will implicitly use its corresponding provider based on its type (e.g., aws_instance uses the aws provider), or you can explicitly link it to an aliased provider. This flexibility allows you to leverage the best services from various clouds or build resilient, hybrid architectures, all managed cohesively through a single Infrastructure as Code definition.

Key Takeaways

  • Providers are Terraform's essential interface to external APIs (clouds, K8s, SaaS, etc.).
  • Use provider aliases to manage multiple distinct instances of the same provider (e.g., different accounts, regions).
  • Declare multiple provider blocks to manage resources across different cloud providers (e.g., AWS and Azure) within a single configuration.
  • Providers and aliases enable powerful multi-cloud and hybrid architectures, managed coherently via IaC.

Code Example

terraform
provider "aws" {
  region = "us-east-1"
}

provider "aws" {
  alias  = "west"
  region = "us-west-2"
}

resource "aws_s3_bucket" "my_east_bucket" {
  bucket = "my-unique-east-bucket-name"
}

resource "aws_s3_bucket" "my_west_bucket" {
  provider = aws.west # Explicitly use the aliased 'west' provider
  bucket   = "my-unique-west-bucket-name"
}

How this code works

This Terraform configuration demonstrates how to manage resources across multiple geographical regions within the same cloud provider, specifically AWS, using distinct provider configurations. The code sets up two separate connections to AWS and then creates an S3 storage bucket in each of those regions, showcasing how to precisely control where resources are deployed.

The two provider "aws" blocks declare the intention to interact with AWS. The first one establishes a default connection to the us-east-1 region. The second provider block defines a separate connection to us-west-2 and is given an alias of west. This alias is essential for distinguishing between multiple configurations for the same cloud provider. When defining resource "aws_s3_bucket" "my_east_bucket", Terraform implicitly uses the default aws provider (for us-east-1) because no provider is explicitly specified. For resource "aws_s3_bucket" "my_west_bucket", the provider = aws.west argument explicitly instructs Terraform to use the aliased provider for us-west-2. A subtle point for beginners is that resources without an explicit provider argument will always default to the unaliased (first defined) provider of that type.

Resources

Related Articles

Hand-picked reads to go deeper on infrastructure as code (terraform).

Back to DevOps Engineer Roadmap