はじめに
どうも！
いつかAWSを触ってみよう…そう思い続け早一年。えぬおかです。
この記事は、私と同じように重い腰を動かす、きっかけとなるスタートパックのような記事になるように書きました。
AWS開発のスタートラインに立てるように一緒に頑張りましょう！
ちなみに、私がAWSを触らずに1年経ってしまった理由は、クレジットカードを登録しており、かつ従量課金制であるため、青天井の請求書をみて絶望することだけは避けたかったからです。たぶん共感の嵐だと思っています。
なので、AWSアカウントを取得したらすぐすべきことをまとめてみました。
ほぼ無料で設定できるものばかりを選んでいます。
Googleで検索すれば出てくるのですが、すこし情報が古いこともありました。
わたしはこの記事を2025/04/29～2025/05/23の間に、私が実際にAWS上で実施しながら書いています。
また、私の理解や判断に必要だったリンクも載せています。
補足や誤り等あれば、ご教授いただければ幸いです。
よろしくお願いいたします。
主な参考記事
すべき設定
ルートユーザーのMFA設定
万が一、ルートユーザーのIDとパスワードが漏洩しても、MFA（多要素認証）を設定していれば、第三者による不正ログインを防ぐことができます。MFAは、ログイン時に追加の認証要素（例：スマホアプリのコード）を必要とするため、パスワードだけではログインできなくなります。
右上に表示されているユーザー名をクリックするとでるポップアップの中に"セキュリティ認証情報"のリンクがあります。
そこからMFA設定をしてください。
私は、普段使っている認証アプリケーションがあったので、それを利用してMFAデバイスとして登録しました。
なお、初回ログインから35日以内にMFA認証を登録しないと、その期間が過ぎると、登録しないとコンソールにアクセスできなくなるそうです。
ルートユーザー以外のユーザーを作る
ルートユーザーをそのまま使うのは危険
ルートユーザーが乗っ取られると大変まずいです。
なので、権限を絞ったユーザーを作成しましょう。
ユーザーの作成
上記のサイトを見ながら作業していきました。
現在は、IAMからユーザーを作成するよりIAM Identity CenterからIAMユーザーを作成することを推奨されているようです。よりセキュアにアカウントを管理・運用できるようです。
IAMからユーザーを作成しようとすると、
よくわからない２択があります。
私は推奨であるAWS Identity Centerを使うことにしました。
安心してください、AWS Identity Centerは無料です。
下記の項に詳細を記載。
補足 ユーザーは２種類あり、区別される
推奨されているAWS Identity Centerで作成するIdentity Centerユーザーと２つ目の選択肢のIAMで作るIAMユーザーは違うものです。
初心者・個人開発・手軽に使いたい → IAMユーザーがおすすめ
- 簡単に始められる
- CLI・SDK利用における再認証の手間がほぼないため気軽に使える
- 個人開発や少人数チームでは十分
セキュリティを重視・企業内・複数アカウントで開発 → AWS Identity Centerユーザーがおすすめ
- セキュリティが高い
- CLI・SDK利用における再認証は若干手間だが、企業では推奨される運用
になります。
よりセキュアなのがIdentity Centerユーザーといった感じだそうです。
私は長い物には巻かれろタイプなので、Identity Centerユーザーを作成しました。
リージョン選択
もしあなたがIAMではなく、AWS Identity Centerを選択した場合、使い始めるときに、リージョンを決める必要があります。
（IAMはグローバルサービスで、リージョン共通。）
上から設定しておくと、ここで初めてリージョンを意識させられます。
私は、西日本に住んでいますが、東京リージョンを選択しました。
- 新サービスの優先度が大阪より東京が高い
- 使用できるサービスが東京の方が大阪より豊富
といった理由です。
大阪リージョンは地理的に近く東京より低レイテンシーでアクセスできそうですが、そんなに重視するポイントじゃないと判断しました。（私にとって誤差です）
パスワードポリシーを設定しよう
個人で使う分には、設定の必要はないかもしれませんが、念のため設定しておきましょう。
なんのために設定するかというと、今後作成するIAMユーザーに設定するパスワードの強さを担保するためです。
パスワードの設定時に、覚えやすいからと言って"aaaa"にしたり、"`PassW@rd"にしたりすると一瞬で破られてしまいます。
なので、簡単には攻撃者に突破されないようなパスワードを設定しましょう。
（後に紹介するMFA設定もしているとしても、念のために…）
デフォルトのパスワードポリシーは、下記の通りです。
これでも十分かと思いきや、そうでもありません。
AWS Security HubのAWS Identity and Access Management (IAM) コントロールのセキュリティ標準によると、
- 大文字
- 小文字
- 数字
- 英数字以外の文字
すべてを使うことが推奨されています。特に「英数字以外の文字」が条件として加わることでパスワードの強度が飛躍的に高まります。
余談ですが、複雑なパスワードに設定しても他サービスと使いまわしでは意味がありません。
パスワードマネージャーを使用してください。複雑なマスターキーを1つ覚えるだけで複雑なパスワードを自動で生成・管理できます。
※AWS Identity Centerでユーザーを作成した場合、パスワードポリシーはデフォルトで設定されているので、設定する必要はありません。(参考)
MFA設定
AWS Identity CenterでIAMユーザーを作成すると、紐づけたメールアドレスにパスワード設定のメールが届きます。
設定後、流れるようにMFA設定を行う画面が表示されました。
そこで、先ほど設定した"ルートユーザーのMFA設定"と同様設定してください。
権限設定
このままコンソールにアクセスしても、適切な権限が設定されていないので何も表示されません。
ルートユーザーから所属グループやユーザーに適切な権限を設定しましょう。
以下の解説は、AWS Identity Centerの場合です。
参考にした記事
私はAWS Identity Centerからユーザーを作成したので、
AWS Identity Centerのグループからご自身の目的にあった許可セットを作成しましょう。
ステップ1：Identity Centerで「グループ」を作る（任意）
グループを作成し、そこに先ほど作成したAWS Identity Centerユーザーを紐づけてください。このグループに所属しているユーザーに対して、まとめて同じ権限を付与することができます。
ステップ2：Identity Centerで「許可セット」を作る
ここでどの許可セットを選べばええねん。って思いますよね。
ベストプラクティスでは最小限の特権を詳細設定したほうが望ましいです。
管理者権限を付与するか、AWSが事前に定義している許可セットからざっくり権限を付与するか、カスタム許可セットを作成し権限を細かく設定するか。
どれを選択するかはセキュリティと利便性のバランスを見て判断してください。
私は、しばらくいろいろ触ってみたいので、初めのうちはAdministratorAccessで設定し、使いたい機能が絞れた時に、改めて権限を絞る作戦です。
作成したユーザにAdministratorAccessを付与することに対する補足
ルートユーザーでアクセスするのが危険ということで、ユーザーを作ったのに結局そのユーザーにAdministratorAccessを与えたら、あんまり意味ないんじゃない？
って思いませんか。私は思いました。
調べてみると、
- 支払い情報の変更
- アカウントの閉鎖
などの特定の操作はルートユーザーにしかできないそうです。
ルートユーザーとIAMユーザー（Admin）は同じに見えて、全然違うんですね。
ルートユーザーは「アカウントの持ち主本人」。このユーザーの認証情報が漏れたら、アカウントそのものが乗っ取られるレベルのリスクです。
IAMユーザーは、たとえAdmin権限があっても「権限を与えられた存在」にすぎず、制御可能・削除可能・救済可能です。
AWSでは、ルートユーザーは鍵付きの金庫にしまっておいて、普段は使わないのが正解。
だから、AdministratorAccess付きのIAMユーザーにもちゃんと意味があるんですね。
の記事には、
AWSルートユーザーの権限は全サービスにアクセスできる「神の権限」で、悪意のあるユーザーが不正にアクセスした場合、深刻なセキュリティ事故が発生するリスクがあります。
不要なログインやアクセスを防ぐことが重要です。
と書かれています。
「神の権限」 を振りかざしたい気持ちはやまやまですが、悪用され莫大な金額を請求されるのが恐ろしいので控えます。
ステップ3：ユーザーまたはグループに許可セットを割り当てる
- AWS Identity Centerのコンソールへログイン
- 左メニューから 「AWSアカウント」 をクリック
- アカウントを選択し、「ユーザーまたはグループの割り当て」をクリック
- 作成したIdentity Centerユーザーを選択（個人ユーザー or グループを選択）
- さきほど作成した 許可セットを選択（AdministratorAccessなど）
- 「割り当て」をクリックし完了
この操作を行うことで、初めて作成したユーザーがAWSアカウントへアクセス可能になります。
作成したユーザのログイン方法の違い。
ルートユーザーまたはIAMユーザーの場合
https://aws.amazon.com/console/
からログインできます。
それに対し、Identity Centerユーザーは専用のログインページを使います。
https://<IdentityCenter-ID>.awsapps.com/start
<IdentityCenter-ID>は、AWS Identity Center を初期設定したときに発行されるID。
管理者がこのURLをユーザーに共有する必要があります。
このURLは、ルートユーザーでユーザーを作成した後にその作成したユーザーで登録したメールアドレスに届いていまし
このページで、Identity Centerユーザー（＝メールアドレスとパスワード）でログインします。
作成したIAMユーザーの請求情報へのアクセス許可設定💰
右上に表示されている自身のユーザー名をクリックしてください。
表示されるポップアップの中に「アカウント」があります。クリックしましょう。
遷移後のページで少しスクロールすると、
「IAM ユーザーおよびロールによる請求情報へのアクセス 」があります。
↓
更新を押すと、無事「有効化済み」になりました。
これで作成したIAMユーザーからでも請求金額が確認できるようになりました。
安心です。
予算を超えた時のアラートを設定する💰
無料枠で遊ぼうと思って触ってみたものの、しばらく放置していると
AWSから請求が来てる！！😱
みたいな話、結構あるあるだと思います。
冒頭でも述べた通り、AWSは従量課金制です。使えば使うほど高額な支払いをすることになります。
ガソリンを入れるときは、メーターで何リットル入れて、いくらかかっているかすぐに分かります。
しかしクラウドは、何にどのくらい使っているか実感がないです。
予想以上の請求を避けるためにも、請求設定 (Billing)と予算(AWS Budgets)の設定をしましょう！
Billing and Cost Managemantの中に請求設定 (Billing)と予算(AWS Budgets)があるようです。
請求設定 (Billing)
請求設定 (Billing)は、請求情報の閲覧・管理を目的としたサービスです。
主に、このサービズで設定しておくべきことは、
- PDF 請求書を E メールで受け取る
- AWS 無料利用枠アラート
の2つです。
Billing and Cost Managemantにアクセスし、左のサイドバーの下の方に「請求設定」があります。
そこにアクセスすると、
お目当ての設定項目がありました。
- 「請求書の送信設定」の項目で、「PDF 請求書を E メールで配信」を有効化しました
- 「アラート設定」の項目で「AWS 無料利用枠アラート」が設定されているか確認しましょう
2番目に関して、デフォルトでルートユーザーの E メールアドレスが設定されていました。
またCloudWatch 請求アラートに関して、参考にしたサイトには
次項の AWS Budgets で代替できるため 予算額を超えたときのCloudWatch 請求アラートは無効で大丈夫です
とありました。
CloudWatch 請求アラートとAWS Budgetsの違いを調べてみました。
十分に AWS Budgetsで代替可能かつCloudWatch 請求アラートより設定が楽と判断しました。
なので、私は、ここではCloudWatch 請求アラートを設定しないことにしました。
予算(AWS Budgets)
ここでは予算額を超えたらメールが来るように設定します。
AWS Budgetsへ遷移し、「予算の作成」をクリックします。
この記事を参考に設定しています。
私は初心者なので、テンプレートを使います。
選ぶテンプレートに関しても、先ほど「CloudWatch 請求アラート」で無料枠のアラートを設定したので、月次コスト予算を選んでいます。
ここで選択したテンプレートに名前を付け、予算を設定しましょう。また予算を超えた時のメールアドレスもここで設定します。
デフォルトでは100ドル（現在のレートで約15,000円）です。
私はケチなので、10ドルに設定しました。
また、メールアドレスもコンマ区切りで複数指定できるようです。
メールを見逃すのが怖いので、2つ設定しました。
予算の85％に達した時、100％に達した時の2回アラートがメールで送られるようです。
なんという親切設計でしょうか。ありがとうございます。
比較表
| 比較項目 | 請求コンソール（Billing） | AWS Budgets |
|---|---|---|
| 目的 | 請求情報の閲覧・管理 | 予算の設定・通知 |
| 通知の有無 | *1 基本的に通知なし（課金状況を確認するだけ） | 通知あり（しきい値超過時にメールなど） |
| 主な機能 | 支払い方法の管理、請求書の表示、課金履歴の閲覧など | 使用量やコストの予算を設定し、超えたら通知 |
| 通知のタイミング | なし（自分で見る） | しきい値に応じてリアルタイムまたは定期通知 |
| 精度 | 実際に確定した料金（正確） | 概算コスト・推定コスト（タイムラグあり） |
| 設定できる予算 | ❌ 不可 | ✅ 可（例：月1,000円超えたら通知） |
*1「請求コンソール（Billing Console）」自体には通知機能はありませんが、「無料利用枠の超過アラート」は、CloudWatch＋Billingの仕組みを使って通知される特別なケースだそうです。
最低限のログを収集できるようにする
CloudTrail証跡の作成
この記事を参考に設定しました。
注意！お金が少しかかります。
この記事にも書かれている通り、管理イベントが1つだけであれば、無料です。
しかし、ログの保存先のS3で保存料金がかかります。有料です。
S3標準ストレージ料金（東京リージョンの場合）
| 保管容量 | 月額の目安 |
|---|---|
| 最初の50TB | 約 $0.025 / GB（≒約3.9円/GB） |
| 例えば1GBなら | 約4円/月 |
CloudTrailのログ量の目安（通常利用）であれば、
-
小規模な個人開発であれば、月数MB〜数百MB程度
⇒ 数円〜十数円/月程度
これは、ほぼ無料と言っていいほど安いですね。
📝 CloudTrailってなに？
CloudTrail は、AWS アカウント内で「誰が・いつ・どの AWS API を呼び出したか」を記録してくれる監査用のサービスです。
たとえばこんな操作が記録されます：
- EC2インスタンスを起動・削除した
- S3のバケットを作成・削除した
- IAMポリシーを変更した
- Lambda関数を実行した
つまり、「AWS リソースに対する操作の履歴」が時系列で残るということです。
なぜ必要か？
仕事でトラブルが起きたとき、まず見るのは「何が起きたかの証拠」、つまりログです。
「誰がいつ、なにを操作したか」がわかることで、次のような場面に役立ちます：
- 意図しないリソース削除があったときに、誰が操作したかを追跡
- セキュリティ的に問題のある操作（たとえば全公開のS3バケット作成）を発見
- チーム開発中のトラブル調査において、何かしらの手順漏れやミスを特定
CloudTrail を設定していないと、そのときに追うべきログ（操作履歴）がなく、原因調査が困難になります。暗中模索です。
自分のあいまいな記憶を信じずログを信じましょう。
記憶より記録。ログは絶対です。
設定
とっても簡単に作成することができました。
S3バケットも同時に作成してくれました。
参考にした記事には、SSE-KMSでログを暗号化するオプションの説明もありました。
私はしませんでした。
転ばぬ先の杖の杖ですね。これで安心です。
実際にログの設定をしてから、1日ごとにまとまって整理されほぞんされていｍ。
Amazon S3 パブリックアクセスブロック設定有効化
なぜ必要？
AWSを本格的に使っていくと、必ずと言っていいほど登場するサービスが Amazon S3（Simple Storage Service） です。
S3は画像、ログ、HTMLファイルなど、さまざまなデータを格納できる非常に便利なサービスです。
ただし、S3の公開設定には注意が必要です。
IAMポリシーやバケットポリシー、アクセスコントロールリスト（ACL）の設定次第で、誰でもアクセス可能な状態にしてしまうことができます。
つまり、操作ミスによって意図せず全世界に公開してしまうリスクがあるのです。
参考:
「Amazon S3」内のデータが設定ミスで公開状態に 漏えいしたデータは？
プライベートデータが誤って全世界に公開されないためにも、Amazon S3のパブリックアクセスブロック設定有効化をしましょう。
アカウントレベルで、S3へのパブリックアクセスを防ぐことができます。
設定方法
S3の「このアカウントのブロックパブリックアクセス設定」から設定できます。
「パブリックアクセスをすべて ブロック」にチェックを入れて変更を保存しましょう。
バケットを公開したくなったら
先ほど設定したパブリックアクセスブロック設定を解除する必要があります。
公開したいタイミングで、
- パブリックアクセスブロック
- バケットポリシー
- アクセスコントロールリスト
について学習したうえで、パブリックアクセスブロックを解除すると安心です。
ただし、例外としてパブリックアクセスブロックをしていてもCloudFront + オリジンアクセスコントロール（OAC）でS3の静的サイトの公開したり、署名付きURLによる一時公開をしたりすることは可能です。
まとめ
以上になります。
ここまで設定をされた方お疲れ様でした！！
ここまで設定を終えると、AWSを使うスタートラインに安心して立てる気がしますね。
ここから走り出しましょう！
今後の私の野望としては、
- 過去に作成したポートフォリオサイト・webアプリをAWS上に移管して改良していきたい
- 新しいWebアプリをLambda,API Gateway,Dynamo DBで作ってみたい
といった感じです。
もしこの記事に誤りや、不足、アドバイスなどあればコメントや編集リクエスト等いただけると嬉しいです。
よろしくお願いいたします。