若收到如下列類似的AWS，帳戶異常活動通知，務必前往帳戶進行確認，避免被駭客入侵
以下為未經授權的IAM使用者信件範例
在AWS建立EC2時需要選定EBS 存儲選項，這些類型本身具有不同特性，會影響EC2效能，所以在選擇時應進行了解與審慎選定，以配合未來業務上的規劃與需求。
在 AWS EC2 中，gp2 和 gp3 是兩種不同的 SSD 類型的 EBS 卷（Elastic Block Store）。
1.若客戶今日設定EC2運用的場景穩定，適合不需要太高配置，可以指定使用gp2。
2.若設定EC2運用的場景，需要靈活的性能配置、高 IOPS 或高吞吐量的工作負載，
在設定初期就建議使用gp3。
而在客戶提問：如何將底層gp2 轉換成 gp3格式?
作業前須謹慎評量，並確認先數據備份，並於轉換時進行監控與調整，以應對相關風險。
在AWS EC2相關資訊中，點擊選定要進行變更的EC2，也要再次確認格式為gp2，然後利用Actions -> Modify volume來進行動作(如圖示)
後續會繼續詢問相關規格(如圖)，依次輸入後即可Modify
後續完成動作後，相關設定可按照需求轉變。
另外，從 gp2 轉變(或稱為遷移)到 gp3 是一種簡單且經濟高效的升級。AWS甚至公告，其儲存成本降低了 20%，並且無需額外容量即可提高效能。可參考技術文件鏈結[2]；其他格式可參考技術文件鏈結[3]。以上資訊供大家參考運用。
參考文件
[1]將 Amazon EBS 磁碟區從 gp2 遷移至 gp3
https://docs.aws.amazon.com/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/ebs-migrate-gp2-gp3.html
[2]https://aws.amazon.com/tw/blogs/storage/migrate-your-amazon-ebs-volumes-from-gp2-to-gp3-and-save-up-to-20-on-costs/
[3]https://aws.amazon.com/tw/ebs/volume-types/
AWS SNS 的主要功能是將消息從發佈者傳遞到訂閱者。這可以用於各種通知場景，例如：
監控警報（如 EC2 實例的健康檢查失敗）。
實現微服務之間的消息傳遞。
用於多渠道用戶通知（電子郵件、簡訊等）。
SNS 運作的核心是 Topic（主題） 與 Subscription（訂閱）：
Topic：消息的發佈點。
Subscription：接收通知的端點（如電子郵件、SQS、Lambda 等）。
以下將介紹如何設置並使用 AWS SNS：
登入 AWS 管理控制台。
搜尋 "SNS"，進入 Simple Notification Service 主頁。
點擊 Create topic。
選擇主題類型：
Standard：適用於大多數應用，支持最多一次交付。
FIFO：適用於需要消息順序和確保唯一交付的場景。
填寫主題名稱，例如：MyTopic。
點擊 Create topic 完成創建。
總結：
FIFO 就是「一步一步來，順序最重要」。
標準就是「效率優先，快就對了」。
在剛剛創建的主題頁面中，點擊 Create subscription。
選擇協議（Protocol）：
Email：將消息發送到電子郵件。
SMS：發送簡訊。
AWS Lambda：觸發 Lambda 函數。
Amazon SQS：將消息發送到 SQS 隊列。
根據選擇的協議填寫目標終端。例如，若選擇 Email，請輸入接收通知的電子郵件地址。
點擊 Create subscription。
如果選擇 Email 協議，請到郵箱查收確認信並點擊確認連結完成訂閱。
返回 SNS 主題頁面，點擊 Publish message。
填寫消息內容：
Subject：消息的主題（僅限 Email 使用）。
Message：消息的內容。
點擊 Publish message，訂閱的用戶或終端將接收到消息。
SNS 可以與許多 AWS 服務整合，例如：
CloudWatch 警報通知：當 CloudWatch 監控檢測到警報條件時，自動發送 SNS 通知。
AWS Lambda：使用 SNS 作為事件源，觸發 Lambda 函數執行處理邏輯。
SQS 隊列：將 SNS 消息發送到 SQS 隊列，實現消息的緩存或延遲處理。
SNS 支援基於消息屬性的過濾訂閱。例如，僅當消息中包含某個屬性時，才向特定訂閱發送通知。
在訂閱設定中，新增過濾策略（Filter Policy）。
例如，若您發佈的消息中包含屬性 type，值為 error，則可以設置過濾策略如下：
{
"type": ["error"]
}使用 CloudWatch Logs 監控 SNS 消息發佈情況：確保消息發佈與接收的成功率。
採用 Dead Letter Queue (DLQ)：處理無法送達的消息。
設置加密：使用 AWS KMS（Key Management Service）加密 SNS 消息，確保數據安全。
設置速率限制與重試策略：避免過載訂閱終端。
確保電子郵件訂閱已確認。
檢查垃圾郵件文件夾。
若使用沙箱環境，請將電子郵件地址添加到允許列表。
SNS 的費用包括以下部分：
消息發佈費用：根據發佈消息的次數計費。
傳送費用：根據選擇的協議（SMS、Email 等）計費。
詳細價格可參考 AWS SNS 價格頁面。
透過以上步驟與功能介紹，您應該能夠輕鬆開始使用 AWS SNS 實現高效的通知與消息傳遞！如果有其他問題或需要深入討論特定場景，歡迎告訴我！
當 AWS EC2 實例發生當機，我方進行報修後得到以下相關回應：
1.原廠工程師檢查EC2實例，未發現底層主機有硬件故障和異常時間
- status check/狀態檢查均無異常
2.原廠工程師通過CloudWatch檢查3個EBS卷，沒有發現3個EBS個卷有異常事件產生，但發現該卷vol-xxxxxx吞吐量超限：
”指標” VolumeThroughputExceededCheck: 1 表明磁盤操作導致吞吐量超過該卷的上限。
綜合分析，EC2底層主機以及EBS均無發現有明顯異常事件，所見異常可能與根卷在特定時間段的大量讀取且導致吞吐量超限有關聯。
處理 EBS 卷吞吐量超限的根本方法是升級 EBS 卷的類型和性能，根據需求選擇合適的 EBS 卷類型（如 gp3、io1、io2），並確保 EC2 實例的性能能夠配合使用的存儲資源。如果吞吐量經常超限，還需要考慮優化應用程式的 I/O 操作，或將負載分散到多個磁碟卷中。本篇先針對EBS容量、EC2類型與設置警報來做說明。
1. 檢查並升級 EBS 卷類型
EBS 提供多種類型的磁碟，根據需求選擇合適的卷型可以避免吞吐量不足的問題。可以考慮升級現有的 EBS 卷類型，以提供更高的吞吐量。
一般用途 SSD（gp3）：提供相對較好的性價比，支持自訂吞吐量和 IOPS。可以升級現有卷為 gp3，並根據需要設置吞吐量。(此選項可自定義吞吐量)
預設性能 SSD（gp2）：吞吐量會受限於卷的大小，因此，卷太小可能無法達到足夠的吞吐量。
性能 SSD（io1/io2）：提供高吞吐量和低延遲，適合要求高吞吐量和高 IOPS 的工作負載。
2. 增加 EBS 卷的容量
如果客戶使用的是 gp2 類型的 EBS 卷，吞吐量是與磁碟容量有關的。具體來說，增加磁碟容量可以提高吞吐量，避免瓶頸。另請注意：增加卷的容量（相關數值至少大於 10 GiB）。
3. 調整 EC2 實例的性能
確保 EC2 實例的大小和性能配置適合工作負載。如果使用的 EC2 實例本身的網絡性能或磁碟性能不夠強大，可能會對吞吐量設有限制。所以應根據需求進行升級 EC2 實例，選擇更高網絡性能和 I/O 性能的類型。
但此一修改須將EC2停機，才能修改實例類型，之後啟動實例還需要再確認性能是否改善。
4. 監控 EBS 性能並設置警報(避免狀況再發生的處置)
使用 AWS CloudWatch 監控 EBS 卷的性能，設置警報來提前識別吞吐量接近極限的情況。可設置警報以便當 EBS 卷的吞吐量達到一定閾值時，及時進行調整。
在CloudWatch操作介面可創建監控警報，選擇 EBS 卷的吞吐量（VolumeReadOps, VolumeWriteOps, VolumeThroughput 等指標），設定當吞吐量接近或超過閾值時觸發警報，並通過電子郵件或其他方式通知。
另外對Auto Scaling相關作法應可緩解相關異常狀況，以上資料供大家參考運用。
若要進一步針對操作系統層面檢視，原廠建議安裝atop等工具以收集相關指標與資訊，可參考下面的2個文章鏈接：
- 如何為執行 Amazon Linux、RHEL、CentOS 或 Ubuntu 的 EC2 執行個體設定 ATOP 監控和 SAR 監控工具？ 請參考網址4
- 如何使用 ATOP 工具和 atopsar 工具，取得 EC2 Linux 執行個體中程序的歷史使用情況統計資料？請參考網址5
參考網址：
1. Request Amazon EBS volume modifications - Amazon EBS
2. Amazon EBS volume types - Amazon EBS
3. Amazon EC2 instance type changes - Amazon Elastic Compute Cloud
4. 設定適用於 EC2 Linux 執行個體的監控工具 | AWS re:Post
5. 使用 ATOP 工具在 EC2 Linux 執行個體上監控歷史資源使用情況 | AWS Re:Post | AWS re:Post
使用 S3 版本控制將物件的多個版本保留在一個儲存貯體中，以便可以還原意外刪除或覆寫的物件
S3啟用版本控制
列出已啟用版本控制之儲存貯體中物件版本
1.登入 AWS Management Console 並開啟 Amazon S3 主控台。已啟用版本控制之儲存貯體中的物件
一.新增物件:
儲存貯體上啟用版本控制後，Amazon S3 便會自動將唯一的版本 ID 新增至儲存貯體中存放的每個物件 (使用 PUT、POST 或 CopyObject)。
二.擷取物件:
簡單 GET 要求會擷取物件的目前版本。下圖顯示 GET 如何傳回 photo.gif 物件的目前版本。
若要擷取特定版本，您必須指定其版本 ID。下圖顯示 GET versionId 要求如何擷取物件的指定版本
使用主控台下載特定版本
Amazon S3 會顯示該物件的所有版本。
三.刪除物件
啟用版本控制時，簡單 DELETE 無法永久刪除物件。Amazon S3 會在儲存貯體中插入刪除標記，而該刪除標記會成為具有新 ID 的目前物件版本。
若要永久刪除已使用版本控制的物件，您必須使用 DELETE Object versionId。
下圖顯示刪除所指定的物件版本會永久移除該物件
使用主控台刪除
Amazon S3 會顯示該物件的所有版本。
四、取消刪除物件
如前所述，一般刪除是新增一個具有刪除標記得新版本，若要取消刪除則需要將具有刪除標記的版本移除。您必須在 DeleteObject versionId 要求中包含其版本 ID。
如果您只使用 DeleteObject 請求，其中目前版本為刪除標記 (不指定刪除標記的版本 ID)，則 Amazon S3 不會刪去刪除標記，而是 PUTs 另一個刪除標記。
若要刪除具有 NULL 版本 ID 的刪除標記，必須在 DeleteObject 請求中作為
版本 ID 為 NULL。
1. VPC 和子網（Subnet）
首先，VPC（虛擬私有雲）是 AWS 中的虛擬網路環境，您可以在其中部署資源，如
EC2 實例。VPC 中的 IP 範圍可以根據需求劃分為多個 子網，每個子網通常位於一個特定的 可用區（AZ）。這樣的配置不僅提高了靈活性，還能確保高可用性，因為即便某個 AZ 出現故障，其他 AZ 仍然能正常運行。
2.
安全群組（SG）與彈性網路介面（ENI）
每個 EC2 實例 都會與一個或多個 彈性網路介面（ENI）
關聯，並且每個 ENI 都可以關聯到一個或多個 安全群組（SG）。這些安全群組規則像是防火牆，控制著流入和流出的流量。ENI 負責連接 EC2 實例和 VPC 的網路，而安全群組則根據需要管理網路流量的規則。
3.
路由表（Route Table）和 Internet Gateway
每個子網都有關聯的 路由表，用來控制流量的路由方向。對於位於公共子網中的 EC2 實例，您需要將 Internet Gateway（IGW） 附加到 VPC，並配置路由表，使流量能夠從 VPC 流向互聯網。這樣可以讓 EC2 實例向外界發送請求，並從外界接收回應。
4.
高可用性架構（High Availability）
為了提高架構的可靠性，應將關鍵資源分散到多個
可用區（AZ） 內。在 VPC 中，您可以將 EC2 實例部署在不同的子網中，並使用 Auto Scaling 和 Elastic Load Balancer（ELB） 來自動調整流量並實現高可用性。這樣即便某個可用區出現故障，流量仍然能夠轉向其他可用區的 EC2 實例，確保業務不中斷。
5.
NAT Gateway / NAT 實例
若您有位於 私有子網
中的 EC2 實例，這些實例無法直接訪問互聯網。這時，您可以設置 NAT
Gateway 或 NAT 實例，讓私有子網的 EC2 實例可以訪問外部服務，如下載更新或訪問外部 API。這樣的配置能夠保障私有子網內的 EC2 實例安全，同時仍然能夠利用公共互聯網資源。
6.
VPC Peering 和 Transit Gateway
在 AWS 中，您可能需要讓多個 VPC 之間進行互通。此時，您可以使用 VPC Peering 或 Transit Gateway。VPC Peering 使兩個 VPC 之間可以直接通信，而 Transit Gateway 則可以將多個 VPC 集中管理，實現更靈活的跨 VPC 通訊方式，適合更大規模的架構。
7.
VPN 連線與 Direct Connect
如果您的本地資料中心需要與 AWS VPC 進行連接，您可以使用 VPN 連線 或 AWS Direct Connect。VPN 連線 通常用於加密的網路連接，適合中小型的需求。而
Direct Connect 則提供一條專用的物理連接，適合對連接性能和穩定性有更高要求的企業使用。
8.
VPC Flow Logs
為了提升網路監控和故障排除的能力，您可以啟用
VPC Flow Logs。這能夠記錄流經 VPC 各網路介面的網路流量，幫助您監控流量走向、分析性能，並識別潛在的安全問題。
總結
這些 AWS VPC 的核心概念和組件是互相配合的，能讓我們建立一個既安全又有彈性的網路架構。透過設定路由表、Internet Gateway、NAT Gateway 等，可以輕鬆設置公共子網和私有子網，還能根據需求選擇像是 VPC Peering 或 VPN 等進階功能來擴展網路。這樣一來，不僅能保證高可用性，還能確保更強的安全性和擴展性。
AWS CloudTrail AWS 服務 是可協助您啟用您的 AWS 帳戶. 使用者、角色或 AWS 服務所執行的動作並記錄當中的事件。事件包括在 AWS Management Console、 AWS Command Line Interface和中執行的 AWS SDKs動作APIs。
CloudTrail 提供三種記錄事件的方法：
(可選擇進行新建S3儲存桶或使用現有S3儲存桶，此處已先建S3後設定的方式進行說明)
1.於AWS主控台中，搜索"S3儲存桶"，並"點選"
2.選取"建立儲存貯體"
4.建立完成後，於上方搜尋攔查找"CloudTrail"
5.於左側選項選擇"線索"→"建立線索"
6.依需求勾選設定，此處可選擇進行新建S3儲存桶或使用現有S3儲存桶，完成後點選"建立"
介紹IAM
AWS IAM (全稱:Identity and Access Management)
l
用於允許多個用戶與應用程式同時在一隻AWS帳戶底下的子帳號，透過可以設定精細的權限來進行靈活管理，以致可以實現”最小權限原則”。
l
該服務為免費服務
l
//要先透過E-mail向AWS申請頂級帳號，這帳號也就是我們所知道的Root Account。
//下圖概念與Linux OS用戶關係是一致的，Root帳號權限過大 >>> 透過IAM服務分割出用戶根群組權限。
IAM的核心組成可以用以下四個核心去看
1.使用者 (Users)
意指使用者，可以是人，也可以是應用程式或者訪問 AWS 資源的對象。
2.群組 (Groups)
群組是使用者的集合。在群組中的使用者都會繼承該群組擁有的所有權限。這樣的設計方便組織和可以簡化權限分配。
3.角色 (Roles)
角色的產生為用於職責分配所誕生，主要在於授予應用程序、服務或其他 AWS 資源訪問權限。角色與使用者不同，沒有附帶固定憑證，而是動態被 AWS 服務採用，我們舉個例子 : 讓一個 Lambda 函數訪問 S3 資源。
4.政策 (Policies)
政策是一種 JSON 格式的配置文件，用於定義權限的細節。它詳細說明了誰（使用者、群組、角色）可以對哪些 AWS 資源執行哪些操作（例如讀、寫、刪除）。政策是權限控制的核心機制。
AWS IAM政策為JSON格式的文件，政策就像規則清單，由它定義授權的詳細規則，這其中包含允許或拒絕等行為以及那些主體可以操作，還以條件約束，以下來拆分它具體的組成。
Effect
這是政策的核心，通常為兩種值，Allow(允許)與Deny(拒絕)，在預設的情況下，都是默認為"拒絕”的，如果希望特定使用者可以使用特定功能，就需要明確設置成”允許”。
Principal(主體)
主體指是”誰”會受到政策的影響
以下為受影響的常見值:
l IAM 使用者（User）
l IAM 群組（Group）
l IAM 角色（Role）
l 外部 AWS 賬戶或特定 ARN（Amazon Resource Name）
Condition(條件)
這是在政策中最靈活的一環，允許設定一些條件來進行限制訪問。比如說：
使用者必須從特定 IP 地址連接。
使用者必須啟用多重驗證（MFA）。
再比如，限制某些操作只能在特定時間內執行。
Action(動作)
該政策主要是描述主體可以執行哪一些操作，比如說:
s3:GetObject：讀取 S3 存儲桶中的文件。
ec2:StartInstances：啟動 EC2 實例。
Resource(資源)
指的是允許什麼資源可以被進行操作。例如，允許使用者呼叫Amazom 储存貯體。
l S3 存儲桶
l EC2 實例
l DynamoDB 表
IAM Role
I通過將 IAM Policy 綁定到特定實體（如 AWS 資源、應用程式或外部帳號）上，授予其對特定 AWS 資源的存取權限，而非針對一般的 IAM 使用者或群組設計。
IAM Role 的三種類型
IAM 角色（Role）是一種動態的權限分配方式，適用於各種複雜場景：
IAM Security Token Service (STS)
介紹:提供臨時憑證，適合短期訪問需求。
特點:
憑證有效期短（15 分鐘到 36 小時）。
包含會話令牌、訪問密鑰 ID 和密鑰，無需使用靜態憑證。
通常與 IAM Role 搭配，用於臨時授權或跨帳戶訪問。
自動失效，無需手動撤銷;動態管理更靈活，無需建立固定身份。
API Access Key
介紹:適合程式化訪問 AWS 的工具（如 CLI、SDK）。
建議:
禁止將 Access Key 硬編碼進程式碼或存放於 EC2 實例中。
新的 Access Key 產生後，應立即廢止舊密鑰以減少風險。