若收到如下列類似的AWS，帳戶異常活動通知，務必前往帳戶進行確認，避免被駭客入侵
以下為未經授權的IAM使用者信件範例
當管理者收到錯誤通知「RDS Error: Access denied for user 'rdsadmin'@'localhost'」，而其他雲端人員表示未曾使用/開通相關服務時，可依以下列舉原因檢查：
IAM 角色或權限設定問題
如果角色或策略配置不當，就會導致「Access Denied」錯誤。
應用程式或自動化腳本錯誤
如果應用程式或自動化腳本錯誤地使用用戶身分訪問資料庫，並且該用戶的權限不正確，就會發生「Access Denied」錯誤。
資料庫存取問題
防火牆、VPC 安全組或 NACL 設置錯誤，可能會阻止用戶連接，從而導致訪問拒絕。
服務設置時連帶啟動/啟用
如果 EC2 實例、Lambda 函數或其他服務無意中引用了資料庫的資源，這些服務可能會使用RDS，且以用戶身份嘗試訪問資料庫。
檢查 IAM 角色和策略：確認與AWS服務相關的 IAM 角色和策略配置，確認用戶訪問權限。
檢查自動化腳本和應用程式：確認自動化流程、Lambda 函數、EC2 實例等是否錯誤地使用 rdsadmin 用戶，並檢查資料庫連接設置。
檢視有無其他帳號使用者進行啟用程式而串聯啟用此類資源：須檢視系統紀錄、系統通知與雲上資源，以確認或排除此可能性。
當AWS EC2實例本身出現數據不足（例如存儲、內存或網絡資源不足）時，且因此發生重啟，通常是因為EC2內部資源分配或使用達到極限，導致實例無法正常運行，進而觸發重啟或宕機。可依序檢視EC2以下功能是否正常：
1. 檢查 EC2 實例的 CPU、內存和磁碟使用情況
如下圖，在EC2檢視時選取並檢視項目如CPU、內存、磁碟與網路，會即刻呈現使用情形：
2. 查看 CloudWatch Logs
(1)查看EC2系統日誌：檢查 EC2 系統日誌，了解是否有硬體或系統錯誤的記錄。
(2)查看CloudWatch監控指標：在 CloudWatch 中查看 EC2 的 CPU 使用率、記憶體使用率、磁碟 I/O 等指標。這些指標能幫助確認資源過載的時間與資訊。
3. 查看 AWS Health Dashboard
有時 AWS 本身的基礎設施問題（如區域內的硬體故障）會導致實例異常重啟。可以查看 AWS Health Dashboard 以查看是否有任何影響你的區域或服務的問題。
常見的故障排除方法：
1.重啟實例：如果實例的狀態檢查未通過，首先重啟實例可能會解決許多暫時性問題。
2.停止並啟動實例：如果重啟無效，可以停止並重新啟動實例，這樣會將實例移動到新的物理主機上。
3.更換實例類型：若實例仍處於過載狀態，可以考慮升級實例類型(提升規格等)，並協助調整所需設定。
4.若異常發生當下有排程工作，應確認應用程式方面有無錯誤，是否有程式衝突/資源瓶頸
以下技術文技可供參考
當帳號下出現啟用AWS新資源的操作時，如何設置自動告警並發送通知，並記錄後續行為？以下將設定以"創建新虛擬機EC2 實例"來舉例說明：
1. 啟用 AWS CloudTrail 並將事件發送至 CloudWatch Logs
使用 CloudTrail 進行的記錄可以被用來進行安全審計、合規性檢查、故障排除和事件回溯。其中具備每個事件詳細信息（如時間戳、來源 IP、執行的 API、請求的參數等），可實時監控並將事件資料儲存於系統日誌中，供爾後檢視資源被啟用後的相關操作。
2.設定AWS SNS主題與發送通知
SNS (Simple Notification Service) 主題可設置告警接收者信箱資訊，使狀況發生時系統即刻發信給指定人員。
3.創建 AWS EventBridge規則
此規則將監控 EC2 Instance State-change Notification事件，這是創建新 EC2 實例的觸發事件。相關參數如：state: ["pending"] ，代表 EC2 實例正在創建的狀態。另外，EventBridge 偵測到資源 被創建的行為後，會將事件傳遞至 SNS，以便發送通知。
收到信件即表示設定正確。
以上相關設定是啟動了自動化告警，提高使用者對雲資源的管理效率，也能及時發現資源被啟用，以降低額外運營成本。
參考資料：
當遭遇DDoS攻擊後，為防止業務損失再發生，還可以購買AWS哪些服務來阻擋 DDOS 攻擊?
以下依序介紹：
1. AWS WAF (Web Application Firewall)
AWS WAF 是專為Web應用程式設計的防火牆，可以幫助您過濾不必要或有害的流量，並阻止惡意請求。AWS WAF 可以與NLB（及其他AWS服務如ALB、API Gateway等）結合使用，對進入的流量進行過濾。
(1)AWS WAF 配置：
自訂規則： 可以根據IP地址、HTTP標頭、URI、參數等設置自訂過濾規則。您可以設定特定的安全規則來攔截來自可疑IP地址或特定模式的流量。
自動規則： 可以使用AWS WAF提供的Managed Rule Groups，這些規則集由AWS或第三方提供，並且會不斷更新以防範最新的攻擊技術。
(2)AWS WAF與Shield Advanced的整合：
Shield Advanced和WAF可以配合使用。WAF可以過濾不必要的HTTP/HTTPS流量，而Shield Advanced則專注於對抗大規模的DDoS攻擊。這兩者結合能提供更全面的防護。
2. AWS Shield
AWS提供了兩個層級的DDoS保護服務：AWS Shield Standard和AWS Shield Advanced。
(1)AWS Shield Standard：
AWS Shield Standard 是內建的免費DDoS防護服務，對所有AWS用戶自動啟用。它提供基本的防禦功能，可以抵擋常見的DDoS攻擊（如SYN/ACK flood、UDP反射攻擊等）。對於大部分基於互聯網的攻擊，此功能已能提供足夠的防護。
(2)AWS Shield Advanced：
如果面對的是更高層級的DDoS攻擊（例如大規模的攻擊），可考慮升級到 AWS Shield Advanced。此服務提供更高級的保護，包括：
。自動檢測和緩解更複雜的DDoS攻擊。
。高級DDoS攻擊報告和分析。
。與AWS WAF整合，可以針對攻擊模式進行更精細的控制。
。可以使用AWS DDoS成本保護，防止DDoS攻擊帶來的額外費用。
3. AWS Firewall Manager
如果有多個AWS帳戶或資源，AWS Firewall Manager 可以幫助集中管理和統一配置WAF和Shield的規則。這使得防護多個服務變得更加簡單。
4. Amazon Route 53
如果流量預判來自於全球，可以使用 Amazon Route 53 的 Geo DNS 和 Traffic Flow 功能來將流量分配到不同的區域，這樣可以減少DDoS攻擊的影響。
5. Amazon CloudFront
將流量通過 Amazon CloudFront（AWS的全球內容傳遞網路）來加速，並利用它的DDoS保護。CloudFront可以緩解來自全球的攻擊流量，減少源伺服器的負擔。
總結以上服務，可以歸納為：
AWS Shield Standard：提供基礎且免費的DDoS保護，適合中小型流量攻擊。
AWS Shield Advanced：經付費後將啟用高級DDoS保護，適合面對大規模攻擊的情況。
AWS WAF：用來設定自訂規則來過濾HTTP/HTTPS請求，並防止不必要的流量進入。
AWS Firewall Manager：如果有多個帳戶或資源，此方面的設定將有助集中管理防火牆規則。
Amazon CloudFront：可以透過CDN來減少源伺服器的負擔，並提供DDoS防護。
參考文件：
Responding to DDoS events in AWS - AWS WAF, AWS Firewall Manager, and AWS Shield Advanced
AWS Shield Standard overview - AWS WAF, AWS Firewall Manager, and AWS Shield Advanced
AWS Shield Advanced overview - AWS WAF, AWS Firewall Manager, and AWS Shield Advanced
AWS Firewall Manager - AWS WAF, AWS Firewall Manager, y AWS Shield Advanced
Amazon CloudFront - AWS Best Practices for DDoS Resiliency
因業務擴展，將在現有AWS基礎上建立新EC2，並將原EC2資料複製給新EC2，以便參考與校正資訊。想確認要如何將舊機器裡的數據資料"完全的複製"到新機器上面去?
可以將舊EC2 在 EBS 快照功能裡，創建出一個新 EBS 卷，然後將這個卷附加到新 EC2 實例，這樣可以達到目的。步驟說明如下：
1. 創建 EBS 快照
首先，登錄到 AWS 管理控制台。進入 EC2 控制台，在左側會看到，選擇Elastic Block Store，點擊指定的EC2後選擇 Create Snapshot（創建快照）。填寫快照的描述，並確認創建。
2. 從 EBS 快照創建新 EBS 卷
在左側Elastic Block Store點擊底下的Snapshot，勾選剛創建的這筆資料，並點擊右邊Actions，指定他選項中的”Create volume from snapshot”
對話窗中出現volume的相關訊息，可以指定colume type類型，size大小，IOPS，可用區等資訊後，確定後按下”create volume”進行作業。
作業完成後將在左側Elastic Block Store的Volumes找到剛完成的volume。
3. 將新的 EBS 卷附加到新 EC2 實例
完成新 EBS 卷的創建後，你可以將它附加到新 EC2 實例。
在左側Elastic Block Store的Volumes（磁碟） 頁面中選擇剛創建的 EBS 卷。
點擊 Actions（操作），然後選擇 Attach Volume（附加卷）。
選擇要附加的 新 EC2 實例。
點擊 Attach（附加），將卷掛載到新 EC2 實例。
4. 在新 EC2 實例上掛載新 EBS 卷
在新 EC2 上需要手動掛載該 EBS 卷，才能使其可用。以下以LINUX系統為示範：
(1)在使用SSH 登錄到新 EC2 實例後，運用指令 lsblk 或 fdisk -l 命令檢查新附加的 EBS 卷。通常會顯示為 /dev/xvdf 或 /dev/nvme1n1。
(2)在創建一個目標掛載點（例如 /mnt/data）：
sudo mkdir /mnt/data
(3)使用 mount 命令將 EBS 卷掛載到該目錄：
sudo mount /dev/xvdf1 /mnt/data
(4)如果這個 EBS 卷是用來存儲數據，則在掛載後可以開始使用它。
可參考資料
Amazon EBS snapshots - Amazon EBS
在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 實現高效的通知與消息傳遞！如果有其他問題或需要深入討論特定場景，歡迎告訴我！
如果遇到用 EKS 建立節點（EC2 實例）時，這些實例自動附帶的 EBS 捲和網路介面並沒有自動打上他們想要的標籤。換句話說，EC2 實例標籤OK，但磁碟區和 ENI 標籤缺失，需要手動或額外配置來補上，如果遇到該情況該如何處置呢?
可參考以下文件，定義標籤使用方式。
1. EKS （eksctl）：
使用 eksctl 定義EKS標籤
https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/eks-using-tags.html#tag-resources-console
2. EBS（Storage Class）：
使用 StorageClass 定義 EBS 標籤。
https://docs.aws.amazon.com/zh_tw/eks/latest/userguide/create-storage-class.html
3. ENI（VPC CNI ）：
使用 VPC CNI 定義ENI標籤
https://docs.aws.amazon.com/zh_tw/eks/latest/userguide/vpc-add-on-create.html
當 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
AWS ADS 和 MGN遷移應用
在進行地端伺服器（on-premises servers）遷移到 AWS 雲端的過程中，AWS 提供了多種工具來協助遷移工作，兩個常見的選擇是
AWS Application Discovery Service (ADS) 和 AWS Application Migration Service (MGN)。這兩者適合於不同的遷移需求，以下是它們的介紹和使用方式：
AWS Application Discovery Service (ADS)
使用 AWS ADS 的步驟：
適用場景：
AWS Application Migration Service (MGN)
適用場景：
AWS MGN 的使用步驟：
總結：