Repository navigation
fix(recfilter): dedupe key lacks account, platform, tenancy, scope, AZ and size-flex #323
Description
Problem
recfilter duplicate detection keys on resourceType|region|engine|deployment (pkg/recfilter/dedupe.go dedupeKey). Consumers that dedupe search results (the MCP search tool, cloud-commitments-mcp#42) therefore cannot trust it for several services:
- EC2:
GetExistingCommitments(providers/aws/services/ec2/client.go) fills only instance type and region, so a recent Windows, dedicated, AZ-scoped or Convertible reservation appears to cover a Linux regional recommendation. - No listing sets
Commitment.Account, while AWS recommendations carry the linked account (parser_ri.go), so from a payer account a purchase in one account can appear to cover another account's recommendation. - RDS size flexibility is not modelled (a larger covering reservation is not recognised), and ElastiCache reservations with an empty
ProductDescriptionact as a wildcard for every engine. adjustSingleRecommendationlowersCountbut leaves cost and savings at the full-count figures.- MemoryDB reserved nodes are always listed as engine
redis(memorydb/client.go:269).
Proposed
Add account, platform, tenancy, scope, AZ and size-flex dimensions to the commitment listings and to dedupeKey, keep cost and savings consistent when a count is reduced (or report the covered count instead), and add tests per service from the real parsers' recommendation shapes.
Until then the MCP consumer suppresses only RDS, OpenSearch, Redshift and ElastiCache (known engine) for the caller's own account and flags the rest.
Activity
cristim commentedon Oct 16, 2026
Claiming: working on a first slice here:
Commitment.Accountand EC2 platform, tenancy and scope in the commitment listing and indedupeKey, delivered as aRefs #323PR. RDS size-flex, the ElastiCache empty-description wildcard and the MemoryDB engine stay open for later slices. The count reduction already scales cost and savings since #379 (common.ResizeCount).cristim commentedon Oct 16, 2026
Design note before the first slice lands. Keying EC2 dedupe on account is unsafe by default, so this slice leaves it out.
With RI sharing on (the AWS Organizations default), a reservation bought in account A also discounts matching usage in account B. If the dedupe key included the account, a recent purchase in A would no longer suppress B's matching recommendation, and the guard would buy a duplicate. A duplicate-purchase guard has to fail toward suppressing.
The first slice therefore keys only the dimensions that rule out coverage whatever the sharing setting: platform, tenancy, scope, and AZ for zonal scope. A Windows, dedicated or zonal reservation cannot cover a Linux, default-tenancy or regional recommendation. A commitment in another account still suppresses, and a test pins that.
Open question for a maintainer: should account keying be added, and only where RI sharing is known to be off for that account? That needs a sharing signal this library doesn't have today.
feat(common): add EC2 platform, tenancy and scope dimensions to Commi…
feat(common): add EC2 platform, tenancy and scope dimensions to Commi…
fix(recfilter): match EC2 commitments on platform, tenancy and scope …
fix(recfilter): match EC2 commitments on platform, tenancy and scope …
fix(aws): report EC2 reservation platform, tenancy and scope so dedup…
cristim commentedon Oct 16, 2026
Slice 1 for EC2 is complete with #458 and #460 (merged) plus #465 (open). Dedupe now matches EC2 commitments on platform, tenancy and scope, and the EC2 listing reports them. This issue stays open for:
build(aws): bump pkg pin to include EC2 commitment dimensions
fix(aws): report EC2 reservation platform, tenancy and scope so dedup…
build(aws): bump pkg pin to include EC2 commitment dimensions
fix(aws): report EC2 reservation platform, tenancy and scope so dedup…
fix(aws): report EC2 reservation platform, tenancy and scope so dedup…