本文主要分享了AWS高級網絡專項認證考試（Advanced Networking Specialty - ANS）的備戰及考試經驗，同時對AWS網絡相關服務進行REVIEW，分析其主要特點和一些應用限制；最後對AWS戰略做簡要分析，討論一下對運營商及企業網絡的影響。
2個月前正好有一些時間，決定樹立個目標、優化一下自己的知識結構。在網上轉了半天，初步選定AWS高級網絡專項認證考試。
先簡單介紹一下本人的專業背景：從事數據通信領域多年，開發過路由器平臺軟件和協議模塊，幹過解決方案銷售，參與過很多運營商IP網絡建設，對主流數通協議及網絡方案是比較瞭解的。3年前開始接觸IT和雲計算，2015年把WEB技術體系囫圇吞棗地過了一遍，包括前端HTML/JavaScript、AJAX以及後端的JSP/Servlet、Tomcat、Spring/Struts、Hibernate、MySQL、JAX-RS 等，當然這些都是利用業餘時間學着玩的，只瞭解一些基本概念、編過一些小程序。後來朋友推薦玩一玩AWS，經過半年多的胡亂摸索（第一次通過SSH登陸EC2主機都有很強的挫敗感），2017年初通過了AWS解決方案架構師（助理級）和AWS開發者（助理級）的認證考試。2017年下半年把比較流行的開源軟件框架都安裝過一遍，包括OpenDaylight、QEMU/KVM、OVS、OpenStack/Python、Docker、Kubernetes及Hadoop等。總的來說，從雲計算的技術體系到業務應用，已經建立了初步概念和感性印象。
AWS 高級網絡專項認證，是亞馬遜2017年新推出的認證項目，重點考察面向企業混合雲場景下的連接、路由、可靠性、容錯、安全、加密、域名解析、CDN、目錄服務、各種雲服務對網絡的需求（VDI、容器、RDS、大數據、數據庫遷移等）、自動化部署與運維、效率與成本、風險及合規等與網絡相關的知識，涉及面比較廣、有一定深度。考試內容以場景爲主，注重考察運用知識解決實際問題、而非知識點本身，170分鐘時間共65道選擇題（單選及多選），每道題介紹一個業務場景，你需要在2分半的時間內理解問題、建立模型、做出選擇。我們通過2道模擬題，看一下試題風格：
關鍵知識點：VPC Peering不支持Transitive Routing；Client-to-Site V_P_N爲Client分配IP地址、做NAT；一般來說NAT只支持單向連接。正確答案爲B。
關鍵知識點：Mumbai和Singapore距離美國東岸距離較遠、時延較大，應該在亞太建立Transit Hub VPC；VPC Peering不支持Transitive Routing，需要V_P_N over VPC Peering，連接2個Transit Hub VPC；跨Region的VPC Peering，AWS自動提供加密，無需採用IPSEC V_P_N，採用GRE隧道效率更高（我第一次做這道題，把Mumbai當成了Miami，整個題都理解錯了）。正確答案爲B。
網上很多人都反饋AWS ANS認證考試比較難，可能是AWS 的9個證書中最難考的一個；美國有一位老兄手裏拿了6個AWS證書（3個助理級 – SA、Developer、SysOps，3個專業級 – SA、DevOps、Big Data），挑戰了3次才通過AWS ANS認證考試。現在回頭分析這個事，我覺得主要原因如下：
1）ANS是2017年新推出的認證項目，通過的人不多，相對其它AWS認證項目，網上各種ANS模擬題庫的質量不高。我在備戰ANS認證考試過程中一共做了800多道模擬題（主要來自Official Study Guide和WhizLabs，很多題目都是拷貝的），而在實際考試中基本一道題也沒有遇到過，因此這個考試就是在考察你的真實水平。
2）網絡就是要複雜一些，連接了各種雲服務和On-premises，涉及到端到端網絡和各種組件，正常情況下你感覺不到它的存在、出了事兒可能全是它的問題；如果對網絡一些核心概念理解不透徹的話，場景稍微調整一下，在遇到壓力的情況，腦袋可能就亂了。
3）現在企業中從事雲計算應用的人員多數來自IT和軟件，從IP轉過來的不多，不同背景的人對AWS ANS認證考試難度的感知自然會有差異。我個人的體會是，IT和軟件涉及面很廣，而IP是比較複雜的。
在網上做了調研之後，當時心理還是有一定壓力的，我行不行啊、這個要投入多少時間？但客觀分析一下，這個認證考試就是爲我這種從IP轉入IT和雲計算的人設計的，如果我都不敢去挑戰，還指望誰呢？我到底算不算專家啊，會考試的人不一定是專家，但真專家應該是不會懼怕這種實戰性強的考試。最終下定決心，上！
目標定下來後，就是堅定不移地執行，接下來的8個星期過得是比較辛苦的，幾乎把所有能利用上的時間都利用上了，“理論學習 – Lab – 模擬題練習 – 總結”，俄羅斯世界盃期間一場足球比賽也沒看。有一天突然收到公司HR的電話 – “薛老師，你上個月加班150個小時、沒事吧”，我說“沒事兒，宿舍沒空調、辦公室涼快、自己看看書啥的”。
我總共看了幾千頁的材料，記了200多頁的筆記，但仍感覺信心不足、預定參加考試的時間也一拖再拖，不僅僅是因爲300多美元報名費的問題，主要擔心如果考不過會影響自信心，畢竟咱是公司的專家。準備到後來都有些厭倦了，材料開始看不進去了、並且找不到大塊的新知識點，時間不能再拖了，於是就報名了8/7的考試。
儘管事先做好了充分的思想準備，考試過程還是非常緊張和刺激，時間飛速流逝，有些題就是看不懂、急得直跺腳，總盼着下一道題能簡單點兒、贏回來一些時間，頭腦中曾出現放棄的念頭（隨機選答案就交卷了），最終hold住了，只要還有一分鐘時間、就要全力以赴去讀題做題。ANS ANS認證考試不僅僅是考察你的專業知識，還包括你的心理素質和意志力，在有限時間和環境壓力下能否穩定發揮。
我用了140分鐘答完了65道題，對其中18道做了標記、屬於拿不準的，然後就用剩下的30分鐘對這18道題進行REVIEW，修改了部分題目的答案。在交卷前的一刻，其實人已經比較放鬆了，過去2個月無論是準備階段還是考試現場，我都做了詳細的策劃、盡了自己最大的努力，也系統地提升了自己在雲計算和網絡結合方面的專業水平，無論結果如何，都沒有遺憾；如果過不了，那就是自己水平不行，或者實踐不到位。點擊鼠標後等待片刻，屏幕顯示：
“Congratulations，you have successfully completed AWS Advanced Networking – Specialty exam…”
我當時心理有些犯嘀咕，complete考試有啥好祝賀的，難道還有人不能complete，我到底有沒有pass啊？離開考場後打開手機，收到了AWS的郵件：
通過了，成績爲84%（及格線通常爲65%~70%），結果還是很不錯的，這說明之前自己揹負了過多的思想負擔、備戰工作有些overly prepared了。實際上認證考試只要能通過就OK了，工作與考試還是有很多區別，考試成績每提升1%都要付出額外的努力和時間，利用這些時間學些新東西或者享受一下生活不是更好嗎！
雲計算並非我的本職工作，過去3年我投入了大量的業餘時間學習雲計算的相關技術，同時在工作中創造各種條件去實踐，我對自己當前取得的進展是滿意的。從當初對雲計算一無所知、人云亦云，到逐漸能夠形成一些自己的觀點並通過AWS ANS這種專業級的雲計算認證考試，我切切實實感受到了自己的進步與成長；並且這種進步是源於自己爲應對未來的挑戰所作出的積極改變，收穫的不僅僅是信心，而是未來廣闊的空間。
接下來我通過3個維度分享一下本次參加AWS ANS認證考試的經驗與心得體會：
1）AWS ANS認證考試的備戰與考試經驗；
2）AWS網絡相關服務REVIEW，主要特點與一些應用限制；
3）AWS戰略的簡要分析。
一、AWS ANS認證考試的備戰與考試經驗
主要採用的學習材料：
閱讀材料 | AWS Certified Advanced Networking Official Study Guide，31.99$，Amazon上有賣； AWS官網上各種雲服務使用指南、FAQs、白皮書和博客； 平時用Google查閱一些知識點； |
培訓視頻 | A Cloud Guru上的ANS培訓視頻（主用），訂閱費29$/月、前7天免費： https://acloud.guru/learn/aws-certified-advanced-networking-specialty Linux Academy上的ANS培訓視頻，訂閱費49$/月、前7天免費： https://linuxacademy.com/amazon-web-services/training/course/name/aws-certified-networking-specialty AWS re:Invent 2017的網絡相關視頻（主用）： https://www.youtube.com/playlist?list=PLhr1KZpdzukewxjrgeVIGw49tiIbkqt0Z 網友整理的AWS ANS相關視頻：https://www.youtube.com/watch?v=SMvom9QjkPk&list=PLlkukGgpsXyvUbJ85RVD7qNJ1mcGKO4_w&index=1 |
模擬題 | Official Study 提供的ANS Practice Test，200多道練習題，隨書贈送： https://testbanks.wiley.com/WPDACE/Dashboard Whizlabs提供8套ANS Practice Test，600多道練習題，29$： https://www.whizlabs.com/aws-advanced-networking-speciality/ |
Lab | 主要用AWS Management Console； 寫了一些簡單的Python Web程序，運行在EC2實例上，做測試用； 採用PuTTY登陸EC2實例，需要配置穿越公司的代理服務器。 |
結合個人情況制定的學習計劃：
Week 1,2,3,4 | 1）看培訓視頻； 2）閱讀Official Study Guide（2遍），完成了主要的課後實驗； 3）溫習、學習了一些背景專業知識，包括： - 對稱加密與非對稱加密、數字簽名、CA證書、SSH、SSL/TLS、HTTPS、IPSEC/IKE； - 正向代理/反向代理/HTTP代理/Socks代理，DHCP、DNS、CDN； - LDAP與Active Directory、SAML/OIDC、SSO； - KVM及XEN虛擬化，SR-IOV/DPDK，Dockers及Kubernetes的網絡技術； - JavaScript和AJAX、Tomcat與Servlet、Cookies與Session，等等。 |
Week 5,6,7 | 完成了800多道模擬題的訓練，進行總結，加深理解。 |
Week 8 | 閱讀Official Study Guide（第3遍），複習200多頁的學習筆記； 重點補做了一些實驗、看了一些視頻。 |
1）備戰期間要堅持鍛鍊身體，調整好競技狀態； 2）AWS ANS認證考試的信息量比較大，平時要做好筆記，定期複習； 3）考試期間沒有太多時間思考，對於一些主流的業務場景，如VPC路由選擇、Hybrid DNS主要場景及方案、Transit Hub VPC方案的主要變種、EC2實例V_P_N網關的水平及垂直擴展方案等，要做好歸納總結、能夠舉一反三。 |
考試預約與參加考試的注意事項：
考試預約 | 參加ANS認證考試前，應先通過一門AWS助理級認證（SA、Developer或SysOps）； 到AWS網站上進行考試預約，支付318美元： https://www.aws.training/certification 建議選擇英文考試，AWS中文資料翻譯的不好、經常會有歧義； 我選擇的考點是：深圳市羅湖區深房廣場1903室，下午1:30考試。 |
參加考試： | 攜帶2個帶照片的個人ID，考點提供安全櫃，可以存放個人物品； 進入考場後不能攜帶任何物品，可以管考試中心的工作人員要一些紙和筆； 計算機考試，電子監控，周邊一圈攝像頭； 考試過程中用腦強度會比較大，事先要確保充足的睡眠和能量，調整好心情； 考試期間允許上廁所，可以準備1瓶水放在去廁所的路上。 |
二、AWS網絡相關服務REVIEW
AWS的英文文檔做的非常好，爲各個服務提供了很詳細的使用指南及FAQs，但涉及到關鍵技術實現時往往一筆帶過，這是我在準備AWS ANS認證考試過程中遇到的主要障礙。在不清楚其具體實現原理的情況下，很多知識點就要靠人爲記憶了，這是一件很不爽的事情。針對一些關鍵服務的實現，我參照了開源軟件的實現方案以及網上的討論，同時結合過去的研發經驗，爭取能夠畫出模型、加深理解、簡化記憶。下面討論AWS網絡相關服務的部分重要及難點問題，來自我備戰期間整理的學習筆記。
VPC轉發邏輯與Transitive Routing
VPC應該是通過SDN及Overlay方案實現的，不支持Multicast和Broadcast，Subnet內部轉發、Subnet之間轉發、EC2實例到各類服務網關（IGW、VGW、NAT、DNS等等）的轉發，都是一跳完成的。
VPC對報文轉發邏輯做了重要的限定：如果一個報文的源地址不是對應本VPC內部的一個接口，則該報文的目的地址一定是對應本VPC內部的一個接口；報文的源地址或者目的地址至少有一個是對應本VPC內部的接口，否則報文就要被丟棄。
這個轉發邏輯的制定 – VPC不支持Transitive Routing，應該主要是考慮到AWS雲端網絡的安全性及可靠性，比如說避免租戶設計的VPC網絡出現環路問題、避免源地址欺騙。VPC不支持Transitive Routing，會影響到AWS雲端網絡設計的方方面面，提升了整體方案的複雜度，這也是與傳統On-premises網絡區別最大的地方。以下表格是我根據AWS的官方文檔和Lab整理出來的：
VPC內部各類服務網關 | EC2 實例 | IGW與 EIGW | VGW | VPC Peering | Gateway VPC Endpoint | Interface VPC Endpoint | VPC DNS | EFS | NAT網關與實例 |
在本VPC內部訪問 | V | V | V | V | V | V | V | V | V |
通過VPC Peering接入後訪問 | V | X | X | X | X | \X 僅支持來自同一Region 其它VPC的部分實例的訪問 | X | X | X |
通過Direct Connect接入後訪問 | V | X | V CloudHub | X | X | V | X | V | X |
通過V_P_N Connection接入後訪問 | V | X | V CloudHub | X | X | X | X | X | X |
IGW/EIGW、VGW、VPC Peering和Gateway VPC Endpoint在VPC內部都不存在ENI接口，只能在VPC內部訪問。
VPC DNS雖然可以通過“VPC CIDR+2”的地址進行訪問，但在VPC內部並不存在ENI接口（應該是VPC路由器直接截獲DNS報文、轉發給AWS-Managed DNS服務），所以只能在VPC內部訪問。
對於Interface VPC Endpoint及EFS，它們在VPC內部都有ENI接口及IP地址，正常情況下與在外部訪問EC2實例沒有區別，AWS應該是基於商業考慮和技術約束做了一些訪問限制。
對於NAT GW和NAT實例，它們在VPC內部都有ENI接口及IP地址，但它們處理的報文都是要訪問Internet的（並非訪問NAT設備本身），由於VPC不支持Transitive Routing，只能在VPC內部訪問。
在AWS平臺上實現Transitive Routing需要採用Overlay的方案，將從VPC外部對VPC內部各類服務網關的訪問/穿透，轉換爲在VPC內部發起請求；針對每一類服務網關，都要採用與之對應的解決方案。
針對VPC DNS的Transitive Routing問題，可採用AWS-Managed SimpleAD、Active Directory或自己部署Unbound，實施Conditional Forwarding。
針對IGW及NAT的Transitive Routing問題，需要採用EC2實例終結V_P_N隧道、做NAT轉換（將報文源地址轉換爲VPC CIDR的地址），纔有可能訪問VPC的IGW及NAT。
針對VPC Endpoint的Transitive Routing問題，需要在HTTP應用層實現，具體可以採用2種方案：
1）反向代理（代理服務）：在VPC內部部署ELB及Proxy Farm，通過修改DNS，將VPC外部對服務網關的訪問轉換爲先訪問ELB，在由ELB及Proxy Farm訪問服務網關。
2）正向代理（代理客戶），在VPC內部部署ELB及Proxy Farm，在客戶端配置ELB作爲代理服務器，客戶端先連接ELB，在由ELB及Proxy Farm訪問服務網關。
VPC 的本地路由
VPC Local Route主要用於VPC內部的轉發、確保所有資源之間的通信，不能被修改，不能用more specific route進行覆蓋。如果你想配置軟件防火牆用於過濾Subnet之間的轉發流量，你無法改動VPC Local Route，但可以通過改動EC2實例OS的路由配置間接實現。
可以在VPC路由表中增加比VPC CIDR範圍更大的Destination。
ENI接口
EC2實例的主接口，無法從實例分離。ENI可以在某Subnet中動態創建，代表虛擬網卡，可以與EC2實例動態綁定（EC2實例所在Subnet與ENI所在Subnet必須在同一AZ內），也可以從一個實例分離並重新綁定到另一個實例。ENI接口可以用於網管網、主備倒換以及虛擬防火牆等。
EC2實例支持ENI接口數量有限，不支持NIC Teaming。
跨賬戶網絡接口：
A賬戶某VPC及Subnet的EC2實例，動態綁定B賬戶某VPC及Subnet中的ENI，EC2實例與ENI需要在1個AZ內；主要用於AWS管理的服務與租戶VPC之間的訪問，包括RDS（AWS管理數據庫、租戶使用數據庫）、Lambda（AWS提供計算資源、訪問租戶VPC）及Workspaces等。該方案的擴展性及可靠性一般。
受控使用，租戶要使用這個功能，需要白名單控制。
ENI接口的Source/Destination Check
與VPC轉發邏輯不支持Transitive Routing的原因類似，EC2實例的ENI接口發送/接收報文時，要做Source/Destination Check：發送報文時，報文的源地址必須是自己的IP地址；接收報文時，報文的目的地址必須是自己的IP地址；否則報文就要被丟棄。當EC2實例提供NAT、V_P_N、Firewall等功能時，接收和發送的報文通常都不是自己的，因此要禁止Source/Destination Check。
安全組
安全組作用於ENI接口。安全組的Inbound規則，端口是自己的、源IP地址是遠端的；安全組的Outbound規則，端口是遠端的、源IP地址是遠端的。安全組，只需要配置Allow。
默認安全組，通過配置自引用規則，實現可以接收來自配置了同一安全組的實例的報文、允許發送所有報文。新建的安全組，開始時禁止接收報文、但可以發送所有報文。
安全組是有狀態的，只要允許報文進入、就允許報文離開，無論Outbound規則是如何配置的；反之亦然。如果針對某些端口，允許進出所有的流量，安全組就不需要維持狀態了。
由於AWS內部的技術實現，對於已經存在的連接，刪除對應的安全組後，通信不會中斷、仍會持續若干天，因此必須要配置網絡ACL。
網絡ACL
網絡ACL作用於Subnet。網絡ACL的Inbound規則，端口是自己的、源IP地址是遠端的；網絡ACL的Outbound規則，端口是遠端的、源IP地址是遠端的。網絡ACL需要顯示配置Allow及Deny規則，按照規則順序進行匹配。
默認ACL，通過在Inbound和Outbound方向配置100號規則，可以發送和接收所有報文。新建的NACL，開始時禁止接收和發送所有報文。
網絡ACL是無狀態的。
IGW、NAT網關/實例和EIGW
NAT網關/實例，只是將報文的源地址轉換爲自身ENI接口的地址（私有地址），用源端口號來區別不同的用戶流；IGW最終將報文的源地址（私有地址）轉換爲公有IP地址或彈性IP地址，是1:1轉換。
NAT網關，是AWS Managed的服務，你不能做任何改動，不能配置其ENI接口的安全組，不能配置Predefined端口、允許外部訪問內部。NAT網關要部署到Subnet級別，性能可以自動伸縮、到45Gps。
NAT實例，可以採用第三方軟件、需要禁止Source/Destination Check。NAT實例的安全組可以配置，Inbound規則實際上意義不大，因爲收到的報文都不是要訪問NAT實例本身的。
EIGW，是爲IPV6業務提供類似IPV4 NAT的體驗，VPC內部可以訪問Internet、Internet不能訪問VPC內部，但不做地址轉換；EIGW部署在VPC級別、非Subnet。
VPC路由優先級
VPC的靜態路由配置是不能出現衝突的，既前往同一個Destination不能有2個Target，但是靜態路由與動態路由之間是可以衝突的，這就涉及路由優先級的問題。AWS網絡有2個位置，需要做出路由選擇，分別是VPC和VGW。
VPC有多個路由來源，包括本地CIDR、靜態配置、VGW動態注入。VPC的路由選擇優先級爲：本地CIDR路由，最長匹配路由（無論來自哪裏），靜態路由（前往某Destination，Target分別爲IGW、VPC Peering、VGW、NAT、ENI等），通過Direct Connect注入的BGP路由（Target爲VGW），V_P_N靜態路由（Target爲VGW），通過V_P_N Connection注入的BGP路由（Target爲VGW）。
VGW也有多個路由來源，包括綁定VPC的CIDR、在V_P_N Connection上配置的靜態路由、通過BGP協議及多個Direct Connect及V_P_N Connection對等體動態學習的路由。VGW的路由選擇優先級爲：本地CIDR路由、最長匹配路由、通過Direct Connect學到的BGP路由、V_P_N靜態路由、通過V_P_N Connection學到的BGP路由。
VGW內部多個Direct Connect或多個V_P_N Connection存在多條BGP路由衝突時，BGP的路由選擇優先級爲：Weight（Highest Wins），Local_Pref（Highest Wins），聚合路由，AS_Path（Shortest Wins），Origin（IGP-EGP-Incomplete）、MED（Lowest Wins）等。
VGW通過BGP over Direct Connect 或 BGP over V_P_N Connection學到路由後，可以動態注入到VPC路由表，也可以在VPC路由表中配置靜態路由、Target指向VGW。
VPC Endpoint
主要是出於安全及合規考慮，訪問AWS公有服務時，不走Internet。主要分爲2類：
Gateway VPC Endpoint，早期的技術實現，主要針對S3和DynamoDB，將這些AWS服務的公網路由注入VPC及Subnet的路由表中（用PL-xxxxxxxx標識、作爲Destination），VPC Endpoint作爲Target（用vpce-xxxxxxxx標識，應該是提供NAT功能）。可以在VPC Endpoint配置IAM策略，能夠訪問哪些S3 Bucket；也可以在S3 Bucket配置IAM策略，能夠被哪些VPC或VPC Endpoint訪問，不能採用基於源IP地址的策略。此外在安全組也可以引用PL-xxxxxxxx、配置策略，網絡ACL中不能引用PL-xxxxxxxx。
Interface VPC Endpoint，最新的技術實現，基於AWS PrivateLink技術，針對EC2、ELB、Kinesis等，爲這些AWS服務在Consumer VPC增加了一個或多個ENI接口及IP地址，同時爲這些ENI接口提供Region及Zone的DNS域名（公網可解析、返回私網IP地址），也可以在Consumer VPC內部將標準AWS服務域名（如：ec2.us-east-2.amazonaws.com）解析爲這些ENI接口的私有IP地址。
通過PrivateLink技術，我們自己也可以對外發布Endpoint Service：在Provider VPC創建Network ELB及Back-end服務器、基於ELB創建Endpoint Service；在Consumer VPC創建Interface VPC Endpoint、引用Provider VPC的Endpoint Service。
因爲Network ELB只支持TCP，所以AWS PrivateLink只支持TCP。
VPC Peering與AWS PrivateLink
VPC Peering適合於2個VPC之間的多個EC2實例之間的雙向通信，最多支持125個Peering；PrivateLink適合於單向通信，可以支持數千個Consumer VPC。
同一Region的VPC Peering，可以引用對端的安全組，並且可配置將對端的公有DNS域名解析爲VPC內部的私有IP地址（非彈性IP地址或公有IP地址）。採用VPC Peering後，並不能自動訪問對端VPC關聯的Route 53私有託管區，仍需要顯示關聯。跨Region的VPC Peering，AWS自動提供加密。
V_P_N
Site-to-Site V_P_N，採用VGW，也可以自己在EC2實例上運行V_P_N軟件、需要禁止Source/Distination Check。
CGW主要向VGW建立連接；CGW如果部署在NAT設備後面，需要支持NAT-T功能（這是IPSec的特性，將IPSEC ESP報文封裝成UDP報文、端口爲4500）。
1個V_P_N Connection、2個IPSec Tunnel，通過路由策略實施Active/Active或Active/Passive：
VGW –> CGW流量，CGW向VGW發佈路由時採用BGP的 最長匹配路由、AS_Prepend或MED等策略；
CGW -> VGW流量，CGW向on-premises內部網絡發佈路由時採用BGP的Weight或Local_Pref等策略。
EC2實例V_P_N網關的HA方案：運行2個EC2實例作爲IPSEC網關、建立隧道，其中EC2-1個作爲on-premises路由的Target；運行自動化腳本，發現問題，修改VPC路由表、實現切換，選擇EC2-2作爲on-premises路由的Target。
EC2實例V_P_N網關的垂直擴展方案：EC2 Instance1（做ELB） 與3個EC2 Instance（處理IPSec）之間運行BGP。
EC2實例V_P_N網關的水平擴展方案：按照不同的Prefix來分離IPSec網關，192.168.0.0./17走EC2 Instance 1，192.168.128.0/17走EC2 Instance 2。
Client-to-Site V_P_N，只能自己在EC2實例上運行V_P_N軟件，通常還要爲Client提供認證、IP地址分配及NAT等功能。
Direct Connect
AWS與全球上百家區域運營商合作，將PoP點下移，採用DX Router就近進入客戶。2種接入方案：
1）光纖直連，DX Router – Dark Fiber – CGW，支持1Gbps和10Gbps；
2）藉助於運營商網絡，DX Router – MPLS PE ………MPLE PE – CGW，支持50~500Mbps。
專用連接，Dedicated Connection，可配置多個VLAN（多個VIF），客戶負責LOA-CFA；客戶需要支付端口小時費。託管連接，Hosted Connection，只對應1個VLAN（1個VIF）、由運營商指定，運營商負責LOA-CFA，客戶也需要支付端口小時費。
CGW通過DX Router及Private VIF，連接到VGW，運行BGP，在VPC及On-premises之間交換路由；VPC只會向CGW宣告其CIDR路由，非其它靜態配置或動態注入的路由；CGW最多向VGW發佈100條路由。
CGW通過DX Router及Public VIF，連接到AWS Internet，運行BGP，通過Community屬性控制On-premises路由的傳播範圍（本Region、本Continent、全球），以及CGW學習AWS Internet路由的範圍（本Region、本Continent、全球）。CGW最多向AWS Internet發佈1000條路由，AWS Internet不會爲On-premises的公網路由提供Transit服務；如果CGW採用私有ASN，AS-Prepend不會起作用。
託管VIF，Hosted VIF，可以是Public VIF，也可以是Private VIF（接收者綁定VPC）。Hosted VIF的流量相關費用，由接收者承擔；端口小時費，由Owner承擔。
VGW可以作爲CloudHub，爲V_P_N Connection及Direct Connect等接入方提供路由及轉發。
CGW通過DX Router及Private VIF連接到Direct Connect Gateway後，可以連接到跨Region的多個VGW。Direct Connect Gateway的控制平面，提供類似BGP路由反射器的功能；其轉發平面，完成CGW與多個VGW之間的流量交換（非VGW之間、非CGW之間）。
CGW通過DX Router及Public VIF接入AWS Internet後，可以再與VGW之間建立V_P_N Connection。
CGW通過DX Router及Private VIF接入VPC後，可以再與VPC內部的EC2實例之間建立V_P_N Connection。這時通常需要CGW支持Tunnel VRF功能：創建VRF，在VRF內部通過DX Router及Private VIF接入VGW和VPC，學到EC2實例V_P_N網關的路由；然後在CGW的主路由表中，創建隧道（隧道的Source及Destination爲VRF的地址空間），連接EC2實例V_P_N網關，再通過BGP交換業務路由。
VPC DNS與Route 53
在VPC發佈EC2實例後，自動提供公有DNS域名及私有DNS域名（enableDnsSupport爲TRUE、enableDnsHostnames爲TRUE），公有DNS域名在VPC內部解析爲私有IP地址。
VPC DNS服務，通過“CIDR+2”的地址訪問，自動爲Internet公有域名、VPC資源以及Route 53私有託管區（與VPC綁定）提供查詢服務。VPC DNS服務，不能被VPC外部訪問（通過VPC Peering、V_P_N、Direct Connect等），不可更改配置。
Hybrid DNS存在多種解決方案：
1）Simple AD是AWS提供的AD管理服務，自動向VPC DNS轉發請求，不可更改配置、不能向On-premises轉發請求。通過配置DHCP Option Set，VPC EC2實例可以使用Simple AD的DNS服務；如果VPC也要解析On-premises的域名，有需求的EC2實例可以安裝Unbound、指向On-premises DNS服務器及VPC Simple AD。On-premises DNS服務器可以設置轉發、指向Simple AD，從而實現On-premises解析VPC資源的域名。
2）Microsoft AD是AWS提供的AD管理服務，可以進行配置，可以向VPC DNS及On-premises DNS轉發請求。通過配置DHCP Option Set，VPC EC2實例可以使用Microsoft AD的DNS服務，同時解析VPC及On-premises的域名。On-premises DNS服務器可以設置轉發、指向Microsoft AD，從而實現On-premises解析VPC資源的域名。
3）在VPC部署Unbound作爲DNS服務器、實施Conditional Forwarding，可以向VPC DNS及On-premises DNS轉發請求。通過配置DHCP Option Set，VPC EC2實例可以使用Unbound的DNS服務，同時解析VPC及On-premises的域名。On-premises DNS服務器可以設置轉發、指向Unbound，從而實現On-premises解析VPC資源的域名。
4）創建Route 53私有託管區、與VPC關聯，利用CloudWatch的定期事件以及Lambda函數，定期在Route 53私有託管區鏡像On-premises的DNS數據庫，相當於爲On-premises在VPC創建了Secondary DNS，實現VPC解析On-premises的域名。
Route 53提供域名註冊、DNS服務以及Health Check功能；Route 53公共託管區，是外部可見的；Route 53私有託管區與Route 53公共託管區共享全球的DNS基礎設施，但Route 53只響應關聯VPC對Route 53私有託管區的查詢，外部無法訪問，主要用於Split-Horizon DNS場景（相同的域名在VPC內部及VPC外部可解析出不同的IP地址）。
Route 53支持Alias記錄，相當於指針，對DNS Resolver提供等效於查詢A記錄的體驗；而採用CNAME，DNS Resolver要做2次查詢。不能爲Zone Apex增加CNAME記錄（DNS協議的要求），但Alias記錄可以。可以創建Alias的Alias – 指向指針的指針。在Route 53私有託管區創建Alias記錄時，不能指向Route 53公共託管區的資源。
用戶可能會選擇非常遠的DNS Resolver完成解析，會導致Route 53的各種路由策略失效。edns-client-subnet，是DNS擴展協議，允許DNS Resolver把用戶IP地址傳遞給DNS Server；DNS Resolver支持這個協議，Route 53纔會處理用戶IP地址。
Route 53 的Health Check可以對特定資源、CloudWatch的Alarm/Metric以及其它的Health Check進行監控；在創建DNS記錄時，可以指定Health Check（並不需要直接相關），從而實現利用Health Check的結果進行DNS查詢、躲開出現問題的資源。
ELB
ELB的大致原理：ELB是AWS-Managed VPC，在Consumer VPC的每個Subnet（需要顯示指定）都會創建1個或多個ENI、進行綁定
對於Internet-facing ELB，將ELB的公有域名解析爲彈性IP或公有IP地址（報文在IGW被轉換爲ENI的私有地址），在VPC內部解析也是這樣的，要求部署在Public Subnet。
對於Internal ELB，ELB的域名仍然是公有域名、但解析爲這些ENI的私有IP地址，可以部署在Public Subnet或Private Subnet。
由於ELB在動態伸縮期間會增加/減少ENI及私有IP地址、以及對應的彈性或公有IP地址，因此要求使用ELB的域名、不直接使用IP地址。NLB的ENI及IP地址是固定，可以直接訪問其IP地址。
CLB是第一代ELB服務，面臨EOX；CLB同時支持HTTPS/HTTP與TCP/SSL監聽器；SSL監聽器主要用於SSL Offloading，如果不處理SSL終結和CA證書，就採用TCP 443作爲監聽器；CLB的HTTPS/HTTP監聽器，在應用層HTTP的處理能力非常有限，只支持基本的Sticky Session、SSL Offloading等功能；不支持SNI。
SSL協商配置（安全策略），在客戶端與ELB之間進行SSL連接的協商，包括SSL協議、SSL密碼、順序首選項組合等。可以採用預定義安全策略，也可以自定義安全策略。
ALB是針對HTTP/HTTPS優化的服務，支持基於URL及HTTP HOST等進行負載均衡；支持SNI，單個IP地址承載多個SSL證書；如果採用目的IP，支持在VPC及ON-premises資源之間進行負載均衡。
NLB是針對TCP優化的服務，直接進行HASH、高性能；如果要求Back-end服務器處理SSL終結及CA證書，通常要使用NLB；如果採用目的IP，支持在VPC及ON-premises資源之間進行負載均衡。
ELB會修改IP報文的源地址，有2種方法，ELB可向Back-end服務器傳遞用戶IP地址：
1）Proxy Protocol，爲TCP添加了一個頭、傳遞用戶原始信息， CLB採用Proxy Protocol V1（文本格式），NLB採用Proxy Protocol V2（二進制格式）；
2）HTTP X-Forwarded_For，在HTTP頭裏面增加一個字段、傳遞用戶原始信息（Client IP、Proxy IP1…、Proxy IP2…），CLB和ALB採用。
NLB，可以保留用戶IP，這個功能可能是通過NLB與VPC Router及IGW深度融合實現的。
CLB和ALB支持配置安全組，實際上就是配置Consumer VPC中ENI接口的安全組，作爲Internet-facing ELB和Internal ELB時配置安全組的邏輯是不同的；NLB不支持配置安全組，可通過配置Back-end服務器的安全組間接實現。
CLB和ALB在動態伸縮過程中IP地址會發生變化，因此在配置Back-end服務器安全組策略時，應基於CLB和ALB採用的安全組（非IP地址）指定規則。
CLB和ALB支持Logs，NLB不支持Logs。
Connection Draining，在Auto Scaling期間，ELB停止向即將停止運行的EC2實例發送新的請求，但允許其處理完正在進行的會話，缺省爲300秒。
S3
S3 Static Web Hosting服務，只支持HTTP，返回HTML ，URL一般爲：http://xgf-bucket-1.s3-website.us-east-2.amazonaws.com/。
S3 API Endpoint服務，支持HTTP和HTTPS，返回XML，URL一般爲：https://s3.us-east-2.amazonaws.com/xgf-bucket-1。
CORS，跨域資源共享，S3 Bucket作爲Static Web Hosting時需要支持CORS，允許客戶訪問Bucket時，能夠實現跨域訪問（網頁中通過XMLHttpRequest引入一些其它網站的內容）。需要配置策略，允許在訪問本網站/網頁時，可以引入其它哪些網站的哪些操作GET/POST等。
S3 Transfer Acceleration，利用CloudFront的全球分發網絡，採用優化路徑下載/上載對象。首先在Bucket啓用Transfer Acceleration；採用新的WBB域名（非API域名）- “bucketname.s3-accelerate.amazonaws.com”，定位到最近的Edge節點，原理與CDN類似。
S3 Bucket和Object的IAM策略是分開配置的，用於Web Hosting時，要允許公開訪問。
S3 API Endpoint支持Signed-URL能力，大致原理如下：
1）外部通過HTTP訪問AWS時（特定URL），需要能識別出發送它們的客戶，包括驗證請求者身份、防止請求被改動、請求期限等。
2）將請求（URL代表某資源 – 圖片、網頁等），採用HASH做一個Digest，然後用“簽名密鑰”對Digest做一個“數字簽名”，然後放在HTTP Authorization頭中，或者以查詢字符串的方式放入URL中。
3）將Signed URL發放給客戶，客戶使用Signed URL進行訪問；AWS收到後，根據“簽名密鑰”進行解密得到了“原始Digest“，同時做一個“Digest”，如果一致就OK了（知道請求是否被改、以及是誰做的）。
Signed URL與Token的應用場景不同（在不擁有密碼的情況下）：Signed URL，讓“外面的人”在一段時間內訪問某“資源、服務”，用URL標識；Token，讓“外面的人”拿到臨時權限，在一段時間內訪問一組資源。
採用S3 Static Web Hosting服務時，如果使用別名，該DNS名稱必須和Bucket名稱相同，這是因爲S3 Static Web Hosting要爲多個賬戶的多個Bucket提供Static Web Hosting服務，它需要根據HTTP 報文頭中的HOST字段找到正確的Bucket。
CloudFront
CloudFront，屬於反向代理（代理服務器），利用了Route 53基於地理的路由策略，返回給請求者最近的資源。
CloudFront支持Web分發和RTMP分發。
CloudFront分發的域名與Origin的域名，是不同的。
通常做法，Origin處理動態請求，對網頁中的靜態資源交給CloudFront處理；也可以將動態請求、靜態請求全部交給CloudFront。
CloudFront，可以與S3、ELB、EC2及第三方服務器集成；與S3集成時，可以採用OAI實現CloudFront到Origin的訪問控制；與其它資源集成時，可以採用Custom HTTP header實現CloudFront到Origin的訪問控制；做到Origin不別其它CloudFront Distribution及非CloudFront資源所訪問。
提供私有內容時，可以採用Signed URL（針對單個文件）或Signed Cookies（針對一組文件），“簽名密鑰”一般是根據Private Key生成，而非Private Key本身。
使用CloudFront，會給你一個DNS域名，可以直接使用，也可以創建一個友好的CNAME記錄或Alias記錄（如果採用了Route 53），但必須要告訴CloudFront這個DNS域名，因爲Cloud Front要根據HTTP HOST字段信息（友好域名）判斷出請求報文屬於哪一個Distribution。
CloudFront與Viewer之間，可以採用HTTP、HTTPS或Redirect HTTP to HTTPS；CloudFront與Origin之間，可以採用Match Viewer、HTTP或HTTPS。需要在US East注入Certificate，自動擴散到全球所有區域。
Lambda@Edge，處理時機爲viewer request，origin request，origin response，viewer response；使用場景爲檢查cookie、重寫URL、動態修改Custom HTTP Header或進行A/B測試（新興的網頁優化方法，一部分客戶訪問A，一部分客戶訪問B，通過兩種方案的優劣）。
使用CloudFront的Geoblocking功能：使用GeoIP數據庫，確定用戶位置，準確率99.8%；在Web Distribution的Restrictions中，配置Geo Restriction中的Whitelist和Blacklist；如果不符合，CloudFront返回403（禁止）。
使用第三方地理定位服務（需要Origin服務器支持）：將內容上傳S3 Bucket，使用OAI，通過CloudFront提供私有內容；編寫Web應用程序，根據用戶IP，調用地理定位服務；如果允許，爲CloudFront分發的內容提供Signed URL（用戶請求抵達CloudFront後，判斷Signed URL）；如果不允許，返回403。
ACM – AWS Certificate Manager
AWS管理TLS證書的服務，支持CloudFront、ELS、Elastic Beanstalk和API Gateway等；可以創建CA證書，或導入你的證書到ACM中；ACM提供的CA證書，13個月有效，自動RENEW。ACM是Regional級別的，在各Region單獨處理；對於CloudFront的證書，需要在US East（NV）集中處理。
AWS WAF
WEB應用防火牆，與CloudFront和Application ELB集成，監控HTTP/HTTPS的請求，採用一些定製化的規則和模式，實施保護。採用WEB ACL進行控制（定義一些Conditions），根據IP地址、URI、HTTP報頭及正文（某些JSP腳本）、地理位置、特定字符串等進行過濾，然後執行一些規則（rule）。
AWS Shield
標準服務，針對常見的Attack，SYN/UDP泛洪，L3/4層，沒有費用，永遠在線，動態應對變化。
高級服務，針對Route 53託管區、CloudFront的分發、ELB等，L7層，實施提供Attack信息。企業上雲後，水平擴展的應用，可以消化DOS；但是通過賬單，可以看到誰被Attack了（EDOS、經濟上遭受DOS）；DOS不會影響你的網絡，但會影響你的費用。Shield高級服務，針對DOS Attack，提供成本保護，但只針對Route 53託管區、CloudFront的分發、ELB等服務。遭受Attack後，你可以實施AWS WAF（採用Shield高級服務，這個免費）；也可以與DRT（DOS處理團隊）聯繫，識別Attack模式；DRT團隊協助你部署AWS WAF，你需要提供Cross-account的IAM角色。
GuardDuty
智能威脅檢測服務，監控和保護你的AWS的Account及Wordload。分析大量數據（利用CloudTrail、VPC Flow Logs、DNS Logs等），不需要探針、不會對負載的可用性及性能造成影響。整體分析，包括賬戶。
Inspector
分析VPC環境、識別安全問題智能威脅檢測服務。EC2實例要安裝Inspector Agent，監控操作系統和應用程序的行爲。針對VPC及EC2。
Macie
使用機器學習ML，發現、分類和保護敏感數據，主要針對S3存儲的數據。
Xen虛擬化與Enhanced Networking
Xen負責CPU及內存，Dom0負責虛擬機管理和I/O虛擬化；Xen，運行的Bare-metal上的，Dom0就相當於主機OS、特權虛擬機，同時支持PV和HVM；支持HVM（硬件虛擬化、需要VT-x/d）和PV（半虛擬化，改動Guest OS內核、將敏感指令改爲功能調用）。Xen的幾種運行模式：
1）PV模式（半虛擬化、全軟件模擬）：不需要CPU支持虛擬化，修改Guest OS內核，完成CPU及內存虛擬化；I/O請求發給Dom0的真實設備驅動；
2）PV on HVM模式（全虛擬化、硬件模擬，但IO採用軟件模擬）：芯片完成對CPU及內存虛擬化的支持，I/O請求發給Dom0的真實設備驅動（修改Guest OS的IO驅動程序、缺省支持一些標準的vNIC及驅動程序），繞過了KVM的全虛擬化I/O階段，對應virto方案。
3）SR-IOV PCI passthrough直通模式（前提是HVM），利用Intel VT-d，將PF/VF直接分配給Guest OS。
PV AMI和HVM AMI啓動方式不同：HVM AMI，直接利用MBR啓動，可繼續安裝PV網絡驅動（主要針對增強聯網SR-IOV），提升I/O性能。PV AMI，利用PV-GRUB、要加載menu.list到OS內核。
增強聯網：就是使用了SR-IOV的實例類型，需要主機的硬件支持，只有支持HVM的實例類型才支持增強聯網。VPC及Internet支持單流5Gbps（在Place Group內可達到10Gbps），多流最多10Gbps或25Gbps（取決於硬件網卡Intel 52999或ENA）。
啓用增強聯網需要AMI支持（AMI不啓用、不安裝驅動，所有VM只能使用PF）。對於採用Intel 52999的實例類型：AMI安裝使用Inter ixgbevf驅動程序、並設置sriovNetSupport屬性（最新的AMI都已經設置完成）；對於採用ENA的實例類型：AMI安裝使用ena驅動程序、並設置enaSupport屬性屬性（最新的AMI都已經設置完成）。
Cloud Formation
用軟件程序描述基礎設施，用AWS CodeCommit或GitHub管理版本，用CloudFormation進行部署，採用CodePipeline進行端到端協同。
validation錯誤，拼寫及格式問題、預處理就可發現問題，不涉及rollback。
semantic錯誤，只有在資源實際創建時才能發現，需要rollback。
引用DependsOn，會影響創建的順序。
Retaining Resource：在Template定義資源時將DeletionPolicy設置爲Retain，在Stack被刪除時保留。
採用新的Template進行Update，可能會Delete、Replace一些資源。在創建Stack時提供JSON文件，定義這些策略（Disable Update:Delete或Update:Replace），防止資源被新Template刪除。
Change Sets：針對當前的Stack，創建Change Set，看差別，然後執行；幫助管理Stack的升級，防止Update具備破壞性。具體提供1個新配置文件，在部署之前，與運行的Stack進行對比，提供Change、可視化，最後是excute。
配置Non-AWS資源：CloudFormation可以創建Custom Resource。在CloudFormation執行Template、創建Custom Resource的時候，可以通過SNS發送消息（提醒人、進行手工操作），或者Invoke Lambda函數（通過Python和SSH配置客戶側的CGW）；然後CloudFormation提供一個Signed URL，你可以來用反饋資源創建結果（ID、Status）。通過這種方式，CloudFormation把非Non-AWS資源也管理起來。
應該爲CloudFormation創建一個Service Role，去創建/更改/刪除Stack；或者採用Caller的IAM權限。
CodeCommit – CI，託管的源代碼控制服務（私有Git存儲庫），仍可以使用Git的CLI，實施版本管理。新特性採用分支版本，避免衝突；證實無誤後，合入主線。
CodePipeline – CD，快速地部署Update，Build – Test – Deploy，SaaS類產品，完全兼容Jenkins的能力和使用習慣，就是將Jenkins上雲、以SaaS形式對外提供服務。CodePipeline可以響應來自CodeCommit的觸發器，定期檢查。
Shared Services VPC與Transit VPC
Shared Services VPC的應用場景：大量資源在AWS上，通過PROXY很容易訪問on-premises，採用proxy控制AWS與on-premises之間的訪問。Shared Services VPC提供的服務包括：一些共享服務（AD、DNS、Database Replicas等）；提供訪問遠端的代理（Spoke VPC與On-premises之間相互訪問），HTTPS或SOCK代理，需要在ASW上管理一些資源。
Transit VPC的應用場景：大量的Spoke VPC要訪問On-premises，很難將On-premises的資源搬到AWS上，實施複雜路由。採用EC2實例 V_P_N網關，連接Spoke VPC的VGW和On-premises的CGW。V_P_N連接不能斷：Hub VPC與Spoke VPC之間有VPC Peering，仍要建立V_P_N連接；On-premises與Hub VPC之間有Direct Connect，仍要建立V_P_N連接。
Transit VPC的4種細分場景和實現方案
方案1：兩個信任的VPC之間通過VPC Peering直接互聯，並且靜態路由的優先級高於V_P_N及BGP，繞過Transit VPC Hub。
方案2： 相互信任，On-premises通過Private VIF及Direct Connect Gateway直接連接VGW及Spoke VPC，AS_Path短，路由優先級高，繞過Transit VPC Hub。
方案3：Transit Hub VPC與遠端VPC通過VPC Peering互聯（提供高帶寬），Transit Hub VPC的EC2實例仍要與遠端VPC中的EC2實例建立IPSEC。
方案4：CGW 的VRF通過Private VIF/DX連接到VGW及VPC，然後與VPC中的EC2實例建立IPSEC隧道（獲得DX的高帶寬），需要CGW支持Tunnel VRF。
Billing與Data Transfer
網絡相關的3種費用：服務/端口小時費，數據處理費用，數據傳送費。
V_P_N Connections：按Connection-Hour收費，還有數據傳輸費用（離開AWS方向）。
Direct Connect：按Port-Hour收費，還有數據傳輸費用（離開AWS方向）；對於Hosted Connection ，只要Accept，就開始Port-Hour收費；對於Hosted VIF，接收者支付Data Transfer相關費用，Port-Hour還是由Owner支付。
Data Transfer - Internet，在AWS Internet與Internet之間的（假設你通過Internet訪問AWS）；流入AWS Internet不收費，流出AWS Internet爲$0.09/GB（由被訪問資源的擁有者支付費用），這涉及AWS Internet與其它Internet之間的網間結算問題。
Data Transfer - Region to Region，在AWS Internet與AWS Internet之間的，入方向不收費，流出方向$0.02/GB。
CloudFront：從Edge到User正常收費；Origin在AWS網絡，從Origin到CloudFront的流量，不收費；上載數據，需要收費，$0.02/GB。
Data Transfer - Same Region，與同一區域AWS公有服務之間的流量，沒有Data Transfer費用（但是AWS公有服務本身收費）；訪問不同區域AWS公有服務，包括AWS服務費及數據傳輸費。
Data Transfer - Inter-AZ（不是Subnet），雙向收費，每個方向$0.01/GB。
Data Transfer - VPC Peering：相同Region的VPC Peering，EC2實例之間的通信，雙向收費，每個方向$0.01/GB。
Data Transfer - Intra-AZ，沒有費用；如果採用Public IP地址通信，雙向收費，每個方向$0.01/GB。
對於採用Direct Connect訪問AWS Internet及VPC，Public VIF及Pirvate VIF本身不涉及流量費用；訪問別人的資源、由對方支付$0.09/GB（離開AWS方向）；訪問自己的資源，採用降低的費率，$0.02/GB（離開AWS方向）。
相關白皮書及博客的連接：
https://aws.amazon.com/cn/blogs/apn/amazon-vpc-for-on-premises-network-engineers-part-one/
https://aws.amazon.com/cn/blogs/apn/amazon-vpc-for-on-premises-network-engineers-part-two/
https://d0.awsstatic.com/whitepapers/aws-amazon-vpc-connectivity-options.pdf
https://d1.awsstatic.com/aws-answers/AWS_Multiple_Region_Multi_VPC_Connectivity.pdf
https://aws.amazon.com/cn/answers/networking/aws-multiple-data-center-ha-network-connectivity/
https://aws.amazon.com/cn/answers/networking/aws-multiple-vpc-***-connection-sharing/
https://d1.awsstatic.com/whitepapers/hybrid-cloud-dns-options-for-vpc.pdf
三、AWS戰略的簡要分析
AWS已經建設了一張覆蓋全球的IP骨幹網，連接了所有的Region（中國和美國政務雲除外），便於企業快速在全球對外提供業務，同時實現企業內部業務的互聯。
AWS與全球上百家區域運營商合作，將PoP點下移，通過Direct Connect服務就近接入企業客戶，實現企業客戶高質量、低成本上雲，構建混合雲、訪問AWS公共服務、對外提供服務。
通過全球IP骨幹網以及Direct Connect，結合提供的各種雲服務，AWS基本就構建了一個端到端的閉環系統，企業只要接入AWS、流量就可以在AWS內部消化掉。當然企業對外提供業務，仍要藉助於AWS Internet與其它Internet的互聯互通。
最近有傳言說，AWS要開發一些企業側的盒子，這應該是很正常的。目前AWS提供Direct Connect及V_P_N服務，要對接On-premises的十幾個供應商的數十款軟硬件產品，這些產品的能力、配置參數等都不同；與其在雲端不斷地去適配這些產品，換個思路就是提供自己的盒子、對技術做歸一化；同時在On-premises有自己的盒子作爲抓手，可以推出一些更有競爭力的混合雲服務，包括路由能力、安全加密能力、可靠性、DNS解析、存儲方案等能力提升。
隨着傳統企業上雲步法加快，雲計算對整個通信行業會產生深遠的影響。
對運營商市場的影響：企業上雲後，其內部互聯自然會從傳統MPLS V_P_N轉向雲專線，雲專線的開通速度和業務集成要遠優於MPLS V_P_N；可以預見長途專線市場將從運營商向雲服務商轉移，雲服務商仍依賴運營商提供的本地專線、接入客戶；未來在個人或消費互聯網領域運營商仍佔據領先地位，但具備全球覆蓋能力的雲服務商將主導高價值的企業互聯網。
對企業市場的影響：企業上雲後，必將逐步減少對傳統IT及網絡設備的投資以及長途線路租用，轉而消費雲服務；由於規模經濟和高效率，每在雲端消費1$，將減少4$的On-premises投資，傳統設備製造商和軟件供應商的市場空間會逐步被蠶食；多數企業網絡最終會演進成爲家庭接入模型。
同時雲計算也會對通信行業帶來一些新的機會。相比傳統的On-premises，雲端出於安全性及可靠性的考慮做出很多的功能限制；對於企業客戶一些定製化的需求，需要引入各類VNF組件、搭建Overlay網絡，包括負載均衡、路由器、V_P_N網關、V_P_N接入服務器、防火牆、WEB防火牆、NAT等等；已有衆多的傳統設備製造商及新型廠家投入到這一領域，推出了相應的軟件化產品，並與主流的雲服務平臺進行了集成。
下圖爲未來的一個跨國公司的企業數字化基礎設施平臺，除了本地接入資源外，企業的IT、軟件及網絡等資源將全部構建於公有云平臺之上。
