AWS的主要服務

EC2 全稱 Amazon Elastic Compute Cloud，提供可調整大小的運算能力，也就是虛擬伺服器。S3 全稱 Amazon Simple Storage Service，能以物件的形式儲存任意數量的資料。把這兩者調換的說法自古以來就常見，因此最好能從名稱的拼寫聯想到各自的角色。執行函式程式碼的是 Lambda，共用檔案的則是 EFS。

Lambda 無需佈建或管理伺服器即可執行程式碼，只會針對所消耗的運算時間計費。程式碼未執行時不會產生費用，這一點是與只要在運作就會持續產生費用的 EC2 最大的差異。並非以建立的函式數量或上傳程式碼本身的容量作為計費單位。

無伺服器並不代表沒有實體伺服器，而是指使用者不需要進行伺服器的採購、設定與擴縮。Lambda 的說明是「無需佈建或管理伺服器即可執行程式碼」，Fargate 的說明則是「不需要佈建、設定、擴縮伺服器或叢集」。實體伺服器仍在AWS一方，由使用者決定作業系統種類與修補套用方針則屬於 EC2 這類形態。

Fargate 是供容器使用的無伺服器按量計費運算引擎，不需要佈建、設定、擴縮伺服器或叢集，可作為 ECS 或 EKS 的啟動類型使用。Kubernetes 的受管理運作是 EKS，由自己選擇執行個體類型與台數的是 EC2 啟動類型，將步驟定義為工作流程的則是 Step Functions。

ECS 的容量選項，基本上有兩種：無伺服器且由AWS管理基礎的 Fargate，以及由使用者選擇並管理執行個體類型與台數的 EC2。另外還有 ECS Managed Instances、以及供地端使用的 ECS Anywhere。不論選擇哪一種，負責容器的配置與擴縮的都是 ECS，差別只在於基礎設施由誰照顧。

EKS 全稱 Amazon Elastic Kubernetes Service，是一項受管理服務，能在AWS上執行 Kubernetes，而不需自行安裝與運作 Kubernetes 叢集，且已通過 Kubernetes 一致性認證。資料庫運作自動化的是 RDS，從較近之處發送內容的是 CloudFront，分配流量的則是 Elastic Load Balancing。

Lambda 無需管理伺服器即可執行程式碼，只會針對所消耗的運算時間計費，未執行時不會產生費用。因此對於呼叫頻率稀疏的處理，等待期間不需付費的 Lambda 較為有利。讓 EC2 或 EKS 叢集持續運作的架構，即使大部分時間並未在處理，也會持續產生費用。

EC2 是官方描述為在雲端提供安全且可調整大小的運算能力的服務，按使用量付費，並可完全控制運算資源。只針對執行時間計費、不需接觸作業系統的是 Lambda，以物件為單位儲存的是 S3，將工作流程定義為狀態的是 Step Functions 的特性。控制範圍越廣，作業系統的管理就越會留給使用者，這一點也要一併掌握。

ECS 全稱 Amazon Elastic Container Service，是一項全受管理的容器協調服務，能輕鬆進行容器化應用程式的部署、管理與擴縮。提供符合 Kubernetes 的叢集是 EKS，啟動虛擬伺服器是 EC2，依事件執行程式碼是 Lambda。ECS 與 EKS 都是彙整容器的服務，差別在於是否使用 Kubernetes。

EKS 是一項受管理服務，能在AWS上執行 Kubernetes，而不需自行安裝與運作 Kubernetes 叢集，且已通過 Kubernetes 一致性認證。另一方面，ECS 是AWS的全受管理容器協調服務，不以 Kubernetes 為前提。兩者都是處理容器的服務，並非只處理虛擬伺服器映像。作為啟動目的地，兩者都能選擇 Fargate。

EBS 是供 EC2 執行個體使用的永久性區塊儲存磁碟區，會在可用區域內自動複寫，原則上是連接到單一執行個體使用。EFS 則是供 Linux 工作負載使用的檔案系統，容量會自動伸縮，支援數千台 EC2 執行個體的平行共用存取。能夠共用的是 EFS 一方，並不會兩者都以共用為前提，或都以單獨連接為前提。

S3 全稱 Amazon Simple Storage Service，是一項可擴展性與可用性優異、能儲存並保護任意數量資料的物件儲存。區塊儲存是 EBS，Linux 用的共用檔案系統是 EFS，記憶體內快取則由 ElastiCache 提供。物件、區塊、檔案這3種資料形式的差異，是選擇AWS儲存服務時的出發點。

EFS 是一種容量會依檔案增減自動伸縮、支援數千台 EC2 執行個體平行共用存取的檔案儲存服務，適合讓多台執行個體同時掛載同一個目錄的用途。EBS 是可用區域內的區塊儲存，原則上連接到單一執行個體，因此各自的儲存空間是分開的。Glacier Deep Archive 是取出需花時間的封存導向儲存類別，ElastiCache 則不是檔案系統，而是記憶體內快取。

EBS 是供 EC2 執行個體使用的永久性區塊儲存，會在同一個可用區域內自動複寫，提供一致的低延遲效能。正因具備這種單一AZ的特性，若需要跨AZ的可用性，就必須另外搭配其他機制。跨區域複寫或在邊緣節點發送內容，都不是 EBS 的角色。

S3 Glacier 是一組封存用的儲存類別，有供需即時取出資料使用的 S3 Glacier Instant Retrieval、供幾乎不存取的長期資料使用的 S3 Glacier Flexible Retrieval，以及以最低成本、花費數小時取出的 S3 Glacier Deep Archive。這是依取出速度與費用的取捨來選擇類別的設計，取出時間並非一律相同。可儲存的資料種類沒有限制，也不能作為區塊儲存來連接使用。

S3 是物件儲存，EBS 是連接到EC2的區塊儲存，EFS 是供 Linux 工作負載使用的檔案儲存。物件是透過API整份存取的資料，區塊是從作業系統看起來像磁碟的資料，檔案則是能從多台主機掛載共用的資料，這樣整理後，依需求選擇時就不容易迷惘。

EBS 是供 EC2 執行個體使用的永久性區塊儲存磁碟區，能提供一致的低延遲效能，因此適合作為作業系統或資料庫的磁碟使用。S3 是物件儲存，並非以區塊裝置的方式連接儲存貯體的機制。Glacier 是取出需花時間的封存導向類別，CloudFront 則是加快發送速度的CDN。

S3 是一項可擴展性、可用性、安全性與效能都優異、能儲存並保護任意數量資料的物件儲存，官方所列出的用途包括Web、行動裝置、備份、封存、IoT、大數據分析等。能從作業系統看成磁碟的是 EBS，以連接單一執行個體為原則的也是 EBS，將資料放在記憶體上則是 ElastiCache 的特性。

EFS 是一種簡單、可擴展且具彈性的檔案系統，新增或刪除檔案時容量會自動伸縮，不需要事先設計容量。先決定並固定容量、或為了擴增而重新建立，都是區塊儲存的思維，連接的執行個體記憶體大小也不會決定容量。這種伸縮性正是它適合作為共用工作空間使用的理由。

S3 Glacier Deep Archive 是以最低成本保存幾乎不存取的資料、取出需花費數小時的封存導向儲存類別，符合這項條件。EBS 與 EFS 都以維持取出速度為設計目標，作為長期休眠資料的存放處成本容易偏高。ElastiCache 是記憶體內快取，本來就不是用於長期保存的機制。先決定能接受多長的取出等待時間，才是選擇類別的思考順序。

RDS 是一項受管理服務，能輕鬆進行雲端關聯式資料庫的建置、運作與擴縮，會自動化硬體佈建、資料庫建置、修補程式套用、備份等管理作業。另一方面，資料表與欄位的設計、索引的判斷、應用程式的架構、資料內容的正確性，都仍是使用者一方的工作。所謂受管理，是把運作的功夫交出去，而不是連設計都交出去。

Aurora 是受管理資料庫服務 Amazon RDS 的一部分，使用相同的管理主控台、CLI、API操作來進行佈建、修補程式套用、備份、復原及故障偵測。差異在於管理的單位：標準 RDS 管理的是個別的DB執行個體，而 Aurora 管理的是以複寫方式同步的DB伺服器整個叢集。Aurora 是相容於 MySQL、PostgreSQL 的關聯式資料庫，並非鍵值型。

DynamoDB 是鍵值型與文件型的 NoSQL 資料庫，是一項全受管理且支援多區域的資料庫，能在任何規模下提供個位數毫秒的效能。資料倉儲是 Redshift，相容於 MySQL、PostgreSQL 的關聯式資料庫是 Aurora，在記憶體上讀寫則由 ElastiCache 負責。

Redshift 是雲端上全受管理、PB等級的資料倉儲服務，不論資料集大小，都能透過既有的SQL工具或BI應用程式獲得高速的查詢效能。ElastiCache 是記憶體內快取，EFS 是共用檔案系統，SQS 是訊息佇列，都不是負責大量資料統計與分析的基礎。

ElastiCache 是一項能輕鬆在雲端部署、運作、擴縮記憶體內快取的服務，透過從高速的記憶體內快取取得資訊、而不依賴以磁碟為基礎的資料庫，來改善Web應用程式的效能。加快分析用查詢的是 Redshift，降低長期保存費用的是 S3 Glacier 的儲存類別，共用目錄則由 EFS 負責。

Aurora 是相容於 MySQL、PostgreSQL 的全受管理關聯式資料庫引擎，擁有高效能的分散式共用儲存子系統，儲存空間會依需要自動擴增。不需要先決定容量再手動擴增。以鍵與值的組合儲存的是 DynamoDB，花時間取出以換取低保存費用的是 S3 Glacier 的封存導向類別。

Redshift 是全受管理、PB等級的資料倉儲服務，適合用SQL工具或BI應用程式對大量資料進行統計與分析。RDS 則是能輕鬆建置、運作、擴縮關聯式資料庫的服務，適合業務系統讀寫日常交易。兩者都用SQL查詢，看起來相似，但都不是 NoSQL，差異也不只在於資料量。

官方說明 DynamoDB 是鍵值型與文件型的 NoSQL 資料庫，能在任何規模下提供個位數毫秒的效能。Redshift 適合大量資料的統計與分析，屬於資料倉儲；RDS 負責關聯模型的讀寫；EFS 是負責檔案共用的儲存服務，都不是以此需求為首要目標的基礎。

RDS 全稱 Amazon Relational Database Service，是一項受管理服務，能輕鬆進行雲端關聯式資料庫的建置、運作與擴縮。以鍵與值的組合儲存的是 DynamoDB，記憶體內快取是 ElastiCache，大量資料的統計由資料倉儲 Redshift 負責。另外，Aurora 是以 RDS 一部分的形式提供的引擎。

Aurora 是以 RDS 一部分的形式提供，可使用相同的管理主控台、CLI、API操作進行佈建、修補程式套用、備份、復原及故障偵測。不需要另外建立管理用的執行個體，這些程序也不需要由使用者自行建置。差異在於，標準 RDS 管理的是個別的DB執行個體，而 Aurora 是以整個叢集作為管理單位。

SQS 是將訊息保留在佇列中，通常由1個消費者輪詢取出的點對點服務。SNS 是發布者將訊息送到主題，再同時推播給多個訂閱者的發布訂閱服務。把兩者互換的說法是典型的混淆，也並非兩者的配送方式相同。可以用方向來記：佇列是接收方去取的存放處，主題則是發送方推送出去的分發角色。

SQS 有標準佇列與FIFO佇列兩種，標準佇列採 at-least-once（至少一次）配送，因此同一則訊息可能送達多次。FIFO佇列具備 exactly-once（恰好一次）處理與順序保證，能保持發送順序且只處理一次。在重視順序或防止遺失的工作流程中，就會選擇FIFO佇列。

SNS 會將送到主題的訊息同時推播給多個訂閱者，訂閱者可以指定為 SQS 佇列。這種由1個 SNS 主題配送給多個 SQS 佇列的形式，正是官方所展示的典型扇出模式。佇列不是配送來源而是接收端，因此不會是佇列去讀取主題的方向。

SNS 的訂閱者類型整理為2類：指SQS、Lambda、HTTP(S)、Data Firehose等應用程式之間的A2A，以及指電子郵件、行動推播、SMS等對人的A2P。並非僅限於其中一種，也不是只以EC2執行個體為目的地的機制。這種廣泛性，正是SNS既能用於對人通知、也能用於應用程式間連接的原因。

Step Functions 是一項服務，能建立工作流程（即狀態機），用以建構分散式應用程式、將流程自動化、協調微服務，以及建立資料或機器學習的管線。各步驟稱為state，執行中的實例稱為execution。流量分配是 Elastic Load Balancing，物件的保存是 S3，鍵與值的快取是 ElastiCache 的職責。

API Gateway 是一項服務，能在任何規模下建立、發布、維護、監控及保護 REST、HTTP、WebSocket 的API，作為存取 EC2 上工作負載、Lambda、任意Web應用程式等後端的前門發揮功能。執行處理本身的是後端一方，統一套用保護規則的是 AWS Firewall Manager，於邊緣進行快取的則是 CloudFront 的角色。

EventBridge 是一項使用事件連接應用程式元件的無伺服器服務，負責事件的擷取、篩選、轉換及配送。事件匯流排是將事件從眾多來源路由到眾多目標的路由器。等候佇列是SQS的說明，狀態機是Step Functions，前門則是API Gateway的說明。

EventBridge Scheduler 是以cron表達式或rate表達式管理定期執行與單次執行的機制，因此在固定時刻啟動的需求由此處理。SQS 是保留訊息、由接收方取出的佇列，SNS 是配送給訂閱者的發布訂閱機制，API Gateway 是發布並中繼API的服務，都不是以按時刻啟動為目的的機制。

SQS 是一項安全、耐用且高可用的託管佇列服務，能整合分散式軟體系統或元件，使其鬆散耦合。受理端只要把訊息放入佇列，就能在當下回應，後續處理則可依自己的速度取出並進行，因此一方的延遲不容易拖累另一方。若採用直接呼叫或整合成一支程式的架構，後續處理的延遲就會直接變成受理端的等待時間。

SNS 會將送到主題的訊息同時推播給多個訂閱者，訂閱者可指定為SQS佇列，因此若要將1件事件配送給3個處理，就要使用SNS主題搭配多個SQS佇列的扇出模式。若讓1個佇列由3個處理共用，通常一旦有人取出，其餘就無法再收到。由發生來源發送3次，或由收到的處理再轉發的架構，每次增加目的地時都要修改發送端，無法做到鬆散耦合。