鐵人檔案
AWS 服務很多，同一項需求也往往有不只一種做法。本系列會以 Cloud Architect / Pre-sales 的實務視角，從需求拆解出發，用 30 天整理多帳號治理、身分權限、網路、資料庫、儲存、災難復原、遷移、自動化與成本最佳化等常見主題。
內容不只介紹服務功能，也會比較不同方案的適用情境、限制、維運負擔與設計取捨，並搭配 AWS 官方文件及簡單的實作或情境推演，一起了解 AWS 架構「為什麼這樣選」！
在 Cloud Architect / Pre-sales 的工作中，收到的需求通常不會是一份完整的技術規格，更多時候只有一句話： 「海外使用者連線很慢，希望可...
昨天提到，面對一個 AWS 需求時，我不會急著選服務，不過，實際開始整理需求後，還會遇到另一個問題：客戶提出的每句話，看起來都很重要，到底該先看哪一個？ 假設客...
前兩天談的是面對需求時，如何確認條件並選擇服務，不過，隨著系統和專案增加，架構問題不只是哪個服務比較適合，還會開始遇到另一件事：如果公司有不只一個 AWS 帳號...
上一篇把帳號放進 AWS Organizations，透過 OU 與政策建立管理邊界，不過有了 Organizations 之後，下一個問題通常不是「能不能集中...
上一篇提到，Control Tower 與 AWS Organizations 可以透過 Controls、SCP 等機制建立帳號層級的治理邊界，不過帳號允許使...
上一篇提到，AWS 不會只看到一條 Allow 就停止判斷，同一個帳號內，Identity-based Policy、Permissions Boundary、...
上一篇比較了兩種跨帳號存取方式： 使用 Resource-based Policy，讓來源帳號的 Role 直接存取目標資源。 使用 AssumeRol...
上一篇已經完成共用測試環境的準備，在 Account B 建立 S3 Bucket，並在 Account A 建立 EC2 與 OrderApiRole，透過...
上一篇透過 IAM Policy 與 Bucket Policy，讓 Account A 的 OrderApiRole 直接讀取 Account B 的 S3...
前面三篇處理的是應用程式的跨帳號存取：讓 EC2 使用 IAM Role，讀取另一個帳號的 S3，接下來換成人員的存取管理。 如果每個帳號都要分別建立 IAM...
