AWS 服務系列（一）：入門與核心概念 - 後端工程師必備的雲端基礎

前言

作為一名後端工程師，掌握雲端服務已經從「加分項目」變成「必備技能」。AWS（Amazon Web Services）作為全球市佔率最高的雲端平台，提供了超過 200 種服務，涵蓋運算、儲存、資料庫、網路、機器學習等各個領域。

本系列文章將從後端工程師的實務角度出發，由淺入深地介紹 AWS 的核心服務。我們不會只是照本宣科地介紹功能，而是著重於為什麼要用、什麼時候用、以及如何正確地用。

本篇作為系列的開篇，將涵蓋以下重點：

• AWS 的全球基礎架構概念
• 身份與存取管理（IAM）的核心原則
• 帳號安全最佳實踐
• 成本管理的基本策略

---

AWS 全球基礎架構

Region 與 Availability Zone

在開始使用任何 AWS 服務之前，首先需要理解其全球基礎架構的設計理念。AWS 的基礎架構由三個層級組成：

graph TD
    subgraph "AWS 全球基礎架構"
        A[Region 區域] --> B[Availability Zone 可用區域]
        B --> C[Data Center 資料中心]
    end
    
    subgraph "範例：ap-northeast-1 東京"
        D[ap-northeast-1a] --> G[多個資料中心]
        E[ap-northeast-1c] --> H[多個資料中心]
        F[ap-northeast-1d] --> I[多個資料中心]
    end

Region（區域）：

• 地理上獨立的區域，如 ap-northeast-1（東京）、us-east-1（維吉尼亞）
• 每個 Region 完全獨立，資料不會自動跨 Region 複製
• 選擇 Region 的考量因素：延遲、合規要求、服務可用性、成本

Availability Zone（可用區域，簡稱 AZ）：

• 每個 Region 包含多個 AZ（通常 3-6 個）
• 每個 AZ 是一個或多個獨立的資料中心
• AZ 之間透過高速、低延遲的專用網路連接
• 設計用於故障隔離：單一 AZ 故障不會影響其他 AZ

為什麼這個概念對後端工程師很重要？

理解 Region 和 AZ 直接影響到你的架構設計：

架構決策	影響因素
資料庫部署	Multi-AZ 部署可提供自動故障轉移
應用程式部署	跨 AZ 部署實現高可用性
災難復原	跨 Region 備份確保業務連續性
延遲優化	選擇離使用者最近的 Region
合規要求	某些資料必須留在特定地理區域

實務建議：對於台灣的服務，通常選擇 ap-northeast-1（東京）作為主要 Region，延遲約 30-50ms。如果需要更低延遲，可考慮 ap-southeast-1（新加坡）。

---

IAM：身份與存取管理

核心概念

IAM（Identity and Access Management）是 AWS 安全的基石。作為後端工程師，你會頻繁與 IAM 打交道，無論是設定 CI/CD 權限、配置服務間通訊、還是管理團隊存取。

graph LR
    subgraph "IAM 核心元件"
        A[User 使用者] --> D[Policy 政策]
        B[Group 群組] --> D
        C[Role 角色] --> D
        D --> E[Permission 權限]
        E --> F[AWS Resources]
    end

四大核心元件：

1. User（使用者）

   • 代表一個人或應用程式
   • 擁有長期憑證（Access Key、密碼）
   • 適用場景：開發人員存取、CI/CD 系統

2. Group（群組）

   • 使用者的集合
   • 便於統一管理權限
   • 適用場景：依職能分組（開發者、維運、只讀）

3. Role（角色）

   • 沒有長期憑證，使用臨時憑證
   • 可被使用者、服務、甚至其他帳號扮演
   • 適用場景：EC2 存取 S3、Lambda 執行、跨帳號存取

4. Policy（政策）

   • JSON 格式的權限定義文件
   • 定義「誰」可以對「什麼資源」執行「什麼動作」

IAM Policy 深度解析

Policy 是 IAM 的核心，理解其結構至關重要：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadAccess",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket",
                "arn:aws:s3:::my-bucket/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        }
    ]
}

Policy 結構解析：

欄位	說明	範例
Version	Policy 語法版本	固定使用 2012-10-17
Statement	權限聲明陣列	可包含多個權限規則
Sid	聲明識別碼（選填）	用於識別和說明
Effect	允許或拒絕	Allow 或 Deny
Action	允許的操作	s3:GetObject、ec2:*
Resource	作用的資源	ARN 格式
Condition	條件限制（選填）	IP 限制、時間限制等

最小權限原則（Principle of Least Privilege）

這是 IAM 設計的黃金法則：只給予完成任務所需的最小權限。

graph TD
    A[錯誤做法] --> B["Action: '*'<br/>Resource: '*'"]
    C[正確做法] --> D["Action: 's3:GetObject'<br/>Resource: 'arn:aws:s3:::specific-bucket/*'"]
    
    B --> E[安全風險高]
    D --> F[安全風險低]

實務範例：假設你的應用程式需要讀取 S3 上的設定檔

❌ 錯誤做法：給予 AmazonS3FullAccess

• 可以存取所有 S3 bucket
• 可以刪除任何物件
• 風險：憑證洩漏時影響範圍巨大

✅ 正確做法：建立自定義 Policy

• 只允許 s3:GetObject
• 只能存取特定 bucket 的特定路徑
• 加上 IP 或 VPC 條件限制

---

Root 帳號與安全最佳實踐

Root 帳號的特殊性

AWS Root 帳號（使用 email 登入的帳號）擁有帳號內的所有權限，無法被限制。這是一把雙面刃：

• ✅ 可以執行任何操作
• ❌ 無法透過 IAM Policy 限制
• ❌ 憑證洩漏會導致災難性後果

Root 帳號安全清單

flowchart LR
    A[建立 AWS 帳號] --> B[啟用 Root MFA]
    B --> C[建立 Admin IAM User]
    C --> D[日常使用 IAM User]
    D --> E[Root 帳號僅緊急使用]
    
    style B fill:#ff6b6b
    style E fill:#4ecdc4

必做事項：

1. 啟用 MFA（多因素認證）

   • Root 帳號必須啟用 MFA
   • 建議使用硬體 MFA 或 Authenticator App
   • 保存備用 MFA 恢復碼在安全位置

2. 不要建立 Root Access Key

   • Root 帳號不應該有 Access Key
   • 如果已存在，立即刪除

3. 建立組織帳號結構

   • 使用 AWS Organizations 管理多帳號
   • 開發、測試、生產環境使用不同帳號

4. 設定帳單警報

   • 在 Billing Dashboard 設定預算警報
   • 防止意外產生高額費用

IAM 使用者最佳實踐

對於日常開發工作，應該使用 IAM 使用者而非 Root 帳號：

# 建議的 IAM 群組結構
Groups:
  - Administrators:
      Policy: AdministratorAccess
      Description: 完整管理權限，僅限資深工程師
      
  - Developers:
      Policy: 
        - PowerUserAccess
        - IAMReadOnlyAccess
      Description: 開發所需權限，不能管理 IAM
      
  - ReadOnly:
      Policy: ReadOnlyAccess
      Description: 只讀權限，適合稽核或新進人員
      
  - CICD:
      Policy: CustomCICDPolicy
      Description: CI/CD 系統專用，最小必要權限

---

IAM Role 的進階應用

為什麼 Role 比 User 更適合服務間通訊？

在後端開發中，我們經常需要讓服務存取其他 AWS 資源。例如：

• EC2 執行個體需要讀取 S3 檔案
• Lambda 函數需要寫入 DynamoDB
• ECS 容器需要從 Secrets Manager 取得密鑰

使用 IAM User（不推薦）：

• 需要管理 Access Key
• Key 可能被寫入程式碼或設定檔
• Key 輪換困難
• 安全風險高

使用 IAM Role（推薦）：

• 沒有長期憑證
• AWS 自動輪換臨時憑證
• 透過 Instance Profile 或 Service Role 附加
• 安全性更高

EC2 Instance Profile 實務

sequenceDiagram
    participant App as 應用程式
    participant IMDS as EC2 Metadata Service
    participant STS as AWS STS
    participant S3 as S3 Service
    
    App->>IMDS: 請求臨時憑證
    IMDS->>STS: 取得 Role 憑證
    STS-->>IMDS: 臨時憑證（有效期限 1-6 小時）
    IMDS-->>App: 回傳憑證
    App->>S3: 使用憑證存取 S3
    S3-->>App: 回傳資料

當你的應用程式部署在 EC2 上時，AWS SDK 會自動從 Instance Metadata Service（IMDS）取得憑證，不需要在程式碼中硬編碼任何憑證。

// Go 語言範例：自動使用 Instance Profile 憑證
package main

import (
    "context"
    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/service/s3"
)

func main() {
    // SDK 自動偵測執行環境，使用適當的憑證來源
    cfg, err := config.LoadDefaultConfig(context.TODO(), 
        config.WithRegion("ap-northeast-1"),
    )
    if err != nil {
        panic(err)
    }
    
    // 使用 Instance Profile 的憑證存取 S3
    client := s3.NewFromConfig(cfg)
    // ... 執行 S3 操作
}

跨帳號存取（Cross-Account Access）

在企業環境中，常見的做法是將不同環境（開發、測試、生產）放在不同的 AWS 帳號中。這時就需要設定跨帳號存取。

graph LR
    subgraph "開發帳號 (111111111111)"
        A[Developer User]
    end
    
    subgraph "生產帳號 (222222222222)"
        B[Cross-Account Role]
        C[Production Resources]
    end
    
    A -->|AssumeRole| B
    B -->|存取| C

設定步驟：

1. 在目標帳號建立 Role，信任來源帳號
2. 來源帳號的使用者被授權執行 sts:AssumeRole
3. 使用者呼叫 AssumeRole 取得臨時憑證
4. 使用臨時憑證存取目標帳號資源

---

AWS 成本管理基礎

計費模式概覽

作為後端工程師，理解 AWS 的計費模式可以幫助你設計成本效益更高的架構：

計費模式	說明	適用場景
隨需（On-Demand）	用多少付多少，無預付	開發測試、流量不穩定
預留（Reserved）	1-3 年承諾，最高折扣 72%	穩定的生產工作負載
Spot	使用閒置容量，最高折扣 90%	可中斷的批次處理
Savings Plans	承諾用量，靈活選擇服務	多服務混合使用

成本監控必做事項

1. 設定 Billing Alarm

   • 在 CloudWatch 設定帳單警報
   • 建議設定多個閾值（50%、80%、100%）

2. 啟用 Cost Explorer

   • 分析歷史費用趨勢
   • 識別成本異常

3. 使用標籤（Tags）

   • 為資源加上標籤（專案、環境、負責人）
   • 便於成本分攤和追蹤

4. 定期審查未使用資源

   • 閒置的 EC2、EBS Volume
   • 過時的 Snapshots
   • 不再使用的 Elastic IP

# 建議的標籤策略
Tags:
  - Key: Environment
    Values: [dev, staging, prod]
    
  - Key: Project
    Values: [project-name]
    
  - Key: Owner
    Values: [team-name or email]
    
  - Key: CostCenter
    Values: [department-code]

---

AWS CLI 與 SDK 入門

AWS CLI 設定

AWS CLI 是後端工程師日常必備的工具：

# 安裝 AWS CLI v2 (macOS)
brew install awscli

# 設定憑證
aws configure
# AWS Access Key ID: AKIA...
# AWS Secret Access Key: ****
# Default region name: ap-northeast-1
# Default output format: json

# 驗證設定
aws sts get-caller-identity

多環境設定（Named Profiles）

實務上，我們通常需要存取多個 AWS 帳號：

# ~/.aws/credentials
[default]
aws_access_key_id = AKIA_DEV_KEY
aws_secret_access_key = dev_secret

[production]
aws_access_key_id = AKIA_PROD_KEY
aws_secret_access_key = prod_secret

[staging]
role_arn = arn:aws:iam::123456789012:role/StagingAccess
source_profile = default

# 使用不同 profile
aws s3 ls --profile production

# 或設定環境變數
export AWS_PROFILE=production
aws s3 ls

---

本章重點回顧

本篇文章介紹了 AWS 的核心基礎概念，這些知識是後續深入學習各項服務的基石：

關鍵要點

1. 全球基礎架構

   • Region 是地理區域，AZ 是故障隔離單位
   • 高可用架構必須跨 AZ 部署

2. IAM 核心原則

   • 遵循最小權限原則
   • 優先使用 Role 而非 User
   • 服務間通訊使用 IAM Role

3. 安全最佳實踐

   • Root 帳號啟用 MFA，日常不使用
   • 不要硬編碼 Access Key
   • 使用 Instance Profile 或 Service Role

4. 成本意識

   • 設定帳單警報
   • 善用標籤管理資源
   • 了解不同計費模式

下一篇預告

在系列的第二篇文章中，我們將深入探討 AWS 運算服務：

• EC2 執行個體類型選擇與優化
• Lambda 無伺服器架構設計
• ECS 與 EKS 容器化部署
• 如何選擇適合的運算服務

---

系列文章導覽

• Part 1：入門與核心概念（本篇）
• Part 2：運算服務深度解析（EC2、Lambda、ECS/EKS）
• Part 3：儲存與資料庫服務（S3、RDS、DynamoDB）
• Part 4：網路架構與安全（VPC、ALB、Security Groups）
• Part 5：訊息佇列與事件驅動（SQS、SNS、EventBridge）
• Part 6：DevOps 與 CI/CD（CodePipeline、CDK）
• Part 7：監控與可觀測性（CloudWatch、X-Ray）
• Part 8：進階架構設計（高可用、災難復原、成本優化）

---

參考資源

• AWS Well-Architected Framework
• IAM Best Practices
• AWS Global Infrastructure