Julio Dutra

Often, organizations need to manage resources across different cloud providers, such as AWS, Azure, and Google Cloud. Terraform provides a robust way to configure and use multiple providers within a single configuration. This article explores how to use multiple providers in Terraform to connect to different cloud environments effectively.

Step 1: Understanding Terraform Providers

Terraform uses providers to interact with various cloud platforms. Each provider is responsible for managing API interactions between Terraform and the target cloud environment. By declaring multiple providers in a configuration file, you can manage resources across different platforms within the same Terraform project.

For example, you can use the AWS provider to manage AWS resources, the AzureRM provider to manage Azure resources, and the Google provider to manage Google Cloud Platform (GCP) resources. Terraform’s flexibility allows you to define and utilize these providers in a single configuration.

Step 2: Setting Up Multiple Providers

To begin, ensure that you have the Terraform CLI installed and properly configured. You will also need access credentials for each cloud provider you want to manage. Here is an example of how to define multiple providers in a main.tf file:

# Define AWS Provider
provider "aws" {
  region = "us-east-1"
  profile = "default"
}

# Define Azure Provider
provider "azurerm" {
  features {}
}

# Define Google Cloud Provider
provider "google" {
  project = "my-gcp-project"
  region  = "us-central1"
} 

In this example, we are defining three different providers: AWS, Azure, and GCP. Each provider block specifies the configuration needed to authenticate and interact with the respective cloud environment.

Step 3: Configuring Provider-Specific Resources

Once the providers are defined, you can use them to create resources in each environment. Below is an example of how to create an S3 bucket in AWS, a Resource Group in Azure, and a Storage Bucket in GCP:

# AWS S3 Bucket
resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-unique-bucket-name"
  acl    = "private"
}

# Azure Resource Group
resource "azurerm_resource_group" "my_rg" {
  name     = "myResourceGroup"
  location = "East US"
}

# Google Cloud Storage Bucket
resource "google_storage_bucket" "my_bucket" {
  name     = "my-gcp-bucket"
  location = "US"
} 

Here, we have defined resources in three different cloud environments. The AWS S3 bucket, Azure Resource Group, and GCP Storage Bucket will be created when you run terraform apply.

Step 4: Using Aliased Providers for Multiple Configurations

In some cases, you may want to use multiple configurations for the same provider, such as managing resources in different regions or accounts. Terraform supports this by using provider aliases.

# Define multiple AWS providers using aliases
provider "aws" {
  alias  = "us_east"
  region = "us-east-1"
}

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

# Resource using the us-east-1 provider
resource "aws_s3_bucket" "east_bucket" {
  provider = aws.us_east
  bucket   = "my-east-bucket"
  acl      = "private"
}

# Resource using the us-west-2 provider
resource "aws_s3_bucket" "west_bucket" {
  provider = aws.us_west
  bucket   = "my-west-bucket"
  acl      = "private"
} 

By using aliases, you can specify which provider configuration to use for each resource. This is particularly useful for managing multiple environments, accounts, or regions.

Step 5: Authenticating and Managing Credentials

Each provider requires authentication to interact with its respective cloud environment. The authentication method varies by provider:

• AWS: Typically uses the AWS CLI configuration file (~/.aws/credentials) or environment variables.
• Azure: Requires the Azure CLI to be installed and authenticated or uses service principals.
• Google Cloud: Uses a JSON service account key file, which can be set via the GOOGLE_APPLICATION_CREDENTIALS environment variable.

Ensure that the credentials are securely stored and managed, using environment variables, secret management tools, or Terraform Cloud’s workspace variables.

Step 6: Running Terraform Commands

After defining your providers and resources, initialize your Terraform configuration:

terraform init

This command downloads the necessary provider plugins. Then, plan and apply your changes:

terraform plan
terraform apply

Terraform will create the specified resources across all defined providers.

Step 7: Managing State Files Across Multiple Providers

Terraform maintains a state file (terraform.tfstate) that records the infrastructure’s current state. When using multiple providers, Terraform will store all states in the same file by default. To isolate states, consider using remote backends like AWS S3, Azure Blob Storage, or GCS. This can prevent conflicts when collaborating across teams or managing different environments.

Step 8: Using Modules for Better Organization

As your configuration grows, consider using Terraform modules to organize and reuse your code. Modules allow you to break down your configuration into reusable components, which is especially helpful when managing resources across multiple providers.

Step 9: Handling Provider Versioning

Providers are updated frequently, and it is essential to manage provider versions carefully. Specify provider versions in the provider block to avoid unexpected changes when running terraform init:

provider "aws" {
  version = "~> 3.0"
  region  = "us-east-1"
}

Step 10: Conclusion

Using multiple providers in Terraform allows teams to manage resources across different cloud environments efficiently. By defining, configuring, and using provider aliases, you can create and manage infrastructure in AWS, Azure, GCP, and other platforms from a single Terraform project. This capability provides flexibility and scalability, essential for modern multi-cloud strategies.

Leveraging Terraform’s capabilities to manage multiple providers can greatly simplify infrastructure management and ensure consistency across cloud environments, enabling a more streamlined and unified DevOps approach.