Google Cloud Virtual Networks (VPC)
What a VPC Is
A VPC is a private, customizable network environment inside a public cloud platform such as AWS, Azure, Google Cloud, or IBM Cloud. It provides:
- Logical isolation from other tenants.
- Control over IP address ranges, subnets, route tables, and gateways.
- Secure placement of compute, storage, and database resources.
Key Components
- Subnets: Segments of the VPC’s IP range for grouping resources.
- Internet Gateway: Enables public internet access.
- NAT Gateway: Allows private subnet resources to access the internet without being exposed.
- Route Tables: Control traffic flow within and outside the VPC.
- VPC Endpoints: Private access to cloud services without using the internet.
- VPN / Direct Connect: Hybrid connectivity to on‑premises networks.
Why VPCs Matter
- Security: Isolation, security groups, and network ACLs.
- Flexibility: Define your own network topology and scale resources.
- Hybrid Integration: Extend your data center into the cloud.
- Control: Full control over routing, connectivity, and resource placement.
A VPC is a foundational cloud networking construct that enables secure, customizable, and scalable cloud deployments.
☁️ Google Cloud Networking
Google Cloud uses a software-defined network (SDN) built on Google's global fiber-optic network.
Think:
GOOGLE CLOUD | ┌─────────────┼─────────────┐ ↓ ↓ ↓ Regions PoPs Services | Zones | VPC Networks
Region
A region is a geographical location where Google Cloud resources run.
Example:
asia-south1 us-central1 europe-west1
Zone
A region contains multiple zones.
Example:
Region: asia-south1 ├── asia-south1-a ├── asia-south1-b └── asia-south1-c
A VM is normally created in a zone.
PoP — Point of Presence
A PoP is where Google's network connects/interconnects with the rest of the internet.
Google's global network connects:
Regions ↔ PoPs ↔ Regions
2. VPC — Virtual Private Cloud ⭐⭐⭐
VPC = Google's managed networking environment for your Google Cloud resources.
It lets you:
- Connect resources
- Isolate resources
- Control traffic
- Configure IP addresses
- Configure routes
- Configure firewall rules
- Connect GCP to on-premises networks
Think of a VPC as your private virtual network inside Google Cloud.
VPC | ┌──────────┼──────────┐ ↓ ↓ ↓ Subnet Subnet Subnet ↓ ↓ ↓ VM VM VM
3. Project
A Project is the main organizer/container for Google Cloud resources.
A project is associated with:
- Resources
- Services
- Billing
- IAM/access control
- Quotas
Example:
Project: My-Application | ├── VPC ├── VM ├── Cloud SQL ├── Cloud Storage └── Other services
Important
A project can contain entire VPC networks.
The course mentioned a default quota of 15 networks per project, with the ability to request more quota.
4. Network vs Subnetwork ⭐⭐⭐
This distinction is extremely important.
VPC Network
A VPC is global.
It can span multiple regions.
VPC Network | ┌───────────┼───────────┐ ↓ ↓ ↓ Asia Europe America Region Region Region
Subnetwork
A subnet is regional.
VPC | ├── asia-south1 subnet | ├── europe-west1 subnet | └── us-central1 subnet
A subnet can span multiple zones within its region.
asia-south1 | ├── Zone A ── VM1 | └── Zone B ── VM2 Same subnet
Easy memory
VPC = Global
Subnet = Regional
VM = Zonal
5. Types of VPC Networks
There are three important network modes:
- Default
- Auto mode
- Custom mode
5.1 Default Network
Every Google Cloud project gets a default VPC network.
It comes with:
- Pre-created subnets
- Pre-configured firewall rules
The default network is an auto mode network.
6. Auto Mode Network
In an auto mode VPC, Google automatically creates a subnet for each region.
The subnets use predefined IP ranges.
The course states that these start with:
/20
and can be expanded up to:
/16
The ranges fit within:
10.128.0.0/9
When Google adds a new region, an auto-mode network can automatically receive a subnet for that region.
Easy idea
AUTO = Google creates subnets for you
7. Custom Mode Network ⭐
A custom VPC doesn't automatically create subnets.
You decide:
- Which regions need subnets
- What CIDR ranges they use
- How large the ranges are
Example:
Custom VPC | ├── asia-south1 │ └── 10.10.0.0/24 | └── us-central1 └── 10.20.0.0/24
Advantage
You have complete control over IP addressing.
Important
Subnet CIDR ranges in the same VPC must not overlap.
8. Auto → Custom Conversion
You can convert:
AUTO ↓ CUSTOM
But not:
CUSTOM ↓ AUTO
So the conversion is one-way.
Memory trick
Auto → Custom = YES
Custom → Auto = NO
Custom mode is generally preferred when you need precise control over enterprise network design.
9. CIDR — IP Range ⭐⭐⭐
CIDR tells you how large an IP range is.
Example:
10.10.0.0/24
IPv4 has 32 bits.
Number of addresses:
2^(32 - prefix)
For /24:
2^(32-24) = 2^8 = 256 addresses
For /20:
2^(32-20) = 4096 addresses
For /29:
2^(32-29) = 8 addresses
10. Reserved IP Addresses in a Subnet
The course explains that four addresses are reserved in the primary subnet range.
For example:
Subnet: 10.10.0.0/29 Total = 8 addresses
Conceptually:
.0 → Reserved .1 → Reserved .2 → Available .3 → Available .4 → Available .5 → Available .6 → Reserved .7 → Reserved
So:
8 total - 4 reserved = 4 usable
This is why a /29 subnet in the demo could support four VM internal addresses.
11. Expanding a Subnet ⭐⭐⭐
One of the labs demonstrated this.
Initially:
Subnet = /29
It had only enough usable IP space for the four VMs.
Creating another VM failed:
IP space exhausted ❌
The subnet was then expanded:
/29 ↓ /23
After expansion:
More IP addresses available ↓ New VM created successfully
Most important point
Subnet expansion can happen without shutting down the existing workloads.
12. CIDR Expansion Rule
When expanding a subnet:
/29 → /28 → /27 → /26
The prefix number becomes smaller.
Why?
Because smaller prefix = larger address space.
For example:
/29 = 8 addresses /28 = 16 /27 = 32 /26 = 64
You cannot shrink it back
If you expand:
/29 → /23
you cannot simply reverse it back to /29.
Memory
Smaller
/number= Bigger network
13. Don't Make Subnets Unnecessarily Large
Large subnets aren't always better.
Very large CIDR ranges can create problems with:
- VPC Peering
- VPN
- On-premises networks
- Multiple network interfaces
- CIDR collisions
So:
Give the subnet enough IPs for expected growth, but don't make it unnecessarily huge.
14. IP Addresses in GCP
A VM can have:
VM | ├── Internal IP | └── External IP (optional)
15. Internal IP ⭐⭐⭐
Every VM needs an internal IP.
It is used for communication inside the VPC.
Example:
VM1 10.10.0.5 | ↓ VM2 10.20.0.5
Internal IPs are assigned from the subnet.
They can be:
- Ephemeral
- Reserved/static
16. External IP
External IP is optional.
A VM doesn't need a public IP to communicate with other resources through private networking.
Example:
VM | ├── Internal IP ✅ | └── External IP ❌
If you want the VM to be directly reachable from the internet, you may need an external IP or another appropriate public-facing service.
17. Ephemeral vs Static IP ⭐⭐⭐
Ephemeral
Temporary IP.
VM ↓ Ephemeral external IP
It can change when the VM is stopped and started.
Static
Reserved IP.
Reserved IP ↓ VM
Used when you need a stable address.
18. Important IP Demo
The course demonstrated:
Before stop: Internal IP = 10.10.0.5 External IP = 34.x.x.x
VM stopped:
Internal IP = 10.10.0.5 External IP = released
VM started:
Internal IP = 10.10.0.5 External IP = NEW IP
Because the external IP was ephemeral.
Remember
Ephemeral external IP → can change
Static external IP → reserved/stable
19. External IP Is Not Directly Known by the VM ⭐⭐⭐
This is a slightly advanced but important concept.
Suppose:
VM internal IP = 10.10.0.5 External IP = 34.100.20.30
Inside the VM, the OS primarily sees:
10.10.0.5
The external IP is mapped by Google's networking layer.
Conceptually:
Internet | 34.100.20.30 | Google VPC mapping | 10.10.0.5 | VM
So if you run:
ifconfig
inside the VM, you won't see the external IP as an IP configured on the VM's network interface.
20. Internal DNS ⭐
Google Cloud provides internal DNS.
A VM has a hostname related to its instance name.
For example:
VM name = web-server
The name can resolve to:
web-server → 10.10.0.5
So applications don't have to hard-code IP addresses everywhere.
21. Zonal and Global DNS
Google Cloud has:
- Zonal DNS
- Global/project-wide DNS
The course recommends zonal DNS because it provides better failure isolation.
Remember
Zonal DNS = recommended for better reliability/failure isolation
22. VM Recreated → IP Can Change
Suppose:
web-server 10.10.0.5
You delete and recreate it.
It might become:
web-server 10.10.0.8
So hard-coding the IP can cause problems.
DNS can continue to resolve the hostname to the appropriate instance.
Best practice
Prefer DNS names over hard-coded IPs where appropriate.
23. Metadata Server
Every Compute Engine VM has access to a metadata server.
It provides VM metadata and participates in DNS resolution.
Conceptually:
VM | ↓ Metadata/DNS resolver | ├── Internal/local DNS | └── Public DNS
24. Cloud DNS
Cloud DNS is Google's managed authoritative DNS service.
It translates:
Domain name ↓ IP address
Example:
www.example.com ↓ 34.x.x.x
It uses Google's global Anycast infrastructure to provide:
- High availability
- Global reach
- Low latency
- Scalability
You don't need to manage your own DNS servers.
25. Alias IP Ranges
Alias IP allows additional internal IP addresses/ranges to be assigned to a VM's network interface.
Useful when one VM hosts multiple applications/containers.
Example:
VM | Network Interface | ┌───────┼───────┐ ↓ ↓ ↓ App 1 App 2 App 3 10.0.0.10 .11 .12
Instead of creating a separate network interface for each service, aliases can be used.
Alias ranges can come from the subnet's appropriate primary/secondary ranges.
26. Routes ⭐⭐⭐
A route tells GCP where traffic should go.
Example:
Destination: 10.20.0.0/24 Next hop: Subnet/appropriate route
Think:
Route = GPS
It finds the path.
27. Default Routes
VPC networks have routes that allow internal connectivity.
When subnets are created, routes allow VMs to reach destinations within the VPC.
There is also a default route for destinations outside the VPC.
Conceptually:
Packet | ↓ Destination IP | ├── Known internal destination │ ↓ │ Specific route │ └── Other destination ↓ Default route
28. Custom Routes
You can create special routes for particular networking requirements.
But:
Creating a route does NOT automatically mean traffic will be allowed.
This brings us to firewall rules.
29. Route vs Firewall ⭐⭐⭐⭐⭐
This is one of the most important concepts in the entire module.
Route
Answers:
WHERE should the packet go?
Firewall
Answers:
IS the packet allowed?
Example:
VM1 | | Packet ↓ ROUTE | | "VM2 is reachable this way" ↓ FIREWALL | | "Is this traffic allowed?" ↓ VM2
Therefore:
Route ✅ Firewall ❌ ↓ Traffic fails
You need the correct route and firewall permission.
30. Virtual Router
Google Cloud has a massively scalable virtual networking layer.
Think of:
VPC | Virtual Router | ┌─────────┼─────────┐ ↓ ↓ ↓ VM1 VM2 VM3
Packets leaving VMs are handled by this virtual networking layer and forwarded according to the applicable routing table.
You don't manage physical routers yourself.
31. Firewall Rules ⭐⭐⭐
A firewall controls network traffic to/from VM instances.
Two directions:
Ingress
Outside → VM
IN = INGRESS
Egress
VM → Outside
EXIT = EGRESS
32. Firewall Is Distributed
Think of the VPC as having security controls around its VM workloads:
VPC | ┌───────┼───────┐ ↓ ↓ ↓ VM1 VM2 VM3
Firewall rules are configured for the network but traffic is enforced at the instance level.
Firewall can control:
Internet → VM
and also:
VM1 → VM2
even when both VMs are in the same VPC.
33. Stateful Firewall ⭐⭐⭐
GCP firewall rules are stateful.
Suppose:
VM1 → request → VM2
The connection is allowed.
The response:
VM2 → response → VM1
is allowed as part of the established connection.
Easy definition
Stateful firewall remembers established connections.
34. Implied Firewall Rules
Even if you delete all explicit firewall rules, there are implied rules.
Conceptually:
Ingress → DENY ALL Egress → ALLOW ALL
So:
Incoming traffic
If no rule allows it:
❌ Denied
Outgoing traffic
If no rule denies it:
✅ Allowed
These are the baseline implied behaviors described in the course.
35. Firewall Rule Components
A firewall rule has:
1. Direction 2. Source/Destination 3. Protocol 4. Port 5. Action 6. Priority 7. Target
Example — SSH
Direction: INGRESS Source: allowed IP range Protocol: TCP Port: 22 Action: ALLOW Priority: appropriate priority Target: SSH VM
36. Firewall Priority ⭐
Multiple firewall rules can match the same traffic.
The rules have priorities.
The applicable rule with the highest precedence / first matching evaluation according to the firewall rule model determines the result.
For the course, remember:
Priority controls which matching rule is evaluated first.
37. Egress Firewall Example
Suppose a VM should not connect to a certain destination:
VM | | TCP 443 ↓ Egress Firewall | X DENY ↓ Destination
That's an egress deny rule.
38. Ingress Firewall Example
Suppose your web server should accept HTTP:
Internet | | TCP 80 ↓ Ingress Firewall | | ALLOW ↓ Web VM
39. Network Pricing ⭐⭐⭐
Now the networking cost part.
Ingress
Traffic coming into Google Cloud:
Internet → GCP
Generally no network ingress charge.
But services such as load balancers can have their own processing charges.
40. Egress
Traffic leaving Google Cloud:
GCP → Internet
Egress can be charged.
Also remember:
Request → Ingress Response → Egress
41. Same-Zone Traffic
Same zone + internal IP:
Zone A VM1 | | Internal IP ↓ VM2
The course says this egress is not charged.
42. Cross-Zone Traffic
Same region but different zones:
Region | ├── Zone A → VM1 | └── Zone B → VM2
Traffic:
VM1 → VM2
can incur inter-zone egress charges.
43. Same Zone Using External IP
Even if VMs are in the same zone:
VM1 → External IP → VM2
the traffic can be charged because it uses the external addressing path.
Therefore, when communicating internally:
Prefer internal IPs rather than unnecessarily using external IPs.
44. Cross-Region Traffic
Example:
asia-south1 | ↓ us-central1
Traffic between regions can incur inter-region egress/network charges.
This is why architecture and resource placement matter.
45. External IP Pricing
External IPv4 addresses can incur charges.
A particularly important point:
Static IP | ↓ Not attached to a resource ↓ Higher charge
So don't reserve static external IPs and leave them unused.
46. Google Cloud IP Range Files
Google publishes IP ranges.
cloud.json
Think:
Google Cloud customer-usable IP ranges
goog.json
Think:
Google's public IP prefixes
goog.txt
Google public prefixes in TXT format.
cloud_geofeed
IP geolocation information for external IP-geolocation providers.
Easy memory:
cloud.json → Cloud IP ranges goog.json → Google public prefixes goog.txt → Google prefixes, TXT geofeed → IP location information
47. Pricing Calculator
Google Cloud has a Pricing Calculator.
You can enter things like:
VM type Region Storage Network traffic Other services ↓ Pricing Calculator ↓ Estimated cost
It's useful because every GCP service can have its own pricing model.
🧠 FINAL MASTER DIAGRAM
If you remember only one diagram from this entire module, remember this:
GOOGLE CLOUD | PROJECT | VPC GLOBAL NETWORK | ┌───────────────┼───────────────┐ ↓ ↓ ↓ REGION REGION REGION | | | SUBNET SUBNET SUBNET | | | ┌───┴───┐ ┌───┴───┐ ↓ ↓ ↓ ↓ VM VM VM VM | | Internal Internal IP IP | Optional External IP | ↓ Internet
Traffic flow:
VM | ↓ ROUTE | | Where should it go? ↓ FIREWALL | | Is it allowed? ↓ DESTINATION
🎯 Most Important Things to Memorize
| Concept | Remember |
|---|---|
| Project | Organizes resources + billing |
| VPC | Global virtual network |
| Subnet | Regional IP range |
| VM | Usually associated with a zone |
| Default network | Pre-created + firewall rules |
| Auto network | Automatically creates regional subnets |
| Custom network | You create/manage subnets |
| Auto → Custom | Possible |
| Custom → Auto | Not possible |
| Internal IP | Required for VM |
| External IP | Optional |
| Ephemeral IP | Can change |
| Static IP | Reserved/stable |
| CIDR | Defines IP range |
| Route | Determines path |
| Firewall | Allows/denies traffic |
| Ingress | Incoming |
| Egress | Outgoing |
| Stateful firewall | Tracks established connections |
| Cloud DNS | Managed DNS |
| Alias IP | Extra internal IPs/ranges on interface |
| Same-zone internal traffic | Generally no egress charge |
| Cross-zone traffic | Can be charged |
| Cross-region traffic | Can be charged |
| Unused static external IP | Higher charge |
| cloud.json | Cloud IP ranges |
| goog.json | Google public prefixes |
🔥 10 Interview/Exam Questions From This Module
1. Is VPC regional or global?
Global.
2. Is a subnet regional or global?
Regional.
3. Does every VM need an external IP?
No.
4. Does every VM need an internal IP?
Yes.
5. What's the difference between route and firewall?
Route = where traffic goes.
Firewall = whether traffic is allowed.
6. What happens to an ephemeral external IP when a VM is stopped?
It is released and a different IP may be assigned when the VM starts again.
7. Can you expand a subnet without shutting down VMs?
Yes.
8. Can an auto-mode VPC be converted to custom mode?
Yes, one way.
9. What does ingress mean?
Incoming traffic.
10. What does egress mean?
Outgoing traffic.
🧠 Super-short revision
Before your next GCP lab, remember this:
PROJECT ↓ VPC = Global ↓ SUBNET = Regional ↓ VM = Zone ↓ INTERNAL IP = Required EXTERNAL IP = Optional ↓ ROUTE = Where? ↓ FIREWALL = Allowed? ↓ TRAFFIC
And for cost:
INGRESS → Generally free EGRESS → Often chargeable Same zone + internal IP → Generally free Cross zone → Can cost Cross region → Can cost External IP → Can cost Unused reserved static IP → Higher charge
Comments
Post a Comment