AWS帳號代開 如何在 AWS 快速部署 WordPress 網站

第一章：先想清楚「快」與「穩」的平衡

在 AWS 上部署 WordPress，真正的難點通常不是把服務「跑起來」，而是把它跑得「快」且「可持續」。快，代表你能在短時間內看到網站首頁、發表第一篇文章；穩，則代表遭遇流量或故障時，你不會在第二天就開始救火。

所以你可以把整個流程想成四個層次：第一是基礎環境（算力與網路）；第二是資料層（資料庫與持久化）；第三是應用層（WordPress 與基本安全）；第四是運維層（快取、備份、監控）。只要每一層都做對，快速上線就不是運氣，而是方法。

AWS帳號代開 第二章：選擇部署方式：EC2 還是 Lightsail？

AWS 提供多種部署途徑。若你追求「最快看到結果」，Lightsail 往往更省心；若你需要更深度控制、成本優化與可擴充性，EC2 更有空間。兩者都能跑 WordPress，但思路不同。

2.1 Lightsail：用最少決策換最快上線

Lightsail 是相對封裝的方案，通常內建或更容易導入 WordPress 的安裝流程，還有簡化的快照與管理介面。對新手或短期專案，這是速度的優先選擇。

適合情境：你要在幾小時內完成上線；團隊希望少花時間在伺服器細節；網站規模在初期不會極端放大。

2.2 EC2：可控、可優化，但需要你掌握更多

EC2 是更通用的計算服務。你需要自己選擇 AMI、配置安全群組、建立與連接資料庫（可使用 RDS 或在同機器部署）。它需要更多步驟，但換來的是你對架構、成本與擴充策略的掌控。

適合情境：你要長期運營、預計流量會增長；希望使用 RDS、Auto Scaling、Elastic Load Balancing 等更完整的組合；或你已熟悉 Linux 與雲端資源。

第三章：快速部署的共同核心流程（不管你用哪種）

不管採用 Lightsail 或 EC2，你都需要處理同樣的核心要素：網路可達性、安全與權限、資料持久化、WordPress 設定、以及讓使用者感受到速度的基本加速策略。

3.1 網路與安全群組：別只想著「能連上」

很多部署失敗不是因為 WordPress，而是因為端口沒有放行。至少你要確保 Web 入口端口可用：

• HTTP：80
• HTTPS：443
• 若需要管理：SSH（通常是 22，但建議限制來源 IP，或改用更安全的方式）

建議做法是「最小權限」：只對必要 IP 開放 SSH；對外只開 80/443；其餘端口保持關閉。你越早養成這種習慣，後面越省時間。

3.2 資料庫與持久化：WordPress 的靈魂在這裡

WordPress 依賴資料庫保存文章、頁面、使用者與設定。若你把資料庫放在同一台 EC2/VM 上，當你遇到重建或升級失敗時，資料可能受到影響。因此：

• 若使用 EC2，建議把資料庫交給 RDS（更穩定且具備備援機制）。
• 若使用 Lightsail，可以用其內建的資料庫/快照能力，但仍要養成備份習慣。

你可以先快上線，但不要把「資料可恢復性」延後。

3.3 基本加速：快取與靜態資源的順序很重要

WordPress 初期速度常常卡在 PHP 計算與資料庫查詢。最有效的手段通常是：

• 安裝快取外掛（例如針對快取與靜態資源的方案）。
• 加上反向代理或邊緣快取（若你後續使用 CloudFront）。
• 啟用 GZIP/Brotli（由 Web server 或設定處理）。

注意：快取外掛通常能立刻帶來改善，但也可能讓網站更新延遲。你要確保有「清除快取」的流程。

AWS帳號代開 第四章：以 Lightsail 為例：一步一步快速上線（可在當天完成）

以下流程以「盡快看到網站」為目的。你依然要留意安全與備份，否則快是快，但容易留下後患。

4.1 建立運算實例與開放必要端口

AWS帳號代開 在 Lightsail 控制台中建立新 instance（選擇適合的規格）。安裝時通常會提供 Linux 環境。完成後：

• 設定防火牆/網路規則，開放 80 與 443。
• SSH 只允許你的 IP（能做就做）。

4.2 安裝 WordPress

Lightsail 常見做法是使用預設映像或一鍵式安裝腳本。安裝時會要求你設定：

• AWS帳號代開 網站目錄或安裝位置（通常是預設 /var/www/html 或類似路徑）。
• WordPress 站點 URL。
• 管理員帳號與密碼。

如果系統會要求資料庫設定，請用自動生成或自行記錄資料庫名稱、使用者與密碼。

4.3 設定外部網域與 HTTPS

你可以先用 IP 或系統給的預覽連結確認 WordPress 正常，再上網域。

若你已經有網域，接下來是：

• 在 DNS 設定 A 記錄或 CNAME 指到你的 Lightsail 公網 IP。
• AWS帳號代開 啟用 HTTPS（可使用內建的憑證工具或 Certbot 類工具）。
• 將 HTTP 重新導向 HTTPS。

完成後，瀏覽器打開你的網域應該會顯示有效的憑證與安全鎖圖示。

4.4 立即做三件事：外掛、時區與日誌

上線前不要只管首頁是否顯示。至少做三項基本檢查：

• 確認 WordPress 時區與語言設定符合你的使用者群。
• 安裝快取外掛與基本安全外掛（含 WAF/封鎖惡意掃描的能力，依你的外掛選擇而定）。
• AWS帳號代開 啟用錯誤日誌或確認系統日志可以查看，方便你在出問題時快速定位。

你會驚訝於「日誌」能省多少時間。很多錯誤不是發生在部署時，而是部署後第一個月才冒出來。

第五章：以 EC2 為例：更完整的架構與更可控的部署

如果你選擇 EC2，建議你用「可重建」的思維。你今天部署成功，不代表明天也能順利升級；只有把架構做得合理，重建才有意義。

5.1 建立 EC2 與網路規則

先建立 EC2 instance（選擇穩定的 Linux 發行版）。然後：

• 建立安全群組：開放 80/443 給全網；SSH 限制你的 IP。
• 若未來要放在 CloudFront 或負載平衡後，可考慮保留適合的架構彈性。

AWS帳號代開 一個好的安全群組是你成本控制的一部分：因為你減少受到惡意流量攻擊的機率，就會降低維運壓力與封鎖成本。

5.2 資料庫建議使用 RDS

WordPress 常用 MySQL 或 MariaDB。RDS 能提供自動備份、維護窗口與較穩定的資料服務。

你需要配置：

• 資料庫實例類型與儲存。
• 資料庫使用者（WordPress 專用）。
• 網路連線（通常用 VPC 與安全群組讓 EC2 能連到 RDS）。

設定完成後，記錄連線資訊：主機名稱、資料庫名、使用者、密碼、端口。

AWS帳號代開 5.3 安裝 Web server 與 PHP 依賴

部署 WordPress 需要 PHP 與 Web server（常見為 Nginx 或 Apache）。你要確保：

• PHP 版本符合 WordPress 支援範圍。
• 必要的 PHP 擴充模組已安裝（依你使用的版本與外掛需求可能不同）。
• Web server 設定正確指向網站目錄。

第一次安裝時，請把目標放在「可用」。等上線後再針對性能做調整，避免一開始就把系統調太複雜。

5.4 安裝 WordPress 並完成資料庫連線

上傳 WordPress 檔案到網站目錄後，透過瀏覽器進入安裝程序。填入資料庫資料：

• 資料庫主機（RDS 的端點）。
• 資料庫名稱、使用者與密碼。
• 管理員帳號、站點標題、email。

安裝成功後，立即檢查：

• 媒體上傳是否正常（例如上傳一張測試圖片）。
• 固定連結（Permalinks）是否可設定且不報錯。
• 外掛安裝是否正常。

5.5 設定 HTTPS：把導向與憑證流程做乾淨

HTTPS 的落地通常包含三件事：取得憑證、配置 Web server、以及確保自動續期。

你可以用 ACME/Certbot 或其他方式取得憑證。完成後必做：

• 將 HTTP 轉到 HTTPS。
• 檢查憑證是否對應正確網域。
• 確認重導向不造成迴圈。

這一步做得好，後面外掛與安全設定才不容易出現奇怪的混合內容問題。

第六章：域名、DNS 與路由的現實問題

很多人卡在這裡，不是 AWS 不行，而是 DNS 的行為本身需要耐心。DNS 更新通常需要時間生效，短則數分鐘，長則可能要到幾小時，甚至更久。

6.1 常見 DNS 設定：A 記錄 vs CNAME

如果你的目的地是固定 IP，A 記錄通常最直觀。若目的地是某個主機名（例如 ALB 或某些雲服務端點），則可能用 CNAME。

在 WordPress 部署後你需要確認：

• 網站網域解析到正確的公網入口。
• www 與非 www 的處理方式一致（要嘛都指向同一目標，要嘛做重導向）。
• 若使用 CloudFront 或負載平衡，DNS 目標要對應對的資源。

6.2 反向代理與 WordPress 的網址一致性

若你日後把流量放到反向代理（例如 Nginx/ALB/CloudFront）上，WordPress 的「站點網址」與實際請求的 URL 可能不一致，導致重導向或連結錯誤。

你要確保 WordPress 的 siteurl 與 home 設定一致，並正確處理 X-Forwarded-Proto 等標頭。這類問題表面是「網址不對」，本質是「架構層的資訊沒有傳給應用」。

第七章：讓網站更快——快取、壓縮與資源策略

部署完成只是起點。WordPress 的速度提升，多半是「架構與設定」的累積，不是單一外掛就能解決。

AWS帳號代開 7.1 站點快取與清除機制

快取外掛通常提供頁面快取、物件快取與瀏覽器快取控制。你要關注兩件事：

• 清除快取：發文、更新頁面後能否立即生效。
• AWS帳號代開 排除規則：登入後、購物流程（若有）不被快取。

如果你沒有設定這些排除，可能出現「更新了但用戶看到舊內容」或「登入後仍被導向快取頁」。這是典型的快取踩雷。

7.2 靜態資源：圖片與字型的策略

AWS帳號代開 WordPress 內容多半以圖片為主。想讓體驗更快，你要做：

• 圖片壓縮：上傳前或透過外掛做壓縮。
• 延遲載入：減少首屏資源。
• 必要時用 CDN：把靜態檔案交給更接近使用者的邊緣節點。

AWS帳號代開 如果你使用 CloudFront，可以讓圖片、CSS、JS 更快送達。當流量開始增加時，CDN 的效益會非常明顯。

7.3 資料庫層：定期維護

WordPress 的資料庫會累積修訂版本、垃圾留言與暫存數據。建議你：

• 定期清理修訂（可在外掛或設定中調整）。
• 清理暫存（配合快取外掛）。
• 監控資料庫連線與慢查詢（有條件再做深入）。

這些工作可能不像「安裝外掛」那麼立刻有感，但它們會降低日後性能惡化的速度。

第八章：備份、還原與災難預案（真正的上線感）

你希望的是可用、而不是只要能開機就算完成。備份是上線後最重要的能力之一，因為你很難保證不會遇到：誤刪、外掛更新失敗、勒索程式、磁碟故障或人為錯誤。

8.1 建立備份策略：資料庫與檔案要分開看

WordPress 至少有兩塊需要備份：

• 資料庫：內容、設定、使用者。
• 網站檔案：主題、外掛、上傳的媒體（如果媒體不在物件儲存）。

如果使用 RDS，通常可利用快照與自動備份；檔案則可透過快照、檔案同步或系統層備份完成。

8.2 不只備份，還要測試還原

很多團隊備份了，但沒有測試還原流程。建議你每隔一段時間就做一次演練：選一份備份，建立一個新的環境並確認網站能正常恢復。

測試的價值在於你會發現隱性問題，例如：

• 資料庫版本不相容。
• 檔案路徑在還原後不一致。
• 環境變數或外掛配置缺失。

8.3 監控：讓你在問題擴大前看見

監控不是複雜工具堆砌。對 WordPress 來說，你至少要能看到：

• CPU、記憶體、磁碟使用率是否異常。
• Web server 的錯誤率（例如 404/500）。
• 資料庫連線數與延遲。

如果你能設置警報，網站在流量突增或故障時，你能更早介入。

第九章：安全清單：讓 WordPress 少踩幾次坑

WordPress 因為普及，很容易成為自動化攻擊的目標。安全不是「上線就完事」，而是一套持續的習慣。

9.1 更新策略：核心、主題、外掛分開看

WordPress 核心、主題與外掛需要保持更新。但更新也要有流程，避免因單一外掛更新造成站點故障。

建議：

• 對重要外掛先在測試環境驗證。
• 更新後立刻檢查登入、發文、圖片上傳。
• 建立變更紀錄：你更新了什麼、什麼時間更新。

9.2 使用強密碼與限制登入嘗試

基本但常被忽略。WordPress 管理員帳號不要使用公開常見的 admin。密碼採用長且複雜的字串，並搭配登入限制（例如限制重試次數、封鎖可疑來源）。

若你把 SSH 暴露在網際網路上，請限制來源 IP 或改用更安全的方式。

9.3 檔案權限與目錄隔離

錯誤的權限設定可能導致檔案被惡意修改。你需要確保 WordPress 所需的目錄才有寫入權限，其他位置保持只讀或限制。

此外，上傳媒體的目錄、外掛與主題檔案的位置要一致且受控，避免不必要的可執行權限。

第十章：成本與擴充：你要知道什麼時候該升級

部署「快」不代表永遠便宜。你需要有一個大概的判斷框架：網站何時需要升級算力、何時需要資料庫調整、何時需要 CDN 或負載平衡。

10.1 成本主要來自什麼

常見成本來源包括：

• EC2/Lightsail 的計算費用。
• 資料庫（若使用 RDS）費用。
• 資料傳輸與 CDN（若使用 CloudFront）。
• 快照備份與儲存增長。

10.2 擴充的路徑：先快，再穩，最後分離

最實際的升級順序通常是：

• 先做快取，減少不必要的計算。
• 觀察資料庫瓶頸，再考慮升級 RDS 規格或調整參數。
• 若流量持續增長，再導入負載平衡與多台 Web（搭配內容分發）。

WordPress 的擴充有很多路徑，但最重要的是不要一次把所有機制都堆上去。你先用監控找到瓶頸，再決定下一步。

第十一章：常見問題與排錯思路（讓你少走彎路）

再完整的流程也可能遇到問題。與其盲目重裝，不如用排錯思路快速定位。

11.1 網站打不開：先查端口與安全群組

如果你能連上 SSH 卻無法開啟網站，通常與以下因素相關：

• 安全群組沒有開放 80/443。
• Web server 沒有啟動或服務綁定錯誤。
• 網域 DNS 還沒生效。

先把基礎可達性釐清，後面才有意義查 WordPress。

11.2 500 錯誤：通常是 PHP 或外掛衝突

500 錯誤常見原因是：

• PHP 設定與外掛需求不相符。
• 外掛衝突或配置錯誤。
• 記憶體不足或權限不足。

你可以先停用可疑外掛、檢查 Web server 與 PHP 日誌，再決定是否回滾。

11.3 登入後卡住或重導向失敗：多半是 URL 不一致

如果遇到登入後一直跳回登入頁，或者 HTTPS/HTTP 互相跳轉，通常與：

• WordPress home 與 siteurl 不一致。
• 反向代理標頭未正確處理。
• 憑證或重導向設定造成迴圈。

你要先確認瀏覽器網址與伺服器收到的協定是不是一致。

第十二章：給你的落地清單（照著做就能跑起來）

下面給一份你可以直接照做的最小落地清單。你可以把它當作自我檢查表。

12.1 部署前

• 確認目標：快速上線還是長期運營。
• 選擇方案：Lightsail（省事）或 EC2（可控）。
• 準備網域（如果要上線到自有網域）。

12.2 部署中

• 開放必要端口：80/443，SSH 僅限來源 IP。
• 配置資料庫連線（建議 EC2 + RDS）。
• 安裝 WordPress 並完成初始設定。
• 確保媒體上傳與固定連結正常。

12.3 部署後（第一天要完成）

• 啟用 HTTPS 並檢查重導向。
• 安裝快取與安全相關外掛（合理設定清除機制）。
• 檢查日誌可用，並確認錯誤能追蹤。
• 建立備份（資料庫快照與檔案備份）並至少測一次還原流程。
• 設置基本監控與警報。

結語：真正的速度來自可重複的流程

在 AWS 快速部署 WordPress 的關鍵，不是把每一步都做到極致，而是用一套可以重複、可以檢查、可以回退的流程。當你能快速上線、同時能在出問題時迅速定位與恢復，你的「快」就會變成長期優勢。

如果你正在準備開始，建議你先用 Lightsail 把網站跑起來驗證需求；等內容與方向確定，再用 EC2 + RDS 做更穩定的架構。這種路線通常比一開始就追求完美更有效率。等你習慣了基本部署，你會發現 AWS 的彈性不是限制，而是讓你把網站從「能用」推到「好用」的工具。