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"
}
}
- Dev Site (Default Provider): This is the default AWS provider configuration, targeting resources in the development account.
- Prod Site 1: Targets the production site in the EU-West-1 region.
- 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”.
Set Up TGW in Prod Site 1:
With the
aws.prod_site_1provider 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 ... }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_1provider.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