英文原文：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，曾擔任高級咨詢師，現為軟件開發工程師。