DevOps Engineer – Professional 試験で間違えやすいポイント集 後半

間違えやすいポイント集 後半です。
前半：https://iret.media/138635
後半：https://iret.media/138658

対象者

DOP（AWS Certified DevOps Engineer ）を勉強している人に向けて、ここ間違いやすいよってところをサービスごとに注記していきます。(2025年1月時点)
結構な量になったので記事を2分割とし、
前半はCodeDeployなどCode三兄弟とCloudFormationについて記載
後半は上記以外のAutoScalingやALBなどその他サービスについて記載。
また、情報を参考にする上での注意点を記事の最後に記載していますので、気になる方はそちらをご確認ください。

EC2

StatusCheckFailed_System メトリクス

以下を検出可能

• ネットワーク接続の喪失
• システム電源の喪失
• 物理ホストのソフトウェアの問題
• ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

Image Builder

AMIのディストリビューションがあり、これを変えたらAutoScalingグループの更新が可能
具体的には、EC2 Image Builder は、標準的なコンテナベースイメージを自動で構築、検証、公開できるサービス

Dedicated Instance とは

EC2インスタンスはAWS側で任意の物理サーバの上で起動する、その為、物理サーバ上のインスタンスには別アカウントのインスタンスも存在する。
しかし、ソフトウェアのライセンス等で物理サーバを専有したい場合があり、その際に使用する。
別アカウントのEC2インスタンスが同じサーバ上で起動しないことを保証する のが Dedicated Instance です。

Dedicated Hosts とは

Dedicated Hosts は Dedicated Instance の上位版といったイメージです。
Dedicated Instance では、別アカウントのEC2インスタンスが同じサーバ上で起動しないことを保証するが、同じアカウントのインスタンスを同じ物理サーバ上で起動させることができない。
しかし、Dedicated Hosts では 物理サーバでのインスタンスの配置を制御することができます。

S3

S3 Object Lambda アクセスポイント

• データを取り出す時に画像の動的なサイズ変更、機密データの編集ができる

クロスリージョンレプリケーション

数時間かかることもある。

Content-MD5パラメータとetagの違いについて

Content-MD5

• 概要:
  Content-MD5 ヘッダーは、リクエストやレスポンスボディの内容に対するMD5ハッシュを提供します。
• 目的:
  • データの整合性を検証するために使用されます。
  • サーバーとクライアント間で転送されるデータが途中で改ざんされていないかを確認します。
• 動作:
  • サーバーまたはクライアントは、ボディの内容からMD5ハッシュを計算し、それをヘッダーに設定します。
  • 受信側が同じ方法でハッシュを計算し、ヘッダー値と一致するかをチェックします。
• 主な特徴:
  • 計算されたMD5ハッシュ値はボディ全体に基づいており、データの完全性確認が主な目的。
  • データが変更されていると、ハッシュが一致しないためエラーが発生します。
• 例:上記はボディ内容のMD5ハッシュをBase64エンコードしたもの。

  Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
  
  

2. ETag

• 概要:
  ETag (エンティティタグ) ヘッダーは、リソースのバージョンや状態を表す一意の識別子です。
• 目的:
  • キャッシュの制御や状態の追跡を目的に使用されます。
  • リソースが変更されているかどうかを効率的に確認します。
• 動作:
  • サーバーはリソースの状態を表す識別子（ハッシュ、タイムスタンプ、バージョンIDなど）を生成し、レスポンスに含めます。
  • クライアントは If-None-Match ヘッダーを使用して、ETagを送信し、サーバーにリソースの変更を確認します。
• 主な特徴:
  • データの完全性確認ではなく、リソースの変更検知が主な目的。
  • 同じリソースであればETagは一致し、変更があれば新しいETagが生成されます。
• 例:上記はリソースを識別するための一意の識別子。

  ETag: "686897696a7c876b7e"
  

MD5とETagの違い

Object lambda アクセスポイント

データを動的変換する便利機能

マルチリージョンアクセスコントロール

S3の双方向レプリケーションには関与しない

PIIとは

PII（個人を特定できる情報）
Personally Identifiable Information

Route 53

Route 53 の「ヘルスチェックとフェイルオーバールール」

Route 53 の「計算ヘルスチェック」では、複数のヘルスチェックを組み合わせて条件（ATLEAST など）を設定できます。

AWS Config

Config コンフォーマンスパックとは？

概要：
AWS Configルールと修復アクションのセットをパッケージ化したもの。
複数のAWS Configルールやカスタムルールを一括で適用できる。
主にセキュリティやコンプライアンス基準に基づいた設定を簡単に適用するために設計されています。
修復アクションの設定が容易なので、そういうものに比重を置くときは良い

Config コンフォーマンスパックを選ぶべき場合

• 簡単に標準的なコンプライアンス基準を適用したい。
• AWSが提供する事前定義のルールセットを利用したい。
• セキュリティやコンプライアンスの基準を迅速に満たす必要がある。

CloudFormation スタックを選ぶべき場合

• AWS Config以外のリソース（IAM、Lambda、S3など）も同時に管理したい。
• 高度なカスタマイズが必要（カスタムルールや複雑な修復アクションを定義する）。
• インフラ全体をコードベースで管理する必要がある。

AWS CloudFormation スタックのドリフトを検出

AWS Config は、AWS リソースの設定変更を監視および評価するサービスであり、AWS CloudFormation スタックのドリフトを検出して通知することができます。

クロスリソース参照例：

  "Resources" : {
    "WebServerInstance": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "InstanceType"   : "t2.micro",
        "NetworkInterfaces" : [{
          "SubnetId" : { "Fn::ImportValue" : "SampleSubnet" },
          "GroupSet" : [ { "Fn::ImportValue" : "SampleSG" } } ],
            :(略)

テンプレート制約 (Template Constraints) と 起動制約 (Launch Constraints) の違い

AWS Service Catalogにおける テンプレート制約 (Template Constraints) と 起動制約 (Launch Constraints) の違いは、それぞれが制約する対象にあります。

テンプレート制約例

テンプレートで設定できるオプションを羅列する仕組み

Parameters:
  InstanceType:
    Description: "EC2 Instance Type"
    Type: String
    AllowedValues:
      - t2.micro
      - t2.small
      - t2.medium
    Default: t2.micro

起動制約例

{
  "LaunchRole": "arn:aws:iam::123456789012:role/ServiceCatalogLaunchRole"
}

require-tagsマネージドルール

リソースに特定のタグがあるかを検出できるマネージドルール

Systems Manager

Systems Manager State Manager

オペレーティングシステムの円滑な適用が可能

Systems Manager Compliance

コンテナリポジトリの脆弱性を発見する機能はないので、Inspectorなどが適切

Inspector

Amazon Inspector を使用した Amazon EC2 インスタンスのスキャン
Amazon EC2 インスタンスに対して脆弱性スキャンを実行するために、AWS Systems Manager エージェント(SSM Agent) のインストールと動作、ポート 443 でのアウトバウンド通信の許可、そして Aws Systems Manager との通信に対するアクセス許可が必要となる

• Amazon Inspector がスキャンしていない EC2 インスタンスに AWS Systems Manager エージェント（SSM Agent) がインストールされていること
• ターゲット EC2インスタンスに、AWs Systems Manager サービスのエンドポイントへのポート 443 でのアウトバウンド通信を許可するセキュリティグループを関連付けられていること
• ターゲット EC2 インスタンスに、AWS Systems Manager と通信するためのアクセス許可を付与するインスタンスプロファイルを関連付いていること

Systems Manager Document

SSM Automation ドキュメント

configから非準拠リソースの自動修復が可能

CloudTrail

サービスの検知であり、ルートユーザーのログインなどを行うサービスではない

AWSSSODirectoryAdministratorとは？

AWS IAM Identity Center (旧AWS SSO) に関連する管理者ロール
主に AWS IAM Identity Center の設定や管理を行うための権限
AWS Organizations を利用したディレクトリ管理に関与する
IAM のポリシー管理やAWSアカウントの管理を目的としたロールではない

EventBridge 入力トランスフォーマー

jsonの形をちょっといじるなどに有効、
大規模なデータ変更に使うものではない

IAM

iam:passroleとiam:assumeroleの違いは？

Auto Scaling

AWS Auto Scaling のスポットインスタンスの配分戦略 Capacity Optimized
スポット価格と中断率の両方を考慮するいい塩梅の戦略

UpdatePolicy 属性、WaitOnResourceSignals

AWS CloudFormation がリソースの設定を待つように設定する必要があり、これはWaitOnResourceSignals と ヘルパースクリプトを使用して行うことができる。
具体的には、AWS CloudFormation は、AWS リソースのプロビジョニングと管理を自動化するためのサービスです。しかし、リソースが正しく設定されているかどうかを CloudFormation 自体が判断することはできません。これは特に、ユーザーデータを用いて設定を行う EC2インスタンスなどのリソースにおいて問題となります。
この問題を解決するために、CloudFormation は WaitOnResourceSignals というオプションを提供しています。これを使用すると、CloudFormation は特定のリソースの設定が完了するのを待つことができます。設定の完了は、ヘルパースクリプト を使用してリソースから CloudFormation に通知されます。

DevOps エンジニアは ヘルパースクリプトを使用して、ユーザーデータの実行が正常に終了したかどうかを CloudFormation に通知できます。さらに、WaitOnResourceSignals の UpdatePolicy を使用して、CloudFormation がリソースの設定を待つようにすることができます。これらの設定により、ユーザーデータの実行が正常に終了しなかった場合に、CloudFormation のデプロイが失敗するようにすることが可能です。

Auto Scalingのウォームプール

起動時間短縮の具体例
通常、新規インスタンスを起動する場合：
1. EC2インスタンスのプロビジョニング（数分）
2. OSとアプリケーションの初期化（追加の数分）
3. 必要な設定の適用（IAMロール、セキュリティグループなど）

Stopped 状態のウォームプールを利用する場合：
1. インスタンスの再起動（通常30秒〜1分程度）
2. 短縮された初期化（アプリケーションは既に基本設定済み）

結論

Stopped 状態のウォームプールインスタンスは、完全な新規インスタンスの起動よりも大幅に起動時間を短縮できます。完全に Running 状態 ではないため即時応答性は低いですが、コスト効率とある程度のスケールアウト速度を両立したい場合には非常に有効な選択肢です。

終了保護しての調査

Amazon EC2 Auto Scaling では、異常なインスタンスをデバッグする際に、インスタンスをスタンバイ状態にすることが推奨されています。スタンバイ状態にすることで、インスタンスが終了されず、開発者が問題の原因を特定するためにログインして調査することができます。

Capacity Optimized vs Diversifiedの違い

Amazon EC2 Auto Scaling のライフサイクルフック

ライフサイクルフックを利用して、新しいインスタンスを Pending：Wait 状態に保持する

これにより、カスタムスクリプトによる監査サービスへの登録が成功または失敗した結果を Amazon EC2 Auto Scaling グループにフィードバックすることが可能となります。
具体的には、このフィードバックを利用し、Amazon EC2 Auto Scaling グループは新しい Amazon EC2 インスタンスへのトラフィックの送信を開始したり、Amazon EC2 インスタンスを終了したりします。
ライフサイクルフックは、新しいインスタンスの状態を Pending:Wait にすることが可能で、これにより Amazon EC2 Auto Scaling グループの操作が一時停止します。
ここでカスタムスクリプトを呼び出してインスタンスを会社の監査サービスに登録することが可能となります。
このカスタムスクリプトが成功した場合、ライフサイクルアクションはCONTINUE値で完了し、新しいインスタンスへのトラフィックの送信が開始されます。
方、スクリプトが失敗した場合、ライフサイクルアクションはABANDON 値で完了し、該当の Amazon EC2インスタンスは終了します。
このような方法で、Amazon EC2 Auto Scaling グループはカスタムスクリプトの結果に基づいて適切なアクションを取ることが可能となります。

※Amazon EC2 Auto Scaling のライフサイクルフック
Amazon EC2 Auto Scaling は、Auto Scaling グループにライフサイクルフックを追加する機能を提供します。これらのフックにより、Auto Scaling インスタンスライフサイクルのイベントを認識し、対応するライフサイクルイベントが発生したときにカスタムアクションを実行するソリューションを作成できます。ライフサイクルフックでは、インスタンスが次の状態に移行する前に、ライフサイクルアクションの完了を待つ時間（デフォルトでは1時間）が指定されます。

RDS

自動バックアップ

1日1回行われる

Aurora

Aurora クラスターのカスタム ANY エンドポイント

クラスター配下の特定のインスタンスを紐付けることができるエンドポイント

マルチクラスター

これは同じリージョンにある必要がある
異なるリージョンで可用性を高めたいならグローバルデータベースを使用する必要がある。
ALBに関しても、リージョナルリソースとなる。

Amazon API Gateway

REST API の相互 TLS 認証の設定

プライベート認証局（CA）を利用することで実現可能
プライベートCAをS3におくことで実現も可能
クライアント証明書ではない。

Amazon Detective

不正なアクティビティは検出しない、特定の検出結果に関連する分析情報を提供するもの

AWS Config

awsで、desired instance typeで特定のamiのみを指定することは可能？
→可能、自動修復も可能

CloudWatch 複合アラーム

CloudWatch 複合アラーム

複数条件でアラームの設定が可能

設定レコーダー

• 設定レコーダーは、サポートされるリソースの設定を設定項目としてアカウントに保存
• 記録を開始する前に、設定レコーダーを作成して起動する
• デフォルトではAWS Configが実行されているリージョンのすべてのサポートされているリソースを記録
• 指定したリソースタイプのみを記録することも可

CodeGuru

CodeGuru Profiler

ランタイムパフォーマンスの検証が可能なサービス

CodeGuru Reviewer

秘匿情報が入っているかなどの検出が可能

Firewall Manager

Firewall Manager には、次のような利点があります。

• アカウント間でリソースを保護するのに役立ちます
• すべての Amazon CloudFront ディストリビューションなど、特定のタイプのすべてのリソースを保護するのに役立ちます
• 特定のタグですべてのリソースを保護するのに役立ちます
• アカウントに追加されたリソースへの保護を自動的に追加します
• AWS Organizations 組織内のすべてのメンバーアカウントを Aws Shield Advanced に登録することができ、組織に参加する新しい対象アカウントを自動的に登録することができます
• AWS Organizations 組織内のすべてのメンバーアカウントまたはアカウントの特定のサブセットにセキュリティグループルールを適用し、組織に参加する新しい範囲内アカウントにルールを自動的に適用できます。
• 独自のルールを使用したり、AWS Marketplace からマネージドルールを購入したりできます

AWS FirewallManager を使用することで、Application Load Balancer (ALB) と Amazon API Gateway APIに対して AWS WAF のウェブ ACL を一元的に管理し、
新しく作成されたリソースに自動的にアタッチすることができる

Organizations 対応

AWS FirewallManager は AWS Organizations に対応しており、セキュリティアカウントを指定して組織全体のセキュリティポリシーを中央で管理することができます。
したがって、セキュリティチームは Firewal Manager を使用して、組織内のすべてのアカウントで ALB と API Gateway API に WAF のウェブ ACLを関連付けることが可能です。
AWS FirewallManager を使用すると、ALB や API Gateway API などの新しく作成されたリソースに対して、自動的に AWS WAF のウェブ ACL をアタッチするポリシーを作成することができます。
これにより、新たにリソースが作成された際も、自動的に適切なウェブ ACL が関連付けられ、セキュリティ維持に役立ちます。

AWS WAF

AWS WAF Web Acl

対象リソースとアクションとルールを指定してブロック、ALLOWするもの

• リソースタイプ
• デフォルトアクション

Application Load Balancer (ALB)

アクセスログは基本S3に書き込む形になる。
CloudWatch に書き込む設定はむずかしい

NATゲートウェイ

複数のアベイラビリティゾーンを跨ぐ形では作れないので、1アベイラビリティゾーンに対して1個作る

CloudWatch

CloudWatch Logs サブスクリプションフィルター

ルートユーザーのログインイベントに一致する CloudWatch Logs サブスクリプションフィルターを作成可能。
「CloudWatch Logs サブスクリプションフィルター」はログデータを他のサービスやストリームに継続的に転送するための機能

OpenID Connect (OIDC)

OpenID Connect フェデレーション用のロールを作成する方法（コンソール）
・既存の IdP からプロバイダー URL、対象ユーザー、署名を使用して IAM ldP を作成します。
→AWS IAM でldP を設定することで、既存のIdPと AWS IAM を連携させることが可能です。これにより、認証情報を使用して Amazon S3へのアクセスを制御し、必要なリソースに対するセキュリティを確保できます。
・必要なS3 アクションを許可するポリシーを持つIAM ロールを作成します。auth.company.com:aud コンテキストキーが appid from idp の場合、OIDC IPがロールを引き受けることを許可するようにロールの信頼ポリシーを構成します。
→「AWS IAM ロール」の信頼ポリシーを設定して、auth.company.com:audコンテキストキーがappid_from_idp である場合にOIDC ldP がロールを引き受けることを許可することで、外部の認証プロバイダーを通じて AWS アカウントへのセキュアなアクセス
を実現します。
・ AssumeRolewithwebIdentity API オペレーションを使用することで、OIDC IP を利用した認証情報を取得し、一時的なアクセスを Amazon S3 に対して行います。
GetFederationToken API は 【AM ユーザーの一時的な認証情報を取得するためのもの

AWS Health

AWSサービス全体の健全性を見ている

GuardDuty

SNSと連携させるにはEvent bridgeが必要

EFS

EFSアクセスポリシー例

{
  "Version": "2012-10-17",
  "Id": "efs-policy-wizard-*****-f36e-442b-aea0-3c4988ad3c53",
  "Statement": [
    {
      "Sid": "efs-statement-*****-0404-435e-9abb-2590ea9df0e0",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientMount"
      ],
      "Condition": {
        "Bool": {
          "elasticfilesystem:AccessedViaMountTarget": "true"
        }
      }
    },
    {
      "Sid": "efs-statement-*****-75bd-4d75-9ec3-ad76c4fd832d",
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    },
    {
      "Sid": "efs-statement-*****-71de-4c1b-8685-783e67f34def",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "elasticfilesystem:ClientMount"
      ]
    }
  ]
}

EFSファイルシステムポリシーでアカウントBのアクセスを許容する設定の例

"Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_B_ID:root"
      },

Reflesh cache

直接S3に配置されたオブジェクトにも対応できるようにする仕組み

Athena

CloudWatch　をデータソースにはできない
S3が主なデータソース

Redis

Redis のクラスターのリードレプリカエンドポイントよりクラスターの設定エンドポイントを使用することが推奨される理由

Redis クラスターにおいて リードレプリカエンドポイント ではなく クラスターの設定エンドポイント を使用することが推奨される理由はいくつかあります。以下にその背景と利点を説明します。

1. クラスター構成変更への耐性

• リードレプリカエンドポイント:
  • 個々のノードに直接接続するため、そのノードに障害が発生すると接続が失われます。
  • クラスターの再構成やフェイルオーバーが発生した場合、新しいリードレプリカを手動で検出して切り替える必要があります。
• クラスターの設定エンドポイント:
  • クラスター全体を抽象化して一つのエンドポイントを提供。
  • 内部で適切なノードにルーティングを行うため、フェイルオーバーやリードレプリカの追加・削除が透過的に処理されます。
  • アプリケーションはクラスターの内部構成に依存せず、接続先を常に安定して保つことができます。

2. 負荷分散

• リードレプリカエンドポイント:
  • 特定のリードレプリカにしか接続できず、負荷分散がアプリケーションに依存します。
  • 高負荷のワークロードではスケーラビリティが制限される場合があります。
• クラスターの設定エンドポイント:
  • クラスター内の複数のリードレプリカに自動的にリクエストを分散。
  • 負荷のバランスを効率的に保つことができ、クラスターのスケーラビリティを最大限活用できます。

3. フェイルオーバーの自動化

• リードレプリカエンドポイント:
  • 特定のノードが障害を起こすと接続が切れるため、アプリケーション側で手動でエンドポイントを切り替える必要があります。
• クラスターの設定エンドポイント:
  • フェイルオーバー時に、自動的に新しいマスターやリードレプリカにルーティングが変更されます。
  • アプリケーションはエンドポイントを気にせず、透過的に接続を維持できます。

AWS Lambda

lambdaオーソライザー例：

token == ‘abc’:検証パターン

import json
from logging import getLogger, INFO

logger = getLogger(__name__)
logger.setLevel(INFO)

def lambda_handler(event, context):
    print("============ event の出力 ============")
    logger.info(json.dumps(event))

    token = event['authorizationToken']
    effect = 'Deny'
    if token == 'abc':
        effect = 'Allow'

    return {
        'principalId': '*',
        'policyDocument': {
            'Version': '2012-10-17',
            'Statement': [
                {
                    'Action': 'execute-api:Invoke',
                    'Effect': effect,
                    'Resource': event['methodArn']
                }
            ]
        }
    }

Amazon Kinesis Data Streams

拡張ファンアウトおよびシャード数の関係イメージ

バッチサイズ

バッチサイズを増加させると、Lambda 関数が一度に処理するレコード数が増えます。その結果、各バッチの処理時間が長くなり、データの取り込みから処理までのレイテンシーが増加する

SQS

ReportBatchItemFailures の概要

• 目的: Lambda関数がバッチ処理中に失敗したアイテムだけを再試行対象としてマークする。
• 対象サービス: 主にSQSとKinesisイベントソースで利用されます。

Lambdaの「キュー可視性タイムアウト（Visibility Timeout）」は、Amazon SQS（Simple Queue Service）とLambdaの統合に関連する重要な概念

可視性タイムアウトの概要

• 目的: SQSキューのメッセージが消費された後に、再度別の消費者から見えるようになるまでの時間を設定。
• 動作:

1. LambdaがSQSからメッセージを取得すると、そのメッセージは「一時的に非表示」になります（可視性タイムアウト）。
2. 非表示期間内にLambdaがメッセージを処理し、成功または失敗をSQSに通知します。

• 成功: メッセージは削除されます。
• 失敗: メッセージは再試行の対象になります。

1. 可視性タイムアウト期間が経過すると、メッセージは再び他の消費者から見えるようになります。

注意

この記事はAWSのサービスの関係や全体像を簡略に理解するため、
少しサービス名を省略表記しているものもあるかもしれませんがご了承ください。
また、AWS自体常にアップデートするものため、2025/02月時点での情報を書いているつもりですが、
最新の情報はあくまで自己責任でお調べいただければと思います。