英文原文：Practical VPC Design
在雲計算的基礎架構領域，沒有比從一開始就正確地布局VPC（虛擬私有雲）IP地址更重要的事情了。VPC的設計對於系統的伸縮性，容錯性以及安全性都有深刻的影響。它也直接影響到基礎架構的靈活性：如果你走進了一個死胡同，將來就可能要花費大量的時間做跨子網實例（instance）遷移來釋放地址空間。
幸運的是，如果記住了幾個原則，正確地布局VPC就容易了。
子網
正確的子網布局是VPC運行良好的關鍵。子網決定路由 、可用區（AZ）的分布和網絡訪問控制列表（NACLs）。
我觀察到圍繞VPC子網劃分最常見的錯誤，是像對待數據中心網絡那樣對待VPC。VPC不是數據中心，不是交換機，更不是路由器，雖然它執行了全部這三項工作。VPC是一種軟件定義網絡，對大量數據包遷入、遷出和跨AWS區域（region）遷移進行了優化。在發起端撿起數據包，然後在其目的地丟下數據包，就這麽簡單。
就是由於這個簡單性，許多數據中心和網絡設備存在的問題在一開始就被解決掉了。
歷史回顧：
90年代時，建造數據中心時使用的是10Mb/秒的以太網交換機。以太網用地址解析協議（ARP）進行廣播，確定交換結構中數據的相應位置。因此，網絡分段與廣播域中主機的數量大致成正比。因此，超過幾百臺主機的網絡段，性能就會降低。再加上IPv4子網公式的反直觀性，導致了在實踐中不同的網段都使用24位的子網。三個字節的地址，在全部約束條件下似乎是最佳選擇。
這種思維不適用於雲環境。VPC既不支持廣播，也不支持多播。就像ARP之於OS，廣播和多播可以非常優雅的使用SDN實現。考慮到這一點，就沒有任何理由將一個VPC劈成一些24位的子網。事實上，不這樣做的重要的原因在於：浪費。因為254（或128或64或32或16）個地址的“中間層”子網，只能有四個中間層主機，其它工作負載都用不到其余的地址。
相反，如果你有一個多用途的子網，可容納4094個地址的話，那麽你可以根據每個末位IP進行自動分組等等工作，這樣一來盡可能的擴大子網就變得十分必要，這樣做可以讓你在龐大的地址池中得以自由地進行動態分配。。
一般來說，創建一個子網主要出於三個原因：
1. 不同的主機需要用不同的的路由方式（例如，內網主機與公網主機）
2. 出於容錯的目的，需要在多個AZ之間分配負載。這項工作應該持續不斷地進行。
3. 特定的地址空間由於安全的原因需要授權NACL（例如，駐留客戶個人身份信息數據庫的網段）
讓我們依次分析一下這些因素。
路由
VPC中的所有主機都可以通過路由與同一個VPC內的其他主機連接。唯一真正的問題在於：允許什麽樣的數據包可以在VPC中進出。
事實上，可以輕松地建立一個禁止任何數據包進入或離開的VPC。只要建立的VPC不存在互聯網網關或虛擬專用網關，就可以有效地將其隔離為孤島了。
VPC不產生任何網絡流量那還有什麽價值。假設，你有一個使用互聯網的應用，在添加了互聯網網關，並為主機指定了一些彈性的IP地址以後，是否就能公開訪問了？不，並非如此。你還需要創建一個路由表，其中默認路由要是互聯網網關。然後對一個或多個子網應用該表。之後，這些子網中的所有主機都將繼??承路由表。你需要創建一個路由表，將Internet網關作為默認路由，然後你需要將該表格應用於一個或多個子網中，之後所有子網內的host都會繼承該路由表屬性。任何指向VPC外被block的IP地址的都需要經過Internet網關，這樣一來你的host就會被賦予回應外部通信的能力；即便如此幾乎沒有應用希望其所有的host都能被公開訪問。
事實上，完善的安全性決定了最小特權原則。因此任何不是絕對需要外部世界直接訪問的主機，都應不能直接從入口傳送流量。這些主機需要有更高一層不同的路由表。
一個子網只能有一個路由表（盡管路由表可以應用於多個子網）。如果希望一組主機與另一組主機用不同的路由，就需要創建新的子網，並對其應用新的路由表。
容錯
AWS以可用區（Availability Zones（AZ））的形式提供了開箱即用的geographic distribution，每個region至少有兩個AZ。
子網不能跨越多個AZs。因此，要實現容錯，需要在AZ中平均分配地址空間，並在每一個裏面分別創建子網。AZ越多越好：假如你有三個可用AZ，就將地址空間分成四份，並把第四分段作為備用。
平均劃分地址空間更加明顯的原因，是讓每個AZ的內部布局都是相同的。當創建諸如自動伸縮組等資源時，它們最好是均勻分布的。如果創建的地址塊是不連續的，必然給今後的維護留下了後悔不已的噩夢。
安全性
在VPC中，防禦措施的第一層已經得到解決：嚴格控制packet的出入。在路由層之上有兩個補充性質的控件：安全組和NACLs（網絡訪問控制表）。安全組是動態的，有橫跨整個VPC的狀態和能力；NACLs是無狀態的（也就是說你需要定義出入端口），靜態的和子網特有的。
一般來說，如果要在多組管理員之間分配變更控制的權限，就需要上述兩個控件。例如，可能讓系統管理員團隊控制安全組，而網絡團隊控制NACL。這樣一來，任何一方都不可能獨自突破網絡的限制。
在實踐中，NACLs應該謹慎使用，並且一旦被創建，就少去改動。因為他們是子網特定的，並與IP地址對應的，在此層管理流量的復雜度，將隨著附加規則個數的增加，成幾何級數地增加。
安全組是完成大部分工作的地方。除了前述的特定場合以外，應盡可能保持安全規則簡單明了，這樣能提供更好的服務。這樣的安全組才是最好的。
一個例子
以上只是一組抽象的準則。我想提供一個具體的例子來說明如何將它們結合在一起。
布局一個VPC最簡單的方法有下列幾個步驟：
1. 在盡可能多的AZ中平均分配你的地址空間。
2. 確定你所需要的不同種類的路由，以及每種路由相關的host數量。
3. 在各個AZ中按照每個路由的需求來創建大小相同的子網，賦予其相同的路由表。
4. 為了預防任何遺漏，留下一點未分配的空間。(相信我一次。）
因此在我們的例子中，將創建一個具有外部訪問網絡主機的，標準的n層架構應用。使用的地址空間是10.0.0.0/16。
最簡單地布局一個VPC地址空間時要忘掉IP範圍，而只從子網掩碼方面考慮。
以上述10.0.0.0/16地址空間為例。假設希望在美國-西部-2（us-west–2）地點運行全部三個AZ，以使Mongo cluster可以達到一個可靠的值。通過地址範圍實現這個需求是很討人厭的。相反，你可以簡單地說：“我需要四個分塊，三個AZ各對應一塊，另一塊備用。”因為子網掩碼是二進制的，屏蔽碼中每增加一個比特就將空間除以二。所以四個分塊，就要增加兩個比特，16比特將變成四個18比特。
10.0.0.0/16:
10.0.0.0/18?—?AZ A
10.0.64.0/18?—?AZ B
10.0.128.0/18?—?AZ C
10.0.192.0/18?—?Spare
現在你要決定在每個AZ內部的公共子網，私有子網和備用容量。能夠公開訪問的主機數量應該遠遠少於只能內部訪問的數量，於是決定將私有子網一半大小的空間分配給公共子網。想要創建一個獨立的地址空間，只需繼續增加bit。即：
10.0.0.0/18?—?AZ A
10.0.0.0/19?—?Private
10.0.32.0/19
10.0.32.0/20?—?Public
10.0.48.0/20?—?Spare
隨後，如果你想要在NACL中增加一個“受保護的”子網，只要再次從備用空間中劃分出一塊即可：
10.0.0.0/18?—?AZ A
10.0.0.0/19?—?Private
10.0.32.0/19
10.0.32.0/20?—?Public
10.0.48.0/20
10.0.48.0/21?—?Protected
10.0.56.0/21?—?Spare
需要確保你在一個AZ中做過任何事情，都在所有其他AZ中重復一遍：
10.0.0.0/16:
10.0.0.0/18?—?AZ A
10.0.0.0/19?—?Private
10.0.32.0/19
10.0.32.0/20?—?Public
10.0.48.0/20
10.0.48.0/21?—?Protected
10.0.56.0/21?—?Spare
10.0.64.0/18?—?AZ B
10.0.64.0/19?—?Private
10.0.96.0/19
10.0.96.0/20?—?Public
10.0.112.0/20
10.0.112.0/21?—?Protected
10.0.120.0/21?—?Spare
10.0.128.0/18?—?AZ C
10.0.128.0/19?—?Private
10.0.160.0/19
10.0.160.0/20?—?Public
10.0.176.0/20
10.0.176.0/21?—?Protected
10.0.184.0/21?—?Spare
10.0.192.0/18?—?Spare
路由表是這樣的：
“Public”
10.0.0.0/16 ?— ?Local
0.0.0.0/0? —? Internet Gateway
“Internal-only” (ie, Protected and Private)
10.0.0.0/16? — ?Local
創建這兩個路由表，把它們應用到每個AZ中正確的子網，然後就大功告成了！
如果團隊中有人擔心空間不足，就給他看這個表：
16-bit: 65534 addresses
18-bit: 16382 addresses
19-bit: 8190 addresses
20-bit: 4094 addresses
很顯然， Web 服務器不需要用4000個IP地址。這還不是問題的關鍵，關鍵是此VPC只有那些路由需求。沒有理由在同一個AZ內部，沒有子網有不同的路由需要時，再創建新的子網。
結論
適當地應用本文建議的規劃方法，就可以確保不會由於起始的決定，在實施時捆住了手腳。這裏談到的一切 - 安全組，自動伸縮，彈性負載均衡，亞馬遜關系數據庫服務，AWS直接連接，甚至更多——這些都可以套用在該模式中。（ 文 / Nathan McCourtney：任職於亞馬遜網絡服務公司AWS，曾擔任高級咨詢師，現為軟件開發工程師。
Tags: 子網 VPC 數據中心 amp 網絡 地址
文章來源：