In more mature AWS environments, resources often span multiple accounts, requiring different configurations and permissions. Terraform’s provider aliasing feature is a godsend in such scenarios. It allows you to manage resources across several AWS accounts in a single Terraform configuration.

Why Multiple AWS Providers?

There are several reasons why an organization might use multiple AWS accounts:

  • Security: Isolate production environments from development environments.
  • Cost Tracking: Delineate billing and track usage costs distinctly for different departments or projects.
  • Service Limits: Avoid reaching service-specific quotas in a single AWS account.

For infrastructure engineers, managing resources across these accounts can be a challenge. Terraform’s ability to define and use multiple provider configurations is a valuable solution.

Defining Providers

In the provided code, there are three distinct AWS provider configurations:

# Provider for Account 1
provider "aws" {
  alias  = "account_one"
  region = "us-west-1" # or your preferred region

  assume_role {
    role_arn     = "arn:aws:iam::<ACCOUNT_1_ID>:role/RoleNameInAccount1"
    session_name = "TerraformSessionAccount1"
  }
}

# Provider for Account 2
provider "aws" {
  alias  = "account_two"
  region = "us-east-1"

  assume_role {
    role_arn     = "arn:aws:iam::<ACCOUNT_2_ID>:role/RoleNameInAccount2"
    session_name = "TerraformSessionAccount2"
  }
}

# Provider for Account 3
provider "aws" {
  alias  = "account_three"
  region = "us-central-1"

  assume_role {
    role_arn     = "arn:aws:iam::<ACCOUNT_3_ID>:role/RoleNameInAccount3"
    session_name = "TerraformSessionAccount3"
  }
}
  1. Dev Site (Default Provider): This is the default AWS provider configuration, targeting resources in the development account.
  2. Prod Site 1: Targets the production site in the EU-West-1 region.
  3. Prod Site 2: Targets another production site in the EU-Central-1 region.

Each of these provider configurations uses an assume_role block, indicating that Terraform should assume a specific IAM role in the target account, ensuring it has the necessary permissions.

Scenario: Cross-Account Transit Gateway

Transit Gateways (TGW) in AWS allow you to connect VPCs across accounts, making them a common use-case for multi-provider configurations.

Scenario: Suppose you have VPCs in both “Prod Site 1” and “Prod Site 2” that need to communicate. You decide to set up a TGW in “Prod Site 1” and then share it with “Prod Site 2”.

  1. Set Up TGW in Prod Site 1:

    With the aws.prod_site_1 provider configuration, you can manage the TGW setup in the “Prod Site 1” account.

    resource "aws_ec2_transit_gateway" "tgw_prod_site_1" {
      provider = aws.prod_site_1
      ...
    }
    
  2. Share TGW with Prod Site 2:

    Once the TGW is set up in “Prod Site 1”, you’d use AWS Resource Access Manager (RAM) to share the TGW with “Prod Site 2”. This would again leverage the aws.prod_site_1 provider.

    resource "aws_ram_resource_share" "share_tgw" {
      provider            = aws.prod_site_1
      name                = "Share-TGW-to-Prod-Site2"
      allow_external_principals = true
      ...
    
      resource_arns       = [aws_ec2_transit_gateway.tgw_prod_site_1.arn]
    }
    

    After sharing, “Prod Site 2” can attach its VPCs to the shared TGW.

    resource "aws_ec2_transit_gateway_vpc_attachment" "attach_vpc_site_2" {
      provider                  = aws.prod_site_2
      transit_gateway_id        = "tgw-0999e009ad2761232"
      vpc_id                    = <Prod_Site_2_VPC_ID>
      ...
    }
    

S3 Bucket Management

Fetching data from 3 different buckets

 data "aws_s3_bucket" "bucket_in_account_one" {
 provider = aws.account_one
 bucket   = "bucket-in-account-one"
 }

 data "aws_s3_bucket" "bucket_in_account_two" {
 provider = aws.account_two
 bucket   = "bucket-in-account-two"
 }

 data "aws_s3_bucket" "bucket_in_account_three" {
 provider = aws.account_three
 bucket   = "bucket-in-account-three"
 }


Buy Me a Coffee