AWS Config 深度实战教程（2026 最新）：资源配置追踪、合规审计与 SSM 自动修复全流程

📅 2026-09-24 · ChengziCloud - 一站式云端服务

Meta Description: AWS Config 实战教程：从开启配置记录器、编写托管与自定义合规规则，到 Conformance Pack 批量治理和多账号聚合，再联动 SSM 自动修复。含 2026 年真实单价、37 个区域清单与 7 大避坑点。

> 关键词：AWS Config、配置记录器、合规审计、Config Rules、Conformance Pack、自动修复

一、前言：云上真正危险的，是你不知道被改成了什么样

在 AWS 上运维久了会遇到一类很典型的事故：某天突然发现某个 S3 桶被设成了公读、安全组开了 0.0.0.0/0 的 22 端口、一台生产 EC2 被人悄悄改了实例类型。打开 CloudTrail，你能看到"谁在几点几分调用了 PutBucketAcl"；打开监控面板，你能看到 CPU 和流量曲线；但这两个工具都回答不了同一个问题——"改完之后，这个资源现在的配置到底长什么样，和三个月前相比偏离了哪些项？"

AWS Config 就是补上这一块的：它把账号里每一个资源的配置状态按时间轴持续记录下来，再用"规则"去判断当前配置是否偏离基线，偏离了就告警、就报告、甚至自动改回去。

一句话决策口诀：CloudTrail 管"谁动了手"，Config 管"东西变成了什么样"，Security Hub 管"整体安全分是多少"。 三者边界会在第七节展开对比。

一个很容易被忽略的前提：AWS Config 必须逐个区域单独开启，不存在"开一次全局生效"。US-EAST-1 的记录器和 ap-east-1 的记录器是两个完全独立的账单项，也是两份独立的配置历史。

本文按"能直接抄"的方式写：先讲清计费模型（因为 Config 是少数"打开就开始按配置项计费、不看账单项根本不知道钱花在哪"的服务），再给三套 CLI 实操（开记录器 / 建合规规则 / 建合规包并自动修复），最后是省钱六招、七个坑和 FAQ。

二、五个核心概念，先建立正确的心智模型

2.1 配置项（Configuration Item，CI）

CI 是"某个资源在某一时刻的配置记录"。它的产生条件是配置变更或关系变更——请特别注意后半句：即使没有新建任何资源，只要资源与资源之间的关系变了（例如把安全组挂到 EC2 实例上、把子网关联到路由表、给实例加上一块 EBS），同样会产生新的配置项。这是很多人第一次看到 Config 账单时算不明白的头号原因。

2.2 两种记录频率：连续 vs 周期

AWS Config 提供两种配置项投递频率，它们的单价差了整整 4 倍：

| 记录频率 | 记录时机 | 单价（每配置项） | 典型场景 | |---|---|---|---| | 连续记录 Continuous | 一旦发生配置/关系变更立即记录 | $0.003 | 安全与合规追踪、审计取证 | | 周期记录 Periodic | 每 24 小时一次，且仅在当天发生过变化时记录 | $0.012 | 运营盘点、容量规划等低频场景 |

反直觉点：周期记录的单价是连续记录的 4 倍（$0.012 vs $0.003），但每个资源每天最多只产生 1 条 CI；连续记录单价低，却可能因为频繁变更在一个资源上产生几十条 CI。所以"哪种更便宜"没有标准答案，必须按"资源数 × 变更频率"两者相乘来算，下面的官方算例会把这两种情况都算给你看。

2.3 三种记录范围策略

记录范围决定"哪些资源会被录进来"，是成本的第一道闸门：

| 策略（recordingStrategy.useOnly） | 行为 | 成本特征 | |---|---|---| | ALL_SUPPORTED_RESOURCE_TYPES | 记录全部受支持资源类型 | 新上线服务类型会自动纳入，账单无声上涨 | | INCLUSION_BY_RESOURCE_TYPES | 只记录你列出的资源类型 | 最可控，但新类型需手工补充 | | EXCLUSION_BY_RESOURCE_TYPES | 记录全部，但排除你指定的类型 | 折中方案；该字段会覆盖其它记录参数 |

还有一个容易踩的开关：includeGlobalResourceTypes。它只针对 IAM 全局资源类型（IAM 用户、用户组、角色、客户管理策略）这一组。当 allSupported=true 时，默认不包含这组全局资源，想包含必须显式设为 true。另外，AWS::RDS::GlobalCluster 无论该字段怎么设都会在支持区域内被记录。

2.4 配置记录器与投递通道

记录器（Configuration Recorder）负责"录"，投递通道（Delivery Channel）负责"送"：配置历史文件与配置快照送到你指定的 S3 桶，配置变更通知发到 SNS 主题。两者都按各自服务的标准价格另行收费——这部分不在 Config 的价目表里，是第二个容易漏算的成本。

2.5 合规规则与合规包

- AWS Config 规则（Config Rule）：一段"期望配置"的声明，对资源的 CI 做评估，输出 COMPLIANT / NON_COMPLIANT / INSUFFICIENT_DATA 三态。 - 合规包（Conformance Pack）：把一组规则 + 一组修复动作打成一个 YAML 模板包，可以一次性部署到整个组织，并在包级别汇总合规分。

整体数据流可以简化为：

` 资源发生变更 | v [ Configuration Recorder ] -> 生成 Configuration Item | | | +--> 历史文件/快照 --> S3 桶（按 S3 计费） | +--> 变更通知 -------> SNS 主题（按 SNS 计费） v [ Config Rules 评估 ] -> COMPLIANT / NON_COMPLIANT | +--> 控制台仪表盘 / 聚合器报告 +--> 自动修复（SSM Automation 文档） `

三、计费模型与 2026 年真实单价

AWS Config 的账单由三块组成：配置项录制费 + 规则评估费 + 合规包评估费，无最低消费、无预付承诺，按量与区域独立计费。

3.1 三张价目表（us-east-1 口径，2026-09 采集）

表一：配置项录制费

| 计费项 | 单价 | |---|---| | 连续记录（Continuous Recording） | $0.003 / 配置项 | | 周期记录（Periodic Recording） | $0.012 / 配置项 | | 自定义/第三方资源配置项 | $0.003 / 配置项（与核心资源同价） |

表二：规则评估费（侦探模式与主动模式同一阶梯，按区域累计）

| 每月评估量区间 | 单价 | |---|---| | 前 100,000 次评估 | $0.001 / 次 | | 第 100,001 – 500,000 次 | $0.0008 / 次 | | 500,001 次及以上 | $0.0005 / 次 |

表三：合规包评估费（独立阶梯，不与规则评估合并累计）

| 每月合规包评估量区间 | 单价 | |---|---| | 前 100,000 次 | $0.001 / 次 | | 第 100,001 – 500,000 次 | $0.0008 / 次 | | 500,001 次及以上 | $0.0005 / 次 |

这三张表里藏着两条能直接省钱的结论：

1. 规则评估费与合规包评估费是两套独立的阶梯，不共享 10 万次低价额度。 如果你把同一条规则既作为独立规则部署、又塞进一个 Conformance Pack，同一份资源会被计费两次评估费。正确做法是二选一。 2. 同时启用"主动 + 侦探"两种模式的规则，其主动模式评估是 $0（免费）。 也就是说，开启 proactive 模式既能拿到"资源上线前预检"的能力，又不额外加钱——这是 Config 里少见的纯赚项。

3.2 四个官方算例（改写自 AWS 定价页）

算例一：100 台 EC2、每台 10 条 CI，比较连续与周期

| 记录方式 | 产生的配置项 | 计算 | 费用 | |---|---|---|---| | 连续记录 | 100 台 × 10 条 = 1,000 条 | 1,000 × $0.003 | $3.00 | | 周期记录 | 每资源每天 1 条 = 100 条 | 100 × $0.012 | $1.20 |

这个算例正是 2.2 节说的：变更密集时周期记录更省，但变更稀疏时（每个资源当天没变就不记录）周期记录的条数会大幅下降，省钱效果更明显。

算例二：一个月的完整账单

假设当月用量为：10,000 条配置项、50,000 次侦探模式规则评估、5 个合规包（每包 10 条规则 × 每条 300 次评估 = 15,000 次合规包评估）：

| 计费项 | 计算 | 费用 | |---|---|---| | 配置项 | 10,000 × $0.003 | $30 | | 规则评估 | 50,000 × $0.001（仍在首个 10 万区间） | $50 | | 合规包评估 | 15,000 × $0.001（独立阶梯的首个 10 万区间） | $15 | | 合计 | | $95 |

算例三：主动模式规则

同样用量，但 50,000 次评估全部来自"仅主动模式"的规则：结果是配置项 $30 + 规则评估 $50 + 合规包 $15 = $95。也就是说只开主动模式的规则，其评估同样计费。

算例四：同时开启主动 + 侦探模式（本文最值钱的一段）

10,000 条配置项 + 25,000 次侦探评估 + 50,000 次主动评估（来自同时开两种模式的规则）：

| 计费项 | 计算 | 费用 | |---|---|---| | 配置项 | 10,000 × $0.003 | $30 | | 侦探模式评估 | 25,000 × $0.001 | $25 | | 主动模式评估（规则同时开两模式时） | 50,000 × $0 | $0 | | 合计 | | $55 |

所以省钱策略非常明确：规则要么只开侦探模式（按次付费），要么同时开主动 + 侦探模式（主动部分免费、获得预检能力）；"只开主动模式"是最不划算的选择。

3.3 不在价目表上的"隐性成本"

| 成本项 | 计费方式 | |---|---| | 配置历史文件与快照的存储 | 投递到你指定的 S3 桶，按 S3 标准价计费 | | 配置变更通知 | 通过 SNS 投递，按 SNS 标准价计费 | | 自定义规则（Customer Managed Rule） | 用 Lambda 实现，按 Lambda 标准价计费（可享 Lambda 免费额度） | | 托管规则（AWS Managed Rule） | 由 AWS 维护，不产生额外的 Lambda 费用 |

四、实操一：用 CLI 开启配置记录器

Config 的 CLI 命名空间是 configservice，共 100 余条命令。开启流程只有四步：创建 S3 投递桶 → 创建 IAM 角色 → 创建记录器 → 创建投递通道并启动。

4.1 第一步：准备 S3 桶与 IAM 角色

`bash // 1. 创建投递桶（桶名全局唯一，按需替换） aws s3 mb s3://my-config-delivery-bucket --region ap-northeast-1

// 2. 给桶加生命周期策略，历史文件 365 天后转低频存储，省 S3 费用 aws s3api put-bucket-lifecycle-configuration \ --bucket my-config-delivery-bucket \ --lifecycle-configuration '{"Rules":[{"ID":"config-archive","Status":"Enabled","Filter":{"Prefix":""},"Transitions":[{"Days":365,"StorageClass":"STANDARD_IA"}]}]}'

// 3. 创建让 Config 写入 S3、发布 SNS 的服务角色 aws iam create-role --role-name ConfigRecorderRole \ --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"config.amazonaws.com"},"Action":"sts:AssumeRole"}]}'

aws iam attach-role-policy --role-name ConfigRecorderRole \ --policy-arn arn:aws:iam::aws:policy/service-role/AWS_ConfigRole `

4.2 第二步：创建记录器（含三种范围策略）

注意：recordingGroup / recordingMode / recordingStrategy 全部是 --configuration-recorder 这个 JSON 结构里的字段，并不是独立的命令行开关（命令只有 --configuration-recorder 与遗留的 --recording-group 两个结构参数）。用 --generate-cli-skeleton input 可以打印官方 JSON 骨架，比手写更保险。

`bash // 方案 A：记录全部受支持资源类型（简单，但账单会随 AWS 上线新服务自动增长） aws configservice put-configuration-recorder \ --configuration-recorder '{"name":"default","roleARN":"arn:aws:iam::123456789012:role/ConfigRecorderRole","recordingGroup":{"allSupported":true,"includeGlobalResourceTypes":true},"recordingMode":{"recordingFrequency":"CONTINUOUS"}}'

// 方案 B：只记录关键资源类型（INCLUSION_BY_RESOURCE_TYPES，最可控） aws configservice put-configuration-recorder \ --configuration-recorder '{"name":"default","roleARN":"arn:aws:iam::123456789012:role/ConfigRecorderRole","recordingGroup":{"allSupported":false,"resourceTypes":["AWS::EC2::Instance","AWS::EC2::SecurityGroup","AWS::EC2::Volume","AWS::S3::Bucket","AWS::RDS::DBInstance","AWS::IAM::Role"],"recordingStrategy":{"useOnly":"INCLUSION_BY_RESOURCE_TYPES"}},"recordingMode":{"recordingFrequency":"CONTINUOUS"}}'

// 方案 C：排除法——录全部但排除高噪声资源（推荐给中大型账号） aws configservice put-configuration-recorder \ --configuration-recorder '{"name":"default","roleARN":"arn:aws:iam::123456789012:role/ConfigRecorderRole","recordingGroup":{"allSupported":true,"exclusionByResourceTypes":{"resourceTypes":["AWS::EC2::NetworkInterface","AWS::EC2::EIPAssociation"]},"recordingStrategy":{"useOnly":"EXCLUSION_BY_RESOURCE_TYPES"}},"recordingMode":{"recordingFrequency":"CONTINUOUS"}}' `

三个易错点：

1. exclusionByResourceTypes 会覆盖其它记录参数，并且此策略下 includeGlobalResourceTypes=false 也拦不住全局 IAM 类型——要排除必须显式写进排除列表。 2. recordingMode.recordingFrequency 只接受 CONTINUOUS 或 DAILY 两个值；需要按资源类型分别设定频率时，用 recordingModeOverrides。 3. allSupported=true 与 resourceTypes 列表互斥：设了全量就不能再枚举资源类型。

4.3 第三步：创建投递通道并启动

`bash aws configservice put-delivery-channel \ --delivery-channel name=default,s3BucketName=my-config-delivery-bucket,snsTopicARN=arn:aws:sns:ap-northeast-1:123456789012:config-topic

aws configservice start-configuration-recorder --configuration-recorder-name default

// 复核状态：recording=true 才算真正开启 aws configservice describe-configuration-recorder-status --configuration-recorder-names default `

4.4 第四步：按需调整配置项历史保留期

`bash // 保留期仅作用于配置项历史；min 30 天，max 2557 天（约 7 年） aws configservice put-retention-configuration --retention-period-in-days 2557 aws configservice describe-retention-configurations `

五、实操二：部署合规规则

5.1 托管规则 vs 自定义规则

| 对比维度 | AWS 托管规则 | 客户自定义规则 | |---|---|---| | 维护方 | AWS，规则更新自动生效 | 你自己（Lambda 代码自维护） | | 额外费用 | 无额外 Lambda 费用 | 按 Lambda 标准价计费（可享免费额度） | | 创建方式 | put-config-rule + 规则标识符与少量参数 | 先建 Lambda 函数，再在规则里引用 | | 适用场景 | 通用最佳实践（加密、公读、MFA 等） | 业务专属基线、内部命名/标签规范 |

5.2 常见托管规则示例（三条高频规则）

`bash // 规则一：S3 桶禁止公共读 aws configservice put-config-rule --config-rule '{"ConfigRuleName":"s3-bucket-public-read-prohibited","Source":{"Owner":"AWS","SourceIdentifier":"S3_BUCKET_PUBLIC_READ_PROHIBITED"}}'

// 规则二：安全组禁止对 0.0.0.0/0 开放 22 端口 aws configservice put-config-rule --config-rule '{"ConfigRuleName":"restricted-ssh","Source":{"Owner":"AWS","SourceIdentifier":"INCOMING_SSH_DISABLED"}}'

// 规则三：EBS 卷必须加密，且仅对带 Env=prod 标签的资源评估 aws configservice put-config-rule --config-rule '{"ConfigRuleName":"encrypted-volumes-prod","Source":{"Owner":"AWS","SourceIdentifier":"ENCRYPTED_VOLUMES"},"Scope":{"TagKey":"Env","TagValue":"prod"}}' `

5.3 触发方式与评估模式

| 配置项 | 取值 | 说明 | |---|---|---| | 变更触发 | 按 Tag / 资源类型 / 资源 ID | 只有这些对象的变更才会触发该规则评估 | | 周期触发 | 1 / 3 / 6 / 12 / 24 小时 | 每次评估对规则可见的全部 CI 做一次快照比对 | | 评估模式 | proactive / detective / both | both 模式下主动部分免费（见第三节） |

5.4 手动触发与查看合规结果

`bash // 立即跑一次指定规则（不等变更触发） aws configservice start-config-rules-evaluation --config-rule-names restricted-ssh

// 查看合规汇总与不合规明细 aws configservice get-compliance-summary-by-config-rule aws configservice get-compliance-details-by-config-rule --config-rule-name restricted-ssh --compliance-types NON_COMPLIANT

// 回溯某个资源的配置变更时间线 aws configservice get-resource-config-history --resource-type AWS::S3::Bucket --resource-id my-bucket

// 用 SQL 直接查配置数据（高级查询） aws configservice select-resource-config --expression "SELECT resourceId, resourceType, configuration.encryption WHERE resourceType = 'AWS::S3::Bucket'" `

六、实操三：用 Conformance Pack 做批量合规治理

单个规则适合"点对点"防住一条风险；当你要同时满足 PCI-DSS、等保、内部安全基线时，一条条建规则既慢又难统一口径——这正是合规包（Conformance Pack） 的用武之地。

6.1 三者怎么选

| 治理方式 | 部署范围 | 成员账号能否改动 | 适用场景 | |---|---|---|---| | 单条 Config 规则 | 单账号单区域 | 可改 | 少量关键检查 | | 单账号 Conformance Pack | 一个账号（可跨区域） | 可改 | 单账号统一基线 | | 组织级 Conformance Pack | 整个 Organizations 下的所有账号 | 不可改（不可变） | 多账号强合规、审计取证 |

组织级合规包的关键价值是不可变性：包内的规则与修复文档无法被成员账号修改或删除，天然适合"总部分发、子公司执行"的治理模型。

6.2 部署一个合规包

`bash // 用官方样例模板（S3 运营最佳实践）从 S3 部署 aws configservice put-conformance-pack \ --conformance-pack-name s3-operational-best-practices \ --template-s3-uri s3://my-config-templates/Operational-Best-Practices-for-S3.yaml \ --delivery-s3-bucket my-config-delivery-bucket \ --delivery-s3-key-prefix conformance-packs/

// 也可以直接内联模板正文 aws configservice put-conformance-pack \ --conformance-pack-name my-internal-baseline \ --template-body file:///root/baseline.yaml \ --conformance-pack-input-parameters ParameterName=AllowedRegions,ParameterValue="ap-northeast-1,ap-east-1"

// 组织级部署（需在管理账号或委托管理员执行，作用于所有成员账号） aws configservice put-organization-conformance-pack \ --organization-conformance-pack-name org-security-baseline \ --template-s3-uri s3://my-config-templates/org-baseline.yaml `

官方提供的样例模板包括 S3 运营最佳实践、DynamoDB 运营最佳实践、PCI 合规最佳实践 等，均为 YAML，可直接下载后改造。规则在包内以 YAML 声明，因此不要在代码块里写行首 # 注释，需要说明的文字写在模板外的正文里。

6.3 查合规得分

`bash // 包级合规汇总与得分 aws configservice describe-conformance-pack-compliance --conformance-pack-name s3-operational-best-practices aws configservice get-conformance-pack-compliance-summary --conformance-pack-names s3-operational-best-practices aws configservice list-conformance-pack-compliance-scores --conformance-pack-names s3-operational-best-practices

// 组织级包的部署状态（哪些成员账号成功/失败） aws configservice describe-organization-conformance-pack-statuses `

七、实操四：多账号聚合与自动修复

7.1 聚合器：把 N 个账号的合规状态收进一块仪表盘

`bash // 组织级聚合器：一次收齐组织内所有账号（推荐） aws configservice put-configuration-aggregator \ --configuration-aggregator-name org-aggregator \ --organization-aggregation-source '{"RoleArn":"arn:aws:iam::123456789012:role/ConfigAggregatorRole","AllAwsRegions":true}'

// 单账号聚合器：手工指定来源账号与区域 aws configservice put-configuration-aggregator \ --configuration-aggregator-name multi-account-aggregator \ --account-aggregation-sources '[{"AccountId":"111111111111","AllAwsRegions":true},{"AccountId":"222222222222","AwsRegions":["ap-northeast-1"]}]'

// 读取跨账号汇总 aws configservice describe-configuration-aggregators aws configservice get-aggregate-compliance-summary-by-config-rule --configuration-aggregator-name org-aggregator `

必须说清的一条边界：聚合器只是报告能力，不能批量下发规则。要在多账号批量部署规则，得用 CloudFormation StackSets 或组织级 Config 规则 / 组织级合规包。很多人误以为建了聚合器就能"统一治理"，结果发现只能看不能改。

7.2 自动修复：Config → SSM Automation

Config 本身不会阻止你做出不合规的操作（它是在变更完成之后才评估的），但它可以触发另一套流程把资源改回来：

`bash // 为规则绑定自动修复：目标是一个 SSM Automation 文档 aws configservice put-remediation-configurations --remediation-configurations '[{"ConfigRuleName":"s3-bucket-public-read-prohibited","TargetType":"SSM_DOCUMENT","TargetId":"AWS-DisableS3BucketPublicReadWrite","Automatic":true,"MaximumAutomaticAttempts":5,"RetryAttemptSeconds":60,"Parameters":{"AutomationAssumeRole":{"StaticValue":{"Values":["arn:aws:iam::123456789012:role/ConfigRemediationRole"]}},"BucketName":{"ResourceValue":{"Value":"RESOURCE_ID"}}}}]'

// 手工触发一次修复（针对具体资源） aws configservice start-remediation-execution \ --config-rule-name s3-bucket-public-read-prohibited \ --resource-keys '[{"resourceType":"AWS::S3::Bucket","resourceId":"my-bucket"}]'

// 查看修复执行状态 aws configservice describe-remediation-execution-status \ --config-rule-name s3-bucket-public-read-prohibited \ --resource-keys '[{"resourceType":"AWS::S3::Bucket","resourceId":"my-bucket"}]' `

MaximumAutomaticAttempts 与 RetryAttemptSeconds 是防止修复失败后无限重试的刹车，务必设置。

7.3 四个"看起来很香、其实不一样"的服务，边界对比

| 服务 | 回答的问题 | 数据形态 | 与 Config 的关系 | |---|---|---|---| | AWS Config | 资源现在的配置是什么、偏离了基线吗 | 配置项时间线 + 合规状态 | 本体 | | CloudTrail | 谁在何时从哪个 IP 发起了什么 API 调用 | API 事件日志 | 可与 Config 时间线关联，回答"是谁改的" | | Security Hub CSPM | 整体安全分是多少、有哪些高危发现 | 安全发现（Findings） | 底层大量依赖 Config 规则做评估 | | CloudFormation Drift | 实际资源是否偏离了模板定义 | 模板差异 | 只覆盖 IaC 管理的资源，面比 Config 窄 |

另需知道：AWS Control Tower 与 AWS Firewall Manager 也在底层使用 Config 规则，所以你开着这些服务时，账号里已经存在一批你看不见来源的 Config 规则——这是排查"规则数量比预期多"的原因。

八、区域支持与配额上限

8.1 区域：亚洲已相当齐全

AWS Config 的官方端点页共列出 34 个商业区域 + 2 个 GovCloud 区域；其底层价格清单另外给出 37 个可报价区域。对中文用户最有意义的是亚洲已覆盖得很全：

| 亚洲区域 | 区域代码 | |---|---| | 中国香港 | ap-east-1 | | 中国台北 | ap-east-2 | | 日本东京 / 大阪 | ap-northeast-1 / ap-northeast-3 | | 韩国首尔 | ap-northeast-2 | | 新加坡 / 泰国 / 马来西亚 | ap-southeast-1 / ap-southeast-7 / ap-southeast-5 | | 澳大利亚悉尼 / 墨尔本 / 新西兰 | ap-southeast-2 / ap-southeast-4 / ap-southeast-6 | | 印度孟买 / 海得拉巴 / 印尼雅加达 | ap-south-1 / ap-south-2 / ap-southeast-3 |

区域选择建议：延迟敏感或数据合规要求落地的选 ap-east-1（香港）；生态最全、文档最齐的选 ap-northeast-1（东京）；东南亚业务选 ap-southeast-1（新加坡）。注意 Config 的费用按区域独立计价、独立累计，多区域开启等于多份账单。

8.2 配额上限

| 配额项 | 默认值 | 可否调整 | |---|---|---| | 每区域每账号 Config 规则数 | 1,000 | 否 | | 单账号 Conformance Pack 数 | 50 | 否 | | 每个单账号合规包内规则数 | 130 | 否 | | 组织级 Conformance Pack 数 | 50 | 否 | | 每个组织级合规包内规则数 | 130 | 否 | | 配置聚合器数 | 50 | 是 | | 单个聚合器内账号数 | 10,000 | 否 | | 每周所有聚合器可增删账号数 | 1,000 | 是 | | 单账号单区域可保存的高级查询数 | 300 | 是 | | 每个资源的标签数 | 50 | 否 |

注意一处口径冲突：官方 FAQ 至今仍写着"每账号默认 150 条规则，可申请提额"，而现行的 Service Quotas 页写明是"每区域每账号 1,000 条且不可调整"。排期做大规模治理时请以 Service Quotas 页为准。另外，放进合规包里的规则同样计入这 1,000 条配额，不是额外豁免。

九、免费套餐口径与省钱六招

9.1 AWS Config 没有按月免费额度

这一点必须先讲清楚，避免有人以为"AWS 有免费套餐，随便开"：

- AWS Config 不在官方"30+ Always Free"服务清单里——官方免费套餐页全文没有 Config 条目，Config 定价页的表格也没有其他服务常见的 with AWS Free Tier 列。判断某服务有无月度免费额度的快捷方法就是看这一列在不在。 - 真正可用的免费资源有两项：一是账号级新免费计划（注册即得 $100 额度，完成入门操作最多再得 $100，合计最多 $200；免费计划有效期 6 个月，到期或额度用尽账号自动关闭，不转付费计划就不会被扣费；额度需自开通起 12 个月内用完）；二是自定义规则所调用的 Lambda 可享 Lambda 免费额度。 - 两个会"打脸"的细节：账号一经加入 AWS Organizations 或建立 Control Tower landing zone，上述 $200 额度会立即失效并自动转为付费计划；另外 AWS 中国大陆区域不提供免费套餐。

结论：Config 想省钱，只能靠把"配置项数量"和"评估次数"压下来，没有别的捷径。

9.2 省钱六招

| # | 招式 | 效果 | |---|---|---| | 1 | 按"资源数 × 变更频率"计算后再选连续/周期，别凭直觉 | 变更密集时周期记录更省（见算例一） | | 2 | 用 INCLUSION 或 EXCLUSION 策略，避免无脑全量 | 挡住"新服务自动纳入"的账单增长 | | 3 | 排除高噪声类型（弹性网卡、EIP 关联、安全组关联等） | 关系类变更产生的 CI 往往占大头 | | 4 | 同一条规则只部署一次：要么独立规则，要么放进合规包 | 两套评估阶梯独立累计，重复部署=双份钱 | | 5 | 规则用"仅侦探"或"主动+侦探"，不要只开主动 | both 模式下主动评估 $0（见算例四） | | 6 | 给规则的 Scope 加 Tag 限定 + 定期清理闲置规则 | 少评估一次就少一次 $0.001 | | 7 | 停记录器时同步处理周期规则 | 停记录器后周期规则仍在按频率评估计费 | | 8 | 给 S3 投递桶配生命周期策略，保留期设为业务最短 | 历史文件堆在 S3 Standard 上会持续累积成本 |

十、常见问题 FAQ

Q: AWS Config 和 CloudTrail 有什么区别？两个都要开吗？ A: CloudTrail 记录"API 调用事件"（谁、何时、从哪个 IP、做了什么操作），Config 记录"资源的配置状态及其时间线"（这个资源现在是什么配置、之前是什么配置、哪一次变更导致它偏离基线）。要回答"是谁把桶改成公读的"，理想姿势是两者都开：用 Config 定位到"桶在 14:03 变成公读"，再用 CloudTrail 关联出"同一时刻是哪个 IAM 用户调用了 PutBucketAcl"。只开一个，事故复盘时会缺一半证据。

Q: 打开 AWS Config 就会开始扣费吗？有免费额度吗？ A: 会。一旦启动配置记录器并产生了配置项，就开始按 $0.003/条（连续）或 $0.012/条（周期）计费；创建规则后，每次评估再按 $0.001 起计费。Config 没有按月免费额度，账号级新免费计划的 $200 额度可以用来抵扣，但加入 Organizations 后该额度会立即失效。

Q: 只开一个区域够吗？ A: 不够。Config 是逐区域独立开启的，你在 us-east-1 开的记录器对 ap-east-1 里的资源毫无感知，两边也是两份独立账单。生产账号应按"有业务资源的区域"逐个开启，否则你的合规报告会存在整片盲区。

Q: 配置项历史默认保留多久？可以改吗？ A: 可以用 put-retention-configuration 调整，单位为天，最小 30 天、最大 2557 天（约 7 年），且该设置仅作用于配置项历史。配置快照/历史文件同时会投递到你的 S3 桶，那部分的生命周期由 S3 生命周期策略控制，与保留期设置是两回事。

Q: 一个账号到底能建多少条规则？我看到"150"和"1000"两种说法。 A: 以现行 Service Quotas 页为准：每区域每账号 1,000 条，且不可调整。FAQ 里的"默认 150 条、可申请提额"是过期口径。注意合规包内的规则也计入这 1,000 条。

Q: Config 能阻止我做出不合规的操作吗？ A: 不能直接阻止。Config 规则的评估发生在配置变更完成并记录之后，它不会拦截 API 调用。要"事前阻止"应当用 IAM 策略、SCP 或 CloudFormation Hooks；要"事前预检"则可以用规则的 proactive 模式。Config 的定位是"发现 + 报告 + 触发修复"。

Q: 自动修复失败会怎样？ A: 修复动作本质是调用一个 SSM Automation 文档。要设置 MaximumAutomaticAttempts（最大自动重试次数）与 RetryAttemptSeconds（重试间隔），否则失败后会反复重试而无人知晓。建议同时把修复执行状态纳入监控告警。

Q: 香港、东京、新加坡支持 Config 吗？国内用户该选哪个区域？ A: 都支持。ap-east-1（香港）、ap-northeast-1（东京）、ap-southeast-1（新加坡）均在官方端点清单内，另外台北 ap-east-2、大阪 ap-northeast-3、首尔 ap-northeast-2 也可用。追求低延迟与就近合规选香港，追求生态完整与资料齐全选东京。

Q: 停止记录器之后，已经记录的历史数据还能查吗？ A: 能。官方明确：你可以随时停止记录配置项，并继续访问此前已记录的配置项。但要注意两点：停止记录器不会自动停掉周期规则的评估（仍会产生评估费），而且停记录期间发生的配置变更不会留下任何 CI 记录，等你想复盘时这段历史是空白的。

Q: Config 和 Security Hub、Control Tower 是什么关系？ A: Security Hub CSPM、Control Tower、Firewall Manager 在底层大量使用 Config 规则做配置评估。所以当你开启这些服务后，账号里会出现一批由它们自动创建的 Config 规则，这就是"规则数量比我自己建的多"的原因。选择上：现成的合规标准（如 PCI-DSS）用 Security Hub CSPM 更省事；要自建内部标准、并希望规则不可被成员账号修改，用 Config 的组织级合规包。

十一、总结

AWS Config 解决的是云上最容易被忽略的一件事——资源被改成了什么，以及现在有没有偏离基线。它的落地顺序建议是：

1. 先定成本边界：算清"资源数 × 变更频率"，选连续还是周期，用 INCLUSION/EXCLUSION 策略圈定记录范围； 2. 再建记录器与投递通道：S3 桶加生命周期策略，IAM 角色最小权限； 3. 然后建规则：先用托管规则把公读、开放端口、未加密、MFA 这几条高危项挡住，模式上选"仅侦探"或"主动+侦探"； 4. 规模化后上合规包与聚合器：组织级合规包保证不可变，聚合器只做统一报告（记住它不能下发规则）； 5. 最后接自动修复：用 SSM Automation 文档把不合规资源改回去，并给重试设置刹车。

最容易被忽略的两条结论，值得再强调一次：合规包评估费与规则评估费是两套独立阶梯，同一条规则部署两次就是双份钱；同时开启主动 + 侦探模式的规则，其主动评估是免费的。把这两条用在你的账号上，往往能立刻省下一笔看不见的支出。

> ⚠️ 文中价格为 2026 年参考价，实际费用随区域和官方调价变动，请以 AWS 官网为准。

> 🚀 需要 AWS 国际版账号？通过 3.chengzicloud.cloud 获取最新注册教程与专属优惠，助你轻松上云。

> 本文由 3.chengzicloud.cloud 提供，点击访问首页了解更多