AWS CDK construct fixes SageMaker AI auto scaling updates

The problem AWS addresses here is a structural mismatch between SageMaker AI's requirement to deregister a scalable target before changing an endpoint and CloudFormation's inability to track Application Auto Scaling resources once they are deregistered. The post lays out three distinct failure modes: an immediate rejection when auto scaling is still registered, a silent loss of scaling when only the endpoint configuration changes, and a broken stack with a failed rollback when both endpoint and scaling parameters change.

The construct's design reflects those failure modes. It splits the work into three custom resources with explicit dependency ordering: Deregister runs first, the endpoint update proceeds normally, then Register Scalable Target waits for InService status before re-registering, and Attach Scaling Policy waits for the target to become queryable before applying the policy. A ConfigHash property on each resource forces re-invocation whenever either the endpoint or auto scaling configuration changes.

The post also details the resource footprint: the deployed stack contains three custom resources, two Step Functions state machines, and twelve Lambda functions, of which five hold the construct's own handler code and seven are generated by the CDK provider framework. For teams already managing SageMaker AI endpoints through CDK, the construct can be copied into an existing project and added alongside current endpoint resources.