Repository navigation
feat(recommendations): carry AWS AvailabilityZoneId for any cross-account zonal EC2 purchase flow #812
Description
Follow-up from platform#792 (D3 in plan platform-792-az.md, deferred).
AWS availability zone NAMES (e.g. us-east-1a) are mapped to physical zones per account, so the same name can be a different physical zone in two accounts. Today this cannot bite: recommendations are collected per account (AccountScopeLinked), tagged with that account's ID, and bought with that account's credentials, and #807 refuses zonal recs whose rec.Account is not the collecting account (payer-account case). If a flow ever buys zonal EC2 RIs across accounts (org-level recs, a payer buying for members, shared recs), the AZ name is not a safe identity: use the zone ID (use1-az1, via DescribeAvailabilityZones) instead.
Scope: decide whether a cross-account zonal flow is planned; if so carry AvailabilityZoneId alongside the name through collection, the recommendations key, the purchase guard and the idempotency key. If not, record the decision and close.
Activity
IAmJSD commentedon Oct 26, 2026
Claiming: working on this
IAmJSD commentedon Oct 26, 2026
Checked on current main (01fb35a). This issue is a decision, not a code change, so it needs the owner.
State on main: no flow buys zonal EC2 RIs across accounts. Recommendations are collected per account and bought with that account's credentials.
dropForeignZonalEC2(internal/scheduler/zonal_recs.go, called fromscheduler.go~1108 and ~1128, tested inzonal_recs_test.go) drops and logs any zonal EC2 rec whoseAccountis not the collecting account. Exchanges are also same-account, andhandler_ri_exchange.gorefuses a zonal lookup without an AZ. AZ names are therefore only ever interpreted in the account they came from. I found no open issue that plans org-level recs, payer-buys-for-members, or shared recs.Options
AvailabilityZoneId(via DescribeAvailabilityZones) alongside the name through collection, the recommendations natural key, the purchase guard and the idempotency key. That needs a schema change, which means a migration. New migrations are on hold right now while the numbers are renumbered, so this couldn't start yet anyway.Recommendation: option 1. There's no consumer today, the safety guard is already in place and tested, and option 2 means a schema migration for a hypothetical flow.
Releasing this until the owner decides.
IAmJSD commentedon Oct 26, 2026
Released: needs an owner decision on whether a cross-account zonal EC2 flow is planned. Options and a recommendation are in the comment above.