AWS Config added 77 resource types yesterday. The sentence worth reading twice is not the count — it is this one: “With this launch, if you have enabled recording for all resource types, then AWS Config will automatically track these new additions.”
Which is the behaviour you asked for when you ticked that box, and it means a line on next month's bill moved without anybody changing anything.
Executive summary
AWS Config now records 77 more resource types, “across key services including Amazon EC2, Amazon S3 Files, and Amazon Q Business”, in “all AWS Regions where the resources are available”. They are also usable in Config rules and aggregators.
If you record all resource types, coverage widened for you automatically and so did the configuration-item count. If you record a selected list, nothing happened and nothing will until you add them — which is the trade you made, and the reason the list needs revisiting on a cadence rather than at setup.
What changed
Three statements from the announcement, each with a consequence.
| AWS says | What it means for you |
|---|---|
| “AWS Config now supports 77 additional AWS resource types” | Breadth, not depth. These are types that previously had no configuration history at all. |
| “if you have enabled recording for all resource types, then AWS Config will automatically track these new additions” | No action needed to gain the coverage, and no action possible to avoid the cost except changing the strategy. |
| “also available in Config rules and Config aggregators” | A rule written against ALL_SUPPORTED scope can now evaluate resources it could not see last week. |
The types themselves are a reasonable sample of what AWS shipped over the preceding months, and a few are directly relevant to things covered in this series:
| Resource type | Why it matters here |
|---|---|
AWS::GuardDuty::ThreatEntitySet, AWS::GuardDuty::TrustedEntitySet | Threat and trusted IP lists become configuration items with history. A trusted list is a suppression surface — #74 was about exactly that kind of quiet reduction in detection. |
AWS::InspectorV2::CodeSecurityScanConfiguration | Scan configuration under change tracking, which is the half of a scanner that decides what it looks at. |
AWS::S3Files::AccessPoint | A new access path to data gets history from the start rather than retroactively. |
AWS::QBusiness::* | Several types. An assistant with access to corporate data is a configuration worth a change log. |
AWS::LicenseManager::Grant, AWS::LicenseManager::License | A grant is a delegation. #72 is the same noun doing the same job in KMS. |
AWS::Braket::SpendingLimit, AWS::BedrockAgentCore::PaymentConnector | Both are controls whose modification is the event you want recorded, not their existence. |
Architecture
There are only two states an account can be in here, and the announcement lands on them in opposite ways.
Recording all resource types. You get the 77 types, the configuration items they generate, and the rule evaluations against them — without a deployment, a change request or a notification. That is the contract working as written.
Recording a selected list. Nothing changed. Your 77 new types are supported and unrecorded, and will stay that way until somebody edits the list. Which is the cost of the control: a selected list does not drift upward in price, and it does not drift upward in coverage either.
Business value
Configuration history is one of those things whose value is entirely retrospective. A type that gains recording today answers questions asked in six months — what did this look like before the incident, who changed it, what else changed at the same time — and cannot answer them about last week.
So the value of this announcement to an all-types account is already banked, quietly, as of yesterday. The value to a selected-list account is available only if somebody looks at the list, which is why a periodic review of it is worth more than the review takes.
The aggregator half matters for anyone running the multi-account setup from #43: new types flow into existing aggregators, so an organisation-wide view of these resources exists without a per-account change.
Security considerations
Several of the new types are controls rather than workloads, and that is the interesting part. A GuardDuty trusted entity set, an Inspector scan configuration, a Braket spending limit — each of these is a thing whose modification is the security event. Recording them means the question "when did this get narrowed?" has an answer that does not depend on CloudTrail retention.
That is worth pairing with the finding from #74: a suppression or trust list quietly reduces what a detector reports, and nothing announces it. Having the list under configuration history turns that into a diffable record, and a Config rule against it turns it into an alert.
The caution is the mirror image. Configuration items contain configuration, and some of these types describe access paths to data. Wherever the recorder delivers — the S3 delivery channel, the aggregator account — is now holding descriptions of a wider set of resources than it was last week. If that bucket's access was scoped on the assumption of a narrower inventory, the assumption changed without the policy changing.
Cost considerations
This is the section that justifies reading the announcement at all, because the cost change is automatic for exactly the accounts that did not choose it.
The pricing page's worked example computes at “$0.003 per continuous configuration item” and “$0.012 per periodic configuration item”. Those are the figures used below, and they come from an example rather than from the rate table, so check them against your own Region and the Pricing Calculator before building a number on them.
Rule evaluations are a separate charge, “per rule evaluation per region”, tiered at “First 100,000 rule evaluations”, “Next 400,000 rule evaluations (100,001-500,000)” and “500,001 and more”. The rate per tier is not quoted here deliberately — it is worth getting from the console rather than from a post.
Two lines move, then, not one: more resources recorded, and more resources for an
ALL_SUPPORTED-scoped rule to evaluate.
The four-changes-a-day line
The two recording frequencies are priced four times apart, and periodic has a fixed ceiling on volume: “Under periodic recording, only 1 configuration item per resource is generated per day.”
Divide the rates — 0.012 / 0.003 — and the break-even is four changes per
day. Above that, continuous is cheaper. Below it, periodic is, and the gap widens the more static
the resource is.
Most of the 77 new types are the static kind. A spending limit, a license, a scan configuration and a threat entity set do not change four times a day; a few of them may not change four times a year. Which makes recording frequency a per-type decision rather than an account-wide one, and this announcement a reasonable moment to make it.
| Resource profile | Cheaper frequency | Why |
|---|---|---|
| Changes more than 4× a day | Continuous | $0.003 each beats $0.012 for one daily item once you pass four. |
| Changes roughly daily | Continuous, comfortably | One continuous item a day is a quarter of the periodic rate. |
| Changes rarely — most of these 77 | Periodic | One item per day regardless, and most days nothing happened. |
Note which way round that is, because it is easy to get backwards: periodic is the more expensive rate per item and is cheaper only because it caps the item count. For a resource that genuinely sits still, continuous recording generates almost nothing and is cheaper still — the arithmetic above is about the ceiling, not about static resources being expensive to record continuously.
Operational considerations
Nothing about this produces a notification. Coverage improved silently, volume increased silently, and the first visible signal is a bill, or a Config rule reporting findings on resources nobody scoped it to.
That second one is the operational surprise worth preparing for. A rule written against all supported types — a tagging rule is the common case — now evaluates 77 more types. If those resources are untagged, as newly supported resources generally are, the rule's compliance count moves and it will look like a regression in somebody's dashboard.
The same applies through Security Hub, which consumes Config rule results. #75 was about a control's status changing because its population changed rather than because anything was fixed or broken. This is that mechanism, pointed the other way: the population grew, so a passing control can start failing without a single resource being misconfigured by anybody's intent.
Tradeoffs
| Choice | Gains | Costs |
|---|---|---|
| Record all resource types | Coverage of new types with no action, ever; no list to maintain; no blind spot you forgot about | A cost line that moves on AWS's schedule rather than yours, and rule populations that grow unannounced |
| Record a selected list | Predictable volume; rule scope you chose | Coverage freezes at whenever the list was written, silently, and 77 types just landed outside it |
| Continuous recording | Every change captured, in order | Volume is a function of change rate, which you do not control |
| Periodic recording | One item per resource per day, a hard ceiling | 4× the per-item rate, and intermediate states between daily snapshots are not captured |
Implementation guidance
- Establish which strategy each account actually uses. All-types and selected-list accounts need opposite responses to this announcement, and in an organisation it is common to have both.
- For selected-list accounts, read the 77 and pick. The security-control types are the ones to argue for: a trusted entity set or a scan configuration under change history is worth more than a workload resource's history.
- For all-types accounts, look at next month's configuration item count rather than waiting for the bill. The increase is already happening.
- Check which rules are scoped to all supported types and expect their populations to have grown. Decide now whether a newly non-compliant count is a finding or noise.
- Set recording frequency per type rather than globally, using four changes a day as the line. Most of these 77 fall on the periodic side.
- Confirm the delivery channel's access is still correctly scoped for an inventory that is wider than it was.
Best practices
- Treat a selected list as a thing with a review date. Its whole failure mode is staying correct while the world widens around it.
- Record the controls, not just the workloads. The modification of a suppression list is a more interesting event than the existence of a queue.
- Write the break-even into the decision, not into a memory. Four changes a day is
0.012 / 0.003, so it moves if either rate does. - Expect compliance percentages to move when the denominator moves. A ratio reported without its population is the recurring theme of this week's posts.
- Do not infer availability from the announcement alone. “in all AWS Regions where the resources are available” is a conditional, and the condition is per resource type.
Who should adopt this and when
Already adopted, if you record all resource types. There is nothing to do except notice, and the noticing is worth a few minutes on the item count and the rule populations.
Worth a deliberate pass this week, if you record a selected list. Seventy-seven types is a large enough batch that the odds of something you want being in it are good, and the security-control types are the strongest candidates.
Worth a frequency review either way. The four-changes-a-day line is cheap to apply and most of these types sit clearly on one side of it.
Key takeaways
- Seventy-seven new resource types, in “all AWS Regions where the resources are available”, and usable in rules and aggregators.
- “if you have enabled recording for all resource types, then AWS Config will automatically track these new additions” — coverage and cost both move with no action on your side.
- A selected list is unaffected, which is the control working and the blind spot growing.
- $0.003 continuous, $0.012 periodic, one periodic item per resource per day — so the break-even is four changes a day, and most of these types are nowhere near it.
- Rules scoped to all supported types now evaluate more resources, so compliance counts can move without anything being misconfigured.
Official AWS references
- AWS Config supports 77 additional resource types — the count, the automatic-tracking behaviour for all-types recorders, rule and aggregator availability, and the Regional conditional
- AWS Config pricing — the continuous and periodic configuration item rates, the one-item-per-resource-per-day rule for periodic recording, and the rule evaluation rate
- Selecting which resources AWS Config records — further reading on recording strategies and per-type frequency; no claims in this post are drawn from it
Comments