AWS M&G Vol2｜Config×Systems Manager×Trusted Advisor×Health

なぜ Management & Governance Vol2 か — ガバナンス実行監視層概観

Vol1では、AWSエンタープライズ環境の「組織基盤層」を確立した。AWS Organizations でマルチアカウント構造を設計し、Control Tower でランディングゾーンを標準化し、Service Catalog で承認済みリソースを配布し、CloudTrail Lake で監査ログを集約した。つまり「統制する・標準化する・監査する」インフラを整えた。

しかし、基盤が整った後こそ、運用の本番が始まる。本番環境では毎日無数のリソース変更が発生し、パッチ未適用のインスタンスが生まれ、コスト超過アラートが積み重なり、AWSサービス障害が突然やってくる。これらに組織的・自動的に対応する能力こそ、ガバナンス実行監視層が担う領域だ。

Vol2が扱う4サービスは、それぞれ明確な役割分担で実行監視層を構成する:

これら4サービスを単独で使うのではなく、Config → 修復 → Systems Manager実行 → Advisor確認 → Health監視という統合ワークフローとして設計することで、人手を最小化した自律的なガバナンス運用が実現する。

M&G Vol1（組織基盤層）を読了済みの方は、Vol1で構築した Organizations / Control Tower の組織構造が、本記事の Config Aggregator やTrusted Advisor Organizational View でそのまま活かされることが分かるだろう。Vol1 → Vol2 の順で理解を積み上げることで、エンタープライズガバナンスの全体像が完成する。

本記事では、各サービスの本番運用で必要な実践ノウハウに焦点を絞る。公式ドキュメントには書かれていない「詰まりポイント」と「アンチパターン→正解パターン変換」も§6で網羅する。Cloud Architect / Operations Engineer が明日から使える設計判断軸を提供することを目標とする。

AWS Config 本番運用 — Config Rules / Conformance Packs / 自動修復 / Aggregator

sequenceDiagram
 participant Resource as AWSリソース
 participant Config as AWS Config
 participant Rule as Config Rule
 participant SNS as SNS通知
 participant SSM as Systems Manager
 Resource->>Config: 設定変更検出
 Config->>Rule: ルール評価
 Rule-->>SNS: NON_COMPLIANT通知
 Rule->>SSM: 自動修復アクション実行
 Note over Rule,SSM: Conformance Packで<br/>ルール一括管理

Configuration Recorder — Config 記録の基盤設定

AWS Config を有効活用する前提として、Configuration Recorder を適切に設定する必要がある。Configuration Recorder がリソース設定変更を記録することで、Config Rules 評価とコンプライアンス管理の土台が確立される。

# Configuration Recorder 設定 (主要リソースタイプに絞り込む)
aws configservice put-configuration-recorder \
  --configuration-recorder '{
 "name": "default",
 "roleARN": "arn:aws:iam::123456789012:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig",
 "recordingGroup": {
"allSupported": false,
"resourceTypes": [
  "AWS::EC2::Instance",
  "AWS::EC2::SecurityGroup",
  "AWS::EC2::VPC",
  "AWS::S3::Bucket",
  "AWS::IAM::Role",
  "AWS::RDS::DBInstance"
]
 }
  }'

# Delivery Channel 設定 (設定履歴の S3 保存先)
aws configservice put-delivery-channel \
  --delivery-channel '{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "configSnapshotDeliveryProperties": {
"deliveryFrequency": "TwentyFour_Hours"
 }
  }'

deliveryFrequency: TwentyFour_Hours は Configuration Snapshot（全リソースの設定スナップショット）の配信間隔だ。PERIODIC 評価モードの Config Rules はこのスナップショット配信タイミングで評価が走る点に注意が必要だ。

Config Rules — マネージドルールとカスタムルール

Config Rules は「あるべき状態」を定義する評価エンジンだ。マネージドルール（AWS 提供） と カスタムルール（ユーザー定義） の2種類がある。

# required-tags ルール: 全 EC2 / RDS に Environment・Owner タグを必須化
aws configservice put-config-rule \
  --config-rule '{
 "ConfigRuleName": "required-tags-production",
 "Source": {
"Owner": "AWS",
"SourceIdentifier": "REQUIRED_TAGS"
 },
 "Scope": {
"ComplianceResourceTypes": ["AWS::EC2::Instance", "AWS::RDS::DBInstance"]
 },
 "InputParameters": "{\"tag1Key\":\"Environment\",\"tag2Key\":\"Owner\"}"
  }'

# restricted-ssh ルール: Security Group の SSH 開放を検知
aws configservice put-config-rule \
  --config-rule '{
 "ConfigRuleName": "restricted-ssh",
 "Source": {
"Owner": "AWS",
"SourceIdentifier": "INCOMING_SSH_DISABLED"
 },
 "Scope": {
"ComplianceResourceTypes": ["AWS::EC2::SecurityGroup"]
 }
  }'

評価モード — CHANGE vs PERIODIC の使い分け

Config Rules の評価モードは、変更トリガー と 定期的 の2種類から選択する。ルールの特性に合わせて正しいモードを選択することが、検出精度とコスト最適化の両立に直結する。

コスト観点: PERIODIC を One_Hour に設定すると評価回数が TwentyFour_Hours の24倍になる。変更頻度の低い設定チェックは必ず TwentyFour_Hours に設定することで評価コストを大幅に削減できる。

カスタムルール — Lambda と AWS CloudFormation Guard

マネージドルールで対応できない組織固有のポリシーは、カスタムルール で実装する。実装方式は Lambda 関数と AWS CloudFormation Guard（Guard）の2種類がある。

Lambda カスタムルール実装例 (タグ命名規則チェック):

import json
import boto3

config = boto3.client('config')

def evaluate_compliance(configuration_item, rule_parameters):
 tags = configuration_item.get('tags', {})
 environment = tags.get('Environment', '')
 valid_envs = ['production', 'staging', 'development']
 if environment.lower() not in valid_envs:
  return {
'compliance_type': 'NON_COMPLIANT',
'annotation': f"Environment tag '{environment}' must be one of {valid_envs}"
  }
 return {'compliance_type': 'COMPLIANT', 'annotation': 'Tag naming convention is correct'}

def lambda_handler(event, context):
 invoking_event = json.loads(event['invokingEvent'])
 configuration_item = invoking_event.get('configurationItem', {})

 evaluation = evaluate_compliance(configuration_item, {})

 config.put_evaluations(
  Evaluations=[{
'ComplianceResourceType': configuration_item['resourceType'],
'ComplianceResourceId': configuration_item['resourceId'],
'ComplianceType': evaluation['compliance_type'],
'Annotation': evaluation['annotation'],
'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
  }],
  ResultToken=event['resultToken']
 )

Conformance Packs — 規制対応ルールの一括管理

Conformance Pack は、複数の Config Rules をテンプレートとして束ねて一括デプロイする機能だ。CIS Benchmark・PCI DSS・NIST などの規制フレームワークへの準拠を、AWS 提供サンプルテンプレートで迅速に実現できる。

AWS 提供サンプルテンプレート

# Conformance Pack のデプロイ (パラメータオーバーライドで設定値を調整)
aws configservice put-conformance-pack \
  --conformance-pack-name "CIS-Level1-Production" \
  --template-s3-uri "s3://my-config-bucket/conformance-packs/cis-level1.yaml" \
  --conformance-pack-input-parameters '[
 {"ParameterName": "AccessKeysRotatedParamMaxAccessKeyAge", "ParameterValue": "90"},
 {"ParameterName": "RequiredTagsParamTag1Key", "ParameterValue": "Environment"},
 {"ParameterName": "RequiredTagsParamTag2Key", "ParameterValue": "Owner"}
  ]'

# デプロイ状況確認
aws configservice describe-conformance-packs \
  --conformance-pack-names "CIS-Level1-Production" \
  --query 'ConformancePackDetails[0].ConformancePackState'

conformance-pack-input-parameters を省略するとパラメータにデフォルト値が使われるが、デフォルト値が存在しないパラメータは NOT_APPLICABLE または ERROR になる。必ずテンプレートの Parameters セクションを確認し、全パラメータに値を渡すこと。

組織レベルデプロイ (AWS Organizations 連携)

マルチアカウント環境では、管理アカウントから全メンバーアカウントに Conformance Pack を一括デプロイできる。

# 組織全体への Conformance Pack デプロイ (管理アカウントで実行)
aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name "Org-Security-Baseline" \
  --template-s3-uri "s3://my-config-bucket/org-conformance-pack.yaml" \
  --conformance-pack-input-parameters '[
 {"ParameterName": "MaxAccessKeyAge", "ParameterValue": "90"}
  ]' \
  --excluded-accounts '["111111111111"]'

# デプロイ状況確認 (全アカウント横断)
aws configservice describe-organization-conformance-pack-statuses \
  --organization-conformance-pack-names "Org-Security-Baseline"

--excluded-accounts で Sandbox アカウントや例外的な設定を持つアカウントを除外できる。

自動修復 (Remediation) — 非準拠の自動解消

Config Rule が NON_COMPLIANT を検出した際に、Systems Manager Automation ドキュメントと連携して自動修復を実行できる。修復の形式は自動修復と手動承認後修復の2種類がある。

自動修復設定

# restricted-ssh ルール: 非準拠 Security Group の自動修復
aws configservice put-remediation-configurations \
  --remediation-configurations '[{
 "ConfigRuleName": "restricted-ssh",
 "TargetType": "SSM_DOCUMENT",
 "TargetId": "AWS-DisablePublicAccessForSecurityGroup",
 "Parameters": {
"GroupId": {
  "ResourceValue": {"Value": "RESOURCE_ID"}
},
"AutomationAssumeRole": {
  "StaticValue": {
 "Values": ["arn:aws:iam::123456789012:role/ConfigRemediationRole"]
  }
}
 },
 "Automatic": true,
 "MaximumAutomaticAttempts": 3,
 "RetryAttemptSeconds": 60
  }]'

Automatic: true で自動修復が有効になる。MaximumAutomaticAttempts: 3 と RetryAttemptSeconds: 60 で、最大3回・60秒間隔のリトライを行う。

自動修復 vs 手動承認後修復の使い分け

本番環境では、可逆的で影響範囲が限定的な修復のみ自動化 し、データ削除・設定の大幅変更は手動承認フローを経るのが原則だ。

修復実行ログの確認

# 修復実行履歴の確認
aws configservice describe-remediation-execution-statuses \
  --config-rule-name "restricted-ssh"

# 修復失敗時の詳細ログ (Systems Manager Automation 実行ログと紐付け)
aws ssm describe-automation-executions \
  --filters Key=DocumentName,Values=AWS-DisablePublicAccessForSecurityGroup \
Key=ExecutionStatus,Values=Failed

修復に使用する AutomationAssumeRole の IAM ロールは最小権限で設計する。対象リソースへの最小限の Write 権限（例: ec2:RevokeSecurityGroupIngress のみ）を付与し、不要な管理者権限を与えないことが安全運用の基本だ。

Aggregator — マルチアカウント/マルチリージョン集約

Aggregator は、AWS Organizations 配下または個別指定した複数アカウント・複数リージョンの Config データを一箇所に集約する機能だ。管理アカウント（または委任管理者アカウント）から組織全体のコンプライアンス状況を一元把握できる。

# Organizations 連携の Aggregator 作成 (管理アカウントで実行)
aws configservice put-configuration-aggregator \
  --configuration-aggregator-name "OrgAggregator" \
  --organization-aggregation-source '{
 "RoleArn": "arn:aws:iam::123456789012:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig",
 "AllAwsRegions": true
  }'

# 全アカウントの非準拠リソースを SQL ライクなクエリで抽出
aws configservice select-aggregate-resource-config \
  --expression "SELECT resourceId, resourceType, accountId, awsRegion WHERE configuration.complianceType = 'NON_COMPLIANT'" \
  --configuration-aggregator-name "OrgAggregator"

AllAwsRegions: true で全リージョンのデータを集約する。特定リージョンのみ集約する AwsRegions 設定は、新リージョン追加時に抜け漏れが起きやすいため、基本的には AllAwsRegions: true を推奨する。

# Config の委任管理者を監査アカウントに設定 (管理アカウントで実行)
aws organizations register-delegated-administrator \
  --account-id 999999999999 \
  --service-principal config.amazonaws.com

Config Rules の料金最適化 — 評価回数制御

AWS Config の主要コストは、Configuration Item の記録回数 と Config Rules の評価回数 だ。大規模環境では両者が爆発的に増加するため、設計段階から最適化を組み込む必要がある。

評価コストの計算と削減施策

Config Rules のルール評価料金は $0.001 / 評価 だ（マネージドルール・カスタムルール共通）。

例: 100 ルール × 100 リソース × 毎日 1 回変更 = 10,000 評価 / 日 = $10 / 日

# 評価回数が多いルールを特定 (月次確認推奨)
aws configservice describe-config-rule-evaluation-status \
  --config-rule-names "required-tags-production" "restricted-ssh" \
  --query 'ConfigRulesEvaluationStatus[*].{Name:ConfigRuleName, LastSuccess:LastSuccessfulEvaluationTime}'

# PERIODIC ルールの評価頻度を TwentyFour_Hours に変更
aws configservice put-config-rule \
  --config-rule '{
 "ConfigRuleName": "root-account-mfa-enabled",
 "Source": {
"Owner": "AWS",
"SourceIdentifier": "ROOT_ACCOUNT_MFA_ENABLED",
"SourceDetails": [{
  "EventSource": "aws.config",
  "MessageType": "ScheduledNotification",
  "MaximumExecutionFrequency": "TwentyFour_Hours"
}]
 }
  }'

エンタープライズ環境では、Conformance Pack でルールを統一管理し、個別設定と Conformance Pack で同じチェックが二重に存在しないよう定期的に棚卸しすることが料金最適化の鍵となる。

AWS Systems Manager 本番運用 — Patch Manager / Run Command / State Manager / Parameter Store

AWS Systems Managerは、AWSリソースおよびオンプレミスサーバの運用管理を一元化するサービスです。Patch Manager・Run Command・State Manager・Parameter Store・Automation・Session Managerの6機能が、日常的なパッチ適用から設定管理・リモートアクセスまでをカバーします。

Patch Manager — パッチ自動化の中核機能

Patch Managerは、EC2インスタンスおよびオンプレミスサーバへのOSパッチ適用を自動化します。パッチベースライン・パッチグループ・メンテナンスウィンドウの3要素で構成されます。

パッチベースライン

パッチベースラインは、どのパッチを承認・拒否するかのルールセットです。AWS提供の定義済みベースラインとカスタムベースラインの2種類があります。

AWS提供パッチベースライン:

カスタムパッチベースライン例:

{
  "Name": "MyCustomBaseline",
  "OperatingSystem": "AMAZON_LINUX_2",
  "ApprovalRules": {
 "PatchRules": [
{
  "PatchFilterGroup": {
 "PatchFilters": [
{"Key": "CLASSIFICATION", "Values": ["Security", "Bugfix"]},
{"Key": "SEVERITY", "Values": ["Critical", "Important"]}
 ]
  },
  "ApproveAfterDays": 7,
  "ComplianceLevel": "HIGH"
}
 ]
  },
  "RejectedPatches": ["kernel-debug*"]
}

ApproveAfterDays: 7 はパッチリリースから7日後に自動承認することを意味します。本番環境では十分な検証期間を確保するため14〜30日に設定するケースが多いです。

パッチグループ — タグベースの対象分離

パッチグループは、インスタンスタグ Patch Group の値でベースラインに紐付けます。本番・ステージング・開発環境を分離して異なるベースラインを適用できます。

# インスタンスにパッチグループタグを付与
aws ec2 create-tags \
  --resources i-1234567890abcdef0 \
  --tags Key="Patch Group",Value="Production"

# パッチグループをベースラインに登録
aws ssm register-patch-baseline-for-patch-group \
  --baseline-id pb-0123456789abcdef0 \
  --patch-group "Production"

メンテナンスウィンドウ設定

メンテナンスウィンドウでパッチ適用の実行スケジュールを定義します。duration は実行可能時間 (時間)、cutoff はウィンドウ終了何時間前に新規タスク開始を停止するかを指定します。

# メンテナンスウィンドウ作成 (毎週日曜 2:00 AM JST)
aws ssm create-maintenance-window \
  --name "ProdPatchWindow" \
  --schedule "cron(0 17 ? * SAT *)" \
  --schedule-timezone "Asia/Tokyo" \
  --duration 4 \
  --cutoff 1 \
  --allow-unassociated-targets false

# パッチタスクをウィンドウに登録
aws ssm register-task-with-maintenance-window \
  --window-id mw-0123456789abcdef0 \
  --task-arn "arn:aws:ssm:ap-northeast-1::document/AWS-RunPatchBaseline" \
  --task-type RUN_COMMAND \
  --targets "Key=WindowTargetIds,Values=wt-0123456789abcdef0" \
  --task-invocation-parameters \
 'RunCommand={Parameters={Operation=["Install"],RebootOption=["RebootIfNeeded"]}}'

パッチコンプライアンスレポート

パッチ適用後のコンプライアンス状態をSystems Manager Compliance機能で確認します。AWS Configと連携することで、非準拠インスタンスの自動修復トリガーも設定できます。

# パッチコンプライアンスサマリー取得
aws ssm list-compliance-summaries \
  --filters Key=ComplianceType,Values=Patch

# 非準拠インスタンス一覧 (緊急対応が必要な項目)
aws ssm list-compliance-items \
  --filters "Key=ComplianceType,Values=Patch" \
"Key=Status,Values=NON_COMPLIANT" \
"Key=SEVERITY,Values=CRITICAL"

Run Command — SSH不要の一括コマンド実行

AWS Systems Manager Run Commandは、インスタンスへのSSH/RDP接続なしでコマンドを一括実行できます。出力はS3またはCloudWatch Logsに自動保存されます。

主要ドキュメント

ターゲット指定と実行制御

# タグベースで複数インスタンスに一括実行
aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=Production" \
  --parameters 'commands=["df -h", "free -m", "uptime"]' \
  --max-concurrency "20%" \
  --max-errors "5%" \
  --output-s3-bucket-name "my-ssm-output-bucket" \
  --output-s3-key-prefix "run-command-output/" \
  --cloud-watch-output-config \
 CloudWatchOutputEnabled=true,CloudWatchLogGroupName=/ssm/run-command

--max-concurrency "20%" は対象インスタンス総数の20%を同時実行します。本番環境では段階的展開のため10〜20%が推奨です。

State Manager — 設定状態の継続管理

State Managerは、インスタンスの設定状態を定義したアソシエーションで継続的に維持します。手動変更やドリフトを定期的に検出し、あるべき状態に自動修正します。

# アソシエーション作成 (必須パッケージ定期インストール確認)
aws ssm create-association \
  --association-name "EnsureRequiredPackagesInstalled" \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=Production" \
  --parameters 'commands=["yum install -y amazon-cloudwatch-agent", "systemctl enable amazon-cloudwatch-agent"]' \
  --schedule-expression "rate(1 day)" \
  --compliance-severity HIGH \
  --apply-only-at-cron-interval

# アソシエーション実行状況確認
aws ssm list-associations \
  --association-filter-list \
 "key=AssociationName,value=EnsureRequiredPackagesInstalled"

Parameter Store — 設定値と機密情報の一元管理

Parameter Storeは、設定値・APIキー・データベース接続情報を安全に管理します。アプリケーションからはAWS SDKで動的に取得でき、ハードコードを排除できます。

Standard vs Advanced パラメータ

SecureString — KMS暗号化による機密情報管理

# KMS暗号化パラメータの作成 (階層構造 /環境/サービス/キー名)
aws ssm put-parameter \
  --name "/prod/myapp/db/password" \
  --value "MySecretPassword123!" \
  --type SecureString \
  --key-id "arn:aws:kms:ap-northeast-1:123456789012:key/mrk-xxxxxxxx"

# 階層配下の全パラメータを復号して取得
aws ssm get-parameters-by-path \
  --path "/prod/myapp/" \
  --recursive \
  --with-decryption

パラメータポリシー (Advanced のみ)

Advanced パラメータではポリシーを設定して有効期限切れの通知を送信できます。

[
  {
 "Type": "Expiration",
 "Version": "1.0",
 "Attributes": {
"Timestamp": "2026-12-31T23:59:59.000Z"
 }
  },
  {
 "Type": "ExpirationNotification",
 "Version": "1.0",
 "Attributes": {
"Before": "15",
"Unit": "Days"
 }
  }
]

アプリケーションからの参照 (Python例)

import boto3

ssm = boto3.client('ssm', region_name='ap-northeast-1')

response = ssm.get_parameter(
 Name='/prod/myapp/db/password',
 WithDecryption=True
)
db_password = response['Parameter']['Value']

Automation — 定型運用手順の自動化

Systems Manager Automationは、複数ステップの運用手順をAutomationドキュメントとして定義し、自動実行します。ステップ間でデータを受け渡すことができ、承認ステップを組み込んで人的確認を強制することも可能です。

承認ステップ付きAutomationドキュメント

schemaVersion: '0.3'
description: '本番環境AMI作成 + 承認フロー'
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  InstanceId:
 type: String
 description: 'AMIを作成するインスタンスID'
  ApproverArn:
 type: String
 description: '承認者のARN (IAMユーザーまたはロール)'
mainSteps:
  - name: ApproveImageCreation
 action: aws:approve
 inputs:
NotificationArn: "{{ ApproverArn }}"
Message: "本番環境AMI作成を承認してください。インスタンス: {{ InstanceId }}"
MinRequiredApprovals: 1
Approvers:
  - "{{ ApproverArn }}"
 timeoutSeconds: 3600
  - name: CreateAMI
 action: aws:createImage
 inputs:
InstanceId: "{{ InstanceId }}"
ImageName: "prod-backup-{{ global:DATE_TIME }}"
NoReboot: false

Config修復アクション連携

Config Ruleが非準拠を検出した際にAutomationを自動実行します。

# Config修復アクション設定 (非準拠検出時にSSM Automationを自動実行)
aws configservice put-remediation-configurations \
  --remediation-configurations \
 ConfigRuleName=ec2-instance-no-public-ip,\
 TargetType=SSM_DOCUMENT,\
 TargetId=AWS-DisablePublicAccessForSecurityGroup,\
 Automatic=true,\
 MaximumAutomaticAttempts=3,\
 RetryAttemptSeconds=60

Session Manager — SSH不要のセキュアリモートアクセス

Session Managerは、SSHキーやパスポート開放なしでEC2インスタンスへのリモートアクセスを提供します。全セッションがS3またはCloudWatch Logsに記録され、監査証跡を確保できます。

セッションログ設定 (S3 + CloudWatch Logs)

# Systems Manager セッション設定の更新
aws ssm update-document \
  --name "SSM-SessionManagerRunShell" \
  --content '{
 "schemaVersion": "1.0",
 "description": "セッションマネージャー設定ドキュメント",
 "sessionType": "Standard_Stream",
 "inputs": {
"s3BucketName": "my-session-logs-bucket",
"s3KeyPrefix": "session-logs/",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "/aws/ssm/sessions",
"cloudWatchEncryptionEnabled": true,
"idleSessionTimeout": "20",
"kmsKeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/mrk-xxxxxxxx"
 }
  }' \
  --document-version "\$LATEST"

IAMポリシーによるアクセス制御

本番環境インスタンスへのアクセスを特定タグに限定するIAMポリシー例です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": ["ssm:StartSession"],
"Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/*",
"Condition": {
  "StringEquals": {
 "ssm:resourceTag/Environment": "Production"
  }
}
 },
 {
"Effect": "Allow",
"Action": [
  "ssm:TerminateSession",
  "ssm:ResumeSession"
],
"Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
 }
  ]
}

AWS Trusted Advisor 本番運用 — 5カテゴリチェック / 優先度設定 / EventBridge連携

AWS Trusted Advisorは、AWSのベストプラクティスに基づいてアカウントの状態を自動チェックするサービスです。コスト最適化・パフォーマンス・耐障害性・サービス制限・運用性の5カテゴリで推奨事項を提示します。Business/Enterprise Supportプランで全チェック項目にアクセスできます。

5カテゴリチェックの全体像

コスト最適化チェック

コスト最適化カテゴリは、未使用リソースやリザーブドインスタンスの推奨により、AWS利用コストを削減する具体的なアクションを提示します。

主要チェック項目:

耐障害性チェック

耐障害性カテゴリは、単一障害点の排除とデータ保護の観点からシステムの弱点を検出します。

# Trusted Advisor チェック結果をCLIで取得 (耐障害性カテゴリ)
aws support describe-trusted-advisor-checks \
  --language ja \
  --query "checks[?category=='fault_tolerance'].[id,name]" \
  --output table

# 特定チェックの詳細結果取得
aws support describe-trusted-advisor-check-result \
  --check-id "Pfx0RwqBli" \
  --language ja

主要チェック項目:

サービス制限チェック

サービス制限チェックは、各AWSサービスのクォータ使用率を監視します。使用率80%超でYellow、100%でRedと表示され、サービス停止を未然に防ぎます。

# サービス制限チェック結果 (使用率80%以上の項目を抽出)
aws support describe-trusted-advisor-check-summary \
  --check-ids eW7HH0l7J9 \
  --query "summaries[0].resourcesSummary"

チェック結果の優先度設定 — Red/Yellow/Green トリアージ

Trusted Advisorのチェック結果はRed・Yellow・Greenの3段階で表示されます。運用チームはこの優先度を基準にトリアージして対応を計画します。

トリアージ判断フレームワーク:

1. Redの優先順位付け — サービス制限Redは最優先 (クォータ超過でサービス停止リスク)
2. コスト最適化のROI評価 — 節約額とリソース変更コストを比較
3. 耐障害性Redの影響試算 — 障害発生時の想定影響範囲を確認
4. Yellowの積み上げ管理 — Yellow項目数を定期的にダッシュボードで可視化

Organizational View — 組織全体のチェック集約

Organizational Viewは、AWS Organizations配下の全メンバーアカウントのTrusted Advisorチェック結果を管理アカウントから一元確認できる機能です。

# 組織レポートを生成 (全メンバーアカウントのチェック結果)
aws support create-trusted-advisor-check-refresh-statuses \
  --check-ids "eW7HH0l7J9" "Qch7DwouX1" "DqdJqYeRm5"

# Organizational View レポートの作成 (管理アカウントから実行)
aws trustedadvisor list-organization-recommendations \
  --max-results 100

EventBridge連携 — チェック結果変更の自動通知

Trusted AdvisorのチェックステータスがGreen→Yellow→Redへ変化した際にEventBridgeイベントを発行し、Lambda・SNSで自動通知・自動対応を実現します。

{
  "source": ["aws.trustedadvisor"],
  "detail-type": ["Trusted Advisor Check Item Refreshed"],
  "detail": {
 "status": ["ERROR", "WARN"],
 "check-name": [
"Service Limits",
"Amazon EC2 Reserved Instance Optimization"
 ]
  }
}

EventBridgeルール + SNS通知の設定

# EventBridgeルール作成 (Trusted Advisor Red/Yellow検知)
aws events put-rule \
  --name "TrustedAdvisorAlertRule" \
  --event-pattern '{
 "source": ["aws.trustedadvisor"],
 "detail-type": ["Trusted Advisor Check Item Refreshed"],
 "detail": {
"status": ["ERROR", "WARN"]
 }
  }' \
  --state ENABLED

# SNSトピックをターゲットに設定
aws events put-targets \
  --rule "TrustedAdvisorAlertRule" \
  --targets '[
 {
"Id": "SNSTarget",
"Arn": "arn:aws:sns:ap-northeast-1:123456789012:TrustedAdvisorAlerts"
 }
  ]'

Lambda自動対応の実装例

import boto3
import json

def lambda_handler(event, context):
 detail = event['detail']
 check_name = detail.get('check-name', 'Unknown')
 status = detail.get('status', 'Unknown')
 affected_resources = detail.get('affected-resources', [])

 sns = boto3.client('sns')
 message = f"""
Trusted Advisor アラート
チェック名: {check_name}
ステータス: {status}
影響リソース数: {len(affected_resources)}
 """
 sns.publish(
  TopicArn='arn:aws:sns:ap-northeast-1:123456789012:TrustedAdvisorAlerts',
  Subject=f'[要対応] Trusted Advisor: {check_name}',
  Message=message
 )
 return {'statusCode': 200, 'body': 'Notification sent'}

Refresh自動化 — チェック結果の定期更新

Trusted AdvisorのチェックはデフォルトでAWSが自動更新しますが、APIを使って手動リフレッシュすることもできます。Business/Enterprise Supportでは5分ごとのリフレッシュが可能です。

import boto3
import time

def refresh_trusted_advisor_checks():
 support = boto3.client('support', region_name='us-east-1')

 checks = support.describe_trusted_advisor_checks(language='ja')
 check_ids = [c['id'] for c in checks['checks']]

 for check_id in check_ids:
  try:
support.refresh_trusted_advisor_check(checkId=check_id)
time.sleep(0.5)
  except support.exceptions.ThrottlingException:
time.sleep(5)
continue

 print(f"リフレッシュ要求送信完了: {len(check_ids)}件")

Lambda + EventBridge Schedulerで週次自動リフレッシュ

# EventBridge Scheduler でLambdaを週次実行
aws scheduler create-schedule \
  --name "WeeklyTrustedAdvisorRefresh" \
  --schedule-expression "cron(0 9 ? * MON *)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --target '{
 "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:RefreshTrustedAdvisor",
 "RoleArn": "arn:aws:iam::123456789012:role/SchedulerRole"
  }' \
  --flexible-time-window '{"Mode": "OFF"}'

Business/Enterprise Support プラン必須チェックの把握

全チェック項目はBusiness/Enterprise Supportプランが必要です。Developerプランではコアチェック6項目のみ利用可能です。

エンタープライズ環境ではBusinessプラン以上が実質必須です。月額費用を超えるコスト最適化提案が得られるケースも多く、ROIが高いサポートプランです。

AWS Health Dashboard 本番運用 — 障害検知 / EventBridge統合 / 自動対応フロー

sequenceDiagram
 participant AWS as AWSサービス
 participant Health as Health Dashboard
 participant EB as EventBridge
 participant Lambda as Lambda
 participant Slack as Slack/Teams
 AWS->>Health: サービスイベント発生
 Health->>EB: Health Event配信
 EB->>Lambda: イベントフィルタ→関数実行
 Lambda->>Slack: 障害通知送信
 Lambda->>Lambda: 自動対応実行
 Note over EB,Lambda: 組織ビューで<br/>マルチアカウント統合

Personal Health Dashboard — 2種類のイベントタイプ

AWS Health Dashboardは、アカウントおよびAWSサービス全体の健全性を可視化するサービスだ。運用の基本となるのが2種類のイベントタイプの使い分けである。

イベントカテゴリ (eventTypeCategory) は3種類:
– issue — サービス障害・可用性低下 (最優先対応)
– scheduledChange — メンテナンス・アップグレード予定
– accountNotification — アカウント設定変更・制限変更通知

影響を受けるリソース一覧の取得

Health APIはグローバルエンドポイントが存在せず、必ずus-east-1を指定する必要がある。他リージョンを指定してもイベント情報は返らない点が頻出の落とし穴だ。

# アクティブなHealth Eventを一覧
aws health describe-events \
  --filter '{"eventStatusCodes":["open","upcoming"]}' \
  --region us-east-1

# 特定イベントの影響リソース一覧
aws health describe-affected-entities \
  --filter '{
 "eventArns": [
"arn:aws:health:us-east-1::event/EC2/AWS_EC2_INSTANCE_ISSUE/EXAMPLE"
 ]
  }' \
  --region us-east-1

予定メンテナンス通知の管理

RDS・ElastiCache・Redshiftなどのマネージドサービスは、定期メンテナンスウィンドウに基づいて自動メンテナンスが実施される。scheduledChange イベントは通常7〜14日前から通知されるため、この期間内に以下を判断する。

• メンテナンスウィンドウの変更可否
• フェイルオーバーの事前準備
• 影響を受けるアプリケーションへの周知

# 予定メンテナンスイベントのみ抽出
aws health describe-events \
  --filter '{
 "eventTypeCategories": ["scheduledChange"],
 "eventStatusCodes": ["upcoming"]
  }' \
  --region us-east-1

EventBridge統合 — Health Eventの自動処理アーキテクチャ

Health EventはAmazon EventBridgeと直接統合できる。EventBridgeのHealth Eventルールは必ずus-east-1リージョンに作成する必要がある。他リージョンにルールを作成しても、Health Eventはキャプチャされない。

Health Eventパターンフィルタリング

特定サービス・特定カテゴリのイベントのみを処理するフィルタリングパターン:

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
 "service": ["EC2"],
 "eventTypeCategory": ["issue"],
 "eventTypeCode": ["AWS_EC2_INSTANCE_ISSUE"]
  }
}

組織内の全サービス・全カテゴリを包括的に監視するパターン:

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
 "eventTypeCategory": ["issue", "scheduledChange"],
 "eventStatusCode": ["open", "upcoming"]
  }
}

Lambda自動対応 — SNS/Slack通知連携

Health Eventを受信したLambdaがSlack Webhookへ通知を送信する実装:

import json
import os
import urllib.request

def lambda_handler(event, context):
 detail = event.get('detail', {})
 service = detail.get('service', 'Unknown')
 event_type_code = detail.get('eventTypeCode', 'Unknown')
 status = detail.get('statusCode', 'Unknown')
 region = event.get('region', 'Unknown')

 entities = detail.get('affectedEntities', [])
 resource_list = [e.get('entityValue', '') for e in entities[:5]]
 resource_text = ', '.join(resource_list) if resource_list else 'N/A (public event)'

 message = {
  "text": (
f":rotating_light: *AWS Health Alert*\n"
f"*Region:* {region}\n"
f"*Service:* {service}\n"
f"*EventType:* {event_type_code}\n"
f"*Status:* {status}\n"
f"*Affected Resources:* {resource_text}"
  )
 }

 webhook_url = os.environ['SLACK_WEBHOOK_URL']
 data = json.dumps(message).encode('utf-8')
 req = urllib.request.Request(
  webhook_url, data=data,
  headers={'Content-Type': 'application/json'}
 )
 resp = urllib.request.urlopen(req)
 return {'statusCode': 200, 'body': resp.read().decode()}

障害対応自動化 — ユースケース別実装パターン

EC2 Hardware Issue → 自動マイグレーション

ハードウェア障害予告通知から自動マイグレーションを実行するLambda。停止→再起動により別の物理ホストへ移行が完了する:

import boto3

def migrate_ec2_instance(instance_id, eip_allocation_id):
 ec2 = boto3.client('ec2')

 addresses = ec2.describe_addresses(
  Filters=[{'Name': 'instance-id', 'Values': [instance_id]}]
 )['Addresses']
 if addresses:
  ec2.disassociate_address(AssociationId=addresses[0]['AssociationId'])

 ec2.stop_instances(InstanceIds=[instance_id])
 ec2.get_waiter('instance_stopped').wait(InstanceIds=[instance_id])

 ec2.start_instances(InstanceIds=[instance_id])
 ec2.get_waiter('instance_running').wait(InstanceIds=[instance_id])

 ec2.associate_address(InstanceId=instance_id, AllocationId=eip_allocation_id)
 return f"Migration completed for {instance_id}"

RDS メンテナンスウィンドウ → 通知+承認フロー

Step FunctionsとSNSを組み合わせた承認フロー。waitForTaskToken でDBAチームの承認を待機する:

MaintenanceStateMachine:
  Type: AWS::StepFunctions::StateMachine
  Properties:
 DefinitionString: !Sub |
{
  "Comment": "RDS Maintenance Approval Flow",
  "StartAt": "SendApprovalRequest",
  "States": {
 "SendApprovalRequest": {
"Type": "Task",
"Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
"Parameters": {
  "TopicArn": "${DBANotificationTopic}",
  "Message.$": "States.Format('RDS Maintenance for {}. Approve? Token: {}', $.rdsIdentifier, $$.Task.Token)"
},
"TimeoutSeconds": 86400,
"Next": "ApplyMaintenance"
 },
 "ApplyMaintenance": {
"Type": "Task",
"Resource": "${ApplyMaintenanceLambdaArn}",
"End": true
 }
  }
}

AZ障害 → Route 53フェイルオーバー

AZ障害Healthイベント受信時のRoute 53レコード自動切り替え。TTLを60秒に短縮して切替速度を確保する:

import boto3

def trigger_route53_failover(hosted_zone_id, record_name, failover_ip):
 route53 = boto3.client('route53')

 resp = route53.change_resource_record_sets(
  HostedZoneId=hosted_zone_id,
  ChangeBatch={
'Comment': 'AZ Failover triggered by Health Event',
'Changes': [{
 'Action': 'UPSERT',
 'ResourceRecordSet': {
  'Name': record_name,
  'Type': 'A',
  'TTL': 60,
  'ResourceRecords': [{'Value': failover_ip}]
 }
}]
  }
 )
 return resp['ChangeInfo']['Status']

組織ビュー (Organization Health) — マルチアカウント統合ダッシュボード

aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal health.amazonaws.com

aws organizations list-delegated-administrators \
  --service-principal health.amazonaws.com

Delegated Administratorを設定することで、中央監視アカウントから組織全体のHealth Eventを統合参照できる。EventBridgeルールもDelegated Administratorアカウントに集約し、一元的な障害対応体制を構築する。

# Organization全体のHealth Eventを取得 (Delegated Adminアカウントで実行)
aws health describe-events-for-organization \
  --organization-event-filter '{
 "eventTypeCategories": ["issue"],
 "eventStatusCodes": ["open"]
  }' \
  --region us-east-1

# 影響を受けるアカウント一覧を取得
aws health describe-affected-accounts-for-organization \
  --event-arn "arn:aws:health:us-east-1::event/EC2/AWS_EC2_INSTANCE_ISSUE/EXAMPLE" \
  --region us-east-1

詰まりポイント7選 + アンチパターン→正解パターン変換

詰まりポイント① — Config Rule 評価モード誤設定で変更検出漏れ

詰まりポイント② — Systems Manager Agent未インストールでRun Command失敗

# Agent稼働確認 (Amazon Linux 2)
sudo systemctl status amazon-ssm-agent

# バージョン確認
amazon-ssm-agent --version

# 最新版へアップデート
sudo yum install -y amazon-ssm-agent && sudo systemctl restart amazon-ssm-agent

詰まりポイント③ — Patch Manager パッチベースライン承認ルール誤設定で未適用

詰まりポイント④ — Trusted Advisor チェック結果のRefresh忘れで古い情報に基づく判断

# 特定チェックのリフレッシュ
aws support refresh-trusted-advisor-check \
  --check-id "Pfx0RwqBli" \
  --region us-east-1

詰まりポイント⑤ — Health EventのEventBridgeルール未設定で障害通知遅延

# us-east-1にEventBridgeルールを作成
aws events put-rule \
  --name "HealthEventAlert" \
  --event-pattern '{"source":["aws.health"]}' \
  --region us-east-1

# us-east-1のルールからap-northeast-1のLambdaを呼び出す場合
# → クロスリージョンイベントバスを経由する

詰まりポイント⑥ — Config Conformance Pack パラメータ未設定でルール不整合

aws configservice put-conformance-pack \
  --conformance-pack-name "SecurityBestPractices" \
  --template-s3-uri "s3://my-bucket/conformance-pack.yaml" \
  --conformance-pack-input-parameters '[
 {"ParameterName":"MaxAccessKeyAge","ParameterValue":"90"},
 {"ParameterName":"RequiredTags","ParameterValue":"Environment,Owner"}
  ]'

詰まりポイント⑦ — Parameter Store SecureString のKMSキー権限不足でデプロイ失敗

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": ["ssm:GetParameter", "ssm:GetParametersByPath"],
"Resource": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/prod/myapp/*"
 },
 {
"Effect": "Allow",
"Action": ["kms:Decrypt"],
"Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/mrk-xxxxxxxx"
 }
  ]
}

アンチパターン→正解パターン変換

① Config ルール評価: 全リソース評価 vs タグベース絞り込み

アンチパターン — Conformance Packを全アカウント・全リソースに無差別適用し、評価数が爆発してコストが跳ね上がる。

{
  "Source": {"Owner": "AWS", "SourceIdentifier": "REQUIRED_TAGS"},
  "Scope": {}
}

正解パターン — スコープをリソースタイプとタグで絞り込む。

{
  "Source": {"Owner": "AWS", "SourceIdentifier": "REQUIRED_TAGS"},
  "Scope": {
 "ComplianceResourceTypes": ["AWS::EC2::Instance", "AWS::RDS::DBInstance"],
 "TagKey": "Environment",
 "TagValue": "Production"
  }
}

② Run Command: インスタンスIDハードコード vs タグベースターゲット

アンチパターン — インスタンスIDをハードコードして実行対象を1台限定にする。インスタンス追加のたびにスクリプト修正が必要になる。

aws ssm send-command \
  --instance-ids "i-1234567890abcdef0" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["yum update -y"]'

正解パターン — タグベースターゲットで動的に対象を選択し、Auto Scalingと連動する。

aws ssm send-command \
  --targets "Key=tag:Environment,Values=Production" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["yum update -y"]' \
  --max-concurrency "20%" \
  --max-errors "5%"

③ Patch Manager: インストール直後スキャン vs 適切なウォームアップ

アンチパターン — Patch Manager実行直後に即座に describe-instance-patches でコンプライアンスを確認し、「パッチ未適用」と誤判断する。

aws ssm send-command --document-name "AWS-RunPatchBaseline" \
  --parameters '{"Operation":["Install"]}' --instance-ids i-xxx
# 即座に確認 → 反映前なので常にNON_COMPLIANT
aws ssm list-compliance-items --filters Key=Status,Values=NON_COMPLIANT

正解パターン — command-executed Waiterまたは一定時間後にコンプライアンスを確認する。

import boto3
import time

ssm = boto3.client('ssm')
response = ssm.send_command(
 Targets=[{'Key': 'tag:Environment', 'Values': ['Production']}],
 DocumentName='AWS-RunPatchBaseline',
 Parameters={'Operation': ['Install']}
)
command_id = response['Command']['CommandId']

waiter = ssm.get_waiter('command_executed')
waiter.wait(CommandId=command_id, InstanceId='i-xxx',
WaiterConfig={'Delay': 30, 'MaxAttempts': 20})

result = ssm.list_compliance_items(
 Filters=[{'Key': 'ComplianceType', 'Values': ['Patch']}]
)

④ Health EventBridge: issue のみ vs 全カテゴリ監視

アンチパターン — issue カテゴリのみ監視し、予定メンテナンス通知を見逃す。

{
  "source": ["aws.health"],
  "detail": {
 "eventTypeCategory": ["issue"]
  }
}

正解パターン — issue + scheduledChange + accountNotification を全て監視し、通知を分類してルーティングする。

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
 "eventTypeCategory": ["issue", "scheduledChange", "accountNotification"]
  }
}

⑤ Systems Manager Automation: 手動実行 vs Config修復連携

アンチパターン — Automationドキュメントを毎回手動で実行し、非準拠リソースを人手で特定してから対処する。レスポンスが遅く、対処漏れも発生する。

# 非準拠を発見するたびに手動実行
aws ssm start-automation-execution \
  --document-name "AWS-DisablePublicAccessForSecurityGroup" \
  --parameters "GroupId=sg-0123456789abcdef0"

正解パターン — Config Ruleと修復アクションを連携させ、非準拠検出時に自動でAutomationドキュメントを実行する。

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
 "ConfigRuleName": "restricted-ssh",
 "TargetType": "SSM_DOCUMENT",
 "TargetId": "AWS-DisablePublicAccessForSecurityGroup",
 "Parameters": {
"GroupId": {
  "ResourceValue": {"Value": "RESOURCE_ID"}
}
 },
 "Automatic": true,
 "MaximumAutomaticAttempts": 3,
 "RetryAttemptSeconds": 60
  }]'

4サービス統合アーキテクチャ — 日常運用ワークフロー

§2〜§6で4サービスをそれぞれ個別に深堀りした。しかし本番運用において4サービスは独立して動くのではなく、一連の統合ワークフローとして連動する。Config がリソースの逸脱を検知し、Systems Manager が修復アクションを実行し、Trusted Advisor が最適化の機会を提示し、Health Dashboard が障害に先行して対応を促す。この4段階のループが自律的に回り続けることが、エンタープライズガバナンスの理想形だ。

本セクションでは、4サービスを組み合わせた 日常運用ワークフロー と Vol1+Vol2 統合ガバナンスフレームワーク を体系化する。

統合運用フロー: Config → 修復 → Systems Manager → Trusted Advisor → Health

4サービスの統合フローは、検知 → 修復 → 最適化 → 対応 の4フェーズで構成される。

flowchart TD
 A[AWS Config\n設定変更検出] --> B{準拠評価}
 B -->|NON_COMPLIANT| C[修復アクション\n自動トリガー]
 B -->|COMPLIANT| D[Trusted Advisor\n定期チェック]
 C --> E[Systems Manager\nAutomation実行]
 E --> F{修復成功?}
 F -->|Success| G[Config再評価\nCOMPLIANT化]
 F -->|Failed| H[SNS通知\n手動対応]
 D --> I{コスト最適化\n推奨あり?}
 I -->|Yes| J[改善アクション\n優先度設定]
 I -->|No| K[Health Dashboard\n障害モニタリング]
 G --> K
 J --> K
 K --> L{AWS障害/\n予定メンテ検知?}
 L -->|Yes| M[自動対応フロー\nEventBridge起動]
 L -->|No| A
 M --> A

このフロー全体が EventBridge によって疎結合に連携する。Config の準拠変更イベント、Trusted Advisor の推奨更新イベント、Health の障害イベントは全て EventBridge ルールで受け取り、Systems Manager Automation や SNS 通知、Lambda 関数へルーティングできる。人手の介在なく24時間ループが回り続けるのが目標だ。

# 毎日の自動ガバナンスダッシュボード生成スクリプト
#!/bin/bash
echo "=== Daily Governance Dashboard $(date +%Y-%m-%d) ==="

# Config 非準拠リソース数の集計
NON_COMPLIANT=$(aws configservice get-compliance-summary-by-config-rule \
  --query 'ComplianceSummariesByConfigRule[*].ComplianceSummary.NonCompliantResourceCount.CappedCount' \
  --output text | paste -sd+ | bc)
echo "Config Non-Compliant Resources: ${NON_COMPLIANT}"

# パッチ未適用インスタンス数の集計
PATCH_NON=$(aws ssm describe-instance-patch-states-for-patch-group \
  --patch-group "Production" \
  --filters Key=State,Values=Missing,Failed \
  --query 'InstancePatchStates | length(@)' --output text)
echo "Patch Non-Compliant Instances: ${PATCH_NON}"

# Health: 進行中のイベント数 (us-east-1 グローバルエンドポイント必須)
HEALTH_EVENTS=$(aws health describe-events \
  --filter eventStatusCodes=open \
  --query 'events | length(@)' --output text 2>/dev/null || echo "N/A")
echo "Active Health Events: ${HEALTH_EVENTS}"

# 週次 Trusted Advisor レポート生成スクリプト
import boto3
import json
from datetime import datetime

def get_weekly_advisor_report():
 support = boto3.client('support', region_name='us-east-1')

 checks = support.describe_trusted_advisor_checks(language='ja')
 results = []

 for check in checks['checks']:
  result = support.describe_trusted_advisor_check_result(
checkId=check['id'],
language='ja'
  )
  status = result['result']['status']
  if status in ('warning', 'error'):
results.append({
 'name': check['name'],
 'category': check['category'],
 'status': status,
 'timestamp': datetime.now().isoformat()
})

 print(f"週次Trusted Advisorレポート: {len(results)}件の要対応推奨事項")
 return results

if __name__ == '__main__':
 report = get_weekly_advisor_report()
 print(json.dumps(report, ensure_ascii=False, indent=2))

Vol1+Vol2 統合ガバナンスフレームワーク

Management & Governance本番運用シリーズは、Vol1（組織基盤層）とVol2（実行監視層）の二部作で設計されている。Vol1で確立した組織基盤が、Vol2の各サービスで直接活用される。

Organizations の委任管理者 (Delegated Administrator) パターンを Vol2 でも活用する。Config は Security OU 内の監査アカウントを集約先とし、Trusted Advisor Organizational View は Management アカウントで有効化する。Systems Manager Quick Setup も Management アカウントから全メンバーアカウントへのパッチポリシーを一括適用できる。

コスト最適化視点 — 4サービス統合コスト管理

4サービスは機能だけでなく、コストも意識した設計が必要だ。

Config Rules 評価回数の最適化

Config Rules の評価コストは「評価回数 × $0.001」だ。大規模環境では評価回数が爆発的に増加する。

# Config Rules の評価モード確認コマンド
aws configservice describe-config-rules \
  --query 'ConfigRules[*].{Name:ConfigRuleName, Mode:Source.SourceDetails[0].MessageType}' \
  --output table

# CONFIGURATION_ITEM_CHANGE_NOTIFICATION (変更時評価) → 高変更頻度リソースに適用
# PERIODIC (毎時/毎日評価) → 変更頻度が低い設定 (MFA設定, S3バケットポリシー) に適用してコスト削減

Systems Manager Session Manager による踏み台サーバー廃止

従来の踏み台サーバー（EC2インスタンス）を Session Manager に置き換えることで、インスタンスコスト削減とセキュリティ向上を同時に実現する。

# 踏み台サーバーコスト vs Session Manager コスト比較
# t3.micro × 24時間365日 = $0.0104/時 × 8760時間 = 約$91/年/台
# Session Manager: Systems Manager エンドポイント $0.01/時 (VPCエンドポイント使用時)
# 踏み台5台構成の場合: $91×5=$455/年 → Session Managerエンドポイントのみで管理可能

# Session Manager 有効化確認
aws ssm describe-instance-information \
  --filters Key=PingStatus,Values=Online \
  --query 'InstanceInformationList[*].{ID:InstanceId, Platform:PlatformType}' \
  --output table

Trusted Advisor リフレッシュ最適化

Trusted Advisor の RefreshTrustedAdvisorCheck は1時間に1回の制限がある。この制限を意識した上で、コスト最適化カテゴリのチェックを優先リフレッシュする。

# Trusted Advisor コスト系チェックの優先リフレッシュ
import boto3
import time

def refresh_cost_checks():
 support = boto3.client('support', region_name='us-east-1')

 # コスト最適化カテゴリの優先チェックID
 cost_check_ids = [
  'Qch7DwouX1',  # EC2 Reserved Instances Optimization
  'hjLMh88uM8',  # RDS Reserved Instances Optimization
  'G31sQ1E9U',# Low Utilization EC2 Instances
  '1iG5NDGVre',  # Idle Load Balancers
 ]

 for check_id in cost_check_ids:
  try:
support.refresh_trusted_advisor_check(checkId=check_id)
print(f"Refreshed: {check_id}")
time.sleep(1)
  except Exception as err:
print(f"Skip {check_id}: {err}")

refresh_cost_checks()

統合設計チェックリスト — 本番環境リリース前の最終確認

4サービス統合アーキテクチャを本番環境に適用する前の確認事項を示す。

Config + Systems Manager 統合チェック

• [ ] Config Rule の修復アクション: Automatic: true かつ MaximumAutomaticAttempts: 3 が設定されているか
• [ ] 修復に使用する Automation ドキュメントに AutomationAssumeRole が設定されているか
• [ ] 修復失敗時の SNS 通知が設定されており、担当者に確実に届くか
• [ ] Config Aggregator の集約アカウントが Security OU 内の監査アカウントに設定されているか

Trusted Advisor + EventBridge 統合チェック

• [ ] Trusted Advisor の EventBridge ルールが Business/Enterprise Support アカウントで有効か
• [ ] 推奨更新イベントのフィルタ (status: error のみ通知等) が過剰通知を防いでいるか
• [ ] Organizational View が有効化されており、全メンバーアカウントの推奨が可視化されているか

Health + EventBridge 統合チェック

• [ ] detail-type: "AWS Health Event" のルールで全カテゴリ (issue, scheduledChange, accountNotification) を監視しているか
• [ ] Organization Health が有効化されており、メンバーアカウントの障害も管理アカウントで受信できるか
• [ ] 障害イベントの自動対応フロー (Lambda / Systems Manager Automation) がテスト済みか

コスト最適化チェック

• [ ] Config Rules の PERIODIC 評価頻度が適切か (高頻度不要なルールが One_Hour になっていないか)
• [ ] Systems Manager Session Manager のVPCエンドポイントコスト vs 踏み台サーバーコストの比較が完了しているか
• [ ] Trusted Advisor の月次コスト推奨レポートの確認フローが確立されているか

まとめ — Management & Governance 二部作完成宣言 + 全軸クロスリンク

本記事（Management & Governance本番運用 Vol2）では、AWS Config / Systems Manager / Trusted Advisor / Health Dashboardの4サービスを本番運用視点で体系化した。§2〜§7で培った知識を最終セクションで統合し、M&G二部作完成の宣言と全軸クロスリンクで締め括る。

§8-1: 4サービス要点まとめ表

本記事で学んだ4サービスの要点を一覧表にまとめる。

4サービスを「1チームとして動かす」設計の要点

ガバナンス導入の優先順位ガイド

4サービスを全て同時に導入しようとすると工数が爆発する。以下の優先順位で段階的に導入することを推奨する。

この5フェーズを完走することで、Level 5（自律的ガバナンスループ）の状態に到達できる。

§8-2: 全26軸クロスリンク — AWSハンズオン本番運用シリーズ

本記事（M&G Vol2）は AWS 本番運用シリーズの第24軸二部作目として位置づけられる。以下の全26軸との知識連携で、包括的な AWS 運用設計力を確立できる。

特に本記事と密接に連携する軸

M&G Vol1 — 第24軸 管理/ガバナンス Vol1（Organizations/Control Tower/CloudTrail Lake）との統合

本記事の前提となる軸。Vol1 で構築した Organizations OU 構造が Config Aggregator の集約設計に、Control Tower Guardrails が Config Rules との補完関係に、CloudTrail Lake が Health Event の監査証跡統合に直結する。M&G本番運用Vol1（Organizations × Control Tower × Service Catalog × CloudTrail Lake）を先に読了していると、本記事の設計判断がより深く理解できる。

コスト最適化軸との統合

Trusted Advisor のコスト推奨（低使用率 EC2・未使用 EBS・未使用ロードバランサー等）は、コスト最適化シリーズの設計判断と直結する。コスト最適化Vol1（Cost Explorer / Budgets / Savings Plans）およびコスト最適化Vol2（RI / Spot / Graviton / Right Sizing）と組み合わせることで、Trusted Advisor の推奨を Cost Explorer での詳細分析に繋げられる。

可観測性軸との統合

Config の評価結果・Systems Manager Patch Compliance・Health イベントは全て CloudWatch メトリクスとして可視化できる。可観測性 Vol2（X-Ray / OpenTelemetry / ADOT）と組み合わせることで、アプリケーショントレースとインフラガバナンスの統合ダッシュボードを構築できる。

全26軸シリーズ一覧

§8-3: Management & Governance 二部作完成宣言 + シリーズ展望

Management & Governance シリーズ展望

Vol1 + Vol2 の二部作完成により、AWSエンタープライズガバナンスの全領域をカバーした。Cloud Architect / Operations Engineer が本番環境のガバナンス設計に必要な全知識が、この二部作で体系的に習得できる。

§8-4: 読者アクションリスト

本記事を読んだ後、実際の環境で取り組む具体的なアクションを示す。

今すぐ実行できるアクション（PoC 環境）

• [ ] AWS Config: マネージドルール restricted-ssh を有効化し、非準拠の Security Group が検出されるか確認する
• [ ] AWS Config: 修復アクション（AWS-DisablePublicAccessForSecurityGroup）を手動トリガーで実行してみる
• [ ] Systems Manager: Patch Manager でパッチグループ Baseline-Test を作成し、テストインスタンスにパッチコンプライアンスを確認する
• [ ] Systems Manager: Session Manager でマネジメントコンソールから EC2 に接続し、SSH 不要でコマンドが実行できることを確認する
• [ ] Trusted Advisor: Business/Enterprise Support アカウントで Organizational View を有効化し、全アカウントの推奨を一覧確認する
• [ ] Health Dashboard: EventBridge ルール source: aws.health を作成し、テスト通知を確認する

本番適用前に実施すべきアクション

• [ ] Config: Aggregator の集約アカウントを Security OU の監査アカウントに設定し、全リージョンの設定変更が集約されることを確認する
• [ ] Config: Conformance Pack（Operational-Best-Practices-for-AWS-Identity-And-Access-Management等）を適用し、規制対応に必要なルール群を一括有効化する
• [ ] Systems Manager: パッチグループを本番/ステージング/開発で分離し、メンテナンスウィンドウのスケジュールを各環境で独立して設定する
• [ ] Systems Manager: Parameter Store の SecureString 型パラメータに KMS カスタムキーを適用し、自動ローテーションポリシーを設定する
• [ ] Trusted Advisor: EventBridge ルールで status: error の推奨のみを SNS で通知し、担当チームの Slack チャンネルにルーティングする
• [ ] Health Dashboard: Organization Health を有効化し、管理アカウントで全メンバーアカウントのイベントを受信できることを確認する

設計・アーキテクチャレビューで確認すべきポイント

• [ ] Config Rules の評価モード（CHANGE / PERIODIC）が各ルールの特性に合わせて最適化されているか
• [ ] Config 修復アクションの IAM ロール（AutomationAssumeRole）が最小権限で設計されているか
• [ ] Systems Manager Patch Manager のパッチ承認ルール（自動承認日数、重大度フィルタ）が組織のリスク許容度と整合しているか
• [ ] Trusted Advisor の推奨通知フィルタが「全推奨通知」ではなく「error のみ」に設定されているか（通知疲れ防止）
• [ ] Health Dashboard の EventBridge ルールが issue / scheduledChange / accountNotification の全カテゴリを網羅しているか
• [ ] 4サービスの統合フロー（Config→修復→Systems Manager→Advisor→Health）が EventBridge で疎結合に連携しているか
• [ ] Config Aggregator の集約先アカウントが複数リージョンをカバーしているか（デフォルトは作成リージョンのみ）
• [ ] Systems Manager の SSM Agent バージョンが全インスタンスで最新版に保たれているか（古いバージョンは一部機能が利用不可）

長期運用で取り組むべきアクション

• [ ] Config Rules の評価結果を Amazon Athena でクエリする分析基盤を構築し、コンプライアンストレンドをレポート化する
• [ ] Trusted Advisor の推奨対応率（error 推奨の解消率）を KPI として設定し、四半期ごとにレビューする
• [ ] Health Dashboard の過去イベントデータを分析し、障害パターンを把握して予防的対策を設計する

コスト最適化のアクション

• [ ] Config: 1ヶ月の評価回数を確認し、PERIODIC 頻度が高すぎるルールを特定して TwentyFour_Hours に変更する
• [ ] Systems Manager: 踏み台サーバーの月次コストを試算し、Session Manager + VPCエンドポイントへの移行 ROI を計算する
• [ ] Trusted Advisor: コスト最適化カテゴリの推奨（低使用率 EC2、未使用 EBS）を Cost Explorer で詳細分析し、削減計画を立案する

§8-5: 参考リソース + CTA

本記事で扱った4サービスの詳細設計は、以下の公式ドキュメントと関連シリーズで深堀りできる。