經(jīng)驗分享: 成功通過AWS 考試

來源：塔塔 更新時間：2018-11-28

更多

著作權(quán)歸作者所有：本文轉(zhuǎn)載來自51CTO博客作者xueguofeng的原創(chuàng)作品

本文主要分享了AWS高級網(wǎng)絡專項認證考試（Advanced Networking Specialty - ANS）的備戰(zhàn)及考試經(jīng)驗，同時對AWS網(wǎng)絡相關(guān)服務進行REVIEW，分析其主要特點和一些應用限制；最后對AWS戰(zhàn)略做簡要分析，討論一下對運營商及企業(yè)網(wǎng)絡的影響。

 

2個月前正好有一些時間，決定樹立個目標、優(yōu)化一下自己的知識結(jié)構(gòu)。在網(wǎng)上轉(zhuǎn)了半天，初步選定AWS高級網(wǎng)絡專項認證考試。

先簡單介紹一下本人的專業(yè)背景：從事數(shù)據(jù)通信領(lǐng)域多年，開發(fā)過路由器平臺軟件和協(xié)議模塊，干過解決方案銷售，參與過很多運營商IP網(wǎng)絡建設，對主流數(shù)通協(xié)議及網(wǎng)絡方案是比較了解的。3年前開始接觸IT和云計算，2015年把WEB技術(shù)體系囫圇吞棗地過了一遍，包括前端HTML/JavaScript、AJAX以及后端的JSP/Servlet、Tomcat、Spring/Struts、Hibernate、MySQL、JAX-RS 等，當然這些都是利用業(yè)余時間學著玩的，只了解一些基本概念、編過一些小程序。后來朋友推薦玩一玩AWS，經(jīng)過半年多的胡亂摸索（第一次通過SSH登陸EC2主機都有很強的挫敗感），2017年初通過了AWS解決方案架構(gòu)師（助理級）和AWS開發(fā)者（助理級）的認證考試。2017年下半年把比較流行的開源軟件框架都安裝過一遍，包括OpenDaylight、QEMU/KVM、OVS、OpenStack/Python、Docker、Kubernetes及Hadoop等?？偟膩碚f，從云計算的技術(shù)體系到業(yè)務應用，已經(jīng)建立了初步概念和感性印象。

AWS 高級網(wǎng)絡專項認證，是亞馬遜2017年新推出的認證項目，重點考察面向企業(yè)混合云場景下的連接、路由、可靠性、容錯、安全、加密、域名解析、CDN、目錄服務、各種云服務對網(wǎng)絡的需求（VDI、容器、RDS、大數(shù)據(jù)、數(shù)據(jù)庫遷移等）、自動化部署與運維、效率與成本、風險及合規(guī)等與網(wǎng)絡相關(guān)的知識，涉及面比較廣、有一定深度。考試內(nèi)容以場景為主，注重考察運用知識解決實際問題、而非知識點本身，170分鐘時間共65道選擇題（單選及多選），每道題介紹一個業(yè)務場景，你需要在2分半的時間內(nèi)理解問題、建立模型、做出選擇。我們通過2道模擬題，看一下試題風格：

關(guān)鍵知識點：VPC Peering不支持Transitive Routing；Client-to-Site V_P_N為Client分配IP地址、做NAT；一般來說NAT只支持單向連接。正確答案為B。

關(guān)鍵知識點：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。

網(wǎng)上很多人都反饋AWS ANS認證考試比較難，可能是AWS 的9個證書中最難考的一個；美國有一位老兄手里拿了6個AWS證書（3個助理級 – SA、Developer、SysOps，3個專業(yè)級 – SA、DevOps、Big Data），挑戰(zhàn)了3次才通過AWS ANS認證考試?，F(xiàn)在回頭分析這個事，我覺得主要原因如下：

1）ANS是2017年新推出的認證項目，通過的人不多，相對其它AWS認證項目，網(wǎng)上各種ANS模擬題庫的質(zhì)量不高。我在備戰(zhàn)ANS認證考試過程中一共做了800多道模擬題（主要來自Official Study Guide和WhizLabs，很多題目都是拷貝的），而在實際考試中基本一道題也沒有遇到過，因此這個考試就是在考察你的真實水平。

2）網(wǎng)絡就是要復雜一些，連接了各種云服務和On-premises，涉及到端到端網(wǎng)絡和各種組件，正常情況下你感覺不到它的存在、出了事兒可能全是它的問題；如果對網(wǎng)絡一些核心概念理解不透徹的話，場景稍微調(diào)整一下，在遇到壓力的情況，腦袋可能就亂了。

3）現(xiàn)在企業(yè)中從事云計算應用的人員多數(shù)來自IT和軟件，從IP轉(zhuǎn)過來的不多，不同背景的人對AWS ANS認證考試難度的感知自然會有差異。我個人的體會是，IT和軟件涉及面很廣，而IP是比較復雜的。

在網(wǎng)上做了調(diào)研之后，當時心理還是有一定壓力的，我行不行啊、這個要投入多少時間？但客觀分析一下，這個認證考試就是為我這種從IP轉(zhuǎn)入IT和云計算的人設計的，如果我都不敢去挑戰(zhàn)，還指望誰呢？我到底算不算專家啊，會考試的人不一定是專家，但真專家應該是不會懼怕這種實戰(zhàn)性強的考試。最終下定決心，上！

目標定下來后，就是堅定不移地執(zhí)行，接下來的8個星期過得是比較辛苦的，幾乎把所有能利用上的時間都利用上了，“理論學習 – Lab – 模擬題練習 – 總結(jié)”，俄羅斯世界杯期間一場足球比賽也沒看。有一天突然收到公司HR的電話 – “薛老師，你上個月加班150個小時、沒事吧”，我說“沒事兒，宿舍沒空調(diào)、辦公室涼快、自己看看書啥的”。

我總共看了幾千頁的材料，記了200多頁的筆記，但仍感覺信心不足、預定參加考試的時間也一拖再拖，不僅僅是因為300多美元報名費的問題，主要擔心如果考不過會影響自信心，畢竟咱是公司的專家。準備到后來都有些厭倦了，材料開始看不進去了、并且找不到大塊的新知識點，時間不能再拖了，于是就報名了8/7的考試。

盡管事先做好了充分的思想準備，考試過程還是非常緊張和刺激，時間飛速流逝，有些題就是看不懂、急得直跺腳，總盼著下一道題能簡單點兒、贏回來一些時間，頭腦中曾出現(xiàn)放棄的念頭（隨機選答案就交卷了），最終hold住了，只要還有一分鐘時間、就要全力以赴去讀題做題。ANS ANS認證考試不僅僅是考察你的專業(yè)知識，還包括你的心理素質(zhì)和意志力，在有限時間和環(huán)境壓力下能否穩(wěn)定發(fā)揮。

我用了140分鐘答完了65道題，對其中18道做了標記、屬于拿不準的，然后就用剩下的30分鐘對這18道題進行REVIEW，修改了部分題目的答案。在交卷前的一刻，其實人已經(jīng)比較放松了，過去2個月無論是準備階段還是考試現(xiàn)場，我都做了詳細的策劃、盡了自己最大的努力，也系統(tǒng)地提升了自己在云計算和網(wǎng)絡結(jié)合方面的專業(yè)水平，無論結(jié)果如何，都沒有遺憾；如果過不了，那就是自己水平不行，或者實踐不到位。點擊鼠標后等待片刻，屏幕顯示：

“Congratulations，you have successfully completed AWS Advanced Networking – Specialty exam…”

我當時心理有些犯嘀咕，complete考試有啥好祝賀的，難道還有人不能complete，我到底有沒有pass?。侩x開考場后打開手機，收到了AWS的郵件：

通過了，成績?yōu)?/span>84%（及格線通常為65%~70%），結(jié)果還是很不錯的，這說明之前自己背負了過多的思想負擔、備戰(zhàn)工作有些overly prepared了。實際上認證考試只要能通過就OK了，工作與考試還是有很多區(qū)別，考試成績每提升1%都要付出額外的努力和時間，利用這些時間學些新東西或者享受一下生活不是更好嗎！

云計算并非我的本職工作，過去3年我投入了大量的業(yè)余時間學習云計算的相關(guān)技術(shù)，同時在工作中創(chuàng)造各種條件去實踐，我對自己當前取得的進展是滿意的。從當初對云計算一無所知、人云亦云，到逐漸能夠形成一些自己的觀點并通過AWS ANS這種專業(yè)級的云計算認證考試，我切切實實感受到了自己的進步與成長；并且這種進步是源于自己為應對未來的挑戰(zhàn)所作出的積極改變，收獲的不僅僅是信心，而是未來廣闊的空間。

接下來我通過3個維度分享一下本次參加AWS ANS認證考試的經(jīng)驗與心得體會：

1）AWS ANS認證考試的備戰(zhàn)與考試經(jīng)驗；

2）AWS網(wǎng)絡相關(guān)服務REVIEW，主要特點與一些應用限制；

3）AWS戰(zhàn)略的簡要分析。

 

一、AWS ANS認證考試的備戰(zhàn)與考試經(jīng)驗

主要采用的學習材料：

閱讀材料	AWS Certified Advanced Networking Official Study Guide，31.99$，Amazon上有賣； AWS官網(wǎng)上各種云服務使用指南、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的網(wǎng)絡相關(guān)視頻（主用）： https://www.youtube.com/playlist?list=PLhr1KZpdzukewxjrgeVIGw49tiIbkqt0Z 網(wǎng)友整理的AWS ANS相關(guān)視頻：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實例，需要配置穿越公司的代理服務器。

 

結(jié)合個人情況制定的學習計劃：

Week  1,2,3,4	1）看培訓視頻； 2）閱讀Official Study Guide（2遍），完成了主要的課后實驗； 3）溫習、學習了一些背景專業(yè)知識，包括：  - 對稱加密與非對稱加密、數(shù)字簽名、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的網(wǎng)絡技術(shù)；  - JavaScript和AJAX、Tomcat與Servlet、Cookies與Session，等等。
Week  5,6,7	完成了800多道模擬題的訓練，進行總結(jié)，加深理解。
Week  8	閱讀Official Study Guide（第3遍），復習200多頁的學習筆記； 重點補做了一些實驗、看了一些視頻。
	1）備戰(zhàn)期間要堅持鍛煉身體，調(diào)整好競技狀態(tài)； 2）AWS ANS認證考試的信息量比較大，平時要做好筆記，定期復習； 3）考試期間沒有太多時間思考，對于一些主流的業(yè)務場景，如VPC路由選擇、Hybrid DNS主要場景及方案、Transit Hub VPC方案的主要變種、EC2實例V_P_N網(wǎng)關(guān)的水平及垂直擴展方案等，要做好歸納總結(jié)、能夠舉一反三。

 

考試預約與參加考試的注意事項：

考試預約	參加ANS認證考試前，應先通過一門AWS助理級認證（SA、Developer或SysOps）； 到AWS網(wǎng)站上進行考試預約，支付318美元： https://www.aws.training/certification 建議選擇英文考試，AWS中文資料翻譯的不好、經(jīng)常會有歧義； 我選擇的考點是：深圳市羅湖區(qū)深房廣場1903室，下午1:30考試。
參加考試：	攜帶2個帶照片的個人ID，考點提供安全柜，可以存放個人物品； 進入考場后不能攜帶任何物品，可以管考試中心的工作人員要一些紙和筆； 計算機考試，電子監(jiān)控，周邊一圈攝像頭； 考試過程中用腦強度會比較大，事先要確保充足的睡眠和能量，調(diào)整好心情； 考試期間允許上廁所，可以準備1瓶水放在去廁所的路上。

 

二、AWS網(wǎng)絡相關(guān)服務REVIEW

AWS的英文文檔做的非常好，為各個服務提供了很詳細的使用指南及FAQs，但涉及到關(guān)鍵技術(shù)實現(xiàn)時往往一筆帶過，這是我在準備AWS ANS認證考試過程中遇到的主要障礙。在不清楚其具體實現(xiàn)原理的情況下，很多知識點就要靠人為記憶了，這是一件很不爽的事情。針對一些關(guān)鍵服務的實現(xiàn)，我參照了開源軟件的實現(xiàn)方案以及網(wǎng)上的討論，同時結(jié)合過去的研發(fā)經(jīng)驗，爭取能夠畫出模型、加深理解、簡化記憶。下面討論AWS網(wǎng)絡相關(guān)服務的部分重要及難點問題，來自我備戰(zhàn)期間整理的學習筆記。

 

VPC轉(zhuǎn)發(fā)邏輯與Transitive Routing

VPC應該是通過SDN及Overlay方案實現(xiàn)的，不支持Multicast和Broadcast，Subnet內(nèi)部轉(zhuǎn)發(fā)、Subnet之間轉(zhuǎn)發(fā)、EC2實例到各類服務網(wǎng)關(guān)（IGW、VGW、NAT、DNS等等）的轉(zhuǎn)發(fā)，都是一跳完成的。

VPC對報文轉(zhuǎn)發(fā)邏輯做了重要的限定：如果一個報文的源地址不是對應本VPC內(nèi)部的一個接口，則該報文的目的地址一定是對應本VPC內(nèi)部的一個接口；報文的源地址或者目的地址至少有一個是對應本VPC內(nèi)部的接口，否則報文就要被丟棄。

這個轉(zhuǎn)發(fā)邏輯的制定 – VPC不支持Transitive Routing，應該主要是考慮到AWS云端網(wǎng)絡的安全性及可靠性，比如說避免租戶設計的VPC網(wǎng)絡出現(xiàn)環(huán)路問題、避免源地址欺騙。VPC不支持Transitive Routing，會影響到AWS云端網(wǎng)絡設計的方方面面，提升了整體方案的復雜度，這也是與傳統(tǒng)On-premises網(wǎng)絡區(qū)別最大的地方。以下表格是我根據(jù)AWS的官方文檔和Lab整理出來的：

VPC內(nèi)部各類服務網(wǎng)關(guān)	EC2 實例	IGW與  EIGW	VGW	VPC Peering	Gateway VPC Endpoint	Interface VPC Endpoint	VPC DNS	EFS	NAT網(wǎng)關(guān)與實例
在本VPC內(nèi)部訪問	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_NConnection接入后訪問	V	X	V CloudHub	X	X	X	X	X	X

IGW/EIGW、VGW、VPC Peering和Gateway VPC Endpoint在VPC內(nèi)部都不存在ENI接口，只能在VPC內(nèi)部訪問。

VPC DNS雖然可以通過“VPC CIDR+2”的地址進行訪問，但在VPC內(nèi)部并不存在ENI接口（應該是VPC路由器直接截獲DNS報文、轉(zhuǎn)發(fā)給AWS-Managed DNS服務），所以只能在VPC內(nèi)部訪問。

對于Interface VPC Endpoint及EFS，它們在VPC內(nèi)部都有ENI接口及IP地址，正常情況下與在外部訪問EC2實例沒有區(qū)別，AWS應該是基于商業(yè)考慮和技術(shù)約束做了一些訪問限制。

對于NAT GW和NAT實例，它們在VPC內(nèi)部都有ENI接口及IP地址，但它們處理的報文都是要訪問Internet的（并非訪問NAT設備本身），由于VPC不支持Transitive Routing，只能在VPC內(nèi)部訪問。

在AWS平臺上實現(xiàn)Transitive Routing需要采用Overlay的方案，將從VPC外部對VPC內(nèi)部各類服務網(wǎng)關(guān)的訪問/穿透，轉(zhuǎn)換為在VPC內(nèi)部發(fā)起請求；針對每一類服務網(wǎng)關(guān)，都要采用與之對應的解決方案。

針對VPC DNS的Transitive Routing問題，可采用AWS-Managed SimpleAD、Active Directory或自己部署Unbound，實施Conditional Forwarding。

針對IGW及NAT的Transitive Routing問題，需要采用EC2實例終結(jié)V_P_N隧道、做NAT轉(zhuǎn)換（將報文源地址轉(zhuǎn)換為VPC CIDR的地址），才有可能訪問VPC的IGW及NAT。

針對VPC Endpoint的Transitive Routing問題，需要在HTTP應用層實現(xiàn)，具體可以采用2種方案：

1）反向代理（代理服務）：在VPC內(nèi)部部署ELB及Proxy Farm，通過修改DNS，將VPC外部對服務網(wǎng)關(guān)的訪問轉(zhuǎn)換為先訪問ELB，在由ELB及Proxy Farm訪問服務網(wǎng)關(guān)。

2）正向代理（代理客戶），在VPC內(nèi)部部署ELB及Proxy Farm，在客戶端配置ELB作為代理服務器，客戶端先連接ELB，在由ELB及Proxy Farm訪問服務網(wǎng)關(guān)。

VPC 的本地路由

VPC Local Route主要用于VPC內(nèi)部的轉(zhuǎn)發(fā)、確保所有資源之間的通信，不能被修改，不能用more specific route進行覆蓋。如果你想配置軟件防火墻用于過濾Subnet之間的轉(zhuǎn)發(fā)流量，你無法改動VPC Local Route，但可以通過改動EC2實例OS的路由配置間接實現(xiàn)。

可以在VPC路由表中增加比VPC CIDR范圍更大的Destination。 

ENI接口

EC2實例的主接口，無法從實例分離。ENI可以在某Subnet中動態(tài)創(chuàng)建，代表虛擬網(wǎng)卡，可以與EC2實例動態(tài)綁定（EC2實例所在Subnet與ENI所在Subnet必須在同一AZ內(nèi)），也可以從一個實例分離并重新綁定到另一個實例。ENI接口可以用于網(wǎng)管網(wǎng)、主備倒換以及虛擬防火墻等。

EC2實例支持ENI接口數(shù)量有限，不支持NIC Teaming。 

跨賬戶網(wǎng)絡接口：

A賬戶某VPC及Subnet的EC2實例，動態(tài)綁定B賬戶某VPC及Subnet中的ENI，EC2實例與ENI需要在1個AZ內(nèi)；主要用于AWS管理的服務與租戶VPC之間的訪問，包括RDS（AWS管理數(shù)據(jù)庫、租戶使用數(shù)據(jù)庫）、Lambda（AWS提供計算資源、訪問租戶VPC）及Workspaces等。該方案的擴展性及可靠性一般。

受控使用，租戶要使用這個功能，需要白名單控制。 

ENI接口的Source/Destination Check

與VPC轉(zhuǎn)發(fā)邏輯不支持Transitive Routing的原因類似，EC2實例的ENI接口發(fā)送/接收報文時，要做Source/Destination Check：發(fā)送報文時，報文的源地址必須是自己的IP地址；接收報文時，報文的目的地址必須是自己的IP地址；否則報文就要被丟棄。當EC2實例提供NAT、V_P_N、Firewall等功能時，接收和發(fā)送的報文通常都不是自己的，因此要禁止Source/Destination Check。 

安全組

安全組作用于ENI接口。安全組的Inbound規(guī)則，端口是自己的、源IP地址是遠端的；安全組的Outbound規(guī)則，端口是遠端的、源IP地址是遠端的。安全組，只需要配置Allow。

默認安全組，通過配置自引用規(guī)則，實現(xiàn)可以接收來自配置了同一安全組的實例的報文、允許發(fā)送所有報文。新建的安全組，開始時禁止接收報文、但可以發(fā)送所有報文。

安全組是有狀態(tài)的，只要允許報文進入、就允許報文離開，無論Outbound規(guī)則是如何配置的；反之亦然。如果針對某些端口，允許進出所有的流量，安全組就不需要維持狀態(tài)了。

由于AWS內(nèi)部的技術(shù)實現(xiàn)，對于已經(jīng)存在的連接，刪除對應的安全組后，通信不會中斷、仍會持續(xù)若干天，因此必須要配置網(wǎng)絡ACL。 

網(wǎng)絡ACL

網(wǎng)絡ACL作用于Subnet。網(wǎng)絡ACL的Inbound規(guī)則，端口是自己的、源IP地址是遠端的；網(wǎng)絡ACL的Outbound規(guī)則，端口是遠端的、源IP地址是遠端的。網(wǎng)絡ACL需要顯示配置Allow及Deny規(guī)則，按照規(guī)則順序進行匹配。

默認ACL，通過在Inbound和Outbound方向配置100號規(guī)則，可以發(fā)送和接收所有報文。新建的NACL，開始時禁止接收和發(fā)送所有報文。

網(wǎng)絡ACL是無狀態(tài)的。 

IGW、NAT網(wǎng)關(guān)/實例和EIGW

NAT網(wǎng)關(guān)/實例，只是將報文的源地址轉(zhuǎn)換為自身ENI接口的地址（私有地址），用源端口號來區(qū)別不同的用戶流；IGW最終將報文的源地址（私有地址）轉(zhuǎn)換為公有IP地址或彈性IP地址，是1:1轉(zhuǎn)換。

NAT網(wǎng)關(guān)，是AWS Managed的服務，你不能做任何改動，不能配置其ENI接口的安全組，不能配置Predefined端口、允許外部訪問內(nèi)部。NAT網(wǎng)關(guān)要部署到Subnet級別，性能可以自動伸縮、到45Gps。

NAT實例，可以采用第三方軟件、需要禁止Source/Destination Check。NAT實例的安全組可以配置，Inbound規(guī)則實際上意義不大，因為收到的報文都不是要訪問NAT實例本身的。

EIGW，是為IPV6業(yè)務提供類似IPV4 NAT的體驗，VPC內(nèi)部可以訪問Internet、Internet不能訪問VPC內(nèi)部，但不做地址轉(zhuǎn)換；EIGW部署在VPC級別、非Subnet。 

VPC路由優(yōu)先級

VPC的靜態(tài)路由配置是不能出現(xiàn)沖突的，既前往同一個Destination不能有2個Target，但是靜態(tài)路由與動態(tài)路由之間是可以沖突的，這就涉及路由優(yōu)先級的問題。AWS網(wǎng)絡有2個位置，需要做出路由選擇，分別是VPC和VGW。

VPC有多個路由來源，包括本地CIDR、靜態(tài)配置、VGW動態(tài)注入。VPC的路由選擇優(yōu)先級為：本地CIDR路由，最長匹配路由（無論來自哪里），靜態(tài)路由（前往某Destination，Target分別為IGW、VPC Peering、VGW、NAT、ENI等），通過Direct Connect注入的BGP路由（Target為VGW），V_P_N靜態(tài)路由（Target為VGW），通過V_P_N Connection注入的BGP路由（Target為VGW）。

VGW也有多個路由來源，包括綁定VPC的CIDR、在V_P_N Connection上配置的靜態(tài)路由、通過BGP協(xié)議及多個Direct Connect及V_P_N Connection對等體動態(tài)學習的路由。VGW的路由選擇優(yōu)先級為：本地CIDR路由、最長匹配路由、通過Direct Connect學到的BGP路由、V_P_N靜態(tài)路由、通過V_P_N Connection學到的BGP路由。

VGW內(nèi)部多個Direct Connect或多個V_P_N Connection存在多條BGP路由沖突時，BGP的路由選擇優(yōu)先級為：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學到路由后，可以動態(tài)注入到VPC路由表，也可以在VPC路由表中配置靜態(tài)路由、Target指向VGW。 

VPC Endpoint

主要是出于安全及合規(guī)考慮，訪問AWS公有服務時，不走Internet。主要分為2類：

Gateway VPC Endpoint，早期的技術(shù)實現(xiàn)，主要針對S3和DynamoDB，將這些AWS服務的公網(wǎng)路由注入VPC及Subnet的路由表中（用PL-xxxxxxxx標識、作為Destination），VPC Endpoint作為Target（用vpce-xxxxxxxx標識，應該是提供NAT功能）?？梢栽赩PC Endpoint配置IAM策略，能夠訪問哪些S3 Bucket；也可以在S3 Bucket配置IAM策略，能夠被哪些VPC或VPC Endpoint訪問，不能采用基于源IP地址的策略。此外在安全組也可以引用PL-xxxxxxxx、配置策略，網(wǎng)絡ACL中不能引用PL-xxxxxxxx。

Interface VPC Endpoint，最新的技術(shù)實現(xiàn)，基于AWS PrivateLink技術(shù)，針對EC2、ELB、Kinesis等，為這些AWS服務在Consumer VPC增加了一個或多個ENI接口及IP地址，同時為這些ENI接口提供Region及Zone的DNS域名（公網(wǎng)可解析、返回私網(wǎng)IP地址），也可以在Consumer VPC內(nèi)部將標準AWS服務域名（如：ec2.us-east-2.amazonaws.com）解析為這些ENI接口的私有IP地址。

通過PrivateLink技術(shù)，我們自己也可以對外發(fā)布Endpoint Service：在Provider VPC創(chuàng)建Network ELB及Back-end服務器、基于ELB創(chuàng)建Endpoint Service；在Consumer VPC創(chuàng)建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適合于單向通信，可以支持數(shù)千個Consumer VPC。

同一Region的VPC Peering，可以引用對端的安全組，并且可配置將對端的公有DNS域名解析為VPC內(nèi)部的私有IP地址（非彈性IP地址或公有IP地址）。采用VPC Peering后，并不能自動訪問對端VPC關(guān)聯(lián)的Route 53私有托管區(qū)，仍需要顯示關(guān)聯(lián)?？鏡egion的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發(fā)布路由時采用BGP的 最長匹配路由、AS_Prepend或MED等策略；

CGW -> VGW流量，CGW向on-premises內(nèi)部網(wǎng)絡發(fā)布路由時采用BGP的Weight或Local_Pref等策略。

EC2實例V_P_N網(wǎng)關(guān)的HA方案：運行2個EC2實例作為IPSEC網(wǎng)關(guān)、建立隧道，其中EC2-1個作為on-premises路由的Target；運行自動化腳本，發(fā)現(xiàn)問題，修改VPC路由表、實現(xiàn)切換，選擇EC2-2作為on-premises路由的Target。

EC2實例V_P_N網(wǎng)關(guān)的垂直擴展方案：EC2 Instance1（做ELB） 與3個EC2 Instance（處理IPSec）之間運行BGP。

EC2實例V_P_N網(wǎng)關(guān)的水平擴展方案：按照不同的Prefix來分離IPSec網(wǎng)關(guān)，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與全球上百家區(qū)域運營商合作，將PoP點下移，采用DX Router就近進入客戶。2種接入方案：

1）光纖直連，DX Router – Dark Fiber – CGW，支持1Gbps和10Gbps；

2）借助于運營商網(wǎng)絡，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路由，非其它靜態(tài)配置或動態(tài)注入的路由；CGW最多向VGW發(fā)布100條路由。

CGW通過DX Router及Public VIF，連接到AWS Internet，運行BGP，通過Community屬性控制On-premises路由的傳播范圍（本Region、本Continent、全球），以及CGW學習AWS Internet路由的范圍（本Region、本Continent、全球）。CGW最多向AWS Internet發(fā)布1000條路由，AWS Internet不會為On-premises的公網(wǎng)路由提供Transit服務；如果CGW采用私有ASN，AS-Prepend不會起作用。

托管VIF，Hosted VIF，可以是Public VIF，也可以是Private VIF（接收者綁定VPC）。Hosted VIF的流量相關(guān)費用，由接收者承擔；端口小時費，由Owner承擔。

VGW可以作為CloudHub，為V_P_N Connection及Direct Connect等接入方提供路由及轉(zhuǎn)發(fā)。

CGW通過DX Router及Private VIF連接到Direct Connect Gateway后，可以連接到跨Region的多個VGW。Direct Connect Gateway的控制平面，提供類似BGP路由反射器的功能；其轉(zhuǎn)發(fā)平面，完成CGW與多個VGW之間的流量交換（非VGW之間、非CGW之間）。

CGW通過DX Router及Public VIF接入AWS Internet后，可以再與VGW之間建立V_P_N Connection。

CGW通過DX Router及Private VIF接入VPC后，可以再與VPC內(nèi)部的EC2實例之間建立V_P_N Connection。這時通常需要CGW支持Tunnel VRF功能：創(chuàng)建VRF，在VRF內(nèi)部通過DX Router及Private VIF接入VGW和VPC，學到EC2實例V_P_N網(wǎng)關(guān)的路由；然后在CGW的主路由表中，創(chuàng)建隧道（隧道的Source及Destination為VRF的地址空間），連接EC2實例V_P_N網(wǎng)關(guān)，再通過BGP交換業(yè)務路由。

VPC DNS與Route 53

在VPC發(fā)布EC2實例后，自動提供公有DNS域名及私有DNS域名（enableDnsSupport為TRUE、enableDnsHostnames為TRUE），公有DNS域名在VPC內(nèi)部解析為私有IP地址。

VPC DNS服務，通過“CIDR+2”的地址訪問，自動為Internet公有域名、VPC資源以及Route 53私有托管區(qū)（與VPC綁定）提供查詢服務。VPC DNS服務，不能被VPC外部訪問（通過VPC Peering、V_P_N、Direct Connect等），不可更改配置。

Hybrid DNS存在多種解決方案：

1）Simple AD是AWS提供的AD管理服務，自動向VPC DNS轉(zhuǎn)發(fā)請求，不可更改配置、不能向On-premises轉(zhuǎn)發(fā)請求。通過配置DHCP Option Set，VPC EC2實例可以使用Simple AD的DNS服務；如果VPC也要解析On-premises的域名，有需求的EC2實例可以安裝Unbound、指向On-premises DNS服務器及VPC Simple AD。On-premises DNS服務器可以設置轉(zhuǎn)發(fā)、指向Simple AD，從而實現(xiàn)On-premises解析VPC資源的域名。

2）Microsoft AD是AWS提供的AD管理服務，可以進行配置，可以向VPC DNS及On-premises DNS轉(zhuǎn)發(fā)請求。通過配置DHCP Option Set，VPC EC2實例可以使用Microsoft AD的DNS服務，同時解析VPC及On-premises的域名。On-premises DNS服務器可以設置轉(zhuǎn)發(fā)、指向Microsoft AD，從而實現(xiàn)On-premises解析VPC資源的域名。

3）在VPC部署Unbound作為DNS服務器、實施Conditional Forwarding，可以向VPC DNS及On-premises DNS轉(zhuǎn)發(fā)請求。通過配置DHCP Option Set，VPC EC2實例可以使用Unbound的DNS服務，同時解析VPC及On-premises的域名。On-premises DNS服務器可以設置轉(zhuǎn)發(fā)、指向Unbound，從而實現(xiàn)On-premises解析VPC資源的域名。

4）創(chuàng)建Route 53私有托管區(qū)、與VPC關(guān)聯(lián)，利用CloudWatch的定期事件以及Lambda函數(shù)，定期在Route 53私有托管區(qū)鏡像On-premises的DNS數(shù)據(jù)庫，相當于為On-premises在VPC創(chuàng)建了Secondary DNS，實現(xiàn)VPC解析On-premises的域名。

Route 53提供域名注冊、DNS服務以及Health Check功能；Route 53公共托管區(qū)，是外部可見的；Route 53私有托管區(qū)與Route 53公共托管區(qū)共享全球的DNS基礎(chǔ)設施，但Route 53只響應關(guān)聯(lián)VPC對Route 53私有托管區(qū)的查詢，外部無法訪問，主要用于Split-Horizon DNS場景（相同的域名在VPC內(nèi)部及VPC外部可解析出不同的IP地址）。

Route 53支持Alias記錄，相當于指針，對DNS Resolver提供等效于查詢A記錄的體驗；而采用CNAME，DNS Resolver要做2次查詢。不能為Zone Apex增加CNAME記錄（DNS協(xié)議的要求），但Alias記錄可以。可以創(chuàng)建Alias的Alias – 指向指針的指針。在Route 53私有托管區(qū)創(chuàng)建Alias記錄時，不能指向Route 53公共托管區(qū)的資源。

用戶可能會選擇非常遠的DNS Resolver完成解析，會導致Route 53的各種路由策略失效。edns-client-subnet，是DNS擴展協(xié)議，允許DNS Resolver把用戶IP地址傳遞給DNS Server；DNS Resolver支持這個協(xié)議，Route 53才會處理用戶IP地址。

Route 53 的Health Check可以對特定資源、CloudWatch的Alarm/Metric以及其它的Health Check進行監(jiān)控；在創(chuàng)建DNS記錄時，可以指定Health Check（并不需要直接相關(guān)），從而實現(xiàn)利用Health Check的結(jié)果進行DNS查詢、躲開出現(xiàn)問題的資源。 

ELB

ELB的大致原理：ELB是AWS-Managed VPC，在Consumer VPC的每個Subnet（需要顯示指定）都會創(chuàng)建1個或多個ENI、進行綁定

對于Internet-facing ELB，將ELB的公有域名解析為彈性IP或公有IP地址（報文在IGW被轉(zhuǎn)換為ENI的私有地址），在VPC內(nèi)部解析也是這樣的，要求部署在Public Subnet。

對于Internal ELB，ELB的域名仍然是公有域名、但解析為這些ENI的私有IP地址，可以部署在Public Subnet或Private Subnet。

由于ELB在動態(tài)伸縮期間會增加/減少ENI及私有IP地址、以及對應的彈性或公有IP地址，因此要求使用ELB的域名、不直接使用IP地址。NLB的ENI及IP地址是固定，可以直接訪問其IP地址。 

CLB是第一代ELB服務，面臨EOX；CLB同時支持HTTPS/HTTP與TCP/SSL監(jiān)聽器；SSL監(jiān)聽器主要用于SSL Offloading，如果不處理SSL終結(jié)和CA證書，就采用TCP 443作為監(jiān)聽器；CLB的HTTPS/HTTP監(jiān)聽器，在應用層HTTP的處理能力非常有限，只支持基本的Sticky Session、SSL Offloading等功能；不支持SNI。

SSL協(xié)商配置（安全策略），在客戶端與ELB之間進行SSL連接的協(xié)商，包括SSL協(xié)議、SSL密碼、順序首選項組合等?？梢圆捎妙A定義安全策略，也可以自定義安全策略。

ALB是針對HTTP/HTTPS優(yōu)化的服務，支持基于URL及HTTP HOST等進行負載均衡；支持SNI，單個IP地址承載多個SSL證書；如果采用目的IP，支持在VPC及ON-premises資源之間進行負載均衡。

NLB是針對TCP優(yōu)化的服務，直接進行HASH、高性能；如果要求Back-end服務器處理SSL終結(jié)及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深度融合實現(xiàn)的。

CLB和ALB支持配置安全組，實際上就是配置Consumer VPC中ENI接口的安全組，作為Internet-facing ELB和Internal ELB時配置安全組的邏輯是不同的；NLB不支持配置安全組，可通過配置Back-end服務器的安全組間接實現(xiàn)。

CLB和ALB在動態(tài)伸縮過程中IP地址會發(fā)生變化，因此在配置Back-end服務器安全組策略時，應基于CLB和ALB采用的安全組（非IP地址）指定規(guī)則。

CLB和ALB支持Logs，NLB不支持Logs。

Connection Draining，在Auto Scaling期間，ELB停止向即將停止運行的EC2實例發(fā)送新的請求，但允許其處理完正在進行的會話，缺省為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時，能夠?qū)崿F(xiàn)跨域訪問（網(wǎng)頁中通過XMLHttpRequest引入一些其它網(wǎng)站的內(nèi)容）。需要配置策略，允許在訪問本網(wǎng)站/網(wǎng)頁時，可以引入其它哪些網(wǎng)站的哪些操作GET/POST等。

 

S3 Transfer Acceleration，利用CloudFront的全球分發(fā)網(wǎng)絡，采用優(yōu)化路徑下載/上載對象。首先在Bucket啟用Transfer Acceleration；采用新的WBB域名（非API域名）- “bucketname.s3-accelerate.amazonaws.com”，定位到最近的Edge節(jié)點，原理與CDN類似。

 

S3 Bucket和Object的IAM策略是分開配置的，用于Web Hosting時，要允許公開訪問。

 

S3 API Endpoint支持Signed-URL能力，大致原理如下：

 

1）外部通過HTTP訪問AWS時（特定URL），需要能識別出發(fā)送它們的客戶，包括驗證請求者身份、防止請求被改動、請求期限等。

2）將請求（URL代表某資源 – 圖片、網(wǎng)頁等），采用HASH做一個Digest，然后用“簽名密鑰”對Digest做一個“數(shù)字簽名”，然后放在HTTP Authorization頭中，或者以查詢字符串的方式放入URL中。

3）將Signed URL發(fā)放給客戶，客戶使用Signed URL進行訪問；AWS收到后，根據(jù)“簽名密鑰”進行解密得到了“原始Digest“，同時做一個“Digest”，如果一致就OK了（知道請求是否被改、以及是誰做的）。

Signed URL與Token的應用場景不同（在不擁有密碼的情況下）：Signed URL，讓“外面的人”在一段時間內(nèi)訪問某“資源、服務”，用URL標識；Token，讓“外面的人”拿到臨時權(quán)限，在一段時間內(nèi)訪問一組資源。

采用S3 Static Web Hosting服務時，如果使用別名，該DNS名稱必須和Bucket名稱相同，這是因為S3 Static Web Hosting要為多個賬戶的多個Bucket提供Static Web Hosting服務，它需要根據(jù)HTTP 報文頭中的HOST字段找到正確的Bucket。 

CloudFront

CloudFront，屬于反向代理（代理服務器），利用了Route 53基于地理的路由策略，返回給請求者最近的資源。

CloudFront支持Web分發(fā)和RTMP分發(fā)。

CloudFront分發(fā)的域名與Origin的域名，是不同的。

通常做法，Origin處理動態(tài)請求，對網(wǎng)頁中的靜態(tài)資源交給CloudFront處理；也可以將動態(tài)請求、靜態(tài)請求全部交給CloudFront。

CloudFront，可以與S3、ELB、EC2及第三方服務器集成；與S3集成時，可以采用OAI實現(xiàn)CloudFront到Origin的訪問控制；與其它資源集成時，可以采用Custom HTTP header實現(xiàn)CloudFront到Origin的訪問控制；做到Origin不別其它CloudFront Distribution及非CloudFront資源所訪問。

提供私有內(nèi)容時，可以采用Signed URL（針對單個文件）或Signed Cookies（針對一組文件），“簽名密鑰”一般是根據(jù)Private Key生成，而非Private Key本身。

使用CloudFront，會給你一個DNS域名，可以直接使用，也可以創(chuàng)建一個友好的CNAME記錄或Alias記錄（如果采用了Route 53），但必須要告訴CloudFront這個DNS域名，因為Cloud Front要根據(jù)HTTP HOST字段信息（友好域名）判斷出請求報文屬于哪一個Distribution。

CloudFront與Viewer之間，可以采用HTTP、HTTPS或Redirect HTTP to HTTPS；CloudFront與Origin之間，可以采用Match Viewer、HTTP或HTTPS。需要在US East注入Certificate，自動擴散到全球所有區(qū)域。

Lambda@Edge，處理時機為viewer request，origin request，origin response，viewer response；使用場景為檢查cookie、重寫URL、動態(tài)修改Custom HTTP Header或進行A/B測試（新興的網(wǎng)頁優(yōu)化方法，一部分客戶訪問A，一部分客戶訪問B，通過兩種方案的優(yōu)劣）。

使用CloudFront的Geoblocking功能：使用GeoIP數(shù)據(jù)庫，確定用戶位置，準確率99.8%；在Web Distribution的Restrictions中，配置Geo Restriction中的Whitelist和Blacklist；如果不符合，CloudFront返回403（禁止）。

使用第三方地理定位服務（需要Origin服務器支持）：將內(nèi)容上傳S3 Bucket，使用OAI，通過CloudFront提供私有內(nèi)容；編寫Web應用程序，根據(jù)用戶IP，調(diào)用地理定位服務；如果允許，為CloudFront分發(fā)的內(nèi)容提供Signed URL（用戶請求抵達CloudFront后，判斷Signed URL）；如果不允許，返回403。

ACM – AWS Certificate Manager

AWS管理TLS證書的服務，支持CloudFront、ELS、Elastic Beanstalk和API Gateway等；可以創(chuàng)建CA證書，或?qū)肽愕淖C書到ACM中；ACM提供的CA證書，13個月有效，自動RENEW。ACM是Regional級別的，在各Region單獨處理；對于CloudFront的證書，需要在US East（NV）集中處理。

AWS WAF

WEB應用防火墻，與CloudFront和Application ELB集成，監(jiān)控HTTP/HTTPS的請求，采用一些定制化的規(guī)則和模式，實施保護。采用WEB ACL進行控制（定義一些Conditions），根據(jù)IP地址、URI、HTTP報頭及正文（某些JSP腳本）、地理位置、特定字符串等進行過濾，然后執(zhí)行一些規(guī)則（rule）。

AWS Shield

標準服務，針對常見的Attack，SYN/UDP泛洪，L3/4層，沒有費用，永遠在線，動態(tài)應對變化。

高級服務，針對Route 53托管區(qū)、CloudFront的分發(fā)、ELB等，L7層，實施提供Attack信息。企業(yè)上云后，水平擴展的應用，可以消化DOS；但是通過賬單，可以看到誰被Attack了（EDOS、經(jīng)濟上遭受DOS）；DOS不會影響你的網(wǎng)絡，但會影響你的費用。Shield高級服務，針對DOS Attack，提供成本保護，但只針對Route 53托管區(qū)、CloudFront的分發(fā)、ELB等服務。遭受Attack后，你可以實施AWS WAF（采用Shield高級服務，這個免費）；也可以與DRT（DOS處理團隊）聯(lián)系，識別Attack模式；DRT團隊協(xié)助你部署AWS WAF，你需要提供Cross-account的IAM角色。

GuardDuty

智能威脅檢測服務，監(jiān)控和保護你的AWS的Account及Wordload。分析大量數(shù)據(jù)（利用CloudTrail、VPC Flow Logs、DNS Logs等），不需要探針、不會對負載的可用性及性能造成影響。整體分析，包括賬戶。

Inspector

分析VPC環(huán)境、識別安全問題智能威脅檢測服務。EC2實例要安裝Inspector Agent，監(jiān)控操作系統(tǒng)和應用程序的行為。針對VPC及EC2。

Macie

使用機器學習ML，發(fā)現(xiàn)、分類和保護敏感數(shù)據(jù)，主要針對S3存儲的數(shù)據(jù)。

Xen虛擬化與Enhanced Networking

Xen負責CPU及內(nèi)存，Dom0負責虛擬機管理和I/O虛擬化；Xen，運行的Bare-metal上的，Dom0就相當于主機OS、特權(quán)虛擬機，同時支持PV和HVM；支持HVM（硬件虛擬化、需要VT-x/d）和PV（半虛擬化，改動Guest OS內(nèi)核、將敏感指令改為功能調(diào)用）。Xen的幾種運行模式：

1）PV模式（半虛擬化、全軟件模擬）：不需要CPU支持虛擬化，修改Guest OS內(nèi)核，完成CPU及內(nèi)存虛擬化；I/O請求發(fā)給Dom0的真實設備驅(qū)動；

2）PV on HVM模式（全虛擬化、硬件模擬，但IO采用軟件模擬）：芯片完成對CPU及內(nèi)存虛擬化的支持，I/O請求發(fā)給Dom0的真實設備驅(qū)動（修改Guest OS的IO驅(qū)動程序、缺省支持一些標準的vNIC及驅(qū)動程序），繞過了KVM的全虛擬化I/O階段，對應virto方案。

3）SR-IOV PCI passthrough直通模式（前提是HVM），利用Intel VT-d，將PF/VF直接分配給Guest OS。

PV AMI和HVM AMI啟動方式不同：HVM AMI，直接利用MBR啟動，可繼續(xù)安裝PV網(wǎng)絡驅(qū)動（主要針對增強聯(lián)網(wǎng)SR-IOV），提升I/O性能。PV AMI，利用PV-GRUB、要加載menu.list到OS內(nèi)核。

增強聯(lián)網(wǎng)：就是使用了SR-IOV的實例類型，需要主機的硬件支持，只有支持HVM的實例類型才支持增強聯(lián)網(wǎng)。VPC及Internet支持單流5Gbps（在Place Group內(nèi)可達到10Gbps），多流最多10Gbps或25Gbps（取決于硬件網(wǎng)卡Intel 52999或ENA）。

啟用增強聯(lián)網(wǎng)需要AMI支持（AMI不啟用、不安裝驅(qū)動，所有VM只能使用PF）。對于采用Intel 52999的實例類型：AMI安裝使用Inter ixgbevf驅(qū)動程序、并設置sriovNetSupport屬性（最新的AMI都已經(jīng)設置完成）；對于采用ENA的實例類型：AMI安裝使用ena驅(qū)動程序、并設置enaSupport屬性屬性（最新的AMI都已經(jīng)設置完成）。

Cloud Formation

用軟件程序描述基礎(chǔ)設施，用AWS CodeCommit或GitHub管理版本，用CloudFormation進行部署，采用CodePipeline進行端到端協(xié)同。

validation錯誤，拼寫及格式問題、預處理就可發(fā)現(xiàn)問題，不涉及rollback。

semantic錯誤，只有在資源實際創(chuàng)建時才能發(fā)現(xiàn)，需要rollback。

引用DependsOn，會影響創(chuàng)建的順序。

Retaining Resource：在Template定義資源時將DeletionPolicy設置為Retain，在Stack被刪除時保留。

采用新的Template進行Update，可能會Delete、Replace一些資源。在創(chuàng)建Stack時提供JSON文件，定義這些策略（Disable Update:Delete或Update:Replace），防止資源被新Template刪除。

Change Sets：針對當前的Stack，創(chuàng)建Change Set，看差別，然后執(zhí)行；幫助管理Stack的升級，防止Update具備破壞性。具體提供1個新配置文件，在部署之前，與運行的Stack進行對比，提供Change、可視化，最后是excute。

配置Non-AWS資源：CloudFormation可以創(chuàng)建Custom Resource。在CloudFormation執(zhí)行Template、創(chuàng)建Custom Resource的時候，可以通過SNS發(fā)送消息（提醒人、進行手工操作），或者Invoke Lambda函數(shù)（通過Python和SSH配置客戶側(cè)的CGW）；然后CloudFormation提供一個Signed URL，你可以來用反饋資源創(chuàng)建結(jié)果（ID、Status）。通過這種方式，CloudFormation把非Non-AWS資源也管理起來。

應該為CloudFormation創(chuàng)建一個Service Role，去創(chuàng)建/更改/刪除Stack；或者采用Caller的IAM權(quán)限。

CodeCommit – CI，托管的源代碼控制服務（私有Git存儲庫），仍可以使用Git的CLI，實施版本管理。新特性采用分支版本，避免沖突；證實無誤后，合入主線。

CodePipeline – CD，快速地部署Update，Build – Test – Deploy，SaaS類產(chǎn)品，完全兼容Jenkins的能力和使用習慣，就是將Jenkins上云、以SaaS形式對外提供服務。CodePipeline可以響應來自CodeCommit的觸發(fā)器，定期檢查。

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網(wǎng)關(guā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種細分場景和實現(xiàn)方案

方案1：兩個信任的VPC之間通過VPC Peering直接互聯(lián)，并且靜態(tài)路由的優(yōu)先級高于V_P_N及BGP，繞過Transit VPC Hub。  

方案2： 相互信任，On-premises通過Private VIF及Direct Connect Gateway直接連接VGW及Spoke VPC，AS_Path短，路由優(yōu)先級高，繞過Transit VPC Hub。

方案3：Transit Hub VPC與遠端VPC通過VPC Peering互聯(lián)（提供高帶寬），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

網(wǎng)絡相關(guān)的3種費用：服務/端口小時費，數(shù)據(jù)處理費用，數(shù)據(jù)傳送費。

V_P_N Connections：按Connection-Hour收費，還有數(shù)據(jù)傳輸費用（離開AWS方向）。

Direct Connect：按Port-Hour收費，還有數(shù)據(jù)傳輸費用（離開AWS方向）；對于Hosted Connection ，只要Accept，就開始Port-Hour收費；對于Hosted VIF，接收者支付Data Transfer相關(guān)費用，Port-Hour還是由Owner支付。

Data Transfer - Internet，在AWS Internet與Internet之間的（假設你通過Internet訪問AWS）；流入AWS Internet不收費，流出AWS Internet為$0.09/GB（由被訪問資源的擁有者支付費用），這涉及AWS Internet與其它Internet之間的網(wǎng)間結(jié)算問題。

Data Transfer - Region to Region，在AWS Internet與AWS Internet之間的，入方向不收費，流出方向$0.02/GB。

CloudFront：從Edge到User正常收費；Origin在AWS網(wǎng)絡，從Origin到CloudFront的流量，不收費；上載數(shù)據(jù)，需要收費，$0.02/GB。

Data Transfer - Same Region，與同一區(qū)域AWS公有服務之間的流量，沒有Data Transfer費用（但是AWS公有服務本身收費）；訪問不同區(qū)域AWS公有服務，包括AWS服務費及數(shù)據(jù)傳輸費。

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方向）。

 

相關(guān)白皮書及博客的連接： 

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/

三、AWS戰(zhàn)略的簡要分析

AWS已經(jīng)建設了一張覆蓋全球的IP骨干網(wǎng)，連接了所有的Region（中國和美國政務云除外），便于企業(yè)快速在全球?qū)ν馓峁I(yè)務，同時實現(xiàn)企業(yè)內(nèi)部業(yè)務的互聯(lián)。

AWS與全球上百家區(qū)域運營商合作，將PoP點下移，通過Direct Connect服務就近接入企業(yè)客戶，實現(xiàn)企業(yè)客戶高質(zhì)量、低成本上云，構(gòu)建混合云、訪問AWS公共服務、對外提供服務。

通過全球IP骨干網(wǎng)以及Direct Connect，結(jié)合提供的各種云服務，AWS基本就構(gòu)建了一個端到端的閉環(huán)系統(tǒng)，企業(yè)只要接入AWS、流量就可以在AWS內(nèi)部消化掉。當然企業(yè)對外提供業(yè)務，仍要借助于AWS Internet與其它Internet的互聯(lián)互通。

最近有傳言說，AWS要開發(fā)一些企業(yè)側(cè)的盒子，這應該是很正常的。目前AWS提供Direct Connect及V_P_N服務，要對接On-premises的十幾個供應商的數(shù)十款軟硬件產(chǎn)品，這些產(chǎn)品的能力、配置參數(shù)等都不同；與其在云端不斷地去適配這些產(chǎn)品，換個思路就是提供自己的盒子、對技術(shù)做歸一化；同時在On-premises有自己的盒子作為抓手，可以推出一些更有競爭力的混合云服務，包括路由能力、安全加密能力、可靠性、DNS解析、存儲方案等能力提升。

 

隨著傳統(tǒng)企業(yè)上云步法加快，云計算對整個通信行業(yè)會產(chǎn)生深遠的影響。

對運營商市場的影響：企業(yè)上云后，其內(nèi)部互聯(lián)自然會從傳統(tǒng)MPLS V_P_N轉(zhuǎn)向云專線，云專線的開通速度和業(yè)務集成要遠優(yōu)于MPLS V_P_N；可以預見長途專線市場將從運營商向云服務商轉(zhuǎn)移，云服務商仍依賴運營商提供的本地專線、接入客戶；未來在個人或消費互聯(lián)網(wǎng)領(lǐng)域運營商仍占據(jù)領(lǐng)先地位，但具備全球覆蓋能力的云服務商將主導高價值的企業(yè)互聯(lián)網(wǎng)。

對企業(yè)市場的影響：企業(yè)上云后，必將逐步減少對傳統(tǒng)IT及網(wǎng)絡設備的投資以及長途線路租用，轉(zhuǎn)而消費云服務；由于規(guī)模經(jīng)濟和高效率，每在云端消費1$，將減少4$的On-premises投資，傳統(tǒng)設備制造商和軟件供應商的市場空間會逐步被蠶食；多數(shù)企業(yè)網(wǎng)絡最終會演進成為家庭接入模型。

同時云計算也會對通信行業(yè)帶來一些新的機會。相比傳統(tǒng)的On-premises，云端出于安全性及可靠性的考慮做出很多的功能限制；對于企業(yè)客戶一些定制化的需求，需要引入各類VNF組件、搭建Overlay網(wǎng)絡，包括負載均衡、路由器、V_P_N網(wǎng)關(guān)、V_P_N接入服務器、防火墻、WEB防火墻、NAT等等；已有眾多的傳統(tǒng)設備制造商及新型廠家投入到這一領(lǐng)域，推出了相應的軟件化產(chǎn)品，并與主流的云服務平臺進行了集成。

下圖為未來的一個跨國公司的企業(yè)數(shù)字化基礎(chǔ)設施平臺，除了本地接入資源外，企業(yè)的IT、軟件及網(wǎng)絡等資源將全部構(gòu)建于公有云平臺之上。

關(guān)于AWS考試預約，深圳邁瑞思考場預約說明如下，考場咨詢熱線：0755-29152000

關(guān)于AWS考試預約，深圳邁瑞思考場預約說明如下，考場咨詢熱線：0755-29152000

http://www.myruisi.com/exam/d30f9053-3382-4e1c-bd1e-5198cc0881e6.html