【2021 AWS re:Invent 即時新聞】Werner Vogels Keynote

本次 Keynote 的開場，Werner Vogels 仍是以主題影片帥氣帶出主題：「The Road to reInvent」，再帶出 Lambda、Serverless 及 Observability 等過往 Keynote 中，令人為之振奮的發布，最後高喊 「I’m ready Vegas, and you?」，宣示 re:Invent 以實體方式回歸，果然很有個人特色啊！

再次重申 2021 年為很重要的 AWS 里程碑，re:Invent 第十年、Cloud 雲端服務推出第十五年，就像昨天 Peter 提到世界的變遷與科技演進的速度都令人相當興奮。

Dr. Werner 每年都會穿著不同的 T-Shirt 登台做 Keynote sharing，也讓每年穿著什麼短 T上台成為 re:Invent 的看頭之一！而今年的 T-Shirt 是來自英國龐克搖滾始祖 The Stranglers 的主題短Ｔ哦。

Start from the Beginning

「Innovation was constrained」

回顧 2003 年，當時 Amazon 隨著業務成長在做開發、滾動功能的時後，發現了如 Computing、Storage、Network 等 IT 資源的調用瓶頸，所以打造了一個平台來讓大家可以透過 Programming 的方式、以程式定義的角度來獲取這些 Resource 持續做 Innovation，這也是 Amazon Web Service 的起源。

AWS 起初在服務推出的時候非常的簡單，舉例 EC2 發布時只有一種 Instance Type：m1，只有一個 Region，甚至都沒有 Available Zone 的概念出現，對於 EC2 Instance 的控制動作也只有 Run & Terminate，是個超級簡單的服務。

但透過這個簡單卻具有強力變革性的服務，AWS 依據使用者的使用場景與需求、伴隨著 Ambitions，打造越來越多的 Instance Types 和 Families 來針對不同場景達成運算優化。而在過往去兩三年間，也透過轉變 EC2 hypervisor 至 Nitro System 來優化整體的 Performance 與 Cost，帶給客戶更好的體驗！

EC2 Mac M1 Instance

在去年 EC2 開始支援 Mac Instance，而 Arm-based 的效能大家有目共睹；除了 Amazon Graviton 之外，再推出 Mac M1 Instance！讓大家可以在 AWS 上，使用 Apple M1 的運算能力開發、測試與發布 Apple Apps。

2021 年平均每天有六千萬台 EC2 Instance 被啟用來滿足客戶的運算場景，相比 2019 年，足足成長了兩倍！雖然雲端環境與服務解除了過往許多機房上的使用限制，但仍有許多 AWS 需要努力改善的部分。

接著來看選擇 AWS Region 的時候，主要會考量 Data residency、Latency、Bandwidth 和 Connectivity 這四個因素來挑選適用的 Region 佈建資源，而這四個因素又可分為三個面向：

• 國家法規：在許多產業別，會基於個人資訊的隱私及安全，由國家直接訂定法律來規範資料這些敏感性資料的儲存位置。例如：醫療、金融產業的資訊，經常被規定是不能離開國家領土範圍的。
• 硬體設備的物理性限制：連接、串連網路的設備總有些物理性質上的限制，例如：裝置間的距離會多少造成資料傳輸上的延遲；設備本身效能的上限及能源轉換率所影響頻寬的大小…等，都有可能影響到使用者體驗。
• 墨菲定律：通常使用者在連接網路時，連線的穩定度往往是一個讓人擔心的要素。連線中斷可能會丟失封包、使進行中的任務需要重新來過…等等，因此穩定且快速的連線能力，也是非常重要的關鍵。

依據四個因素、三個面向，AWS 從一開始的 N. Virginia Region 開始逐步拓展在全球的 Region，讓使用者可以根據不同法規、網路效能或是其他考量點，去挑選出適用 Region 。舉例來說，佈建在美東或歐洲 Region 的話，對於位在亞洲的使用者來說延遲會變得非常明顯！隨著提供越來越多的 Region 讓使用者選擇，其中需要考量的因素可能不只一個，例如：延遲性與成本要如何兼顧？而這就需要使用者自行斟酌了！

使用者位置在中亞，可選擇部署在新加坡的 Region 來縮短應用程式與 end-user 的物理距離，進而降低延遲性；抑或選擇部署在歐洲、北美洲的 Region，雖然延遲提高但仍在可接受範圍，同時也可以享有既低的成本。

AWS Global footprint 截至目前已經有 25 個 Regions、81 個 Available Zones，目前已公布規畫中的 Regions 有 9 個（綠色點）也預計在近兩年釋出。

接著細看「延遲性」這一點，不僅擴展 Region 在解決這個問題外，還有 Points of presence 又稱 Edge Location 邊緣節點在此也至關重要！在這上面有運行了 CloudFront、Lambda@Edge、S3 transfer accalarator 等 edge 端服務，讓使用者流量可以透過鄰近的 PoP 點進入到 AWS Backbone 當中，以確保連線的穩定性與速度。

除了 Points of presence 邊緣節點以外，AWS Local Zones 的推出也拉近了 Region 與使用者的距離。使用者可以把 VPC 延伸範圍至 Local Zone，並把運算單位 EC2、ECS、EBS 等服務放置在離使用者極近的距離，進而大幅度縮短網路傳輸的距離，更能及時地取得運算結果。同時也預告在 2022 年，將有多達 30 個 Local Zones 誕生於世界各地。

最後還有 AWS Wavelength，更是透過設置支援 5G 網路的基礎設施端點，來提供更高速的網路傳輸、讓使用者獲得更低的延遲性。

AWS Network and Backbone

將時間拉回 2006 年剛發佈 EC2 時，每一台 EC2 Instance 都會獲得一個動態的 Public IP，彼此之間透過 Internet 互相溝通，這時的網路配置模式我們又稱為 EC2 Classic 。而針對 EC2 的發展 AWS 開始作出不同的優化：

• 2008 年推出 EC2 AutoScaling 依據服務需求自動擴展／縮減 EC2 機器數量、為了 EC2 之間的負載平衡推出 ELB、CloudWatch 來監控 EC2 運行狀況、提供 Elastic IP 讓 EC2 擁有固定的 Public IP。
• 2009 年推出 VPC 提供使用者配置客製化網路環境、控制流量進出規則、路由策略，也可以透過 VPN 或是 DX 連接地端與雲端的網路環境，並在 2013 年開始以 VPC 取代 EC2 Classic 為預設 EC2 的網路環境。

歷經上面歷史的沿革，也重新定義了使用者在雲上面針對「網路」的體驗，讓服務之間的溝通不一定要經過 Internet ，也可以透過 AWS backbone network 如 VPC Endpoint，發展至現今的 AWS backbone network 更是擁有 100 gigabyte 高速效率。

有許多服務皆透過 AWS backbone network 來降低延遲、進而優化使用者體驗。

即使透過 AWS Backbone 提升了許多服務體驗，但對使用者來說，要連結自身地端環境至 AWS 雲端，仍有許多挑戰：需要使用者提供巨大、繁雜的表格，來管理、設定雲端與地端（可能是公司、工廠端）之間的連線。因此，AWS 想要解決那些已在 AWS 運行眾多服務（VPC），一定且必須連結 AWS 雲端與地端的使用者的麻煩及對於強大網路頻寬的需求。

AWS Cloud WAN

AWS Cloud WAN 是一個可以讓使用者創建、管理、監控這些擴及全球、個人的網路環境，例如：VPC & 地端環境，加以解決頻寬問題或是跨 Region、跨 VPC 的網路流量交換。

運作方式：

• 選擇啟用的 Region
• 所有使用者的用戶、裝置、地端環境會自動地透過 VPN 或是 DX 連線到鄰近 Region，而這些都是藉由 AWS Backbone 來完成的，不僅快速又安全。

• 根據需求切割多個網路環境，並可以管控不同網路環境之間的溝通

• 使用者可以透過 Dashboard 監控在網路環境所有的活動，進而幫助做故障排除或是解決性能問題。

• 支援 AWS Cloud WAN 的 Partner。

Beyond the Region

儘管 AWS 為了解決延遲性的問題，提供 Region、Points of presense、Wavelength zone 以及 Local zone，但使用者持續要求更低的延遲。

而解決辦法就是將 AWS 更貼近使用者的環境！

除此之外，針對那些無法離開使用者本身網路環境的 Application，但又希望可以藉由 AWS 雲端來驅動這些 Application 的需求，又該如何是好？

因此，先前推出了 AWS Outposts，將 AWS 的基礎設施直接搬至使用者的環境中，不僅可在自身環境運行 AWS 服務，也可以真實地帶來更即時的運算能力及體驗。

從客戶案例中，可以看到 Outposts 實際帶給他們的益處：FanDuel 利用 Outposts 提供低延遲的運算效果；而 FAB（第一阿布達比銀行）則是為了解決 Data residency 的需求；最後 Philips 則是兩者都需要而採用 Outposts。

一開始只提供了 42U 的選項，後續又推出 1U、2U（適用於不同規模的工廠、公司的需求），而 Outposts 上也支援 AWS 上核心的服務，如：RDS、EC2、ECS。

「Connecting Billion of Devices」

那如果是上百萬個裝置要做連線到雲端呢？ Dr. Werner 稱這為 「Internet of Billions ot Things」，AWS 則提供 FreeRTOS、IoT Core 以及 Greengrass 來解決這個需求。

• AWS FreeRTOS：適用於微型控制器的 FreeRTOS 作業系統
• AWS IoT Core：集中管理物聯網設備
• AWS Greengrass：在設備上進行邊緣運算，並在裝置連線上網後，幫助上傳數據至 AWS 雲端作後續的管理、分析、資料處理。

雖然提供了這些 IoT 相關的服務，但現今的產業仍存在許多舊式的裝備，以美國為例，27 年前的裝置仍在使用及運作。因此，可以想像這些裝置並不適合現代需要上傳資料至雲端的設備需求，也就無法真正受益於這些服務。那對於這些舊型的設備，可以利用 AWS 去年推出的 Monitron 來追蹤場域狀況。Monitron 可偵測溫度、震動⋯等數值，透過 Gateway 將資料上傳至雲端，幫助設備維護人員進行維護預測。

而不管在工廠還是零售環境中，大多都有使用攝影機進行監控，其實可以將這些 Data Stream 進行分析。 AWS Panorama Appliance 可透過機器學習模型來幫助我們分析，以便利商店爲例，你可以透過它去分析客戶的狀況，像是在哪裡逗留最久、怎麼移動⋯等等，進而去改變商品的陳列方式或是動線，提高客戶滿意度。安裝攝影機已不僅僅是為了查看是否有人偷竊商品等監控行為，而是要透過觀察、蒐集及分析資料，創造更大的效益！

除了完成眼前的需求，也要看到更遠的目標，其中多數的目標都需具備合規性，尤其是醫療產業。再來，並不是所有環境都是完美的，可能會遇到像沙漠、雪地這樣嚴峻的環境，那要如何在這樣的環境下汲取資訊並且傳送到 AWS 呢？

那針對「Compliant、Rugged、Remote」這三個需求又要如何滿足？

使用者們可以透過 AWS Snow Family 來解決在嚴峻環境的困境，不管是多少 GB 或 TB 的資料，皆可根據需求來選擇需要的類型。

而現在不僅是在地球上，就連外太空我們也開始發展。 新的領域 AWS Ground station，就是透過衛星來傳送資訊。

Capella Space

Sharing by Payam Banazadeh, CEO & Founder from Capella Space

Payam 期望可以即時地創造出一個真實世界的數位副本，來讓世人察覺每一個在世上的改變，同時還可以把這樣的流程自動化；就好比設置一個不僅影響數位虛擬世界，也改變了實際狀況的 trigger point。

舉例來說：如果人們可以即時地了解所有港口、貨船、運送航線的狀況，是否可以避免未來發生全球供應鏈上的中斷，進而避免全球資源的短缺？

為了達成這一目的，可透過在大海中部署眾多的感測器，來收集大海中的資料，藉此查看貨船運送狀況來調度運送路線；不僅是大海中的資料，近年來更是收集到陸上的資訊，提升了整體貨運的值與量。

下一個層級則是太空（Space），太空的數據是特殊且具有許多優勢的。試想：如果是要對全球的狀況來下達全球性的決定，那是不是需要即時地對世界有所了解才能幫助人們做出更好的決策？

現在有了強大的衛星，可以即時的看到地球表面的狀況，例如：可拍攝到任何時候、任何條件下，颱風的即時照片。藉此可以讓人們取得可靠、可視化的即時狀況，進而達到真正且立即的監控。

目前有五個衛星正在運作，未來將發射更多的衛星來擴大資訊範圍，同時也意味著將有更大的資料量。而連結了大海、陸地及太空的資料後，預計會有 500PB 的資料量；為了存放這些大量的資料，同時做到即時、低延遲的存取，需要全然不同的解決方案。

Payam 決定自行建構屬於他們自己的解決方案，其中有主要幾項需求： – 建構分散式儲存、存取資料的系統 – 全自動化、去除人為動作 – 即時資料處理 – 無上限的儲存空間及運算效能 – 穩定的擴展機制

而透過 AWS 完全可以達到需求： – 大量的資料可以無上限的存放在 S3 bucket – 當衛星回傳照片，EC2 搭配 Auto Scaling Group 可以即時的被處理 – 甚至對於更快速的存取，可以利用 AWS Ground Station 傳到不同 Region 內

AWS Ground Station 使用 AWS 的光纖纜線，毫秒內即可讓衛星回傳的資料安全地進到 VPC 雲端環境處理。

而現在整個系統都建構在 AWS 上面，透過單一個 robust API 就可以快速的擷取一張從外太空拍攝的照片，就像從外送平台點餐一樣快速、簡單，而且這整個過程是全自動化、無人為參與。

Demo 系統操作過程： – 點擊想觀看的地點（ex: 拉斯維加斯） – 挑選時間長度（從當下往後推算多久時間的照片）

接下來全部交給系統處理！衛星會依據你選取的地區開始拍攝照片，回傳圖片至 Ground Station，在雲端上做資料處理，完成！使用者可以立即的獲得預期的的即時影像，就這麼簡單又快速。

其中最驚人的是：透過一個 API 就能完成這些動作！只需要傳送 API 請求，就可以把他們強大的功能引入到 Application 及 Workflow 中，拿到衛星所拍的照片、拿到最即時的資訊。

這個系統真正的改變整個數位世界與真實世界互動的方式，讓全自動化的流程，不只侷限於數位網路世界，而是在真實生活的世界產生影響力。

此外，還有更多幫助人們做出最佳決策的例子： – 偵測到海上油污事件 – 驗證中國水壩潰堤事件 – 火山研究學者透過比對照片中的煙霧，發現新的火山口 – 即時通知當地機構亞馬遜雨林的森林砍伐事件 – 還有更多氣象預報、洪水..等事件的即時偵測

“What would you do and what would you build if you were one api called away from seeing our planet and its billions of changes?” – Payam Banazadeh, CEO & Founder from Capella Space.

隨著衛星技術逐漸成熟，把機房送上太空、在太空運算的可能性越來越高，我們也期許看到「Lunar Region」的實現！

綜觀從 Cloud 的範圍從 Region 和 Availability Zone 出發，Edge 位置的 PoP、On-premises、IoT Devices、克服環境的 Snow Family、再上到太空宇宙的衛星，Dr. Werner 稱之為「The Everywhere Cloud」，雲端的範圍不再僅僅是機房之間的抽象化了。

Distributed not decentralized

在雲端上眾多的資源雖然彼此是以分散的 Components 在各自運作，但從管理面來看，並不是 decentralized – 失去集中管理的可能性！這些服務、元件，都是透過 AWS IAM 在做身份驗證與授權管理，來定義誰在什麼條件下，能針對何種資源做什麼操作，而這範圍從 Region、AZ 到 Edge 端都受用。上百萬的使用者在管理幾千種 AWS 資源，使得 IAM 要在 Scale 和 Secure 之間取得平衡。

IAM 的運作邏輯：當我們針對某個資源做操作時，會經由 control plane 去做身份驗證後，再確認是否擁有權限執行該動作，分為 Authentication 和 Authorization 兩個動作。

而身份尤其重要，以 IAM User 為例，我們都知道 Access Key & Secret Key 代表使用者身份 ，而這組 Key 會用來執行 AWS CLI、呼叫 API request等動作。

其中 Secret Key 會被用來以 SigV4 加密 Request，並送到 AWS Service Endpoint，再呼叫 IAM Service Endpoint 做 SigV4 的身份確認、驗證 Request 與檢查權限；如果有發現 SigV4 不一致的話便會回傳 Access Deny，可想而知 IAM Endpoints 的負載量之大！

而 Secret Key 只是 SigV4 Signing Key 的一部分，其他還包含： – date Hash 過後的時間戳記 – region Request 要訪問哪個 Region – service Request 要和哪個 Service 做互動

Secret Key 被堅持放置在 Control Plane 中，是為了避免發生 Security Violations 的可能性；要降低 IAM Endpoint 負載的解決方法是可以透過 Control Plane 產生一把 Derived Key，而這把 Derived Key 包含了 Secret Date 和 Region 的資訊。

驗證流程就會變成由 Request 帶入 Derived Key 而非 SigV4，進到 IAM Endpoint 檢驗時，只需確認 Request 帶入的 Derived Key 和 Control Plane 發出的 Derived Key 資訊是否對稱，不用像先前一樣，要把 SigV4 送到 Control Plane 中。而 Derived Key 的概念則類似 API Scope，針對特定 User、特定服務、特定日期、特定 Region 去限縮 Request 的範圍做驗證。

這個改動可大大降低 IAM Service 的 loading，不僅增快 Request 的檢驗速度、也同時增加了驗證的可靠性！

Evolved from Simpler System

Werner 以 IAM 這個服務為例，舉出 IAM 在每秒鐘可以承受上億次數的 API 呼叫，要如何做到這件事呢？其實就是讓系統盡可能的簡單化，這樣才能讓系統接受如此龐大的呼叫次數，又能滿足現在 IAM 所需的安全性需求。

因為當事情越變得複雜，就越不該構建一個複雜的系統。所有複雜的系統之所以能運作，都是從簡單的系統發展而來的；因此我們能歸納出把簡單的東西做得越有效率，複雜系統的效率也會隨之提升。

其實一個複雜的系統是需要透過簡單的工具來做組裝與優化，假設我們要把一個盒子放置在高處，這可能需要花費很多的力氣，但使用到對的工具時，就可能不費吹灰之力就能完成。而這些小小的工具集合起來，則可以創造出更多的機器。

如果拿一個螺絲、一個槓桿和一個輪子，就能製造出一個手推車的話，放在此處來看，機器其實就是透過更簡單的機器所製造的。

跑車、卡車，甚至是賽車，皆亦能透過相同的元件組裝而成。

而這些都是透過 Primitive 所構建的，將這些 Primitive 組合在一起，就可以製作出這些複雜的機器，這也是為何我們要使用 AWS 的原因。

AWS 以 Primitive 為初衷，並不是框架。

如果是一個框架，你可能需要 4 到 5 年時間才能將所有東西組合起來，這也就意味著當你在交付產品給客戶時，這個框架可能早已過時了，但你可能需要透過這個框架來建置未來十年要用的東西，這並不是我們樂見的。

AWS 提供給你的就是這些小小的元件，這樣你就可以準確的建構你想要的東西，就像積木一樣，拼湊成你想要的樣子。

而 AWS 提供的的每個服務、功能，都可以視為小小的元件，透過如此豐富的元件選項，讓使用者可以任意拼湊出想像中的產品、組成新的機器。

真正實踐這句話 —「Build what you want to build without us telling you how to build it」。

Dr. Werner 也開玩笑地說，我們都提供這麼多的服務了，如果還要求更多，基本上就是你的問題了。

同時也舉例 AWS 上有些服務也是由多個服務所構成的，例如：

• ＡＷＳLakeFormation 資料湖分析服務
  • SageMaker
  • S3
  • Athena
  • DynamoDB
  • Aurora
  • EMR
  • OpenSearch Service
  • RedShift

• AppRunner 部署 Container 應用程式
  • CodePipeline
  • Fargate
  • Route53
  • ALB
  • IAM

• Amplify 快速創建 Web App
  • AppSync
  • Cognito
  • DynamoDB
  • Lambda
  • S3
  • Route53

Amplify Studio

AWS Amplify 是一個讓 Web 和 Mobile Developer 可以快速、輕鬆、並且靈活地結合 AWS Services 來打造應用程式的服務，使用者可以透過 Amplify 快速的以 Frontend 為基底打造服務框架。

但對於 Frontend Developer 要打造一個全端的應用程式，除了 HTML、CSS、JavaScript 之外，可能還需要知道 API 對接、Database 搭建與管理、Server 維運與建制…等相關領域，都是很大的挑戰。

AWS Amplify Studio 提供一個視覺化的開發介面，並可以匯入 Figma 元件，並在元件上設定 Data、Session 等連結、生成程式碼後再 Import 至前端程式碼當中，便能自動地完成前端頁面與後端 API 串接等行為。

Sharing by Ali Spittel, AWS Senior Developer Advocate

Ali Spittel 直接透過建構一個 Amplify App 來讓大家了解 Amplify Studio 的功能及其帶來的益處。

她希望透過這個 App 來上傳此時她在這場 session 的內容，讓潛在的聽眾能立即給予回饋；而不僅是這一段 session 的內容，每一場 re:Invent session 的內容都可以紀錄。

• 首先要建構 Amplify 的 Data Model（資料模型），使用者可以自行決定每個欄位的資料型態，透過 Amplify Studio 的圖形化介面操作，建立資料與資料之間的關係和連結。

• 接著便可以新增 session（從上圖中的 7 場 session，變成下圖的 8 場）

• 而前端頁面的設計，最常遇到 UI/UX 設計師與工程師之間的期望落差（設計師對於程式設計的不熟悉、工程師對於色彩、畫素的不敏銳..等等）。針對這樣的問題，工程師現在可透過在 Amplify Studio 中所支援的 Figma (現今較受歡迎的介面開發工具)，來引入 UI/UX 設計師的 UI 程式碼，解決這之間的溝通鴻溝。

工程師只需要在 Amplify Studio 貼上設計師的 Figma 連結，就可以引入設計師所製作的各種介面及元件。

• 引入 Figma 之後，可在左側邊的欄位找到所有的 Component，也可以直接拉一個 Component 來編輯。
• 如 Ali Spittel 所示範要創建一場 session 用的介紹，從引入的 Figma 中選取一個。而在這個 Component 內有四個欄位，分別對應至先前在 Amplify Data Model 上的欄位，後續就可直接在 Data Model 看到每個欄位所存放的值。
• 甚至可從 Data Model 設定篩選及排序，而這會影響到介面中每個 Component 的顯示或排序。
• 設定好後，Amplify Studio 會出現一段程式碼，讓工程師可以直接複製貼上到自己的 Application 中，並調用設定好的 Component。

• 接著，說到該如何整合至現有或全新的 Application 時，以 React App 為舉例：當前端工程師正進行開發時，僅需要透過 Amplify 的指令集，執行 amplify pull 這一行指令，就可引入在 Amplify 中的 Component，且能馬上轉換為 JS 程式碼，而工程師只需微調即可。

• 引入後，搭配剛剛所提到，由 Amplify Studio 提供並讓工程師可直接複製貼上的那段程式碼，即可讓 Components 渲染（Render）在網頁中。

• 此外，最方便的是，當設計師想要更新這些 Component 的風格時，一樣可以繼續利用 Figma 修改；修改完後，再同步 Amplify Studio 裡的 Component。而在同步前，Amplify Studio 還會預先確認是否確定要同步；最後，工程師再執行一次 amplify pull 的指令，將修改內容全部同步至 Application 中，快速、簡單，也不會增加工程師的工作負擔。

• 新功能 – Scale with Amplify：讓開發者可以取用 Amplify Tool Chain 以外的 AWS 服務
  • amplify override：可以覆蓋掉 Amplify 原本自動產生的設定
  • amplify add custom：可以透過 CDK 來引入任何 AWS 的服務
  • amplify export：匯出 Amplify backend 成 CDK template

AWS Cloud Control API

在調用 AWS 資源時都是以 API 完成動作，Service API 在不同服務中會有不同的 API 語法，且資源名稱也會不一樣。其中，會出現有著相同動作卻有著不同的動作名稱，如 List、Get、Describe…等都是去做 Read 行為，而這也造成使用者覺得資源調用不易。

Cloud Control API 便是在解決此問題，幫助使用者能以直覺的方式來規範與 AWS 資源的互動。

同時，此處也 look back 過去 15 年來，維護、設計與開發 AWS APIs 的經驗分享，以及做 APIs 開發時應該思考的六個面向： – APIs are forever – Never break backward compatibility – Work backwards from customer use cases – Create APIs with explicit and well-documented failure mods – Create APIs that are self-describing and have a clear, specific purpose – Avoid leaking implementation details at all costs

APIs 創建後就不能任意更改、刪除，不然容易影響使用者，同時也要注意向下兼容與使用者的使用場景。「Keep APIs as simple as possible」- 動作越簡單越容易被重複利用、提升共用性，APIs 名稱和動作效果的關係越直覺越好，並且也要考慮到遇到 APIs 運行失敗的場景，該如何提供相關的錯誤資訊。

以此為開發準則而設計出來的 AWS SDK APIs 除了既有支援的程式語言，在今年 Developer Preview 也陸續宣布新增支援 Swift、Kotlin、Rust。

針對 AWS CDK 也正式發布了 AWS CDK v2！

AWS CDK 是可以讓 Developer 透過自己熟悉的程式語言如 Typescript、Python、Golang 等(Elad 帶領了整個 CDK 社群將 AWS Service Resources 基於 AWS Best Practices 封裝為一個個的 Construct)，提供 Developer 以 Construct 的角度帶出 Application as a Code 的概念，能快速的打包並轉譯成大家熟悉的 CloudFormation 作部署。

CDK v2 版本改善了許多在部署時的體驗，比方說支援 Hot Swap，過去在做 Lambda Function 程式碼版本切換時，會需要整個 Rebuild Lambda Function 的動作，讓新版本替代原版本；而透過 Hot Swap 可直接針對 Function 中的程式碼做置換，來大幅度節省部署的時間！

爾後也推了出 Construct Hub，讓開發者可以快速的使用、搜尋、甚至一同貢獻自定義的 CDK Construct 來參與整個 CDK 社群的開發。

Liberty Mutual Insurance

由來自 Libert Mutual Insurance 的 Technical Architect Matt 登場介紹

從 2014 年開始將 Application 架構等資訊服務 Migrate to Cloud，除了原本開發的 Workflow 與 Knowledge，需再花許多的心力投入於學習 AWS Services，甚至結合兩邊以打造新的開發體驗。

打從 2019 年發布 AWS CDK 後，AWS 就先透過內部 PoC 專案以 TypeScript 用 CDK 寫了 API GW 與 Lambda，僅僅只編寫 14 行程式碼就產生 1500 行的 CloudFormation Template，大大的降低 Develoepr 搭建 Appliction 的 Loading！

並且 CDK 社群提供非常豐富的學習資源，來幫助大家學習及測試。此時也提到 CDK 社群的活躍程度，當一個 AWS 服務或是功能新發布，CDK 社群二話不說馬上捲起袖子開發，不需一個星期的時間就能 release 出來讓大家都可以用 CDK deploy 最新最潮的 AWS 服務與功能！

透過一開始提的企業學習風氣、結合 AWS CDK 與 AWS 的學習資源，不僅大幅度降低學習成本、同時也轉換出更多的開發能量，而且打造出來的服務框架全部都是 follow AWS Pattern 與 Best Practices，甚至連剛 On-board 的新人都能在 Day 1 就開始貢獻！

Sustainable Future

為了永續經營，很重要的是要讓使用者們知道他們目前使用了多少 Energy 來支撐 Business 的運作。去年 re:Invent 時，Peter 提出了 「The greenest energy is the energy you don’t use」，我們需要知道如何更有效率的使用這些 Energy 便成了很重要的議題。

透過 Cloud 我們可以使用最新的硬體設備，以更低的能耗比換取更高的效能，因此 AWS 也持續地推出新的硬體設備讓使用者有更多選擇。那如果選用 Serverless 的話，因為其底下的 Server 與資源調用均由 AWS 管理，而 AWS 能把能源耗損更有效率的轉換成效能，並支撐使用者的需求，如 AWS Lambda Function 的調用、AWS Fargate 支撐 Container application 等情境。

基於使用者會依據各自場景的需求，啟用不同的 AWS Services 搭載架構支撐商業邏輯，既 Security Shared Responsibility 之後，又推出了 Sustainability Shared Responsibility 永續發展責任共擔模組！將 AWS 與使用者的責任分為 AWS own “of” 和 customer own “in” 兩部分，如果是選用 Serverless Services 的話，則部分會轉往由 AWS 負責。

客戶或使用者可透過前一天由 Peter 發布的 AWS Customer Carbon Footprint Tool 來獲得能源與碳排放足跡的使用報告。

Dr. Werner 在 re:Invent 2012 時曾提及「Don’t forget to turn off the lights」的概念，帶出適時 review 資源使用狀況，加以判斷是否需要 Scale in or down，甚至是查找多餘的服務資源用量都是很重要的事，且再次強調這些事情在永續經營責任共擔模型是由客戶負責的。

更進一步地說明，Latency 由 1.5s 縮短為 1.2s 對使用者體驗有極大的改善，同樣在能源消耗也佔有極大的成份，這短短的 0.3s 可以節省多少能源？從這觀點可以幫助使用者回顧自身架構會造成多少能源的浪費，而這觀點及角度是以往多數使用者忽略的事情。

也因為這一塊是需要大家共同負責及學習，AWS Well Architected Framework 新增了第六大模塊：永續經營 Sustainability Pillar，來協助使用者 Review 並持續改善。

同時推出 AWS re:post 一個 AWS 社群，讓大家可以透過社群的力量協助彼此！也再度提及去年發布的 Amazon Builder Library，裡面有很多實用且標準的解決方案可作為學習參考。

Build Something Completely New

Cloud 服務持續地推陳出新及改善體驗，也會一同推動開發方式的改變，如同 AWS CDK 大大地改變了 Resource 與 Application 開發、部署的體驗！這些改變與衝擊都能再帶來更多創新的想法，這些新點子又能再推動下一輪的改變，Dr. Werner 將這個循環以 AWS Flywheel 的形式分享給大家，並鼓勵大家持續地打造及設計足以撼動世界的創新！

–>

Amazon Games – New World

New World 是一款由 Amazon Games 發行的 MMORPG 遊戲，全部基於 AWS Services 的架構來設計及打造，如大家熟悉的支援任務、人物、故事線等等 RPG 的元素。

相比過往的遊戲架構，透過分散式伺服器的設計概念來支撐整個遊戲世界的運行，將每一組的 Clients 分組為不同的 Single World，每一組 Single World 由不同的 Server 集群來支撐。New World 的遊戲體驗作為開放世界 Open World，每一個 Single World 的 Server 集群會再進一步分組去 host 開放世界中不同的區塊，並且每一區塊之間都由不同的 Server 負擔，以這樣的設計來確保區塊之間轉換的順暢度。

除了提到透過 EC2 的運算能力作為強大的遊戲主機外，不同 Single World 的每一區塊中都會生成大量的資料，而這些資料的交換是由 DynamoDB 來支撐資料讀寫。去年提的 Observability 在大型 MMORPG 遊戲中尤其重要。遊戲中所產生的 log 透過 Kinesis 串流到 S3 與 Redshift 做存放，再以 ElasticSearch 來視覺化這些資訊。

遊戲中也會有許多的角色互動，比方說與 NPC 對話、接任務、解任務、商店買賣等非即時戰鬥的日常操作，都透過 Serverless API 的架構做 workload 的乘載。至於 Client Session 或是 Session-based 的操作都還是透過 EC2 去做連線控管。

透過詳細的架構分享，帶給大家的概念其實是以這樣的方式打造一個 Fully born in the Cloud 的 MMORPG 遊戲。New World 也已經在 2021 年 9 月份發行，可透過 Stream 購買遊玩。

Build System the Way You Always Wanted

不同於 Amazon 或是 AWS，Dr. Werner 勉勵大家勇於用自己的方式來建構你想要的系統，並強調沒有人可以跟你說你不能，而是「沒有做不到，只有想不到」。

我們基於 Cloud 去設計系統、架構時會考量是否具有 Fault tolerant、Secure、Scalabe、High performing、Cost effective、Sustainable 等六個特性。這概念來自於 Dr. Werner 於 re:Invent 2012 Keynote 時所提出 21st Century Architecture。

如果有興趣的讀者歡迎點選觀看：2012 re:Invent Day 2 Keynote: Werner Vogels

回顧當初所提及的幾個元素，重申了以下幾點應該從 Day 1 就一定要做的：

• Protecting your customer is the first priority
• Integrate security into your application from the ground up
• Instrument everything, all the time

當中最重要的是要「好好地保護 Customer」，持續並永遠都位於 Pirority 1！在打造 Application 時，人們常因專注於 How to build 而疏忽了安全性，請謹記從 Day 1 就要開始隨時隨地思考到 Security ，如 IAM 權限控管、如何保護客戶的資料、如何追蹤 API 呼叫行為…等不同層級，如此才能保護好我們的 Business，同時也保護好我們的客戶！

並同時打造好一個持續追蹤的方式，一但服務上線、客戶開始黏著後，除了 Feature 的更新，也要考慮到怎麼確保 Security、How to Operation，而後續這些維運行為所花費的時間與力氣，一定會比打造服務來的多，這也是為什麼去年提出 Observability 的重要性。

最後的最後，Dr.Werner 鼓勵大家要實際地「動手去做去打造」才會產生、造就價值！

NOW! GO BUILD！