2026年6月16日
2026年6月16日
AWSアカウントの初期セットアップとセキュリティ設定|ルートユーザーの保護・作業用ユーザー・請求アラート・ログ
AWSアカウントを作ったら、EC2などを動かす前に「ルートユーザーを封印する」「日常の作業用の入口を作る」「請求の異常に気付ける仕組みを置く」「操作の記録を残す」の4つを済ませておくのが基本です。この記事では、アカウント作成直後に行う設定を順番に並べ、それぞれをなぜ行うのか、どこでつまずきやすいか、設定できたかをどう確かめるかを説明します。
AWSのコンソールは画面構成やメニュー名がたびたび変わります。ここでの説明は2026年10月現在の情報をもとにしていますが、項目名は目安として読み、迷ったときはAWSの公式ドキュメントで最新の手順を確認してください(2026年10月現在)。
最初に理解しておくこと:ルートユーザーは日常で使わない
アカウント作成時に登録したメールアドレスとパスワードでログインする主体を「ルートユーザー」と呼びます。ルートユーザーはアカウント内のすべての操作ができ、IAMのポリシーで権限を絞ることもできません。パスワードが漏れると、リソースの削除や高額なインスタンスの大量起動まで一気にされてしまいます。
そのため、ルートユーザーは「アカウントの解約や支払い方法の変更など、ルートでしかできない操作のときだけ使う鍵」と考え、普段の作業は別の主体で行います。ルートでしかできない操作は多くないので、初期設定を終えたあとはほとんどログインしない状態が理想です。
ステップ1:ルートユーザーを守る
強いパスワードとMFAを設定する
まずルートユーザーでログインし、アカウント名のメニューからセキュリティ認証情報の画面を開いて、多要素認証(MFA)を登録します。選べる方式は、パスキーやセキュリティキー(FIDO2)、認証アプリ(TOTP)、ハードウェアのTOTPトークンなどです。AWSはルートユーザーへのMFAの登録を段階的に求める方針を取っており、未登録だとログイン時に登録を促されることがあります。
つまずきやすいのは、MFAを登録したスマートフォンを機種変更して入れなくなるケースです。MFAデバイスは複数登録できるので、認証アプリとセキュリティキーなど2つ以上を登録しておくと、1つを失ってもログインできます。パスワードはパスワードマネージャーで長いランダムな文字列を生成して保管します。
ルートのアクセスキーは作らない
アクセスキーはCLIやプログラムからAWSを操作するための認証情報です。ルートユーザーのアクセスキーがあると、それが漏れたときの被害がアカウント全体に及びます。セキュリティ認証情報の画面でアクセスキーが1つも無いことを確認し、もしあれば削除します。
連絡先と登録メールアドレスを見直す
アカウント設定の画面では、請求・運用・セキュリティの各連絡先(代替の連絡先)を登録できます。AWSからの不正利用の疑いや障害の通知が担当者に届くよう、個人のアドレスではなく、チームで受け取れるアドレスを設定しておくと引き継ぎで困りません。ルートユーザーのメールアドレスも、退職などで受信できなくなるとパスワードの再設定ができなくなるため、長く使える共有のアドレスにしておくのが無難です。
ステップ2:日常の作業用の入口を作る
日常の作業には、IAM Identity Center のユーザーか、IAMユーザーを使います。
- IAM Identity Center:AWSが人のログインに推奨している方式です。ユーザーごとに一時的な認証情報が発行され、長期のアクセスキーを手元に置かずにCLIも使えます。複数のアカウントを使い分ける場合や、チームで使う場合に向いています。
- IAMユーザー:1つのアカウントを個人で使う小規模な環境では、IAMユーザーにMFAを付けて使う方法も選べます。ただしアクセスキーを発行すると長期の認証情報になるため、扱いには注意が必要です。
どちらの場合も、最初に作るのは管理者権限を持つユーザーです。IAM Identity Center ならAWSが用意している管理者用の権限セットを割り当て、IAMユーザーならグループを作って管理者のポリシーを付け、そのグループにユーザーを入れます。ユーザーに直接ポリシーを付けるより、グループや権限セットの単位で管理したほうが、人が増えたときに整理しやすくなります。
作業用ユーザーを作ったら、一度ログアウトしてそのユーザーでログインし直し、EC2やIAMの画面が開けることを確かめます。ここで問題がなければ、以後はルートユーザーでログインしないようにします。
請求情報へのアクセスを許可する
IAMユーザーやロールで請求の画面を見ようとすると、管理者ポリシーを付けていても拒否されることがあります。これは、アカウント設定の中にある「IAMユーザーとロールに請求情報へのアクセスを許可する」設定が有効になっていないためです。この設定はルートユーザーでしか変更できないので、ステップ1でルートでログインしている間に有効にしておくと二度手間になりません。
ステップ3:請求の異常に気付ける仕組みを置く
AWSは使った分だけ請求される仕組みなので、消し忘れたリソースや、認証情報の漏えいによる不正な利用が、月末の請求で初めて発覚することがあります。これを防ぐために、早い段階で予算の通知を設定します。
- AWS Budgets:月の予算額を決め、実際の金額や予測額がその一定割合を超えたらメールで通知します。テンプレートから作れるので、最初はこれだけでも効果があります。
- コスト異常検出(Cost Anomaly Detection):普段の使い方から外れた支出の増加を検出して通知します。予算の閾値に達する前の急な変化に気付けます。
新規アカウントの無料利用枠の仕組みは2025年に見直されており、作成時期によって内容が異なります。無料の範囲や期限は請求の画面と公式の案内で確認し、無料の範囲を超えたら通知が来るように設定しておくと安心です。具体的な金額は変わるため、この記事では挙げません。
ステップ4:操作の記録を残す
CloudTrailの証跡を作る
CloudTrailは、誰がいつどのAPIを呼んだかを記録するサービスです。何も設定しなくても直近の管理イベントはイベント履歴で見られますが、保存期間に限りがあります。インシデントが起きたときにさかのぼって調べられるよう、証跡(トレイル)を作成してS3バケットに長期保存します。すべてのリージョンを対象にしておくと、普段使っていないリージョンでの不審な操作も記録されます。
保存先のS3バケットは、パブリックアクセスをブロックし、削除や改ざんをしにくい設定にしておきます。ログを保存するだけでなく、ときどきイベント履歴を開いて、自分の知らない操作が無いかを眺める習慣を付けると、異変に早く気付けます。
脅威の検出を有効にする
GuardDutyはCloudTrailやVPCのフローログなどを分析し、不審なAPI呼び出しや既知の悪性IPとの通信を検出するサービスです。Security HubやIAM Access Analyzerと組み合わせると、設定の不備や外部に公開されたリソースも洗い出せます。いずれも利用量に応じた料金がかかるため、試用期間の間に通知の量と費用感を確認してから、継続するかを決めるとよいでしょう。
ステップ5:アカウント全体の既定値を安全側に寄せる
最後に、あとから作るリソースが自動的に安全な状態になるよう、アカウント単位の既定値を確認します。
- S3のパブリックアクセスブロック:アカウント単位で有効にすると、バケットの設定を誤っても外部に公開されにくくなります。静的サイトの配信などで公開が必要な場合は、CloudFront経由で配信する構成を検討します。
- EBSの既定の暗号化:リージョンごとの設定です。有効にすると、新しく作るEBSボリュームが自動で暗号化されます。使うリージョンで有効になっているかを確認します。
- パスワードポリシー:IAMユーザーを使う場合は、パスワードの長さや再利用の制限を設定します。
- 使うリージョンを決める:日本向けのサイトなら東京(ap-northeast-1)や大阪(ap-northeast-3)が候補です。普段使わないリージョンにリソースが無いかを、ときどきコンソールで確認します。
設定できたかを確かめるチェックリスト
初期設定が終わったら、次の項目を見直します。
- ルートユーザーにMFAが2つ以上登録され、アクセスキーが無い
- 作業用のユーザーでログインでき、MFAが有効になっている
- 請求の画面を作業用のユーザーで開ける
- 予算の通知が設定され、テストとして通知先のメールが受信できている
- CloudTrailの証跡がすべてのリージョンで有効になり、S3にログが届いている
- S3のパブリックアクセスブロックとEBSの既定の暗号化が有効になっている
このあとEC2でWordPressを動かすなら、SSHの鍵ペアやセキュリティグループの設定に進みます。アクセスキーをサーバーに置くのではなく、EC2にIAMロールを割り当てて権限を渡す方式を選ぶと、認証情報が漏れる経路を減らせます。
まとめ
- ルートユーザーはMFAを複数登録し、アクセスキーを作らず、日常では使わない。
- 日常の作業は IAM Identity Center のユーザーか、MFA付きのIAMユーザーで行う。権限はグループや権限セットで管理する。
- 請求情報へのアクセス許可はルートでしか変えられないので、初期設定のうちに有効にしておく。
- AWS Budgets とコスト異常検出で、想定外の請求に早く気付けるようにする。
- CloudTrailの証跡をすべてのリージョンで作り、S3のパブリックアクセスブロックとEBSの既定の暗号化を有効にする。