Cost effective methods for accessing S3 buckets cross-region

When you need to access Amazon S3 buckets across AWS Regions, from Amazon EC2 instances or other AWS services, you might need to optimize for cost while aligning with your organizational priorities. This article covers seven common patterns you should consider. Each pattern has different trade-offs related to organizational policies, network architecture, and cost.

For simplicity, we'll list these options in order of increasing data transfer costs. We use 1,000 GB/month as the total traffic estimate for a month. All prices were verified as of January 2026. Please check current AWS pricing pages for the most up-to-date rates, as pricing may change over time.

Option 1: Utilize IPv6 and Egress only Internet Gateway (EIGW)

The lowest cost pattern is to deploy an EIGW, and use a dual stack endpoint to connect to S3.

Costs

With this pattern, you pay only for cross-region data transfer. The type of data transfer will depend on whether bytes are sent to or received from S3, though pricing is typically the same for both.

• Bytes sent to S3 from EC2, for example during uploads:
  • No charge from S3.
  • EC2 data transfer charge, from the data transfer OUT From Amazon EC2 To {region} table.
• Bytes received from S3, for example during downloads:
  • S3 data transfer charge, from the Data transfer OUT From Amazon EC2 To {region} table.
  • No charge from EC2

Example costs: For an EC2 instance in us-east-1, at the lowest volume tier outside of the 100 GB free tier, to reach an S3 bucket in us-west-2, this option would generate charges at the following rates:

• Uploads/Downloads: $0.02 per GB transferred.

This gives a monthly total of $20.00 (1,000 GB * $0.02).

Other considerations

This option provides the lowest cost but may face organizational policy constraints:

• Data perimeter concerns: An EIGW allows access to the internet, which may conflict with data perimeter policies. While a firewall layer could mitigate this, firewalls add extra cost and complexity. Restricting access to a specific S3 bucket requires an advanced firewall. Helping customers solve that challenge is one of the motivations for PrivateLink, which will be discussed in other options..
• Traffic classification: Traffic passing through an Internet Gateway or EIGW may be classified differently than traffic that does not, even though it does not "go over the internet" to reach Amazon S3 endpoints (see "Does traffic go over the internet when two instances communicate using public IP addresses, or when instances communicate with a public AWS service endpoint?")..
• IPv6 readiness: Your organization may not be ready to support IPv6 in your VPCs.

This option is particularly attractive for organizations that:

• Prioritize cost optimization above all other factors
• Have minimal security policy restrictions on outbound internet traffic
• Are ready to support IPv6 infrastructure
• Don't require strict data perimeter enforcement

Option 2: Utilize Internet Gateway (IGW), and and EC2 instance with an IPv4 public IP

The next lowest-cost option is similar to Option 1, except that your EC2 instances require public IPv4 addresses and access the Amazon S3 IPv4 endpoints.

Costs

Costs are similar to Option 1, with one addition: you are charged for each public IPv4 address you use.

Example costs: For an EC2 instance in us-east-1, at the lowest volume tier outside of the 100 GB free tier, to reach an S3 bucket in us-west-2, this option would generate charges at the following rates:

• Uploads/Downloads: $0.02 per GB transferred.
• Per Hour: $0.005 per hour per public IP.

This gives a monthly total of $23.65 ($20.00 (1000 GB * $0.02) + $3.65 ($0.005 * 730 hours)).

Other considerations

This option shares the concerns of Option 1 with additional security complexity:

• Data perimeter concerns: Same as Option 1 - an IGW allows access to the internet, which may conflict with data perimeter policies.
• Traffic classification: Same as Option 1 - traffic may be classified differently even though it doesn't traverse the public internet.
• Inbound access management: Every resource with a public IP requires proper security group configuration to block inbound access. While security groups can handle this (and do by default), validating this at a per-instance, per-security-group level is more complex than never provisioning an IGW at all.
• Defense-in-depth complexity: Because security is critical, defense-in-depth techniques that create easily verifiable barriers are valuable. This option requires more validation effort than alternatives.

This option is particularly attractive for organizations that:

• Need IPv4 connectivity and cannot use IPv6
• Have minimal security policy restrictions on internet-facing gateways
• Have robust security group management processes in place
• Prioritize cost over operational simplicity

As such, most organizations choose a different option.

Option 3: VPC interface endpoint (VPCE) with VPC peering

In this option, you create PrivateLink interface endpoints for S3 in each region where you have a bucket that needs to be accessed, and then create cross-region VPC peering connections to the VPCs that provide those interface endpoints.

Costs

Your costs involve:

• PrivateLink interface endpoint: $0.01 per AZ per hour.
• PrivateLink data processing charges: tiered pricing between $0.01-$0.004 per GB. These charges apply to bytes sent to and received from S3.
• Bytes sent to S3 from EC2: Same as Option 1.
• Bytes received from S3: Same as Option 1.
  • However, instead of an S3 data transfer charge, you will see an EC2 data transfer charge. The reason this is different than Option 1 is that this traffic is charged for entering the VPC where the interface endpoint exists. S3 then bills that traffic like it's coming from the region the interface endpoint resides. Since those rates are the same the actual amount should be the same, but it does change how it appears on bills and in AWS Cost Explorer.

Example costs: For an EC2 instance in us-east-1 (at the lowest volume tier) to reach an S3 bucket in us-west-2, this option would generate charges at the following rates:

• Uploads/Downloads: $0.03 per GB transferred (from $0.01 (VPCE) + $0.02 (inter-Region data transfer))
• Per Hour: $0.01 per hour per VPCE.

This gives a monthly total of $37.30 ($30.00 (1000 GB * $0.03) + $7.30 ($0.01 * 730 hours)).

Other considerations

This option provides strong security benefits but introduces management complexity:

• Management complexity: Creating a large number of VPC peering connections can be a management challenge. Additionally, quotas exist for the number of peering connections per VPC, and complex environments may run into those quotas.
• Policy constraints: VPC peering connections might be something your organization avoids or discourages in a security policy. In many general scenarios, compared to Transit Gateway solutions, VPC peering security is harder to manage at scale.
• Centralization considerations: While the relevance of management concerns would be lower for a central VPC that contained only VPC interface endpoints, general policies might still be a blocker. Changing those policies to be more flexible, or pursuing exceptions, may not be a high priority if Transit Gateways are already in use for other purposes.

Those considerations accounted for, this option provides these advantages:

• Data perimeter compliance: The PrivateLink interface endpoint only enables access to S3, not other sites or services, maintaining a strong data perimeter approach.
• Policy enforcement: You can define a VPC endpoint policy, limiting the S3 buckets accessible via the endpoint, furthering consistency with data perimeter approaches.
• Private connectivity: Data clearly stays within managed networks, which satisfies common customer policies.

Centralization decision: After choosing this option, another decision is needed: should endpoints be centralized or distributed? Because there is a per-AZ per-hour charge for endpoints, having an endpoint for every source VPC is inefficient. Instead, reusing a centralized VPC endpoint with multiple source VPCs attached will help minimize that cost. As you are already defining connectivity between VPCs via VPC peering, this is a matter of connecting multiple source VPCs from one region to a single VPC in the destination region. If the number of VPCs needing a destination is greater than the VPC peering connection quota, use multiple destination VPCs in a 50:1 ratio.

This option is particularly attractive for organizations that:

• Want to maintain a strong data perimeter approach
• Need granular bucket-level access control via endpoint policies
• Can manage VPC peering connections within quota limits
• Don't already have Transit Gateway infrastructure in place

Option 4: Cross-Region PrivateLink

This option leverages cross-region connectivity for AWS PrivateLink, which allows VPC interface endpoints to access services across AWS Regions without requiring VPC peering or Transit Gateway connections. With this approach, you create S3 interface endpoints in the source region and configure cross-region access, enabling EC2 instances in the source region to connect directly to those endpoints.

Costs

Your costs involve:

• PrivateLink interface endpoint: $0.01 per AZ per hour.
• PrivateLink data processing charges: tiered pricing between $0.01-$0.004 per GB. These charges apply to bytes sent to and received from S3.
• Cross-region PrivateLink data transfer: Standard inter-region data transfer rates apply.
• Bytes sent to S3 from EC2: Same as Option 1.
• Bytes received from S3: Same as Option 1.

Example costs: For an EC2 instance in us-east-1 (at the lowest volume tier) to reach an S3 bucket in us-west-2, this option would generate charges at the following rates:

• Uploads/Downloads: $0.03 per GB transferred ($0.01 (VPCE) + $0.02 (inter-Region data transfer))
• Per Hour: $0.01 per hour per VPCE.

This gives a monthly total of $37.30 ($30.00 (1000 GB * $0.03) + $7.30 ($0.01 * 730 hours)).

Other considerations

Cross-region PrivateLink provides several advantages over traditional approaches:

• Simplified architecture: No need to manage VPC peering connections or Transit Gateway attachments between regions, reducing operational complexity.
• Data perimeter compliance: The PrivateLink interface endpoint only enables access to S3, not other sites or services, maintaining a strong data perimeter approach.
• Policy enforcement: You can define VPC endpoint policies to limit access to specific S3 buckets, furthering consistency with data perimeter approaches.
• Private connectivity: Data clearly stays within AWS managed networks, which satisfies common customer policies regarding data in transit.
• Scalability: Easier to scale across multiple regions without hitting VPC peering quotas or managing complex routing tables.

Centralization decision: Similar to Option 3, you should consider whether to centralize or distribute endpoints. Because there is a per-AZ per-hour charge for endpoints, reusing a centralized VPC endpoint with multiple source VPCs or regions accessing it will help minimize costs. When centralizing, each region would need interface endpoints to reach S3 buckets in other regions (using gateway endpoints for local region access at no additional cost), and VPC peering within each region to connect VPCs to the centralized endpoint VPC. Compared to Option 3 this results in more endpoints, but many fewer VPC peering connections. Transit Gateway could also be used within region, but this option isn't considered since it provides few benefits vs using Transit Gateway directly.

This option is particularly attractive for organizations that:

• Want to avoid the complexity of VPC peering or Transit Gateway management
• Need to connect many VPCs across multiple regions to S3 endpoints
• Prioritize operational simplicity while maintaining security and compliance requirements
• Already use PrivateLink extensively in their architecture

Option 5: S3 Multi-Region Access Points with Global interface endpoint

The next option utilizes a feature of Amazon S3 called Multi-Region Access Points. These route all S3 data request traffic through a single global endpoint, and allow you to directly control the shift of S3 data request traffic between AWS Regions at any time. In this use case, you could create a Multi-Region Access Point with your single bucket added to it.

Additionally, you need to create a PrivateLink endpoint for the Multi-Region Access Point (com.amazonaws.s3-global.accesspoint). These PrivateLink interface endpoints allow access to Multi-Region Access Points globally from the region where they are created. However, it's important to note that these endpoints do not grant access to all buckets globally. They only allow access to a bucket through its participation in a Multi-Region Access Point. It's also worth noting that the endpoints themselves are not global. Like all VPC interface endpoints, they are regional, with zonal IPs, and specific to the VPC to which they are attached.

Costs

Your costs involve:

• Multi-Region Access Point data routing charges: $0.0033 per GB.
• PrivateLink interface endpoint: $0.01 per hour per AZ per hour.
• PrivateLink data processing charges: tiered pricing between $0.01-$0.004 per GB. These charges apply to bytes sent to and received from S3.
• Bytes sent to S3 from EC2: Same as Option 1.
• Bytes received from S3: Same as Option 1.

Example costs: For an EC2 instance in us-east-1 (at the lowest volume tier) to reach an S3 bucket in us-west-2, this option would generate charges at the following rates:

• Uploads/Downloads: $0.0333 per GB transferred. ($0.01 (VPCE) + $0.02 (Inter-region data transfer) + $0.0033 (Multi-Region Access Point data routing)).
• Per Hour: $0.01 per hour per VPCE.

This gives a monthly total of $40.60 ($33.30 (1000 GB * 0.0333 per GB) + $7.30 ($0.01 * 730 hours))

Other considerations

• Primary use case: The primary use cases for Multi-Region Access Points are performance and multi-region resilience, rather than cost optimization. As such, this option has fewer published examples and may be less well-known.
• Organizational familiarity: Your organization may not have used Multi-Region Access Points in the past, and thus have no established policies or guardrails.

Those considerations accounted for, this option provides these advantages:

• Data perimeter compliance: The Multi-Region Access Point PrivateLink interface endpoint only enables access to S3, not other sites or services, maintaining a strong data perimeter approach.
• Policy enforcement: You can define a Multi-Region Access Point policy, limiting the Multi-Region Access Points and thus buckets accessible via the endpoint, furthering consistency with data perimeter approaches.
• Private connectivity: Data clearly stays within managed networks, which satisfies common customer policies.
• Simplified connectivity: With an S3 Multi-Region Access Point in front of the S3 bucket and s3-global VPC endpoints local to the compute, there is no need for VPC peering.

Centralization decision: After choosing this option, another decision is needed: should endpoints be centralized or distributed? Because there is a per AZ per hour charge for endpoints, having an endpoint for every VPC is inefficient. Instead, reusing a centralized VPC endpoint with multiple source VPCs attached will help minimize that cost.

This option is particularly attractive for organizations that:

• Need dynamic traffic routing between regions for performance optimization
• Require multi-region resilience and failover capabilities
• Want simplified global endpoint management

Option 6: VPC endpoints with Transit Gateway

This option is similar to Option 3, but instead of connecting the VPCs with VPC peering, a Transit Gateway is used.

Costs

Your costs involve:

• PrivateLink interface endpoint: $0.01 per hour per AZ per hour.
• PrivateLink data processing charges: tiered pricing between $0.01-$0.004 per GB. These charges apply to bytes sent and received to/from S3.
• Transit Gateway attachment: $0.05 per attachment per hour (required in both VPCs).
• Transit Gateway per GB data processed: $0.02 per GB
• Bytes sent to S3 from EC2: This is the same as for Option 1.
• Bytes received from S3: Instead of a S3 data transfer charge, you will see a EC2 data transfer charge. The reason this is different than Option 1 is that this traffic is charged for the purpose of entering the VPC where the interface endpoint exists. S3 then sees that billing of that traffic like it's coming from the region the interface endpoint resides. Since those rates are the same the actual amount should be the same, but it does change how it appears on bills and in AWS Cost Explorer.

Example costs: For an EC2 instance in us-east-1 (at the lowest volume tier) to reach an S3 bucket in us-west-2, this option would generate charges at the following rates:

• Uploads/Downloads: $0.05 per GB transferred. ($0.01 (VPCE) + $0.02 (inter-Region data transfer) + $0.02 (TGW data processing))
• Per Hour: $0.11 per hour. Based upon [$0.01 per hour (VPCE) + $0.10 per hour (TGW attachment x 2)]

This gives a monthly total of $130.30 ($50.00 (1000 GB * $0.05) + $80.30 ($0.11 * 730 hours))

However, if we assume that TGW attachments pre-existed this solution, the monthly total is $57.30 ($50.00 (1000 GB * $0.05) + $7.30 ($0.01 * 730 hours))

Other considerations

This option is the most feature-rich but also has the highest costs:

• Cost considerations: This option has the highest static and per-GB costs of all options. However, if Transit Gateway attachments already exist for other purposes, the incremental cost is significantly lower.
• Existing infrastructure: Organizations already using Transit Gateway for other connectivity needs may find this option more attractive, as it leverages existing infrastructure and operational expertise.

Those considerations accounted for, this option provides these advantages:

• Data perimeter compliance: The PrivateLink interface endpoint only enables access to S3, not other sites or services, maintaining a strong data perimeter approach.
• Policy enforcement: You can define a VPC endpoint policy, limiting the S3 buckets accessible via the endpoint, furthering consistency with data perimeter approaches.
• Private connectivity: Data clearly stays within managed networks, which satisfies common customer policies.
• Advanced routing: Management of connections and routing between VPCs can utilize Transit Gateway routing capabilities, including route tables, route propagation, and centralized network management.

This option is particularly attractive for organizations that:

• Already have Transit Gateway infrastructure deployed
• Need centralized network management and routing capabilities
• Require advanced routing features like route table segmentation
• Value operational consistency over cost optimization

Option 7: NAT Gateway

This option uses a NAT Gateway provisioned into the VPC with the EC2 instance, allowing access to the Amazon S3 IPv4 endpoints.

Costs

Your costs involve:

• NAT Gateway: $0.45 per AZ per hour.
• NAT Gateway data processing charges: $0.045 per GB. These charges apply to bytes sent to and received from S3.
• Public IP Address: $0.005 per hour
• Bytes sent to S3 from EC2: This is the same as for Option 1.
• Bytes received from S3: This is the same as for Option 1.

Example costs: For an EC2 instance in us-east-1 (at the lowest volume tier) to reach an S3 bucket in us-west-2, this option would generate charges at the following rates:

• Uploads/Downloads: $0.065 per GB transferred. ($0.045 (NAT data processing) + $0.02 (inter-Region data transfer))
• Per Hour: $0.05 per hour. ($0.045 per hour (NAT-GW) + $0.005 per hour (public IP))

This gives a monthly total of $101.50 ($65.00 (1000 GB * $0.065) + $36.50 ($0.05 * 730 hours).

However, if we assume that the NAT Gateway pre-existed this solution, the monthly total is $65.00.

Other considerations

This option shares similar concerns with Options 1 and 2:

• Data perimeter concerns: Same as Options 1 and 2 - traffic passes through an internet-facing gateway, which may conflict with data perimeter policies.
• Traffic classification: Same as Options 1 and 2 - traffic may be classified differently even though it doesn't traverse the public internet.
• Existing infrastructure: If NAT Gateways already exist for other purposes (such as providing internet access for software updates), the incremental cost for S3 access is significantly lower.
• Scalability limitations: While NAT Gateways can be centralized and shared by multiple VPCs via VPC peering or Transit Gateway, this approach may not scale well for high-volume usage.

This option is particularly attractive for organizations that:

• Already have NAT Gateway infrastructure deployed for other purposes
• Need IPv4 connectivity without public IPs on instances
• Have minimal security policy restrictions on internet-facing gateways
• Want a simple, well-understood networking pattern

Performance

For most use cases, all seven options will have similar enough performance characteristics that this should not be a key decision point. However, you will want to monitor capacity for VPC endpoints and NAT Gateways.

NAT Gateways begin scaling after 5 Gbps, and VPC endpoints at 10Gbps, both scaling automatically up to 100 Gbps. If you exceed 100 Gbps, you'll want to scale horizontally by decentralizing and routing.

There are other limits specific to very large numbers of concurrent connections, but since S3 traffic is unlikely to be a primary contributor to those limits, this detail is not covered in depth here.

NAT Gateways would add the most latency of these solutions, but in most cases this difference is not significant enough to influence decisions.

Additional Examples

The options above provide an estimate for a single example. Because some costs are based on static provisioning and some are based on traffic volume, I wanted to provide some additional examples showing the influences there. In addition the examples so far focused on a single instance, in a single VPC, in a single AZ. While this might fit some use cases like a low-priority data migration, there are other cases where greater resilience and a larger number of participating resources will be involved. While I can't provide an example for every case, I did want to show a few.

Remember, when examining these examples, that if a static resource already exists, for example Transit Gateway VPC attachments, you won't need to provision another, and so that cost should be subtracted from these estimates that assume no existing resources are in place. If your organization uses Transit Gateway, many, maybe all, of your VPCs will already have attachments.

Example 1: Low volume, low priority, single source

This example is the one used throughout the earlier discussion. For most scenarios a higher degree of resilience is recommended. This example is offered to illustrate the most minimal requirements. It assumes a single VPC (and single instance for the Internet Gateway scenario), communicating with only one other region, and does not provide resilience to an availability zone impairment. Total traffic for the month is 1 TB with traffic passing from us-east-1 to us-west-2.

-	(1) EIGW	(2) IGW	(3) VPC Peering	(4) Cross-Region PL	(5) MRAP	(6) TGW	(7) NAT-GW
Traffic Costs	$20.00	$20.00	$30.00	$30.00	$33.30	$50.00	$65.00
Static Costs	-	$3.65	$7.30	$7.30	$7.30	$80.30	$36.50
Total Costs	$20.00	$23.65	$37.30	$37.30	$40.60	$130.30	$101.50

Example 2: Low volume, low priority, development

In this second example, we show the impacts from needing to provision additional static resources due to having multiple regions, VPCs and instances. Like example 1, this example does not offer resiliency to availability zone impairments and is only appropriate to low priority cases, for example development in a cost conscious environment.

In this example, there are 4 regions, each with 10 VPCs, and each VPC has 3 EC2 instances (thus 120 total instances). Total traffic for the month is 1 TB. We'll assume traffic passes between regions with the similar rates to us-east-1 to us-west-2. A realistic example would be the set of us-east-1, us-west-2, eu-west-1, and eu-central-1.

For options requiring VPC endpoints (Options 3, 4, 5), we assume one endpoint per VPC per region (40 total endpoints). For NAT Gateway (Option 7), we assume one NAT Gateway per VPC (40 total).

-	(1) EIGW	(2) IGW	(3) VPC Peering	(4) Cross-Region PL	(5) MRAP	(6) TGW	(7) NAT-GW
Traffic Costs	$20.00	$20.00	$30.00	$30.00	$33.30	$50.00	$65.00
Static Costs	-	$438.00	$292.00	$292.00	$292.00	$1,752.20	$1,460.00
Total Costs	$20.00	$458.00	$322.00	$322.00	$325.30	$1,802.00	$1,525.00

With centralization

If we use a central service VPC approach, we can reduce the number of static resources.

• Egress Only Internet Gateway and Internet Gateway options have no such resources, so are not affected.
• For VPC Peering and Transit Gateway, this means instead of each VPC connecting to a corresponding VPC in other regions, one VPC in each region receives traffic from all the VPCs in other regions.
• For Cross-Region PrivateLink, each region needs a centralized VPC with interface endpoints to access S3 buckets in the other 3 regions (3 endpoints per region, 12 total across 4 regions). Gateway endpoints are used for local region S3 access at no additional cost. VPC peering within each region connects the 10 VPCs to the centralized endpoint VPC.
• For Multi-Region Access Points, this means that instead of each VPC having its own Multi-Region Access Point global VPC Endpoints, one VPC per region contains such an endpoint, or endpoint per AZ, and other VPCs connect to that VPC via VPC Peering.
• For NAT Gateways, this means a single NAT Gateway, or one per AZ exists in each region, rather than each VPC having its own set of NAT Gateways.

-	(3) VPC Peering	(4) Cross-Region PL	(5) MRAP	(6) TGW	(7) NAT-GW
Traffic Costs	$30.00	$30.00	$33.30	$50.00	$65.00
Static Costs	$29.20	$87.60	$29.20	$1,635.20	$146.00
Total Costs	$59.20	$117.60	$62.50	$1,685.20	$211.00

Example 3: Low volume, redundant

In this example, we show how redundancy brings additional costs, but with some solutions accelerating faster than others.

In this example, there are 4 regions, each with 10 VPCs, and each VPC has 3 EC2 instances (thus 120 total instances). Total traffic for the month is 1 TB. We'll assume traffic passes between regions with the similar rates to us-east-1 to us-west-2. A realistic example would be the set of us-east-1, us-west-2, eu-west-1, and eu-central-1. There are also 3 AZs per VPC, each of which has redundant networking resources.

For options requiring VPC endpoints (Options 3, 4, 5), we assume one endpoint per AZ per VPC per region (120 total endpoints = 4 regions * 10 VPCs * 3 AZs). For NAT Gateway (Option 7), we assume one NAT Gateway per AZ per VPC (120 total).

-	(1) EIGW	(2) IGW	(3) VPC Peering	(4) Cross-Region PL	(5) MRAP	(6) TGW	(7) NAT-GW
Traffic Costs	$20.00	$20.00	$30.00	$30.00	$33.30	$50.00	$65.00
Static Costs	-	$438.00	$876.00	$876.00	$876.00	$2,336.00	$4,380.00
Total Costs	$20.00	$458.00	$906.00	$906.00	$909.30	$2,386.00	$4,445.00

With centralization

-	(3) VPC Peering	(4) Cross-Region PL	(5) MRAP	(6) TGW	(7) NAT-GW
Traffic Costs	$30.00	$30.00	$33.30	$50.00	$65.00
Static Costs	$87.60	$262.80	$87.60	$1,693.60	$438.00
Total Costs	$117.60	$292.80	$120.90	$1,743.60	$503.00

Example 4: High volume, redundant

In this final example, we show how higher traffic volume causes traffic costs to be of higher importance. We use all the same resources as Example 3, but assume 100,000 GB of traffic per month. This amount would be equivalent to 39.5 MB/s of continuous traffic over the course of a month. Since all resources provisioned support 10 Gbps or higher, there's no need to provision extra networking resources to meet that traffic volume.

-	(1) EIGW	(2) IGW	(3) VPC Peering	(4) Cross-Region PL	(5) MRAP	(6) TGW	(7) NAT-GW
Traffic Costs	$2,000.00	$2,000.00	$3,000.00	$3,000.00	$3,330.00	$5,000.00	$6,500.00
Static Costs	-	$438.00	$876.00	$876.00	$876.00	$2,336.00	$4,380.00
Total Costs	$2,000.00	$2,438.00	$3,876.00	$3,876.00	$4,206.00	$7,336.00	$10,880.00

With centralization

-	(3) VPC Peering	(4) Cross-Region PL	(5) MRAP	(6) TGW	(7) NAT-GW
Traffic Costs	$3,000.00	$3,000.00	$3,330.00	$5,000.00	$6,500.00
Static Costs	$87.60	$262.80	$87.60	$1,693.60	$438.00
Total Costs	$3,087.60	$3,262.80	$3,417.60	$6,693.60	$6,938.00