Skip to content

Instantly share code, notes, and snippets.

@huynhbaoan
Created December 28, 2024 08:58
Show Gist options
  • Save huynhbaoan/6793093027699c972057690202ec2089 to your computer and use it in GitHub Desktop.
Save huynhbaoan/6793093027699c972057690202ec2089 to your computer and use it in GitHub Desktop.
Below is a comprehensive end-to-end example of how you might Resource Access Manager (RAM) share a CloudWAN core network from a prod account to a nonprod (NP) account. The example is organized into two folders—prod/ and np/—each containing minimal Terraform configurations. It illustrates:
1. Creating a CloudWAN core network in prod.
2. Creating a RAM resource share in prod.
3. Associating the nonprod account as a principal.
4. Sharing the CloudWAN core network with nonprod.
5. Referencing the shared CloudWAN in nonprod to create a VPC attachment.
Disclaimer: This is a simplified example for demonstration. You would adapt naming, variables, and references to suit your actual environment (e.g., separate files, modules, state management, encryption, etc.).
Folder Structure
cloudwan-project/
├── policy
│ └── core_network_policy.json # (Optional) Where you store the JSON policy
├── prod
│ ├── variables.tf
│ ├── prod_cloudwan.tf # Create CloudWAN & share via RAM
│ └── prod_ram_share.tf # Alternatively combined in one .tf file
├── np
│ ├── variables.tf
│ └── np_cloudwan.tf # Reference shared resource and attach to it
└── ...
Below, we’ll show the key .tf files in prod/ and np/.
prod/variables.tf
variable "region" {
type = string
default = "ap-southeast-2"
}
variable "nonprod_account_id" {
type = string
default = "222222222222" # Replace with your actual NP account ID
}
You might also define AWS provider configuration here, or in a separate providers.tf:
provider "aws" {
region = var.region
# credentials or profile for the prod account
}
prod/prod_cloudwan.tf
#######################
# 1. Create Core Network
#######################
resource "aws_networkmanager_core_network" "prod_core_network" {
name = "prod-core-network"
}
############################
# 2. Optionally Set a Policy
############################
resource "aws_networkmanager_core_network_policy" "prod_core_network_policy" {
core_network_id = aws_networkmanager_core_network.prod_core_network.id
# Option 1: inline JSON (example placeholder)
# policy_document = <<POLICY
# {
# "Segments": [ ... ],
# "SegmentActions": [ ... ],
# ...
# }
# POLICY
# Option 2: reference external file
policy_document = file("${path.module}/../policy/core_network_policy.json")
}
If you have no policy yet, you can skip creating the aws_networkmanager_core_network_policy resource. But typically, CloudWAN requires a policy to define segments and routing behavior.
prod/prod_ram_share.tf
############################################
# 3. Create a RAM Resource Share for CloudWAN
############################################
resource "aws_ram_resource_share" "prod_cloudwan_share" {
name = "prod-cloudwan-core-network-share"
allow_external_principals = false
}
#######################################################
# 4. Associate the Nonprod Account with This Share
#######################################################
resource "aws_ram_principal_association" "prod_cloudwan_share_np_account" {
resource_share_arn = aws_ram_resource_share.prod_cloudwan_share.arn
principal = var.nonprod_account_id
}
###################################################################
# 5. Associate the Core Network Resource with the RAM Resource Share
###################################################################
resource "aws_ram_resource_association" "prod_core_network_ram_assoc" {
resource_share_arn = aws_ram_resource_share.prod_cloudwan_share.arn
resource_arn = aws_networkmanager_core_network.prod_core_network.arn
}
This shares the CloudWAN core network with the nonprod account. The nonprod account can now “see” and attach to that shared resource, subject to any necessary IAM permissions and roles.
At This Point (in Prod Account)
• You have created a CloudWAN core network (aws_networkmanager_core_network.prod_core_network).
• You have optionally set a core network policy (segments, routing rules).
• You have created a RAM resource share, associated your nonprod account, and shared the core network.
Your prod account stands ready. Now, let’s see how nonprod uses it.
np/variables.tf
variable "region" {
type = string
default = "ap-southeast-2"
}
variable "prod_core_network_name" {
type = string
default = "prod-core-network" # Must match the name from the prod environment
}
You’d also define your AWS provider for nonprod here, pointing to the nonprod account:
provider "aws" {
region = var.region
# credentials or profile for the NP account
}
np/np_cloudwan.tf
Here’s how the nonprod side references the shared CloudWAN by name (or you could discover it via aws_ram data resources or pass in the ID/ARN from a pipeline).
##################################
# 1. Discover the Shared Core Network
##################################
data "aws_networkmanager_core_network" "prod_shared" {
// Provide a filter to find the name or ID that was shared
// name = var.prod_core_network_name
// OR a direct ID if you pass it as a variable
// depends on how you want to fetch the resource
name = var.prod_core_network_name
}
####################################################
# 2. Create a VPC Attachment to the Shared Core Network
####################################################
resource "aws_networkmanager_vpc_attachment" "np_mel_int" {
core_network_id = data.aws_networkmanager_core_network.prod_shared.core_network_id
vpc_arn = aws_vpc.my_np_mel_vpc.arn # Example
subnet_arns = [
aws_subnet.np_mel_subnet1.arn,
aws_subnet.np_mel_subnet2.arn
]
segment_name = "NP MEL int seg" # Must match a segment in the policy
tags = {
Environment = "nonprod"
Name = "NP-MEL-int-attachment"
}
}
• data "aws_networkmanager_core_network" "prod_shared" finds the resource that has been shared from prod.
• Then you attach your nonprod VPC to the CloudWAN via aws_networkmanager_vpc_attachment. Note that you specify:
• core_network_id from the data source.
• vpc_arn and subnet_arns from the nonprod VPC you want attached.
• segment_name that matches what is defined in the prod account’s core network policy.
You’d repeat as needed for all your nonprod VPC attachments: np_syd_int, np_mel_ext, np_mel_ext_fw, etc.
What Resources Need RAM Share?
• AWS Network Manager resources that you want a different AWS account to use or attach to. In this example:
• The CloudWAN core network is owned by prod, but must be accessible by nonprod.
• If you also want the nonprod account to see or attach to other cross-account resources (e.g., a shared Route 53 Resolver Rule, or a Transit Gateway—if you were using TGW in addition to or instead of CloudWAN), you’d share those resources as well via RAM.
• If nonprod has its own CloudWAN and you want prod to attach, you would do the reverse sharing from NP to prod.
Putting It All Together
1. Prod creates and owns the CloudWAN core network.
2. Prod sets up a RAM resource share to share the CloudWAN with nonprod.
3. Nonprod references that shared resource (either by using the data "aws_networkmanager_core_network" with the same name or by looking it up with a data resource for RAM shares).
4. Nonprod can then create VPC attachments pointing to the shared CloudWAN.
5. Both sides maintain appropriate IAM roles/permissions to ensure cross-account usage is allowed.
That’s the full example. In actual practice, you may:
• Break out attachments into separate .tf files per environment.
• Parameterize the references or resource ARNs.
• Use local modules or place the resources inline.
• Include additional resources like AWS Network Firewall.
But the above shows all the essential parts for RAM-sharing CloudWAN from a prod account to a nonprod account.
Short Answer
• prod_cloudwan_share is an aws_ram_resource_share resource—a “container” that lets you share your CloudWAN core network (or other AWS resources) with another AWS account via AWS Resource Access Manager (RAM).
• The relationship between the core network and the RAM share is established through an aws_ram_resource_association. This association effectively says: “Take the CloudWAN core network ARN and make it visible/useable in another AWS account.”
Why Do We Need a Resource Share?
AWS Resource Access Manager (RAM) is the native AWS service that lets you securely share certain AWS resources across different AWS accounts or Organizations. When you create a CloudWAN core network in prod, that resource lives entirely within the prod account by default. If you want another account (e.g., nonprod) to attach its VPCs to that same CloudWAN, you must “share” the core network with the nonprod account.
How It All Ties Together
1. Core Network Creation
resource "aws_networkmanager_core_network" "prod_core_network" {
name = "prod-core-network"
}
• This is the CloudWAN resource itself. It’s owned by your prod account.
2. Resource Share
resource "aws_ram_resource_share" "prod_cloudwan_share" {
name = "prod-cloudwan-core-network-share"
allow_external_principals = false
}
• aws_ram_resource_share is the container or “share” you create in prod.
• By itself, it doesn’t share anything yet. It’s just an empty share with a friendly name.
3. Principal Association (which account can use the share)
resource "aws_ram_principal_association" "prod_cloudwan_share_np_account" {
resource_share_arn = aws_ram_resource_share.prod_cloudwan_share.arn
principal = var.nonprod_account_id
}
• This says: “I want to share with nonprod_account_id.”
• Now the nonprod account is allowed to consume resources associated with this share.
4. Resource Association (which resource are we actually sharing?)
resource "aws_ram_resource_association" "prod_core_network_ram_assoc" {
resource_share_arn = aws_ram_resource_share.prod_cloudwan_share.arn
resource_arn = aws_networkmanager_core_network.prod_core_network.arn
}
• This step actually “binds” your CloudWAN core network (the resource) to the “container” (the RAM resource share).
• Now, the nonprod account (the principal) can see and attach to the CloudWAN core network.
Hence, the RAM share is what enables cross-account access to your CloudWAN. Without that, the nonprod account can’t even “see” the CloudWAN resource from prod.
Diagram
+---------------------------------------------+
| Prod AWS Account |
| (owns the CloudWAN core network) |
| |
| 1) aws_networkmanager_core_network.prod_core_network
| -> This is the CloudWAN resource |
| |
| 2) aws_ram_resource_share.prod_cloudwan_share
| -> The "container" for sharing |
| |
| 3) aws_ram_principal_association.prod_cloudwan_share_np_account
| -> Ties the share to the nonprod acct |
| |
| 4) aws_ram_resource_association.prod_core_network_ram_assoc
| -> Ties the share to the core network |
+---------------------------------------------+
| (RAM Share)
v
+---------------------------------------------+
| Nonprod AWS Account |
| (wants to attach to the prod CloudWAN) |
| data.aws_networkmanager_core_network.prod_shared
| -> Looks up the shared CloudWAN resource |
| resource.aws_networkmanager_vpc_attachment
| -> Actually attaches a NP VPC to CloudWAN |
+---------------------------------------------+
The np account uses a data source or a known ID/ARN reference to discover the prod CloudWAN, then creates an aws_networkmanager_vpc_attachment to connect its VPC subnets to that CloudWAN.
In Summary
• prod_cloudwan_share is the Terraform resource name for aws_ram_resource_share.
• It does not itself create the CloudWAN; rather, it’s how you expose the already-created CloudWAN resource (the core network) to another account.
• The link between them is aws_ram_resource_association, which says “I want to share resource X (the CloudWAN) with resource share Y (the container).”
• Then aws_ram_principal_association associates the nonprod account with that resource share, granting it visibility and usage rights.
That’s how CloudWAN in prod becomes accessible from nonprod.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment