AWSの始め方

お仕事でAWSはよく使うのですが、最初からAWSアカウントを作って環境構築したことはなかったので、やり方をまとめてみました。
とくに最低限やっておいた方が良いと自分が思ったものについて記載します。

本記事内容は最新状況と一致しているとは限りません。
必ず公式情報をチェックし、自身の責任で設定してください。

1. AWSアカウント開設方法

1.1. アカウント作成に必要なもの

• メールアドレス
• 電話番号 (アカウント認証に使用する)
• クレジットカードまたはデビットカード (料金の支払いに利用する)

1.2. アカウント開設手順

まず、AWSのサインアップページにアクセス
※AWSのトップページ などからサインアップのリンクで遷移しても良い

1. ルートアカウント用のメールアドレスを入力
2. アカウント名を入力 (開設後に変更可能)
3. メールアドレス検証コードを入力
   ※前手順で入力したメールアドレスに届く
4. ルートアカウント用のパスワードを入力
5. 連絡先情報(氏名、住所、電話番号など)を入力
6. 請求情報(クレジットカード番号など)を入力
7. 本人確認検証コードを入力
   ※検証コードはSMSまたは電話(自動音声)で届く
8. サポートプランを選択

手順の公式情報は以下。

2. AWSアカウント開設したらまず最初にやること

個人の勉強、検証用途でのAWS利用を想定してピックアップしました。
レベルについては筆者個人の判断です。
商用サービスレベルでのセキュリティ・運用サービスの検討は要件に沿って行いましょう。

レベル	内容
M (must)	必ずやるべき
S (should)	特に理由がなければやるべき
O (optional)	任意

料金	内容
F	無料
F+	基本無料(オプションで有料)
Pf	そのサービス自体は無料だが、連携サービスが有料
P-	有料だが安価
P	有料

2.1. やること一覧

2.1.1. アカウント設定

サービス	内容	レベル	料金
アカウント	ルートユーザーでサインインできるか確認	M	F
アカウント	代替の連絡先設定	O	F
アカウント	秘密の質問設定	O	F
設定	ルートユーザーの言語・リージョン設定	S	F

2.1.2. 料金

サービス	内容	レベル	料金
アカウント	IAMユーザー/ロールによる請求情報へのアクセス設定	S	F
Billing	請求書PDFの受領 billing>請求設定>請求書の送信設定	S	F
Billing	請求アラート設定 billing>請求設定>CloudWatch 請求アラート 🚨一度有効化すると無効化できないので注意。 予算アラートで代替可能	O	Pf
Budgets	予算アラート設定 予算を元に実際のコストと予測コストを監視する 閾値を超えた際の通知までは無料 追加のアクションは有料	S	F+

2.1.3. セキュリティ

サービス	内容	レベル	料金
IAM	ルートユーザーにアクセスキーがないことを確認	M	F
IAM	パスワードポリシー設定	M	F
IAM	ルートユーザーのMFA設定	M	F
IAM	ユーザー/グループ作成	M	F
IAM	ユーザーへのMFA設定強制	S	F
IAM	アカウントエイリアスの作成	O	F
IAM	ユーザーアクセスのIPアドレス制限	S	F
GuardDuty	有効化 GuardDuty は脅威検知サービス。 AWS のイベントログなどを監視し、不審なアクセスを検知してくれる。	O	P
Inspector	有効化 Inspector は脆弱性検知サービス。 EC2 インスタンス, ECR のコンテナイメージ, Lambda 関数を対象にアプリケーションで使用されるパッケージの脆弱性を検出してくれる。	O	P
Security Hub	有効化 AWSのセキュリティ系検知イベントを集約し、一覧表示できる。	O	P-
Detective	有効化 Detective はセキュリティ系検知イベントの調査・分析が簡単にできるサービス。	O	P

2.1.4. モニタリング

サービス	内容	レベル	料金
CloudTrail	証跡の作成 ※CloudTrail は AWS アカウント内の IAM ユーザーのアクティビティや API 呼び出しの履歴を記録するサービス イベント履歴は直近 90 日間無料で閲覧可能だが、証跡を作成するとS3に転送されるので、S3への配信や保管に料金がかかる。	O	P
Config	有効化 ※Config は AWS リソースの変更を記録し、そのリソースの状態が予め定めたルールに合致するか監査するサービス	O	P
TrustedAdvisor	通知設定有効化 ※TrustedAdvisor はコスト、性能、セキュリティ、耐障害性などのベストプラクティスをサポートしてくれるサービス。 アカウントのサポートプランがベーシックの場合は自動でのチェックが走らない。手動実行が必要なので通知はあまり意味がなさそう。	O	P
Cost Explorer	有効化 Cost Explorer は実績コスト、予測コストの可視化サービス	O	F+
EventBridge	マネジメントコンソールへのサインイン通知	O	Pf
HealthDashboard	EventBridgeによる通知設定	O	Pf

自分がやった方が良いと思ったことを書き出してみました。
中には、料金もかかるし、個人の勉強のための環境だったらそこまでやらなくてもいいかなというものもあるので、オプションとしているものもあります。
個人の感覚で対応はご検討ください。

次の章から必須レベル中心にやり方を説明します。

2.2. ルートユーザーでサインイン確認

AWSのトップページ などからサインインのリンクで遷移

2.3. ルートユーザーのアカウント設定

• ナビゲーションバーのアカウント名ボタン(※画面右上) > アカウント
  • 言語
  • デフォルトリージョン
    

2.4. ルートユーザーにアクセスキーがないことを確認

• ナビゲーションバーのアカウント名ボタン(※画面右上) > セキュリティ認証情報 > アクセスキー

アクセスキーとは、CLIなどのプログラムからAWSへアクセスを可能とするための認証情報で IAM ユーザー単位で発行できるもの。

セキュリティ観点でルートユーザーにはアクセスキーを作成しないことが強く推奨されている。
デフォルトでは作成されていないはずだが、もし不用意に作ってしまっていたら削除しておく。

2.5. パスワードポリシー設定

• IAM > アカウント設定 > パスワードポリシー

デフォルトでも良いが、パスワード強度が足りないと思う場合はカスタムルールを設定する。

1. 「編集」押下
2. 以下例
   • カスタム
     • 最小文字数: 12文字
     • パスワード強度
       • ✅ 少なくとも 1 つのアルファベットの大文字 (A～Z) が必要です
       • ✅ 少なくとも 1 つのアルファベットの小文字 (a～z) が必要です
       • ✅ 少なくとも 1 つの数字が必要です
       • ✅ 少なくとも 1 つの英数字以外の文字が必要です (! @ # $ % ^ & * ( ) _ + - = [ ] {} | ')
     • その他の要件
       • ✅ ユーザーにパスワードの変更を許可

2.6. ルートユーザーのMFA設定

• ナビゲーションバーのアカウント名ボタン(※画面右上) > セキュリティ認証情報 > 多要素認証(MFA)

セキュリティを強化するため、多要素認証を設定する。
AWS アカウントのルートユーザー (コンソール) の仮想 MFA デバイスを有効にします

1. 「MFAデバイスの割り当て」を押下
2. デバイス名を入力
3. MFAデバイスを選択
   ※通常、認証アプリが最も気軽に使いやすい
   以下、認証アプリによる手順
4. (未インストールであれば)認証アプリをインストール
   Google Authenticator, Microsoft Authenticator など
5. QRコード表示
6. 認証アプリでQRコードを読み取り、アカウントを追加
7. 認証アプリでワンタイムパスコードを表示
8. 連続する2つのパスコードを入力
9. 「MFAを追加」押下

MFA設定後に再度サインインしようとすると、MFAのワンタイムパスコードを入力するように求められるようになります。

2.7. IAMユーザーの作成

• IAM
  • ユーザーグループ
  • ユーザー

ルートユーザーはそのAWSアカウントに対して完全な権限を持ち、なんでもできてしまうユーザーなので、普段使いには向かない。
もし、ルートユーザーの認証情報が漏れてしまえばいくらでも悪用できる。
悪用されずとも、よくわからず操作して意図せずAWSのリソースを作成してしまった、削除してしまったなどの事故に結びつきやすくなる。

以下、管理者ユーザーと閲覧専用ユーザーの作成例

1. ユーザーグループ>グループを作成
   • 管理者ユーザー
     • ユーザーグループ名: Administrators
     • 許可ポリシー: AdministratorAccess
   • 閲覧専用ユーザー
     • ユーザーグループ名: ReadOnlyUsers
     • 許可ポリシー: ReadOnlyAccess

   本来、ユーザーには役割によって適切で最小限の権限をつける必要があります。
   AWSが予め用意しているマネージドポリシーまたは、ユーザーが任意に設定できるカスタムポリシーを使いましょう。
   慣れないうちは、マネージドポリシーが便利です。

   マネージドポリシーの例

   マネージドポリシー	概要
   AdministratorAccess	IAMユーザーとして可能な範囲で、全ての許可
   PowerUserAccess	IAM, Organization, Account 関連以外の全ての許可
   ReadOnlyAccess	サービス全般に対する読み取り許可
   <ServiceName>FullAccess	対象サービスに関する全般的な許可
   <ServiceName>ReadOnlyAccess	対象サービスに関する読み取り許可

2. グループを作成
3. ユーザー>ユーザーを追加
4. ステップ1(ユーザーの詳細を指定)
   • ユーザー名
   • ✅ AWS マネジメントコンソールへのユーザーアクセスを提供する
   • ユーザーにコンソールアクセスを提供していますか？
     • ○ Identity Center でユーザーを指定する
       ※ Identity Center は複数のAWSアカウントでIAMユーザーを統一的に管理する仕組み
       マルチアカウントでシステムを構築しない場合は関係ない
     • ◉ IAMユーザーを作成します
   • コンソールパスワード
     • ○ 自動生成されたパスワード
       他の人が使うIAMユーザーを作成している場合は、自動生成して後から変えてもらう
     • ◉ カスタムパスワード
       自身が使うIAMユーザーであれば、ユーザー作成と同時にパスワード設定しても良い
     • ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります
       ※パスワード設定し直させるかによってチェック
5. ステップ2(許可を設定)
   • ◉ ユーザーをグループに追加
   • ✅ Administrator
6. ステップ3 (確認して作成)
7. ステップ4 (パスワードを取得)
   必要あれば、パスワードをメールで送信したり、CSVでダウンロードしたりできる。
   パスワードを表示したり、ダウンロードしたりできるのはこのタイミングのみなので注意。

その他の役割のユーザーを作る場合は、付与する権限を検討の上、IAMポリシーの作成が必要です。
IAMポリシーを検討する段階でAWS Policy Generatorを使うとAWSへのログインも不要でIAMポリシー用のJSONを作成できます。

IAM ユーザーとかルートユーザーってそもそも何？

2.8. ユーザーへのMFA設定強制

多要素認証された IAM ユーザーがセキュリティ認証情報ページで自分の認証情報を管理できるように IAM ポリシーを作成します。
また IAM ユーザーに多要素認証を設定することを強制させます。

1. IAM > ポリシー > ポリシーを作成

2. JSON タブ選択

3. 以下のJSONを入力

   自身の認証情報管理ポリシー

   説明のためにコメントを入れていますが、実際に設定する際は取り除いてください。

   {
     "Version": "2012-10-17",
     "Statement": [
       // アカウントレベルの情報表示を許可
       {
         "Sid": "AllowViewAccountInfo",
         "Effect": "Allow",
         "Action": [
           "iam:GetAccountPasswordPolicy",
           "iam:ListVirtualMFADevices"
         ],
         "Resource": "*"
       },
       // 自分のパスワード変更を許可
       {
         "Sid": "AllowManageOwnPasswords",
         "Effect": "Allow",
         "Action": [
           "iam:ChangePassword",
           "iam:GetUser"
         ],
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       },
       // 自分のアクセスキー作成、更新、削除を許可
       {
         "Sid": "AllowManageOwnAccessKeys",
         "Effect": "Allow",
         "Action": [
           "iam:CreateAccessKey",
           "iam:DeleteAccessKey",
           "iam:ListAccessKeys",
           "iam:UpdateAccessKey"
         ],
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       },
       // 自分のデジタル署名用証明書アップロード、更新、削除を許可
       {
         "Sid": "AllowManageOwnSigningCertificates",
         "Effect": "Allow",
         "Action": [
           "iam:DeleteSigningCertificate",
           "iam:ListSigningCertificates",
           "iam:UpdateSigningCertificate",
           "iam:UploadSigningCertificate"
         ],
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       },
       // 自分の CodeCommit の SSH パブリックキーアップロード、更新、削除を許可
       {
         "Sid": "AllowManageOwnSSHPublicKeys",
         "Effect": "Allow",
         "Action": [
           "iam:DeleteSSHPublicKey",
           "iam:GetSSHPublicKey",
           "iam:ListSSHPublicKeys",
           "iam:UpdateSSHPublicKey",
           "iam:UploadSSHPublicKey"
         ],
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       },
       // 自分の CodeCommit の Git 認証情報アップロード、更新、削除を許可
       {
         "Sid": "AllowManageOwnGitCredentials",
         "Effect": "Allow",
         "Action": [
           "iam:CreateServiceSpecificCredential",
           "iam:DeleteServiceSpecificCredential",
           "iam:ListServiceSpecificCredentials",
           "iam:ResetServiceSpecificCredential",
           "iam:UpdateServiceSpecificCredential"
         ],
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       },
       // 自分の仮想 MFA デバイスを作成、更新、削除を許可
       {
         "Sid": "AllowManageOwnVirtualMFADevice",
         "Effect": "Allow",
         "Action": [
           "iam:CreateVirtualMFADevice"
         ],
         "Resource": "arn:aws:iam::*:mfa/*"
       },
       // 自分の MFA デバイス表示または管理を許可
       {
         "Sid": "AllowManageOwnUserMFA",
         "Effect": "Allow",
         "Action": [
           "iam:DeactivateMFADevice",
           "iam:EnableMFADevice",
           "iam:ListMFADevices",
           "iam:ResyncMFADevice"
         ],
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       },
       // MFA でサインインしていない場合、MFA関連アクション以外のアクションを拒否
       {
         "Sid": "DenyAllExceptListedIfNoMFA",
         "Effect": "Deny",
         "NotAction": [
           "iam:CreateVirtualMFADevice",
           "iam:EnableMFADevice",
           "iam:GetUser",
           "iam:ListMFADevices",
           "iam:ListVirtualMFADevices",
           "iam:ResyncMFADevice",
           "sts:GetSessionToken"
         ],
         "Resource": "*",
         "Condition": {
           "BoolIfExists": {
             "aws:MultiFactorAuthPresent": "false"
           }
         }
       }
     ]
   }
   

   

4. ポリシー名と説明を入力
   

5. ポリシーを作成

6. IAM > 作成したポリシー > アタッチされたエンティティ

7. アタッチボタン押下

8. ユーザーやグループを選択して、ポリシーをアタッチ

   このポリシーをアタッチすると、MFAを設定するまでほとんどのアクションが許可されません。
   パスワードの変更もできないので、このポリシーをアタッチするユーザーにはパスワード変更を強制しないようにしてください。

2.9. IAMユーザーに請求情報へのアクセス許可

AWS アカウントの請求情報について、デフォルトではルートユーザーのみがアクセスできます。
ルートユーザーは普段利用しないので、請求情報をいつでも確認したい場合は、請求情報の閲覧を一般の IAM ユーザーに開放します。

複数人で利用するAWSアカウントの場合は、請求情報を見せても良い範囲を検討し、適切に権限を付与してください。

1. ナビゲーションバーのアカウント名ボタン(※画面右上) > アカウント
2. (下の方にスクロールして)「IAM ユーザー/ロールによる請求情報へのアクセス」の編集ボタン押下
   
3. 「IAM アクセスをアクティブ化」をチェックして、更新ボタン押下

以上で、請求関連の権限が付与されている IAM ユーザーでログインすると請求ダッシュボードなどで請求情報が閲覧できるようになる。
必要な権限については、以下のドキュメントを参照。

2.10. 予算アラート設定

1. Budgets>予算を作成
2. 指示に従って予算を作成する
   ※テンプレートから、ゼロ支出予算、月次コスト予算などを作り、必要に応じて閾値などを調整するとよさそう。

2.11. アカウントエイリアスの作成

通常、IAMユーザーのログインページは https://{アカウントID}.signin.aws.amazon.com/console/ になりますが、アカウントIDは覚えにくいので、エイリアスを設定できます。

1. IAM > アカウントエイリアス
2. 作成ボタン押下
3. エイリアスを入力

エイリアス設定後は https://{アカウントエイリアス}.signin.aws.amazon.com/console/ からログイン可能になります。

2.12. IAMユーザーのIPアドレス制限

不正アクセスを防ぐため、自宅や会社など特定のIPアドレスからのアクセスのみに制限したいかもしれません。
IAM ユーザーに対して 以下のポリシーを設定することで制限が可能になります。

IP制限ポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SourceIPRestriction",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            // 特定のIPアドレス、もしくはCIDRで指定
            // 複数指定も可能
            "xx.xx.xx.xx"
          ]
        },
        "Bool": { "aws:ViaAWSService": "false" }
      }
    }
  ]
}

ただし CloudFormation などユーザーの代わりに AWS サービスが AWS リソースを操作をするような場合に操作元の IP アドレスが変わり、制限を受けてしまいます。
IAM ユーザーに直接権限を与えるのではなく IAM ロール経由で権限を与えることでこのような例を回避することが可能です。
具体的な方法は、以下の記事が詳しい。

👉 以前は制限があったようですが aws:ViaAWSService グローバル条件コンテキストキーを用いることで、スイッチロールは不要になった模様。

3. 参考

• 【資料公開】AWSアカウントで最初にやるべきこと 〜2022年6月版〜 | DevelopersIO
• AWS 初心者向けハンズオン ハンズオンはじめの一歩: AWS アカウントの作り方 & IAM 基本のキ
• AWS 初心者向けハンズオン Security #1 アカウント作成後すぐやるセキュリティ対策

以上