AWS帳號認證辦理 AWS亞馬遜雲實名賬號遷移指南

前言：遷移不是搬家，是搬家還要把電都接好

你以為「AWS 亞馬遜雲實名賬號遷移」只是把帳號資訊改一改？醒醒，這種事比較像：你要把家搬到新地址，順便把水電瓦斯、網路路由、門鎖權限、快遞投遞規則、以及家裡所有貴重物品（服務資源）也一起搬過去。搬完還得確認：門能不能開、燈會不會亮、系統是不是又在半夜報警。

本文用相對務實的方式，把遷移思路拆成可執行的步驟。你不一定每一步都要做，但你會知道「該做什麼、為什麼、以及最常見的踩坑點在哪」。若你是第一次做，建議直接把本指南當作遷移計畫書骨架；若你已經做過一次，本文也能幫你檢查漏網之魚。

什麼是「實名賬號遷移」？先釐清你在遷移什麼

很多人卡在第一句話：我到底要遷移的是「實名」還是「帳號」？在 AWS 的世界裡，實名通常牽涉到帳號持有者/付款相關資訊、稅務或合規資訊、聯絡資訊等；而「遷移」往往意味著從一個 AWS 賬號（Account）遷移到另一個 AWS 賬號，或至少完成帳號層級的資料更新。

實務上常見有三種情況：

• 情況 A：更換 AWS 主帳號（例如從舊帳號轉到新帳號，因為實名/付款/合規需要調整）。這才是最典型、也最容易踩坑的「遷移」。
• 情況 B：保留帳號，只更新實名/聯絡/付款資訊。若只是資料變更，難度通常較低，但仍要小心信用卡/付款方式與稅務資訊生效時間。
• 情況 C：組織/多帳號結構調整。例如原本在 Organizations 下，因為公司治理或合規要求要調整管理帳號或成員帳號。

在開始操作前，你先寫一句話定義目標，避免中途才發現方向跑偏：

「我們是要把工作負載（EC2、S3、RDS…）從舊 Account 遷到新 Account，並且把權限、網路、帳單與監控全部接續。」

若你的目標不是這句，那就需要調整策略。

AWS帳號認證辦理 遷移前必做：盤點清單，別等事故發生才想起來

遷移最怕什麼？最怕你以為自己只用了一個服務，結果其實你用了一整座城市。下面這份盤點清單，建議用表格整理，越具體越好。

1）資源盤點：你到底有什麼在跑

列出舊帳號中所有與「可用性」強相關的資源類型。至少包括：

• 計算：EC2、Auto Scaling、Lambda、ECS/EKS（如果有）
• 儲存：S3、EBS、EFS
• 資料庫：RDS/Aurora/DynamoDB/ElastiCache
• 網路：VPC、子網、路由表、NAT、VPN/Direct Connect、Security Group、NACL
• 負載均衡：ALB/NLB/CloudFront
• 安全與身份：IAM 角色/使用者/策略、KMS、Secrets Manager、SSM Parameter Store
• 監控與告警：CloudWatch、CloudTrail、SNS、事件規則
• 事件與自動化：EventBridge、Step Functions、各種 Lambda 觸發器
• AWS帳號認證辦理 基礎設施：ACM 證書、Route 53、憑證、授權 token

盤點的方法不用很花俏：AWS 資源標籤（Tag）、Billing/Cost Explorer、CloudTrail 事件、以及你團隊的建置文檔。把「資源清單」先出來，後面遷移才不會像尋寶：找到地圖後才發現缺了指南針。

2）依賴盤點：什麼東西依賴你

資源是你家裡的家具；依賴是「這家具是怎麼連到電視、又怎麼接上網路」。常見依賴：

• 外部服務依賴：第三方回呼、API Gateway、Webhooks
• 內部服務互通：跨服務 IAM 授權、跨帳號角色信任
• 跨帳號存取：共享 S3、跨帳號 KMS、跨帳號 IAM Role assume
• 網域依賴：DNS 指向、ACM 證書所在區域與帳號綁定

尤其是跨帳號權限，遷移最容易出現「功能還在但不能用」的狀況。例如你搬了資料到新帳號，但 IAM trust relationship 還停留在舊帳號，那就會出現 403 或權限失效。

3）合規盤點：實名資訊與付款資訊的敏感度

如果你是因為實名合規遷移（例如主帳號持有人、付款帳單資訊、稅務身份變更），建議提前判斷：

• 新帳號是否已完成實名/付款設定
• 付款方式生效時間（是否需要驗證或等待）
• 是否涉及稅務資訊（VAT/公司統一稅號等）
• 舊帳號何時需要保留（例如帳單截止日）

務實建議：先做一個「生效窗口」時間表。你不希望在遷移當天才發現付款審核卡住，然後雲服務自動停擺。雲不會抱怨，但它會讓你抱怨人生。

遷移策略選型：直遷、並行、或分批？選錯會延長工期

你可以選擇不同遷移策略。以下提供三種常見路線：

策略 1：並行遷移（推薦給大多數團隊）

在新帳號建立同等環境，把資料與配置同步/複製過去，測試通過後再切換流量。優點是風險低，缺點是初期成本（需要同時跑兩套環境）。

適合：有線上服務、不能輕易停機的情況。

策略 2：分批遷移

先遷移不影響核心流程的資源（例如監控、基礎存儲），再遷移主服務，最後切換最關鍵的網路與權限。

適合：資源很多、團隊同時參與、希望逐步降低不確定性。

策略 3：直遷（不太推薦，除非你很確定）

直接把主要資源改成指向新帳號或直接搬移。優點是省事，缺點是排錯困難，因為你把「搬家」與「驗證」壓在同一個時刻。

適合：非關鍵系統、或你有很強的回滾機制。

帳號層級要點：主帳號、成員帳號、Organizations 別弄混

許多遷移失敗，不是服務搬不過去，而是帳號結構搞亂。

1）如果你用 AWS Organizations

你需要確認：

• 管理帳號（Management Account）是否變更
• 新帳號是否要加入 Organizations
• AWS帳號認證辦理 Service Control Policies（SCP）是否會影響新帳號行為
• 帳號層級與根層級的策略是否一致

SCP 會像公司規章：你就算準備了一套「合法的操作」，但如果 SCP 不允許，你照樣不能做。遷移前後都要檢查。

2）IAM 身份與權限的核心問題：trust relationship

跨帳號 assume role 常見場景是「新帳號要能讀舊帳號的資源」或相反。你要把以下內容逐一映射：

• 角色 ARN（Amazon Resource Name）在新帳號會不同
• trust policy 裡面指定的 principal 也要更新
• 資源策略（例如 S3 bucket policy）裡的 AWS Principal 可能要改

簡單講：搬家後門鎖位置變了，鑰匙孔也得重新配。

資料與配置遷移：先搬「資料」，再搬「控制」

在 AWS 遷移裡，一般順序建議是：先讓新環境「能跑」，再讓它「能讀寫資料」，最後才把流量與依賴全面切換。

1）S3：搬資料最常見，但權限策略要跟上

• 資料：使用同步方案（例如 S3 複製/同步）或遷移工具
• 權限：確保 bucket policy、ACL（如果有）與 IAM principal 對應
• 加密：如果用 KMS，KMS Key ARN 要在新帳號重新建立或做授權映射

常見坑：資料複製完成了，但服務讀不到。通常是權限或 KMS 授權沒跟上。

2）資料庫：以最小停機為目標

資料庫遷移通常分三類：

• 快照/備份 + 新建（適合資料量不太大、可接受停機窗口）
• 持續同步（適合要降低停機時間，但設定複雜度較高）
• 應用層逐步切換（適合能接受短暫延遲或有一致性策略）

不管哪種，請確保：

• 連線字串、端點、憑證（若有）會更新
• 安全組（Security Group）允許來源與端口
• 監控與告警（CloudWatch）不要丟到宇宙之外

3）KMS：別把加密鑰匙當魔法，它需要人授權

KMS 是最常造成「看起來都對，實際讀不了」的服務之一。你需要確認新帳號：

• 是否建立了對應的 KMS Key
• Key policy 與 IAM policy 是否允許需要的角色/服務使用
• 如果是跨帳號使用，是否授權了必要的 grant/Principal

小提醒：很多團隊遷移時只複製資料，卻忘了替換或重新建立 KMS key 的授權關係。結果就是解密直接失敗。

AWS帳號認證辦理 4）IAM：策略文件可以複用，但 ARN 必須更新

遷移時，IAM 最容易出現「看似有權限、但 ARN 不匹配」的狀況。你可以採用方法：

• 先用舊帳號的 IAM policy 做草稿
• 把文檔中的 Account ID 替換成新帳號
• 檢查 resource 的 ARN 是否包含正確 region 與 service 前綴
• 針對跨帳號 trust relationship 逐條核對

把 IAM 做成可審查的清單，比一次性「全丟上去」可靠得多。尤其在遷移的壓力時段，審查清單就是你的安全氣囊。

帳單與付款遷移：不要讓雲服務在你眼前「靜音」

遷移不只是在技術層，也在商業與合規層。付款設定錯了，雲可能不會立刻爆炸，但它會用「計費異常、服務受限」的方式告訴你：你以為沒事，它其實在生氣。

1）付款方式與帳單週期

你需要核對：

• 新帳號的付款方式是否已完成驗證
• 預付/後付的設定是否一致
• 是否有信用卡/發票/稅務欄位等需要補齊
• 預計切換日期，確保帳單結算不至於混亂

建議在切換窗口前，先對新帳號啟動一個低成本測試，確認計費與服務運作正常。

2）預留實例、Savings Plans、折扣與標籤策略

如果你有使用預留實例或 Savings Plans，請檢查：

• 這些資源是否會隨帳號遷移而失效
• 新帳號是否需要重新購買或重新套用折扣
• Cost Allocation Tag 是否延續，以便後續成本追蹤

遷移後突然成本上升，常見原因不是你真的變貴，而是折扣沒承接上。

網路與端點切換：DNS 不改，系統就像你換了門牌卻不通知快遞員

如果你的應用透過自建網域、CloudFront、API Gateway、或特定端點提供服務，那你必須管理「切換順序」。

1）Route 53 與憑證（ACM）

注意兩點：

• 若使用 Route 53，DNS record 的指向需要更新到新資源
• 若使用 ACM 證書，證書所在區域與新資源配對方式要正確（例如 CloudFront 的證書通常要求特定 region）

常見坑：你換了負載均衡器，但 HTTPS 證書沒有對上，導致用戶看到憑證錯誤。這類錯誤最「尷尬」，因為看起來像網路問題，但其實是證書策略問題。

2）VPC 與安全組：別只看連得上，還要看「能不能做你想做的事」

新帳號的安全組需要重新配置。特別是：

• 源/目的（CIDR、SG references）是否正確
• 跨服務通信是否被允許（例如 ALB → EC2、EC2 → RDS）
• NAT/VPN/Direct Connect 路由是否正確

如果你使用內部服務互通，請先做最小化測試：例如從前端到後端 API 呼叫，再測資料讀取是否通。

監控、日誌與告警：你不想在出事時才想起來要看日誌

遷移常見「看不到」問題，其實是日誌沒有搬，告警也沒繼承。

1）CloudWatch：告警與 Dashboard 都要重新確認

遷移後請檢查：

• 告警（Alarm）是否存在
• Dashboard 視覺化是否需要重新建立
• 告警通知（SNS/Email/ChatOps）是否設定好

2）CloudTrail：審計日誌別丟

若你有合規要求，CloudTrail 通常需要持續保留。確認：

• Trail 是否開啟（單帳號或組織層級）
• 日誌目的地（S3）權限與 KMS 是否正確
• 事件選擇器（event selectors）是否一致

切換流程：最後一公里才是真正的考驗

當新帳號的資源都已部署並測試通過，你還要做切換。切換常見包含：

• 更新 DNS/端點
• 更新應用設定檔（連線字串、憑證、環境變數）
• 切換 CI/CD pipeline 來源或部署目標（若有）
• 更新第三方系統的憑證/回呼地址

切換前的「演練」建議

在正式切換前做一場演練：

• 安排一個時間窗（避開高峰）
• 準備回滾方案（回到舊帳號的 DNS 或撤回策略）
• 指定一位「不發散的決策者」與一位「技術救火的人」

你會發現：大多數事故不是技術不會，是人會慌。

驗證清單：遷移完成不等於你真的完成了

遷移完成後，建議你用下面這份清單逐項勾選。把它當成「交付驗收表」，會非常有效。

1）功能測試

• 前端頁面/ API 是否可用
• 資料庫讀寫是否正常（含更新、查詢、交易一致性）
• 檔案上傳下載（S3）是否正常且權限正確
• 排程任務/定時任務是否運行

2）權限測試

• 各角色（IAM Role）是否能 assume 成功
• KMS 是否能加解密
• AWS帳號認證辦理 跨帳號存取是否成功（若有）

3）網路與安全測試

• HTTPS 是否正常（憑證有效、鏈結正確）
• 安全組與 NACL 是否沒有放鬆或錯封
• 內外網路路由與連線（VPN/Direct Connect）是否正常

4）成本與計費測試

• 新帳號有沒有異常高成本
• 折扣/預留實例是否如預期套用
• Cost allocation 標籤是否存在且可用

5）可觀測性測試

• 日誌是否能在新帳號查到
• 告警能否觸發（至少做一次模擬）
• CloudWatch 指標是否正常上報

善後：舊帳號怎麼處理？別留雷

遷移後你會面臨一個問題：舊帳號是否要保留？保留多久？刪除什麼？這些都跟合規、資料保留策略、以及你團隊的習慣有關。

建議的善後步驟

• 確認所有資源已停止或已搬遷完成（避免雙跑造成成本爆炸）
• 保留必要的審計日誌與備份（通常要符合內部或法規要求）
• 調整舊帳號的 IAM 使用者/角色，避免仍有人誤操作
• 更新文檔：把新帳號的 Endpoint、環境變數、部署目標更新到位

最後提醒一句：不要因為「看起來都好了」就把舊帳號完全當成垃圾桶。遷移期間你會製造一些你當下沒想到的依賴；等它們冒出來時，你會很想感謝你當初留了一條後路。

常見踩坑總結：把你的痛點變成我的備忘錄

• 資源搬了，權限沒搬：結果就是 403、KMS 解密失敗或 S3 讀不到。
• AWS帳號認證辦理 跨帳號信任沒更新：trust relationship 沒改， assume role 直接失敗。
• DNS/端點切換太急：導致外部用戶在過渡期間訪問到不存在的服務或錯誤憑證。
• ACM 證書與區域不匹配：HTTPS 畫面恐怖到足以讓人失眠。
• 告警與日誌沒確認：你以為能監控，結果只是「沒有資料可看」。
• 折扣/預留沒承接：遷移後成本突然上升，然後大家開始用眼神討伐雲。

一個實用的遷移計畫範本（你可以直接照抄）

如果你需要把這件事變成可執行的項目管理任務，這裡給你一個範本（你可以改成你們的實際內容）。

階段 0：準備

• 確認遷移範圍（帳號層級 vs 資料更新 vs Organizations 結構）
• 盤點資源、依賴、權限與合規需求
• 建立新帳號環境（基礎網路、IAM 骨架、KMS/存儲初始配置）

階段 1：遷移與建置

• 同步 S3/資料庫/必要的配置
• 建立新帳號的 IAM、KMS 授權、CloudWatch/CloudTrail
• 逐項測試「功能 + 權限 + 可觀測性」

階段 2：切換

• 更新 DNS/端點與應用設定
• 切換 CI/CD（如有）
• 切換期間密切監控告警

階段 3：驗收與善後

• 完成驗證清單勾選
• 回滾演練結果與正式切換記錄存檔
• 停用/刪除或保留舊資源，更新文檔

結語：把不確定性變成清單，你就已經贏了一半

AWS 亞馬遜雲實名賬號遷移的難點，從來不只是技術按幾下。真正的難點在於「你是否掌握全貌」：資源有哪些、權限怎麼串、加密鑰匙在哪、告警是否還在、帳單是否會卡、DNS 是否已準確切換。

只要你把本文的盤點、策略選型、資源與權限映射、切換與驗證清單落地，你就能把遷移從一場賭局，變成一次有節奏的工程。雲端不怕你忙，怕的是你忙著做，卻沒留痕、沒驗收。

最後送你一句遷移行業名言（雖然可能不太「正式」，但真的很真）：遷移完成不是最後一步，驗證清單才是。 祝你切換順利、成本可控、告警安靜、同事不在半夜敲你。