それ積んどく?

ひたすら何かを積んでいくブログ

AWS CloudFormation StackSets のまとめ

概要

複数リージョンまたアカウントに CloudFormation テンプレート(スタック)を
一斉展開できる StackSets 機能について記載。
スタンドアローンアカウントが対象(非 Organizations管理)。

  • 役割の異なる 2 つのアカウントが存在する。
    • 管理者アカウント ... スタックセットを実行するアカウント。
    • ターゲットアカウント ... スタックが展開されるアカウント。
  • 各アカウントに対する事前の権限設定が必要。
    • 規定の名前の 2 つのロールが必要。
      • 管理者アカウント(管理ロール): AWSCloudFormationStackSetAdministrationRole
      • ターゲットアカウント(実行ロール): AWSCloudFormationStackSetExecutionRole
    • 管理者アカウントが実行ロールを引き受ける内容となっている。
      • 作成可能なリソースは実行ロールに割り当てるポリシーに依存する。
    • いずれも AWS から環境設定用の CloudFormation テンプレートのサンプルが提供されている。
  • 複数の展開先を指定する以外は、通常の CloudFormation と使い方は同じ。
    • アカウントとリージョンを指定する。
    • 同一アカウントの場合は実行アカウントに自身のアカウント ID を指定する。

[参考サイト]

スタックセットとは

単一の CloudFormation テンプレートを複数のアカウント、リージョンに展開する機能。

スタックセットでは、1 つの CloudFormation テンプレートを使用して、複数のリージョンの AWS アカウントにスタックを作成できます。各スタックに含まれるリソースはすべて、スタックセットの CloudFormation テンプレートで定義されます。スタックセットを作成する際、使用するテンプレートに加え、そのテンプレートで必要なパラメータや機能を指定します。

see also

アカウントと権限

マルチアカウント展開できることから、スタックセット実行時は
管理者アカウント(実行元のアカウント)、ターゲットアカウント(展開先のアカウント)
の 2 つのアカウントの指定が必要。

  • 管理者アカウント
  • ターゲットアカウント

それぞれのアカウントに役割に応じたスタックセットの実行権限が必要。

  • 実行元先が同一のアカウントの場合でも、所定の権限設定が必要。
  • この際は、自身のアカウント ID を指定して実行する。

規定名称の IAM ロールを使用。

  • 管理者アカウント(管理ロール): AWSCloudFormationStackSetAdministrationRole
  • ターゲットアカウント(実行ロール): AWSCloudFormationStackSetExecutionRole

IAM ロールの作成

AWS 提供のサンプルベースで記載。

  • ターゲットアカウントに AdministratorAccess 権限でリソースが作成できるようになる。

see also

管理者アカウント

実行元のアカウントに必要な IAM ロール。

  • 実行元のアカウントによる AssumeRole を許可する。
    • AWSCloudFormationStackSetAdministrationRole

[AWSCloudFormationStackSetAdministrationRole]

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole"
            ],
            "Effect": "Allow"
        }
    ]
}

ターゲットアカウント

展開先のアカウントに必要な IAM ロール。

  • 実際のリソース作成に必要な権限付与を担う IAM ロール。
    • AWSCloudFormationStackSetAdministrationRole が昇格する先のロール。
  • ロールに割り当てられた権限の行使を可能にする。
    • サンプルでは AdministratorAccess を許可。
  • 信頼関係を設定している。

[AWSCloudFormationStackSetExecutionRole]

<admin_account_id> は管理者アカウントのアカウント ID。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<admin_account_id>:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

単一アカウント用のテンプレート

AWS 提供のサンプルを合体させただけです。
実行アカウントにスタックセット実行に必要な IAM ロールを作成します。

[使い方]

  • CloudFormationCreateIAMRoleForStackSets.yml でテンプレートを保存してスタックを実行。
    • 名前は任意(コピペ用に適当に名前をつけてます)。
  • 実行したリージョンにスタックが作成。
aws cloudformation deploy \
    --template-file CloudFormationCreateIAMRoleForStackSets.yml \
    --stack-name CloudFormation-Stack-CreateIAMRole-ForStackSets \
    --capabilities CAPABILITY_NAMED_IAM

see

[CloudFormationCreateIAMRoleForStackSets.yml]

AWSTemplateFormatVersion: 2010-09-09
Description: Configure the AWSCloudFormationStackSetExecutionRole to enable use of your account as a target account in AWS CloudFormation StackSets.

Resources:
  AdministrationRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AWSCloudFormationStackSetAdministrationRole
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service: cloudformation.amazonaws.com
            Action:
              - sts:AssumeRole
      Path: /
      Policies:
        - PolicyName: AssumeRole-AWSCloudFormationStackSetExecutionRole
          PolicyDocument:
            Version: 2012-10-17
            Statement:
              - Effect: Allow
                Action:
                  - sts:AssumeRole
                Resource:
                  - "arn:*:iam::*:role/AWSCloudFormationStackSetExecutionRole"

  ExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AWSCloudFormationStackSetExecutionRole
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Sub ${AWS::AccountId}
            Action:
              - sts:AssumeRole
      Path: /
      ManagedPolicyArns:
        - !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess

see also

Stacksets の操作

マニュアルベースで概要を記載。
() 内は GUI 上の表記。★ は本記事内で扱うもの。

  • 既存スタック(リソース)の内容を変更する場合は「更新」。
  • アカウントやリージョンに追加展開する場合は、「追加」。
  • テンプレートに設定したパラメータ変更のみの場合は「パラメータの上書き」。
  • 「更新」と「上書き」は一部リージョンのみの選択も可能。

[概要]

  • ★スタックセットの作成
    • 新規作成。
  • スタックセットの更新(Stacksets の詳細を編集)
    • スタックセット中のスタックインスタンスを更新する場合の操作。
      • 変更したテンプレートをアップロード or 何らかのパラメータを変更。
    • アカウントやリージョンの追加はこの操作では出来ない。
  • スタックをスタックセットに追加する(Stacksets にスタックを追加)
    • スタックをさらに別のアカウントやリージョンに展開する場合。
      • 追加展開するアカウント ID とリージョンを指定して実行。
      • テンプレートは既存テンプレートのまま。
  • タックインスタンスのパラメータを上書きする(Stacksets のパラメータを上書き)
    • 文字通り、パラメータ(デプロイオプション)のみ変更可能。
      • テンプレートは既存テンプレートのまま。
      • テンプレート中のパラメータ操作が可能。上書き or テンプレート値に戻す等の操作が出来る。
    • 対象のアカウント ID とリージョンを指定して実行。
      • 展開済みのアカウントとリージョンのみ選択可能。
  • スタックセットからのスタックインスタンスの削除(Stacksets からスタックを削除)
    • 追加の逆。削除するアカウントとリージョンを指定。
  • ★スタックの削除(Stacksets の削除)
    • Stacksets 削除の前にすべてのスタックインスタンス(スタック)の削除が必要。

[検証メモ]

長くなったものを別だし。

  • スタックセットの更新(Stacksets の詳細を編集)
    • アカウント番号やリージョンを入力しなくてもエラーにはならない。
      • 新規作成時と同様のアカウントとリージョンに変更が反映される。
    • リージョンは展開済みのリージョンのみ選択可能。
      • リージョン指定時はアカウント ID とセットで指定が必要。
        • エラー) Must provide both Accounts and Regions if providing a filter
      • 一部リージョンのみの指定も可能。
        • 但し、選択されなかったリージョンの状態ステータスは PENDING になる(実害は不明)。
          • 未選択リージョンではテンプレートと差異が出たはずだが、ドリフトの検出ではエラーにならなかった。
          • 検証は EventBridge ルール名だけ変えて行ったので、対象にならなかったのかもしれない。

see also

StackSets の作成

  • StatkSets が実行元のリージョンに作成される。
  • Stack が展開先のリージョンに作成される。
    • StatkSets 上でスタックインスタンスとして管理される。
  • GUI 上では無効なリージョンも対象として追加可能なため、除外する必要がある。

[設定パラメータ]

  • テンプレートの選択
    • IAM 管理ロール ARN ... ロール名を選択するか、ARN を入力。
      • AWSCloudFormationStackSetAdministrationRole
    • IAM 実行ロール名 ... 実行ロールはデフォルトで下記が設定済。
      • AWSCloudFormationStackSetExecutionRole
    • テンプレートの準備。
      • Amazon S3 URL
      • テンプレートのアップロード
        • cf-templates-<ランダム>-<リージョン名>バケットが作成される。
      • スタック ID(ARN)
  • StackSet の詳細
    • StackSet名
    • 説明
    • パラメータ
      • スタックにパラメータが設定されている場合に入力。
  • StackSet オプション
    • タグ:
      • 作成リソースにタグを設定する場合。
    • 実行設定
      • 非アクティブ or アクティブ ... 並列実行の可否(アクティブのほうが断然早い)。
  • デプロイオプション
    • スタックセットにスタックを追加
      • ● 新しいスタックのデプロイ
      • ○ スタックをスタックセットにインポート
    • スタックをアカウントにデプロイ
      • 対象アカウント ID を入力。
    • デプロイするリージョン
      • リージョンを選択。
    • 同時アカウントの最大
      • 1
    • 耐障害性
      • 0
    • リージョンの同時実行
      • 1

see also

StackSets の削除

StackSets の削除時はまず展開したリソース(スタックインスタンス)を
先に削除する必要がある。
画面が削除っぽくないので、初めてやるとちょっと面食らう。

スタックインスタンスの削除 -> StackSets の削除

  • 展開時と同様に対象アカウントを指定して削除を実施する。

[作業の流れ]

  1. 対象の StackSets を選択。
  2. アクションより、「StackSets からスタックを削除」をクリック。
  3. デプロイオプションの設定
    1. ● スタックをアカウントにデプロイ
      1. <アカウント ID> を入力。
    2. リージョンの指定
      1. 対象リージョンを選択。
    3. デプロイオプション(デフォルト設定を記載)
      1. 同時アカウントの最大数: 1
      2. 障害耐性: 1
      3. スタックを保持: 無効
      4. リージョンの同時実行: 順次
  4. 内容を確認して削除を実施。
  5. 削除完了後、スタックインスタンスのタブを確認。
    1. 何もない状態になれば StackSets を削除できる。
  6. アクションより、「StackSets の削除」をクリック。

see also

ドリフトの検出

CloudFormation テンプレートで設定したリソースの設定と
実際のリソースの設定差分を検出できる(つまり手動変更の検出)。

  • 対象のスタックまたはスタックセットに対して、ドリフトの検出を実行。
  • 差分がなければ「IN_SYNC」、差分があれば「DRIFTED」になる。
    • 差分の詳細は、該当リージョンのスタックから確認する。
  • 差分の修正はテンプレートの修正 or 再展開などで行う(1 クリック是正のようなものはなかった)。

see also

AWS CLI でよく使うコマンド

概要

AWS CLI 利用時によく使いそうなコマンドの組み合わせを記載する。
ある程度溜まったら外だしを検討する。

有効なリージョンの確認

[有効なリージョンの表示]

aws ec2 describe-regions --all-regions \
--filters "Name=opt-in-status,Values=opt-in*" \
--query "sort_by(Regions[].{Name:RegionName},&Name)" --output text
  • 有効なリージョン
    • デフォルトで有効: "OptInStatus": "opt-in-not-required"
    • 追加で有効: "OptInStatus": "opted-in"
  • 無効なリージョン
    • "OptInStatus": "not-opted-in"

[利用例]

下記のように変数に代入してオプションとして利用。

REGIONS=$(aws ec2 describe-regions --all-regions \
--filters "Name=opt-in-status,Values=opt-in*" \
--query "sort_by(Regions[].{Name:RegionName},&Name)" --output text)

see also

AWS Developer Associate(DVA-C01)受験記録

概要

受験者のスペック

  • 2年前に AWS Certified Solutions Architect(SAA-C01) を取得。
    • 3週間ほど前に SysOps(AWS-SOC02) を取得。
  • 受験のきっかけは、最近ようやく AWS 案件に関わることになったから。
    • けどまたオンプレ案件担当に逆戻りしそう。
  • 開発案件は未経験(Git がほんの少し分かる程度)。

勉強期間

  • 勉強期間は2週間位(延べ27時間ぐらい)
  • ポケットスタディを読むのに1週間、ひたすら模擬試験を解くのに1週間の配分。
    • Udemy の問題を2周し終わったのは試験前日(2回目は概ね9割とれた)。
  • 直前にやった模擬試験は 7 割だった。
    • 解説も何も出ないので、どれが正解でどれが不正解だったのかよくわからん。

結論

  • ソリューションや SysOps の知識だけでは合格が難しく、追加の学習が必要。
    • サービスとして範囲は被る部分もあるが、より詳細なユースケースを問われる。
    • 舐めプしたらまず落ちる(と思う)。世間で言われてるほど簡単とは思わない。
  • 公式の模擬試験(¥2,000 掛かる方)はあんまり参考にならない。
    • 言葉足らずな尖った設問が多く、本試験より別の意味で難しい内容が多かった(本試験はもっと普通)。
    • そのくせ20問しか問題数がない。
    • 10 問だけのサンプル問題のほうがより実際のイメージに近い。
  • 本試験は割とあっさりめの問題が多いので、サービスごとのユースケース(問題傾向)をしっかり押さえておけば多分受かる。
  • 設問は消去法による絞り込みを活用すべし。

[結果]

f:id:jigoku1119:20210913171230j:plain
DVA受験結果

使った教材

AWS SysOps Administrator Associate(SOA-C02) 受験記録

概要

受験者のスペック

  • 2年前に AWS Certified Solutions Architect(SAA-C01) を取得。
  • 以来 AWS 経験を積む機会は結局なく、ペーパードライバーとして余生を過ごす。
  • 受験のきっかけは、最近ようやく AWS 案件に関わることになったから。

結論

  • 良くも悪くもない成績ながら無事合格。
  • AWS コンソールを使った操作が中心だから試験ラボは思ったより怖くない。
    • 試験範囲がべらぼうに広い中、一体どんなことをやらされるのかと思ってたら至ってスタンダードな内容だった。
  • でも可能な限り、代表的な使い方については予め実機(AWS コンソール)を触っておくと安心。
    • 画面操作なので設定概念が分かっていたらヤマカンでやれないこともない(今回1問はぶっつけ本番でやった)。
    • 但し、全体の2-3割程度の点数を持っていかれるので、ラボを落とすと合格は相当厳しい。
  • 更新前の試験教材が役に立つかは不明(ちょっと前に Udemy で教材を買っていたものの、結局使わず)。
    • 試験対策カウンター的に試験内容が一新されてそうだったので、素直に他の方のを買い直しました。
  • 新しいの(SAA-C02)は知らんけど、これ SAA よりむずくない??
    • 試験範囲が広く、より突っ込んだ内容が出る。
    • SAA -> SOA -> SDA が良さげ。

[成績]

f:id:jigoku1119:20210823172752j:plain

使用教材に関して

以下の3つです。

Tutorials Dojo は Udemy とプラットフォームが違うだけで、たぶん内容は一緒です。
(プラスで試験ラボ用の問題がついてる)

僕は説明をよく読まなかったので、Udemy と Tutorials Dojo の両方を買ってしまいましたが、よくよく読むと Udemy に Tutorials Dojo の期間限定の利用権が付いてるぽいですね。
(どっちを買うかは好みと Udemy のセールのタイミングとかとご相談かなと。)

  • FREE EXCLUSIVE 3-MONTH ACCESS TO THE TUTORIALS DOJO PORTAL - EXAM SIMULATOR - where you can see the answers right away as you go through each question, plus other training modes and perks! This is an optional feature and registration is required to access the simulator (using your name and email address).

サンプル試験ラボ(公式)

なお、別途試験ラボのサンプルも提供されているみたいです。
試験予約した時のメールにログイン情報とかが書いてありました。
(受かってから気づいた!!)

期間限定ではありますが、試験ラボのサンプルを無料で試すことができます。本番の試験の前に試験ラボの環境を実際に体験してください。試験ラボは、最初の受験日から 90 日間にわたって、3 回受験することができます。

試験ラボ

詳細は書けないのですが、出るのはとても一般的な内容です。
AWS コンソールを使って指示された条件でリソースを作る試験になっているようです。
(画面が左右に分かれていて、左側にコンソール。右側に問題って感じです。)

ただ課題の出され方が抽象的なので、どの機能を使って設定すればよいのか自分で想像して考える必要があります。
ウィザードを使ってできることはウィザードの内容で良く、特に指定がなく、 ウィザードが自動設定するものは恐らくデフォルト設定の範囲として扱ってよいはずです。
(というかそれ以上に判断材料がない)

前提リソースを伴うものは、タブをもう一つ開くなり、事前に作るなりして作成すればよいです。
(設問を読んだ段階で、作成順序を整理できるとベスト)

注意書き

  • 試験ラボがめちゃくちゃ遅延してて、1クリックで1分は余裕で待たされる有様でした。
  • 1問20分程度を推奨されていますが、30分は見ておいたほうが精神的に良いです。
    • 学科が1時間で終わったので、今回は時間は売るほど余ってたけど。

対策した内容

基本的に設定概念(要素)を整理しておくことが大事になるかと。
実習した後はリソースの削除を忘れずに!!(超大事)

  • CloudWatch メトリックフィルターの設定
    • 設定する流れと用語について整理。
    • できればやっておいたほうが良い。
  • CloudFormation スタックの展開と更新
    • これは一回経験しておいたほうが良い。
    • テンプレートを最低限読めるようにしておく。
  • EC2、VPC の作成
    • この周辺はどうとでもなりそうだったので、サラッと流した。
  • AWS Backup の設定
    • どういうふうに設定するのかを整理。
      • バックアップ対象の設定方法と出来ることできないことの整理。
  • ALB を伴うオートスケーリンググループの設定
    • どういうふうに設定するのかを整理。
    • 微妙にややこしいので、やっておくと吉。
  • S3 の設定
    • ライフサイクルポリシー、バージョン管理の設定方法。
    • ややこしいので要対策(特にライフサイクル)。
  • KMS の設定
    • これ単体というよりは他と絡むことが多いぽい。
  • SNS の設定
    • これ単体というよりは他と絡むことが多いぽい。
    • 概念を理解しておけば良い。
  • RDS の設定
    • AWS のサンプル問題に載ってたやつ。
    • RDS 触ったことなかったので、実際やった。
  • IAM の設定
    • IAM ポリシーの設定周り。
    • 方法というよりは中身のおおよその書きっぷりを覚えとく。
  • EFS, FSx
    • ウィザードの流れを確認。
  • Dynamo DB
    • ウィザードの流れを確認。
    • RDS 出そうなら出るんかなぁと思った。
  • ElastiCache
    • ウィザードの流れを確認。
    • RDS 出そうなら出るんかなぁと思った。

勉強方法

  1. 模擬試験をひたすら解く。
  2. 解く中で ? と思ったものを調べてひらすらメモを取る。
    1. VS Code でサービスごとにメモを作ってひたすら書く。
      1. BlackBelt も流し読みする。
    2. サービス名を見て何をするものかわからなければ調べて一言でまとめる。
    3. 試験に出そうだなと思ったものは、設定概念と用語を整理する。
    4. 各サービスのユースケース(出題パターン)を覚える。
    5. たまに AWS コンソールを開いて覗く。
  3. 試験ラボ対策に AWS コンソールをいじる。
    1. 今回は教材が提供してる分だけやった(試験前日!)。

AWS アカウントの初期設定

概要

各種 AWS 初期設定ブログなどを参考にした個人的メモ書き。

  • 操作はコンソールベースで行う。
  • アップデートで UI や仕様は細かく変化するため、一次ソースを洗った裏取りを推奨。
  • 組織管理しない単独アカウントを対象とする(非 Organization)。
  • アカウント作成後、とりあえずやっておきたいことの網羅を目指す。
    • 無料枠が活用できるので、セキュリティ系の有償サービスも使う。
      • 但し、少し費用がかかっても使いたいサービスがほとんど。
    • AWS クラウド無料利用枠 | AWS

[参考サイト]

下記は本記事中で一切触れていないサービス(必要に応じて適用と判断)。
いずれも商用環境では利用を検討したいツール。

更新履歴

  • 2021/06/28 新規作成
  • 2023/01/26 全体的に見直し
    • よくわかってなかったときに初版を書いたので全体的に見直した。

設定サービス/作成リソース

本記事内でいじる主なサービスとその生成物の概要。

  • CloudTrail
    • マルチリージョンサービス(単一リージョンで設定すれば使える)。
    • 作成されるもの
  • GuardDuty
    • リージョンサービス(リージョン単位で設定)。
    • 作成されるもの
      • サービスロール
  • Security Hub
    • リージョンサービス(リージョン単位で設定)。
      • 特定のリージョンに検知結果の統合は可能。
    • 作成されるもの
      • サービスロール
  • AWS Config
    • リージョンサービス(リージョン単位で設定)。
    • 作成されるもの
      • レコーダー
      • 保存用の S3 バケット
      • サービスロール
  • S3
  • IAM
    • グローバルサービス。
    • IAM ユーザ
      • 管理ユーザ(任意)
    • IAM グループ
      • 管理用グループ(任意)
    • IAM ロール
      • AWS Config 用サービスロール: AWSServiceRoleForConfig
      • GuardDuty 用サービスロール:
        • AWSServiceRoleForAmazonGuardDuty
        • AWSServiceRoleForAmazonGuardDutyMalwareProtection
      • Security Hub 用サービスロール: AWSServiceRoleForSecurityHub

AWS アカウントの作成

最初に AWS のルートアカウントを作成する。

  • リソースの保有および請求単位になる。
  • 管理用の IAM ユーザを作るまではこのアカウントで操作する。
  • root ユーザなので MFA を設定して凍結。普段使いはしない。

[設定内容]

  • E メールアドレス
    • ルートアカウントとしてのログイン ID になる(あとから変更可能)。
  • アカウント名
    • 任意の名前。アカウントの利用用途などがわかる名前にする(あとから変更可能)。
    • 個人アカウントの場合は、名前-姓 -目的 (例:paulo-santos-testaccount) などの命名規則の使用を検討してください。

  • 請求先情報
    • アカウント種別(Business or Personal)
      • 入力項目が変化する。
    • 請求先住所
      • 請求書に載る。
  • クレジットカード情報
  • サポートプランの選択
  • SMS 認証

see also

アカウントの環境設定

個別サービス以外の全般的な設定を行う。

ルートアカウントの MFA 設定

ログイン時の多要素認証(MFA)を有効化する。

  • 複数の MFA デバイスを設定可能(最大 8)。

[操作手順]

  1. 右上のマイアカウントのメニューより、「マイセキュリティ認証情報」をクリック。
  2. IAM のセキュリティ認証情報より、「MFA を割り当てる」をクリック。
  3. MFA デバイスを選択。
    1. バイス名: 任意
      1. 既存デバイスと重複は不可。
    2. MFA デバイスを選択
      1. ● 認証アプリケーション
      2. ○ セキュリティーキー
      3. ○ ハードウェア TOTP トーク
  4. QR コードを表示、認証アプリ(GoogleAuthenticator等)より読み込み、コードを 2 つ入力する。
  5. 一度サインアウトして、MFA を使用して再ログインする。

see also

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

権限を与えても初期設定だと IAM ユーザはアクセスできないのでそれを開放する。

[操作手順]

  1. 右上のマイアカウントのメニューより、「アカウント」をクリック。
  2. IAM ユーザ/ロールによる請求情報へのアクセスより、「編集」をクリック。
  3. 「IAM アクセスのアクティブ化」を選択し、更新。

see also

パスワードポリシーの設定

IAM ユーザに設定可能なパスワードのポリシーを設定する。
パスワードポリシーを設定しない場合、デフォルトポリシーが適用される。
(デフォルトポリシーだと後述する Security Hub によるチェックに引っかかる)

  • パスワードの最小長は 8 文字、最大長は 128 文字です
  • 大文字、小文字、数字、および非英数字 ( )の文字タイプの組み合わせのうち、少なくとも 3 つ! @ # $ % ^ & * ( ) _ + - = [ ] { } | '
  • AWS アカウント名または E メールアドレスと同一でないこと
  • パスワードを無期限にする

see also

[操作手順]

  1. サービスの IAM を開く。
  2. アクセス管理 - アカウント設定 をクリック。
  3. パスワードポリシーを選択するをクリック。

支払通貨の変更

ドル建ての支払いを日本円に変更する。 現在は、デフォルトで日本円。

[操作手順]

  1. 右上のマイアカウントのメニューより、「アカウント」をクリック。
  2. お支払い通貨の設定より、編集をクリック。
  3. USD -> JPY に変更して更新。

Budget の設定

Budget を使用して予算を設定する。
予算を設定すると利用料金の超過を検知できる。

  • テンプレートによる初期設定が可能。
    • 後から内容は変更できる。
  • 直接 E メールを飛ばすほか、SNS への通知も設定可能。

予期しない料金超過を検知したい場合は、Cost Anomaly Detection の利用も検討。

look at

[料金に関して]

  • 予算通知は無料(2020/12/15~)。
  • アクションの追加は、最初の 2 つの予算まで無料。
    • Your first two action-enabled budgets are free (regardless of the number of actions you configure per budget) per month. Afterwards each subsequent action-enabled budget will incur a $0.10 daily cost.

see also

[操作手順(テンプレートの場合)]

一例として月額予算の場合を記載。

  1. 右上のマイアカウントのメニューより、「請求ダッシュボード」をクリック。
  2. 左側の Budget を選択し、「予算の作成」をクリック。
  3. 予算の設定
    1. ● テンプレートを使用(シンプル)
    2. ○ カスタマイズ(アドバンスト)
  4. テンプレートの選択
    1. ○ ゼロ支出予算
      1. 無料可能枠で予算を作る場合。
    2. ● 月次コスト予算
    3. ○ 日次の Saving Plans のカバレッジ予算
    4. ○ 1 日の予約使用率予算
  5. テンプレートの設定
    1. 予算名: <任意>
    2. 算額($): <任意>
    3. E メールの受信者: <任意>(複数指定時は、カンマ区切り)
    4. スコープ: すべての AWS サービス(固定値)
      1. 実際の支出が 85 %、実際の支出が 100 %、予測される支出が 100 % に達するとアラートが送信される。
  6. 予算を作成。

see also

UI 設定変更(統合設定)

最近の AWS コンソールは下記の設定が可能。
アカウントまた IAM ユーザごとに設定内容が AWS 側に保存される。

[設定内容]

デフォルト設定を記載。

  • ローカリゼーションとデフォルトのリージョン
    • 言語: 日本語
    • デフォルトのリージョン: 最後に使用したリージョン
      • ログイン後の最初のリージョンを設定可能。
  • 表示
    • ビジュアルモード: ライト
      • ダークモードにできる。
    • お気に入りバーの表示: サービス名とアイコン
  • 設定管理
    • 最近アクセスしたサービスを記憶する: はい

[操作手順]

  1. 右上のマイアカウントのメニューより、「設定」をクリック。
  2. 内容を設定。

[メモ]

  • 単一の環境(ブラウザ)で複数ユーザを使った場合、以前のログインユーザの影響を受けてる気がする。

see also

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

AWS にログインする際に入力するアカウント ID にエイリアスを設定できる。
エイリアスを設定するとエイリアスを用いたログイン URL が利用できるようになる。

https://<Your_Account_Alias>.signin.aws.amazon.com/console/

  • グローバルで一意である必要がある。
  • エイリアス設定後も従来の URL は使用できる。
  • エイリアスはアカウントに 1 つのみ設定可能(上書き)。

[操作手順]

  1. サービスの IAM を開く。
  2. ダッシュボードより、アカウントエイリアスの「作成」をクリック。
    1. 任意の名前を入力。
      1. すでに使われている名前だとエラーが出る。
    2. 成功すると「このアカウントのエイリアス XXX が作成されました。」のメッセージが出る。

セキュリティサービスの有効化

AWS の運用にあたって利用が推奨される管理系サービスを有効化する。
後述する IAM ユーザ作成を先にやってそのユーザによる操作でも良い
(必要な権限を与えること)。

  • CloudTrail
    • AWS 環境上での操作履歴を残せるため、利用は必須と考える。
  • AWS Config
    • リソースの構成履歴が残せるため、利用は必須と考える。
  • GuardDuty
    • 機械学習により不正なアクティビティを自動検知できるため、利用は必須と考える。
  • SecutiryHub
    • 各種アラートの集約ができるため、利用を推奨。
    • GuardDuty のアラート集約ができる(使わない場合、個別の設定が必要)。

設定にあたり、対象リージョンが合っているかを確認すること!!

CloudTrail の有効化

AWS 上での API 操作ログの確認を可能にする。
最新 90 日間のアクティビティを CloudTrail 上で表示、検索、ダウンロードできる。

  • デフォルトでマルチリージョン対応。
    • 有効化したリージョンに S3 バケットが作成される。
  • Cloudtrail 自体は基本無料。S3 への保存に対して課金される。
  • ログファイルを暗号化する場合は、SSE-KMS を使用(KMS キーの作成が必要)

[作成されるもの]

  • CloudTrail の証跡
  • 証跡を保存する S3 バケット

[操作手順]

  1. サービスの CloudTrail を開く。
  2. 「証跡の作成」をクリック。
  3. 設定内容
    1. 証跡名:management-events
    2. 証跡ログバケット及びフォルダ: aws-cloudtrail-logs-XXX
  4. 証跡作成後、下記の設定を変更。
    1. ログファイルの検証 を有効化。
    2. CloudTrail ログの検証を可能にするダイジェストが生成されるようになる。
      1. CloudTrail ログファイルの整合性の検証 - AWS CloudTrail

[追加の検討事項]

AWS Config の有効化

AWS リソースの設定変更を評価、監査、審査できる。

  • リソースが規定の設定になっているかのチェックや、過去の設定状況の確認が行える。
  • マネージドルール、カスタムルールによる柔軟なチェックが可能。
  • Security Hub 利用における前提条件。

[作成されるもの]

[料金に関して]

  • 記録された設定項目あたりの料金と、ルールの評価数に応じて課金される。
  • その他 S3 バケットの料金が掛かる。

see also

[設定手順]

有効化はリージョン単位で行う。

  1. サービスの AWS Config を開く
  2. AWS Config のセットアップの、「1-Click セットアップ」をクリック。
    1. デフォルト設定。必要に応じてルールを設定。
  3. 以下の設定のレコーダが作成される。
    1. 記録するリソースタイプ: このリージョンでサポートされているすべてのリソースを記録します。
    2. AWS Config ロール: AWSServiceRoleForConfig
    3. 配信方法
      1. Amazon S3 バケット: config-backet-XXX
  4. 作成後、下記の設定を変更。
    1. グローバルリソース(AWS IAM リソースなど)を含める を有効化。

see also

[追加の検討事項]

see also

AWS Config の全リージョンでの有効化

AWS Config はリージョン単位で有効化が必要。
全リージョンで有効化する場合は下記を検討(商用環境ではほぼ必須と考えられる)。

see also

脅威モニタリングサービス。
以下のデータソースをもとに悪意のあるアクセスなどを検知してくれる。

  • AWS CloudTrail event logs
  • VPC Flow Logs
  • DNS logs

see also

[料金に関して]

  • 有料サービスで、30 日間はすべての機能が無料で使える。
  • 分析されたイベント量に応じて課金される。
    • つまり、利用が多ければ多いほど料金がかかる。
  • 個人検証程度のアカウントなら無視できるレベル。

see also

[操作手順]

有効化はリージョン単位で行う。

  1. サービスの GuardDuty を開く。
  2. GuardDuty を無料で試すの、「今すぐ始める」をクリック。
  3. 「GuardDuty を有効にする」をクリック。
    1. サービスのアクセス権限の説明が書いてある。
      1. ログソースに対して、GuardDuty からのアクセス許可を設定する。
    2. ロール名:AWSServiceRoleForAmazonGuardDuty

[追加の検討事項]

Guard Duty の全リージョンでの有効化

GuardDuty はリージョン単位で有効化が必要。
全リージョンで有効化する場合は下記を検討(商用環境ではほぼ必須と考えられる)。

  • CloudFormation のスタックセットによる一括展開。
  • 各リージョンからのアラート通知は後述の SecurityHub による集約と合わせて検討する。

see also

Security Hubの有効化

セキュリティステータスの一元化、
およびペストプラクティスに基づくセキュリティチェックが出来る。
集約に対応する AWS サービスは下記。

これらの対応サービスのアラートを個別サービスではなく、
SecurityHub 経由で検出できるようになる。
具体的には、 EventBridge でイベント設定をする際、対象が

"source": ["aws.securityhub"]

のような形になる。

see also

[前提条件]

[料金に関して]

  • 30 日間は無料で使用できる。
    • ただし、セキュリティチェックをする場合、AWS Config のルール実行に応じた料金がかかる。
  • セキュリティチェックの実施件数と検出件数に応じて従量課金される。
  • 設定 - 使用 から利用料金を確認できる。
    • トライアル期間に目安を確認すると良い。

see also

[操作手順]

  1. サービスの Security Hub を開く。
  2. Security Hub の使用を開始するより、Security Hub に移動をクリック。
  3. 設定
    1. AWS Config の有効化
      1. すべてのアカウントと Security Hub を利用するすべてのリージョンで AWS Config を有効にするよう求められる。
        1. 有効化のための CloudFormation テンプレートのダウンロードが可能。
    2. セキュリティ基礎
      1. [x] AWS 基礎セキュリティのベストプラクティス v1.0.0 を有効化
      2. [ ] CIS AWS Foundations Benchmark v1.2.0 を有効
      3. [ ] PCI DSS v3.2.1 を有効化
  4. 設定完了後、下記を任意で変更。
    1. 設定 - リージョン より、集約リージョンを設定する。

セキュリティチェックの結果が出るまでには時間がかかる(24時間?)

Security Hub の全リージョンでの有効化

Security Hub はリージョン単位で有効化が必要。
全リージョンで有効化する場合は下記を検討。

  • CloudFormation のスタックセットによる一括展開。
  • 各リージョンでのセキュリティチェックの利用可否。

see also

Security Hub の運用

Security Hub では検知ごとにワークフローが生成される。

  • このステータス操作により、状態管理が可能。
    • 確認した限り、Security Hub 上での状態変更は大元のソースの状態には反映されない模様 (GuardDuty で確認)。
  • ステータス変更に応じた各種アクションの実行が可能。

see also

IAM ユーザ/グループの作成

ルートアカウントは何でも出来るので、普段は専用の IAM ユーザを使用して操作する。
今回は代替となる管理者権限を持ったユーザを作成する。

  • ユーザ個別ではなく、グループに対する権限付与を推奨(管理が煩雑になる)。
  • 直接権限を埋め込むインラインポリシーは使用しない。
  • ユーザは使い回さない(個別ユーザの作成)。
  • MFA を設定する。

see also

IAM グループの作成

[設定する権限]

下記は AWS が内容を管理するマネージドポリシーになる。

  • AdministratorAccess
    • すべてのリソースに対する、すべての操作権限を有する。
    • 後述の請求情報へのアクセス権 Billing も含む。

see also

[操作手順]

  1. サービスの IAM を開く。
  2. アクセス管理 - ユーザグループ をクリック。
  3. グループの作成をクリック。
  4. 設定内容
    1. ユーザグループ名:任意
    2. アクセス許可ポリシー:AdministratorAccess

IAM ユーザの作成

[操作手順]

  1. サービスの IAM を開く。
  2. アクセス管理 - ユーザー をクリック。
  3. ユーザーを追加をクリック。
  4. ユーザー詳細
    1. ユーザー名:任意
    2. アクセスの種類:
      1. ■ コンソールアクセスを有効化
        1. コンソールのパスワード
          1. 自動生成またはカスタムパスワードを設定。
        2. □ ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります
  5. アクセス許可の設定
    1. ユーザをグループに追加。
      1. 先ほど作成したグループに参加させる。
    2. アクセス権限の境界の設定
      1. 権限を制限したい場合に設定。
      2. IAM エンティティのアクセス許可の境界 - AWS Identity and Access Management
  6. タグの追加(オプション)

CLI 操作などを行いたい場合は、別途アクセスキーを生成。

MFA の有効化

権限が強いので、MFA を有効にする。

[操作手順]

  1. サービスの IAM を開く。
  2. アクセス管理 - ユーザー をクリック。
  3. 作成したユーザーをクリック。
  4. セキュリティ認証情報 - MFA デバイスの割り当てより、管理をクリック。
  5. 以降、ルートアカウントの際と操作は同様。

通知設定

有効化したセキュリティサービスなどの通知設定。
やっておきたいものを記載(方法はいつか別記事)。
いずれも EventBridge で設定。

サービスの設定

デフォルト VPC の削除

利用可能な各リージョンに自動的に作成されているデフォルト VPC を削除する。

  • デフォルトで上限 5 VPC のクォータがあるため、使わない場合は消しておく。
    • 消しても復元できる。後から消そうとすると取り違えも起こり得るため、早めの対処を推奨。
  • 使う場合は、設定を充分に見直す(特に IGW を割り当てたパブリック系のサブネット)。
  • 最初は抵抗があるが、使っていなければ消しても特に実害はない。

サービスの VPC から操作する(詳細手順は URL 参照)。

see also

EBS のデフォルト暗号化の設定

EBS 作成時のデフォルト設定を変更可能。

  • 設定はリージョン単位。
  • デフォルトで暗号鍵として AWS 管理のマネージドキーが使用可能。
    • マネージドキーの料金は、API アクセスのみ課金される(無料枠あり)。
    • カスタマーキーを使用する場合、別途作成が必要(こちらは鍵の保有自体に料金が発生)。
  • 鍵の保有や暗号化の実施は、組織のポリシーに照らして全体的に検討が必要。
  • KMS はリージョンサービスのため、暗号化した場合はクロスリージョンレプリケーションなどの各種バックアップにおいて追加の検討が必要になる。

サービスの EC2 - ダッシュボードから操作する(詳細手順は URL 参照)。。

see also

S3 バケットのパブリックブロックの設定

バケットの外部公開ポリシーをアカウント単位で設定できる。

  • デフォルトで無効。
    • 未設定状態でもバケットに明示的な許可が必要なため、デフォルトで公開状態にはならない。
  • 有効にするとブロック対象となる公開設定をした際にエラーが出るようになる。
    • 既存のポリシー設定より、こちらの設定が優先(最も厳しい内容が適用)。
  • 設定はアカウント単位で有効になる(すべてのリージョンに適用される)。
  • すべてブロックにしておいて、必要に応じて開放していくほうが安全と考えられる。

2023/04 以降はデフォルトでブロックが有効になる。

2023 年 4 月以降、Amazon S3 はすべての新しい S3 バケットの S3 ブロック パブリック アクセスとオブジェクト所有権 (ACL が無効) のデフォルト設定を変更します。

サービスの S3 から操作する(詳細手順は URL 参照)。

see also

S3 バケットの暗号化設定

今後デフォルトで SSE-S3 の暗号化が適用される模様。
2023/01 時点では過渡期のためか、まだ未設定状態だった。

  • 必要に応じて変更。

see also

オプション

必要に応じて設定する内容などを記載。

Trusted Advisor の通知設定

デフォルトで有効。
以下の 5 つの観点でベストプラクティス準拠をチェックしてくれる。

  • コスト最適化
  • パフォーマンス
  • セキュリティ
  • フォールトトレランス
  • サービスの制限

サポートプランに応じて使用できる内容が異なる。

  • 特に通知は来ないので、定期的に見たい場合は通知設定より、通知先(E-Mail)を設定する。
    • ただし、Business サポート以上の契約が必要。

Trusted Advisor 通知機能を使用すると、AWS リソースのデプロイの最新情報を常に得ることができます。このサービスにオプトインすると、毎週メールにより通知されます。メール通知のチェックステータスの概要を最新の状態にしておくにはチェックのリフレッシュが必要です。AWS Business Support、AWS Enterprise On-Ramp、および AWS Enterprise Support を利用しているアカウントを対象にチェックの自動リフレッシュが毎週実施されます。AWS デベロッパーサポートと AWS ベーシックサポートを利用しているアカウントは AWS マネジメントコンソールにログインしてチェックのリフレッシュをトリガーする必要があります

see also

Cost Explorer の設定

Budget で予算を作成すると有効化される。
(内容表示には有効化から 24 時間程度の時間が必要。)

下記のオプションを設定可能(デフォルト無効)。

  • 時間単位とリソースレベルのデータ(有料)
    • 有料だが時間単位でリソース使用状況が確認できるようになる。
  • Amazon EC2 リソースの推奨事項を受け取る
    • 使用状況に応じたインスタンスサイズのレコメンドを受けられるようになる。

see also

[料金に関して]

  • API アクセスはリクエストあたりの課金。
    • Each request will incur a cost of $0.01.

  • 前述の時間単位のデータは 毎⽉ UsageRecord 1,000 個あたり 0.01 USD。
    • The cost is $0.01 per 1,000 UsageRecords month.

see also

Cost Usage Report(CUR) の出力

下記を含んだレポートが作成できる。

設定後は指定した S3 バケットに対して定期的なレポート出力(最低1日1回)が行われる
(初回レポートは最大 24 時間必要)。

  • これ自体は無料。S3 の利用料金は掛かる。
    • 個々のレポートのサイズは 1 ギガバイトを超える可能性があり、すべての行を表示するデスクトップ スプレッドシート アプリケーションの容量を超える可能性があります。

  • csv 形式の圧縮ファイル(gzip)が生成される。

see also

コスト配分タグの設定

AWS 試験でよく出題されるリソースに設定したタグを用いてコスト分析するやつ。

see also

Billing の詳細設定

Billing - 詳細設定より、下記のオプションが設定可能。

秘密の質問の設定

アカウントに追加のセキュリティを設定したい場合(実効性はない気がする)。

秘密の質問を追加することで、AWS アカウントの安全性を高めることができます。お客様がカスタマーサービスへお問い合わせの際、カスタマーサービスはお客様が AWS アカウントの所有者であることを確認するためにこの質問を利用します。

  • 電話での問い合わせ時に確認される模様。
  • 一度設定すると消す方法はない模様(未検証)。
  • 役に立つのかコレ?

see also

代替連絡先の設定

ルートアカウントのメールアドレス以外の連絡先を登録する際に設定。

see also

命名規則の検討

タグ付けのルールと合わせて検討する。
作り出す前に簡単にでも決めておくことを推奨。

下記は個人的にやっていたこと。

  • Release: <yyyy-mm> みたいなタグをつけたコスト配分タグを使った分析。
    • リリースタイミングで随時つけていた。
  • EC2 に対する VPC など依存関係がある上位リソースがある場合、名前にそれを含める。
    • 例示) <上位リソース>_<サービス名>_<リソース名>_<オプション>
      • オプションは public など補足情報がある場合に使用。
        • test-vpc_ec2_testsv

see also

CloudShell の活用

CLI の実行環境が標準で備わっている。

  • 立ち上げたらすぐ使える。
    • Azure と違って初期設定不要。
  • 1G のストレージが無料で使える。

see also

有効なリージョンの確認

日本国内で使う分には特に有効化は不要。
右上のマイアカウントから有効なリージョンが確認出来る。

  • デフォルト設定の変更は不可。追加の有効化のみ可能。

see also

準拠法/管轄裁判所の変更

現在(2023/01)は不要な模様。

  1. アマゾン ウェブ サービス ジャパン合同会社とは何ですか? 2022 年 2 月 1 日より、アマゾン ウェブ サービス ジャパン合同会社(AWS Japan) が、Amazon Web Services, Inc. (AWS Inc.) に代わり、日本国内の全てのアカウントに対する新しい AWS クラウドサービスの契約当事者となります。したがって、日本国内のすべてのアカウントは AWS Inc. ではなく、AWS Japan からクラウドサービスを購入することになります。日本国内の請求書払いのアカウントは、2021 年 11 月 1 日に、既にAWS Japan に移行されています。

see also

AWS Health Dashboard によるイベント監視

AWS Health Dashboard で障害状況などが確認できる。

see also

AZ-104(Microsoft Azure Administrator) 受験記録

概要

先日 AZ-104 を受験し無事合格したのでその際に行った勉強法を残します。
(成績は907点でした。ただこれにはカラクリがあります。)

※ちなみに私は Azure はほぼ未経験で、クラウド自体も AWS-SAA を2年前にとっただけのペーパーエンジニアです(実務経験なし)。
(なお本業は他称 Solarisスペシャリスト)

所感

出題は合計 64 問で、前半 60 問がセクション問題を含む選択問題、残り4問が長文問題(想定内容から最適解を導く)でした。
ラボ問題みたいなのは出題されませんでした。
最終的に1時間近く時間が残りましたが、最後に長文問題が出たので時間配分は注意が必要かもです。

トラブルが嫌だったので最寄りの試験会場で受験しました(オンラインもできるらしいですね)。

結論

最初に結論だけ書くと、学習内容に記載の Udemy の問題集を覚えるまでやり込めば誰でも合格できます。
(前述したカラクリの正体がこれです。問題の類犠性が非常に高く、8割"見たことある"内容の問題が出題されました。)

学習内容

問題集を先にやるか、Learn などの学習を先にやるかはお好みで良いと思います。
ただ AZ-900 の解説本は一番最初に読んでおいたほうがあとの理解がずっと楽になります (内容が非常に良質なので必読と言って良いかもしれません)。

AZ-900 を取得済みならいきなし問題集でも問題ないです
(そのレベルの方なら適時 Docs や Learn の参照のほうが効率が良いと思います)。

  • AZ-900 の解説本で Azure の全体像を掴む。
  • Microsoft Learn を眺める。
    • 但し、見るのは AZ-104 系ではなく AZ-900 に分類される比較的初歩的な方を優先で良いです 。
      • 検索で引っ掛ければそれぞれ関連したものが出てきます。
        • 「Azure の基礎」で出てくる6部まであるやつがいい感じにまとまっています。
      • 手を動かせる演習は時間、また興味があればやるで良いと思います。
        Azure はリソースができるのを待つ時間が結構長く、演習の半分ぐらいが待ち時間とかザラだからです。
    • 私は一応 AZ-104 で検索して出てきたものにすべて目を通しましたが、試験に出る?見たいな内容も多く、日本語も頭に入りにくく、さらに網羅性もイマイチに感じた為です。
      • ただ中にはたまに必読と思えるような良質なのも混じってます(特定のユースケースや分野にフォーカスしたものにその傾向が強い?)。
    • その点 AZ-900 系は全体の概要や基本となる考え方が書かれたものが多く、Azure に限らず役に立つのと頭に入りやすいからです。
  • AZ-900 を受験する(オプション)。
    • Microsoft 系の資格試験が初めてであれば推奨。試験会場や受験方法などの下見の意味合いが大きいです。
    • たまにバウチャーをもらえるオンライン講座を Microsoft が主催してるようなので、探してみましょう。
      • わたしはそれでタダで受けました。
  • AZ-104 - Microsoft Azure Administrator Practice Tests 2021 | Udemy をやりこむ。
    • 全編英語ですが、機械翻訳でどうとでもなるので英語がわからなくても臆する必要はありません。
      • 定期的にセールをやってるっぽいので、時期があってればとりあえず買っておくのもアリです。
    • おすすめの理由は、
      • 問題傾向の類似性が非常に高い。
      • 評価が高く、定期的なアップデートの形跡が見える(2021とか)。
      • 解説が充実している。
    • の3点です。
    • 最後が一番のポイントかもしれません。正解理由と参考リンクが書いてありスムーズに学習できます。

必要な期間

私は毎日3-4時間程度勉強するペースで、1ヶ月ぐらい掛けました。
( 半分くらい Learn を頑張って読んだ期間(修行)です。
 程度がわかってればたぶん半分くらいにできたはず。。。)。

  • 最短1週間。
    • Udemy の問題をやり込む時間です。英語の問題集なので、読むために適時翻訳をかけたりする必要があり1問1問に時間がかかります。
  • 理想は3週間。
    • 一定期間集中して時間が取れる想定です(1日3時間程度?)。
    • 前述の AZ-900 系の学習で基礎固めをする期間が2週間、問題をやり込む期間が1週間です。
      • AZ-900 も受験するなら追加で1週間ぐらいでしょうか(試験は受験料も高いし、緊張もするので可能なら別途時間を取ったほうが良いです)。

参考教材

関連して読んだもの。

おまけ

AZ-900 のときはなかったんですが、こんなん出てくるんですね。
1分野だけ普通なのなんか悔しいのですが(笑)。

f:id:jigoku1119:20210523114120j:plain

AZ-104(Microsoft Azure Administrator) 試験範囲(日本語訳)

まえがき

ほんとは受験が終わった後に使った学習コンテンツの情報と一緒に出すつもりだったんですが、 いつ受けるんですか?という具合に延期しまくっている状態なので中身が古くなる前にあげておきます (本音は放置してたサイトをとりあえず更新したかっただけです…) 。
で、いつ受けるんですか??(試験予約してから延長が1か月に突入中)

概要

Exam AZ-104: Microsoft Azure Administrator - Learn | Microsoft Docs
に記載の試験範囲の詳細を記載した pdf の抜粋(の日本語機械翻訳)。
試験範囲を確認したかったけど、一目見て日本語でどうぞになった人用(僕)。

前提条件

  • 2021/03/26 の更新分を対象にする。
  • 3/26 の更新前後で出題割合が変わったものは末尾に差分の数値を記載。下記が変わっていた。
    • ストレージの作成と管理の割合が5%上昇。
    • Azure 計算資源の展開と管理、仮想ネットワークの構成と管理が5%ダウン(但し、もともと両者の割合は大きい)。
    • 細かい内容の比較は途中で挫折したけど、文言やら見た目が変わってただけで大きく変化はなかった印象。
  • 記載範囲は機械翻訳ベースなので必要に応じて原書を参照のこと(え。
  • コピペミスとかあったらすまぬ。。。

試験範囲

1. Azure アイデンティティおよびガバナンスの管理 (15-20%)

Azure AD オブジェクトを管理

  • ユーザーとグループを作成する
  • ユーザーとグループのプロパティを管理する
  • バイス設定の管理
  • 一括ユーザー更新を実行する
  • ストアカウントの管理
  • Azure AD Joinを構成する
  • セルフサービスパスワードリセットの構成

役割ベースのアクセス制御(RBAC)を管理

  • カスタムロールを作成する
  • Azure リソースへのアクセスを提供するために異なるスコープでのロールの割り当て
  • アクセス割り当ての解釈

サブスクリプションとガバナンスの管理

  • Azure ポリシーの設定
  • リソースロックの設定
  • リソースへのタグの適用と管理
  • リソースグループの管理
  • サブスクリプションの管理
  • コストの管理
  • 管理グループの設定

2. ストレージの作成と管理 (15-20%) ↑5%アップ

ストレージの保護

  • ストレージアカウントへのネットワークアクセスの設定
  • ストレージアカウントの作成と構成
  • 共有アクセス署名(SASトークンの生成
  • アクセスキーの管理
  • ストレージアカウントにAzure AD認証を設定する
  • Azure Filesへのアクセスの設定

ストレージの管理

AzureファイルとAzure Blob Storageの構成

  • Azureファイル共有の作成
  • Azure File Syncサービスの作成と構成
  • Azure Blob Storageの構成
  • Azure Blob Storageのストレージ階層の構成
  • ブロブのライフサイクル管理の設定

3. Azure 計算資源の展開と管理 (20-25%) ↓5%ダウン

Azure Resource Managerテンプレートを使用した仮想マシンVM)のデプロイメントの自動化

  • Azure Resource Manager テンプレートの変更
  • 仮想ハードディスクテンプレートの設定
  • テンプレートからのデプロイ
  • Azure Resource Managerテンプレートとしてデプロイメントを保存
  • 仮想マシンエクステンションのデプロイ

VMの設定

  • Azure Disk Encryptionの設定
  • リソースグループ間でのVMの移動
  • VMサイズの管理
  • データディスクの追加
  • ネットワークの設定
  • VMの再配置
  • 高可用性の設定
  • スケールセットの導入と構成

コンテナの作成と構成

Azure App Serviceの作成と構成

  • App Service プランの作成
  • App Service プランでのスケーリング設定の構成
  • App Service の作成
  • App Service の保護
  • カスタム ドメイン名の設定
  • App Serviceのバックアップの設定
  • ネットワーク設定の構成
  • デプロイメント設定を行う

4. 仮想ネットワークの構成と管理 (25-30%)↓5%ダウン

仮想ネットワークの導入と管理

  • ピアリングを含む、仮想ネットワークの作成と設定
  • プライベートおよびパブリックIPアドレスの設定
  • ユーザー定義のネットワークルートの設定
  • サブネットの実装
  • サブネット上のエンドポイントの設定
  • プライベートエンドポイントの設定
  • カスタムDNS設定、プライベートまたはパブリックDNSゾーンを含む、Azure DNSの設定

仮想ネットワークへのセキュアなアクセス

  • セキュリティルールの作成
  • ネットワークセキュリティグループ(NSG)をサブネットまたはネットワークインタフェースに関連付ける
  • 効果的なセキュリティルールの評価
  • Azure Firewallの実装
  • Azure Bastion Serviceの実装

ロードバランシングの設定

仮想ネットワークの監視とトラブルシューティング

オンプレミスのネットワークとAzureの仮想ネットワークの統合

  • Azure VPN Gatewayの作成と構成
  • Azure Expreの作成と構成
  • Azure仮想WANの構築

5. Azure 資源の監視とバックアップ (10-15%)

Azure Monitorを使ったリソースの監視

  • メトリクスの設定と解釈
  • Azure Monitorログの設定
  • ログの照会と分析
  • アラートとアクションの設定
  • Application Insightsの設定

バックアップとリカバリーの実装

  • リカバリーサービスのデータ保管庫の作成
  • バックアップポリシーの作成と設定
  • Azure Backupを使ったバックアップとリストアの実行
  • Azure Site Recoveryを用いたサイト間リカバリーの実行
  • バックアップレポートの設定とレビュー

参考サイト

情報収集する過程でお世話になったサイト。