AWS Daily Intelligence #68 - Whether these ten arrive depends on a choice you made years ago

Ten more resource types in AWS Config, including ElastiCache clusters and replication groups. Whether they start being recorded in your accounts tomorrow, and whether that costs you anything, is decided entirely by a recording strategy somebody chose when Config was first turned on.

“AWS Config now supports 10 additional AWS resource types across key services including Amazon ElastiCache and Amazon QuickSight.”

Executive summary

The ten are AWS::Billing::BillingView, AWS::MPA::IdentitySource, AWS::Connect::HoursOfOperation, AWS::Notifications::OrganizationalUnitAssociation, AWS::ElastiCache::CacheCluster, AWS::NotificationsContacts::EmailContact, AWS::ElastiCache::ReplicationGroup, AWS::Oam::Link, AWS::MediaLive::SignalMap and AWS::QuickSight::Agent. They work with Config rules and aggregators, and are available in all Regions where the resources themselves are.

The sentence that decides what happens in your estate is this one: “AWS Config will automatically track these new additions” — conditional on automatic recording for all resource types being enabled.

What changed

Before today you could not write a Config rule about an ElastiCache cluster, because Config did not record one. That is a bigger statement than it sounds: a resource type Config does not support is not evaluated as non-compliant, and it is not evaluated as compliant either. It is absent from the denominator.

#96 was about the gap between an evaluation result and a finding — that ERROR and NOT_APPLICABLE are not passes. This is the layer underneath: before a resource can return any of those four results, Config has to be recording its type. A compliance percentage is computed over what is recorded, and today that set changed for some accounts and not others.

Architecture

Diagram: AWS Config added 10 new supported resource types, and whether an account starts recording them depends on its recording strategy. An account recording all current and future resource types with exclusions picks up the new types automatically, which adds configuration items and cost without any action. An account recording specific resource types picks up nothing until someone adds them. The diagram also shows what a non-recorded resource still produces: AWS Config captures only the creation and deletion of that resource and no other details at no cost, the details page provides null values for most configuration details and no relationship or change information, and those create and delete notifications are sent during the periodic baselining process rather than on creation or deletion.

Two recording strategies, two different outcomes from the same announcement

Your recording strategy	What happens today	What it costs
“Record all current and future resource types with exclusions”	The ten start being recorded, with no action and no notification	New configuration items, charged as usual
Record specific resource types	Nothing — the list is explicit and these are not on it	Nothing, and no new coverage either

Neither outcome is wrong and neither produces an event. An estate that standardised on recording everything has just widened its Config footprint; an estate that curates a list has just had its coverage gap grow by ten types without anything changing.

What a non-recorded resource still gives you

Worth knowing because it is better than nothing and much worse than recording: “If a resource is not recorded, AWS Config captures only the creation and deletion of that resource, and no other details, at no cost to you.”

“The details page for a non-recorded resource provides null values for most configuration details, and it does not provide information about relationships and configuration changes.”

And those events are not timely: “These resource types are only recorded during the periodic baselining process … which is at a less frequent cadance than that for the other resource types”, so “create and delete notifications are not sent upon creation or deletion, but during the baselining process”.

A row in the console for an ElastiCache cluster with null configuration, appearing some time after it was created, is exactly the kind of thing that reads as coverage in a screenshot and is not.

If you turn these on, expect a spike

“You might notice increased activity in your account during your initial month recording with AWS Config when compared to subsequent months”, because “During the initial bootstrapping process, AWS Config runs evaluations on all the resources in your account that you have selected for AWS Config to record.” Adding resource types to an existing recorder is a smaller version of the same event.

Business value

ElastiCache is the one that will matter to most estates. Cache clusters and replication groups hold configuration worth auditing — encryption settings, network placement, version — and until now none of it was in Config's inventory or available to a Config rule, a conformance pack or an aggregator.

AWS::Billing::BillingView and AWS::MPA::IdentitySource are the quietly interesting ones: configuration of how billing is viewed and how multi-party approval identities are sourced are both things a security reviewer would want change history on, and now there is some.

Security considerations

Coverage changed asymmetrically across your estate, and nothing announced it. If some accounts record all types and others curate a list — which is common, because the curated ones are usually the cost-sensitive ones — your organisation's Config coverage just diverged a little further. An aggregator will show you the result without explaining the cause.

A rule with nothing in scope is quiet, not green. Writing a conformance pack rule for AWS::ElastiCache::CacheCluster in an account that does not record it produces no findings, which looks identical to compliance. This is the #96 problem one level down.

Cost considerations

Config bills on configuration items, so new recorded types mean new items. The accounts that adopt these ten automatically are precisely the ones that did not evaluate whether they wanted to.

The lever if that matters is recording frequency: “Daily recording allows you to receive a configuration item (CI) representing the most recent state of your resources over the last 24-hour period, only if it's different from the previous CI recorded.” AWS lists cost efficiency among its benefits, and the arithmetic is less obvious than that suggests. The rates are “$0.003 per continuous configuration item” and “$0.012 per periodic configuration item” — a periodic item costs four times a continuous one, so daily recording saves money only where it produces fewer than a quarter as many items. For a resource that changes several times a day that is easily true; for one that changes once a week it is the opposite, because the daily mode still emits an item whenever the state differs.

One caveat before reaching for it either way — “AWS Firewall Manager depends on continuous recording to monitor your resources.”

Operational considerations

Region support is not a barrier to enabling the type. “If a resource type is supported by AWS Config in at least one Region, you can enable the recording of that resource type in all Regions supported by AWS Config”, so you can set the intent once rather than tracking per-Region rollout.

Exclusion is the strategy that ages well. Recording all current and future types with an exclusion list means new types arrive by default and you subtract the ones you do not want. An inclusion list means every AWS expansion is a change request nobody raises.

Tradeoffs

Recording all current and future types	Recording a specific list
New types arrive automatically, so coverage keeps pace with AWS	Cost is predictable and nothing changes without a decision
Cost grows without a decision being made	Coverage silently falls behind every time AWS adds types
Ephemeral workloads can generate substantial recording volume	A rule written for an unrecorded type returns nothing and looks clean

Implementation guidance

Find out which strategy each account actually uses before deciding anything. In a large organisation this is rarely uniform, and the answer determines whether today's announcement was a cost event, a coverage event, or nothing.

If you curate a list, decide on these ten explicitly. ElastiCache is the one worth adding for most people; the others depend on whether you use the service at all.

If you record everything, check what the new types did to your item volume after a few days rather than at month end.

Prefer exclusion over inclusion as the standing strategy, and keep the exclusion list as the place where cost decisions are recorded with reasons.

Best practices

Treat the recording strategy as a governed setting rather than a per-account default. It decides what every compliance number in the organisation is computed over, and it is usually set once by whoever enabled Config.

When a rule reports nothing, confirm the type is recorded before concluding anything. Silence has two causes and only one of them is good news.

Use exclusions for ephemeral workloads rather than narrowing the inclusion list — AWS suggests exactly this for Spot instances, EMR jobs and Auto Scaling churn, and it keeps the default open.

Who should adopt this and when

Nothing to adopt if you record all types — it has happened. Verify the cost effect and move on.

Add ElastiCache now if you curate a list and run ElastiCache. Cluster configuration is audit-relevant and this is the first time it has been available to Config rules.

Revisit your strategy if this announcement surprised you in either direction. That surprise is the useful signal here, more than the ten types.

Key takeaways

Ten new types, and your recording strategy decides whether you get them. Record-all accounts have them already; curated accounts will never get them without a change.

Unrecorded is not invisible, but it is close. Creation and deletion only, null values for the rest, and delivered on the baselining cadence rather than when it happened.

Coverage is the denominator of every compliance number you report. A type Config does not record cannot be compliant or non-compliant; it is simply not counted.