Forem: Gergo Vadasz

No More Middlemen: Native AWS to Google Cloud Connectivity Explained

Gergo Vadasz — Fri, 24 Apr 2026 21:42:23 +0000

Until now, connecting AWS and Google Cloud meant stitching together VPNs over the public internet, colocating in the same facility with two separate cross-connects, or paying a third-party network provider to bridge the gap. These approaches work - plenty of companies rely on them daily - but they all come with operational overhead and added complexity that make multi-cloud connectivity harder to set up and maintain than it needs to be.

That changed on April 14, 2026, when AWS launched AWS Interconnect - multicloud with Google Cloud as the first partner. For the first time, you can provision a dedicated, private connection between AWS and GCP directly from the console - no middleman, no colo, no VPN tunnels. I got hands-on with it the same week it went GA, and in this post I'll walk you through exactly how to set it up, step by step.

What is AWS Interconnect - multicloud?

AWS Interconnect - multicloud is a new service under the AWS Direct Connect family that lets you create private, high-bandwidth connections directly to other cloud providers. At launch, Google Cloud is the only supported partner, with Microsoft Azure and Oracle Cloud Infrastructure coming later in 2026.

The key things to know:

It lives under Direct Connect in the AWS console
Connections are region-to-region (e.g., AWS eu-central-1 to GCP europe-west3)
It uses a Direct Connect gateway on the AWS side and Partner Cross-Cloud Interconnect on the GCP side
Bandwidth ranges from 1 Gbps to 100 Gbps, with granular sizing - unlike traditional Cross-Cloud Interconnect which only offers 10G/100G increments
Redundancy is built into the underlying resources - no need to manually configure redundant connections like with traditional Cross-Cloud Interconnect
The connection can be initiated from either the AWS or the GCP side
Each GCP project is limited to one transport resource per region
Pricing is based on bandwidth and geographic scope
Free tier: One free local 500 Mbps interconnect per region, starting May 2026

Architecture Overview

Before diving into the setup, here's what the end-to-end architecture looks like:

On the AWS side, traffic flows from your EC2 instances through a VPC Attachment into a Transit Gateway, then via a Direct Connect Attachment to a Direct Connect Gateway. The Direct Connect Gateway connects to GCP through the Partner Cross-Cloud Interconnect - this is the actual cross-cloud link that AWS provisions behind the scenes. On the Google Cloud side, the interconnect attaches to your VPC via GCP VPC Network Peering - to be clear, this is not a peering between the AWS VPC and the GCP VPC. It's a standard GCP VPC Network Peering used to connect the interconnect's managed network to your own GCP VPC, giving your Compute Engine instances direct reachability to AWS resources.

VPC Network Peering is not the only option on the GCP side - you can also use Network Connectivity Center (NCC) to connect the Partner Cross-Cloud Interconnect to your Google Cloud environment. NCC is the better choice if you need to connect multiple VPCs or integrate this into a broader hub-and-spoke topology on the GCP side. In this walkthrough, I'm using VPC Network Peering for simplicity.

The key takeaway from this diagram is that both sides use familiar networking primitives - there's no new proprietary overlay. If you've worked with AWS Transit Gateway or GCP Partner Interconnect before, the building blocks will feel familiar. What makes this work is that AWS and Google maintain pre-established network links between their regions. This service automates the provisioning of a dedicated connection over that shared infrastructure - no manual cross-connects or third-party involvement needed.

Prerequisites

Before you begin, you'll need:

An AWS account with access to Direct Connect in a supported region
A Google Cloud project with the Network Connectivity API enabled
Appropriate IAM permissions on both sides

Step 1: Create the Multicloud Interconnect in AWS

Navigate to Direct Connect > AWS Interconnect - multicloud in the AWS console. You'll see the interconnect dashboard - click Create Multicloud Interconnect.

Select a provider

The first step is selecting your cloud provider. Currently, only Google Cloud is available.

Select regions

Choose the AWS region and the corresponding Google Cloud region for your interconnect. Your region choices determine the physical connection path, which affects latency and performance. In my setup, I'm using eu-central-1 (Frankfurt) on the AWS side and europe-west3 (Frankfurt) on the GCP side - keeping both in the same metro for the lowest latency.

Configure options

Configure the interconnect details: give it a description, select a Direct Connect gateway (or create one), choose your bandwidth, and add any tags. On the right side, you'll see the option to create a new Direct Connect gateway if you don't have one yet.

Once submitted, AWS provisions the interconnect and generates an activation key. This key is what ties the AWS side to the GCP side - copy it, you'll need it in the next step.

Step 2: Create the Transport in Google Cloud

Now switch to the Google Cloud Console. Navigate to Network Connectivity > Partner Cross-Cloud Interconnect and click Create Transport.

Connection start point

Paste the activation key from AWS. Google Cloud will automatically detect the remote cloud provider and region. A transport profile is pre-provisioned for you.

Transport profile

The transport profile confirms the connection details: the remote cloud service provider (Amazon Web Services), region, description, and bandwidth.

Basic configuration

Configure the transport name, bandwidth, IP stack type (IPv4 single stack), and transport connectivity settings.

Connection

Select the appropriate VPC on GCP side, and provide what ip ranges should GCP advertise towards AWS.

Verify the transport via CLI

You can also verify and manage the transport using gcloud. Note that at the time of writing, the transport commands are only available in the beta track:

gcloud beta network-connectivity transports list

NAME: gcp-to-aws
REGION: europe-west3
REMOTE_PROFILE: aws-eu-central-1
BANDWIDTH: BPS_1G
STATE: ACTIVE

For more details, use describe with the --region flag:

gcloud beta network-connectivity transports describe gcp-to-aws --region europe-west3

Set up VPC Network Peering via CLI

Once the transport is active, create the VPC Network Peering between your VPC and the transport's managed network. You can find the peering network URI in the transport's peeringNetwork field from the describe output above.

gcloud compute networks peerings create "gcp-to-aws" \
    --network="gcp-vpc" \
    --peer-network="projects/n088e7d12bbcf2d64p-tp/global/networks/transport-5c75b1ed8bc1eeec-vpc" \
    --stack-type=IPV4_ONLY \
    --import-custom-routes \
    --export-custom-routes

Make sure to enable --import-custom-routes and --export-custom-routes so that routes are exchanged between your VPC and the interconnect.

Step 3: Wait for the Connection to come up

Since we initiated the connection from the AWS side and pasted the activation key into GCP, there's no additional key exchange needed. The GCP side confirms there is no pairing key to share back - the activation key from AWS was sufficient.

Back in the AWS console, the interconnect status will transition from Pending to Available automatically once both sides have completed their configuration. No manual acceptance is required when the connection is initiated from AWS.

Step 4: AWS Networking Setup

With the interconnect link established, you now need to wire up the AWS networking side to make traffic flow.

Create a Transit Gateway

Create a Transit Gateway to act as the central hub for routing between your VPCs and the interconnect.

Direct Connect Gateway

The Direct Connect gateway bridges the interconnect and your AWS networking. Link it to the Transit Gateway so traffic can flow between your VPCs and GCP.

Configure Allowed Prefixes

Finally, specify the allowed prefixes - these are the AWS-side CIDR ranges that will be advertised towards GCP over the interconnect.

Step 5: Verify the Connection

AWS side: Transit Gateway route table

Once everything is associated, check the Transit Gateway route table. You should see routes learned from the GCP side via the interconnect.

GCP side: Transport details

Back in Google Cloud, the transport details should show an Active status, confirming the connection is up and running.

GCP side: VPC routes

Finally, check your GCP VPC routes. You should see the AWS prefixes appearing in the route table, learned through the cross-cloud interconnect.

Ping test

With routes in place on both sides, let's verify end-to-end connectivity. From the AWS EC2 instance (192.168.0.10), pinging the GCP VM (10.0.0.2):

ubuntu@ip-192-168-0-10:~$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=61 time=4.16 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=61 time=1.60 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=61 time=1.62 ms
--- 10.0.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.598/2.456/4.155/1.201 ms

And from the GCP VM (10.0.0.2), pinging back to the AWS instance:

gergo@gcp-test-vm:~$ ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
64 bytes from 192.168.0.10: icmp_seq=1 ttl=61 time=2.42 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=61 time=1.33 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=61 time=1.44 ms
64 bytes from 192.168.0.10: icmp_seq=4 ttl=61 time=1.36 ms
--- 192.168.0.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.334/1.636/2.419/0.453 ms

Sub-2ms latency between Frankfurt regions - that's what you'd expect from a dedicated interconnect within the same metro.

First Impressions

After setting this up, a few things stand out:

What I liked:

The activation key / pairing key exchange is straightforward - it's similar to how Partner Interconnect works in GCP today
End-to-end setup took under an hour, which is remarkable compared to traditional cross-connect provisioning
The integration with existing AWS networking primitives (Direct Connect gateway, Transit Gateway) means you can plug this into an existing hub-and-spoke architecture without redesigning anything

What to watch out for:

The Direct Connect gateway and Transit Gateway association is an extra step that could trip up users who are new to AWS networking. AWS VPN Gateway can be used as well instead of TGW.
Terraform support is not yet available, though it's being tracked - for now, it's console/CLI only

What I'm curious about:

How the free 500 Mbps tier (coming May 2026) will work in practice
Performance characteristics compared to VPN-over-internet approaches
How Azure and Oracle Cloud integrations will look when they launch later this year - cross-cloud connectivity is already possible between Azure and Oracle Cloud, so it will be interesting to see how the AWS Interconnect approach compares

Conclusion

AWS Interconnect - multicloud is a significant step forward for multi-cloud networking. It removes the biggest friction point - the physical connectivity - and turns what used to be a weeks-long procurement process into something you can set up in an afternoon. If you're running workloads across AWS and Google Cloud, this is worth evaluating immediately, especially with the free 500 Mbps tier on the horizon.

References

Originally published at gergovadasz.hu

Deploy a Private Website with Cloudflare Zero Trust and Terraform

Gergo Vadasz — Thu, 23 Apr 2026 13:00:00 +0000

Cloudflare Zero Trust is a security platform that lets you control who can access your internal or private applications — without using a traditional VPN. It authenticates users through methods like email or Google/Microsoft accounts before granting access.

In this post, I'll show you how to deploy a private website behind Cloudflare Zero Trust using Terraform, with a VM hosted on Google Cloud.

What You'll Need

A free Cloudflare account
A domain managed by Cloudflare
Cloudflare Zero Trust activated
Infrastructure to host the website (VM, PaaS, etc.)
For this guide: a Google Cloud project with VPC network access

Collect Cloudflare Account Details

Create a terraform.tfvars file with your Cloudflare and GCP details:

cloudflare_zone           = "yourdomain.com"
cloudflare_zone_id        = "ce...."
cloudflare_account_id     = "7a...."
cloudflare_email          = "[email protected]"
cloudflare_token          = "b6...."
gcp_project_id            = "your-gcp-project"
zone                      = "europe-west4-a"
machine_type              = "e2-small"

API Token Requirements:

Cloudflare Tunnel: Edit
Access: Apps and Policies: Edit
DNS: Edit
Zero Trust: Edit

Deploy with Terraform

The Terraform code is available in my public repository: github.com/vadaszgergo/terraform-public/tree/main/cloudflare-zero-trust-web-application

Deployment involves:

Cloudflare Zero Trust resource creation (takes seconds)
VM provisioning in Google Cloud
Auto-installation via cloud-init script (5-6 minutes):
- OS updates and package installation
- Static website creation
- Cloudflared tunnel configuration and startup

Once complete, your website is accessible at http_app.yourdomain.com — but only after email authentication through Cloudflare's access policy.

What Makes This Powerful

This setup can serve as a secure entry point for both private and public websites. The flexibility is what makes it interesting:

Private applications: Internal dashboards, admin panels, staging environments — accessible only to authenticated users
Public with protection: Your production site behind DDoS protection and WAF
Any hosting backend: Works with VMs, containers, home labs, or any environment that can run cloudflared

You get all of this without opening any inbound ports on your server, without configuring a VPN, and without managing certificates manually.

Conclusion

It's surprisingly simple to protect your applications using Cloudflare's powerful policies and authentication features, without relying on a traditional VPN. The Terraform code handles everything — from the Cloudflare tunnel and access policies to the GCP VM and website setup.

You can extend this further with multi-user policies, device posture checks, and Cloudflare's analytics dashboard.

Check out the full guide and Terraform code at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.

Save NAT Gateway Costs by Using an EC2 - Terraform Code Included

Gergo Vadasz — Tue, 21 Apr 2026 13:00:00 +0000

AWS NAT Gateways cost at least $33/month before you even send a byte of data. For dev environments, small startups, or personal projects, that's a lot of money for something a $3.50/month EC2 instance can handle.

In this post, I'll show you how to use a small EC2 instance as a NAT device — and provide the complete Terraform code to deploy it.

The Cost Comparison

Solution	Monthly Base Cost
AWS NAT Gateway	~$33 + data processing fees
EC2 NAT Instance (t2.micro)	~$3.50
Elastic IP (per instance)	$3.60

The trade-off: an EC2 NAT instance introduces a potential single point of failure without an HA setup. For production, you'd want multiple instances. But even two EC2 NAT instances (one per AZ) are more economical than a single NAT Gateway.

How It Works

The concept is simple:

Deploy a Linux server in a public subnet
Create a route table for private subnets pointing 0.0.0.0/0 to the EC2 instance's network interface
Disable source/destination check on the EC2 instance
Configure IP forwarding and iptables NAT rules on the instance

Configuration Commands

The EC2 instance needs IP forwarding enabled and iptables configured for NAT:

# Enable IP forwarding
echo 1 | tee /proc/sys/net/ipv4/ip_forward

# Make it persistent
sed -i '/net.ipv4.ip_forward=1/s/^#//g' /etc/sysctl.conf
sed -i '/net.ipv4.conf.all.accept_redirects=0/s/^#//g' /etc/sysctl.conf
sed -i '/net.ipv4.conf.all.send_redirects=0/s/^#//g' /etc/sysctl.conf
sysctl -p

# Configure iptables for NAT masquerading
mkdir -p /etc/iptables
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables-save > /etc/iptables/rules.v4

Terraform Implementation

The Terraform code handles everything:

VPC with CIDR 10.0.0.0/16
Internet Gateway
2 public subnets (10.0.1.0/24, 10.0.2.0/24)
2 private subnets (10.0.3.0/24, 10.0.4.0/24)
EC2 NAT instance (t2.micro, Ubuntu 22.04 LTS)
Route tables and security groups
Disabled source/destination checking
Cloud-init script for automated NAT configuration

Deployment is straightforward:

terraform init
terraform apply

The cloud-init script handles all the NAT configuration automatically on first boot — no SSH required.

When to Use This

Good for:

Development and testing environments
Startups and small businesses watching cloud costs
Personal projects and labs
Any environment where $33/month per NAT Gateway adds up

Stick with NAT Gateway for:

Production workloads requiring high availability out of the box
High-throughput scenarios (NAT Gateway scales to 45 Gbps)
Environments where operational simplicity outweighs cost savings

Conclusion

For high availability, deploying multiple EC2 NAT instances (one per AZ) remains more economical than multiple NAT Gateways while maintaining secure private resource internet access.

Get the complete Terraform code at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.

Hub-and-Spoke Topology with Azure Firewall - Deployment Guide with Terraform

Gergo Vadasz — Thu, 16 Apr 2026 13:00:00 +0000

Enterprise organizations frequently employ hub-and-spoke network architectures. This design streamlines network administration, enables centralized traffic inspection, and establishes a single connectivity gateway to and from the internet. In Azure, Azure Firewall is frequently the go-to solution for implementing such a centralized security model.

In this post, I'll walk through a simplified hub-and-spoke configuration where Azure Firewall manages both north-south (internet-bound) and east-west (inter-spoke) traffic filtering.

What is Hub and Spoke Topology?

A hub-and-spoke topology consists of a central hub serving as the primary connection point, with all other networks (spokes) connecting to it. In Azure, the hub hosts shared services — firewalls, VPN gateways, monitoring tools — while spokes contain workloads dependent on the hub for connectivity and security.

Key advantages:

Simplifies management across multiple networks
Centralizes shared services deployment
Reduces operational complexity as scale increases
Improves security posture through unified policy enforcement
Enhances scalability — adding spokes doesn't require reworking multiple peerings

Azure Firewall as a Central Security Solution

Azure Firewall is a managed, cloud-native network security service controlling and logging traffic across Azure environments. In hub-and-spoke topologies, it serves as the enforcement point for both inbound/outbound connections and lateral spoke-to-spoke traffic.

Benefits of central firewall placement:

Centralized traffic inspection with consistent policy enforcement
Automatic scalability and built-in high availability
Single location for rule management instead of per-spoke deployments
Advanced threat protection via Threat Intelligence filtering, FQDN filtering, and Application Rules

Architecture

Network Configuration:

Hub VNet: 10.0.0.0/16 containing AzureFirewallSubnet with dedicated public IP
Spoke 1: 192.168.0.0/16 with subnet 192.168.1.0/24
Spoke 2: 172.16.0.0/16 with subnet 172.16.1.0/24

Key Components:

VNet Peerings: Hub connects to each spoke with forwarded traffic enabled
User-Defined Routes: Each spoke subnet routes 0.0.0.0/0 to firewall private IP (Virtual Appliance)
Exception Routes: SSH access from specific external IPs bypasses firewall
Firewall Rules: Permit ICMP/TCP (22/80/443) between spokes and to internet
Testing VMs: Ubuntu VMs in each spoke with public IPs for connectivity testing

Result: Direct spoke-to-internet and spoke-to-spoke communication is blocked; all traffic routes through the firewall for inspection and logging.

The Hidden Challenge: Azure Firewall SNAT Port Exhaustion

A critical limitation worth knowing about: an Azure Firewall instance with a single public IP provides 2,496 SNAT ports per backend virtual machine, totaling approximately 4,992 ports with the default dual instances.

Scaling solutions:

Attach up to 250 public IPs (expensive; operationally complex for external whitelisting)
Integrate NAT Gateway for 64,512 ports per IP supporting up to 16 IPs (1+ million pooled ports)

This is something that often catches people off guard in production, so plan for it early if you expect significant outbound connections.

Try It Yourself

The complete Terraform code deploys this entire hub-and-spoke architecture with Azure Firewall — VNets, peerings, UDRs, firewall rules, and test VMs. A single terraform apply gets you a working lab.

Check out the full code at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.

Deploying an AWS Multi-Region Hub-Spoke Architecture with Terraform

Gergo Vadasz — Tue, 14 Apr 2026 13:00:00 +0000

I recently tested a multi-region hub-and-spoke architecture in AWS using Transit Gateways. While this architecture may not suit all production scenarios, it effectively demonstrates Transit Gateway functionality and scalable multi-region networking principles.

High-Level Architecture

Components:

1 Hub VPC in eu-west-1
1 Spoke VPC in eu-central-1
1 Spoke VPC in us-east-1

Key features:

Dedicated Transit Gateways per region facilitate inter-region routing
Spoke TGWs connect to Hub TGW, enabling spoke-to-spoke traffic through the hub
Hub VPC provides internet outbound access via NAT gateways
Deployment includes test Ubuntu servers: one in EU spoke public subnet, one in US spoke private subnet

Setup Walkthrough

1. Deploying VPCs and Subnets

Three VPCs deployed across regions with public/private subnets and route tables. These require later modifications for proper cross-region routing.

2. Setting Up Internet Access

Internet Gateways deployed in Hub and EU spoke VPCs to enable SSH access for testing.

3. Deploying Transit Gateways and Attachments

Three Transit Gateways created with two attachment types:

VPC Attachments: Connect VPCs to regional TGWs
Peering Attachments: Connect Transit Gateways across regions

Communication flow: VPC 1 → VPC Attachment → Transit GW 1 → Peering Attachment → Transit GW 2 → VPC Attachment → VPC 2

4. Configuring Transit Gateway Route Tables

Spoke TGW Route Tables:

Default route (0.0.0.0/0) directs traffic to peering attachment connecting spoke to hub

Hub TGW Route Table:

EU Spoke VPC CIDR → EU Spoke Peering Attachment
US Spoke VPC CIDR → US Spoke Peering Attachment
Default Route (0.0.0.0/0) → Hub VPC Attachment with NAT Gateways

5. Modify VPC Route Tables

Spoke VPCs: Add default route (0.0.0.0/0) to local Transit Gateway

Hub VPC: Add routes for spoke VPC CIDRs (10.0.0.0/16 and 192.168.0.0/16) to local Hub TGW

6. Deploying NAT Gateways for Internet Access

NAT Gateways deployed in Hub VPC public subnets route spoke VPC internet traffic. Hub private subnet route tables configured with 0.0.0.0/0 pointing to NAT Gateways.

7. Deploying and Testing Servers

Testing procedure:

SSH into EU Spoke public server via its public IP
From EU server, SSH into US private server (verifies spoke-to-spoke communication)
From US server, test internet connectivity:

ping google.com
curl ifconfig.me

The public IP should match the Hub NAT Gateway IP, confirming correct outbound routing through the hub.

Summary

This architecture demonstrates how Transit Gateways enable scalable multi-region networking in AWS. Terraform automates the entire deployment, ensuring consistency and repeatability versus manual configuration.

The complete Terraform code provisions everything — VPCs, Transit Gateways, peering attachments, route tables, NAT Gateways, and test servers across all three regions.

Check out the full code at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.

Free Uptime Monitoring Using a Self-Hosted Solution

Gergo Vadasz — Sat, 11 Apr 2026 09:06:35 +0000

I recently encountered a peculiar issue with one of my clients. They were experiencing intermittent connectivity problems with a specific website—random occurrences a few times a day where the site would become unreachable. They suspected the issue might be within their Azure virtual network environment. However, after a thorough review of their setup, I was fairly confident that the problem wasn't on the Azure side. The challenge was proving it definitively.

What caught my attention was the website's unusual rate-limiting behavior. If I tested the site multiple times in quick succession, I would get blocked for 15 minutes. This behavior initially sidetracked me, but I eventually realized I needed a way to monitor the website's uptime to determine if it was going down intermittently. That's when I started exploring uptime monitoring solutions.

There are several free or trial-based SaaS solutions available in the market, such as:

UptimeRobot
Pingdom
Site24x7

While these tools are great, I wanted something more flexible and self-hosted since I already own a few servers. That's when I discovered Uptime Kuma, a free, open-source uptime monitoring tool. Its code is available on GitHub, and it offers both Docker and non-Docker installation options. I opted for the Docker installation since I already had other containers running.

Getting started with Uptime Kuma is incredibly straightforward. With just a single Docker command, you can have it up and running:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Uptime Kuma boasts a clean, responsive user interface and is packed with features. It supports monitoring for a wide range of services, including:

HTTP/HTTPS
TCP
Ping
gRPC
DNS
MQTT
Various databases (MySQL, PostgreSQL, etc.)
RADIUS

You can configure monitors with specific HTTP methods, expected response codes, headers, and even response bodies, making it highly customizable.

Once you've added a monitor, Uptime Kuma provides detailed charts and logs showing the service's uptime and downtime. This makes it easy to identify patterns or recurring issues.

To ensure comprehensive monitoring, I set up Uptime Kuma on two different servers located in separate countries. Additionally, my client is planning to deploy it in their own environment. This means we'll soon have three independent monitoring sources. My idea is simple: if the client's application running in Azure starts experiencing errors, we can cross-check the logs from all three monitoring systems. If the website is down across all three, we can conclusively prove that the issue lies with the website itself, not the client's infrastructure.

So far, Uptime Kuma has proven to be an excellent tool. Its extensive feature set, ease of use, and the fact that it's completely free make it a standout choice for anyone in need of a reliable uptime monitoring solution. The open-source community behind it deserves immense appreciation for offering such a powerful tool at no cost.

Originally published on gergovadasz.hu

Azure Route Server and NVA: Enforcing VNet Traffic - plus Terraform Code

Gergo Vadasz — Thu, 09 Apr 2026 13:00:00 +0000

I recently discovered some knowledge gaps regarding Azure Route Server (ARS) during a discussion with a cloud architect, so I decided to explore it in depth using my personal lab environment.

Lab Topology

The test environment includes:

Hub Virtual Network containing both an NVA (Network Virtual Appliance) and Azure Route Server
Two Spoke VNets, each peered only with the hub
BGP enabled between the NVA and Azure Route Server
Spoke-to-spoke traffic routed through the NVA

The goal: understand how Azure Route Server can dynamically manage routing and its advantages over static approaches.

Why Use Azure Route Server?

Limitations of Standard VNet Peering

Default VNet peering provides full connectivity but lacks traffic filtering capabilities. Enterprises often require inspection or filtering of inter-VNet traffic.

Traditional Solutions

Traffic can be redirected through:

Azure Firewall (Microsoft's native solution)
Third-party NVAs: Cisco ASR/ASA, Palo Alto NGFW, FortiGate NGFW, F5 Load Balancer, or Linux VMs running iptables/UFW

Manual implementation requires creating User-Defined Routes (UDRs), assigning next-hop values to the NVA, and updating routes when topology changes. This becomes complex and error-prone — especially in environments with dozens of VNets and subnets.

How Azure Route Server Solves This

ARS simplifies routing through dynamic BGP-based route injection:

Eliminates manual UDR management — routes learned dynamically from NVAs
Automatically updates routes — no manual next-hop modifications needed
Scales efficiently — supports multiple NVAs for redundancy
Provides high availability — deploys two redundant BGP peering IPs

Once an NVA establishes BGP peering with ARS, learned routes inject automatically into Azure's routing tables. All VNet resources route through the NVA without manual UDRs.

Testing Spoke-to-Spoke Routing via the NVA

Lab Configuration

Hub VNet hosting NVA and Azure Route Server
Spoke VNets peered only with hub (no direct spoke-to-spoke peering)
BGP session established between NVA and ARS
Spoke-to-spoke traffic constrained through NVA only

Validation Results

ARS received routes from the NVA, learned routes were injected into spoke VNets, and spoke-to-spoke traffic was successfully routed via NVA.

BGP Neighborship Summary:

nva-test# sh ip bgp summary

IPv4 Unicast Summary (VRF default):
BGP router identifier 10.0.1.4, local AS number 65020 vrf-id 0
BGP table version 6
RIB entries 8, using 1472 bytes of memory
Peers 2, using 1446 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.0.3.4        4      65515       175       160        0    0    0 00:01:37            3        1 N/A
10.0.3.5        4      65515       173       160        0    0    0 00:01:37            3        1 N/A

BGP Routes Table:

nva-test# sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
   10.0.0.0/8       0.0.0.0                  0         32768 i
   10.0.0.0/16      10.0.3.5                               0 65515 i
                    10.0.3.4                               0 65515 i
   10.1.0.0/16      10.0.3.5                               0 65515 i
                    10.0.3.4                               0 65515 i
   10.2.0.0/16      10.0.3.5                               0 65515 i
                    10.0.3.4                               0 65515 i

Spoke VNet Route Evidence

Connectivity Validation

Ping from spoke 1 to spoke 2:

gergo@spoke1-vm:~$ ping 10.2.1.4
PING 10.2.1.4 (10.2.1.4) 56(84) bytes of data.
64 bytes from 10.2.1.4: icmp_seq=1 ttl=63 time=5.87 ms
64 bytes from 10.2.1.4: icmp_seq=2 ttl=63 time=2.48 ms

Traceroute confirms traffic goes through the NVA:

gergo@spoke1-vm:~$ traceroute 10.2.1.4
traceroute to 10.2.1.4 (10.2.1.4), 30 hops max, 60 byte packets
 1  10.0.1.4 (10.0.1.4)  1.528 ms  1.503 ms  1.490 ms  # NVA IP
 2  10.2.1.4 (10.2.1.4)  2.736 ms *  2.706 ms           # Spoke-02 server

Final Thoughts

Azure Route Server is a powerful tool for simplifying routing and enforcing network policies in cloud environments. By leveraging BGP-based dynamic routing, it eliminates manual UDR management, making it ideal for large-scale enterprise hub-and-spoke architectures in Azure.

Have you used Azure Route Server in production? Share your thoughts or challenges in the comments!

The complete Terraform code for this lab is available at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.

Connecting Your Hybrid Cloud with GCP Connectivity Center and Router Appliance - with Terraform

Gergo Vadasz — Mon, 06 Apr 2026 20:28:01 +0000

In hybrid cloud environments, connecting on-premises networks to Google Cloud in a scalable and manageable way is a common challenge. Google Cloud's Network Connectivity Center (NCC) implements a hub-and-spoke model for streamlined network management.

In this post, I'll walk through deploying two VPCs — one serving as a network hub with a Router Appliance VM, another for testing connectivity with a standard VM instance.

What is GCP Network Connectivity Center?

Network Connectivity Center (NCC) is Google Cloud's centralized network connectivity management solution. It enables a hub-and-spoke topology, simplifying connections across VPCs, VPNs, interconnects, and SD-WAN gateways in hybrid and multi-cloud settings.

Key benefits:

Reduced complexity in peering and route configuration
Enhanced visibility into hybrid network topology
Scalable network expansion through spoke attachment

Architecture

The environment consists of:

A Connectivity Center hub
Internal VPC spoke with test VM
Router appliance VPC
Router appliance VM attached as spoke
Cloud Router for BGP route exchange

Step-by-Step Setup

1. Create the Internal VPC

Create an internal VPC with a 10.0.0.0/24 subnet and deploy a Linux VM in it.

2. Create the Router Appliance VPC

Create a router appliance VPC with a 10.1.0.0/24 subnet and deploy a Linux VM that will serve as the router appliance.

3. Create the Cloud Router

Create a GCP Cloud Router in the router appliance subnet with AS number 64512.

4. Create the NCC Hub and Spokes

Create an NCC Hub, then attach two spokes: one VPC spoke (internal VPC) and one Router Appliance spoke.

Configure the Router Appliance spoke with BGP using AS number 65001.

5. Configure the Router Appliance VM

SSH into the Router Appliance VM. Since I want to demonstrate a hybrid connection, we need to simulate routing towards a remote location. In real-life scenarios, this could be a remote data center, branch office, SD-WAN solution, or even another cloud environment.

Create a loopback interface with a 192.168.0.0/24 IP to simulate the remote network:

# Create loopback ip address
ip addr add 192.168.0.1/24 dev lo

# Add entry to the route table
ip route add 192.168.0.0/24 dev lo

Verify the configuration:

gergo@nva-instance:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 192.168.0.1/24 scope global lo

6. Install FRR and Configure BGP

# Install FRR
sudo apt install frr

# Enable BGP in FRR
sudo sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons

# Restart FRR to take effect
sudo systemctl restart frr

# Configure BGP
sudo vtysh -c 'conf t' \
-c 'route-map ACCEPT-ALL permit 10' \
-c 'exit' \
-c 'router bgp 65001' \
-c 'neighbor 10.1.0.4 remote-as 64512' \
-c 'neighbor 10.1.0.4 description "GCP Peer 1"' \
-c 'neighbor 10.1.0.4 ebgp-multihop' \
-c 'neighbor 10.1.0.4 disable-connected-check' \
-c 'neighbor 10.1.0.5 remote-as 64512' \
-c 'neighbor 10.1.0.5 description "GCP 2"' \
-c 'neighbor 10.1.0.5 ebgp-multihop' \
-c 'neighbor 10.1.0.5 disable-connected-check' \
-c 'address-family ipv4 unicast' \
-c 'network 192.168.0.0/24' \
-c 'neighbor 10.1.0.4 soft-reconfiguration inbound' \
-c 'neighbor 10.1.0.4 route-map ACCEPT-ALL in' \
-c 'neighbor 10.1.0.4 route-map ACCEPT-ALL out' \
-c 'neighbor 10.1.0.5 soft-reconfiguration inbound' \
-c 'neighbor 10.1.0.5 route-map ACCEPT-ALL in' \
-c 'neighbor 10.1.0.5 route-map ACCEPT-ALL out' \
-c 'end' \
-c 'write'

Verifying Route Exchange

After configuration, BGP neighborship with Cloud Router should be established:

nva-instance# show ip bgp summary

IPv4 Unicast Summary:
BGP router identifier 192.168.0.1, local AS number 65001 VRF default vrf-id 0
BGP table version 2
RIB entries 3, using 384 bytes of memory
Peers 2, using 47 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.1.0.4        4      64512       101       104        2    0    0 00:32:29            1        2 "GCP Cloud Router
10.1.0.5        4      64512       101       104        2    0    0 00:32:29            1        2 "GCP Cloud Router

The BGP table shows the internal VPC subnet learned from Cloud Router, and the 192.168.0.0/24 loopback advertised locally:

nva-instance# show ip bgp
BGP table version is 2, local router ID is 192.168.0.1, vrf id 0

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.0.0/24      10.1.0.1               100             0 64512 ?
 *=                   10.1.0.1               100             0 64512 ?
 *>  192.168.0.0/24   0.0.0.0                  0         32768 i

Route Tables in Google Cloud Console

The Router Appliance VPC routing table shows the NCC Hub advertising the internal VPC, and the Router Appliance advertising 192.168.0.0/24:

The Internal VPC routing table shows 192.168.0.0/24 being advertised with next hop as NCC Hub:

Connectivity Test

With firewall rules permitting traffic, connectivity testing succeeds:

gergo@internal-vm:~$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.823 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.336 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.268 ms

Conclusion

NCC is a powerful tool that can simplify networking setup and operation in Google Cloud. From here, you could expand the demo with additional VPCs, more Cloud Routers, or failover scenario testing.

The complete Terraform code provisions everything automatically — NCC hub, spokes, Router Appliance, Cloud Router, VMs, and even the BGP routing. No manual steps required in the Google Cloud Console.

Check out the full Terraform code and guide at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.

Hybrid DNS with GCP Network Connectivity Center and Enterprise IPAM

Gergo Vadasz — Sat, 04 Apr 2026 19:29:34 +0000

I recently worked through a hybrid DNS design for a Google Cloud environment with some interesting constraints that I think are worth writing up.

The setup involved implementing a company-wide on-premises DNS system built on enterprise IPAM platforms (Infoblox, EfficientIP, or BlueCat) with two critical requirements:

Security policies prohibit DNS queries originating from Google's public IP ranges
The IPAM must remain the authoritative source for all DNS records, including GCP-hosted zones

The solution involved deploying virtual machines within GCP to bridge these constraints.

How DNS Works in Google Cloud

By default, Compute Engine instances use the VPC-internal DNS resolver at 169.254.169.254, handled by Cloud DNS based on the VPC network configuration.

Cloud DNS Zone Types

Private zones: Cloud DNS hosts records directly and is authoritative
Forwarding zones: Cloud DNS forwards queries to target name servers; with private routing, source IPs originate from 35.199.192.0/19
Peering zones: Cloud DNS delegates resolution to another VPC network's DNS context via metadata-plane operations (no actual DNS packets exchanged between VPCs)

The 35.199.192.0/19 Source IP Challenge

Cloud DNS forwarding zones support standard and private routing modes:

Standard forwarding: Source IP depends on target (public IPs use Google ranges; RFC 1918 addresses use 35.199.192.0/19)
Private forwarding: Forces all queries through the VPC network using 35.199.192.0/19, regardless of target IP type

Critical characteristics of this range:

Google Cloud automatically installs a non-removable route for 35.199.192.0/19 in every VPC network. This route is not visible in route tables and cannot be modified or exchanged between VPCs.

Enterprise firewalls typically block this range as it appears to be from a public IP range.

Why This Solution Is Necessary

Problem 1: On-premises firewalls reject Cloud DNS forwarding queries arriving from 35.199.192.0/19

Problem 2: Organizations require IPAM platforms to remain the single authoritative source for all DNS records across hybrid environments

The Solution: Deploy an IPAM grid member (simulated as a BIND VM) within GCP that:

Is authoritative for GCP zones (e.g., gcp.example.com)
Forwards on-premises zone queries to on-prem DNS servers using its private IP
Receives all GCP workload DNS queries via Cloud DNS forwarding
Receives GCP zone queries from on-premises via conditional forwarding

Network Topology

NCC Hub-and-Spoke Setup

The design uses three VPC networks connected through Google Cloud's Network Connectivity Center:

Infra VPC Spoke:

Hosts the DNS VM (IPAM grid member)
Hosts the SD-WAN VM
Central VPC where DNS forwarding zones reside

App VPC Spoke:

Hosts application workloads
VMs query DNS through Cloud DNS, which peers to Infra VPC

SD-WAN Router Appliance Spoke:

The SD-WAN VM (physically in Infra VPC) registered as a router appliance in NCC
Runs FRR (Free Range Routing)
Peers BGP with NCC Cloud Router (ASN 64515 ↔ 64514)
Advertises on-premises subnet 192.168.1.0/24

The SD-WAN VM includes:

NIC0 in Infra VPC (for BGP peering with NCC)
NIC1 in On-Prem VPC (simulating WAN link to data center)
IP forwarding enabled for inter-network routing

NCC route exchange ensures all VPCs learn about each other's subnets, enabling the App VPC to reach on-premises resources via the SD-WAN VM.

Cloud DNS Peering and Forwarding Configuration

Cloud DNS includes four managed zones with no private authoritative zones:

Peering Zones (in App VPC):

Zone	DNS Name	From	To
gcp-dns-peering	gcp.example.com	App VPC	Infra VPC
onprem-dns-peering	on-prem.example.com	App VPC	Infra VPC

Forwarding Zones (in Infra VPC):

Zone	DNS Name	Target
gcp-dns-forwarding	gcp.example.com	DNS VM (10.0.1.10)
onprem-dns-forwarding	on-prem.example.com	DNS VM (10.0.1.10)

Both forwarding zones use forwarding_path = "private" to ensure VPC routing rather than internet routing.

Why Peering Instead of Cross-VPC Forwarding?

Cloud DNS forwarding cannot work across VPCs because of the 35.199.192.0/19 return path behavior.

When Cloud DNS uses a forwarding zone with private routing, queries originate from 35.199.192.0/19. Every VPC contains a special, non-removable route for this range pointing to that VPC's own Cloud DNS context. This route is not exchanged between VPCs through any mechanism (NCC, VPC peering, etc.).

If the App VPC forwards a query to the DNS VM in the Infra VPC:

The query arrives with a source IP from 35.199.192.0/19
The DNS VM responds to that source IP
The Infra VPC's special route for 35.199.192.0/19 points to its own Cloud DNS, not back to the App VPC
The response is silently dropped

DNS peering solves this entirely by evaluating queries in the target VPC's DNS context without sending packets between VPCs, eliminating cross-VPC return path issues.

Referenced Documentation:

Traffic Flows

Flow 1: GCP Workload Resolves a GCP Hostname

Query: app-server.gcp.example.com from App VM (10.0.2.10)

App VM (10.0.2.10)
  ↓ dig app-server.gcp.example.com
Cloud DNS (169.254.169.254) -- App VPC context
  ↓ Peering zone: gcp.example.com → Infra VPC (metadata-plane)
Cloud DNS -- Infra VPC context
  ↓ Forwarding zone: gcp.example.com → 10.0.1.10, Source: 35.199.192.0/19
DNS VM / IPAM (10.0.1.10)
  ↓ Authoritative zone: gcp.example.com
  ↓ app-server = 10.0.2.10
Response: 10.0.2.10
  ↓ Returns to 35.199.192.0/19 (Infra VPC route, correct context)
Cloud DNS returns answer to App VM

The query remains within GCP, with Cloud DNS peering then forwarding to the DNS VM.

Flow 2: GCP Workload Resolves an On-Premises Hostname

Query: app1.on-prem.example.com from App VM (10.0.2.10)

App VM (10.0.2.10)
  ↓ dig app1.on-prem.example.com
Cloud DNS (169.254.169.254) -- App VPC context
  ↓ Peering zone: on-prem.example.com → Infra VPC
Cloud DNS -- Infra VPC context
  ↓ Forwarding zone: on-prem.example.com → 10.0.1.10, Source: 35.199.192.0/19
DNS VM / IPAM (10.0.1.10)
  ↓ Forward zone: on-prem.example.com → 192.168.1.10
  ↓ Source IP: 10.0.1.10 (private IP, on-prem firewall allows)
  ↓ Path: via SD-WAN VM (NCC router appliance, BGP-learned route)
On-Prem DNS (192.168.1.10)
  ↓ Authoritative zone: on-prem.example.com
  ↓ app1 = 192.168.1.50
Response travels back the same path

The on-premises DNS server sees the query from 10.0.1.10, a private RFC1918 address, never from 35.199.192.0/19.

Flow 3: On-Premises Resolves a GCP Hostname

Query: app-server.gcp.example.com from on-premises client

On-Prem Client
  ↓ dig app-server.gcp.example.com
On-Prem DNS (192.168.1.10)
  ↓ Conditional forwarder: gcp.example.com → 10.0.1.10
  ↓ Path: via SD-WAN VM (static route in on-prem VPC)
DNS VM / IPAM (10.0.1.10)
  ↓ Authoritative zone: gcp.example.com
  ↓ app-server = 10.0.2.10
Response: 10.0.2.10
  ↓ Returns to on-prem DNS via SD-WAN VM
On-prem client receives answer

The DNS VM resolves this locally as it is authoritative for gcp.example.com.

Traffic Flow Summary

From	To	Zone	Path
App VM	GCP hostname	gcp.example.com	Cloud DNS peer → forward → DNS VM (authoritative)
App VM	On-prem hostname	on-prem.example.com	Cloud DNS peer → forward → DNS VM → on-prem DNS
On-prem	GCP hostname	gcp.example.com	On-prem DNS → DNS VM (authoritative)
On-prem	On-prem hostname	on-prem.example.com	On-prem DNS (authoritative, local)

Key Design Decisions

No Cloud DNS private zones: The IPAM remains the single authoritative source; Cloud DNS only peers and forwards
DNS peering is mandatory for cross-VPC resolution: The 35.199.192.0/19 return path constraint makes forwarding zones across VPCs non-functional
DNS VM uses private IP for on-premises queries: Queries originate from 10.0.1.10 rather than 35.199.192.0/19, allowing enterprise firewalls to accept them into trusted zones
NCC provides hybrid routing: The SD-WAN VM advertises on-premises routes via BGP to NCC, which propagates them to all spoke VPCs

Try It Yourself

The complete Terraform code for this setup is available on my blog — it provisions the entire environment including the NCC hub, DNS VM with BIND, SD-WAN VM with FRR, and all Cloud DNS zones. A single terraform apply gets you a working lab.

Check it out at gergovadasz.hu.

Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.