AWS → Azure Feature Parity Gaps

[rocketri]

Summary

This issue tracks the feature parity gaps between the AWS and Azure provider implementations, identified via static analysis of the codebase.

---

Services Covered

Domain	AWS	Azure
Compute	EC2	Compute (VMs)
Relational DB	RDS	Database (Azure SQL)
Cache	ElastiCache	Cache (Redis)
NoSQL	(none)	CosmosDB
Search	OpenSearch	Implemented but unreachable (see below)
Data Warehouse	Redshift	(missing)
In-memory DB	MemoryDB	(missing)
Savings Plans	SavingsPlans	(missing)

---

Gaps: Azure Behind AWS

Feature	AWS	Azure
Multi-account (Organizations)	Yes — enumerates org accounts automatically	No — GetAccounts discovers subscriptions but GetServiceClient only operates on one at a time
Savings Plans	Yes	No
Data Warehouse (Redshift)	Yes	No Azure Synapse equivalent
MemoryDB	Yes	No
Convertible RI exchange	Yes (EC2 only) — ListConvertibleReservedInstances, FindConvertibleOfferings	No
RI Utilization reporting	Yes — GetRIUtilization via Cost Explorer	No

---

Bug: Azure Search Client is Dead Code

providers/azure/services/search/ is fully implemented (GetRecommendations, GetExistingCommitments, PurchaseCommitment, ValidateOffering, GetOfferingDetails, GetValidResourceTypes) but is never reachable — GetSupportedServices() and GetServiceClient() in providers/azure/provider.go have no reference to it.

It needs to be wired up:

1. Add common.ServiceSearch to the GetSupportedServices() return slice
2. Add a case common.ServiceSearch: branch in GetServiceClient() returning NewSearchClient(...)

---

Azure-Only (AWS gaps)

• CosmosDB — no AWS NoSQL equivalent in CUDly
• Azure Search — once wired up, AWS OpenSearch is the counterpart

---

Notes

• All service clients that are implemented (both providers) share the full ServiceClient interface: GetRecommendations, GetExistingCommitments, PurchaseCommitment, ValidateOffering, GetOfferingDetails, GetValidResourceTypes
• Azure tags reservations inline at purchase time (embedded in the PUT body); AWS EC2/OpenSearch/Redshift make a separate tagging call post-purchase — this is parity via different mechanisms, not a gap
• GetRIUtilization is an AWS-specific extension explicitly outside the provider.RecommendationsClient interface

[cristim]

Sub-issues Filed

This meta-tracker has been split into the following triaged sub-issues:

Gap	Sub-issue
Azure multi-account (Subscriptions)	#553
Azure Savings Plans	#554
Azure Synapse data warehouse	#555
Azure in-memory database (Cache for Redis)	#556
Azure RI exchange	#557
Azure RI utilization reporting	#558
AWS NoSQL service support	#559

See individual issues for detailed scope, acceptance criteria, and suggested approaches.

[cristim]

PR #560 addresses the Azure Search wiring sub-task: GetSupportedServices() now includes ServiceSearch and GetServiceClient() dispatches to NewSearchClient(). Also fixed the pre-existing ServiceOther misclassification in the search client itself.

Remaining open gaps from the original analysis (not addressed by #560):

• CosmosDB client service type (check if it also returns ServiceOther vs ServiceNoSQL)
• Any other service clients not yet wired (check the issue description for the full list)
• The GetValidResourceTypes / ValidateOffering patterns may need integration testing once the client is reachable

[cristim]

Status update on the 7 split-out sub-issues:

• In flight (parallel): feat(providers/azure/provider): add multi-account (Subscriptions) support #553 Azure multi-account (P2), feat(providers/azure/services): add RI utilization reporting #558 Azure RI utilization reporting (P2)
• Queued behind P2s: feat(providers/azure/services): add Savings Plans support #554 (Savings Plans), feat(providers/azure/services): add Synapse data warehouse support #555 (Synapse), feat(providers/azure/services): add Cache for Redis support #556 (Managed Redis), feat(providers/azure/services): add RI exchange support #557 (RI exchange), feat(providers/aws/services): add NoSQL service support #559 (AWS NoSQL) — all P3, all effort/l. Holding off on parallel fan-out because each touches providers/azure/provider.go switch + go.mod Azure SDK deps, so concurrent agents would merge-conflict heavily. Will pick them up serially after the two P2s land.

Plus PR for the Azure Search wiring sub-task is in flight under separate branch fix/issue-473-azure-search-wiring.