feat(aws-ecs): add windows core and kernel optimized ecs amis

[ykethan]

Issue # (if applicable)

Closes #.

Reason for this change

ECS packages currently does not have all the AMI's from the documentation:
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html

Description of changes

adds

For Windows Server Core variants:

Windows Server 2022 Core: /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
Windows Server 2019 Core: /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized

For kernel-specific Amazon Linux 2 variants:

Amazon Linux 2 kernel 5.10: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended
Amazon Linux 2 kernel 5.10 (arm64): /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended
Amazon Linux 2 kernel 5.10 (GPU): /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended
Amazon Linux 2 kernel 5.10 (Neuron): /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended

Describe any new or updated permissions being added

Description of how you validated changes

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ The title scope of the pull request should omit 'aws-' from the name of modified packages. Use 'ecs' instead of 'aws-ecs'.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

[shikha372]

Thanks @ykethan for submitting this request, left few comments to address

[shikha372]

i don't think we were setting a default value for this.hwtype before, is my understanding correct

[ykethan]

you are right, we only set this on EcsOptimizedAmi class

aws-cdk/packages/aws-cdk-lib/aws-ecs/lib/amis.ts

Lines 118 to 122 in 6b441b7

	/**
	* Constructs a new instance of the EcsOptimizedAmi class.
	*/
	constructor(props?: EcsOptimizedAmiProps) {
	this.hwType = (props && props.hardwareType) || AmiHardwareType.STANDARD;

But in EcsOptimizedImage class dont set a default value during initialization

aws-cdk/packages/aws-cdk-lib/aws-ecs/lib/amis.ts

Lines 257 to 261 in 6b441b7

	/**
	* Constructs a new instance of the EcsOptimizedAmi class.
	*/
	private constructor(props: EcsOptimizedAmiProps) {
	this.hwType = props && props.hardwareType;

[shikha372]

okay a little bit confused, can we remove this default that we're adding here or its needed ?

hwType: this.hwType ?? AmiHardwareType.STANDARD,

[ykethan]

The default is needed in this case. Let me explain:

In the original code, we didn't have an explicit default for this.hwType in the EcsOptimizedImage class constructor - it simply assigns this.hwType = props && props.hardwareType which could leave it as undefined.

When we previously constructed the SSM parameter path, we had a series of conditionals:

+ (this.hwType === AmiHardwareType.GPU ? 'gpu/' : '')
+ (this.hwType === AmiHardwareType.ARM ? 'arm64/' : '')
+ (this.hwType === AmiHardwareType.NEURON ? 'inf/' : '')

With these conditionals, if this.hwType was undefined, none of these would match, which functionally behaves like using STANDARD (since no hardware-specific path segment would be added).

Now with the new shared utility function constructSsmParameterPath(), we need to provide an explicit hwType value. Using this.hwType ?? AmiHardwareType.STANDARD ensures we maintain the same behavior as before - if this.hwType is undefined, we default to STANDARD.

So while we're adding an explicit default here, it's not changing the actual behavior - it's just making the implicit default from the original code explicit for the utility function.

Let me know if this makes sense or if you'd prefer to handle it differently.

[shikha372]

okay got it, if I understand correctly, the AmiHardwaretype check was to add specific suffix like 'gpu/' or 'arm64', since there is no special case handling for this.hwType === AmiHardwareType.STANDARD its same as being undefined.

failing build

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 022da8d
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository