Google Cloud — 網路服務簡介

運用"雲端服務"加速企業的數位轉型願景

11 min readDec 25, 2023

若我們有接觸過其他雲端平台的網路概念，例如AWS。哪麼理解GCP的網路相對來說就比較容易。當然，每一家雲端的網路都有相同與不相同之處，我們也會在這裡一併說明。

Virtual Private Cloud (VPC)

所謂的VPC，我們可以把它看成是傳統的地端機房+辦公司網路。我們可能規劃172.16.0.0/16的CIDR，然後根據每個辦公室樓層或地端機房的需求切分成不同的subnet。

GCP VPC支援的CIDR有"RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16"。以下三種IP range，VPC也不支援。

Private Google Access-specific virtual IP addresses: 199.36.153.4/30, 199.36.153.8/30
Current (local) network RFC 1122 — 0.0.0.0/8
Local host RFC 1122 — 127.0.0.0/8

在這種架構之下(以傳統Firewall觀點)，我們在地端機房的DB通常是不會直接暴露對外的。一定有一些安全設機與機制在把守這一塊。而VPC則可以帶給我們與傳統地端機房相同的安全性，但又多了地端機房沒有的特性。

既然VPC是我們機房內機器/系統運作的地方，哪我們就會有相對應的控制措施來管控進出的網路流量。GCP的VPC與AWS/Azure不同地方在於，GCP的VPC範圍是涵蓋GCP的全球機房的。也就是說如果我們整個VPC的CIDR是172.16.0.0/16，哪其中切分出來的subnet可以在任一個GCP的region。例如subnet A在台灣，subnet B在東京。

為什麼要切分subnet?

如果已經有AWS VPC概念的人，這一段可以跳過。要切分subnet是因為我們在雲端上建立不同類型的資源 — 資料庫、VM等。每種類型的資源都有自己的存取要求。

例如Load Balancer大都是面向Internet的（Public resource）。資料庫或VM instance則不應透過Internet存取。只有我們的網路 (VPC) 內的應用程式才應該能夠存取它們（私有資源）。

VPC subnets

所以我們為Public和private resource資源建立不同的subnet:

可以從Internet存取Public subnet中的資源
無法從 Internet 存取Private subnet中的資源
但是Public subnet中的資源可以與Private subnet中的資源通訊

再一次，GCP的每一個subnet可以在不同的Region。當我們建立一個GCP project時，GCP的VPC中已經有一個Default的VPC了。並且該VPC的subnet會平均散落在各個Region。

基本上我們應該建立自己的VPC，有兩種建立模式可供選擇:

Auto —
每個Region都會自動建立subnet，Project中自動建立的Default VPC使用的是自動模式
Custom —
需要手動指定每個subnet的範圍大小跟所在的Region/zone

subnet的範圍是可以再次修改的，但只能長大不能變小。例如可以從 /24長成 /22，只要沒有跟另外的subnet有衝到就好。

另外，雖然絕大部分的GCP resource都是建立在VPC內的。但是還是有少數服務無法這樣做，如Cloud Storage。但VPC內的resource一定會有存取這一類Service的時候，像是VM要把Cloud storage的bucket當成share folder。當然可以直接透過把VM掛上Public IP，但會有安全問題及流量費用過高的問題。這就我們就可以在VPC中啟用"Private Google Access"，這可以讓我們VPC裡的resource 用private IP的方式去連結該服務。如果我們在VPC裡有VM在運作時，我們想知道其網路流量狀況，可以啟用"VPC Flow Logs"。

Firewall Rules

有管理過地端機房Firewall的人，基本的Firewll在這一部分的概念也雷同。但我們會說明不同的部分。GCP的firewall也是statefull的，並且每條規則都會需要指定Priority(0–65535)，firewall會按順序檢查規則。這些都與傳統的firewall無異。

以下是我們在create firewall時就會存在的firewall rule並且priority是65535。而這些規則是無法刪除的，但是我們可以建立high priority來越過它們。

Allow all egress
Deny all ingress

而在Default VPC中，GCP還會建立以下額外的四條規則:

Allow incoming traff ic from VM instances in same network
作用:default-allow-internal
Allow Incoming TCP traff ic on port 22 (SSH)
作用:default-allow-ssh
Allow Incoming TCP traff ic on port 3389 (RDP)
作用:default-allow-rdp
Allow Incoming ICMP from any source on the network
作用:default-allow-icmp

Firewall Rules — Ingress and Egress Rules

Ingress就是由外(Internet)向內(VPC)，Egress就是反過來。Ingress rule會有:

Target (定出目的地): 範圍可以是All instances 或單一instances(有tag)
Source (定出來源): CIDR 或All instances 或單一instances(有tag)

而Egress rule則是:

Target (定出來源): All instances 或單一instances(有tag)
Destination: CIDR Block

每條rule都有需要設定以下屬性:

Priority — 數字越少，Priority越高
Action on match — Allow或Deny
Protocol — 例如TCP or UDP or ICMP
Port —甚麼port，如22/3389等
Enforcement status — 啟用或關閉該rule

我們最好使用network tags來控制VM的網路流量的進出。Firewall Rule的最佳實踐有:

確保Firewall Rule允許正確類型的流量：

只允許來自LB的流量進入VM Instance
從source IP 範圍中刪除 0.0.0.0/0
新增130.211.0.0/22和35.191.0.0/16
允許從LB到VM instance的health check

Shared VPC

當公司因為不同的環境或部門有很多個VPC時，而有些服務又是大家需要一起用的。這時就會啟用Shared VPC了，也就是hub-spoken的網路架構。要啟用shared VPC需要設定以下的條件:

在Org level或shared folder leve建立（需要的存取權限：Shared VPC Admin）
允許同一Org中的project之間共用 VPC
Shared VPC需要包含一個host project(HUB)與多個service projects(Spoken)：
Host project — shared VPC
Service project— attach到host project

而這整個網路架構都是由一個網路團隊進行管理。

VPC Peering

Shared VPC適用於同一個公司的內部網路。但是若是不同公司需要互相連接呢?不管這兩個要Peer的VPC是否處於同一個或不同的Project，理論上他們都可以連接。

所有通訊均使用Private IP 進行，要這樣做是因為:

效率很高，因為所有通訊都發生在 Google 網路內
高度安全，因為無法透過 Internet 存取
服務之間的資料傳輸不收取資料傳輸費用

這種方式與sharded VPC不一樣，兩個VPC的Network admin還是各管各的網路。

Cloud VPN

GCP提供的全託管式VPN服務。一般用於Site-to-Site(也就是地端機房連VPC)，當然也可以用client-to-site的方式。它與我們一般認知的VPN沒有甚麼不同，走的是IPSec VPN Tunnel 與Internet Key Exchange protocol。不過在GCP這一端的架構有以下兩種:

HA VPN(看名字就知道，GCP提供具HA的VPN服務)
可用度的SLA為99.99%，提供兩個Public IP給予另一端的VPN device。目前只支援BGP protocol。這需要啟用Cloud HA VPN gateway(Regional resources with two interfaces)
Classic VPN(沒有HA)
可用度的SLA為99.9%，只提供一個Public IP。支援Static Route(policy-based, route-based)與BGP。需要GCE的VPN gateway。

通常會使用VPN的方式，大都傳輸資料不太重要、網路穩定度與速度要求也不高的網路traffic。另外BGP 是由Cloud Router 支援的。

Cloud Interconnect(網路專線)

一般傳統的機房有些會設置兩個地點(主要與備援)。GCP也提共這一類的服務，用網路專線的方式，讓我們把地端機房與VPC連結起來。所以它提供高速、專用、低延遲的網路功能。而Interconnect分為以下兩種模式

Dedicated Interconnect

這一類的網路專線只有兩種網路效能選擇10 Gbps或100 Gbps。每一個網路連線(Network connection):

10Gbps x 8條線路=合併成80Gbps頻寬
100Gbps x 2條線路=合併成200Gbps頻寬

Partner Interconnect

如果我們的網路要求沒有哪麼高(50Mbps — 10Gbps)，哪就可以用這一種。這是GCP將網路專線業務委託給Local ISP。我們藉由Local ISP的線路路由到GCP的VPC中。

無論用哪一種網路專線，它的費用都會比Cloud VPN來得高。要使用這種連結方式，有一些限制需要注意(跟傳統地端機房一樣):

兩邊的IP網段不可以互相衝突
永遠都要有備援。有錢一點可以牽兩條專線，沒錢的可以用Cloud VPN當備援

最後一種，就是用BGP的方式來跟Google做BGP peering。但前提是你公司要夠大，不然Google應該不會理你。

Cloud CDN(Content Delivery Network)

Cloud CDN使用Google的global edge network來加速資料的傳送(它也是一種資料的快取)。它與External HTTP(S) Load Balancing(一種Proxy mode)直接整合。在其LB的設定中，到流量到達Google Front Ends (GFEs)後。CDN會檢查，如果 URL 對應到設定了 Cloud CDN 的backend(GCP的computing服務或Cloud Storage):

如果在快取中找到內容（cache hit），GFE 會發送快取回應
如果在快取中找不到內容（cache miss），則請求將轉發到後端（原始伺服器），回應將發送給使用者並快取f起來

我們可以設定TTL來決定快取內容的存活時間。

最佳實踐

一般快取分為靜態或動態:

靜態的範例如: Cache-Control：public，max-age=259200（72 小時）
動態的範例如:較小的緩存週期 — Cache-Control：public，max-age=300（5 分鐘）

但我們最好使用custom cache keys來增加cache hit ratio。預設的 cache key是整串URI的，例如: http://jasonkao.com/jason-image/jason.jpg。如果完全沒有對應到整串網址:

https而不是http — -發生cache miss
http://jasonkao.com/jason-image/jason.jpg?mobile=1(網址字串不符)也會cache miss

而Customize cache key就會是 protocol/host/query string的任何組合。而我們也可以對URL有版本控管，例如:

Cloud DNS

這是GCP提供的全託管DNS服務。其功能與AWS Route53是一樣的，但是沒有Route53哪麼多有的沒的附加功能。