What Happened
- CloudWatch scaling: As of November 10, 2026, CloudWatch PromQL alarms can trigger EC2 Auto Scaling and Application Auto Scaling simple or step scaling policies using queries over CloudWatch OpenTelemetry metrics. Target tracking is not supported. Step scaling requires a query that returns one series for comparison with a threshold. Actions can be configured through the console, PutMetricAlarm API, CLI, SDKs, or CloudFormation. Standard alarm pricing applies. [2]
- OpenSearch upgrades: Amazon OpenSearch Service now supports clone-based upgrades for domains running OpenSearch 1.1 or later, or Elasticsearch 7.10. Teams can test a new version while the primary domain serves traffic, cancel before cutover, or roll back within a chosen retention period after cutover. The feature is available in supported AWS Commercial Regions, excluding Asia Pacific (New Zealand, Taipei, and Thailand) and Mexico (Central). [3]
- Partner planning: Eligible AWS Partners can now create or collaborate on business plans in AWS Partner Central, with AI-assisted readiness scores, goal tracking, attachments, exports, and APIs, SDKs, and notifications for integration. Access is for partners actively engaged with AWS Partner management teams in US East (N. Virginia). [1]
Why It Matters to Businesses
PromQL-triggered scaling lets teams use an existing query to drive supported scaling policies rather than maintain a separate classic metric alarm. Clone-based OpenSearch upgrades create a validation window before production cutover and a defined opportunity to reverse it afterward. Partner Central’s changes are narrower in scope but may reduce manual coordination for eligible partners preparing business reviews. [1][2][3]
Kimbodo Engineering Perspective
The useful change is not simply more automation; it is a clearer decision point. A scaling alarm still needs a query that represents demand rather than noise. An OpenSearch clone still needs workload-specific acceptance criteria, because a successful upgrade does not establish that application queries perform acceptably. An AI-assisted partner readiness score should inform a review, not replace evidence or ownership of the plan. [1][2][3]
How We Would Implement It
- For scaling, test the PromQL query against historical traffic, confirm it returns one series when used for step scaling, and define thresholds, steps, and rollback conditions in infrastructure as code. [2]
- For OpenSearch, inventory domain versions and regional eligibility, establish a query and performance baseline, validate the clone against representative reads, and set a retention period that gives operators time to detect regressions after cutover. [3]
- For Partner Central, connect planning notifications or APIs only where an eligible team has a clear workflow owner; keep exported plans and attachments within the organization’s existing document controls. [1]
Risks, Costs and Security
PromQL alarms carry standard alarm pricing, while poorly chosen thresholds can cause unnecessary scaling or delayed capacity. Clone-based upgrades require planning for temporary duplicate infrastructure and a finite rollback window; validate expected costs and data-handling controls before starting. Partner-plan integrations should use appropriately scoped access, particularly where attachments or business-review exports contain sensitive commercial information. [1][2][3]
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Application Development practice, or Estimate My AI Application.
