經驗分享: 成功經過AWS Advanced Networking Specialty認證考試

薛國鋒  xueguofeng2011@gmail.com

 

本文主要分享了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戰略的簡要分析。

 

1、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瓶水放在去廁所的路上。

 

2、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技術，針對EC二、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，能夠與S三、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://d0.awsstatic.com/whitepapers/Networking/integrating-aws-with-multiprotocol-label-switching.pdf

https://d1.awsstatic.com/whitepapers/hybrid-cloud-dns-options-for-vpc.pdf

https://aws.amazon.com/cn/blogs/compute/powering-secondary-dns-in-a-vpc-using-aws-lambda-and-amazon-route-53-private-hosted-zones/

https://aws.amazon.com/cn/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-using-aws-directory-service-and-amazon-route-53/

https://aws.amazon.com/cn/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-using-aws-directory-service-and-microsoft-active-directory/

https://aws.amazon.com/cn/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-by-using-unbound/

3、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、軟件及網絡等資源將所有構建於公有云平臺之上。