Terraform azurerm and gcs State Backends

By Khimananda Oli | Last reviewed: August 2026

Managing infrastructure state locally is a liability that eventually breaks team workflows and risks data loss. Configuring Terraform azurerm and gcs state backends correctly solves this by enabling secure remote storage, native state locking, and encrypted collaboration across distributed teams. Whether you are deploying to Azure or GCP, the backend configuration dictates your operational safety and compliance posture.

Before diving into provider-specific syntax, understand that remote state is the foundation of collaborative DevOps. As detailed in our guide on Terraform state management and remote backends, the backend block does more than just save a JSON file; it defines how your team coordinates changes safely. In 2026, with multi-cloud becoming standard for resilience, knowing both Azure and GCP backend patterns is essential for architects managing cross-platform environments.

How do you configure the Terraform azurerm backend for production?

The azurerm backend stores state in an Azure Storage Account container. A common mistake in tutorials is skipping the prerequisite resource creation; Terraform cannot create the backend storage account using the same backend configuration that relies on it. You must bootstrap these resources first, ideally via a separate bootstrap pipeline or manual CLI commands.

Bootstrap the Storage Account

Create a dedicated resource group and storage account with security best practices enabled. Never use the default access tier for state files.

az group create --name rg-terraform-state --location eastus2

az storage account create \
  --name sttfstateprod2026 \
  --resource-group rg-terraform-state \
  --sku Standard_LRS \
  --encryption-services blob \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

az storage container create \
  --name tfstate \
  --account-name sttfstateprod2026

Configure the Backend Block

In your root module, define the backend. Note that sensitive values like access_key should never be hardcoded. Use environment variables (ARM_ACCESS_KEY) or Azure AD authentication instead.

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "sttfstateprod2026"
    container_name       = "tfstate"
    key                  = "prod/network.tfstate"
    use_oidc             = true
  }
}

Using use_oidc = true enables Workload Identity Federation, eliminating long-lived service principal secrets. This aligns with modern security standards discussed in our guide to handling secrets in CI/CD pipelines. For local development, developers can authenticate via az login, while CI runners use federated credentials.

How do you set up the Terraform gcs backend with proper locking?

Google Cloud Storage (GCS) offers a simpler setup but requires explicit configuration for state locking. Unlike Azure's native blob lease mechanism, GCS locking was historically optional. In 2026, always enable it to prevent race conditions during parallel applies.

Create Bucket and Enable Versioning

GCS buckets for state must have versioning enabled. This is your primary disaster recovery mechanism against accidental state corruption or deletion.

gcloud storage buckets create gs://my-org-tf-state-2026 \
  --project=my-gcp-project \
  --location=asia-south1 \
  --uniform-bucket-level-access \
  --versioning

gcloud storage buckets update gs://my-org-tf-state-2026 \
  --lifecycle-file=lifecycle.json

Backend Configuration with Locking

The gcs backend supports impersonation for secure access without exporting service account keys directly.

terraform {
  backend "gcs" {
    bucket         = "my-org-tf-state-2026"
    prefix         = "prod/network"
    impersonate_service_account = "[email protected]"
  }
}

State locking in GCS works by creating a temporary lock object. If a process crashes, the lock may persist. Always verify lock status before force-unlocking. The impersonate_service_account parameter allows engineers to use their personal identity to act as the automation service account, maintaining audit trails without distributing JSON key files.

What are the key differences between azurerm and gcs backends?

While both backends serve the same fundamental purpose, their implementation details affect operational workflows. Understanding these nuances prevents friction when managing multi-cloud estates.

A critical distinction lies in access control philosophy. GCS strongly recommends Uniform Bucket-Level Access, which disables legacy ACLs entirely. This simplifies permission management but means you cannot grant object-level permissions within the state bucket. Azure allows finer-grained RBAC at the container level, which can be useful if you segregate state files by team within a single storage account.

How do you migrate existing state to a new remote backend?

Migrating state is a high-risk operation. Whether moving from local to remote, or between clouds, follow this exact procedure to avoid orphaned resources.

1. Backup Current State: Run terraform state pull > backup.tfstate before any migration. Store this file securely outside version control.
2. Update Backend Config: Modify the backend block in your HCL to point to the new destination.
3. Initialize with Migration: Run terraform init -migrate-state. Terraform will detect the change and prompt for confirmation.
4. Verify Integrity: Run terraform plan immediately after migration. It should show "No changes". Any drift indicates a failed migration or mismatched state.
5. Clean Up Old Backend: Only delete the old state file after verifying the new backend works across multiple successful applies.

If migrating between different cloud providers (e.g., Azure to GCS), ensure your credentials are configured for both providers during the transition window. Terraform needs read access to the source and write access to the destination simultaneously during init.

What security controls are mandatory for state backends in 2026?

State files often contain sensitive outputs, database connection strings, or implicitly sensitive resource attributes. Treating the backend as a public artifact is a severe vulnerability. Implement these controls as baseline requirements:

• Encryption at Rest: Verify customer-managed keys (CMK) are active for regulated workloads. Default platform encryption is sufficient for most internal tools, but fintech and healthcare typically require CMK for compliance audits.
• Network Isolation: Use Private Endpoints (Azure) or VPC Service Controls (GCP) to restrict state access to trusted networks only. Public internet access to state containers should be disabled.
• Immutable Storage: Enable immutability policies for compliance-critical environments. This prevents ransomware or malicious insiders from deleting state history.
• Least Privilege Access: Grant Storage Blob Data Contributor (Azure) or Storage Object Admin (GCP) only to automation identities. Developers should have read-only access unless actively debugging.
• Audit Logging: Enable diagnostic logs for all read/write operations. In SOC 2 environments, you must demonstrate who accessed state and when. Our article on automating SOC 2 compliance evidence covers integrating these logs into evidence collection pipelines.

Securing Your Infrastructure Foundation

Properly configured Terraform azurerm and gcs state backends transform infrastructure management from a fragile manual process into a resilient, auditable engineering discipline. Start by bootstrapping your backend resources with security-first defaults, enforce OIDC or workload identity over static keys, and validate your locking mechanism before trusting parallel workflows. If your team is preparing for compliance audits or scaling multi-cloud operations, review our Infrastructure as Code with Terraform practical guide for broader architectural patterns. Need help designing a compliant state management strategy? Contact me to discuss your specific environment requirements.