AWS アカウント作成後にまず行う初期設定｜ルートユーザーの保護・IAM Identity Center・請求アラート・CloudTrail

AWS アカウントの初期設定で先に済ませるべきことは、①ルートユーザーに MFA を付けてアクセスキーを作らない、②日常の作業用に別の ID（IAM Identity Center のユーザーか IAM ユーザー）を作る、③AWS Budgets で請求の上限アラートを入れる、④CloudTrail が記録されていることを確かめる、の 4 つです。この 4 つが終わってから、EC2 や Lightsail に WordPress を載せます。

結論を先にまとめます。

• アカウント作成時のメールアドレスとパスワードが「ルートユーザー」です。何でもできる ID なので、日常の操作には使いません。AWS は 2026年11月現在、すべての種類のアカウントでルートユーザーの MFA を必須にしています（初回サインインから 14 日以内に登録を求められます）。
• ルートユーザーのアクセスキー（CLI や API 用の長期キー）は作りません。CLI から使う必要があれば aws login で一時的な資格情報を取ります。
• 日常の操作は、AWS が推奨する IAM Identity Center のユーザー、または管理者権限を持つ IAM ユーザーで行います。どちらも MFA を付けます。
• 請求は AWS Budgets で月額の上限を決めてメール通知を入れます。使い過ぎは通知が来た時点で止めても数時間分は請求されるので、早めのしきい値にします。

ルートユーザーと作業用 ID の違い

AWS の公式ドキュメントは、人がサインインする用途には IAM ユーザーより IAM Identity Center（旧 AWS Single Sign-On）を勧めています。Identity Center のユーザーはサインインごとに一時的な資格情報をもらうので、漏れたパスワードやアクセスキーが長く使われる危険が小さいからです。1 人で 1 アカウントだけ使う小規模な構成では、管理者権限の IAM ユーザーを 1 つ作る方法でも始められます。

手順 1: ルートユーザーを保護する

1. ルートユーザーでマネジメントコンソールにサインインし、右上のアカウント名から セキュリティ認証情報 を開きます。
2. MFA を割り当てるで、認証アプリ（仮想 MFA）か、パスキー・セキュリティキー（FIDO）を登録します。AWS はフィッシングに強いパスキー・セキュリティキーを推奨しています。2 台以上登録しておくと、1 台をなくしても別の 1 台で入れます。種類の選び方と紛失時の手順は AWS の MFA を設定する方法 にまとめています。
3. 同じ画面の アクセスキー が空であることを確かめます。ルートユーザーのアクセスキーは作りません。
4. ルートユーザーのメールアドレスは、個人のアドレスではなく、担当者が代わっても受け取れる会社のグループアドレスにします。復旧に使う電話番号も最新にしておきます。

パスワードは 8〜128 文字で、大文字・小文字・数字・記号のうち 3 種類以上を含める必要があります。パスワード管理ツールで生成したものを使います。

手順 2: 日常の作業用 ID を作る

IAM Identity Center を使う場合（推奨）

1. コンソールで IAM Identity Center を開き、有効化します。アカウントへのアクセス管理に使うには「組織インスタンス」が必要で、このとき AWS Organizations も有効になります（1 アカウントでもそのまま進められます）。
2. ID ソースは「Identity Center ディレクトリ」（Identity Center の中にユーザーを作る）を選びます。社内に Microsoft Entra ID や Google Workspace があれば、それをつなぐこともできます。
3. ユーザーを作り、「許可セット」（例: AdministratorAccess）を割り当てます。ユーザーは AWS アクセスポータルの URL からサインインし、MFA を登録します。

IAM ユーザーで始める場合

1. IAM → ユーザー → ユーザーの作成で、管理者用のユーザーを作ります。「AWS マネジメントコンソールへのアクセスを提供」を選び、パスワードを設定します。
2. 許可は、まずは AWS 管理ポリシー AdministratorAccess を付け、後で必要な範囲に絞ります。
3. 作成後、そのユーザーで一度サインインし、MFA を登録します。
4. 請求画面も見せたい場合は、ルートユーザーで アカウント → IAM ユーザーおよびロールによる請求情報へのアクセス を有効にしておきます（これをしないと、ポリシーで許可しても請求画面が開けません）。

この後は、ルートユーザーでサインアウトし、以降の作業は作った ID で行います。

手順 3: 請求アラートを入れる

1. Billing and Cost Management → Budgets → 予算を作成 を開きます。
2. 「コスト予算」を選び、期間は月次、金額は想定する月額の少し上に設定します。
3. 通知は「実際のコスト」が予算の 50%・80%・全額に達したとき、のように段階を分けてメールを登録します。「予測コスト」の通知も付けると、月の途中で超えそうな時に先に分かります。

AWS Budgets の情報は 1 日に最大 3 回更新され、前の更新から 8〜12 時間後に反映されます。通知が来た時点ではすでに数時間分の利用が発生しているので、「止めたい額」より低めのしきい値にしておきます。

手順 4: CloudTrail と各種の記録を確かめる

CloudTrail は、コンソールや API での操作（管理イベント）を記録するサービスです。アカウントを作った時点で有効になっており、イベント履歴から直近 90 日分の管理イベントを検索できます。「誰がいつインスタンスを止めたか」「ルートユーザーのサインインがあったか」はここで追えます。

90 日より長く残したい、S3 に保存して監査に使いたい、という場合は「トレイル」を作ります。1 つ目のトレイル（管理イベントのみ）は S3 の保存料金だけで作れます。

あわせて見ておくものを挙げます。

• リージョン: WordPress を日本の利用者向けに置くなら、東京（ap-northeast-1）か大阪（ap-northeast-3）を選びます。使わないリージョンは「アカウント → AWS リージョン」で無効化できます。
• IAM の認証情報レポート: IAM → 認証情報レポートで、MFA の有無やアクセスキーの作成日を一覧できます。
• Trusted Advisor: 無料の範囲でも、ルートユーザーの MFA 未設定やセキュリティグループの全開放を指摘してくれます。

WordPress の観点: EC2 / Lightsail に載せる前に

初期設定が終わったら、WordPress をどこに載せるかを決めます。

どちらでも、SSH（22 番）は自社の固定 IP からだけに絞り、WordPress のデータベースは定期的にバックアップします（WordPress のデータベースを手動でバックアップする方法）。既存のサーバーから移す場合の費用と期間の考え方は サーバー移行を頼む場合の費用・期間・準備 に書いています。

よくある質問

ルートユーザーの MFA は本当に必須ですか

2026年11月現在、AWS はスタンドアロン・管理・メンバーのすべてのアカウント種類でルートユーザーの MFA を必須としています。未登録のまま初回サインインから 14 日を過ぎると、コンソールに入る前に MFA の登録を求められます。

1 人で使う小さな構成でも IAM Identity Center を使うべきですか

AWS の推奨は Identity Center ですが、1 人・1 アカウントなら、MFA を付けた管理者 IAM ユーザーでも大きな問題はありません。人が増える、アカウントを分ける、という段階になったら Identity Center に移すと管理が楽になります。

無料利用枠を超えないか心配です

AWS Budgets で月額の上限を決め、50% と 80% で通知を受けるのが現実的な対策です。Budgets の反映には 8〜12 時間の遅れがあるので、通知を見てすぐ止めても数時間分は請求が発生します。使わないリソース（止めたインスタンスの EBS、Elastic IP の未使用分、スナップショット）が残りがちな点にも注意してください。

アクセスキーを作ってしまいました

ルートユーザーのアクセスキーは、セキュリティ認証情報の画面で「無効化」してから削除します。CLI から操作したい場合は、作業用の IAM ユーザーか Identity Center のユーザーで aws configure sso または aws login を使い、一時的な資格情報で作業します。

まとめ

• AWS アカウントの初期設定は、ルートユーザーの MFA 登録とアクセスキーを作らないことから始めます。
• 日常の操作は IAM Identity Center のユーザー（または MFA 付きの管理者 IAM ユーザー）に分け、ルートユーザーは「ルートでしかできない作業」にだけ使います。
• AWS Budgets の請求アラートと CloudTrail のイベント履歴を確かめてから、EC2 や Lightsail に WordPress を載せます。

関連記事

• AWS の MFA を設定する方法｜ルートユーザーと IAM ユーザー、パスキー・認証アプリ・ハードウェアキーの選び方
• サーバー移行（引っ越し）を頼む場合の費用・期間・準備
• WordPress のデータベースを手動でバックアップする方法

参考: Setting up your AWS account（IAM User Guide）、Root user best practices for your AWS account、What is IAM Identity Center?、Managing your costs with AWS Budgets、CloudTrail concepts

更新履歴: 2026-11-09 全面改訂（定型文の記事を、ルートユーザーの保護・作業用 ID・請求アラート・CloudTrail の 4 段階の手順に置き換え。MFA の詳細は別記事に分離）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。