AWS企業帳號代辦 AWS 亞馬遜雲國際站 EC2 實例詳解

前言：EC2 不是把電腦搬進機房而已

如果你第一次聽到「AWS EC2」，可能直覺會想：不就租一台雲端主機嗎？答案部分對，但也只是對一半。EC2（Elastic Compute Cloud）更像是「可彈性伸縮的虛擬運算工廠」。你可以在上面跑網站、API、資料庫（或把資料庫交給更專業的服務）、做批次運算、測試環境，甚至把整套系統像樂高一樣組起來。

而且最有趣的是：EC2 能讓你像炒菜一樣隨時加火候——需要更快就升級規格，需要省錢就降級規格。你以為你在管理伺服器，其實你在管理「資源的表情包」。今天你的主機很兇，明天它就可以溫柔一點。

本文用「實例詳解」的方式，帶你把常見操作流程完整走一遍：從挑實例、設定網路與安全群組、準備金鑰，直到部署一個可用的服務，最後再處理常見錯誤與最佳實務。希望讀完你不只會按按鈕，還能知道每一步為什麼這樣做。

EC2 是什麼？你到底在租什麼

EC2 的核心是「實例（Instance）」。你在 AWS 控制台建立一個實例後，AWS 會在指定的硬體資源池上幫你配置虛擬機。你會得到：

• 一個或多個 CPU/記憶體配額（由實例型別決定）
• 可配置的儲存（例如 EBS 磁碟）
• 網路介面（在 VPC 裡分配 IP、路由與防火牆規則）
• AWS企業帳號代辦 用金鑰（Key Pair）或其他方式登入

簡單講：你是在租一台「可以隨時調整規格與擴縮」的運算容器，而不是在租一台固定的鋁罐主機。

實例型別選擇：別讓你的主機跟你的需求吵架

選實例型別最怕什麼？最怕你一時手滑把「超大」租來，最後只跑單人小網站；或反過來租「超小」，結果網站高峰直接卡成慢動作。

AWS 常見實例族群大致可分幾類（具體依地區與供給略有差異）：

通用型（General Purpose）

AWS企業帳號代辦 適合多數中小型網站、應用服務、輕量級資料處理。若你沒有非常明確的資源瓶頸，通用型通常是起手式。

計算最佳化（Compute Optimized）

CPU 密集型，例如高頻交易處理、批次運算。看你的程式是否「在算」而不是「在等」。

需要更多記憶體，例如資料庫、快取、記憶體型應用。若你的應用老是在抱怨 OOM（Out of Memory），可能要往這類方向調整。

儲存最佳化（Storage Optimized）

若你的工作負載常常大量讀寫磁碟，這類會更合適。

實務建議：先用通用型或你預期的最小可行規格起跑，然後透過 CloudWatch 看 CPU/記憶體/網路/磁碟的趨勢，再逐步調整。

部署實例的前置準備：你需要知道的「角色分工」

在開始跑 EC2 之前，通常會遇到幾個概念：VPC、子網路（Subnet）、安全群組（Security Group）、網際網路閘道（IGW，若需要）、路由表、金鑰（Key Pair）。

你可以把它們想成：

• VPC：你的私人小宇宙（網路邊界）
• 子網路：小宇宙裡的街區
• 安全群組：門牌與警衛規則（入站/出站）
• 金鑰：登入用的通行證
• 路由：交通指引（封包要怎麼出去）

接下來我們做一個「可上線的 EC2 範例」，把各個部件串起來。

實例範例：建立一台可 SSH 登入並部署網站的 EC2

以下以一台簡單服務為例：在 EC2 上跑一個 Web 伺服器（例如 Nginx），讓你能使用瀏覽器看到頁面。你不需要一開始就做複雜架構，先把「能通」建立起來。

步驟 1：選擇 AMI（映像檔）與作業系統

AMI 是「作業系統 + 可能的預裝元件」的模板。常見選擇是 Ubuntu、Amazon Linux、或其他 Linux 發行版。

實務小提醒：

• 若你要教學/快速上手，Ubuntu 或 Amazon Linux 通常比較省事。
• 若你有團隊既定標準，選與團隊一致的 AMI。
• 確認版本（例如 Ubuntu 22.04 vs 24.04），避免後面更新策略不同導致踩坑。

步驟 2：選擇實例型別

以入門範例，你可以選通用型中較小的規格（例如 t 系列）。如果只是跑 Nginx 或輕量 API，這通常足夠。

先把重點放在流程，而不是硬體規格。你要的不是「最強」，你要的是「先能跑」。

步驟 3：建立或選擇 VPC 與子網路

如果你是第一次使用，AWS 通常會提供預設 VPC 或你能建立新 VPC。子網路選擇要注意：你的 EC2 若需要從網際網路直接訪問（例如 SSH 或 Web），通常會放在能路由到 IGW 的公有子網路（Public Subnet）。

如果你不知道該選什麼，就先選「公有子網路 + 有公網 IP」的設定，讓你快速把流程跑通。

步驟 4：安全群組（Security Group）怎麼設

安全群組是最常讓新手抓狂的地方，原因不是規則複雜，而是大家常常把「暫時先開放」當作「永遠不會忘記」。然後一年後你回來看，發現 0.0.0.0/0 開了 SSH，心情就像在看一年前自己寫的密碼備忘錄。

針對這個範例，通常需要：

• 入站：
  • SSH（通常是 22）來源可以先限制成你的 IP（例如你家網路或公司固定 IP），若沒有固定 IP，至少確保你理解風險。
  • HTTP（80）與/或 HTTPS（443）讓公網可訪問 Web。
• 出站：一般允許所有出站（0.0.0.0/0），讓系統能更新套件與連外。

如果你的目的只是測試，開放 HTTP 沒問題；但 SSH 盡量不要全網公開。你可以犯錯，但別犯太大。

步驟 5：金鑰對（Key Pair）與登入

你需要選擇一個 Key Pair。若你還沒有：

• 在 AWS 控制台建立新金鑰對
• 下載私鑰檔（例如 .pem）
• 妥善保管，不要上傳到 Git，尤其不要把它丟到公共資料夾

登入方式（以 Linux/macOS 為例的概念）通常是：

• 確保私鑰檔權限正確
• 用 SSH 指令連到 EC2 的公網 IP 或 Elastic IP

Windows 使用者則常用 PuTTY 或 WSL/PowerShell 對應方式。

AWS企業帳號代辦 步驟 6：啟動 EC2 並取得 Public IP

建立完成後，你會在實例詳細資訊裡看到公網 IP（若選了公有網路與自動分配公網 IP）。

當狀態顯示「running」，你就可以嘗試 SSH 登入。

步驟 7：在 EC2 安裝 Web 服務並啟動

登入後，你可以：

• 更新套件索引
• 安裝 Nginx（或你偏好的 Web 伺服器）
• 啟動服務並設定開機自啟
• 修改預設頁面，輸出一些資訊驗證部署成功

若你想快速驗證：

• 把頁面內容改成顯示「EC2 上線成功」與版本號
• 用瀏覽器打開公網 IP，看是否能看到頁面

當你看到頁面時，你會有一種很真實的成就感：原來雲端並不是遙不可及的概念，它就是一台真正會回應你要求的機器。

Elastic IP、DNS 與「不想每次都換網址」的解法

很多人剛開始會忽略一件事：如果你停止或重啟某些配置，公網 IP 可能會變。你可能會遇到這種情境：

「欸我剛剛還能打開，怎麼現在不行了？」——你的網址可能跟著變了。這時候 Elastic IP 就登場了。

AWS企業帳號代辦 Elastic IP 是什麼

Elastic IP 允許你保留一個公網 IP 與帳號/資源綁定。你可以在某些情況下把 IP 從一台實例重新綁到另一台實例，讓切換變得更平滑。

DNS 與網域指向

如果你有網域，可以用 Route 53（或其他 DNS 服務）將網域指向 Elastic IP。這樣你即使替換 EC2 實例，網域仍維持可用。

用一句話總結：不要讓你們的 URL 隨便改變，除非你們專門做流量驚喜包。

儲存設定：EBS 不只是磁碟，它是你的資料家

EC2 的儲存通常分為兩種概念：根磁碟（Root Volume，作業系統所在）與資料磁碟（Data Volume）。常見是使用 EBS。

你需要考慮：

• 容量：夠不夠未來擴張
• 磁碟類型：例如 gp3（通用型）、io1/io2（高 IOPS）等
• 是否需要快照備份
• 是否要跨區復原（進階）

如果你只是跑簡單網站，磁碟大小不用太誇張；但如果你要跑資料庫或大量 log，磁碟就會成為「你的系統是否會突然爆炸」的關鍵因素之一。

成本概念：你要算的是「運行時間 + 資源用量」

EC2 成本通常跟以下幾項有關：

• 實例運行的時數（On-demand 或其他方案）
• EBS 磁碟容量與 IOPS/效能
• 資料傳輸（特別是出到網際網路的部分）
• Elastic IP（若未綁定使用，可能會有額外費用，需注意）

建議你：

• 在建立實例時確認預估費用
• 用 Cost Explorer 或 Billing Dashboard 監控
• 測試完成後停止不必要的實例

很多人第一次用 AWS 看到帳單驚嚇，不是因為 AWS 貪婪，而是因為他們忘記「關機」這件事。雲端最會的不是搶劫，是「不提醒你還在繳租」。

部署進階：用 User Data 自動化初始化

手動登入安裝 Nginx 沒問題，但如果你要快速建立多台環境（例如 staging、production 或多個區域），你會想要自動化。

這時候你可以使用 EC2 的 User Data。

User Data 可以做什麼

• 安裝套件
• 初始化設定（例如把環境變數寫進設定檔）
• 啟動服務
• 拉取程式碼並部署（簡單情境）

好處是：你建立實例時就讓它「自己長出牙齒與肌肉」，不需要你再手動操作。

範例思路：建立後自動安裝 Nginx

流程概念如下：

1. 在建立 EC2 的頁面找到 User Data
2. 填入腳本（適用於你的 OS）
3. 啟動實例
4. 過一段時間後用瀏覽器或 curl 驗證頁面

這會讓你從「按鈕運維」升級成「可重現部署」。你會明顯感覺，自己的效率從 1 倍進到 3 倍甚至 5 倍（視你是否愛手動而定）。

監控與告警：別等網站當機才知道

EC2 最容易出事的時候，往往不是你剛開始設定的時候，而是「上線之後、流量上來、你忘了看監控」。

AWS 內建 CloudWatch 可監控 CPU、網路、磁碟使用量等。你可以：

• 設定 CPU 使用率超過某阈值就告警
• 磁碟使用率接近滿載就告警
• 服務不可用（透過簡單健康檢查或搭配負載平衡器）時告警

如果你要更成熟，可以再加上負載平衡器（ELB）與 Auto Scaling，讓流量來了你也不會手忙腳亂。

常見錯誤排除：遇到問題先別慌，先看這些

EC2 常見問題其實很多都很「重複」，你只要掌握排查順序，就能節省大量時間。

問題 1：SSH 連不上（超常見）

可能原因：

• 安全群組沒開 22
• 安全群組來源 IP 不對
• 實例沒有公網 IP 或你連錯地址
• 金鑰對不匹配或私鑰權限不正確

排查順序建議：

1. 確認 EC2 是否 running
2. 確認是否能看到公網 IP
3. 檢查安全群組入站規則
4. 確認你使用的 Key Pair 是否正確
5. 登入後檢查 SSH 服務狀態（若可登入）

如果你已經做完以上仍失敗，那也許你需要檢查你到底是連「哪台」——雲端實例多了之後，最容易犯的錯是：你正在連你以為的那台，但其實連到另一台。

問題 2：Web 打得開卻顯示 502/504

可能原因：

• Web 服務沒有啟動或端口未開
• 安全群組沒開 80/443
• 服務綁錯網卡或綁到 localhost
• 應用程式本身掛掉（錯誤碼、依賴服務未啟動）

排查建議：

• 用瀏覽器看錯誤碼
• SSH 登入確認服務狀態
• 檢查 Nginx/APP 的 log
• 確認防火牆（若有在 OS 層啟用）

AWS企業帳號代辦 問題 3：費用突然變高

最常見是：

• 實例忘記停（仍在計費）
• 磁碟擴張了或快照太多
• 資料傳輸量增加
• Elastic IP 沒有正確使用（若不綁定可能有額外費用）

解法：

• 進 Billing 檢視主要費用項目
• 對照時間點（最近是否做了大規模測試）
• 設定警報避免「月底才驚覺」

最佳實務：把 EC2 做得像成熟工程，而不是像一次性攤販

接下來這段不是要你背誦條文，而是告訴你「哪些習慣能讓你少踩坑」。

1）使用最小權限原則設定安全群組

能限制來源 IP 就限制來源 IP。能只開必要端口就不要全部放行。安全群組不是開心就好，它是你未來的風險。

2）不要把敏感資訊寫死在腳本或映像檔

API Key、密碼、憑證等要用環境變數或 AWS 服務（例如 Secrets Manager / SSM Parameter Store）管理。

3）用自動化取代手動

User Data、或更進階的 IaC（Infrastructure as Code）工具（例如 Terraform / CloudFormation）可以讓環境重現。你會驚訝自己有多討厭手動。

4）設定備份與快照策略

EBS 可以做快照。若你跑了重要資料，請規劃快照頻率與保留時間。

AWS企業帳號代辦 5）監控與告警要先做起來

不要等到網站掛了才開始看 CPU。告警不是要你焦慮，是要你提早行動。

一個更像真實世界的版本：把網站拆成「資料與服務」

上面範例是單台 EC2 跑 Nginx。現實常常要更完整：資料可能需要保存、服務可能需要部署更新、甚至要處理多台。

一個常見的做法：

• EC2 跑 Web/API
• 資料用托管型服務（例如 RDS、DynamoDB）
• 靜態檔案用 S3
• 用 CloudFront 加速（需要時）

AWS企業帳號代辦 這樣 EC2 的責任更清晰：專注在計算與服務，不要讓它變成「什麼都自己來」的全能選手。

擴縮與高可用：什麼時候該升級到 Auto Scaling

當你發現單台 EC2 開著跑沒問題，但流量增加或部署需求上升，你就會遇到：

• 部署時需要停機？（或至少要降低影響）
• 流量高峰時 CPU 被打爆
• 單點故障（某台掛了整站受影響）

這時候通常導入負載平衡器與 Auto Scaling。Auto Scaling Groups 可根據負載自動增加/減少實例數量。

你不用立刻把世界變成 Kubernetes 對吧？先把負載平衡與基本擴縮做起來，節奏更健康。

部署清單：把 EC2 流程變成可重用的 checklist

最後給你一份「建立 EC2 並上線」的清單（像廚房出餐單一樣）。你可以每次照著做，成功率會高很多。

• AWS企業帳號代辦 確定目標：要跑網站？API？測試？批次運算？
• 選擇 AMI：對應 OS 與團隊習慣
• 選擇實例型別：先用可行規格起跑
• 設定 VPC/子網路：需要公網就選公有子網並規劃路由
• 設定安全群組：僅開必要端口，SSH 盡量限制來源
• 建立金鑰對：妥善保管私鑰
• 配置 EBS：容量與類型，必要時規劃快照
• 使用 User Data：自動安裝與啟動服務
• 部署後驗證：SSH、HTTP/HTTPS、log 是否正常
• 設定監控告警：CPU、磁碟、服務狀態
• 成本控管：確認計費項目，測試後停止不必要資源

結語：你已經不只是「能開機」，而是「能交付」

AWS EC2 的學習曲線確實有，但只要把流程拆開，你就會發現它並沒有你想像中的那麼神祕。你需要的不是魔法咒語，而是：

• 正確的選型
• 清楚的網路與安全設定
• 能自動化的初始化流程
• 有監控告警的日常運維

下次當你又聽到「EC2 不是用來跑東西的嗎？」你可以微笑著回答：「是的，它是用來跑東西的；而且我還能讓它跑得很有邏輯。」

如果你願意，你也可以把本文範例延伸到更完整的情境：例如上傳網站程式到 EC2、連接資料庫、設定環境變數、做滾動部署，甚至把整套改成 IaC 管理。從一台可用的 EC2 開始，你會一步一步把雲端技能變成真正可交付的能力。