AWS

前言 - 現有架構的挑戰 最近，我在一個 Serverless 專案中遇到了一個讓人頭疼的挑戰。這個專案運行在多個 Lambda Functions 之上，為了避免冷啟動帶來的延遲問題影響使用者體驗，需要確保 Functions 處於「熱啟動」狀態（Warm Start），如何有效管理大量的預熱 (prewarm) 操作變得非常棘手。 常見的解決方案之一，是為每個 Lambda Function 配置一個 EventBridge Scheduler，雖然可以達到預熱效果，但： 管理成本高：需要單獨為每個 Lambda Function 配置 Scheduler，數量多難以管理。 靈活性不足：難以快速響應需求變更，重新部署新的 Lambda Function 時，需要修改 Scheduler 的 Target。 基於這些挑戰，我開發了 Tag-Based Lambda Warmer Terraform Module，提供了一種低成本、高靈活性的解決方案。 Tag-Based Lambda Warmer 介紹 Tag-Based Lambda Warmer 的核心理念非常簡單： 將需要被預熱 (prewarm) 的 Lambda Function 加上指定的 Tag（例如：Prewarm=true）。 當你部署 Terraform Module 後，EventBridge Schduler 會定期調用 Tag-Based Lambda Warmer，Warmer 會根據 Tag 自動篩選需要被預熱的 Lambda Functions 這套解決方案特別適合以下情境： 低流量、間歇性工作負載：例如開發環境或小型應用中的 Lambda Functions，需要偶爾處於熱啟動狀態，但不需要持續高效能。 多環境管理：通過不同的 Tag（例如 Environment=dev 或 Environment=prod），可以輕鬆在多個環境中靈活部署。 成本敏感型專案：對於中小型 Serverless 應用，這種解決方案能有效降低運維成本。 還是要提醒，這種透過定期調用來保持熱啟動狀態的解決方案，只能讓你保持至少有一個熱啟動狀態的 Execution Environment，今天流量突然有一個高峰，碰上冷啟動是不可避免的...

(原本沒打算寫那麼多，結果每個故事的前因後果，一個連結一個，就越寫越多了) 最近我從第六屆 AWS Educate 雲端大使計劃畢業了！第六屆大使計劃任職期間真的非常充實且充滿挑戰，我也在這段旅程中成長了非常非常多。 這篇文章會從我踏上資訊科技之路開始說起，一直到我加入 AWS Educate 雲端大使計劃，再一一回顧我在第六屆 AWS Educate 雲端大使中的一些成就和重要活動，最後也會分享一些我在這段旅程中的收穫和成長，以及我的近期未來規劃。 我和 AWS 的淵源，我又是怎麼一路成為 AWS Educate 雲端大使 「我覺得我很幸運，我算是在很早期就對於職涯目標很明確，而且到越後期越明確。」 講到這個，回憶起高中時，學校為了我們選組還有選大學科系有做了兩次興趣測驗，我只知道測驗結果顯示我的興趣鑑別度很明確，而且我在資訊管理學系超級高分，重測一次的結果也是一樣，也因此我很早的志願就是「資訊管理學系」，所以學測完申請學校時，每個學校都填資訊管理學系。後來就進入了輔仁大學讀資管系，現在回頭看，真的沒選錯路，完完全全選對路。 2022 踏入職場後與 AWS 的第一次接觸 我是從大二開始進入職場實習的，這間公司叫做 eGroupAI，主要產品有兩個，分別是人臉辨識系統和 SaaS 企業管理平台，當時我就是以一個菜鳥實習生身份進入，也是第一次見證到真正業界的開發流程，當時的公司主要使用 Spring Boot，如果要加入公司的正式開發的行列，需要歷經一個實習生考試，沒有考過就是直接掰掰，所以當時白天實習，晚上回到家要瘋狂讀課程和寫作業，還好最後考過了。 加入正式開發的行列後，第一件事情就是要配置好開發環境，光是裝 IDE, JDK, 配置一堆有的沒的就可以用掉一整個工作天，我當時跟 AWS 的第一次接觸，就是主管叫我去安裝 AWS CLI，配給我一個 IAM User 的 Access Key ID 和 Secret Access Key (簡稱 AKSK)，然後輸入一些指令，當時我其實也不知道那是什麼，問了主管這個是什麼東西，他說因為開發會有一段會經過雲，後端有用到 DynamoDB，這樣你在本地開發時才有權限去處理那邊的東西。 而也隨著我在學習的過程，我開始對整個軟體的運作流程以及架構逐漸明朗，也因此我與雲端的淵源越來越深，認識的也越來越多。2022 年的某天，我參加了 AWS Educate 舉辦的工作坊，而且是辦在 AWS 辦公室裡面，正好可以去參觀一下。當時在工作坊尾聲時，有一個最大獎，只要回答出今天講的服務的一個實際應用案例，就可以拿走，正好我當時開發時就有處理過 S3 相關的東西，所以我腦海馬上蹦出我在開發上的實踐，最後這個大獎就被我拿走了，當時這個小小成就感影響我蠻大的，讓我有繼續探索雲端技術的動力。 不夠自信讓我差點卻步申請 AWS Educate 雲端大使計劃 隨後就是我迷上了雲端技術，當時 AWS 大大小小的活動我都一定會參加，但是 AWS 的活動都舉辦在平日，為了參加活動我都必須翹課，而且排班時都要避開 AWS 活動日，而當時我對容器化很感興趣，所以每個活動的下午分場議程我都專挑一些 Modernization 或是 Container 相關的主題，那時候有一個 Solutions Architect (SA) 他叫做 Kerrigan ，我特別喜歡他的演講風格，而且他演講的主題多半都和我感興趣技術有關，那時候我剛開始經營 LinkedIn，當時我認為建立關係是一個很謹慎且重大的事，很怕一個菜雞學生跟大神建立關係會被拒絕，某次演講結束後我就寫了一段訊息然後鼓起勇氣去建立關係，這是我第一次跟原本不認識的人建立關係，而沒多久後我看到被接受邀請的通知就超開心，而且 Kerrigan 也有給予我一些正面回應。現在回頭看，雖然好像只是簡單的建立關係，但對當時的我來說是相當大的鼓舞，這是能讓我繼續往雲端技術探索動力來源之一。...

最近正在準備 AWS ANS 證照剛好學到 AWS Site-to-Site VPN，也因此實作練習對我來說很重要所以打算寫這篇文章，一方面記錄實作過程一方面留著可以作為教學文章供他人參考 這篇文章將教學如何在 AWS 上建立 Site-to-Site VPN，我們會使用 Libreswan 來配置 VPN Server，這樣就可以在 AWS VPC 和 Data Center (本文示範會在 N. Virginia Region 中建立 VPC 來模擬 Data Center) 之間建立一個安全的 VPN Tunnel，讓兩者可以互相通信 一、創建 VPC (Oregon Region) 首先我們先創建架構圖右邊 AWS 的 VPC，因此我切換到 Oregon Region，並且依照下圖配置 VPC 以及 Subnet 二、配置 Route Table (Oregon Region) 然後創建 Route Table，並和上一步創建的 Subnet 建立 Association 我們要修改 Subnet 的 Association，確保該子網與我們剛才創建的路由表關聯在一起 如下圖配置 Route Table association 三、創建 EC2 Instance (Oregon Region) 接著進入 EC2 Console 頁面，現在要在剛才的 Subnet 啟動一台 EC2 Instance，若沒提到的地方可以保持預設...

大家好，我是 Shiun，今天想和大家分享我在 eCloudValley MSP 部門擔任雲端工程師實習生的經歷。這段實習讓我學到了很多實用的雲端技術，同時也在工作中遇到了許多有趣的挑戰。 實習工作內容 在 eCloudValley 的實習期間，我主要負責以下幾項工作： 學習使用公有雲，包括 AWS 和 Azure。 開發公司內部的 GenAI 應用。 與同期且同部門實習生共同開發專案。 定期與 Mentor 開會。 參與最終展演。 撰寫系統文件。 實習期間大事紀 專案大改方向 在 eCloudValley 實習期間，我們的專案經歷了一次重大轉變。起初，我們的任務是開發一個 AI Bot 開單助理，目的是幫助客戶在雲端遇到問題時能夠迅速獲得支援。這個專案的初步構想是： 客戶向 AI 助理求助，並向 AI 助理提供必要資訊，例如： EC2 SG Inbound Rule, 健康檢查狀態… 等等 如果客戶提供的資訊不夠明確，AI 助理要明確地告知客戶還需提供哪些資訊。 AI 助理彙總客戶問題，轉化為技術人員易於理解的語言。 將資訊轉化後，開 ticket 到開單系統。 然而，在實作過程中，我們發現這個 AI 助理的效果不如預期，且後續優化存在技術瓶頸。客戶問題過於多樣化、且問題幾乎都很具情境，不是那種有標準解答或是標準 SOP 就能解決的問題，所以 AI 助理難以處理，導致準確率低，最終還是需要人工介入，反而增加了工作量。 因此，我們在 4 月底決定將專案轉變為一個「會議錄影機器人」。這個機器人會被邀請到 LINE 群組中，默默記錄每一條訊息以及圖片 (圖片透過 Claude 3 Sonnet 取得 Caption)。TAM 只需在群組中輸入特殊指令或貼圖即可控制錄影，最終在前端頁面查看記錄並由 LLM 總結，創建 Ticket 到 MSP 部門的 Ticket System。...

情境描述 上圖顯示的是我剛在 Cognito User Pool 中新增了一個 user，可以注意到箭頭處顯示 Force change password。 當這個 user 嘗試首次登入時，他們會遇到這樣的情況: { "message": "New password required"， "challengeName": "NEW_PASSWORD_REQUIRED"， "session": "AYABeAsYJsR3yEr0iJssKPPUPEgAHQABAAdTZXJ2aWNlABBDb2duaXRvVXNlclBvb2xzAAEAB2F3cy1rbXMAS2Fybjphd3M6a21zOnVzLXdlc3QtMjowMTU3MzY3MjcxOTg6a2V5LzI5OTFhNGE5LTM5YTAtNDQ0Mi04MWU4LWRkYjY4NTllMTg2MQC4AQIBAHhPj7k9zU4nGXUQUvM0Ccwk42DS-fm3vKmH75ktTrktNQG1gnjl6HkUVUYN1J_HPow6AAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMulTha32s34j2CmQWAgEQgDtog8CDFh2e-4YyjM2kB_MXheMgmrdY_IF3aN9TImZXddMBj7djEAPPduLZnG3ddBLYQa8x3T3WPKUkvwIAAAAADAAAEAAAAAAAAAAAAAAAAADCbdmpLPo0E4QkWLlyH8ov_____wAAAAEAAAAAAAAAAAAAAAEAAAC1oMtgshmuUU4fk36WHKBzPgJEoE1MmL0PFyhR9lRcimImOIObhhxvC1fwiYylgbYx0Gu0i1cp5Le8AvrAnUGEJjZp54TMPP4N-JCT3qSrHeq_Kat_2CuECVSQqkc1qH4z9FVOTvAnos4FrDSn2W6KvFfLo8YQh2LJxM1h3GdIeyYqj7Ipfk6PZKGYmV5P741rRMNcuYBtvE8Hq9gVqMbEPG-c5MppY_q9JoG9TyQRN7rVGlZf62_WtTqST2F3-DZPoXTMTyY"， "challengeParameters": { "USER_ID_FOR_SRP": "shiun"， "requiredAttributes": "[]"， "userAttributes": "{\"email\":\"xxxxx@gmail.com\"}" } } Cognito 回傳了一個 NEW_PASSWORD_REQUIRED 的 challenge，同時給了我們一個 session token。這就是我們需要處理的 case。 解決方案 要解決這個問題，我們需要提供一個 change-password 的 API endpoint，讓 user 可以順利更改密碼。整個 flow 大致如下: User 首次登入 Cognito 回傳 NEW_PASSWORD_REQUIRED challenge 和 session token 前端帶著 session token 呼叫我們的 change-password API 密碼更改成功，user 順利登入系統 以下是一個處理這種情況的 Lambda function 範例:...