AWS re:Invent 2019 Day 2

Global Infrastructure

AWS Local Zone

從現在起 AWS Global Infrastructure 除了 Region、AZ 外，在 AZ 之下又多了 Local Zone (LZ)，提供一個相對 AZ 又更貼近於使用者、延遲更低、響應速度更快的部署目標。

第一個 Local Zone (LZ) 為於洛杉磯，區域代號為 us-west-2-lax-1a ，提供使用者延伸 VPC Resources：EC2 Instances (T2, C5, M5, R5, R5d, I3en, G4)、EBS (io1, gp2)、FSx、ALB 至洛杉磯，更貼近當地 End-User，也將於 2020 在 LAX 洛杉磯部署第二個 Local Zone us-west-2-lax-1b。

相信未來全球各地會有更多的 Local Zone 出來，集結拓展為下一代基礎建設。

參考來源至：AWS Local Zones

Instance Computing

New Instance Type: Ifn1, M6g, R6g, C6g

搭載 AWS Inferentia 晶片的 Inf1 Intstance，針對機器學習運算、成本做優化，和同等級運算效能之 G4 Instance 相比，成本約降低 40%。

搭載最新 Arm-based AWS Graviton2 Processor，和現行 x86-based M5/R5/C5 相比，效能約提升40%，約在 2020 Q1 GA。

SPECjvm® 2008: +43% (estimated)
SPEC CPU® 2017 integer: +44% (estimated)
SPEC CPU 2017 floating point: +24% (estimated)
HTTPS load balancing with Nginx: +24%
Memcached: +43% performance, at lower latency
X.264 video encoding: +26%
EDA simulation with Cadence Xcellium: +54%

參考來源至：Graviton2-Powered General Purpose, Compute-Optimized, & Memory-Optimized EC2 Instances

AWS Compute Optimizer

在諸多 Well-Architect 案例中為了做效能優化、成本優化，時常透過 Monitoring 確定 EC2 Instances 運作情況、是否需要更換 Instance Type、是否 Over-provisioning 或是 Under-provisioning …等考量。

AWS Compute Optimizer 以機器學習方式分析 Account 中過往 EC2 使用狀況，來源自 CloudWatch 所記錄 Metrics，不論是 Built-in Metrics 或者是透過 CloudWatch Agent 推中之 Custom Metrics，進一步分析、判斷 Instances 是否需要調整、可以升級/降級至哪個 Instance Type。

現已正式發布、並支援以下 Region：US East (N. Virginia), US West (Oregon), Europe (Ireland), US East (Ohio), South America (São Paulo)。

更重要的是此服務為免費使用！強烈建議若有部署 EC2 Instances 在支援 Regions，可以立即嚐鮮看看效果。

參考來源至：Introducing AWS Compute Optimizer

AWS Outposts

在去年引起熱烈討論的 Outposts 終於正式發布！

機房管理員往往在維護、安裝、更新實體伺服器花費許多心思、時間，現在只需要透過 AWS Console 選定規格、發送請求，AWS 便會到府安裝並接手處理這些維運行為；若後續有要更新升級，也能透過 Console 提出申請。

使用須知如下：

支援服務：
- Nitro-basd EC2 Instance Type – C5, C5d, M5, M5d, R5, R5d, G4, I3en
- EBS – gp2
- ECS
- EKS
- EMR
- Amazon RDS for PostgreSQL (Preview)
- Amazon RDS for MySQL (Preview)
支援地區：
- North America (United States)
- Europe (All EU countries, Switzerland, Norway)
- Asia Pacific (Japan, South Korea, Australia)
Support Plan 須為 Enterprise
Billing & Payment Options – 須購買三年長度，付費方式有 All Upfront, Partial Upfront, and No Upfront，細節請參考 AWS Outposts pricing

參考來源至：AWS Outposts Now Available – Order Yours Today!

Container

Fargate for EKS !!

從 re:Invent 2017 發布 Fargate 時，便提及會同時支援 ECS & EKS 兩大Container服務；等了兩年的時間，終於正式GA支援EKS！

在目前廣為使用部署 EKS Cluster 的工具 eksctl 也及時發布版本更新，支援以 Fargate 作為 pods 的部署單位：

eksctl create cluster --name demo-newsblog --region us-west-2 --fargate

在 EKS Cluster Console 中也可以透過 Fargate Profile 宣告當 pods 部屬時所需要的 Fargate 資源。

參考來源至：Amazon EKS on AWS Fargate Now Generally Available

Fargate Spot

AWS 現在正式推出 Fargate Spot，可節省高達 70% 的費用！

如同 EC2 Spot 的原理，AWS 運用可用的備用運算資源，當 Spot 的價格符合出價，可在 Fargate Spot Instance 上運行允許可被中斷的任務，然而，當 AWS 將要收回該 Spot Instance 時，會有 2 分鐘的警示時間。雖然 Spot Instance 隨時有可能被收回，但 Fargate 仍會確保每個 Service 有最少常規數量的 Task 仍然運行中，以維持應用程式的高度可用性。

此外也可以搭配先前推出的 Savings Plans，作為成本估算的策略之一。

建議搭配 Fargate 來運行最低的常規使用量，其餘可能額外、Scale 出來的用量使用 Fargate Spot 來填補，搭配兩者使用以節省更多費用。
設定好 Cluster 內的 capacity provider strategy 後，執行 Run Task / Service，運行後可以在 Details 確認Task Capacity Provider。

參考來源至：AWS Fargate Spot Now Generally Available

ECS Capacity Providers

以往可以使用 Launch Type 來控制 Task 是否使用 EC2 或 Fargate，並且可以使用位置限制（placement constraints）和放置策略（placement strategies）來控制 Task 的位置，但是，只有已經可用的容量，例如：已經運行的 EC2 Instance）才能用來執行 Task，而且位置限制和策略也只會考慮已經可用的容量。

隨著 Capacity Providers 的推出，可讓應用程式定義容量使用方式的需求，並針對容器化工作負載如何在不同類型的運算容量上執行，定義彈性規則，以及管理容量擴展。

Capacity Providers 支援 EC2 及 Fargate 型態。若用使用 EC2 類型，可指定 Auto Scaling Group 作為 Capacity Providers，確保即使尚未可用，仍需要執行工作所需的容量；若使用 Fargate 類型，則可指定 Fargate 和 Fargate Spot。此外，也可以預先定義執行 Task 的分割百分比，或確保服務在多個可用區域中執行相同數量的任務。

在 Cluster 中可以從 Capacity Provider 看到 Cluster 內能使用的類型，並點擊右上角的 Update Cluster 來設定 Capacity Provider strategy。若使用的是 EC2 類型，則可點擊 Create，用特定 ASG 來創建 Capacity Provider。

若使用的是 Fargate 類型，可在同一個 Cluster 內，同時使用 Fargate 或 Fargate Spot，並可設定 weight 來指定運行時的比例；或是設定 base 來指定該種 Capacity Provider 最低運行的數量，但一個 Cluster 中，只有一個 Capacity Provider 的 base 可設定大於 0。

如為現有 Cluster，須先透過 aws ecs put-cluster-capacity-providers 更新 Default Capacity Provider，再透過 aws ecs update-service --force-new-deploymeny 強制重新部署既有 ECS Service

## Update cluster capacity providers with Fargate and Fargate Spot
aws ecs put-cluster-capacity-providers \
    --cluster cluster_name \
    --capacity-providers FARGATE FARGATE_SPOT \
    --default-capacity-provider-strategy capacityProvider=FARGATE_SPOT,weight=1 \
    --region us-west-2

## Update services run with Fargate and Fargate Spot
aws ecs update-service --capacity-provider-ttrategy capacityProvider=FARGATE_SPOT,weight=1 --force-new-deploymeny

參考來源至：Amazon ECS Capacity Providers Now Available

參考來源至：Documentation – Amazon ECS Cluster Capacity Providers

ECS Cluster Auto Scaling

以往，ECS 無法直接管理 ASG 的擴展，使用者必須在 ECS 之外手動設定 ASG 的擴展原則，而可用於縮放的數量並未考慮所需的工作計數，只考慮正在執行的工作。透過 ECS Cluster Auto Scaling，使用者可以設定 Capacity Providers 以啟用 ASG 的管理擴展、保留 ASG 中的多餘容量，以及管理 ASG 中執行個體的終止。

參考來源至：Amazon ECS Cluster Auto Scaling Now Available

Serverless

Step Functions Express Workflows

Express Workflows 是一種新型的 AWS Step Functions 工作流類型，它以符合成本效益的方式協調 AWS 運算、資料庫和訊息服務，每秒超過 100,000 個事件。Express Workflows 自動啟動以響應事件，例如通過 Amazon API Gateway 發出的 HTTP 請求，AWS Lambda 請求，AWS IoT 規則引擎操作以及 Amazon EventBridge 中的 100 多個其他 AWS 和 SaaS 事件源。Express Workflows適用於大批量事件處理工作負載，例如IoT數據提取，串流數據處理和轉換以及大量微服務協調流程。

參考來源至：Introducing AWS Step Functions Express Workflows

Lambda Provisioned Concurrency

當 Lambda Function 一段時間未使用，需要處理併發 Request 或更新 Function 時，Lambda 會重新佈建執行環境。執行環境的佈建時間會根據 Lambda Function Package 大小、不同的 Runtime 而影響，導致 Request 路由到執行環境時產生「Latency」，這種等待時間通常稱為「 Cold Start 」，對於大部分使用場景可能會進而影響到使用者體驗。

在 Lambda Console 針對 Lambda Function Version / Alias 指定 Provisioned Concurrency 數量，Provisioned Concurrency 可以使 Function 保持 initial 狀態，並且可以隨時響應，大幅度地降低 Provision Latency，減少原先結構會有的 Cold Start 問題發生。

比較設置 Provisioned Concurrency 前後的回應時間如下圖：

參考來源至：AWS Lambda announces Provisioned Concurrency

圖片來源至：New – Provisioned Concurrency for Lambda Functionst

Storage

EBS direct APIs

透過適用於 snapshot 的 EBS direct APIs，可以直接讀取 snapshot 的狀態並取得兩個 snapshots 之間的差異，而無需另外建立 EBS volumes 和 EC2 Instamces 來看兩者的不同。

當使用者運用 EBS snapshot 來備份 EBS volumes 時為 Incremental Backup，每一次的備份都只會儲存相較於前一份 EBS snapshot 有變更的 Blocks。然而當需要使用 snapshot 來復原 volumes 時，會自動偵測較舊的版本，並將較新變更的 Blocks 覆蓋上去，概念如下圖：

有了 EBS direct APIs 後，可以透過 ListSnapshotBlocks 來了解 snapshots 的變更紀錄。以上圖為例，若對 Snap1 做呼叫，會回傳 [T0, T1, T2, T3, T4, T5, T6, T7]，若對 Snap2 呼叫，則會回傳 [T0, T4]。

此功能可讓使用者輕鬆取得 EBS volumes 的變更資訊，並使其能夠實現更快（縮短高達 70% 的備份時間）、更精細（達到更準確的 recovery point objectives）且更低成本的備份。

參考來源至：AWS launches EBS direct APIs that provide read access to EBS snapshot data, enabling backup providers to achieve faster backups of EBS volumes at lower costs

圖片來源至：New – EBS Direct APIs – Programmatic Access to EBS Snapshot Content

S3 Access Points

當使用者的同一個 S3 Bucket 擁有許多的權限控制的 Bucket policy 時，對維運人員來說是一件非常頭痛的事情，當我們只想修改其中一項存取權限時，深怕會動到其他項目，因此 S3 Access Points 便是一個很好的解決方案，我們可以針對不同對象或應用程式新增 access point，並個別設定針對這些對象的使用權限，以做到個別控管。

任何 S3 Access Points 都可以限制在 VPC 中，以在私有網路中保護 S3 的資料，而 AWS Service Control Policies 可以用來確保組織中的所有存取點都受到 VPC 限制。

參考來源至：Easily Manage Shared Data Sets with Amazon S3 Access Points

UltraWarm（Preview）

Elasticsearch 作為 ELK 代表性服務，針對各種不同的 Logs 做視覺化處理加以分析效能、安全性、察覺是否有潛在危害的發生。使用者卻在 Logs 的存儲策略上遇到容量的限制、成本的考量、保存期限…等問題，進而影響到使用 Elasticsearch 的成效。

UltraWarm 作為專為 Elasticsearch 存放 Logs 的存儲服務，相比現行架構，最高可以節省至 90% 的存儲成本。

在 Elasticsearch Cluster 中，把 “Hot” Data 存放至 Cluster Data Node 的層級，其餘 Data 轉存至 S3 中並透過 UltraWarm Node 存取，大幅度地降低 Data Node 的存儲空間，也同時解決了 Storage Scale 的需求且能對應上 S3 優越的 Durability 能力。

參考來源至：UltraWarm Storage for Amazon Elasticsearch Service (Preview)

AI

Amazon Kendra

Amazon Kendra 是由機器學習且易於使用的企業搜索服務，開發人員可以在應用程式中添加搜索功能，以便發現存儲在整個公司的大量內容中的信息。這包括來自手冊，研究報告，常見問題解答，HR文檔，客戶服務指南的數據，可在各種系統中找到，例如：文件系統、網站、Box、DropBox、Salesforce、SharePoint、Amazon S3 等。輸入問題時，該服務將使用機器學習來了解上下文並回傳最相關的結果，無論是精確答案還是整個文檔。例如：使用者可以問：『公司信用卡上的現金獎勵是多少？』，Amazon Kendra 將搜索到相關文檔並回傳像是『2％』之類的特定答案。

Amazon Kendra 經過最佳化，可從特定領域（例如：IT、製藥、保險、能源、工業、金融服務等）找到準確的答案。Kendra 的機器學習模式會透過擷取最終使用者搜尋模式和回饋來定期更新，讓 Kendra 的相關性能與企業的資訊趨勢保持一致。

參考來源至：Amazon Kendra

Amazon Rekognition 新增客製化標籤訓練

Amazon Rekognition 客製化標籤訓練提供訓練特定的影像分析模型，用以辨識特殊物件與場景。此功能可以訓練帶有少量標籤圖像的模型，以檢測機器零件的需求為例，在原先 Amazon Rekognition 所提供的辨識物件功能，對於所有這些圖像，Amazon Rekognition 將標籤為“機器零件”。

而透過 Amazon Rekognition 自定義標籤，使用者可以訓練自己的自定義模型來識別特定的機器零件，例如渦輪增壓器，變矩器等，但須先收集並上傳各個零件 10 張圖片作為訓練模型辨識的資料，並在 Console 中為每個物件進行標籤。

圖片上傳方式：

匯入已由 SageMaker Ground Truth 標籤完成之資料
使用 S3 儲存桶之圖片
使用先前使用客製化標籤訓練的資料集副本
從本機上傳

當資料集上傳並標記完成後，便可執行自定義標籤動作，Amazon Rekognition 會針對每個用例自動選擇最有效的機器學習技術。使用者可以查看每個模型的性能，並獲得有關如何進一步改進其模型的建議。

以下為使用 Amazon Rekognition 物件辨識與 Amazon Rekognition 自定義標籤之結果比較。

文章參考至：AWS launches Amazon Rekognition Custom Labels to enable customers find objects and scenes unique to their business in images 參考來源至：Announcing Amazon Rekognition Custom Labels

Amazon Fraud Detector

此次 AI 更新的服務 Fraud Detector 是一個全託管，可識別潛在的詐欺性在線活動的服務，例如在線支付的詐騙和創建假賬戶。利用機器學習和來自 AWS 和 Amazon.com 的 20 年欺詐檢測專業知識，以毫秒為單位自動識別潛在的欺詐活動。

參考來源至：Amazon Fraud Detector FAQs

Amazon CodeGuru

Amazon CodeGuru 為新的 AI 服務，是一個全託管的代碼檢測服務，可識別程式碼的嚴重缺陷（例如：敏感數據的不當處理和資源洩漏）和基於 Java 的 AWS 最佳實踐偏差，同時標記可能導致生產問題的常見問題（例如：偵測缺少分頁或批次操作的錯誤處理），並提供如何修正或改善程式碼的智慧建議，目前支援 GitHub 與 CodeCommit。

參考來源至：Amazon CodeGuru FAQs

Machine Learning

Sagemaker Studio

此次最重大的更新莫過於在機器學習領域中的 Sagemaker 有了重大的改變。

宣布了一個整合式的機器學習 IDE，裡面包含： 用於機器學習（ML）的網頁整合式開發環境（IDE），使用前須先擁有 IAM 權限才能夠使用此服務。此服務擁有 AWS 自己的 Notebooks 名為 Sagemaker Notebooks（預覽階段），可以輕鬆地創建和共享 Jupyter Notebooks。

第二個是 SageMaker Experiments，可以針對每次的訓練作業進行一次性的比較，以評估哪一次的訓練最為有效，並可以迅速的部署此模型。當我們在訓練模型時難免會遇到問題，SageMaker Debugger 會自動檢查訓練的模型，並收集數據進行分析，以提供實時通知和建議，SageMaker Model Monitor 可以檢視已部署模型的質量偏差（部署結果）並接收警報，最後則是在機器學習中，選擇算法是一個非常困難的問題。特別是要選擇和掌握可以解決問題的最佳模型。機器學習算法通常需要大量的訓練參數，這些參數需要設置通常經過多次修正與訓練才能得知最適合的值，以縮小模型的準確性。

使用者需要呼叫一次 API 或在 Amazon SageMaker Studio 中點擊幾下，SageMaker Autopilot 首先檢查數據集並創建許多數據預處理步驟，機器學習算法和超參數運行測試。然後，可以使用這種組合來訓練管道，並將其部署到實時端點或批次處理。

此圖為此次更新後於 Sagemaker 服務中的功能對應簡圖。

參考來源至：ついにSageMekerの統合環境が登場！「SageMaker Studio」が発表されました #reinvent

Amazon Augmented AI (Preview)

多數機器學習應用程序要求人工審核員檢查具有較低可信度的預測以確保結果正確。例如，在某些情況下，由於掃描質量低或筆跡較差，從人工掃描的申請表中提取信息可能需要人工審核。但是建立人工審核系統往往耗時又昂貴，因為涉及複雜的工作流程、編寫自定義軟件來管理審核任務和結果，以及在許多情況下管理大量人工審核員。

Amazon A2I 為常見的機器學習應用提供了內建的人工審查工作流程，例如內容審核和從文檔中提取文本，從而可以輕鬆地審查來自 Amazon Rekognition 和 Amazon Textract 的預測，還可以為基於 Amazon SageMaker 或任何其他工具的 ML 模型創建自己的工作流程。使用 A2I，使用者可以允許人工審核員在模型無法做出高可信度預測時進行干預，也可以持續審核其預測。

參考來源至：Announcing Amazon Augmented AI: Easily Implement Human Review for ML Predictions

Database

Amazon Managed Apache Cassandra Service (MCS)

除了 Amazon DynamoDB 及去年re:Invent發布的 Amazon DocumentDB (with MongoDB compatibility) 的 NoSQL Database Solutions，今年又發布以 Apache Cassandra 為託管對象的 Amazon Managed Apache Cassandra Service (MCS)。

跟 DynamoDB 一樣為 Serverless 服務，使用者僅需為實際使用量付費、依據負載狀況做自動化擴展 AutoScaling 以確保 Tables 的運作效能，在使用上也是透過 Cassandra Query Language (CQL) 和 Tables 互動。

對於使用場景不易搬遷至 DynamoDB / MongoDB 的使用者是一大福音！

現正以Open Preview Regions：

US East (N. Virginia)
US East (Ohio)
Europe (Stockholm)
Asia Pacific (Singapore)
Asia Pacific (Tokyo)

參考來源至：Amazon Managed Apache Cassandra Service (MCS)

RDS Proxy (Preview)

以往應用程式會與資料庫建立 Connections 以傳輸並取得資料，這些 Connections 會消耗資料庫 Memory 和 CPU 資源。許多應用程式包括現代無伺服器架構上的應用程式，都開啟大量資料庫 Connections、對資料庫造成壓力，從而導致資料庫性能降低和應用程序可伸縮性受限。

RDS Proxy 建立並管理與資料庫的必要 Connections Pools，以便應用程序創建較少的數據庫 Connections。RDS Proxy 支援 Auto Scaling，使 DB Instances 不需要耗費額外資源來進行 Connections 管理，同時透過 Connections Pools 來提高性能。發生故障時，RDS Proxy 會自動連線至 RDS Standby Instance、同時保留應用程式的連線，並將 RDS 和 Aurora 異地同步備份資料庫的容錯移轉時間降低高達 66%。

使用 RDS Proxy，可以透過 AWS Secret Manager 和 AWS IAM 管理資料庫登入資料和存取，無需在應用程式程式碼中嵌入資料庫登入資料。

參考來源至：Introducing Amazon RDS Proxy (Preview)

圖片來源至：Using Amazon RDS Proxy with AWS Lambda

Amazon Redshift Federated Quering (Preview)

此功能推出後使用者便能跨資料庫、數據倉庫（Data warehouse）、資料湖（Data lake）快速的查詢資料，目前使用者可以實時查詢 Amazon RDS for PostgreSQL、Amazon Aurora PostgreSQL 中的資料，也可以和現有 S3 當中的表進行聯合查詢並彙整成新的一張 Data Table。

CREATE EXTERNAL SCHEMA IF NOT EXISTS online_system
FROM POSTGRES
DATABASE 'sales_db' SCHEMA 'system'
URI 'my-hostname' port 5432
IAM_ROLE 'iam-role-arn'
SECRET_ARN 'ssm-secret-arn';

可以使用此語法將 RDS 或 Aurora PostgreSQL 資料庫添加到 Redshift 叢集。

通過 Redshift Federated Quering 便可以直接從 Redshift 連接到 RDS、S3 中並執行處理 ETL / ELT 的查詢。

參考來源至：Amazon Redshift introduces support for federated querying (preview)

Amazon Redshift RA3 instance nodes

RA3 執行個體建立在 AWS Nitro 系統上，具有高頻寬網絡、高性能 SSD 作為本地緩存，同時可自動儲存到 S3，與大多數使用者用的 Dense Storage（DS2）執行個體相比，可以用相同的成本獲得 2 倍的性能提升和 2 倍的儲存容量。 另外 RA3 和現行架構、用法完全一致，使用者可以直接 透過快照方式將工作負載無痛移植到 RA3 節點上。

參考來源至：Amazon Redshift introduces RA3 nodes with managed storage enabling independent compute and storage scaling

Announcing Amazon Redshift data lake export: share data in Apache Parquet format

現在可以將 Amazon Redshift 查詢的結果作為 Apache Parquet 卸載到 Amazon S3 數據湖，Apache Parquet 是一種高效的開放式列式存儲格式，用於分析。與文本格式相比，Parquet 格式的卸載速度提高了 2 倍，並且在 Amazon S3 中消耗的存儲量減少了 6 倍。這讓使用者能夠以 Parquet 開放格式將在Amazon Redshift 中完成的數據轉換和充實保存到 Amazon S3 數據湖中，再透過 Redshift Spectrum 和其他 AWS 服務（例如 Amazon Athena、Amazon EMR 和 Amazon SageMaker）分析數據。

使用者可以指定一或多個分割區欄，以便自動將卸載的資料分割到 Amazon S3 Bucket 中。例如可以選擇卸載行銷資料，並按年、月和日資料行進行分割。這可讓您的查詢利用磁碟分割修剪和略過掃描非相關的磁碟分割，改善查詢效能並將成本降至最低。

參考來源至：New for Amazon Redshift – Data Lake Export and Federated Query

Networking & Content Delivery

AWS Wavelength

AWS Wavelength 可將 AWS 服務與 5G 網路連結，讓開發人員以不到 10 毫秒的超低延遲效能交付應用程式到各種移動裝置和終端使用者們，對於未來運用在遊戲、直播串流或AR/VR將會達到更好的成效。

目前支援的電信商與區域： * Verizon in North America * Vodafone in Europe * SK Telecom in South Korea * NTT Docomo, and KDDI in Japan

參考來源至：AWS Wavelength

Transit Gateway Network Manager

大多數全球網絡都包含位於 Cloud 以及一個或多個 On-Premise 組成混合資源。若要監控整個全球網路，通常必須將雲端資料和內部部署整合在一起，這會導致不一致的管理與監控體驗。

Transit Gateway Network Manager 集中管理和監視整個AWS和本地的全球網絡，降低了跨 Regions 和遠程位置管理網絡的操作複雜性

在 Network Manager Console 中，可以從 VPC Transit Gateways 部分中看到全球網路的概觀，為所搭建的 AWS Transit Gateways、通過 Site-to-Site VPN Connection 連接到 Transit Gateways 的實體設備和網站以及連接到 Transit Gateways 的 AWS Direct Connect 位置提供了集中管理點。

並且可以選擇地圖上的任何節點以獲取詳細資訊，包括所有 VPN Connection、VPC 和所選 Transit Gateway 處理的 VPN 的狀態。

在 Topology 面板中，可以查看網絡中所有資源的邏輯關係，選擇圖中的任何節點都會顯示特定於資源類型的詳細資訊，如Transit Gateways、VPC、Customer Gateway…等。

Network Manager 使用 Amazon CloudWatch 收集原始數據並將數據輸入/輸出、丟包和 VPN 連接狀態處理成可讀、即時的指標。

這些統計資訊將保留 15 個月，以便訪問歷史紀錄並更好地了解 Web 應用程序或服務的性能，亦可設置警報，以監視某些閾值，並在達到這些閾值時發送通知或採取措施。

參考來源至：New for AWS Transit Gateway – Build Global Networks and Centralize Monitoring Using Network Manager

VPC Ingress Routing

以往若使用者想要讓 Cloud 環境套用與地端 On-Premise 相同的資安政策，如：IPS/IDS 或其他防火牆的設置，需要先將流量導回 On-Premise 做檢查，再路由回到 Cloud 環境，這不僅增加延遲時間，也讓過程變得更加複雜。

VPC Ingress Routing 有助於整合第三方的 IPS / IDS 或其他防火牆解決方案，以幫助針對網路七層中應用層的防護。

EC2 上的 Security Group 是針對網路層、傳輸層的防護。

VPC Ingress Routing 透過創建一台 Appliance Instance 作為流量檢查角色，將經由 IGW 或是 VGW 進來的流量，優先導流到 Appliance Instance 上做檢查，再轉到終端的 Application Instance。如此一來相較於使用 AWS WAF，已經習慣使用某一種第三方防火牆軟體，可以在 Cloud 使用與 On-Premise 一樣的解決方案。

以前不支援將 Route Table 套用至 IGW，所有進入 IGW 的請求，會直接進入到 VPC Subnets 或是直接到 ELB，而無法路由到特定的目的地。現在可為 IGW 客製化路由表，將進入到 VPC 的請求路由到特地目的地。

如下圖，搭建好 Cloud 環境後，可開始設定各個 Route Table:

為了讓流量先導至 Appliance Instance，需做以下設定：
1. 將路由表附加到 IGW（10.0.1.0 子網的 CIDR 路由到 Appliance Instance 的 ENI）
2. 更改公共 10.0.0.0/24 子網的路由表（將 0.0.0.0/0 路由更改為 IGW）
3. 更改公共 10.0.1.0/24 子網的路由表（將 0.0.0.0/0 路由更改為 Appliance Instance ENI）
4. Disable Appliance Instance Source/Destination Check，Appliance Instance 才會將封包轉到 Application Instance。
完成設定即可變成以下架構，即使放置了防火牆，IDP / IPS 等，也可以通過簡單的通信路徑進行設置。

參考來源至：IGWとVGWにルートテーブルをアタッチ！全ての通信をEC2経由へ。サードパーティIDS製品などの通信をシンプルに #reinvent, New – VPC Ingress Routing – Simplifying Integration of Third-Party Appliances

Accelerated Site-to-Site VPN Connections

現在可以自由選擇是否在 Site-to-Site VPN connection 啟用 Accelerate，加速 VPN connection 的存取速度。

Accelerated VPN connection使用了去年發布的 AWS Global Accelerator，讓 On-Premises 裝置點路由至 AWS edge location (PoPs) 進而取代掉相對較遠的 VPC VGW 端點，獲得較低的連線 Latency，加速整體的連線速度。縮短之間連線的距離，也能降低因 Public Internet 會有的網路順斷導致 VPN Connection 斷開的可能性發生。

參考來源至：Accelerated Site-to-Site VPN Connections

Multicast on Transit Gateways

在 AWS 上原先不支援 Broadcast 和 Multicast 的通訊方式，以往使用者若有相關需求，需要自行在 VPC 上以 EC2 做覆蓋網路 (Overlay network) solution 虛擬出 Multicast。

現在可以透過 Transit Gateways 支援串接 VPC Subnets 之間以 Multicast 作聯繫。

Multicast domain： * 建立 Multicast 網路環境 * 選擇要作為 Multicast Router 的 Transit Gateway * Assocaiate VPC Subnets 至 Multicast domain

Multicast group * 建立 Source 作為 Multicast Sender、或是作為 Multicast Receiver * Multicast group IP 為 IPv4 class D：224.0.0.0/4 * Group 成員為 EC2 Instance ENIs

Multicast source * 發送 Multicast 的 EC2 Instance ENI

Multicast group member * 接收 Multicast 的 EC2 Instance ENIs 集群

參考來源至：Amazon Transit Gateway

Transit Gateway Inter-Region Peering

AWS Transit Gateway 現在支援在不同 AWS Region中的 Transit Gateways 之間建立 Peering Connection。使用 Inter-Region Transit Gateway 對等傳輸的流量始終停留在 AWS 全球網絡上，並且永遠不會遍歷至 Public Internet，從而減少了威脅媒介，例如常見漏洞利用和 DDoS 攻擊。

參考來源至：AWS Transit Gateway now supports Inter-Region Peering

Security

Amazon Detective

Amazon Detective 是一項新服務，協助使者用輕鬆分析，調查和快速確定潛在安全問題或可疑活動的根本原因。Amazon Detective 會自動從 Accounts 中收集日誌數據，並使用機器學習，統計分析和圖論來構建一組連結的資料，使能夠輕鬆地進行更快，更有效的安全調查。

Amazon Detective 可以分析來自多個資料來源的數兆個事件，如 VPC Flow Log、AWS CloudTrail 和 Amazon GuardDuty，並自動建立資源、使用者和它們之間隨著時間的互動檢視。有了這個統一的檢視，在一個地方視覺化所有的詳細資料和內容，以找出結果的根本原因，向下鑽研相關的歷史活動，並快速確定根本原因。

參考來源至：Introducing Amazon Detective

Business Applications

Contact Lens for Amazon Connect

是一個通過機器學習並支援 Amazon Connect 的服務，使客服中心主管和分析人員能夠了解其客戶對話的內容，情感和趨勢，從而確定關鍵客戶反饋並改善客戶體驗，客服中心每天都會接收到大量的客戶訊息，從而導致數百萬小時的通話記錄。公司希望能夠在所有電話中進行搜索，以識別問題，共同主題和代理商指導的機會。他們可以使用現有的聯絡中心分析產品，但是這些工具價格昂貴，提供通話記錄的速度很慢，並且缺乏所需的記錄準確性。這使得難以快速檢測到客戶問題並向其代理商提供可操作的性能反饋。現有工具無法提供實時分析，也就是客服人員無法在掛斷電話之前識別和幫助這些沮喪的客戶。而現在可以透過 Contact Lens for Amazon Connect 來實時判斷客戶當下情緒，並快速搜索客戶常建主題以及多項有利於客服人員之功能。

參考來源至：Contact Lens for Amazon Connect