Why write a profile before picking a service
In Level 1 you saw every Google Cloud networking service on one page. The usual mistake comes next: someone says "we need a load balancer and a VPN" before anyone has written down what the workload actually does. A connectivity profile fixes that. It's a short, reusable document that turns vague needs into numbers you can test. Each service lesson later in this course gets checked against it.
Think of it as a building survey done before you hire builders. Nobody quotes for plumbing until they know how many bathrooms there are and where the water main comes in.
We'll fill one in for a realistic workload: ShopFast, an online store. It serves customers in the US and Europe from us-central1 and europe-west1, and it sends orders to an ERP system in a data centre in Frankfurt.
Step 1: List every flow, then classify it
Work in this order: list the flows → mark which boundaries each one crosses → attach numbers → attach cost lines. If you put numbers on a flow before you know its boundaries, you'll price it wrong.
- North-south traffic enters or leaves your environment: users on the internet, partners, the on-premises data centre.
- East-west traffic moves between your own workloads: web tier to API, API to database, region to region.
The boundary matters more than the direction. Within the same network, a flow that stays in one zone costs nothing. The same bytes crossing zones, regions, clouds or a hybrid link start costing money and adding latency.
# connectivity-profile.yaml (ShopFast, v1, 2026-10)
flows:
- id: F1
name: customers -> storefront (HTTPS)
direction: north-south
crosses: [internet]
protocol: HTTPS (TCP 443, HTTP/2)
volume_out_gib_month: 1000 # responses sent to users
latency_target: p95 < 300 ms page load
- id: F2
name: storefront -> orders API -> database
direction: east-west
crosses: [zone] # replicas sit in two zones
protocol: gRPC + PostgreSQL (TCP 5432)
volume_gib_month: 5000
latency_target: p99 < 10 ms per call
- id: F3
name: us-central1 <-> europe-west1 replication
direction: east-west
crosses: [region]
volume_gib_month: 400
- id: F4
name: orders -> Frankfurt ERP
direction: north-south
crosses: [hybrid]
protocol: HTTPS + SFTP batch
volume_gib_month: 200
bandwidth_peak: 200 Mbps
- id: F5
name: private VMs -> package mirrors / SaaS APIs
direction: north-south (outbound only)
crosses: [internet]
volume_gib_month: 300
Gotcha: teams forget outbound-only flows like F5: OS updates, container image pulls, calls to payment APIs. They don't show up on architecture diagrams, but they do show up on the bill.
Step 2: Answer the non-traffic questions
Numbers alone don't pick a service. Add the constraints:
availability:
storefront: 99.95% monthly, survive loss of one zone
hybrid_link: survive loss of one tunnel or one device # F4 must not stop
failover_rto: 5 min regional, 0 for zonal
segmentation:
model: zero trust; no flat network
rules: only orders API may reach DB; ERP reachable only from orders
internet_exposure:
public_endpoints: [storefront]
ddos_concern: high (sales events draw bots)
compliance:
data_paths: EU customer orders must stay in EU regions + Frankfurt
encryption: TLS in transit, IPsec on hybrid link
team_skills: strong on Terraform + HTTP; no BGP experience yet
Every line here will rule services in or out later. A team with no BGP experience is a real constraint, because Google's HA VPN and Interconnect both run BGP sessions through Cloud Router.
Step 3: Attach the cost model to each flow
Google Cloud networking costs fall into three buckets:
- Hourly charges: things that exist whether or not traffic flows (forwarding rules, VPN tunnels, NAT gateways).
- Per-GB processing: a fee for each byte a managed service handles (load balancers, Cloud NAT).
- Data transfer and egress: a fee for moving bytes between zones or regions, or out to the internet.
One byte can be charged in more than one bucket. A response sent through a load balancer is charged once for load-balancer processing and again for internet egress.
The example prices below are US-region list prices published as of October 2026. They vary by region and change over time, so always re-check them.
# cost_model.py: rough monthly network cost per flow
HOURS = 730
P = {
'egress_internet_premium': 0.12, # $/GiB, first TiB to North America
'inter_zone': 0.01, # $/GiB, zone to zone, same region
'lb_processing': 0.008, # $/GiB, external LB outbound (US)
'lb_rule_hour': 0.025, # $/forwarding rule/hour
'nat_processing': 0.045, # $/GiB through Cloud NAT
'vpn_tunnel_hour': 0.05, # $/tunnel/hour (up to 0.075 in some regions)
}
flows = {
'F1 egress': 1000 * P['egress_internet_premium'],
'F1 LB processed': 1000 * P['lb_processing'],
'F1 LB rule': HOURS * P['lb_rule_hour'],
'F2 inter-zone': 5000 * P['inter_zone'],
'F4 VPN tunnels': 2 * HOURS * P['vpn_tunnel_hour'], # 2 tunnels for HA
'F5 NAT': 300 * P['nat_processing'],
}
for k, v in flows.items(): print(f'{k:16} ${v:8.2f}')
print(f'{"TOTAL":16} ${sum(flows.values()):8.2f}')
F1 egress $ 120.00
F1 LB processed $ 8.00
F1 LB rule $ 18.25
F2 inter-zone $ 50.00
F4 VPN tunnels $ 73.00
F5 NAT $ 13.50
TOTAL $ 282.75
This rough model leaves out F3 (inter-region rates depend on the region pair, so look yours up) and F4's bytes leaving Google Cloud. Traffic sent over VPN to a gateway outside Google Cloud is charged at internet egress rates. Mark both as TODO with a source link rather than guessing.
Inbound traffic from the internet carries no data transfer charge. Services that process those bytes, such as a load balancer, still bill for it.
Step 4: Sanity-check the numbers against limits
Now test the profile against what services can physically do. For example, F4 needs to survive the loss of one tunnel. Google's HA VPN gives a 99.99% SLA for most topologies only when you configure two tunnels, or four tunnels to an AWS peer gateway, which is why the cost model counts two. Each tunnel handles up to about 250,000 packets per second, roughly 1–3 Gbps depending on packet size. So 200 Mbps fits easily. A future 10 Gbps nightly batch wouldn't, and that's the moment to look at Interconnect.
Best practice: version the profile in Git next to your Terraform. When a flow's volume doubles, change the number, rerun the cost script and see whether the service choice still holds.
Key takeaways
- Work in order: list flows → mark boundaries (zone, region, cloud, hybrid, internet) → add numbers → add cost lines.
- North-south traffic enters or leaves your environment; east-west traffic moves between your own workloads. Cost depends on which boundaries a flow crosses.
- Record protocols, latency targets, peak bandwidth, failover expectations, segmentation, DDoS exposure, data-residency paths and team skills, because each one rules services in or out.
- Every flow maps to hourly, per-GB processing and data transfer/egress charges, and one byte can hit more than one of them.
- Hidden flows like outbound NAT traffic and cross-zone database calls are where surprise bills come from.