Terraform Provider Configurations: Examples and Tips

Terraform providers are the core of infrastructure as code capabilities, acting as the connection between your configuration files and the target API of a service. Understanding how to configure them effectively is fundamental to managing your infrastructure efficiently and securely. This blog explains what provider configurations are, how to use them, and best practices, with examples of the top providers in use today.

What Are Terraform Provider Configurations?

A Terraform provider is a plugin that allows Terraform to interact with a specific cloud provider (like AWS, Azure, or Google Cloud), a SaaS platform, or any other service with an API that Terraform can interact with. The provider configuration is a block of code in your Terraform files (.tf) that tells Terraform which provider to use and how to authenticate and connect to it.

This configuration typically includes details like access keys, secret keys, regions, and other provider-specific settings. Without a properly configured provider, Terraform has no way of managing your resources.

How to Use Them in Your Code

Using provider configurations involves two key steps: declaring the required providers and configuring them.

Configure the Provider: After declaring the provider, you configure it with a provider block. This is where you'll provide authentication details and default settings.Terraform

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

In this example, we're configuring the AWS provider to create resources in the us-east-1 region. Authentication is often handled separately through environment variables or CLI configurations for security reasons, which is why you do not see them in the code snippet.

Declare Required Providers: In your main Terraform configuration file (often main.tf or a dedicated versions.tf), you must specify the providers your configuration needs. This is done within a terraform block.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

This block tells Terraform to download the AWS provider from the official HashiCorp registry and to use a version compatible with version 5.0.

Tips and Tricks for Provider Configurations

• Separate Provider and Resource Files: Keep your provider configurations in a dedicated file, like providers.tf, to keep your code organized and easy to navigate.
• Manage Credentials Securely: Never hardcode credentials (access keys, secrets) in your provider blocks. The best practice is to use environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, etc.) or, for cloud environments, leverage OIDC, IAM roles, and service accounts.
• Pin Provider Versions: Use version constraints in your required_providers block to prevent unexpected changes or breaking updates from new provider versions. The ~> operator allows for patch and minor releases within a major version.

Utilize Aliases for Multi-Region/Account Deployments: If you need to manage resources in multiple regions or across different accounts for the same provider, use the alias meta-argument.

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

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

resource "aws_s3_bucket" "bucket_east" {
  bucket = "my-unique-bucket-east"
}

resource "aws_s3_bucket" "bucket_west" {
  provider = aws.west
  bucket   = "my-unique-bucket-west"
}

Use Variables for Flexibility: Avoid hardcoding values like regions or project IDs. Instead, use variables to make your configurations reusable and adaptable.

variable "aws_region" {
  description = "The AWS region to deploy resources in."
  type        = string
  default     = "us-west-2"
}

provider "aws" {
  region = var.aws_region
}

Top 5 Terraform Providers and Example Usage

Based on recent download statistics and community usage, these are the top 5 Terraform providers for 2025. Checkout a larger list here.

1. AWS (Amazon Web Services)

The most popular provider, used for managing the vast array of AWS services.

Example Usage:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = "us-east-1"
}

# Create a VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "main-vpc"
  }
}

This configuration sets up the AWS provider for the us-east-1 region and creates a new Virtual Private Cloud (VPC).

2. Null

A utility provider that allows you to execute local or remote scripts and trigger other resources without creating a tangible infrastructure object.

Example Usage:

terraform {
  required_providers {
    null = {
      source  = "hashicorp/null"
      version = "~> 3.2"
    }
  }
}

# Run a local script after an EC2 instance is created
resource "null_resource" "configure_instance" {
  triggers = {
    instance_id = aws_instance.web.id
  }

  provisioner "local-exec" {
    command = "echo Instance ${aws_instance.web.id} is ready."
  }
}

This null_resource will execute the echo command whenever the ID of the aws_instance.web resource changes.

3. Random

Another utility provider that generates random values, which is useful for creating unique resource names, passwords, and other data. See a dedicated blog on this here.

Example Usage:

terraform {
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.5"
    }
  }
}

# Generate a random string for a unique S3 bucket name
resource "random_string" "bucket_suffix" {
  length  = 8
  special = false
  upper   = false
}

resource "aws_s3_bucket" "example" {
  bucket = "my-app-bucket-${random_string.bucket_suffix.result}"
}

This configuration creates a unique S3 bucket name by appending a random 8-character string.

4. Azure (Microsoft Azure)

The provider for managing resources within Microsoft's Azure cloud platform.

Example Usage:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

# Configure the Azure Provider
provider "azurerm" {
  features {}
}

# Create a Resource Group
resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "East US"
}

This example configures the Azure provider and creates a new resource group in the "East US" location.

5. Google Cloud (GCP)

The provider for managing resources on the Google Cloud Platform. See a getting started guid for the GCP provider here.

Example Usage:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

# Configure the Google Cloud Provider
provider "google" {
  project = "your-gcp-project-id"
  region  = "us-central1"
}

# Create a Google Cloud Storage bucket
resource "google_storage_bucket" "example" {
  name     = "my-unique-gcs-bucket-name"
  location = "US"
}

This configuration specifies the GCP project and region and then creates a new Google Cloud Storage bucket.

Managing Provider Configurations in Scalr

When managing infrastructure with Terraform through a platform like Scalr, handling credentials is a critical security and operational challenge. Scalr's "Provider Configurations" feature is the direct solution to this problem. It offers a secure, centralized way to manage and delegate cloud credentials for your Terraform workspaces.

This section explainins what Scalr Provider Configurations are, how to use them, and the best practices to integrate them into your workflow.

What Are Scalr Provider Configurations?

A Scalr Provider Configuration is a feature within the Scalr platform that acts as a centralized vault for your cloud provider credentials. Instead of embedding access keys, service principal secrets, or other authentication tokens in your Terraform code or environment variables within VCS, you store them securely within Scalr.

These stored configurations can then be attached to any workspace. When a Terraform run executes in that workspace, Scalr automatically injects the correct credentials, allowing Terraform to authenticate with the target provider (like AWS, Azure, or Google Cloud) seamlessly.

In short, it decouples credential management from your code and Terraform platform, dramatically improving security and simplifying operations.

How Scalr Provider Configurations Work

The provider configurations are created and managed at what is referred to as the account scope. The account scope is where the platform teams that manage Scalr maintain all objects that are then shared or assigned with all environments and workspaces.

When creating a provider configuration, you can choose between a major cloud provider or "other":

Cloud providers - Advanced support for AWS, Azure, and Google give users the ability to use authentication methods such as OIDC.

"Other" providers - This option can be used for ANY Terraform provider. When other is selected, users enter the attribute and parameter that is needed for the provider:

Once the provider configurations are created, they are then assigned to environments in Scalr and all workspaces in the environments will inherit them. Admins can choose to set a default provider configuration for the environment or allow users to select the required configuration at the workspace level. If multiple configurations of the same type are used within a workspace, aliases can be set to ensure they are used at the right times with the provided Terraform code.

After the assignment is done, the workspaces inherit the provider configurations, and the provider block is automatically passed into the run, users do not need to define the provider block in their Terraform code:

Example code snippet:

# The provider block is now clean.
# Scalr injects the configuration at runtime.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

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

# Your resources are defined as usual
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

Benefits of Scalr Provider Configurations

This feature shines in scenarios where security, scale, and operational efficiency are paramount.

Managing Multi-Account Cloud Environments

The most common use case. A company has separate AWS accounts for development, staging, and production. How it works: Create three distinct Provider Configurations in Scalr: aws-dev, aws-staging, and aws-prod. Each holds the unique keys for its respective AWS account. The app-dev workspace links to aws-dev, app-staging to aws-staging, and so on. Developers never handle credentials.

Enabling Cross-Cloud Deployments

A single application needs to create resources in both AWS and Azure simultaneously. How it works: Create an aws-config and an azure-config in Scalr. Attach both Provider Configurations to the same workspace. The Terraform code can now contain both provider "aws" and provider "azurerm" blocks, and Scalr will inject the correct credentials for each during the run.

Securely Onboarding New Developers

A new team member needs to run Terraform for a project without being given direct cloud credentials. How it works: Grant the developer access to the relevant Scalr environment. The workspaces within are already linked to the necessary Provider Configurations. The developer can trigger runs and manage infrastructure without ever possessing the secret keys themselves.

Temporary Project-Based Access

A contractor needs to deploy a short-term project and requires temporary infrastructure access. How it works: Create a dedicated Provider Configuration with credentials that have a limited lifespan. Attach it to their workspace. When the project is over, simply delete the Provider Configuration in Scalr to instantly revoke all Terraform access. No key rotation or IAM cleanup is immediately needed.

See the full docs on using the Scalr provider configurations here.

Best Practice: Use the Scalr Provider to Manage Provider Configurations

Scalr has a Terraform provider that can be used to manage all Scalr objects. It is considered best practice to use the provider to manage the provider configurations in Scalr. Here is an example of using the provider to create a AWS provider configuration in Scalr:

resource "scalr_provider_configuration" "aws-oidc" {
  name                   = "aws_oidc_example"
  account_id             = "acc-sscctbisjk12345"
  export_shell_variables = false
  environments           = ["*"]
  aws {
    credentials_type = "oidc"
    role_arn         = "arn:aws:iam::11111111111:role/test-oidc"
    audience         = "my-awesome-audience"    
  }
}