BGP的結構和功能

BGP用於在不同的自治系統（AS）之間交換路由資訊, 處理不相關 間的多路連線的協議 。當兩個AS需要交換路由資訊時，每個AS都必須指定一個執行BGP的節點，來代表AS與其他的AS交換路由資訊。這個節點可以是一個主機。但通常是路由器來執行BGP。兩個AS中利用BGP交換資訊的路由器也被稱為邊界閘道器（Border Gateway）或邊界路由器（Border Router）。

AWS WAF - Web Application Firewall

AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF gives you control over which traffic to allow or block to your web applications by defining customizable web security rules. You can use AWS WAF to create custom rules that block common attack patterns, such as SQL injection or cross-site scripting , and rules that are designed for your specific application. New rules can be deployed within minutes, letting you respond quickly to changing traffic patterns. Also, AWS WAF includes a full-featured API that you can use to automate the creation, deployment, and maintenance of web security rules.

AWS WAF pricing is based on how many rules you deploy and how many web requests your web application receives . There are no upfront commitments.

You can deploy AWS WAF on either Amazon CloudFront as part of your CDN solution or the Application Load Balancer (ALB) that fronts your web servers or origin servers running on EC2. 

Benefit: 

Increased Protection Against Web Attacks

Security Integrated with How You Develop Applications

Ease of Deployment & Maintenance

Improved Web Traffic Visibility

Cost Effective Web Application Protection

Refer to:

Route53

您可以將 DNS 與執行狀況檢查服務組合使用，路由流量到執行正常的終端節點，或者獨立監控終端節點和/或對其提供警報。

LBR（基於延遲的路由）是 Amazon Route 53 的一項新功能，有助於您提高應用程式對全球受眾的效能。您可以在多個 AWS 地區執行應用程式，Amazon Route 53 則透過其遍佈全球的節點將終端使用者路由到可提供最低延遲性的 AWS 地區。

Refer to: 

Amazon CloudFront

Amazon CloudFront 是 AWS 的 CDN，是一個用於加快將靜態和動態的 Web 內容（如: .html, css, .js, 圖片檔案）分發給使用者的Web 服務。

比如你在中國，想請求一張 Web 伺服器位於美國的圖片，在檢索到圖片之前，這個請求會從一個網路路由到另一個網路，在經歷 n 多個路由後，才能到達該圖片所在的伺服器，這是一個非常大的跳數，同時會對效能、可用性和可靠性產生很大影響。但是如果將原始伺服器與 CloudFront 關聯（關聯後 CloudFront 知道從哪些原始伺服器獲取資源），這時不再透過原始伺服器訪問圖片，而是 透過 CloudFront 分配的 URL 訪問圖片，則該請求將被路由到遲延最短的 CloudFront 邊緣站點 。如果該內容在遲延最短的 CloudFront 邊緣站點的快取中存在，則將直接從該邊緣站點的快取中返回圖片。如果請求的內容不在該邊緣站點的快取中，才從源去取（請求的內容不在快取中，這裡寫的比較籠統，這種情況下 CloudFront 是如何工作的，詳細工作流程，見下面 Note 的解釋）。這樣大大減少了路由數，從而提高了效能。

Note：如果請求的內容不在遲延最短的邊緣站點的快取中，CloudFront 的處理如下：

① CloudFront 將比較該請求與分配中的說明，然後根據對應的檔案型別將檔案請求轉發到適用的源伺服器。例如，對於影像檔案，轉發到 Amazon S3 儲存桶；對於 HTML 檔案，轉發到 HTTP 伺服器。

② 原始伺服器將這些檔案發回 CloudFront 邊緣站點。

③ 當從源返回的第一個位元組到達 CloudFront 時，CloudFront 就開始將這些檔案轉發給使用者，同時將這些檔案新增到邊緣站點的快取中，方便有人再次請求這些檔案。

Refer to: https://blog.csdn.net/u011886447/article/details/79070197

關於EBS磁碟的IOPS,以及IOPS是如何測量的

IOPS就是每秒的讀寫操作。 亞馬遜EBS使用16KB的快大小來衡量EBS的IO表現。

當你建立一塊預設IOPS為4000的EBS磁碟，並把他掛載到最佳化EBS的例項上（EBS-optimized instance，最佳化EBS的EC2例項連結EBS的IO通道是是專用的，可以保證足夠的IO頻寬），你可以每秒傳輸4000個16KB大小的塊。（這樣大概IO頻寬就是62.5MBps，或者500Mbps）(這個IOPS 4000就是這個衡量出來的)。 

當塊大小大於16KB是，你的IOPS數值就變小，但是此時例項到EBS的IO頻寬還是等於你傳輸16KB塊對應IOPS數值時候的表現。當操作的塊大小為16KB或者更小時，你能得到你預設的IOPS數值的表現。對於更小的塊操作，你可能會看到超過你預設的IOPS數值的表現（在客戶端測量時），這是因為有的客戶端會將小的快合併成一個16KB大小的塊來傳輸。 

如果你得到的IOPS數值小於你預設的IOPS，這可能是因為你的 EC2例項頻寬是IO效能的瓶頸 ：你的例項得是EBS最佳化型例項，或者是擁有明確標註為10Gbps的網路卡的型別的例項，而且你的EBS磁碟的IO頻寬至少得超過你預設的IOPS。另一個你沒有得到你預設的IOPS數值的原因很可能是因為你讀寫操作次數根本就沒達到磁碟的上限，這樣也就沒法測量出EBS卷的真實IOPS表現。

DynamoDB中的二級索引(global secondary index)

Refer to:  https://blog.csdn.net/vikings_1001/article/details/48675945

IPSEC Tunnel

IPSec VPN是目前VPN技術中點選率非常高的一種技術，同時提供VPN和資訊加密兩項技術。

IPSec VPN的應用場景分為3種：
1. Site-to-Site（站點到站點或者閘道器到閘道器）：如灣區評論的3個機構分佈在網際網路的3個不同的地方，各使用一個閘道器相互建立VPN隧道，企業內網（若干PC）之間的資料透過這些閘道器建立的IPSec隧道實現安全互聯。
2. End-to-End（端到端或者PC到PC）： 兩個PC之間的通訊由兩個PC之間的IPSec會話保護，而不是閘道器。
3. End-to-Site（端到站點或者PC到閘道器）：兩個PC之間的通訊由閘道器和異地PC之間的IPSec進行保護。

VPN只是IPSec的一種應用方式，IPSec其實是IP Security的簡稱，它的目的是為IP提供高安全性特性，VPN則是在實現這種安全特性的方式下產生的解決方案。 IPSec是一個框架性架構，具體由兩類協議組成：
1. AH協議（Authentication Header，使用較少）：可以同時提供資料完整性確認、資料來源確認、防重放等安全特性；AH常用摘要演算法（單向Hash函式）MD5和SHA1實現該特性。
2. ESP協議（Encapsulated Security Payload，使用較廣）：可以同時提供資料完整性確認、資料加密、防重放等安全特性；ESP通常使用DES、3DES、AES等加密演算法實現資料加密，使用MD5或SHA1來實現資料完整性。

為何AH使用較少呢？ 因為AH無法提供資料加密，所有資料在傳輸時以明文傳輸，而ESP提供資料加密；其次AH因為提供資料來源確認（源IP地址一旦改變，AH校驗失敗），所以無法穿越NAT 。當然，IPSec在極端的情況下可以同時使用AH和ESP實現最完整的安全特性，但是此種方案極其少見。

IPSec封裝模式介紹完IPSec VPN的場景和IPSec協議組成，再來看一下IPSec提供的兩種封裝模式（傳輸Transport模式和隧道Tunnel模式）

可以發現傳輸模式和隧道模式的區別：
1. 傳輸模式在AH、ESP處理前後IP頭部保持不變，主要用於End-to-End的應用場景。
2. 隧道模式則在AH、ESP處理之後再封裝了一個外網IP頭，主要用於Site-to-Site的應用場景。

從上圖我們還可以驗證上一節所介紹AH和ESP的差別。下圖是對傳輸模式、隧道模式適用於何種場景的說明。

從這張圖的對比可以看出：
1. 隧道模式可以適用於任何場景
2.  傳輸模式只能適合PC到PC的場景
隧道模式雖然可以適用於任何場景，但是隧道模式需要多一層IP頭（通常為20位元組長度）開銷，所以在PC到PC的場景，建議還是使用傳輸模式。
為了使大家有個更直觀的瞭解，我們看看下圖，分析一下為何在Site-to-Site場景中只能使用隧道模式：

如上圖所示，如果發起方內網PC發往響應方內網PC的流量滿足閘道器的興趣流匹配條件，發起方使用傳輸模式進行封裝：
1. IPSec會話建立在發起方、響應方兩個閘道器之間。
2. 由於使用傳輸模式，所以IP頭部並不會有任何變化，IP源地址是192.168.1.2，目的地址是10.1.1.2。
3. 這個資料包發到網際網路後，其命運註定是杯具的，為什麼這麼講，就因為其目的地址是10.1.1.2嗎？這並不是根源，根源在於網際網路並不會維護企業網路的路由，所以丟棄的可能性很大。
4. 即使資料包沒有在網際網路中丟棄，並且幸運地抵達了響應方閘道器，那麼我們指望響應方閘道器進行解密工作嗎？憑什麼，的確沒什麼好的憑據，資料包的目的地址是內網PC的10.1.1.2，所以直接轉發了事。
5. 最杯具的是響應方內網PC收到資料包了，因為沒有參與IPSec會話的協商會議，沒有對應的SA，這個資料包無法解密，而被丟棄。
我們利用這個反證法，巧妙地解釋了在Site-to-Site情況下不能使用傳輸模式的原因。並且提出了使用傳輸模式的充要條件：興趣流必須完全在發起方、響應方IP地址範圍內的流量。比如在圖中，發起方IP地址為6.24.1.2，響應方IP地址為2.17.1.2，那麼興趣流可以是源6.24.1.2/32、目的是2.17.1.2/32，協議可以是任意的，倘若資料包的源、目的IP地址稍有不同，對不起，請使用隧道模式。

IPSec協商

IPSec除了一些協議原理外，我們更關注的是協議中涉及到方案制定的內容：
1. 興趣流：IPSec是需要消耗資源的保護措施，並非所有流量都需要IPSec進行處理，而需要IPSec進行保護的流量就稱為興趣流，最後協商出來的興趣流是由發起方和響應方所指定興趣流的交集，如發起方指定興趣流為192.168.1.0/24à10.0.0.0/8，而響應方的興趣流為10.0.0.0/8à192.168.0.0/16，那麼其交集是192.168.1.0/24à10.0.0.0/8，這就是最後會被IPSec所保護的興趣流。
2. 發起方：Initiator，IPSec會話協商的觸發方，IPSec會話通常是由指定興趣流觸發協商，觸發的過程通常是將資料包中的源、目的地址、協議以及源、目的埠號與提前指定的IPSec興趣流匹配模板如ACL進行匹配，如果匹配成功則屬於指定興趣流。指定興趣流只是用於觸發協商，至於是否會被IPSec保護要看是否匹配協商興趣流，但是在通常實施方案過程中，通常會設計成發起方指定興趣流屬於協商興趣流。
3. 響應方：Responder，IPSec會話協商的接收方，響應方是被動協商，響應方可以指定興趣流，也可以不指定（完全由發起方指定）。
4. 發起方和響應方協商的內容主要包括：雙方身份的確認和金鑰種子重新整理週期、AH/ESP的組合方式及各自使用的演算法，還包括興趣流、封裝模式等。
5. SA：發起方、響應方協商的結果就是曝光率很高的SA，SA通常是包括金鑰及金鑰生存期、演算法、封裝模式、發起方、響應方地址、興趣流等內容。

我們以最常見的IPSec隧道模式為例，解釋一下IPSec的協商過程：

上圖描述了由興趣流觸發的IPSec協商流程，原生IPSec並無身份確認等協商過程，在方案上存在諸多缺陷，如無法支援發起方地址動態變化情況下的身份確認、金鑰動態更新等。伴隨IPSec出現的IKE（Internet Key Exchange）協議專門用來彌補這些不足：
1. 發起方定義的興趣流是源192.168.1.0/24目的10.0.0.0/8，所以在介面傳送發起方內網PC發給響應方內網PC的資料包，能夠得以匹配。
2. 滿足興趣流條件，在轉發介面上檢查SA不存在、過期或不可用，都會進行協商，否則使用當前SA對資料包進行處理。
3. 協商的過程通常分為兩個階段，第一階段是為第二階段服務，第二階段是真正的為興趣流服務的SA，兩個階段協商的側重有所不同，第一階段主要確認雙方身份的正確性，第二階段則是為興趣流建立一個指定的安全套件，其最顯著的結果就是第二階段中的興趣流在會話中是密文。

IPSec中安全性還體現在第二階段SA永遠是單向的：

從上圖可以發現，在協商第二階段SA時，SA是分方向性的，發起方到響應方所用SA和響應放到發起方SA是單獨協商的，這樣做的好處在於即使某個方向的SA被破解並不會波及到另一個方向的SA。這種設計類似於雙向車道設計。
IPSec雖然只是5個字母的排列組合，但其所涉及的協議功能眾多、方案又極其靈活，本期主要介紹IPSec的基本原理，在後續專欄還會繼續介紹IPSec的其它方面知識。

Refer to:  https://blog.csdn.net/Walking_Thinker/article/details/79127902

AWS Management Portal for vCenter

Option 1: Federation Authentication Proxy

You can set up the management portal to authenticate users using the AWS Connector for vCenter.

Your users don't have direct access to AWS resources. Instead, the vSphere client gets the user's information from your vCenter server and assumes an AWS Identity and Access Management (IAM) role to get temporary AWS security credentials for the user. The following diagram illustrates this process.

Federation authentication proxy

1. The user signs in to vCenter, clicks  Home , and then clicks  AWS Management Portal . The vSphere client sends an authentication request to the connector.

2. The connector authenticates the user.

3. The connector requests temporary security credentials from AWS Security Token Service (AWS STS).

4. AWS STS sends the connector temporary security credentials for the user.

5. Users are granted access to AWS resources based on the permissions assigned to them by an administrator.

Option 2: SAML-Based Authentication

You can set up the management portal to authenticate users using your identity provider (IdP).

Your users don't have direct access to AWS resources. Instead, the vSphere client gets the user's information from your identity store and uses a SAML assertion to grant the user access to AWS Management Portal for vCenter. The following diagram illustrates this process.

SAML-based authentication

1. The user signs in to vCenter, clicks  Home , and then clicks  AWS Management Portal . The vSphere client sends an authentication request to the IdP.

2. The IdP authenticates the user.

3. The IdP generates a SAML authentication response that includes assertions that identify the user and provide information about the user.

4. The vSphere client posts the SAML assertion to an AWS single sign-on (SSO) endpoint. The endpoint requests temporary security credentials from AWS Security Token Service (AWS STS) and creates a console sign-in URL.

5. AWS sends the console a sign-in URL to the vSphere client with a redirect.

6. The management portal grants users access to AWS resources based on the permissions assigned to them by an administrator.
   

Refer to: 

Amazon S3: Allows IAM Users Access to Their S3 Home Directory, Programmatically and In the Console

Refer to: 

https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/

AWS services that support Signature Version 2

Amazon EC2 Auto Scaling

AWS CloudFormation

Amazon CloudWatch

AWS Elastic Beanstalk

Amazon Elastic Compute Cloud (Amazon EC2)

Elastic Load Balancing

Amazon EMR

Amazon ElastiCache

AWS Identity and Access Management (IAM)

AWS Import/Export

Amazon Relational Database Service (Amazon RDS）

Amazon Simple Notification Service (Amazon SNS)

Amazon Simple Queue Service (Amazon SQS)

Amazon SimpleDB

SignatureMethod

The hash-based protocol used to calculate the signature. This can be either HMAC-SHA1 or HMAC-SHA256 for Signature Version 2.

SignatureVersion

The version of the AWS signature protocol.

Refer to:  

AWS Well architecutre 

S3是大規模的物件儲存，EFS是檔案體統 ，支援NFS等協議。