Google Cloud NAT Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking

1. Introduction

Cloud NAT is a managed Network Address Translation (NAT) service in Google Cloud that gives private resources outbound access to the public internet (and other external destinations) without assigning external IP addresses to those resources.

In simple terms: your VMs, GKE nodes, or other workloads can live on private IPs only, but still download packages, call external APIs, fetch container images, or send logs to SaaS endpoints—while remaining unreachable from the internet by default.

Technically, Cloud NAT performs source NAT (SNAT) for egress traffic from selected subnets and IP ranges in a VPC network. It’s configured on a Cloud Router in a specific region, uses one or more Google-managed external IP addresses, and maintains NAT mappings so return traffic can reach the originating private workload. Cloud NAT is not a general-purpose firewall and it does not provide inbound connectivity—its scope is outbound translation and related observability/controls.

The main problem it solves is very common in cloud Networking: private-by-default workloads still need outbound internet access. Without Cloud NAT, teams often add external IPs to instances (increasing exposure and operational burden) or build and maintain NAT instances (increasing toil and reliability risk).

Service status note: Cloud NAT is an active, current Google Cloud service name and is part of the VPC Networking portfolio. Always verify the latest behavior and limits in official docs because quotas and UI labels can change.

2. What is Cloud NAT?

Official purpose

Cloud NAT provides managed outbound NAT for resources that use private IP addresses in a Google Cloud VPC network. It enables egress connectivity while avoiding per-instance external IP addresses.

Official documentation (overview): https://cloud.google.com/nat/docs/overview

Core capabilities

Cloud NAT typically provides:

Outbound internet access for private resources (no external IPs needed)
Managed, regional NAT service (no NAT VM maintenance)
Configurable egress IP addresses (auto-allocated or user-reserved static external IPs)
Configurable NAT scope (specific subnetworks and, where applicable, primary/secondary ranges)
NAT logging (for visibility and troubleshooting)
Scales egress translation without manual instance scaling (within service limits/quotas)

Major components

Cloud NAT is usually described using these building blocks:

VPC network: Where your private workloads live.
Subnetworks (regional): The IP ranges where Cloud NAT will apply.
Cloud Router (regional): The control plane object where Cloud NAT configuration is attached. Cloud Router is also used for dynamic routing (BGP) in hybrid designs, but Cloud NAT can be used even if you are not using BGP.
Cloud NAT gateway (regional): The NAT configuration on the router, including egress IPs, subnet selection, logging, and port allocation behavior.
External IP addresses: Either auto-allocated ephemeral addresses or static reserved external IPs you provide.

Service type

Managed Networking service (not a VM appliance)
Provides SNAT for egress
Operates at the VPC edge for selected regional resources (details depend on the exact workload type and routing path—verify in official docs for your specific use case such as GKE, serverless, or hybrid)

Scope: regional/global/zonal?

Cloud NAT is regional: – You create/configure it in a specific region. – It applies to regional subnetworks selected in that region. – Multi-region environments typically deploy Cloud NAT per region.

Scope boundaries commonly include: – Project-scoped resources (the Cloud Router and NAT config exist in a project) – Regional attachment (router/NAT are regional) – Network/subnet selection (you must select which subnets and ranges are NATed)

How it fits into the Google Cloud ecosystem

Cloud NAT commonly sits alongside:

Compute Engine: Private VMs needing outbound access.
GKE: Private clusters / private nodes needing to pull images, reach package repos, or call external services.
Hybrid connectivity: Cloud VPN / Cloud Interconnect where on-prem or other networks route through the VPC and need internet egress (only when routing and security are designed appropriately—verify your routing model).
Security services:
Cloud Firewall rules (control egress/ingress at VPC level)
Cloud Armor (for inbound protection via load balancers; not a NAT feature)
VPC Service Controls (data exfiltration controls for Google APIs; not replaced by NAT)
Operations:
Cloud Logging (NAT logging)
Cloud Monitoring (metrics for routers/NAT—verify metric names)

3. Why use Cloud NAT?

Business reasons

Reduce risk of exposure: Avoid assigning external IPs to every instance/node.
Simplify governance: Centralize outbound internet access through managed NAT with consistent policy and logging.
Improve auditability: A smaller set of egress IPs is easier to track and allowlist with vendors/partners.
Lower operational overhead: No NAT instance patching, scaling, or failover runbooks.

Technical reasons

Private workloads still need egress: OS updates, dependency downloads, external API calls, time sync, telemetry exporters, etc.
Deterministic egress IPs (when using reserved static IPs): Helpful for third-party allowlists.
Supports modern private architectures: Private GKE nodes, private VMs, and segmented subnets.

Operational reasons

Managed scaling and availability: You don’t design a NAT VM autoscaling group or worry about single points of failure in a DIY NAT.
Central troubleshooting point: NAT logging and router-level visibility can accelerate egress investigations.
Less configuration drift: NAT behavior is a managed service rather than mutable OS-level iptables.

Security/compliance reasons

No inbound reachability by default: Cloud NAT does not create inbound paths to private instances.
Centralized egress control: Combine Cloud NAT with:
egress firewall rules
explicit proxy architectures
DNS policies
organization policies (where applicable)
Supports IP-based allowlisting for compliance-oriented vendors (with static NAT IPs).

Scalability/performance reasons

Avoid bottlenecks and tuning of NAT VM throughput/conntrack tables.
Use managed NAT behavior rather than per-host rules.

When teams should choose it

Choose Cloud NAT when you need: – Outbound internet access for resources without external IPs – A managed NAT solution with optional static egress IPs – Per-region NAT for segmented VPC subnets – Reduced attack surface compared to external IPs on every VM

When teams should not choose it

Cloud NAT is not a fit when you need: – Inbound connectivity to private workloads (use load balancing, IAP, VPN, PSC, etc.) – Application-layer controls (URL filtering, TLS inspection, DLP). Consider proxy-based egress (explicit proxy, secure web gateway, third-party appliances) if you need L7 policy. – A single global NAT across all regions (Cloud NAT is regional; you’ll deploy per region). – IPv6-only egress translation requirements (verify current IPv6 capabilities in official docs; Cloud NAT is primarily used for IPv4 egress scenarios).

4. Where is Cloud NAT used?

Industries

Cloud NAT shows up anywhere private cloud Networking is required:

Financial services and fintech (restrict inbound exposure, controlled egress)
Healthcare (segmented networks and audit trails)
Retail/e-commerce (private app tiers with outbound dependencies)
SaaS providers (standardized egress IPs for third-party integrations)
Media/gaming (private compute fleets pulling external content/tools)
Public sector (private-by-default policies)

Team types

Platform engineering teams building shared VPC patterns
SRE and operations teams managing egress reliability
Security teams implementing least exposure
DevOps teams running CI/CD runners and private build agents
Network engineers managing hybrid routing and segmented environments

Workloads

Compute Engine VMs in private subnets
Private GKE nodes (and, depending on cluster networking mode, related IP ranges—verify specifics for your GKE configuration)
Batch processing workers that download dependencies
Private bastionless operations using IAP + NAT for updates
Hybrid workloads where on-prem hosts egress through Google Cloud (requires careful routing and security design)

Architectures

Multi-tier apps: private app tier + private data tier; NAT for outbound only
Shared VPC hub-and-spoke: centralized egress per region
Private clusters: GKE private nodes with controlled egress
Regulated environments: explicit egress IP allowlists

Production vs dev/test usage

Dev/test: Commonly used to avoid giving external IPs to dev instances and to simplify security reviews.
Production: Used for standardized egress IPs, controlled outbound access, and reduced operational risk versus NAT instances.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Cloud NAT is frequently the right tool.

1) Private VM package updates

Problem: Private VMs (no external IPs) can’t run apt-get update/yum update.
Why Cloud NAT fits: Provides outbound SNAT so the VMs can reach public repositories.
Example: A private Debian fleet in 10.10.0.0/24 needs security updates nightly.

2) Private GKE nodes pulling container images

Problem: Private nodes can’t pull images from external registries or public endpoints.
Why Cloud NAT fits: Enables outbound connections without exposing nodes.
Example: A private GKE cluster pulls images from Docker Hub or a partner registry.

3) Allowlisted egress IPs for third-party SaaS

Problem: A vendor only accepts traffic from known public IPs.
Why Cloud NAT fits: Use static reserved external IPs as NAT egress addresses.
Example: Your payment processor requires allowlisting; you provide 2 NAT IPs per region.

4) Outbound access for private CI/CD runners

Problem: Self-hosted runners in private subnets must download dependencies and publish artifacts.
Why Cloud NAT fits: Keeps runners private while enabling outbound downloads.
Example: GitHub Actions runners in Compute Engine fetch packages and call GitHub APIs.

5) Private data processing workers calling external APIs

Problem: Workers need to call external APIs but must not be internet-addressable.
Why Cloud NAT fits: Supports outbound calls; no inbound exposure.
Example: Data enrichment jobs call geocoding and fraud scoring APIs.

6) Centralized outbound egress in a Shared VPC

Problem: Multiple service projects need controlled internet egress.
Why Cloud NAT fits: Shared VPC + regional NAT provides consistent patterns.
Example: One host project provides NAT per region for many service projects (verify Shared VPC permissions and design).

7) Hybrid on-prem egress through Google Cloud

Problem: On-prem network wants to use Google Cloud as an egress point (for specific routes).
Why Cloud NAT fits: When traffic is routed into a VPC subnet and out to the internet, NAT can translate the source.
Example: A branch office routes a subset of traffic via Cloud VPN to Google Cloud for consistent egress IPs. (This requires careful routing, firewalling, and capacity planning—verify in official docs.)

8) Private microservices needing outbound telemetry

Problem: Services must send metrics/logs/traces to external endpoints.
Why Cloud NAT fits: Enables outbound to SaaS monitoring endpoints without external IPs.
Example: Prometheus exporters push to a managed observability platform with IP allowlisting.

9) Bastionless administration (IAP + NAT)

Problem: You want SSH access without a bastion VM, but instances still need updates.
Why Cloud NAT fits: Use IAP TCP forwarding for admin access; Cloud NAT for outbound updates.
Example: SREs SSH via IAP into private VMs; NAT enables patching and tool installs.

10) Egress IP consistency for partner APIs across environments

Problem: Partners want separate allowlists for dev/stage/prod.
Why Cloud NAT fits: Assign different static IP sets per environment/project/region.
Example: Dev NAT IPs differ from prod NAT IPs to reduce blast radius.

11) Migration away from NAT instances

Problem: NAT instances are fragile and require scaling, patching, and failover.
Why Cloud NAT fits: Managed service reduces operational load and failure modes.
Example: Replace an iptables-based NAT VM pair with Cloud NAT per region.

12) Controlled egress for private subnets with firewall enforcement

Problem: You want outbound access but only to approved destinations/ports.
Why Cloud NAT fits: Pair NAT with egress firewall rules and/or proxy controls.
Example: Allow only TCP 443 outbound; deny everything else; NAT provides translation.

6. Core Features

Feature availability and exact configuration options can change. Verify the latest feature set in official docs: https://cloud.google.com/nat/docs/overview

6.1 Managed outbound NAT (SNAT) for private resources

What it does: Translates private source IPs to one or more external IPs for outbound connections.
Why it matters: Resources remain private (no external IP), reducing exposure.
Practical benefit: Private subnets can still reach the internet for updates and APIs.
Caveats: NAT does not create inbound reachability; unsolicited inbound connections are not possible via NAT alone.

6.2 Regional Cloud NAT gateways (configured on Cloud Router)

What it does: NAT configuration is attached to a regional Cloud Router.
Why it matters: NAT is managed per region and aligns with regional subnetworks.
Practical benefit: Clear blast radius; predictable routing and operations per region.
Caveats: Multi-region deployments require NAT per region.

6.3 NAT IP address options (auto vs manual)

What it does: Lets you:
auto-allocate external IPs, or
provide reserved static external IPs
Why it matters: Static egress IPs are often required for allowlisting.
Practical benefit: Stable integration with external partners and SaaS.
Caveats: Reserved external IPs have their own pricing and lifecycle; manage inventory carefully.

6.4 Subnetwork and IP range selection

What it does: Choose which subnetworks are NATed, and (depending on design) which ranges are included.
Why it matters: Avoid “accidental internet” for sensitive subnets.
Practical benefit: Principle of least privilege at the network layer.
Caveats: Ensure you include the correct ranges for your workload (for example, in some Kubernetes networking setups, secondary ranges may matter—verify for your GKE mode).

6.5 Port allocation and scale behavior

What it does: NAT must allocate source ports per VM/endpoint to multiplex many private endpoints over fewer external IPs.
Why it matters: Port exhaustion is a real failure mode for high-connection workloads.
Practical benefit: Proper sizing (IPs/ports) improves reliability.
Caveats: Understand your connection patterns (many short-lived connections vs few long-lived). Use monitoring and consider more NAT IPs when needed.

6.6 NAT logging

What it does: Exports logs about NAT translations and/or errors to Cloud Logging (configurable).
Why it matters: Egress visibility helps incident response and troubleshooting.
Practical benefit: Identify which internal IP is talking to which external destination (subject to log fields and sampling).
Caveats: Logging can increase cost (log ingestion/storage) and may collect sensitive metadata. Apply retention and access controls.

6.7 Works with hybrid routes (when traffic traverses the VPC)

What it does: Can NAT traffic that enters the VPC (for example via Cloud VPN/Interconnect) and then egresses to the internet—if routing/firewalling allows.
Why it matters: Centralized egress can be part of a hybrid architecture.
Practical benefit: Consistent egress IPs and centralized controls.
Caveats: This is an advanced design; validate routing symmetry, firewall rules, and organizational security requirements. Verify in official docs for supported patterns.

6.8 High availability (managed service)

What it does: Google manages availability for the NAT service in-region.
Why it matters: NAT instances are a common single point of failure; managed NAT reduces that risk.
Practical benefit: Fewer operational runbooks and less toil.
Caveats: You still need to design for regional failures if your business requires multi-region resilience.

7. Architecture and How It Works

High-level architecture

Cloud NAT sits between your private resources and external destinations:

Your private VM (no external IP) sends traffic to an external IP (e.g., deb.debian.org).
Routing uses the default internet route (0.0.0.0/0) in the VPC.
At egress, Cloud NAT translates the source private IP:port into a NAT external IP:port.
Return traffic matches the NAT mapping and is delivered back to the private VM.

Cloud NAT is configured on a Cloud Router (regional). Cloud Router is the configuration/control plane anchor; Cloud NAT uses it to define which subnets/ranges are NATed and how external IPs/ports are allocated.

Request/data/control flow (conceptual)

Control plane
You create a Cloud Router in region X.
You create a Cloud NAT configuration attached to that router, selecting subnetworks and external IP allocation mode.
Data plane
VM initiates outbound connection → packets traverse VPC routing → NAT translation occurs at the managed edge → packets go to the internet.
Return traffic comes back to NAT external IP:port → NAT mapping → private VM IP:port.

Integrations with related services

Common integrations include:

Compute Engine: Private VMs for outbound access.
GKE: Private nodes; NAT for pulling images and calling external endpoints.
Cloud VPN / Cloud Interconnect: Hybrid routing scenarios.
Cloud Logging: NAT logs.
Cloud Monitoring: Router/NAT metrics and alerting.
Cloud Firewall rules: Control egress destinations/ports; NAT does not replace firewalling.
IAP: Administrative access to private VMs without bastions (complementary pattern).

Dependency services

Typically required: – VPC network + subnetworks – Cloud Router (regional) – Cloud NAT configuration (on the router)

Often used together: – Firewall rules for egress and IAP SSH – Cloud DNS (optional) for name resolution control

Security/authentication model

Configuration changes are controlled by IAM.
Logs are in Cloud Logging and accessible via IAM.
NAT does not authenticate traffic; it only translates addresses/ports. Security controls are implemented via:
egress firewall rules
proxy architectures
identity-aware access at the application layer (where possible)
workload identity/service accounts for Google APIs (NAT is not an identity mechanism)

Networking model considerations

Cloud NAT provides outbound translation only.
It supports many-to-few mapping (many private endpoints → few external IPs), using port allocation.
For deterministic egress, use reserved static IPs.
For Google APIs access, consider Private Google Access where applicable; Cloud NAT is for internet egress, not a replacement for private access to Google APIs. (There are advanced patterns that combine these—verify current docs for your use case.)

Monitoring/logging/governance considerations

Enable NAT logging selectively (errors-only vs full translation logging options depend on current product capabilities; verify in docs).
Monitor for:
port allocation pressure / port exhaustion
dropped connections (if exposed in metrics/logs)
unusual egress patterns (security signal)
Apply consistent naming and labels to routers/NAT gateways for cost allocation and operations.

Simple architecture diagram (Mermaid)

flowchart LR
  VM[Private VM\n(no external IP)] -->|egress traffic| VPC[VPC Subnet]
  VPC --> NAT[Cloud NAT\n(regional)]
  NAT --> NET[Internet]
  NET --> NAT --> VPC --> VM

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Region["Region: us-central1 (example)"]
    subgraph VPC["VPC Network"]
      subgraph SubnetA["Private Subnet A"]
        GKE[GKE private nodes / VMs\n(no external IPs)]
      end

      FW[Egress Firewall Rules\n(allowlist 443, etc.)]
      DNS[Cloud DNS (optional)\npolicy/control]
      Router[Cloud Router (regional)]
      NATgw[Cloud NAT (regional)\nstatic egress IPs + logging]
    end
  end

  GKE --> FW --> Router --> NATgw --> Internet[(Internet / External APIs)]
  GKE --> DNS
  Internet --> NATgw --> Router --> GKE

  subgraph Ops["Operations & Security"]
    Logging[Cloud Logging\nNAT logs]
    Monitoring[Cloud Monitoring\nmetrics & alerts]
    SIEM[SIEM/SOC tooling\n(optional)]
  end

  NATgw --> Logging --> SIEM
  NATgw --> Monitoring

8. Prerequisites

Account/project requirements

A Google Cloud project with billing enabled
Permissions to create and modify VPC Networking resources

IAM roles (typical)

Exact least-privilege roles depend on your org policy and whether you use Shared VPC. Common roles include:

For creating networks/subnets/firewalls:
roles/compute.networkAdmin (broad)
For creating routers and NAT:
roles/compute.networkAdmin typically covers it
For VM creation:
roles/compute.instanceAdmin.v1
For IAP SSH:
roles/iap.tunnelResourceAccessor
For viewing logs:
roles/logging.viewer

Always prefer least privilege: – Split duties (network admin vs VM admin vs security/logging viewer). – In Shared VPC, ensure host project vs service project permissions are correctly assigned. Verify in official Shared VPC docs.

Billing requirements

Cloud NAT is billable (gateway time and data processing, plus related costs like external IPs and egress).
Cloud Logging ingestion and retention can add costs when NAT logging is enabled.

Tools needed

Google Cloud CLI (gcloud) installed and authenticated:
Install: https://cloud.google.com/sdk/docs/install
Optional but recommended:
curl locally
SSH client (though in this lab we’ll use IAP tunneling)

Region availability

Cloud NAT is regional. Choose a region where:
you can create Compute Engine instances
Cloud NAT is available (generally widely available; verify if you use restricted regions)

Quotas/limits

Common quota areas (verify exact values in your project/region): – Number of Cloud Routers per region – Number of NAT configurations/gateways per router/region – External IP address quotas – NAT port and endpoint scaling limits

Check quotas in: – Google Cloud Console → IAM & Admin → Quotas – Or relevant Compute Engine API quota pages (verify current UI path)

Prerequisite services/APIs

Enable APIs (names can change; verify in console): – Compute Engine API

Cloud NAT is part of VPC networking and typically managed through Compute Engine networking surfaces.

9. Pricing / Cost

Official pricing reference: – VPC network pricing (includes Cloud NAT): https://cloud.google.com/vpc/network-pricing – Pricing calculator: https://cloud.google.com/products/calculator

Pricing varies by region and is subject to change. Do not rely on blog posts for exact rates—always confirm in the official pricing page and calculator.

Pricing dimensions (how you’re billed)

Cloud NAT costs typically include:

Cloud NAT gateway time (per NAT gateway per hour) – You pay for having Cloud NAT configured/active in a region.
Data processing (per GiB processed by Cloud NAT) – Charged based on the volume of traffic processed through NAT.
External IP addresses – If you use reserved static external IPs, they have their own pricing. – Auto-allocated NAT IPs may still be billable depending on how they are provisioned/used—verify current rules on the External IP pricing page and VPC pricing.
Network egress (internet) – Internet egress from Google Cloud is billed separately under network egress pricing. – Cloud NAT’s “data processing” is distinct from general egress charges.
Logging – If NAT logging is enabled, Cloud Logging ingestion and retention can add noticeable cost at scale.

Free tier

Cloud NAT itself is not generally considered a “free tier” service in the way some serverless products are.
You may still be within always-free usage for some other components (like small VM usage in eligible regions), but Cloud NAT pricing is separate. Verify current free tier details.

Key cost drivers

Total egress traffic volume (GiB) through NAT
Number of NAT gateways (regions and environments)
Number of NAT external IPs (static allowlist requirements often increase this)
Logging volume when NAT logging is enabled
Connection patterns (port pressure can force additional IPs in some designs)

Hidden/indirect costs to plan for

Cloud Logging: NAT logs can be high-volume in busy environments.
Operational overhead: While NAT is managed, troubleshooting often involves logs and metrics—ensure you budget for observability tools and retention.
Egress to internet: Often the largest cost driver; NAT does not reduce egress charges.

Network/data transfer implications

Cloud NAT is about address translation; it does not eliminate:
internet egress charges
cross-region egress charges
inter-zone or inter-region traffic charges (if your design causes them)

Design tip: – Keep workloads and their NAT in the same region to avoid unintended cross-region routing costs.

How to optimize cost (practical)

Use Cloud NAT only in regions where you need it.
Start with auto-allocated NAT IPs unless you have an allowlist requirement.
If you need static IPs, allocate only what you need and monitor port/connection pressure before adding more.
Enable NAT logging in a scoped way:
consider “errors only” if available, or use sampling/filters (verify current options)
apply log sinks and retention controls
Reduce internet egress where possible:
use caching proxies for package repositories (if appropriate)
prefer private access patterns to Google APIs when suitable (e.g., Private Google Access), reducing internet traversal (verify architecture fit)

Example: low-cost starter estimate (how to think about it)

A small lab environment in one region might include: – 1 Cloud NAT gateway active for a few hours/days – Low outbound traffic (a few GiB from OS updates) – Minimal/no NAT logging

Use the pricing calculator to model: – NAT gateway hours – NAT data processed (GiB) – Internet egress (GiB) – Any static IP charges

Because rates vary by region and change over time, use the calculator rather than hard-coded numbers.

Example: production cost considerations

For production, expect to evaluate: – NAT gateway in each active region (prod/stage/dev separation) – Static NAT IPs (often 2+ for availability and capacity planning) – High outbound data volume (telemetry, downloads, third-party calls) – Logging volume if enabled (possibly large) – Egress optimization strategies and vendor allowlisting processes

10. Step-by-Step Hands-On Tutorial

This lab builds a minimal but realistic private VM that can reach the internet only after you configure Cloud NAT. You’ll access the VM securely using IAP tunneling (no external IP and no bastion).

Objective

Create a VPC and private subnet.
Create a VM without an external IP.
Confirm the VM cannot reach the internet initially.
Create a Cloud Router and Cloud NAT.
Confirm the VM can reach the internet after NAT is enabled.
Clean up all resources.

Lab Overview

You will create these resources in one region (example: us-central1):

VPC: nat-lab-vpc
Subnet: nat-lab-subnet (10.10.0.0/24)
VM: nat-lab-vm (no external IP)
Cloud Router: nat-lab-router
Cloud NAT: nat-lab-nat
Firewall rule for IAP SSH: allow TCP/22 from IAP range to the VM

Estimated time: 20–40 minutes.

Cost notes: – Compute Engine VM costs, Cloud NAT costs, and any logging costs apply. – Use a small machine type and delete everything after the lab.

Step 1: Set your project and region

Choose a project with billing enabled and set variables:

export PROJECT_ID="YOUR_PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"
export NETWORK="nat-lab-vpc"
export SUBNET="nat-lab-subnet"
export SUBNET_RANGE="10.10.0.0/24"
export ROUTER="nat-lab-router"
export NAT="nat-lab-nat"
export VM="nat-lab-vm"

gcloud config set project "$PROJECT_ID"
gcloud config set compute/region "$REGION"
gcloud config set compute/zone "$ZONE"

Expected outcome: – gcloud is pointed at the correct project/region/zone.

Verification:

gcloud config list

Step 2: Enable the required API(s)

gcloud services enable compute.googleapis.com

Expected outcome: – Compute Engine API enabled.

Verification:

gcloud services list --enabled --filter="name:compute.googleapis.com"

Step 3: Create a VPC network and a private subnet

Create a custom-mode VPC and subnet:

gcloud compute networks create "$NETWORK" --subnet-mode=custom

gcloud compute networks subnets create "$SUBNET" \
  --network="$NETWORK" \
  --region="$REGION" \
  --range="$SUBNET_RANGE"

Expected outcome: – A VPC and subnet exist in your chosen region.

Verification:

gcloud compute networks describe "$NETWORK"
gcloud compute networks subnets describe "$SUBNET" --region "$REGION"

Step 4: Create a VM with NO external IP

Create a small Debian VM without an external IP:

gcloud compute instances create "$VM" \
  --network="$NETWORK" \
  --subnet="$SUBNET" \
  --zone="$ZONE" \
  --machine-type="e2-micro" \
  --image-family="debian-12" \
  --image-project="debian-cloud" \
  --no-address

Expected outcome: – VM exists with only an internal IP. – No external IP is attached.

Verification:

gcloud compute instances describe "$VM" --zone "$ZONE" \
  --format="get(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs)"

You should see: – an internal IP (like 10.10.0.x) – no accessConfigs / no natIP

Step 5: Allow IAP SSH access to the VM (no external IP)

To SSH without a public IP, use IAP TCP forwarding. You must allow TCP/22 from the IAP TCP range:

gcloud compute firewall-rules create nat-lab-allow-iap-ssh \
  --network="$NETWORK" \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges="35.235.240.0/20" \
  --target-tags="iap-ssh"

Apply the network tag to the VM:

gcloud compute instances add-tags "$VM" \
  --zone="$ZONE" \
  --tags="iap-ssh"

Expected outcome: – Firewall rule exists. – VM is tagged to match the rule.

Verification:

gcloud compute firewall-rules describe nat-lab-allow-iap-ssh
gcloud compute instances describe "$VM" --zone "$ZONE" --format="get(tags.items)"

Step 6: Try to reach the internet BEFORE Cloud NAT (should fail)

SSH via IAP:

gcloud compute ssh "$VM" --zone "$ZONE" --tunnel-through-iap

Inside the VM, try:

curl -I https://example.com

Expected outcome: – This typically fails (timeout / could not resolve / connection error), because the VM has no external IP and there is no NAT configured yet.

Exit SSH:

exit

Note: DNS resolution behavior depends on VPC/DNS settings, but the key is that outbound connectivity should not succeed without NAT (or another egress method).

Step 7: Create a Cloud Router (regional)

gcloud compute routers create "$ROUTER" \
  --network="$NETWORK" \
  --region="$REGION"

Expected outcome: – A Cloud Router exists in the region.

Verification:

gcloud compute routers describe "$ROUTER" --region "$REGION"

Step 8: Create Cloud NAT and attach it to the router

Create NAT with auto-allocated external IPs and apply it to the subnet:

gcloud compute routers nats create "$NAT" \
  --router="$ROUTER" \
  --region="$REGION" \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips

Expected outcome: – Cloud NAT is configured for all subnet IP ranges in that region/router scope.

Verification:

gcloud compute routers nats describe "$NAT" \
  --router="$ROUTER" \
  --region="$REGION"

Step 9: Retry outbound access AFTER Cloud NAT (should succeed)

SSH again via IAP:

gcloud compute ssh "$VM" --zone "$ZONE" --tunnel-through-iap

Inside the VM:

curl -I https://example.com

Expected outcome: – You receive HTTP response headers (e.g., HTTP/2 200 or HTTP/1.1 200 OK).

Optional additional verification inside VM:

sudo apt-get update

Expected outcome: – Package index updates succeed.

Exit:

exit

Step 10 (Optional): Enable NAT logging (use carefully)

NAT logging helps troubleshooting but can add cost. To enable logging, use the current Cloud NAT logging flags supported by gcloud. Because logging options can evolve, verify in official docs and gcloud help:

gcloud compute routers nats update "$NAT" \
  --router="$ROUTER" \
  --region="$REGION" \
  --enable-logging

If you need specific log filters (errors only vs translations), check:

gcloud compute routers nats update --help

Expected outcome: – Logging enabled (if supported by current CLI version).

Verification: – In Cloud Console → Logging → Logs Explorer – Query for NAT/router logs (exact log name can change; search for “NAT” and the router name).

Validation

You have validated Cloud NAT when:

The VM has no external IP.
Before NAT, outbound curl fails.
After NAT, outbound curl succeeds.
(Optional) apt-get update works.

Quick VM external IP check:

gcloud compute instances describe "$VM" --zone "$ZONE" \
  --format="get(networkInterfaces[0].accessConfigs)"

Should be empty.

Troubleshooting

Common issues and realistic fixes:

SSH via IAP fails – Ensure you have the role roles/iap.tunnelResourceAccessor. – Confirm firewall rule allows TCP/22 from 35.235.240.0/20. – Confirm VM has the iap-ssh network tag. – Verify your organization policy doesn’t block IAP or SSH.
Outbound still fails after NAT – Confirm NAT is in the same region as the subnet. – Confirm NAT is configured to cover your subnet (--nat-all-subnet-ip-ranges or explicit subnet selection). – Confirm there is a default route to the internet gateway (default VPC route usually exists unless removed). – Check egress firewall rules: you may have a deny rule blocking outbound (common in hardened environments).
DNS resolves but connections time out – Often indicates routing/NAT/firewall issues. – Verify egress firewall rules allow TCP 443 (or the port you’re testing).
High-connection workloads fail intermittently – Possible port exhaustion or NAT scaling pressure. – Consider adding NAT external IPs and reviewing connection reuse patterns. – Use Cloud Monitoring and NAT logs to investigate (verify available metrics/log fields in docs).

Cleanup

Delete resources to stop billing:

gcloud compute instances delete "$VM" --zone "$ZONE" --quiet

gcloud compute routers nats delete "$NAT" \
  --router="$ROUTER" \
  --region="$REGION" --quiet

gcloud compute routers delete "$ROUTER" --region="$REGION" --quiet

gcloud compute firewall-rules delete nat-lab-allow-iap-ssh --quiet

gcloud compute networks subnets delete "$SUBNET" --region="$REGION" --quiet
gcloud compute networks delete "$NETWORK" --quiet

Expected outcome: – All lab resources removed.

11. Best Practices

Architecture best practices

Deploy Cloud NAT per region where private workloads need egress.
Use separate NAT gateways per environment (dev/stage/prod) to reduce blast radius and simplify allowlisting.
For Shared VPC, centralize Networking in the host project and standardize NAT patterns per region (verify org operating model).
For sensitive workloads, pair Cloud NAT with:
tight egress firewall rules
DNS controls (where appropriate)
proxy-based egress for L7 policy needs

IAM/security best practices

Apply least privilege:
separate roles for NAT/router admin vs VM admin vs log viewer
Use change control:
infrastructure as code (Terraform) for routers/NAT and firewall policies
peer review for changes affecting egress

Cost best practices

Start with auto-allocated NAT IPs unless static allowlisting is required.
Right-size NAT logging:
enable only when needed or scope to errors-only if supported
define log retention and sinks
Monitor internet egress and eliminate unnecessary downloads (caching, artifact registries, dependency pinning).

Performance best practices

Understand connection patterns:
high fan-out microservices can open many short-lived connections and stress port allocation
Use connection reuse and keep-alives at the app layer when feasible.
If you need predictable egress IPs and scale, plan a pool of NAT external IPs.

Reliability best practices

Treat NAT as a regional dependency:
for multi-region DR, deploy NAT in each region where workloads fail over
Keep workloads in-region with their NAT to avoid cross-region routing surprises.

Operations best practices

Enable and use observability:
NAT logging (with cost controls)
Monitoring dashboards and alerts (verify metric availability)
Standardize naming:
nat-${env}-${region} and router-${env}-${region}
Document egress IP ownership:
who manages allowlisting requests
how IP changes are handled
Regularly review:
NAT scope (which subnets are NATed)
firewall rules (egress restrictions)
external IP inventory

Governance/tagging/naming best practices

Use labels/tags consistently:
env, owner, cost-center, data-classification
Keep “break glass” procedures:
temporarily enable logging or expand NAT IPs during incidents, then roll back.

12. Security Considerations

Identity and access model

Cloud NAT configuration is managed via IAM permissions on Compute Engine Networking resources.
Restrict who can:
create/update routers
create/update NAT configurations
allocate and attach external IPs
modify firewall rules and routes

Recommended controls: – Use least privilege roles. – Use separate admin groups for Networking changes and application changes. – Use audit logs (Cloud Audit Logs) to monitor configuration changes.

Encryption

Cloud NAT does not terminate TLS; it translates IP/port.
Payload encryption is handled end-to-end by your applications (TLS) or VPN tunnels.
For sensitive egress, enforce TLS at the application layer and restrict plaintext protocols at firewall/proxy.

Network exposure

Cloud NAT does not expose your instances to inbound connections from the internet.
However, Cloud NAT does enable outbound connectivity, so you must still prevent data exfiltration by:
restricting egress destinations/ports
using DNS controls
using proxy/security gateways where needed
adopting workload identity and API-level controls for Google services

Secrets handling

Don’t treat NAT as a security boundary for secrets.
Use Secret Manager (or your approved secret system) and avoid embedding secrets in images or startup scripts.
Control outbound to secret exfil endpoints using egress policies.

Audit/logging

Use Cloud Audit Logs for changes to routers/NAT/firewalls.
Use NAT logs (when enabled) for egress investigations.
Restrict log access and set appropriate retention.

Compliance considerations

Many compliance regimes require:
reduced inbound exposure (helped by private IP-only designs)
egress monitoring and allowlisting (supported via NAT logging + static IPs)
Ensure log data handling meets retention and privacy requirements; NAT logs can include internal IPs and destination metadata.

Common security mistakes

NATing “everything” by default without egress firewall restrictions.
Enabling full NAT logging at high volume without access controls or cost controls.
Relying on NAT as the only control for egress security (it is not).
Forgetting to document and manage static NAT IPs used in allowlists.

Secure deployment recommendations

Start with:
private subnets
Cloud NAT for required outbound
strict egress firewall rules (least privilege)
optional proxy for L7 filtering
Use static NAT IPs only when required; manage them like critical assets.

13. Limitations and Gotchas

Limits and behaviors evolve. Verify current constraints in official Cloud NAT documentation and your project quotas.

Common limitations

Outbound-only: No inbound connectivity is provided by Cloud NAT.
Regional: Must deploy per region; cannot use one NAT for all regions.
Port exhaustion risk: High-connection workloads can exhaust available NAT ports on a given external IP.
Not an L7 security product: No URL filtering, TLS inspection, user-based policy, or malware scanning.

Quotas and scaling gotchas

External IP quotas can block scaling if you need more NAT IPs.
Router/NAT quotas can limit how many independent gateways you deploy.
Logging volume can grow quickly.

Regional constraints

Your Cloud NAT must be in the same region as the subnetworks it NATs.
Multi-region architectures require consistent configuration and automation.

Pricing surprises

Cloud NAT has its own charges (gateway + data processed) and you still pay standard internet egress.
NAT logging can produce high log ingestion/storage costs if enabled broadly.

Compatibility issues

If you remove or modify default routes, private instances may not reach the internet even with NAT.
Strict egress firewall policies can block needed outbound ports (common in locked-down orgs).
Hybrid NAT patterns (on-prem egress through Cloud NAT) require careful routing symmetry; asymmetric routing can break return traffic.

Operational gotchas

Troubleshooting egress often requires coordinating:
firewall rules
routes
NAT scope
DNS resolution
application behavior (timeouts, retries, connection reuse)
NAT issues can appear as “the internet is down” from the VM perspective; build runbooks.

Migration challenges

Migrating from NAT instances to Cloud NAT requires:
identifying current egress IP dependencies (allowlists)
updating partners with new NAT IPs (if changing)
validating routing and firewalling
validating performance for high-connection workloads

14. Comparison with Alternatives

Cloud NAT is one option in Google Cloud Networking for enabling outbound connectivity. Here’s how it compares.

Key alternatives in Google Cloud

External IP per VM: Simple, but increases exposure and management overhead.
NAT instances (self-managed): Flexible, but requires patching, scaling, failover, and performance tuning.
Proxy-based egress (self-managed or partner solutions): Adds L7 controls (URL filtering, auth, TLS inspection), but more complexity and cost.
Private Google Access: Access Google APIs privately without internet egress (complementary, not a full NAT replacement). Verify applicability per service.

Other clouds

AWS NAT Gateway
Azure NAT Gateway

Open-source / self-managed

Linux iptables/nftables NAT appliances
pfSense/OPNsense-based NAT
Envoy-based egress gateways (more proxy than NAT)

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Google Cloud NAT (Cloud NAT)	Private workloads needing outbound internet	Managed, regional, avoids external IPs on VMs, supports static egress IPs, integrates with VPC	Outbound only, regional, not L7 policy	Standard pattern for private subnets needing internet egress
External IP per VM	Small/simple setups	Very simple, no extra NAT config	Larger attack surface, per-VM management, harder allowlisting consistency	Quick prototypes where exposure is acceptable and controlled
NAT instance (self-managed)	Highly customized NAT behavior	Full control (iptables, routing), can combine with proxy	Ops burden, scaling, HA complexity, patching	Specialized needs not met by Cloud NAT (verify) or legacy constraints
Proxy / Secure web gateway	Compliance requiring L7 inspection/filtering	URL/category filtering, auth, detailed logs, TLS inspection (where allowed)	More complexity, latency, cost	Regulated egress where destination control is mandatory
Private Google Access	Access Google APIs without internet	Keeps Google API traffic on Google network paths	Only for Google APIs; not general internet	Use alongside NAT or instead of NAT for Google API access patterns
AWS NAT Gateway	AWS environments	Managed NAT service	Different cloud; design differences	When building on AWS
Azure NAT Gateway	Azure environments	Managed NAT service	Different cloud; design differences	When building on Azure

15. Real-World Example

Enterprise example: regulated private GKE platform with allowlisted egress

Problem: A financial services company runs private GKE clusters. Nodes must pull updates and call specific external risk/scoring APIs. Security requires:
no external IPs on nodes
fixed egress IPs for vendor allowlisting
centralized egress visibility
Proposed architecture:
Shared VPC per environment (prod/nonprod)
Private subnets per region with private GKE nodes
Cloud NAT per region with reserved static external IPs
Egress firewall rules allow only required destinations/ports (often 443)
NAT logging enabled in a controlled way + log sink to SIEM
Why Cloud NAT was chosen:
Managed egress without external IPs on nodes
Stable egress IPs for allowlisting
Reduced operational risk vs NAT instances
Expected outcomes:
Reduced attack surface
Faster vendor onboarding (known egress IPs)
Better incident response with NAT logs and metrics
Predictable regional egress design

Startup/small-team example: private VM build agents with minimal ops

Problem: A startup runs private build agents on Compute Engine. They must download dependencies and push artifacts, but the team wants minimal security exposure and minimal networking maintenance.
Proposed architecture:
One VPC with private subnet in a single region
Build agent VMs with no external IPs
Cloud NAT with auto-allocated external IPs
IAP for SSH access during debugging
Why Cloud NAT was chosen:
Quick to set up and managed
Keeps VMs private without managing NAT appliances
Expected outcomes:
Secure default posture with low maintenance
Working outbound builds without bastions or public IPs

16. FAQ

1) Does Cloud NAT allow inbound connections to my private VM?

No. Cloud NAT provides outbound NAT (SNAT). It does not create inbound connectivity for unsolicited internet traffic.

2) If my VM has no external IP, how can I SSH to it?

Use IAP TCP forwarding (gcloud compute ssh --tunnel-through-iap) or connect through a VPN/Interconnect path. Cloud NAT is not for admin access.

3) Is Cloud NAT global?

No. Cloud NAT is regional. You deploy it per region.

4) Do I need Cloud Router to use Cloud NAT?

Yes. Cloud NAT configuration is attached to a Cloud Router (regional).

5) Does Cloud NAT replace firewall rules?

No. Cloud NAT does not enforce allow/deny policy by itself. Use VPC firewall rules (and/or firewall policies) to control egress.

6) Can I get fixed egress IP addresses?

Yes. Use reserved static external IP addresses for the NAT gateway so your outbound traffic uses known IPs.

7) What causes Cloud NAT port exhaustion?

Many private endpoints opening many simultaneous outbound connections (or many short-lived connections) can exhaust available source ports on the NAT external IPs. Mitigations include adding NAT IPs and improving connection reuse.

8) Can Cloud NAT be used for GKE?

Yes, commonly for private nodes needing outbound access. Ensure NAT scope includes the relevant subnetworks/ranges for your cluster mode (verify current GKE + Cloud NAT guidance).

9) Can Cloud NAT be used with serverless (Cloud Run / Cloud Functions)?

Often indirectly: serverless egress through a Serverless VPC Access connector into a VPC can then use Cloud NAT for internet egress. Verify current serverless networking docs for your exact setup.

10) Is Cloud NAT the same as Private Google Access?

No. Private Google Access is for reaching Google APIs without public internet egress (in many cases). Cloud NAT is for internet egress via NAT.

11) Does Cloud NAT provide NAT for IPv6?

Cloud NAT is primarily used for IPv4 egress NAT scenarios. IPv6 behavior and best options can change—verify current IPv6 and Cloud NAT documentation for your requirements.

12) Do I still pay for internet egress if I use Cloud NAT?

Yes. Cloud NAT adds NAT-related charges, but internet egress charges still apply separately.

13) Is Cloud NAT suitable for compliance environments?

Often yes, as part of a broader control set: private IP-only workloads, controlled egress, static IP allowlists, and logging. Compliance requirements vary—pair NAT with firewalling, monitoring, and governance.

14) How do I troubleshoot “no internet” from a private VM?

Check, in order: – VM has default route to internet gateway – egress firewall rules allow required ports – Cloud NAT exists in the same region and includes the VM’s subnet/range – NAT is healthy and not under port pressure – DNS resolution and application timeouts

15) Can I use Cloud NAT for on-prem traffic exiting via Google Cloud?

In some architectures, yes—if on-prem traffic is routed into the VPC and then out to the internet, Cloud NAT can translate it. This is an advanced pattern requiring careful routing, firewalling, and validation. Verify in official docs for supported designs.

17. Top Online Resources to Learn Cloud NAT

Resource Type	Name	Why It Is Useful
Official documentation	Cloud NAT overview	Core concepts, architecture, configuration basics. https://cloud.google.com/nat/docs/overview
Official documentation	Cloud NAT documentation (main)	End-to-end docs including logging and troubleshooting. https://cloud.google.com/nat/docs
Official documentation	Cloud Router documentation	Required component for Cloud NAT configuration. https://cloud.google.com/network-connectivity/docs/router
Official pricing	VPC Network Pricing (Cloud NAT)	Authoritative pricing model and SKUs. https://cloud.google.com/vpc/network-pricing
Official tool	Google Cloud Pricing Calculator	Model NAT gateway hours, data processing, and egress. https://cloud.google.com/products/calculator
Official tutorial/docs	IAP TCP forwarding / SSH via IAP	Secure admin access to private VMs without external IPs. https://cloud.google.com/iap/docs/using-tcp-forwarding
Official docs	VPC firewall rules	Required for egress control and IAP SSH ingress. https://cloud.google.com/firewall/docs/firewalls
Official docs	VPC routes	Understand default routes and custom routing impacts. https://cloud.google.com/vpc/docs/routes
Official docs	Cloud Logging	Manage NAT log ingestion, retention, and access. https://cloud.google.com/logging/docs
Official docs	Cloud Monitoring	Build dashboards and alerts for networking services. https://cloud.google.com/monitoring/docs
Architecture guidance	Google Cloud Architecture Center	Reference architectures for private networking patterns (search for Cloud NAT + private workloads). https://cloud.google.com/architecture
Videos (official)	Google Cloud Tech YouTube	Look for Cloud NAT / VPC Networking deep dives (verify latest). https://www.youtube.com/@googlecloudtech

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams, beginners	Google Cloud fundamentals, Networking, automation, DevOps practices	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Developers, DevOps engineers	DevOps tooling, CI/CD, cloud basics	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud operations, monitoring, cost/ops practices	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform engineers	Reliability engineering, observability, incident response	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams, SREs, IT managers	AIOps concepts, monitoring automation, operational analytics	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps / Cloud training content (verify offerings)	Beginners to intermediate engineers	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training programs (verify course catalog)	DevOps practitioners	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps guidance/training (verify services)	Teams needing short-term help or coaching	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and enablement (verify services)	Ops/DevOps teams	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact offerings)	Architecture, implementation, migrations, automation	Shared VPC + Cloud NAT rollout; private subnet patterns; IaC for networking	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training services	Platform enablement, DevOps transformation, cloud best practices	Designing private networking; Cloud NAT + IAP patterns; cost governance setup	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify scope)	CI/CD, cloud operations, reliability practices	Building secure egress; operational runbooks; monitoring/logging for Networking	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Cloud NAT

To use Cloud NAT confidently, learn these Google Cloud Networking fundamentals:

VPC networks, subnetworks (regional), IP addressing
Routes and default internet gateway behavior
VPC firewall rules (ingress vs egress)
Compute Engine VM networking (internal/external IPs)
Basic DNS and name resolution in VPC
IAM basics for networking resources

Suggested practice: – Build a VPC with private and public subnets. – Use IAP to access private VMs. – Apply egress firewall rules to restrict outbound ports.

What to learn after Cloud NAT

To design production-ready egress and secure Networking:

Private Google Access and private access patterns for Google APIs
Shared VPC and organization-level governance
Cloud VPN / Cloud Interconnect and dynamic routing with Cloud Router (BGP)
Centralized egress with proxy architectures (for L7 control)
Network security controls (hierarchical firewall policies, VPC Service Controls where applicable)
Observability:
Logging sinks, metrics-based alerts, SIEM integration
Cost optimization for network egress and logging

Job roles that use Cloud NAT

Cloud engineer / Cloud network engineer
Solutions architect
DevOps engineer / Platform engineer
SRE
Security engineer (cloud network security)
Operations engineer

Certification path (Google Cloud)

Google Cloud certifications change over time. Cloud NAT appears under broader Networking objectives rather than as a standalone exam topic. Relevant certification tracks often include:

Associate Cloud Engineer (ACE)
Professional Cloud Architect
Professional Cloud Network Engineer (if available in your region/timeframe; verify current certification catalog)

Verify current certifications: https://cloud.google.com/learn/certification

Project ideas for practice

Build a private GKE cluster with Cloud NAT and restricted egress firewall rules.
Implement per-environment NAT IPs (dev/stage/prod) and document allowlisting workflow.
Simulate port pressure by generating many outbound connections; observe NAT logs/metrics (do carefully to avoid cost).
Create Terraform modules for Cloud Router + Cloud NAT + firewall rules with standardized naming/labels.

22. Glossary

Cloud NAT: Google Cloud managed service providing outbound (SNAT) for private resources in a VPC.
NAT (Network Address Translation): Technique to map one IP address space to another; here mainly private-to-public for outbound connectivity.
SNAT (Source NAT): Changes the source IP/port of outbound packets so replies return to the NAT gateway.
VPC (Virtual Private Cloud): Your private virtual network in Google Cloud.
Subnetwork (Subnet): Regional IP range within a VPC where resources get IPs.
Cloud Router: Regional Google Cloud resource that supports dynamic routing (BGP) and hosts Cloud NAT configuration.
External IP address: Publicly routable IP address in Google Cloud; can be ephemeral or reserved (static).
IAP (Identity-Aware Proxy): Google Cloud service to access private resources securely without exposing them publicly (includes TCP forwarding).
Egress: Outbound traffic leaving a network or resource.
Ingress: Inbound traffic entering a network or resource.
Firewall rule: VPC rule controlling allowed/denied traffic by direction, protocol, ports, tags/service accounts, and IP ranges.
Port exhaustion: Condition where NAT cannot allocate sufficient source ports for new outbound connections.
Shared VPC: A Google Cloud model where a host project owns the network and service projects attach workloads.

23. Summary

Cloud NAT (Google Cloud Networking) is a regional, managed outbound NAT service that lets private resources reach the internet without external IPs. It matters because it reduces attack surface, centralizes and standardizes egress behavior, and eliminates the operational burden of managing NAT instances.

Cloud NAT fits best in private-by-default architectures—private VMs, private GKE nodes, and segmented VPC designs—especially when you need stable egress IPs for allowlisting. Cost planning should account for NAT gateway time, NAT data processing, internet egress, external IP addresses, and potentially logging volume. Security-wise, Cloud NAT is not a firewall or proxy; pair it with egress firewall rules, governance, and (when needed) proxy-based controls for deeper inspection.

Next step: extend this lab by adding egress firewall restrictions, enabling NAT logging with retention controls, and deploying Cloud NAT consistently across multiple regions and environments using infrastructure as code.

Category

1. Introduction

2. What is Cloud NAT?

Official purpose

Core capabilities

Major components

Service type

Scope: regional/global/zonal?

How it fits into the Google Cloud ecosystem

3. Why use Cloud NAT?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose it

When teams should not choose it

4. Where is Cloud NAT used?

Industries

Team types

Workloads

Architectures

Production vs dev/test usage

5. Top Use Cases and Scenarios

1) Private VM package updates

2) Private GKE nodes pulling container images

3) Allowlisted egress IPs for third-party SaaS

4) Outbound access for private CI/CD runners

5) Private data processing workers calling external APIs

6) Centralized outbound egress in a Shared VPC

7) Hybrid on-prem egress through Google Cloud

8) Private microservices needing outbound telemetry

9) Bastionless administration (IAP + NAT)

10) Egress IP consistency for partner APIs across environments

11) Migration away from NAT instances

12) Controlled egress for private subnets with firewall enforcement

6. Core Features

6.1 Managed outbound NAT (SNAT) for private resources

6.2 Regional Cloud NAT gateways (configured on Cloud Router)

6.3 NAT IP address options (auto vs manual)

6.4 Subnetwork and IP range selection

6.5 Port allocation and scale behavior

6.6 NAT logging

6.7 Works with hybrid routes (when traffic traverses the VPC)

6.8 High availability (managed service)

7. Architecture and How It Works

High-level architecture

Request/data/control flow (conceptual)

Integrations with related services

Dependency services

Security/authentication model

Networking model considerations

Monitoring/logging/governance considerations

Simple architecture diagram (Mermaid)

Production-style architecture diagram (Mermaid)

8. Prerequisites

Account/project requirements

IAM roles (typical)

Billing requirements

Tools needed

Region availability

Quotas/limits

Prerequisite services/APIs

9. Pricing / Cost

Pricing dimensions (how you’re billed)

Free tier

Key cost drivers

Hidden/indirect costs to plan for

Network/data transfer implications

How to optimize cost (practical)

Example: low-cost starter estimate (how to think about it)

Example: production cost considerations

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Set your project and region

Step 2: Enable the required API(s)

Step 3: Create a VPC network and a private subnet

Step 4: Create a VM with NO external IP

Step 5: Allow IAP SSH access to the VM (no external IP)