AWS アカウント作成後にすぐやるべきこと

はじめに

前回の記事で AWS アカウントの作成まで実施しました。
本記事では、アカウント作成直後の 無防備な状態 から 最低限安全に運用できる状態 となるための作業をまとめます。

アカウント作成直後の状態は以下です。

• アカウント全体を支配できるルートユーザーしか存在しない
• 課金監視が無効
• セキュリティ監視が無効

放置すると 不正利用 や 意図しない高額請求 に気づかず、とんでもない被害が出る可能性があるので、この記事の内容は アカウント作成当日中 に完了させてください。

また、主なターゲットは Terraform で AWS のインフラを管理したい個人開発者向けです。
（私がそのために AWS アカウントの準備したものの備忘録となりますので）

やるべきこと

• ルートユーザーの MFA 設定
• IAM ユーザーによる請求情報へのアクセス有効化
• 管理者用ユーザーの作成 (Identity Center)
• 管理者用ユーザーの MFA 設定
• Cost Explorer の有効化
• 請求アラートの有効化
• AWS Budgets の作成
• IAM Access Analyzer の有効化

ルートユーザーの MFA 設定

ルートユーザーはアカウント内の最強権限を持つため、今後は基本的に利用しないユーザーとなります。
アカウントを封印し、MFA を設定して厳重に保護していく必要があります。

手順

1. ルートでログイン（これが最後のログインになるはず）
   • https://console.aws.amazon.com/console/home/?nc2=h_si&src=header-signin
   • ルートユーザーの E メールを使用したサインイン を選択
2. 右上のアカウントを選択し セキュリティ認証情報 に入る
3. MFA が設定されていない場合には MFA が割り当てられていません と表示されるので MFA を割り当てる を選択
4. MFA の設定
   • デバイス名は識別しやすい名前（例：AWS-MFA-Root）
   • 認証アプリケーションを選択
5. 認証アプリケーションをダウンロードし QR コードを読み込む
   • 私は安直なので 1 つ目に記載のある Google Authenticator を選択しました (ﾃﾍｯ)
   • 表示された指示通りに、QRコードを読み、コードを入力し、MFA 追加 をクリック
6. 追加できたら「多要素認証 (MFA)」に追加されているか確認

これでルートユーザーのログイン時に MFA が要求されるようになります。

なぜパスキーではなく認証アプリ（TOTP）なのか

2026 年時点では、ルートユーザーの MFA としては パスキーではなく認証アプリケーションによる TOTP を私はお勧めしておきます。

理由：

• パスキーは比較的新しい技術で、トラブル時の対応ノウハウがまだ少ない
• パスキーはデバイス依存になりやすく、デバイスを失うと詰むリスクがある
  • 例：水をこぼしてデバイスが壊れたら、その時点で終了の可能性
• ルートユーザーは基本的にアクセスしないため 「失うリスク > 漏れるリスク」 と考えられる

最終的には個人の判断ですが、復旧しやすさを優先するなら TOTP が無難です。

IAM ユーザーによる請求情報へのアクセス有効化

デフォルトでは、ルートユーザー以外からは請求情報にアクセスできない設定となっています。
ルートユーザーは封印するので、ルート以外からも請求情報にアクセスできるようにする必要があります。

手順

1. 右上のアカウントを選択し アカウント に入る
2. IAM ユーザーおよびロールによる請求情報へのアクセス を探す
3. 無効化済み となっている場合は 編集 を押す
4. IAM アクセスをアクティブ化 のチェックボックスをクリックし、更新 を選択
5. 有効化済み となっていれば OK

管理者用ユーザーの作成 （Identity Center）

ルートユーザーは封印するので、今後の運用で利用する管理者ユーザーを作成します。
このユーザー作成が完了すれば、今後はルートユーザーを使わずここで作成する管理者ユーザーで作業します。

ユーザーの管理は IAM Identity Center を利用します。

なぜ Identity Center を使うのか

最終的に Terraform で AWS のインフラ管理を行うことを目標にしています。
ローカルから Terraform を実行するだけなら、IAM ユーザー + アクセスキーでも動きますが、本記事では Identity Center を採用します。

それぞれの選択肢を比較すると以下の通りです。

1. IAM ユーザー + アクセスキー
   • メリット
     • 設定が楽
     • シンプルで、すぐ動かせる
   • デメリット
     • アクセスキーが永続的な認証情報となるため、漏洩したら致命的
     • ローテーションが面倒
     • AWS 公式が非推奨 にしている
2. IAM ユーザー + MFA + STS でセッショントークン取得
   • メリット
     • アクセスキーが漏れても MFA がないと使えない
     • 一時的なトークンなので有効期限がある
   • デメリット
     • 設定が複雑
     • 根本のアクセスキーは存在し続ける
3. Identity Center + SSO
   • メリット
     • アクセスキー不要
     • 一時的な認証情報なので、漏洩リスクが少なく、セッション切れたら自動失効
     • AWS 公式が推奨 している
   • デメリット
     • 初期設定が面倒
     • Identity Center の概念を理解する必要がある

採用理由

「初期設定が面倒」というデメリットはあるものの、長期運用での安全性とメンテ性を考えると Identity Center を採用すべきだと考えています。
また、アクセスキーを所有することで生じる「誤って Git にコミットした」「永続キーをどこで保管するか」といった悩みから解放されます。

また 個人アカウントだからこそ、アクセスキー管理はやめた方が良い と考えています。
企業であれば情シスや SRE が漏洩検知や緊急停止の仕組みを整えているかと思いますが、個人ではすべてを自分で管理する必要があります。
「個人利用なら過剰では？」という考えも拝見しましたが、せっかく自由に使えるアカウントなので、知識や経験のためにも採用することをおすすめします。

グループの利用について

Identity Center にはグループという概念があり、複数ユーザーに同じ権限を一括付与できます。
個人利用では 1 ユーザーしか作らないため基本的に不要ですが、本記事では筆者の後学のためにグループ作成を採用しています。

理由：

• 一般的に Identity Center を運用する際は、グループ経由で権限を割り当てることが多い
• 将来複数人でアカウントを管理することになった際の移行が容易
• Terraform 化した際にコードが綺麗になりやすい

最低限の構成で十分という方は、グループを飛ばして直接ユーザーに permission set を割り当ててください。動作上は同じです。

手順

「グループ作成 -> ユーザー追加」といった順序で進めます。

Identity Center の有効化

コンソールから IAM Identity Center にアクセスし、Identity Center を有効化します。

グループの作成

これで「Admins グループに所属するユーザーは AdministratorAccess の権限を持つ」状態になります。

• IAM Identity Center > グループ から「グループの追加」を選択します。
  • グループ名
    • Admins など
  • 説明
    • オプションだが入力推奨
    • 例：管理者グループ
• IAM Identity Center > 許可セット から「許可セットの作成」を選択します。
  • 許可セットのタイプ
    • 事前定義されたアクセス許可セット
  • AWS 管理ポリシー
    • AdministratorAccess を選択
  • セッション期間
    • 12 時間 に設定
    • デフォルトの 1 時間では頻繁に再ログインが必要になり、開発時に不便です
• IAM Identity Center > AWS Organizations: AWS アカウント から該当の AWS アカウントを選択し、「ユーザーまたはグループを割り当て」をクリックします。
  • 作成したグループ（例：Admins）を選択
  • 作成した permission set（例：AdministratorAccess）を選択
  • 内容を確認して「送信」

ユーザーの作成

• IAM Identity Center > ユーザー から「ユーザーの追加」を選択します。
  • 入力内容（必須項目のみで OK）：
    • ユーザー名
      • 個人を識別できる名前を採用（例：firstName-familyName）
      • グループを作成する場合は「人」と「役割」を分離するため、admin のような役割名ではなく個人名がおすすめ
    • パスワード
      • 「パスワードの設定手順が記載された E メールをこのユーザーに送信します」を選択
    • E メールアドレス
      • 自分のメール（招待メールが届きます）
    • 名 / 姓
      • 自分の名前
    • 表示名
      • 自動入力されるのでそのままで OK

ユーザー作成画面の途中でグループ所属の選択があるので、作成した Admins グループを選択します。

AWS access portal URL を控える

IAM Identity Center > 設定 に移動し、「アイデンティティソース」にある AWS access portal URL をブックマークします。

形式：https://d-xxxxxxxxxx.awsapps.com/start

これが、今後管理者ユーザーで AWS にログインする際に使う URL です。

ルートからログアウト

ここまで完了したら、ルートからログアウトしましょう。
今後ルートでアクセスするのは、緊急時のみになります。

管理者用ユーザーの MFA 設定

ユーザー作成時に届いた招待メールから、初回パスワード設定と MFA 登録を行います。

手順

1. 招待メールのリンクをクリック
2. パスワードを設定
3. AWS access portal にリダイレクトされ、ログイン画面でユーザー名・パスワードを入力
4. 初回ログイン時に MFA 登録画面が表示される
5. 認証アプリ（Google Authenticator など）で QR コードを読み込み、6 桁コードを入力
6. MFA 登録完了 → access portal にアクセス可能

Cost Explorer の有効化

過去の利用状況を可視化するためのサービスです。
異常な請求が来た際や、アラートが鳴った際の調査の手掛かりとなります。

手順

1. 上部の検索バーで「Billing and Cost Management」を開く
2. 初回アクセスなら「Cost Explorer の有効化」または「Enable Cost Explorer」が表示されるのでクリック

ポイント

• 有効化してもデータが見られるようになるまで 最大 24 時間 かかる
• 有効化自体は 完全無料
• API 経由でデータを取得する場合のみ、リクエストごとに $0.01 の課金（コンソール閲覧は無料）

請求アラートの有効化

意図しない課金を早期検知するための設定です。
無料で有効化できるため、絶対に設定しておきましょう。

手順

1. Cost Explorer と同じく「Billing and Cost Management」から、左バーにある「請求設定」を開く
2. 「アラート設定」の「編集」をクリック
3. 以下にチェックを入れる
   • AWS 無料利用枠アラート：無料利用枠の使用量が 85% に達した時、超えた時にメール通知
   • CloudWatch 請求アラート：請求金額が CloudWatch のメトリクスとして発行される
4. 「更新」または「保存」で確定

ポイント

• どちらも 完全無料 で利用可能
• AWS 無料利用枠アラートは ルートユーザーのメールアドレスにのみ 送信される仕様
• CloudWatch 請求アラートを有効にしておくと、後述の Budgets の精度も上がる

AWS Budgets の作成

予算を設定し、閾値を超えたらメール通知される仕組みを作ります。
個人アカウントでよくある、「気がついたら請求金額がとんでもない」といった事象の防衛策です。

手順

1：ゼロ支出予算の作成

「$0.01 でも課金が発生したら通知する」予算です。
無料枠での運用を想定する場合、課金が発生しただけで気づけるものです。

1. 請求アラートと同じく「Billing and Cost Management」から、左バーにある「予算」を開く
2. 「予算を作成」をクリック
3. 「テンプレートを使用（シンプル）」を選択
4. テンプレートから「ゼロ支出予算」を選択
5. 入力内容
   • 予算名：zero-spend-alert など
   • E メール受信者：通知を受け取りたいメールアドレス
6. 予算を作成 をクリック

2：月次コスト予算の作成

月の予算上限を決めて、超えそうな場合に通知する予算です。

1. 同様に「予算を作成」をクリック
2. テンプレートから「月次コスト予算」を選択
3. 入力内容
   • 予算名：monthly-budget など
   • 予算額：月にいくらまで使う想定か
   • E メール受信者：自分のメールアドレス
4. 予算を作成 をクリック

月 2 つまで無料

AWS Budgets は 月 2 つの予算まで完全無料 で利用できます (AWS Budgets Pricing)。
本記事では無料枠内で運用するため、2 つの予算を作成します。

月次コスト予算の閾値について

テンプレートで作成した場合、デフォルトで以下のタイミングで通知されます：

• 実績が予算の 85% に到達
• 実績が予算の 100% に到達
• 予測が予算の 100% に到達

予算額の設定について

可能な限り低く設定したいと考えがちですが、低すぎる予算はアラート疲れの原因になります。

• 学習用個人アカウントなら $10〜$30 が目安
• 心配であれば最初は低めに設定し、頻繁にアラートが鳴るようなら見直す

予算額は「通常使用では鳴らず、異常時にだけ鳴る」設定が理想です。

IAM Access Analyzer の有効化

外部からアクセス可能なリソース（公開された S3、IAM ロールなど）を自動検知してくれるセキュリティ監視サービスです。
外部アクセスアナライザー は完全無料で利用できるため、必ず有効化しておきましょう。

手順

1. 右上のリージョンセレクターで通常利用するリージョンを選択
   • 日本国内、個人アカウントなら 東京リージョン (ap-northeast-1) で作業しておくとわかりやすい
2. 上部の検索バーで「IAM」と検索し、左バーにある「Access Analyzer」を開き、アナライザーを作成 をクリック
3. 設定内容
   • 検出結果のタイプ：「リソース分析 - 外部アクセス」を選択（追加費用なし と表示されるもの）
   • 信頼ゾーン：「現在の組織」を選択
     • Identity Center を有効化している場合は Organizations が作成されているはず
     • 1 アカウント運用なら「現在のアカウント」と挙動は同じ
   • 名前：デフォルトのままで OK
   • タグ：空欄で OK
4. アナライザーを作成 をクリック

アカウント作成日のセットアップ完了

ここまで完了すれば、AWS アカウントとして以下の状態になります。

• ルートユーザーは MFA で保護され、日常運用から切り離されている
• 管理者用ユーザー（Identity Center 経由）で安全に作業できる
• 課金監視（請求アラート、Budgets、Cost Explorer）が稼働している
• セキュリティ監視（IAM Access Analyzer）が稼働している

これで 作成日にやるべき最低限の防衛線 が完成しました。