先に要点
- AWSで最初に必ずやるべきなのは、rootユーザーを普段使いしない前提を作ることです。MFA、強いパスワード、回復手段の管理を最優先で入れます。2024年5月以降、AWSはroot MFAを段階的に必須化しており、2025年6月17日からは組織内メンバーアカウントのrootにもコンソールサインインから35日以内のMFA設定が求められます。
- 次に、人間の入口を整理し、権限を最小化し、監査ログを残すことが大事です。具体的には IAM、CloudTrail、一時認証情報中心の運用です。人間の入口は IAM Identity Center に寄せるのが今の流れですが、移行には固有のハマりどころがあります。
- 請求アラートや予算管理は後回しにしない方がいいです。立てっぱなしのNAT Gatewayや公開設定ミスのS3で、検証環境でも月3万円〜数十万円の請求が現実に発生します。
- 1サービスずつ覚えるより、入口、権限、監査、コスト、バックアップの5本柱で最初に守りを作る方が、あとで崩れにくいです。未使用リージョンの無効化もこの段階で考えます。
「AWSって何から設定すればいいの？」「とりあえずEC2を立てれば始められる？」「最初に忘れると危ないものは何？」という疑問はかなり自然です。
実際、AWSはできることが多いぶん、最初に「何を立てるか」より「何を先に守るか」を決めておかないと、あとで運用が崩れやすくなります。
この記事では、2026年6月時点のAWS公式ベストプラクティスをもとに、AWSで最初に必ずやるべきことを整理します。一般論だけでなく、実際に請求事故が起きるパターンや、未使用リージョン無効化・IAM Identity Center移行で詰まりやすい点まで踏み込みます。
個別のサービス用語から先に押さえたい場合は、AWSで最初に覚えたい基本用語まとめ｜EC2・IAM・S3・VPCのつながりを整理 もつながります。
まず結論
AWSで最初にやるべきことは、サービスを増やす前に次の土台を作ることです。
この順で考えると、あとからEC2、RDS、S3、Lambdaを増やしてもだいぶ安定します。
1. rootユーザーを普段使いしない
AWS公式では、アカウント作成直後から rootユーザーを日常作業に使わない ことが強く勧められています。
rootユーザーは、
- すべてのサービスに無制限アクセス
- 請求情報も含めた完全権限
- アカウント解約など一部の特別操作も可能
という最強権限です。
だからこそ、「便利だからこれで全部やる」ではなく、普段は触らない 状態にするのが最初の基本です。
最低限やること
- rootパスワードを強くする
- rootに MFA を入れる
- rootの回復用メールと電話番号の管理を決める
- rootアクセスキーは作らない(作ってあるなら削除する)
root MFAはもう「任意」ではない
ここは時系列を押さえておくと判断しやすいです。AWSはroot MFAを段階的に必須化してきました。
| 時期 | 対象 | 内容 |
|---|---|---|
| 2024年5月〜 | 管理アカウント(大規模アカウントから順次)のroot | マネジメントコンソールへのサインインにMFAを必須化 |
| 2024年6月〜 | 全アカウント | FIDO2パスキーをMFA手段として追加 |
| 2025年6月17日〜 | Organizations内メンバーアカウントのroot | コンソールサインインから35日以内にMFA未設定だとサインインがブロックされる |
公式によれば、root MFAの導入でパスワード関連の攻撃の99%超を緩和できたとされています。つまりこの設定は「あとでやる」ではなく、最初に終わらせる前提で考えるべきものです。特に複数アカウントを将来持つ予定なら、Organizationsの「集中 root アクセス管理(centralized root access)」を使うと、メンバーアカウント側のroot資格情報そのものを無効化でき、35日ルールに各アカウントで個別対応する手間も消えます。
2. 管理者作業の入口をrootから分ける
rootを使わないと言っても、では誰がAWSを触るのか、という話になります。
AWS公式では、rootの代わりに管理者用の入口を作ることが勧められています。
最近のベストプラクティスでは、人間ユーザーの入口は IAM Identity Center(旧 AWS SSO)を中心に考える流れがかなり自然です。
ここで大事なのは、「とりあえずIAMユーザーを人数分作る」だけで終わらないことです。IAMユーザーは長期パスワードとアクセスキーが残りがちで、退職者対応やキーローテーションが重くなります。Identity Centerなら、SSOで入って必要なときだけ一時認証情報を発行する形に寄せられます。
IAM Identity Center移行でハマりやすい点
「公式が勧めるから」と勢いで移行すると、次のような落とし穴があります。実際に運用判断が必要になるのはこのあたりです。
プライマリリージョンが固定される
Identity Centerのインスタンスは最初に有効化したリージョンが「プライマリ」になり、後から別リージョンへ移すには一度インスタンスを削除して作り直す必要があります。東京で使うつもりが、テストでバージニア(us-east-1)で有効化してしまい、本番前に全部やり直す、という事故が起きやすいです。最初に「どのリージョンで有効化するか」を意識して決めてください。
SCPで自分を締め出す
後述の未使用リージョン無効化SCPを先に張ると、Identity Centerが内部で使うグローバルエンドポイント(us-east-1)が拒否され、SSOログイン自体が通らなくなることがあります。リージョン制限SCPには Identity Center / IAM / STS など必要なグローバルサービスを必ず例外(NotAction)に入れます。
IAMユーザーとの二重管理
移行途中で「Identity Centerの権限セット」と「旧IAMユーザーのポリシー」が両方生きていると、どちらで入ったかで権限が変わり監査が濁ります。移行したらIAMユーザー側のコンソールパスワードとアクセスキーは早めに無効化し、入口を一本化します。
このあたりの土台になるのが IAM です。
詳しくは IAMとは？AWSでユーザー・グループ・ロール・ポリシーをどう使い分けるのか でも整理しています。
3. AdministratorAccess を配りすぎない
AWSを始めたばかりだと、何でも触れる方が早いので、つい広い権限を配りがちです。
でも公式のIAMベストプラクティスでも、最小権限(least privilege) が強く勧められています。
最初に意識したいこと
- 人間の常用入口は一時認証情報中心
- ワークロードはロール中心
- 長期アクセスキーは必要最小限
- 権限は広く配って固定しない
特に、「ひとまず全員管理者」のまま運用が伸びると、あとで誰の操作か分からなくなったり、事故の範囲が大きくなったりします。
最初は多少面倒でも、読むだけ、デプロイだけ、監査だけ のように分けていく方が後が楽です。
4. CloudTrailを見える状態にする
AWSで最初にやるべきこととして、CloudTrail はかなり重要です。
理由はシンプルで、AWSでは「誰が何をしたか」を後から追えることが運用の土台になるからです。
たとえば、
- 誰がIAMポリシーを変えたか
- 誰がEC2を止めたか
- 誰のロールで設定変更が走ったか
を追いたいとき、CloudTrailが入口になります。
ここで誤解しやすい点
CloudTrailは便利ですが、「有効にしたら全部を永久保存してくれる」わけではありません。コンソールの「イベント履歴」は直近90日分のみで、しかも管理イベント中心です。長期保存や全リージョン横断の記録が欲しいなら、自分でS3バケットに出力する 証跡(Trail) を作る必要があります。AWS公式でも、Trail、保存先設計、暗号化(SSE-KMS)、ログファイル検証、バケットの削除保護まで含めて考えることが勧められています。
そのため、AWSを複数人で触るなら、CloudTrailは「あとで考える監査」ではなく、最初に敷くべき操作履歴 と考えた方がいいです。
詳しくは CloudTrailとは？AWSで誰が何をしたか追う監査ログの基本 で整理しています。
5. コストの見張りを入れる ― 高額請求は「検証中」に起きる
AWSの高額請求は本番の大規模構成より、むしろ「検証中・放置中」に起きます。「まだ本番じゃないから大丈夫」が一番危ない発想です。よくある2つを、現象→原因→確認→回避の形で具体化します。
シナリオA:NAT Gatewayの立てっぱなし
原因
VPCウィザードやチュートリアル通りに作ると、プライベートサブネットからの通信用にNAT Gatewayが自動で立つことがあります。NAT Gatewayは無料枠がなく、東京リージョンで約 $0.045/時(=月およそ32〜33ドル、1ドル150円なら約5,000円)に加え、処理データ1GBあたり約 $0.045〜0.062 がかかります。トラフィックが無くても、立っているだけで時間課金が走り続けます。高可用性で3つのAZに置くと、アイドルでも月100ドル近くになります。
確認手順
Cost Explorerで「サービス別」→「Usage Type」で NatGateway-Hours / NatGateway-Bytes を確認。VPCコンソールの「NATゲートウェイ」一覧で、検証用VPCに残っていないかを見る。
回避
検証で外向き通信が不要なら、そもそもNAT Gatewayを置かない。必要でも、検証が終わったら必ず削除する。S3など一部のサービスはVPCエンドポイント(Gateway型は無料)で代替できる。停止ルールを最初に決めておく。
シナリオB:S3の公開・データ転送による予想外請求
現象
静的ファイルを置いただけのS3バケットなのに、月の請求が突然数万円〜数十万円に跳ね上がる。明細は「DataTransfer-Out」やリクエスト課金が支配的。
原因
バケットやオブジェクトを誤って公開し、URLが拡散して大量ダウンロードされた、あるいは外部からの大量GETを受けた。S3はインターネット向けのデータ転送(おおむね最初の数十TBが1GBあたり約0.114ドル前後、東京)とリクエスト数で課金されます。1ファイルが大きく拡散すると、転送量だけで一気に積み上がります。
確認手順
S3コンソールの各バケットで「アクセス許可」→ブロックパブリックアクセスがオンか確認。Cost Explorerで DataTransfer-Out-Bytes と Requests-Tier1/2 の急増を見る。配信が必要なら CDN(CloudFront)経由かどうかも確認。
回避
アカウント全体で「ブロックパブリックアクセス」を有効にしておく(新規バケットは既定でオン)。公開配信はS3直リンクではなくCloudFront経由にし、予算アラートで早期に気づける状態を作る。
AWS公式のBudgetsベストプラクティスでも、予算の期間を請求サイクルに合わせることや、実績だけでなく予測(forecast)を含めて早めに見ることが勧められています。
最低限の設定
- 月額の上限目安を決める(個人開発でも、たとえば月100ドル超でアラート)
- AWS Budgetsで 80% / 100% / 120% のしきい値通知を入れる
- 誰に通知するか(メール/SNS)を決める
- 検証環境の停止・削除ルールを決める
この4つだけでも、上の2シナリオはかなり防げます。
6. 未使用リージョンを無効化して誤操作を減らす
AWSは既定で多数のリージョンが有効です。使うつもりのないリージョンにリソースが作られると、見落とした課金や、地理的に意図しない場所へのデータ配置につながります。そこで 未使用リージョンの無効化 を初期に検討します。
判断のポイントは「アカウント単体か、Organizations配下か」です。
| 構成 | やり方 | 注意点 |
|---|---|---|
| 単体アカウント | アカウント設定の「リージョン」で、デフォルト無効リージョンを「無効化」のまま使わない。一部リージョンは個別に有効/無効を切り替えられる | us-east-1など一部の基盤リージョンは無効化できない。グローバルサービスがここに依存する |
| Organizations配下 | SCP(サービスコントロールポリシー)で、許可リージョン以外のAPI呼び出しをDenyする | SCPはIAMポリシーで上書きできず、root権限でも回避できない。だからこそ設定ミスの影響が大きい |
ハマりどころ:グローバルサービスのus-east-1依存
リージョン制限SCPで一番やりがちな事故が、IAM・STS・CloudFront・Route 53・組織管理・IAM Identity Centerといったグローバルサービスまで巻き込んで拒否してしまうことです。これらのエンドポイントは物理的にus-east-1にホストされているため、aws:RequestedRegion で許可リージョンを東京だけに絞ると、これらの操作が一斉に通らなくなります。
回避策は、Deny条件の NotAction にグローバルサービスのアクションを列挙して例外化することです。AWS公式のサンプルSCPがありますが、サンプルは最新の全グローバルサービスを網羅していないので、自組織で使うサービスに合わせて足してください。SCPはroot権限でも回避できない性質上、本番アカウントにいきなり張らず、まずテスト用アカウントで検証してから展開するのが鉄則です。
なお、IAM Identity Center自体の追加リージョン削除は「プライマリリージョンから」しか実行できません(aws sso-admin remove-region)。プライマリ自体は削除できないので、リージョン構成は前章の通り最初の有効化時点で決めておきます。
7. バックアップと復旧を後回しにしない
AWSはクラウドなので安心、と思われがちですが、バックアップ設計は別で必要です。
たとえば、
のように、サービスごとに守り方が違います。
特に実務では、「壊れない」より「壊れても戻せる」の方が重要です。さらに、誤操作や権限を持った内部からの削除に備え、削除を物理的に止める仕組み(S3のオブジェクトロック、AWS Backupのボールトロック)も検討します。AWSを触り始めたら、構築と同時にバックアップと復旧手順を考えておく方が安全です。
8. 複数アカウントの前提を早めに持つ
1人で小さく始める間は、1アカウントでも回せます。
ただ、AWS公式では、チーム運用や環境分離では複数アカウント戦略がかなり重要視されています。
ここで言いたいのは、いきなり大規模構成にしよう、という話ではありません。
むしろ最初の段階で、
- 本番と検証は分けた方がいい
- 請求を分けたい場面がある
- 権限や監査を分けたい場面がある
という発想を持っておくのが大事です。
小さなうちは1アカウントでも、「いずれ分ける前提」で命名、タグ、権限、ログの置き方を決めておくと後から苦しくなりにくいです。 この「後から苦しくなる」の中身をもう少し具体的に見るなら、AWSを1アカウントで運用し続けると何がつらいのか で、権限、請求、監査、クォータ、障害影響の観点から整理しています。
9. タグと命名を先に決める
意外と効くのがこれです。
AWSはリソースが増えると、
- どれが本番か
- どれが検証か
- 誰のものか
- 消していいのか
が分からなくなりやすいです。
だから最初に、
- 環境名(env: prod / dev)
- 所有者(owner)
- 用途(purpose)
- コスト配賦用のタグ(コスト配分タグとして有効化)
を決めておくと、あとでかなり助かります。特にコスト配分タグを有効化しておくと、前章のNAT GatewayやS3の請求を「どの環境のものか」で切り分けられ、原因特定が一気に速くなります。
じゃあ最初のチェックリストは何か
迷ったら、まずこの順でやるのがおすすめです。
これだけでも、AWSの初期運用はかなり崩れにくくなります。
2026年6月時点の整理
最新のAWS公式情報を踏まえると、今の「AWSで必ずやるべきこと」は、サービス個別の設定より前に
をそろえることです。
EC2を立てる、RDSを作る、S3を使う、Lambdaを書くのはそのあとでも間に合います。 最初の守りを先に作っておく方が、結果的にずっと速いです。
AWSアカウント初期設定に関するよくある質問
Q. まず最初にやることは？
A. 「rootのMFA設定」「管理者入口の用意(IAM Identity Centerまたは管理者IAMロール)」「rootを平時使わない方針」「CloudTrailのTrail有効化」「Budgetsの予算アラート設定」「未使用リージョンの無効化」です。root MFAは2024年以降必須化が進んでいるので、最優先で終わらせます。
Q. 個人開発でもここまで必要？
A. 必要です。アカウント侵害時の被害が大きいうえ、設定ミスの放置でも請求事故が起きます。NAT Gateway放置で月3万円、S3公開で数十万円といったケースは個人でも珍しくありません。最低でも「MFA + 最小権限 + 予算アラート」の3点は入れてください。
Q. NAT Gatewayの請求が高いのですが、すぐ消していい？
A. 検証で外向き通信が要らないなら消して問題ありません。本番でプライベートサブネットからの通信が必要な場合だけ残します。S3やDynamoDBへの通信はGateway型VPCエンドポイント(無料)で代替でき、NAT経由を減らせます。
Q. 予算アラートはどう設定する？
A. AWS Budgetsで月額予算を作り、80% / 100% / 120%のしきい値でメールまたはSNS通知を設定します。実績だけでなく予測(forecast)ベースの通知も入れると、月初の急増に早く気づけます。1日10ドル目安の個人開発でも「月100ドル超でアラート」を入れておくと安心です。
Q. 未使用リージョンの無効化でハマる点は？
A. SCPでリージョンを絞るとき、IAM・STS・CloudFront・Route 53・IAM Identity Centerなどのグローバルサービスはus-east-1にホストされているため、これらを NotAction で例外にしないと操作が一斉に止まります。SCPはroot権限でも回避できないので、必ずテスト用アカウントで検証してから本番へ展開してください。
Q. IAM Identity Centerはいつ・どう入れる？
A. 人間ユーザーが2人以上になる、または本番/検証を分け始めたタイミングが目安です。注意点として、最初に有効化したリージョンがプライマリとして固定され、後から変えるにはインスタンスの作り直しが必要です。テストで誤ってus-east-1で有効化しないよう、運用リージョン(東京など)を決めてから有効化します。
Q. リージョンはどこを選ぶ？
A. 日本国内利用なら東京(ap-northeast-1)が基本です。グローバル展開時はバージニア(us-east-1)も主要候補になります。使わないリージョンはSCPまたはアカウント設定で無効化し、誤操作とリソース散乱を防ぎます。
Q. 個人プロジェクトを終わらせるときは？
A. リソース棚卸し→不要リソース全削除(特にNAT Gateway、Elastic IP、EBS、ロードバランサーなど時間課金系)→Cost ExplorerとTrailで残存が無いか確認→1〜2週間様子見→必要ならアカウント閉鎖、の流れです。「削除し忘れ」が翌月の高額請求になりがちなので、時間課金系から消します。
まとめ
AWSで必ずやるべきことは、「まず何のサービスを使うか」を決めることではありません。
それより先に、入口、権限、監査、コスト、復旧 の土台を作ることです。
特に最初の一歩としては、
- rootを守る(MFAは必須化の流れ)
- 管理者入口をIAM Identity Centerに寄せる
- IAM を雑にしない
- CloudTrail を見る
- 予算アラートを入れ、NAT・S3公開を点検する
この5つを先に終わらせるだけでも、かなり違います。
この記事のあとに一緒に読みたい
- IAMとは？AWSでユーザー・グループ・ロール・ポリシーをどう使い分けるのか
- CloudTrailとは？AWSで誰が何をしたか追う監査ログの基本
- AWSで最初に覚えたい基本用語まとめ｜EC2・IAM・S3・VPCのつながりを整理
参考リンク
- AWS Account Management: Using the AWS account root user
- AWS IAM: Root user best practices for your AWS account
- AWS What's New: AWS IAM now enforces MFA for root users across all account types
- AWS Security Blog: Secure root user access for member accounts in AWS Organizations
- AWS Account Management: Enable or disable AWS Regions in your account
- AWS Organizations: General SCP examples (deny access based on requested Region)
- Amazon VPC Pricing: NAT Gateway pricing
- AWS Cost Management: Best practices for AWS Budgets
- AWS CloudTrail: Security best practices in AWS CloudTrail
- AWS Organizations: Best practices for a multi-account environment