[ECS] [bug]: Explicitly setting transitEncryptionPort for an EFS volume causes mount to fail on newer ECS agents

[clemens-oppenauer]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
Setting the "transitEncryptionPort" to any fixed value instead of relying on the automatic default value causes tasks to fail to mount the EFS volumes on newer (1.82.1+) ECS Agent versions. This used to work fine on 1.79.1 and lower.

Which service(s) is this request for?
ECS (EC2-backed)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
I'm trying to migrate a workload to ECS and in the process used fixed values for the transit encryption port as I was using the host network mode and wanted to avoid port collision issues. It has since been switched to the awsvpc mode. This used to work fine on ECS Agent 1.79.1 (ami-0630e81a78b8aa3cf) but immediately fails on ECS Agent 1.82.1 (ami-0737b92769833f216) with the following error message:

CannotStartContainerError: Error response from daemon: error while mounting volume '': VolumeDriver.Mount: failed to mount volume ecs-cassandra-13-cassandra_efs-bed3fac2cad489978b01: mounting volume failed: Specified port [3005] is unavailable.

The machine configurations are identical except for the AMI used. There are also no other services using that port on the machine.

Are you currently working around this issue?
Removing the "transitEncryptionPort" setting from the task definition and relying on the default value works fine. We will be using this configuration going forward, however this regression should still be investigated.

Attachments
collect-i-00c3bb98c256e2d62-202404121438.tgz