AWS のアカウントを作ると、最初にサインインするのは登録したメールアドレスとパスワードの「ルートユーザー」です。そのまま EC2 を立てたり S3 を触ったりできてしまうので、何も設定しないまま学習を始める人は少なくありません。ところが、教材にも試験にも「ルートユーザーは日常に使わない」「MFA を付ける」「CloudTrail で記録する」「予算のアラートを置く」が繰り返し出てきます。
この記事は、アカウントを作った日にやっておく設定を、なぜそれが要るのかと一緒に順に整理します。操作の手順は変わるので、公式ドキュメントへ送ります。
この記事の結論
- 責任共有モデルでは、アカウントの ID・権限・記録の設定は利用者の担当で、AWS が代わりに守ってはくれません。
- ルートユーザーはアカウントのすべてに手が届く ID なので、MFA を付けてアクセスキーを作らず、ルートにしかできない作業のときだけ使います。
- 日常の作業には、IAM Identity Center か IAM で作った作業用の ID を使い、人の利用者には一時的な認証情報で入る形が勧められています。
- CloudTrail は「誰が、いつ、どの API を呼んだか」を記録するサービスで、90 日より長く残すには S3 に配信する証跡を作ります。
- AWS Budgets で予算としきい値を決めておくと、使いすぎに気づくのが請求書が届く前になります。
アカウントを作った直後、何が危ないのか？
たとえると、アカウントを作った直後は「家の親鍵を玄関に置いたまま、防犯カメラも電気代の知らせもない」状態です。親鍵（ルートユーザー）で毎日出入りしていると、落としたときにすべてを開けられてしまいます。誰が出入りしたかの記録がなければ、何かあっても後から追えません。電気代の知らせがなければ、付けっぱなしに気づくのは請求が来てからです。
正確な言葉に戻すと、AWS の責任共有モデルは「クラウド”の”セキュリティは AWS、クラウド”内の”セキュリティは利用者」と分けています。データセンターの建物や設備、ハードウェアを守るのは AWS です。一方、誰にサインインを許すか、どの権限を渡すか、操作の記録をどう残すかは、クラウド”内”の話なので利用者が自分で設定しないと、そのままになります。
最初にやる設定は、次の3つの危なさに対応しています。
| 危なさ | 起きること | 最初にやる設定 |
|---|---|---|
| 強すぎる ID を毎日使う | ルートユーザーの認証情報が漏れると、アカウントのすべてが操作される | ルートユーザーに MFA、アクセスキーを作らない、作業用の ID を別に作る |
| 記録が無い | 設定が変わっていても、誰がいつ変えたかを追えない | CloudTrail の証跡で操作の記録を残す |
| 使いすぎに気づけない | 止め忘れや不正な利用が、請求が来るまで分からない | AWS Budgets で予算としきい値を決め、通知を受ける |
DAY ONE作った日にやる順番
親鍵をしまい、記録と知らせを付けてから使い始める
-
ルートに MFA
アクセスキーは作らない
-
作業用の ID
Identity Center か IAM
-
ルートをしまう
ルートだけの作業に
-
CloudTrail
全リージョンを S3 へ
-
AWS Budgets
予算としきい値で通知
ルートユーザーとは（日常に使わない理由と MFA）
ルートユーザーは、AWS アカウントを作ったときにできる最初の ID で、アカウントのメールアドレスとパスワードでサインインします。アカウントのすべてのサービスとリソースに手が届き、IAM のポリシーで権限を絞ることができません。だからこそ、ルートユーザーを日常の作業に使うと、漏れたときの被害が最大になります。
IAM のユーザーガイドは、ルートユーザーについて次のことを勧めています。
- ルートユーザーのサインインに多要素認証（MFA）を付ける。可能ならパスキーやセキュリティキーのような、フィッシングに強い方式を選ぶ
- ルートユーザーのアクセスキーを作らない（プログラムからルートの権限で操作できる鍵を持たない）
- ルートユーザーの認証情報が要る作業のとき以外は、ルートユーザーでサインインしない
- 日常の作業には、管理者の権限を持つ別の ID を作って使う
「ルートにしかできない作業」には、アカウントの設定（ルートユーザーのメールアドレスやパスワードなど）の変更、IAM の管理者が誤って自分の権限を消してしまったときの復旧、請求情報を IAM の利用者にも見せる設定の有効化、AWS Organizations に属さない単独のアカウントの解約などがあります。どれも頻繁にやる作業ではありません。
MFA について、IAM のユーザーガイドは、単独のアカウントを含むすべての種類のアカウントでルートユーザーに MFA の設定を求めると説明しています。登録の期限などの細かい扱いは変わることがあるので、公式ページで確認してください。
CHECK 1ここまでの確認
日常の作業をルートユーザーで行わないほうがよい理由として、正しいものは?
答えと解説
答え: 1. ルートユーザーはアカウントのすべてに手が届き、IAM のポリシーで権限を絞れないから
ルートユーザーはアカウントを作ったときの最初の ID で、アカウントのすべてに手が届きます。漏れたときの被害が最大になるので、ルートにしかできない作業のときだけ使います。「ルートユーザーとは」の章を読み直してください。
作業用の ID は IAM Identity Center か IAM か？
ルートユーザーをしまったら、毎日の作業に使う ID が要ります。作り方は大きく2つあります。
WHO SIGNS INサインインの門
毎日の出入りは作業用の IDで。ルートは限られた作業だけ
サインイン（誰に、何のために入らせるか）
- ルート日常の作業 使わないすべてに手が届く
- ルートルートだけの作業 限って使うMFA を付けて
- IdCIdentity Center の作業用 ID 日常に使う一時的な認証情報
- IAMMFA を付けた IAM ユーザー 日常に使う1つのアカウントで
- 鍵埋め込んだアクセスキー 置かない長く使える
IAM Identity Center（勧められている形）
IAM Identity Center は、人の利用者のサインインを一元管理するサービスです。利用者は Identity Center のポータルからサインインし、割り当てられた許可セットの権限で各アカウントに入ります。このとき使われるのは、時間が来ると切れる一時的な認証情報です。
IAM のベストプラクティスは、人の利用者には ID プロバイダーとのフェデレーションで一時的な認証情報を使わせることを勧めていて、その中心に IAM Identity Center を置いています。認証情報が漏れても長くは使われないこと、退職や異動のときに1か所で止められることが理由です。
単独のアカウントで Identity Center を有効にすると、AWS Organizations の組織が作られ、そのアカウントが管理アカウントになります。複数のアカウントを使う予定があるなら、最初からこの形にしておくと、後でアカウントを増やすときに ID を作り直さずに済みます。
IAM ユーザー（1つのアカウントで始めるとき）
IAM ユーザーは、1つのアカウントの中に作る ID です。管理者の権限を持つ IAM ユーザーを作って MFA を付ければ、日常の作業からルートユーザーを外すことはできます。ただし IAM ユーザーのパスワードやアクセスキーは、利用者が止めるまで使える長期の認証情報です。アクセスキーはどうしても要るときだけ作り、コードやリポジトリに書かないことが前提になります。
| 見る点 | IAM Identity Center | IAM ユーザー |
|---|---|---|
| 認証情報 | 時間で切れる一時的なもの | パスワードやアクセスキーなど、止めるまで使える長期のもの |
| 管理する場所 | 1か所で、複数のアカウントへの入口をまとめる | アカウントごとに作る |
| 単独のアカウントで始めると | 組織が作られ、そのアカウントが管理アカウントになる | そのアカウントの中だけで完結する |
| 向く場面 | 複数のアカウント、チームでの利用、組織の仕組みも学ぶとき | まず1つのアカウントで試すとき |
どちらを選んでも、MFA を付けること、必要な権限だけを渡すこと（最小権限）は同じです。ユーザー・ロール・ポリシーの関係は IAM の記事で整理しています。
READ ALSO — 学習中向け・段1 入口
IAM とは何か｜ユーザー・ロール・ポリシーを「誰が・何に・何をしてよいか」で読み解く
CHECK 2ここまでの確認
作業用の ID について、IAM のベストプラクティスが人の利用者に勧めているのはどれ?
答えと解説
答え: 2. ID プロバイダーとのフェデレーションで一時的な認証情報を使わせ、IAM Identity Center で一元管理する
長く使える認証情報は、漏れたときに使われ続ける危険があります。人の利用者は一時的な認証情報で入る形が勧められています。「作業用の ID は IAM Identity Center か IAM か」の章を読み直してください。
CloudTrail とは（誰が何をしたかの記録を残す）
AWS CloudTrail は、アカウントの中で「誰が、いつ、どこから、どの API を呼んだか」を記録するサービスです。コンソールでの操作も、CLI や SDK からの操作も、裏では API の呼び出しなので、同じように記録されます。
何も設定しなくても、CloudTrail のイベント履歴で、リージョンごとに過去 90 日分の管理イベント（リソースの作成・変更・削除のような操作）を見られます。ただし 90 日を過ぎると見られなくなるので、長く残すには証跡（trail）を作って、ログを S3 のバケットに配信します。
| 見る点 | イベント履歴 | 証跡（trail） |
|---|---|---|
| 準備 | 要らない | 作る（配信先の S3 バケットを決める） |
| 残る期間 | 過去 90 日分 | S3 に置いたログを消すまで |
| 記録の範囲 | リージョンごとの管理イベント | 選んだイベント。全リージョンを対象にもできる |
| 向く用途 | 最近の変更をすぐ確かめる | 監査、長期の保管、アラームとの連携 |
証跡を作るときは、全リージョンを対象にしておくと、普段使わないリージョンで起きた操作も記録に残ります。管理イベントの1つめの写しを S3 に配信すること自体には CloudTrail の料金はかかりませんが、S3 の保管料はかかります。金額は公式の料金ページで確認してください。
記録は「何かあったときに見る」ものです。「ルートユーザーでサインインされたら知らせる」のように、記録を CloudWatch Logs に送ってアラームにつなげる使い方は、監視の設計の段で扱います。
CHECK 3ここまでの確認
CloudTrail の証跡を作らなくても、コンソールのイベント履歴で見られるのはどの範囲?
答えと解説
答え: 1. リージョンごとの、過去 90 日分の管理イベント
イベント履歴はリージョンごとに過去 90 日分の管理イベントを見せるもので、それより長く残すには S3 に配信する証跡を作ります。「CloudTrail とは」の章を読み直してください。
請求のアラートはなぜ最初に置くのか？（AWS Budgets）
セキュリティの設定に請求のアラートが入っているのは、使いすぎは、不正な利用に気づく一番早い合図になることがあるからです。認証情報が漏れて知らないリージョンで大きなインスタンスが立てられた場合も、学習で作ったものを止め忘れた場合も、最初に表に出るのは費用です。
AWS Budgets では、月ごとの費用などに予算を決め、しきい値を超えたときに通知を受けられます。決めるのは主に次のことです。
- 予算の金額（学習用なら、払ってもよい上限の金額）
- しきい値（金額そのものか、予算に対する割合か）
- 実際の費用で知らせるか、予測した費用で知らせるか
- 通知の送り先（メールアドレスや Amazon SNS のトピック）
予測で知らせる設定は、予測に使う利用の履歴がたまるまで働きません。アカウントを作った直後は、実際の費用で知らせるしきい値も一緒に置いておくと安心です。
アラートは知らせるだけで、リソースを止めたり消したりはしません。予算アクションで IAM のポリシーや SCP を自動で適用する仕組みもありますが、動いているものを止めるのは利用者です。費用の分析は Cost Explorer、予算の監視と通知は Budgets と、役割が分かれています。新しく作ったアカウントの料金の仕組み（無料プランと有料プランの選び方など）は変わることがあるので、公式ページで確認してください。
READ ALSO — 未経験向け・段1 入口
AWS の料金の考え方｜従量課金・無料利用枠・止め忘れを「電気代」で理解する
まとめ（最初の日にやる順番）
アカウントを作った日にやること
- ルートユーザーに MFA を付け、ルートユーザーのアクセスキーは作らない
- 日常の作業用の ID を、IAM Identity Center か、MFA を付けた IAM ユーザーで作る
- 以後はルートユーザーでサインインせず、ルートにしかできない作業のときだけ使う
- CloudTrail で、全リージョンを対象にした証跡を S3 に配信する
- AWS Budgets で予算としきい値を決め、メールで通知を受ける
- 責任共有モデルでは、ID・権限・記録の設定は利用者の担当です。
- ルートユーザーはアカウントのすべてに手が届くので、MFA を付けてしまっておきます。
- 人の利用者には、IAM Identity Center などを通した一時的な認証情報が勧められています。
- CloudTrail のイベント履歴は 90 日分なので、長く残すには証跡を作ります。
- AWS Budgets は、使いすぎと不正な利用に気づく早い合図になります。
参照ソース
- AWS account root user — ルートユーザーの性質、ルートにしかできない作業（2026年9月時点の AWS 公式ドキュメント）
- Root user best practices for your AWS account — MFA、アクセスキーを作らないこと、日常の作業用に管理者の ID を作ること（2026年9月時点の AWS 公式ドキュメント）
- Multi-factor authentication for AWS account root user — ルートユーザーの MFA、すべての種類のアカウントで MFA を求めること（2026年9月時点の AWS 公式ドキュメント）
- Security best practices in IAM — 人の利用者はフェデレーションと一時的な認証情報を使うこと、IAM Identity Center、最小権限（2026年9月時点の AWS 公式ドキュメント）
- What is IAM Identity Center? と Enable IAM Identity Center — 一元管理のサインイン、単独のアカウントで有効にすると組織が作られること（2026年9月時点の AWS 公式ドキュメント）
- Working with CloudTrail event history — イベント履歴はリージョンごとに過去 90 日分の管理イベント、長く残すには証跡を作ること、管理イベントの1つめの写しの配信（2026年9月時点の AWS 公式ドキュメント）
- What Is AWS CloudTrail? — CloudTrail が記録するもの（2026年9月時点の AWS 公式ドキュメント）
- Managing your costs with AWS Budgets と Creating a cost budget — 予算、しきい値、実績と予測の通知、予測に履歴が要ること（2026年9月時点の AWS 公式ドキュメント）
- 責任共有モデル — 「クラウドのセキュリティ」と「クラウド内のセキュリティ」の分担（_data/registry.yml の shared-responsibility。確認日は台帳に従う）
