The Central IT Strategy: Cutting Cross-Region AWS Data Costs for Internal Services

If you are part of Central IT, you are effectively running an internal SaaS platform. You house critical services in a primary region (e.g., eu-west-1 Ireland), and internal application teams across the company consume these services from other regions (e.g., eu-central-1 Frankfurt).

If these internal teams are connecting to your service via a public Application Load Balancer (ALB) DNS name, your organization is paying an “internet tax.” Every gigabyte leaving Ireland for the public internet costs roughly $0.09. Routing internal traffic out to the internet just to bring it back into another AWS region is inefficient, expensive, and increases your attack surface.

Keeping this traffic on the Amazon global network backbone, you can slash data transfer costs down to roughly $0.02 — $0.03 per GB.

This post explores the three primary methods for Central IT to achieve this: VPC Peering (the cost leader), AWS PrivateLink (the security and manageability leader) and AWS Transit Gateway(The Coporate Hub).

The Prerequisite: Go Private

Before implementing either solution, ensure your architecture supports private access. If you only have a public-facing ALB/NLB, you must deploy a parallel Internal ALB/NLB. PrivateLink is designed to connect to internal resources that do not have public IP addresses. While Transit Gateway and VPC Peering works for internal resources connection, VPC Peering is more treated as network bridge and Transit Gateway as network office for Hub-and-Spoke mode. Think of it like an international airline system:

• Mesh (VPC Peering): If you want to fly from Lyon to Manchester, you need a direct flight. If you want to fly from Lyon to Stuttgart, you need another direct flight. As you add cities, you need hundreds of direct routes.
• • Hub-and-Spoke (Transit Gateway): You fly from Lyon to Frankfurt (The Hub). From Frankfurt, you can transfer to Manchester, Stuttgart, or New York. You only need one flight path: Lyon → Frankfurt.

Option 1: VPC Peering (The Cost-Leader)

A VPC peering connection is a networking connection between two VPCs that enables routing of traffic using private IPv4 addresses. It works within the same region and across different regions (Inter-Region Peering). Think of it as plugging a direct network cable between your central datacenter and the internal team’s datacenter.

VPC Peering is the absolute cheapest way to move data between regions. You only pay the inter-region data transfer fee (~$0.02/GB). There are no hourly infrastructure fees or data processing surcharges.

What to Consider Before Choosing Peering

The Operational Headache: IP Overlap. Peering has a hard constraint: You cannot peer VPCs with overlapping IP ranges. If your central service VPC is 10.0.0.0/16, and an internal team in Frankfurt—perhaps enabled by an M&A activity or legacy setup—also uses 10.0.0.0/16, peering is impossible. For Central IT managing dozens of connections, IP Address Management (IPAM) becomes a significant hurdle.

For Central IT, the primary concern with peering isn’t necessarily that internal teams are malicious; it’s Blast Radius and Lateral Movement. If a consumer team’s VPC in Frankfurt gets compromised, a peering connection can turn that single breach into a direct threat to your central service hub. Here are the specific security risks of VPC Peering:

1. The “Wide Open Door” Risk VPC Peering connects networks at the IP layer. By default, it enables full connectivity potential between the route tables. If you aren’t extremely careful with Security Groups, a compromised instance in the consumer VPC can scan every port on every instance in your peered subnets. VPC Peering is an “open hallway”; you have to manually lock every single door along that hallway.

2. Cross-Region Security Group Limitations This is a critical operational risk for the Ireland-to-Frankfurt scenario. In cross-region peering, you cannot reference a Security Group ID as what you can in same region Peering. You are forced to allow traffic from a broad IP Range (e.g., “Allow traffic from 10.2.0.0/16"). This forces you to trust the entire VPC or subnet of the consumer team, rather than specific instances.

3. Lateral Movement (The “Pivot” Attack) If an attacker gains shell access to an EC2 instance in the consuming VPC, they can use the peering link to map out your central internal architecture. They may attempt to exploit other internal services (databases, caches) running in your VPC that weren’t meant to be exposed but are accessible due to broad peering rules.

4. Bypassing Central Inspection If your organization uses a “Security Inspection VPC” (e.g., with Palo Alto or Fortinet firewalls) to filter east-west traffic via a Transit Gateway, direct VPC Peering bypasses this inspection entirely.

The Implementation Steps to follow

In general, the main peering targets are your highly trusted entities either internal teams or strategic consumers. Once decision is made, you can follow these steps:

1. Verify CIDRs: Ensure your VPC CIDR and the customer’s VPC CIDR do not overlap.
2. Create Peering Request: In the VPC console, create a peering connection request, specifying the customer’s account ID and VPC ID (and region, if different).
3. Customer Acceptance: The customer must accept the pending peering request.
4. Update Route Tables (Both sides): ◦ You: Add a route to your private subnet routing tables sending traffic destined for the customer’s CIDR to the peering connection ID (pcx-xxxx). ◦ Customer: Adds a route sending traffic for your CIDR to the peering connection ID.
5. Update Security Groups: On your Internal ALB/NLB’s security group, add an inbound rule allowing HTTPS traffic from the customer’s VPC CIDR block.
6. Setup DNS: For the smoothest experience, use Route53 “Cross-Account VPC Association” to share your Private Hosted Zone with the customer. This allows their EC2 instances to resolve your service’s domain name to your internal ALB’s private IP automatically.

# 1. Initiate the Peering Connection
aws ec2 create-vpc-peering-connection \\
    --region eu-west-1 \\ 
    --vpc-id vpc-YOUR_SERVICE_VPC_ID \\
    --peer-vpc-id vpc-CUSTOMER_FRANKFURT_VPC_ID \\
    --peer-region eu-central-1 \\  # Customer's Region
    --peer-owner-id 123456789012  # Customer's Account ID

# 2. Accept the Peering Connection
aws ec2 accept-vpc-peering-connection \\
    --region eu-central-1 \\
    --vpc-peering-connection-id pcx-xxxxxxxxx # Output from previous cmd

# 3. Update Routing Table on both side
aws ec2 create-route \\
    --region eu-west-1/eu-central-1 \\
    --route-table-id rtb-YOUR_PRIVATE_SUBNET_RTB \\
    --destination-cidr-block 10.2.0.0/16 \\ # Your/Customer's VPC CIDR
    --vpc-peering-connection-id pcx-xxxxxxxxx

# 4. Update Security Groups on both side if needed
aws ec2 authorize-security-group-ingress \\
    --region eu-west-1 \\
    --group-id sg-YOUR_INTERNAL_ALB_SG \\
    --protocol tcp \\
    --port 443 \\
    --cidr x.x.x.x/x # Customer's VPC CIDR

# Optional: Only needed if outbound rules are restricted
aws ec2 authorize-security-group-egress \\
    --region eu-central-1 \\
    --group-id sg-CUSTOMER_INSTANCE_SG \\
    --protocol tcp \\
    --port 443 \\
    --cidr x.x.x.x/x # Your Service VPC CIDR

More over DNS setup

Once VPC peering is done with all update of SG or Routing Table, the last step is DNS setup. In general, to provide the smoothest experience for internal customers, the Cross-region PHZ Association is better than asking customers to created their own PHZ.

The Decision: Associate vs. Duplicate

You have two architectural choices for how the customer resolves your internal ALB/NLB api.yourservice.internal.

Option A: Cross-Account Association (Recommended)

You “share” your existing Private Hosted Zone (PHZ) from Ireland with their VPC in Frankfurt. Once associated, their EC2 instances query Route53, and Route53 answers using your records. It’s better:

1. Single Source of Truth: If your Internal ALB IP changes (e.g., you rebuild the stack), you update the record once in your central PHZ. All connected customers (Ireland, Frankfurt, etc.) see the update immediately.
2. Zero Admin for Customer: They don’t need to manage DNS records. They just “plug in.”

But do make sure if you have other services in this PHZ, with VPC peering, customer connection to these services will change at the same time. You may want to align the behavior.

Option B: Customer Creates New PHZ (Duplicate)

The customer creates their own PHZ named api.yourservice.internal in their account and manually adds an A-Record or CNAME record pointing to your IP. A-Record with specific IPs is definitely not good. While even with CNAME record

1. Management Nightmare: If you have 20 internal teams, you have 20 different DNS records to chase down. If you have architecture change, e.g. migrate from ALB to NLB for performance or want Blue/Green deployment for new stack and switch traffic, customers traffic breaks until they manually update their DNS record.

Here is a brief summary which you can refer to while making decision:

DNS

Option 2: AWS PrivateLink (The Internal SaaS Standard)

If VPC Peering is a direct bridge, AWS PrivateLink is like giving your customer a magic door inside their own building that opens directly into your service. You create a “VPC Endpoint Service,” and the customer creates an “Interface Endpoint.” This places an Elastic Network Interface (ENI) directly into the customer’s subnet. When they send traffic to that ENI IP address, AWS tunnels it securely to your load balancer. More over AWS PrivateLink here.

What to Consider Before Choosing PrivateLink

PrivateLink is the current standard for multi-tenant SaaS providers because it solves the IP overlap issue and offers strict, one-way security.

1. The IP Overlap Solver: PrivateLink works perfectly even if both you and the customer are using 10.0.0.0/16. Because the traffic hits a specific ENI IP in their subnets, there are no routing conflicts.
2. Built-in Security Isolation (Solves Peering Risks): PrivateLink is unidirectional by design. The consumer can initiate connections to your service on a specific port (e.g., 443), but your service cannot initiate connections back to them. Furthermore, it only exposes the load balancer, not the rest of your network. It inherently mitigates the “lateral movement” risks associated with peering. Note here unidirectional means who can initiate the connection, but data flows back and forth once the session is on.
3. Architecture Requirements: PrivateLink currently requires a Network Load Balancer (NLB) as the entry point. If you use an ALB, you must place an internal NLB in front of your internal ALB.
4. Cost Structure: PrivateLink is slightly more expensive than peering. You pay for the hourly endpoint usage plus a “Data Processing” fee (~$0.01/GB) in addition to standard data transfer rates, which results as ~$0.03/GB in total.
5. Cross-region support on: Since late 2024, Interface Endpoint supports cross-region access to Endpoint Service through it comes with extra cost, latency and complexity.

The Implementation Steps

Once decision is made, there are actions to be done in Provide and Consumer side:

Provider Side (You):

1. Prepare Load Balancer: Ensure you have an internal NLB pointing to your application (or pointing to your internal ALB as a target).
2. Create Endpoint Service: Create a “VPC Endpoint Service” and attach it to your NLB. If cross-region, allow specifically the region in Endpoint service. Do taking private DNS into account.
3. Set Permissions: Whitelist the IAM ARN of the customer’s AWS account so they have permission to connect to your service.
4. Provide Service Name: Give the customer the generated Service Name (e.g., com.amazonaws.vpce.eu-west-1.vpce-svc-xxxx).

Consumer Side (Customer):

1. Create Endpoint: In their VPC console, they “Create Endpoint,” choose “Find service by name,” and paste the name you provided.
2. Select Subnets: They choose which subnets in their VPC the endpoint network interfaces should live in.
3. Enable Private DNS: Crucially, they should enable “Private DNS” option during creation. This allows them to use your actual service domain name (e.g., api.yourservice.com) within their VPC, and AWS automatically resolves it to the private endpoint IPs.

More over Private DNS

While choosing AWS PrivateLink, DNS config simply cannot and should not be ignored. It’s highly recommended to enable Private DNS in VPC Endpoint Service and it supports only one domain name. If you need to serve multiple domain names and if wildcart doesn’t work, it’s better to leave this OFF and let the customers manage the DNS in their Route53 PHZ. More details you can refer this post.

Here is the brief summary if Private DNS on/off:

Private DNS

Option 3: AWS Transit Gateway (The Corporate Hub)

AWS Transit Gateway (TGW) acts as a cloud router. You attach all VPCs to a central TGW, acting as a hub-and-spoke network. For cross-region traffic, you peer the TGW in Ireland with a TGW in Frankfurt.

What to consider before choosing TGW

1. Centralized Management: You manage connections in one place rather than managing a “mesh” of hundreds of peering connections.
2. Security Inspection: Unlike direct VPC Peering, TGW allows you to route traffic through a central “Inspection VPC” (e.g., carrying Palo Alto or Fortinet firewalls) for deep packet inspection before it reaches your service.
3. Transitive Routing: VPC Peering is non-transitive but TGW is transitive.
4. The Cost: Transit Gateway is the most expensive option for high-volume data transfer because AWS charges you for the “Data Processing” at the TGW level plus the actual data transfer. You pay for data entering and leaving TGW. ~$0.02 (Data Processing) + ~$0.02 (Inter-Region Transfer) = ~$0.04/GB.
5. IP Overlap Issues: Like VPC Peering, TGW generally requires unique IP ranges. Routing overlapping CIDRs through a TGW is technically possible but requires complex NAT (Network Address Translation) tables that add significant management overhead.
6. Latency: Every packet must hop to the Hub, be processed, and hop to the destination.7 This adds a tiny amount of latency compared to a direct line.
7. MTU and Bandwidth: TGW enforces a maximum MTU as 8500, this may cause issue for large packets if not configured properly. Also the uppper limit for Bandwidth is 50Gbs.

The Implementation Steps

Here is a summary of the steps to implement an Inter-Region Transit Gateway (TGW) architecture (e.g., Ireland $\leftrightarrow$ Frankfurt).

1. Create the Hubs (TGW Creation): Create a Transit Gateway in each region (e.g., tgw-ireland and tgw-frankfurt). Assign unique ASNs to each. If they match, peering will fail.
2. Connect the Spokes (VPC Attachments): Create VPC Attachments to connect your Service VPC and Customer VPCs to their local TGW. Also select one subnet per Availability Zone to place the TGW network interface.
3. Build the Bridge (Inter-Region Peering): Transit Gateway peering, like VPC peering
4. Configure the Hub Routing (TGW Route Tables): Ensure local VPC attachments are “propagating” their CIDRs to the TGW Route Table automatically. You must manually add a route for the other region’s CIDR pointing to the Peering Attachment. (e.g., In Ireland TGW: Dest: Frankfurt-CIDR →Target: Peering-Attachment).
5. Configure the Local Routing (VPC Route Tables): Update the standard route tables in your actual VPC subnets. Add a route sending traffic for the remote region to the local Transit Gateway ID.
6. Security & Verification: Update Security Groups to allow traffic from the remote CIDR ranges (SG IDs will not work). You can use AWS Network Reachability Analyzer or standard ping/curl to verify end-to-end connectivity.

Other Options

For cross region traffic, AWS also offers Cloud WAN and Global accelerator, but are more expensive. If you are in gaming, really need performance and low-latency, Global accelerator may be a good option.

Cloud WAN is being treated as the next generation of TGW designed for global scale. Instead of managing individual TGWs in Ireland and Frankfurt and manually building the “bridge” (peering) between them, Cloud WAN allows you to define a Single Global Network Policy, and AWS builds the underlying mesh for you automatically. If you are expanding in more regions, Cloud WAN is a good option to take away the management burden from TGW.

A quick decision matrix:

Cost Matrix

Final Recommendation

1. Choose AWS PrivateLink if… You are offering a specific service (API, Tool, Dashboard) to internal teams. The slight cost premium over peering is worth the security isolation and the ability to ignore IP overlapping issues. This is the modern standard for “Internal SaaS.”

2. Choose VPC Peering if… You are moving massive amounts of raw data (e.g., petabytes of backups) where cost is the only metric that matters, and you have strict control over the network IPs to ensure no overlaps.

3. Choose Transit Gateway if… You need general “any-to-any” connectivity (e.g., connecting VPCs to on-premise VPNs or Direct Connect) or if you require traffic to pass through a central firewall appliance for compliance reasons. Do not use it solely for point-to-point service consumption, as you will pay a premium for features you aren’t using.