はじめに
こんにちは、KUDs です。
「AWS を触ってみたいけど、知らないうちに高額請求が来るのが怖い」
AWS を始めるときに、いちばん多い不安がこれだと思います。
実際、「消し忘れたサーバーで数万円請求された」という話はいまも定期的に流れてきますし、決して都市伝説ではありません。
この記事では、AWS アカウントを作った直後にやっておくべき初期設定を7つ紹介します。
乱暴にまとめると、先に安全装置を全部つけてから運転を始めましょうという話です。
所要時間は30分ほど。
そして、この記事でやる作業自体には一切お金がかかりません。それどころか、設定3はやるだけで AWS からクレジットがもらえます。
なお、この記事は2025年7月に AWS の無料利用枠の仕組みが大きく変わったあとの情報で書いています。
「12ヶ月無料」を前提にした記事はもう当てはまらないので、そのあたりも含めて整理していきます。
この記事について
この記事は、AWS を初めて触る方向けのシリーズの1本です。
シリーズ全体では、AWS アカウントの初期設定から、AWS CLI の導入、Claude Code を使った開発環境の構築、そして実際にアプリを公開するところまでを順番に扱っています。
全体の地図と読む順番は、以下のロードマップ記事にまとめてあります。
この記事だけでも完結する内容になっていますので、初期設定だけ知りたい方はここだけ読んでいただければ大丈夫です。
そもそも AWS が何なのかから知りたい方は、前回の記事もあわせてどうぞ。
レンタルサーバーや VPS との違い、料金の仕組みを整理しています。
対象は「AWS アカウントを作ったばかりの個人の方」です。
会社で複数アカウントを運用している方には、ここで紹介する内容は簡略化されすぎているのでご注意ください。
まだアカウントを作っていない方へ
この記事はアカウントを作ったあとの設定を扱います。
まだの方は、先に作ってから読み進めてください。15分ほどで終わります。
作成手順は、AWS 公式がスクリーンショットに番号を振って解説しています。
私が書き直すより確実なので、そちらをご覧ください。
そのうえで、つまずきやすいところだけ挙げておきます。
1. 住所は英語で入力します
「東京都〇〇区〜」ではなく、番地から書く英語表記です。市区町村と番地の順序が日本語と逆になるので、そこだけ戸惑うと思います。
2. カードが弾かれることがあります
海外決済がブロックされていると登録できません。その場合はカード会社に連絡すれば解除してもらえます。
また、デビットカードやプリペイドカードは種類によって使えないことがあるので、うまくいかないときはクレジットカードで試してください。
3. 1ドルの請求が出ますが、戻ります
カードが有効かどうかを確かめるための与信確認です。実際の請求ではありません。
4. サポートプランは「ベーシック（無料）」を選びます
有料のプランも並びますが、学習には不要です。後からいつでも変更できます。
5. 学習目的なら「無料アカウントプラン」がおすすめです
作成の途中で、無料か有料かを選ぶ画面が出ます。
無料 → 有料は後から変更できますが、有料 → 無料には戻せません。 迷ったら、戻せるほうを選んでおくのが安全です。
ただし無料プランには期限があり、切れるとアカウントごと閉鎖されます。
このあたりは重要なので、次の章で詳しく扱います。
【重要】2025年、AWSの無料利用枠は仕組みが変わりました
設定の話に入る前に、これを知らないと判断を全部間違えるという前提があります。
2025年7月15日以降に作った AWS アカウントには、「12ヶ月無料利用枠」は存在しません。
かつては「アカウント作成から12ヶ月間は t2.micro のサーバーが月750時間まで無料」といった枠がありました。
AWS 入門記事の多くはこれを前提に書かれていますが、新規アカウントではもう使えません。
代わりに導入されたのが、アカウント作成時に選ぶ2つのプランです。
| 無料アカウントプラン | 有料アカウントプラン | |
|---|---|---|
| 使用中の課金 | 発生しない | クレジットを超えた分は実費 |
| もらえるクレジット | 最大200ドル | 最大200ドル |
| 使える無料枠 | Always Free のみ | Always Free ＋ 短期トライアル |
| 期間 | 6ヶ月、またはクレジットを使い切るまで | 期限なし |
| 期間終了後 | アカウントが自動的に閉鎖される | ― |
| プラン変更 | 有料へ変更できる | 無料には戻せない |
無料アカウントプランは、AWS が初めて用意した「本当に課金されない」プランです。
公式ドキュメントにも「使用中に発生する料金なし」とはっきり書かれています。課金が怖い方にとっては、これ以上ない安心材料です。
ただし、正直にお伝えしなければならない代償があります。
公式ドキュメントの表現をそのまま引用すると、こうです。
無料アカウントプランの有効期限が切れると、アカウントは自動的に閉鎖され、リソースとデータにアクセスできなくなります。
「停止」ではなく「閉鎖」です。 作ったものは使えなくなります。
その後90日間はコンテンツが保持されるので、その間に有料アカウントプランへアップグレードすれば復旧できますが、放置すれば完全に削除されます。
そしてもうひとつ、有料プランから無料プランへ戻すことはできません。片道切符です。
詳しい条件は公式ドキュメントで確認してください。
なお、2025年7月15日より前に作ったアカウントは「レガシー無料利用枠」として、従来どおり12ヶ月無料枠が使えます。
また、Always Free（ずっと無料）の枠は今もどちらのプランにも存在します。すべてが有料化されたわけではありません。
設定1: 自分のアカウントプランを確認する
というわけで、まず自分がどちらのプランなのかを確認してください。
ここから先の判断がすべて変わります。
確認手順
- AWS マネジメントコンソールにログイン
- 右上のアカウント名 → 請求とコスト管理
- 左メニューの「無料利用枠」を開く
ここで、現在のプランと、クレジットの残高・残り期間が確認できます。
無料プランの場合は以下のような表示が出ます。
どちらだったかで、この先の心構えが変わります。
- 無料アカウントプランだった場合 … 課金の心配はほぼありません。ただし6ヶ月でアカウントが閉鎖されるため、「本番として長く使うもの」をここに作ってはいけません。学習・お試し専用と割り切ってください
- 有料アカウントプランだった場合 … クレジットを使い切ったあとは実費が発生します。この記事の設定3以降が特に重要になります
どちらの場合でも、この記事の7つはすべてやっておいてください。
無料プランでも、ルートユーザーが乗っ取られれば「有料プランにアップグレードされたうえで悪用される」可能性は残っているためです。
設定2: ルートユーザーにMFAを設定する
7つのなかで、これがいちばん重要です。
AWS アカウントを作ったときのメールアドレスでログインするユーザーを「ルートユーザー」と呼びます。
これはそのアカウントで何でもできる最強の権限を持っています。請求先の変更も、アカウントの削除も、すべて可能です。
乗っ取られた場合、高性能なサーバーを大量に起動されて莫大な請求が発生する、という被害が実際に起きています。
攻撃者にとって、AWS アカウントは「他人の財布で計算資源が使える場所」だからです。
そこで MFA（多要素認証） を設定します。
パスワードに加えて、スマホの認証アプリなどによる確認が必要になる仕組みです。
設定手順
- ルートユーザーでマネジメントコンソールにログイン
- 右上のアカウント名 → セキュリティ認証情報
- 「多要素認証（MFA）」の欄で「MFA デバイスを割り当て」
- デバイスの種類を選ぶ（後述）
- 画面の指示に従って登録
どのデバイスを選ぶか
| 種類 | 具体例 | 備考 |
|---|---|---|
| パスキー / セキュリティキー | iPhone・Mac の生体認証、YubiKey | AWS が最も推奨。フィッシングに強い |
| 認証アプリ（TOTP） | Google Authenticator、1Password、Authy | いちばん手軽。これでも十分。 |
| ハードウェア TOTP トークン | 専用の物理デバイス | 個人利用ではあまり使わない |
迷ったら普段使っているパスワードマネージャーの認証アプリ機能か、Mac / iPhone のパスキーで登録するのが楽です。
「35日以内でいい」わけではありません
現在、AWS ではルートユーザーの MFA が必須化されています。
ただし猶予があり、AWS のルートユーザーのベストプラクティスには「初回サインインの試行から35日以内に MFA を登録する必要がある」と書かれています。
つまり、サインアップした時点では MFA なしの状態で最大35日間放置できてしまいます。
これは「35日は安全」という意味ではなく、単に35日間まったく無防備でいられるという意味です。
アカウントを作った初日にやってください。 5分で終わります。
復旧手段も確保しておく
MFA デバイスを紛失すると、ログインできなくなります。
そのため、以下も必ず確認してください。
- ルートユーザーのメールアドレスに、いつでもアクセスできること
- 登録している電話番号が最新であること（デバイスを全部失ったときの復旧経路になります）
- ルートユーザーのパスワードを、他で使い回していない強固なものにすること
なお、MFA デバイスは複数登録しておくことが推奨されています。AWS は「柔軟性と回復力のために、ルートユーザーには複数の MFA デバイスを有効にすることを強く推奨します」としており、最大8個まで登録できます。
1つ登録すればログインはできますが、2つ目（たとえば認証アプリに加えてパスキー）を登録しておくと、片方を失っても、もう片方でそのままログインできます。
メールと電話番号による復旧手続きを踏まずに済むので、可能なら2つ登録しておくのがおすすめです。
設定3: 予算アラートを作る
ここからがコストの話です。この記事の本丸と言ってもいいところです。
AWS には AWS Budgets という、予算を決めて超えたら通知してくれる機能があります。
古い記事の料金情報にご注意ください
日本語の記事でよく見かける「AWS Budgets は2つまで無料、それ以降は1日 0.02 ドル」という説明があります。
これは現在の料金体系ではありません（当時は正しかったものが、その後変わっています）。
現在の公式の料金ページには、こう書かれています。
You can monitor and receive notifications on your budgets free of charge.
つまり、通知だけの予算であれば、個数の制限なく無料です。
課金されるのは「アクション付きの予算」（月2個まで無料、以降1日 0.10 ドル）と「予算レポート」（1件 0.01 ドル）だけです。
つまり、予算アラートは好きなだけ無料で作れます。 作らない理由がありません。
予算1: ゼロ支出予算を作る
AWS には「ゼロ支出予算」というテンプレートが用意されています。
公式の説明は「支出が AWS 無料利用枠の上限を超えたときに通知する予算」で、実質的に1円でも課金が発生したら通知する設定です。
- マネジメントコンソール上部の検索窓で「Budgets」を検索して開く
- 「予算を作成」
- 「テンプレートを使用（シンプル）」を選択
- 「ゼロ支出予算」を選択
- 通知先のメールアドレスを入力して作成
これで「無料のつもりだったのに課金が始まっていた」にその月のうちに気付けます。
予算2: 自分の許容額で予算を作る
ゼロ支出予算だけだと、実際に何かを作り始めた瞬間から通知が鳴り続けてうるさくなります。
そこで、「ここを超えたらさすがにおかしい」という金額でもう1つ作っておきます。
- 同じく「予算を作成」→「テンプレートを使用（シンプル）」
- テンプレートは「月次コスト予算」
- 予算額に自分の許容額（学習用なら 5〜10 ドル程度）
- アラートのしきい値を設定（実績の80% と 予測の100% の2本立てがおすすめ）
- 通知先のメールアドレスを入力
ポイントは「予測」でもアラートを設定されることです。
実績だけを見ていると、月末に「使い切ってから」気付くことになります。予測を見ておけば、月の途中で「このペースだと超えます」と教えてくれます。
なぜ CloudWatch の請求アラームではないのか
同じことは CloudWatch の請求アラームでもできますが、初心者には Budgets をおすすめします。
| AWS Budgets | CloudWatch 請求アラーム | |
|---|---|---|
| 予測でのアラート | できる | できない |
| リージョンの制約 | なし | バージニア北部（us-east-1）でしか作れない |
| 事前の有効化 | 不要 | 請求アラートの有効化が必要 |
| 通知先 | メールを直接指定できる | SNS トピックの作成が必要 |
CloudWatch の請求アラームは「なぜか東京リージョンでは作れない」という有名な罠があります（請求のメトリクスがバージニア北部にしか存在しないためです）。
初心者がここで詰まる必要はないので、Budgets を使ってください。
おまけ: この作業でクレジットが20ドルもらえます
新規アカウントには、5つのアクティビティを完了すると1つにつき20ドル、最大100ドルのクレジットが付与される仕組みがあります。
その5つとは、以下です。
- Amazon EC2 でインスタンスを起動する
- Amazon Bedrock のプレイグラウンドで基盤モデルを使う
- AWS Budgets でコスト予算を設定する
- AWS Lambda で Web アプリを作る
- Amazon RDS でデータベースを作る
ここで注目してほしいのは、5つのうち4つは、実行すると実際に料金が発生してクレジットから引かれるという点です。AWS 自身がそう注記しています。
料金が発生しないのは「3. 予算の設定」だけです。
つまり、いま作った予算アラートは、無料でできるうえに20ドルもらえて、しかも今後の課金事故を防いでくれるという、いちばんお得なアクティビティでした。
5つのなかで最初にやるべきものが何かは、これで明らかだと思います。
クレジットの詳しい話は、別の記事で改めて扱います。
設定4: 無料利用枠アラートとコスト異常検出を確認する
予算アラート以外にも、AWS には自動で動く監視の仕組みがあります。
すでに動いているものと、動いていないものがあるので、確認しておきましょう。
無料利用枠の使用量アラート（既定でオン）
無料枠の85%に達すると自動でメールが届く仕組みがあり、個人アカウントでは既定で有効です（無料利用枠の使用量の追跡）。
確認する場合は、マネジメントコンソール → 請求とコスト管理 → 請求設定（Billing preferences）→ アラート設定 から見られます。
通知先のメールアドレスが正しいかだけ確認しておいてください。
コスト異常検出（既定の設定では役に立ちません）
AWS Cost Anomaly Detection は、機械学習で「いつもと違う使われ方」を検知して知らせてくれる機能です。
無料で使えて、Cost Explorer を有効化すると自動的に設定されます。
ただし、初心者にとっては既定の設定のままだとほぼ意味がありません。
自動で作られる通知の条件が「100ドル以上、かつ想定より40%以上の超過」だからです（コスト異常検出の開始方法）。
クレジット200ドルで学習している人にとって、100ドルの異常に気付いたところで、それはもう手遅れです。
使うなら、自分でしきい値を低く設定し直してください。
また、この機能は過去の使用実績から学習するため、作りたてのアカウントではしばらくまともに機能しません。
主役はあくまで設定3の予算アラートで、こちらは二の矢、という位置づけで考えるのが現実的です。
設定5: 作業用のIAMユーザーを作り、ルートを使うのをやめる
ルートユーザーは強力すぎるので、日常の作業には使いません。
代わりに、権限を絞った作業用のユーザーを作ります。この仕組みが IAM（アイアム） です。
設定手順
- マネジメントコンソールの検索窓で「IAM」を検索して開く
- 左メニューの「ユーザー」→「ユーザーを作成」
- ユーザー名を入力（例:
my-dev-user） - 「AWS マネジメントコンソールへのユーザーアクセスを提供する」にチェックを入れる（コンソールにログインして使うため）
- 「次へ」→「ポリシーを直接アタッチする」
PowerUserAccessを検索してチェック- あわせて
SignInLocalDevelopmentAccessも検索してチェック（2つ選んだ状態にします） - 「次へ」→「ユーザーの作成」 * 初回パスワードをコピーしておくこと！
- 作成後、画面右上のアカウント名をクリックし、「マルチセッションサポートをオンにする」
- 「セッションを追加」を押して、
my-dev-userと初回パスワードでサインインする
なぜ AdministratorAccess ではなく PowerUserAccess なのか
AdministratorAccess は管理者権限そのもので、IAM ユーザーの追加や権限の変更までできてしまいます。
PowerUserAccess は「IAM と請求まわり以外はほぼ何でもできる」権限です。学習には十分な自由度がありつつ、権限そのものを書き換えられる事故は防げます。
必要になったときに権限を足す、という進め方を「最小権限の原則」と呼びます。
AWS の資格試験でも繰り返し問われる、いちばん基本的な考え方です。
もうひとつの SignInLocalDevelopmentAccess は何か
こちらは、ブラウザ経由で認証して一時的な認証情報を受け取るための権限です。
次の記事で AWS CLI を設定するときに、アクセスキーを作らずに済ませるために使います。
AWS のリソースを操作する権限は含まれていないので、付けても権限が広がりすぎることはありません。
いま付けておくと、次の回でつまずかずに済みます。
「IAM ユーザーは非推奨、IAM Identity Center を使え」について
ここは丁寧に説明します。この記事でいちばん誤解が多いところだからです。
「IAM ユーザーはもう古い、これからは IAM Identity Center（旧 AWS SSO）を使うべき」という記述をよく見かけます。
そして、その主張自体は基本的に正しいです。AWS の公式ドキュメントも、人間が AWS にアクセスするときは ID プロバイダによるフェデレーションと一時的な認証情報を使うことを推奨しています。
ただし、新規アカウントの学習者に限っては、これをやると大きな代償を払うことになります。
単一アカウントで IAM Identity Center を有効化すると、クレジットが即座に消えます
IAM Identity Center の有効化ページには、公式に警告が書かれています。
If you use a free tier account, creating an AWS organization automatically upgrades your account to a paid plan with pay-as-you-go pricing. Your free tier credits expire immediately.
（無料利用枠のアカウントで AWS 組織を作成すると、アカウントは従量課金の有料プランに自動的にアップグレードされ、無料利用枠のクレジットは即座に失効します）
そして、組織に属していない単一アカウントで IAM Identity Center を有効化しようとすると、表示されるのは「AWS Organizations で IAM Identity Center を有効にする」というページです。公式ドキュメントいわく、この選択肢は「あなたのアカウントを管理アカウントとする新しい組織を作成します」。
つまり、単一アカウントで IAM Identity Center を有効にする＝ AWS Organizations を作る＝クレジット200ドルが即座に失効する、という流れになります。
「組織を作らないインスタンス」では代わりになりません
実は IAM Identity Center には、組織を作らずに使える「アカウントインスタンス」という形態もあります。
しかし、これは代替になりません。公式ドキュメントにこう書かれています。
Account instances do not support permission sets and therefore do not support access to AWS accounts.
（アカウントインスタンスは許可セットをサポートしていないため、AWS アカウントへのアクセスはサポートしていません）
アカウントインスタンスで使えるのは、一部の AWS マネージドアプリケーションへのサインインだけです。
肝心の「AWS のコンソールに SSO でログインする」ができません。
IAM Identity Center のアカウントインスタンスについて（公式）
結果として、クレジットを失わずに IAM Identity Center でコンソールにログインする方法は、事実上ありません。
非推奨なのは「IAM ユーザー」ではなく「長期のアクセスキー」です
では IAM ユーザーを使うのは危険なのか、というと、そこも正確に理解しておく必要があります。
AWS は IAM ユーザーを「廃止」も「非推奨」ともしていません。 警告の対象になっているのは、長期の認証情報、具体的にはアクセスキーです。
AWS のルートユーザーのベストプラクティスの表現はこうです。
Where possible, best practices recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys.
同じページでは、単一のスタンドアロンアカウントには IAM ロール、AWS Organizations で複数アカウントを管理する場合は IAM Identity Center、という使い分けも明記されています。
そして AWS が単一アカウント向けに出しているセキュリティ指針（AWS Startup Security Baseline）では、フェデレーションが使えない場合の出発点として、IAM ユーザーが明確に認められています。
If your startup is not yet ready to configure identity federation, you can create IAM users directly as a starting point.
As a baseline, create an IAM user with a username, password, and multi-factor authentication (MFA) for each human operator.
同じページには、この矛盾をきれいに解消する一文もあります。
Avoid creating long-lived access keys for IAM users. Instead, use temporary credentials through
aws loginto access the AWS CLI and SDKs, even when using IAM user credentials.
この記事の結論
以上をまとめると、新規アカウントの学習者が取るべき道は明確です。
- IAM ユーザーを作る（フェデレーションが現実的に使えないため、公式に認められた出発点）
- パスワード＋MFA でコンソールにログインする
- 長期のアクセスキーは作らない。 コマンド操作は
aws loginによる一時的な認証情報で行う（AWS CLI 2.32.0 以降） - アカウントが増えたり、クレジットを使い切ったりしたら、IAM Identity Center への移行を検討する
「ロールや一時認証情報が推奨なのに、なぜ IAM ユーザーなのか」という疑問への答えは、ユーザーという入れ物ではなく、長期のアクセスキーを作らないことが本質だからです。
IAM ユーザーにパスワードと MFA だけを持たせ、アクセスキーを発行しなければ、警告されている問題のほとんどは発生しません。
aws login の実際の使い方は、AWS CLI を導入する記事で詳しく扱います。
ルートユーザーのアクセスキーは絶対に作らない
念のため、これも書いておきます。
ルートユーザーのアクセスキーは、どんな理由があっても作らないでください。
漏れた瞬間にアカウントごと乗っ取られます。AWS 自身も「ルートユーザーのアクセスキーを作成しないことを強く推奨します」と書いており、プログラムからの操作が必要な場合は aws login を使うよう案内しています。
設定6: S3のブロックパブリックアクセスを確認する
S3 は AWS のファイル置き場のサービスで、初心者が最初に触ることが多いサービスです。
同時に、「意図せず全世界に公開してしまう」事故が最も多いサービスでもあります。
新しく作るバケットは、既定でパブリックアクセスが禁止されています。
これに加えて、アカウント全体に一括で網をかける設定があるので、そちらを確認しておきましょう。バケットごとの設定ミスがあっても、アカウント側でブロックされていれば公開事故になりません。
確認手順
- 検索窓で「S3」を検索して開く
- 左メニューの「アカウントと組織の設定」を開く
- 「このアカウントのブロックパブリックアクセス設定」の4項目を確認し、オフになっていたら「編集」からすべてオンにする
以前は左メニューに「このアカウントのブロックパブリックアクセス設定」という項目が直接並んでいましたが、現在は「アカウントと組織の設定」の中に移動しています（公式手順）。
古い記事のとおりに探すと見つからないので注意してください。
なお、バケット単位の既定と違い、アカウント単位の設定が最初からオンになっているかどうかは公式に明記されていません。
だからこそ、ここは「確認する」ではなく「自分の目で見て、オフならオンにする」作業として扱ってください。AWS 自身も、アカウントレベルでも4項目すべてを有効にすることを推奨しています。
将来、静的な Web サイトを公開するときにはこの設定を部分的に解除することになりますが、そのときは意識して解除するのが大事です。
既定でオフになっていて気付かないまま公開されている、という状態を避けるための設定です。
ちなみに、あの「バケット名を総当たりされて高額請求」は現在は起きません
S3 について、「バケット名を推測されて大量にアクセスされ、身に覚えのない請求が来た」という話を読んだことがあるかもしれません。
この問題は 2024年に AWS 側で修正されています。
現在は、アカウント外から送られてきて認可されずにエラー（HTTP 403）を返したリクエストには、リクエスト料金も通信料金も課金されません。
古い記事の情報なので、必要以上に怖がらなくて大丈夫です。
Amazon S3 が認可されていないリクエストに課金しなくなった件（AWS の発表）
設定7（任意）: アカウントの代替の連絡先を設定する
最後は任意の設定です。急がなくてかまいません。
AWS では、用途別に「代替の連絡先」を3つ登録できます。
| 連絡先 | 何が届くか |
|---|---|
| 請求 | 請求書、支払いに関する通知 |
| 運用 | サービス障害やメンテナンスの通知 |
| セキュリティ | セキュリティに関する重大な通知 |
設定手順
- 右上のアカウント名 → アカウント
- 「代替の連絡先」→「編集」
- 必要なものにメールアドレスと氏名・電話番号を入力
「設定しないと通知が届かない」わけではありません
この設定について、「セキュリティ連絡先を登録しておかないと、鍵の流出などの重要な通知を受け取れない」という説明を見かけることがあります。
これは正確ではありません。
公式ドキュメントには、代替の連絡先について次のように書かれています。
These are in addition to the email address associated with the root user of the account. The primary account contact will continue to receive all email communications sent to the root account’s email.
（これらはルートユーザーに紐づくメールアドレスに加えて指定するものです。主要アカウント連絡先は、ルートアカウントのメールアドレス宛のすべてのメール通信を引き続き受信します）
つまり代替の連絡先は、通知の宛先を差し替えるものではなく、宛先を増やすものです。
設定していなくても、ルートユーザーのメールアドレスにはすべて届きます。
では、誰が設定すべきか
この機能が本来想定しているのは、担当者が分かれている組織です。
- 請求の通知は経理のメーリングリストへ
- 障害の通知は運用チームへ
- セキュリティの通知はセキュリティ担当へ
といった振り分けをするための機能で、AWS の説明でも「担当者が不在のときのために」という文脈で語られています。
個人で1つのアカウントを使っていて、すべて自分のメールアドレスで受け取るなら、設定しなくても実害はありません。
設定する価値があるのは、次のようなケースです。
- ルートユーザーのメールアドレスを普段見ないアドレスにしている（この場合はぜひ設定してください）
- 請求の通知だけ別のアドレスに送りたい
- 将来的に誰かと共同で運用する予定がある
いずれにせよ、ルートユーザーのメールアドレスを普段確実に読めるようにしておくことのほうがはるかに重要です。
そちらは設定2で確認済みですね。
やってはいけないこと
初期設定の記事でよく勧められているけれど、初心者はやらないほうがいいものをまとめます。
AWS Organizations を作る・参加する
これがいちばん高くつきます。
AWS Free Tier の利用規約には、次のように書かれています。
If you are using an AWS Free Plan account and enroll in AWS Organizations, your account will be upgraded to a Paid Plan account, and you will no longer be able to use or earn credits offered under the Free Tier.
公式 FAQ の表現はもっと直接的です。
When your account joins an AWS Organization or sets up an AWS Control Tower landing zone, your Free Tier credits expire immediately, and your account will be ineligible to earn more AWS Free Tier credits.
「もらえなくなる」だけではありません。すでに持っているクレジットも即座に失効します。
そして、組織を作ってしまう操作は AWS Organizations の画面だけではありません。
IAM Identity Center の有効化、AWS Control Tower のセットアップも、内部で組織を作ります。 設定5で触れたとおりです。
公式ドキュメントによれば、以下のいずれかを行うと無料アカウントプランは自動的に有料プランへ切り替わります。
AWS Organizations への参加 / AWS Control Tower ランディングゾーンのセットアップ / AWS Partner Network への参加 / Professional Services 契約の作成 / AWS との Enterprise Agreement への加入 / AWS Skill Builder Team サブスクリプションの購入 / アカウントを HIPAA または SEC 準拠として指定
学習用のアカウントでは、これらに一切近づかないでください。
「便利そうだから」と有効化した瞬間に、3万円ぶんの学習リソースが消えます。
なお、ここで引用した規約の文面は無料アカウントプランを対象として書かれています。有料アカウントプランのクレジットがどう扱われるかは公式に明記されていないため、この記事では断定しません。
いずれにせよ、クレジットを使い切るまでは組織を作らないのが安全です。
GuardDuty / Security Hub / AWS Config を有効化する
「セキュリティのために有効化しましょう」と紹介されることがありますが、これらはすべて結構お高いです。
無料トライアル期間が終わると課金が始まり、しかも Security Hub は AWS Config の記録を必要とするため、Config の料金も別途かかります。
料金は各公式ページで確認できます（GuardDuty / Security Hub / AWS Config）。
課金を心配してこの記事を読んでいる方が、セキュリティのつもりで請求を増やしてしまうのは本末転倒です。
個人の学習用途では、有効化してもいいが常時稼働させるとすぐにクレジットが尽きかねないと理解しておきましょう。
無料で使えるものとしては、IAM Access Analyzer（外部に公開されているリソースの検出）と Trusted Advisor の基本チェックがあります。こちらは触ってみて損はありません。
使わないリージョンを無効化する
「不要なリージョンを無効化してセキュリティを高めましょう」という手順を見かけますが、新規アカウントでやる必要はありません。
- 東京リージョンは既定で有効、かつ無効化できません
- 大阪や香港などのオプトインリージョンは、もともと無効です
つまり、やることがほとんどありません。
むしろ操作を誤って自分がアクセスできなくなるリスクのほうが大きいので、初心者は触らないでください。
CloudTrail の証跡（トレイル）を作成する
「操作ログを残しましょう」と CloudTrail の証跡作成を勧める記事がありますが、証跡を作ると S3 の保管料金が継続的に発生します。
CloudTrail の イベント履歴 は既定で有効・無料・90日間保持されています。
個人の学習用途なら、これで十分でしょう。
高額というわけではないですが、忘れてしまうことが多いため、証跡を永続的に残すのはそれなりのサービスを作ったときで良いかと思います。
パブリック IPv4 アドレスの料金に注意する
これは「やってはいけないこと」ではなく知っておくべき罠です。
2024年2月から、パブリック IPv4 アドレスは1個あたり1時間 0.005 ドル（月あたりおよそ3.6ドル）で課金されるようになりました（VPC の料金）。
厄介なのは、EC2 インスタンスを「停止」しても、紐づいた Elastic IP には課金され続けることです。
「使っていないから0円のはず」と思い込んでいると、じわじわ請求が積み上がります。
停止ではなく削除する。 これを習慣にしてください。
ネットの情報で古くなっているもの
この記事を書くにあたって公式ドキュメントを確認したところ、日本語の情報で古くなっているものがかなりありました。
検索して出てきた記事と食い違ったときのために、まとめておきます。
| よく見る記述 | 2026年8月時点の実際 |
|---|---|
| アカウント作成から12ヶ月は無料枠が使える | 2025年7月15日以降の新規アカウントでは終了。無料/有料のアカウントプラン制に変わった |
| AWS Budgets は2つまで無料、以降は1日0.02ドル | 通知だけの予算は個数無制限で無料。課金対象はアクション付き予算とレポートのみ |
| IAM ユーザーは非推奨、Identity Center を使うべき | 方針としては正しいが、新規アカウントで有効化すると組織が作られてクレジットが即失効する。非推奨なのは IAM ユーザーそのものではなく長期のアクセスキー |
| 代替の連絡先を設定しないと重要な通知を受け取れない | ルートユーザーのアドレスには届く。代替の連絡先は宛先を「増やす」もので、個人利用では任意 |
| 左メニューの「このアカウントのブロックパブリックアクセス設定」から確認する | 「アカウントと組織の設定」の中に移動している |
| S3 はバケット名を総当たりされると高額請求のリスクがある | 2024年に修正済み。認可されないリクエストには課金されない |
| 使わないリージョンは無効化すべき | 新規アカウントではほぼやることがない（東京は無効化不可、その他は元から無効） |
情報の鮮度が特に落ちやすい領域なので、迷ったら AWS の公式ドキュメントを見るのがいちばん確実です。
正直な話：いまAWSを完全無料で学ぶのは難しいです
最後に、いちばん正直な話をします。
12ヶ月無料利用枠がなくなったことで、「1円も払わずに AWS を学ぶ」のは、以前よりかなり難しくなりました。
無料アカウントプランを選べば課金はされませんが、6ヶ月でアカウントごと閉鎖されます。
なので、私としてはこう考えるのが健全だと思っています。
もらったクレジットを、学習の教材費として使い切る。
200ドルというのは、日本円でおおよそ3万円ぶんの計算資源です。
参考書を数冊買うのと同じくらいの金額を、実際に動くインフラを触る経験に変えられると考えれば、かなり効率のいい投資です。
大事なのは、「使うこと」を怖がるのではなく、「気付かないこと」を防ぐという発想の切り替えです。
そのために設定3の予算アラートを入れました。想定外の課金には、必ず気付ける状態になっています。
消し忘れると課金が続くもの
そのうえで、消し忘れが致命傷になりやすいリソースを挙げておきます。
今後この記事のシリーズで何かを作ったときは、必ず最後に削除するところまでやってください。
| リソース | なぜ危険か |
|---|---|
| EC2 インスタンス | 起動しっぱなしだと時間課金が積み上がる。停止しても EBS の保管料金は残る |
| Elastic IP / パブリック IPv4 | 停止中のインスタンスに紐づいていても課金される |
| NAT ゲートウェイ | 何もしなくても月数十ドル規模。初心者の高額請求の代表格 |
| RDS データベース | インスタンス料金＋ストレージ料金。停止しても7日で自動再起動する |
| EBS ボリューム・スナップショット | インスタンスを消してもボリュームだけ残ることがある |
| S3 のオブジェクト | 少額だが、バケットを消さない限り永久に残り続ける |
このシリーズでリソースを作る記事には、すべて「後片付け」の手順を必ず入れます。
面倒でも飛ばさずにやってください。「作ったら消す」を最初に習慣化した人だけが、AWS を安心して学び続けられます。
よくある質問
Q. クレジットを使い切ったらどうなりますか？
A. 無料アカウントプランの場合、その時点でプランが終了し、アカウントが閉鎖されます（90日以内に有料プランへアップグレードすれば復旧できます）。有料アカウントプランの場合は、超過分が実費として請求されます。
Q. 無料アカウントプランで作ったものは、有料プランに変えたら残りますか？
A. 期限が切れる前にアップグレードすれば、そのまま使い続けられます。期限が切れたあとでも、90日以内であれば復旧できます。残っているクレジットも今後の請求に充当されます。
Q. 有料プランから無料プランに戻せますか？
A. 戻せません。 公式に明記されている一方通行の変更です。最初にどちらを選ぶかは慎重に決めてください。
Q. 支払い方法（クレジットカード）の登録は必須ですか？
A. 無料アカウントプランであっても、アカウント作成時に支払い方法の登録が必要です。登録時に有効性確認のための処理が行われますが、金額は変動する可能性があるため、ここでは具体的な数字は書きません。実際の画面表示をご確認ください。
Q. 予算アラートは何個まで作っていいですか？
A. 通知だけの予算であれば、個数の制限なく無料です。ゼロ支出予算と自分の許容額の2つを作るところから始めるのがおすすめです。
Q. 会社のアカウントでも、この設定でいいですか？
A. この記事は個人の単一アカウント向けです。組織で複数アカウントを運用する場合は、AWS Organizations と IAM Identity Center を前提にした設計が必要になります。設定5の内容は特に当てはまりません。
Q. MFA デバイスを失くしてしまいました
A. ルートユーザーのメールアドレスと登録済みの電話番号を使った復旧フローがあります。だからこそ、設定2で「メールと電話番号を最新に保つ」ことをお願いしました。どちらも失っている場合はサポートへの問い合わせが必要になり、時間がかかります。
さいごに
AWS アカウントを作った直後にやるべき初期設定を7つ紹介しました。
- 自分のアカウントプランを確認する
- ルートユーザーに MFA を設定する
- 予算アラートを作る（ついでにクレジット20ドル）
- 無料利用枠アラートとコスト異常検出を確認する
- 作業用の IAM ユーザーを作り、ルートを使うのをやめる
- S3 のブロックパブリックアクセスを確認する
- （任意）アカウントの代替の連絡先を設定する
全部やっても30分ほど、費用は0円です。
そして、やってはいけないことでいちばん大事なのはこれです。
クレジットを使い切るまで、AWS Organizations を作らない。（IAM Identity Center や Control Tower の有効化も含みます）
AWS が怖いのは、AWS が危険だからではなく、「何が起きているか分からない」からです。
気付ける仕組みを先に入れてしまえば、あとは安心して触れます。
ここまで終わったら、次はいよいよ手を動かす段階です。
このシリーズでは、開発環境の構築、AWS CLI の導入、そして実際にアプリを公開するところまでを順番に扱っていきます。
次は、Mac に Homebrew を導入します。
これ以降のツールをすべて1行で入れられるようになり、しかもその1行を AI に任せられるようになります。
シリーズの全体像と読む順番は、ロードマップにまとめてあります。
KUDs のサービス
KUDs では、実際に AWS 上で動く Web サービスを公開しています。
「AWS でこういうものが作れるのか」という参考にしていただければ嬉しいです。
ご質問やご指摘は contact@kuds.jp までお寄せください。
「ここで詰まった」という報告は、記事を良くするうえでいちばんありがたいフィードバックです。
コメント