AWS Configに75個のマネージドルールが一挙追加 — Lambda・Amplify・SageMakerのセキュリティ評価が手軽に

AWS Configに75個のマネージドルールが追加されました（2026年3月18日 AWS What’s New）。

75個という数は、1月に追加された13個と比べても大幅な拡充です。特に注目すべきは、これまでConfigのマネージドルールが手薄だったAmplify（13ルール）、SageMaker（25ルール前後）、Route 53（13ルール）に一気に対応した点です。セキュリティポスチャの評価範囲が広がったと言えます。

追加されたルールの全体像

今回追加されたルールを対象サービスごとに分類すると、以下のようになります。

Lambda関連（ログ設定の評価）

ルール名	評価内容
`lambda-function-log-format-json`	ログ形式がJSONに設定されているか
`lambda-function-application-log-level-check`	アプリケーションログレベルが指定値か
`lambda-function-system-log-level-check`	システムログレベルが指定値か

2023年11月にLambdaに追加された高度なログ制御機能（JSONログ、ログレベル設定）に対応するルールです。Lambda関数のログをJSON形式で統一していないとNON_COMPLIANTになります。

見落としがちですが、lambda-function-application-log-level-checkはJSONログを使用しているLambda関数のみが評価対象です。ログ形式がTextの関数は評価対象外になります。これはルールの前提条件として知っておく必要があります。

Amplify関連（13ルール）

ルール名	評価内容
`amplify-app-no-environment-variables`	アプリに環境変数が直接設定されていないか
`amplify-app-build-spec-configured`	ビルド仕様が設定されているか
`amplify-app-description`	アプリに説明が設定されているか
`amplify-app-tagged`	タグが付与されているか
`amplify-branch-auto-build-enabled`	ブランチの自動ビルドが有効か
`amplify-branch-pull-request-preview-enabled`	PRプレビューが有効か
`amplify-branch-auto-deletion-enabled`（※アプリレベル）	ブランチの自動削除が有効か
他6ルール	ブランチのタグ・説明・フレームワーク設定等

ここで注意が必要なのはamplify-app-no-environment-variablesです。このルールは環境変数が存在するだけでNON_COMPLIANTになります。Amplifyアプリで環境変数を使うこと自体は一般的ですが、このルールは「環境変数に機密情報を直接格納していないか」を間接的にチェックする意図があると思われます。Secrets ManagerやParameter Storeを使うべきという方針を組織に展開する場合に使えます。

SageMaker関連（約25ルール）

カテゴリ	代表的なルール	評価内容
VPC配置	`sagemaker-domain-in-vpc`	ドメインがVPC内にあるか（`AppNetworkAccessType`が`VpcOnly`か）
暗号化	`sagemaker-endpoint-configuration-kms-key-configured`	エンドポイント設定にKMSキーが指定されているか
データ品質	`sagemaker-data-quality-job-encrypt-in-transit`	データ品質ジョブで転送時暗号化が有効か
モデル	`sagemaker-model-in-vpc`, `sagemaker-model-isolation-enabled`	モデルのVPC配置・ネットワーク分離
ノートブック	`sagemaker-notebook-no-direct-internet-access`	ノートブックの直接インターネットアクセス禁止
タグ	複数ルール	各種リソースへのタグ付与

SageMakerはAI/MLワークロードで利用されるため、学習データの漏洩や不正アクセスのリスクが特に高いサービスです。VPC内での実行や暗号化の強制は、コンプライアンス要件が厳しい環境では必須になります。これまでこれらを個別にカスタムルールで実装していた組織にとっては、マネージドルールへの移行が選択肢になります。

Route 53関連（13ルール）

カテゴリ	代表的なルール	評価内容
クエリログ	`route53-query-logging-enabled`	DNSクエリログが有効か
タグ	`route53-hosted-zone-tagged`, `route53-health-check-tagged`	タグ付与
復旧準備	`route53-recovery-readiness-*`（5ルール）	Recovery Readinessのリソースにタグが付いているか
Resolverファイアウォール	`route53-resolver-firewall-*`（3ルール）	Resolverファイアウォール関連のタグ

Route 53のルールはタグ関連が大半ですが、route53-query-logging-enabledは実用的です。DNSクエリログの有効化は、セキュリティインシデント発生時の調査で重要な証跡になります。

ACM関連

ルール名	評価内容
`acm-certificate-transparent-logging-enabled`	証明書の透明性ログが有効か
`acm-certificate-rsa-check`	RSA鍵長が適切か
`acmpca-certificate-authority-tagged`	プライベートCAにタグが付いているか

acm-certificate-transparent-logging-enabledは、Certificate Transparency（CT）ログへの記録が無効化されていないかをチェックします。CTログはSSL/TLS証明書の不正発行を検知するための仕組みで、明示的に無効化されている場合のみNON_COMPLIANTになります。デフォルトは有効なので、意図的に無効化していない限りは準拠状態になります。

実際に試してみた

自分の検証環境で3つの新ルールを有効化し、評価結果を確認してみました。

AWS CLI: aws-cli/2.34.8
リージョン: ap-northeast-1

ルールの有効化

# lambda-function-log-format-json を有効化
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "lambda-function-log-format-json",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "LAMBDA_FUNCTION_LOG_FORMAT_JSON"
  },
  "Scope": {
    "ComplianceResourceTypes": ["AWS::Lambda::Function"]
  }
}' --profile your-profile --region ap-northeast-1

パラメータ付きのルールも同様に有効化できます。

# lambda-function-application-log-level-check（パラメータ付き）
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "lambda-function-application-log-level-check",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "LAMBDA_FUNCTION_APPLICATION_LOG_LEVEL_CHECK"
  },
  "InputParameters": "{\"logLevel\":\"WARN\"}",
  "Scope": {
    "ComplianceResourceTypes": ["AWS::Lambda::Function"]
  }
}' --profile your-profile --region ap-northeast-1

評価を手動実行

aws configservice start-config-rules-evaluation \
  --config-rule-names lambda-function-log-format-json \
    acm-certificate-transparent-logging-enabled \
    lambda-function-application-log-level-check \
  --profile your-profile --region ap-northeast-1

評価結果

lambda-function-log-format-json

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name lambda-function-log-format-json \
  --compliance-types NON_COMPLIANT COMPLIANT \
  --query "EvaluationResults[].{ResourceId:EvaluationResultIdentifier.EvaluationResultQualifier.ResourceId,ComplianceType:ComplianceType}" \
  --profile your-profile --region ap-northeast-1 --output table

-------------------------------------------------------------------
|                GetComplianceDetailsByConfigRule                 |
+-----------------+-----------------------------------------------+
| ComplianceType  |                  ResourceId                   |
+-----------------+-----------------------------------------------+
|  NON_COMPLIANT  |  my-step-function-lambda                      |
+-----------------+-----------------------------------------------+

検証環境のLambda関数はログ形式がTextのままだったためNON_COMPLIANTと判定されました。実際にLambdaの設定を確認すると：

aws lambda get-function-configuration \
  --function-name my-step-function-lambda \
  --query "{LoggingConfig:LoggingConfig}" \
  --profile your-profile --region ap-northeast-1

{
    "LoggingConfig": {
        "LogFormat": "Text",
        "LogGroup": "/aws/lambda/my-step-function-lambda"
    }
}

LogFormatがTextのため、NON_COMPLIANTは正しい判定です。

acm-certificate-transparent-logging-enabled

------------------------------------------------
|    GetComplianceDetailsByConfigRule           |
+----------------+-----------------------------+
| ComplianceType |         ResourceId          |
+----------------+-----------------------------+
|  COMPLIANT     |  arn:aws:acm:...cert/xxxx   |
|  COMPLIANT     |  arn:aws:acm:...cert/yyyy   |
|  COMPLIANT     |  arn:aws:acm:...cert/zzzz   |
+----------------+-----------------------------+

ACM証明書3つはすべてCOMPLIANT。CTログはデフォルトで有効なので、明示的に無効化していなければこの結果になります。

lambda-function-application-log-level-check

このルールの評価結果は**空（0件）**でした。

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name lambda-function-application-log-level-check \
  --profile your-profile --region ap-northeast-1 --output json

[]

これは意外な結果ですが、仕組みを考えると正しい挙動です。このルールはJSONログを使用しているLambda関数のアプリケーションログレベルをチェックするものです。自分の環境のLambda関数はすべてログ形式がTextだったため、そもそも評価対象にならなかったのです。

つまり、lambda-function-log-format-jsonとlambda-function-application-log-level-checkはセットで使うことに意味があるルールです。

まずlambda-function-log-format-jsonでJSON形式への移行を促す
JSON形式に移行した関数に対してlambda-function-application-log-level-checkでログレベルを統制する

この関係性はドキュメントには明示されていませんが、実際に動かしてみると明確にわかります。

組織展開：Conformance Packsの活用

今回のルールはConformance Packsでまとめて展開できます。組織全体に一括で適用する場合は、CloudFormationテンプレート形式でパックを定義します。

Resources:
  LambdaLogFormatJson:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: lambda-function-log-format-json
      Source:
        Owner: AWS
        SourceIdentifier: LAMBDA_FUNCTION_LOG_FORMAT_JSON
      Scope:
        ComplianceResourceTypes:
          - AWS::Lambda::Function

  LambdaAppLogLevelCheck:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: lambda-function-application-log-level-check
      Source:
        Owner: AWS
        SourceIdentifier: LAMBDA_FUNCTION_APPLICATION_LOG_LEVEL_CHECK
      InputParameters:
        logLevel: WARN
      Scope:
        ComplianceResourceTypes:
          - AWS::Lambda::Function

  AcmTransparentLogging:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: acm-certificate-transparent-logging-enabled
      Source:
        Owner: AWS
        SourceIdentifier: ACM_CERTIFICATE_TRANSPARENT_LOGGING_ENABLED
      Scope:
        ComplianceResourceTypes:
          - AWS::ACM::Certificate

Organizations連携でデプロイすれば、全アカウントに同じルールセットを展開できます。

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name "lambda-logging-standards" \
  --template-body file://conformance-pack.yaml \
  --profile your-profile --region ap-northeast-1

Security Hubとの関係

ここで注意が必要なのは、Security HubとAWS Configの関係です。Security Hubのセキュリティ標準（AWS Foundational Security Best Practices等）は内部的にAWS Configルールを使っています。しかし、今回追加されたルールがすべてSecurity Hubのコントロールにマッピングされているわけではありません。

Security Hubでカバーされない領域の評価を行いたい場合に、今回のマネージドルールを直接有効化する価値があります。例えば：

Amplifyのセキュリティ評価 — Security Hubの標準にはAmplify関連のコントロールが少ない
SageMakerの細かいネットワーク分離 — sagemaker-model-isolation-enabledのような粒度のチェック
Lambdaのログ形式標準化 — 組織固有のログ管理ポリシーの強制

「Security Hubがあるからいいや」ではなく、組織固有の要件に合わせてConfigルールを追加で有効化するというアプローチが現実的です。

注意点

料金への影響

AWS Configはルール評価1回あたり課金されます。75ルールを全て有効化すると、リソース数に応じて料金が跳ね上がる可能性があります。

Config rule evaluations: $0.001/evaluation（最初の100,000回/リージョン/月）
Lambda関数が100個ある環境で10ルール追加 → 設定変更のたびに1,000回の追加評価

まずは必要なルールを選別して有効化し、全ルールを無条件に有効化することは避けた方が良いと思います。

グローバルサービスのRecorder問題 — ルールを有効化しても何も出ない

自分の検証環境で実際にハマったケースです。Route 53のHosted Zoneが4つ存在するのに、Configで確認すると0件として認識されていました。

# Route 53のHosted Zoneは4つある
aws route53 list-hosted-zones --query "HostedZones[].Name" \
  --profile your-profile --output table

-----------------------------------
|        ListHostedZones          |
+---------------------------------+
|  example.dev.                   |
|  admin.example.com.             |
|  sandbox.example.com.           |
|  googleapis.com.                |
+---------------------------------+

# しかしConfigでは0件
aws configservice get-discovered-resource-counts \
  --resource-types AWS::Route53::HostedZone \
  --profile your-profile --region ap-northeast-1 --output table

-----------------------------------
|   GetDiscoveredResourceCounts   |
+----------------------------+----+
|  totalDiscoveredResources  |  0 |
+----------------------------+----+

原因は、Config Recorderがus-east-1に設定されていなかったことです。

Route 53やIAM、CloudFrontなどのグローバルサービスのリソースは、Configではus-east-1のRecorderでのみ記録されます。ap-northeast-1にRecorderがあっても、グローバルサービスのリソースは追跡されません。

# us-east-1にRecorderがない
aws configservice describe-configuration-recorders \
  --profile your-profile --region us-east-1 --output json

{
    "ConfigurationRecorders": []
}

つまり、Route 53関連の新ルール（route53-query-logging-enabled等）をap-northeast-1で有効化しても、評価対象のリソースが存在しないため結果は常に0件になります。

グローバルサービスのConfigルールを使いたい場合は、us-east-1にConfig Recorderを設定する必要があります。Organizations経由でConfig Aggregatorを使っている場合でも、各アカウントのus-east-1にRecorderがなければグローバルリソースは記録されない点は見落としがちです。

タグ系ルールの扱い

今回追加されたルールの中にはタグの有無だけをチェックするルールが多く含まれています（*-tagged系）。タグ付けポリシーの強制にはAWS Organizationsのタグポリシーという別の仕組みもあるため、どちらを使うかは組織の運用方針次第です。Configルールの場合は「非準拠の検知→通知」、タグポリシーの場合は「そもそもタグなしでのリソース作成を拒否」という違いがあります。

Terraformでの設定

今回のマネージドルールはTerraformのaws_config_config_ruleリソースでも設定できます。source_identifierにAWS側のルール識別子を指定するだけなので、Terraform AWS Provider側に特別な新バージョンは必要ありません。

# パラメータなしのルール
resource "aws_config_config_rule" "lambda_json_logs" {
  name = "lambda-function-log-format-json"

  source {
    owner             = "AWS"
    source_identifier = "LAMBDA_FUNCTION_LOG_FORMAT_JSON"
  }

  scope {
    compliance_resource_types = ["AWS::Lambda::Function"]
  }

  depends_on = [aws_config_configuration_recorder.recorder]
}

# パラメータ付きのルール
resource "aws_config_config_rule" "lambda_app_log_level" {
  name             = "lambda-function-application-log-level-check"
  input_parameters = jsonencode({ logLevel = "WARN" })

  source {
    owner             = "AWS"
    source_identifier = "LAMBDA_FUNCTION_APPLICATION_LOG_LEVEL_CHECK"
  }

  scope {
    compliance_resource_types = ["AWS::Lambda::Function"]
  }

  depends_on = [aws_config_configuration_recorder.recorder]
}

ポイントはdepends_onでaws_config_configuration_recorderを指定している点です。Config Recorderが存在しない状態でルールを作成するとエラーになります。先述のグローバルサービスの問題もあるので、Route 53やIAM関連のルールを使う場合はus-east-1にもRecorderを設定することを忘れないようにしてください。

まとめ

75個のマネージドルール追加は、AWSが力を入れているセキュリティ評価の範囲拡大の一環です。特にAmplifyやSageMakerのように、これまでマネージドルールがほぼなかったサービスへの対応は歓迎すべきアップデートだと思います。

自分が検証して印象的だったのは、Lambdaのログ関連ルールがセットで使う前提で設計されている点です。lambda-function-log-format-jsonでJSON化を促進し、JSONにした関数にlambda-function-application-log-level-checkでログレベルを統制する。この段階的なアプローチは、組織のログ標準化を進める際の参考になると思います。

ただし、75ルール全てを有効化するのではなく、自組織のセキュリティ要件に照らして必要なルールを選定することが重要です。料金面もそうですが、NON_COMPLIANTが大量に出ても対応しきれなければ意味がないからです。