[ECS] [Feature Request]: Support ConnectionTrackingSpecification on task ENIs (awsvpc mode, EC2 launch type)

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) 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**

Allow ECS task definitions (or ECS service configuration) to specify `ConnectionTrackingSpecification` parameters (`TcpEstablishedTimeout`, `UdpTimeout`, `UdpStreamTimeout`) for task ENIs.

Currently, EC2 instances support configuring connection tracking timeouts via `modify-network-interface-attribute`, but ECS task ENIs (created in `awsvpc` networking mode) are `RequesterManaged` and ephemeral — there is no declarative way to set connection tracking timeouts on them at creation time or through the task definition.

According to [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html), this feature is available only with [Nitro-based instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-hypervisor-type), so the task or service definition would need to conditionally apply this for ECS on EC2 launch type with Nitro instances.

**Which service(s) is this request for?**
ECS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

This is relevant to any ECS workload that handles high volumes of short-lived connections — DNS resolvers, gRPC services, real-time messaging, API gateways, SIP servers, SNMP collectors, Syslog aggregators, or any service where connections are numerous but individually brief.

When connection tracking is active on an ENI (which is [always the case](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#security-group-connection-tracking-automatically-tracked) for traffic flowing through NLBs, NAT Gateways, PrivateLink, or Network Firewall), the default timeouts are:

| Parameter | Default | Impact |
|-----------|---------|--------|
| `TcpEstablishedTimeout` | 432,000s (5 days) | A TCP connection idle for 2 minutes will never be reused, yet its conntrack entry persists for 5 days |
| `UdpStreamTimeout` | 180s | Excessive for request/response UDP patterns like DNS |
| `UdpTimeout` | 30s | Reasonable for most cases |

For workloads handling millions of connections, these defaults cause conntrack table entries to accumulate far beyond what is necessary. Once the ENI's conntrack capacity is exhausted, new connections are silently dropped — visible as `conntrack_allowance_exceeded` in VPC Flow Logs and CloudWatch ENI metrics. This is a hard failure with no graceful degradation.

The [AWS documentation on connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) explicitly recommends adjusting these timeouts for several scenarios that are common in ECS workloads:

- **High connection counts through load balancers or firewalls** — NLB idle timeouts are fixed at 350s (TCP) and 120s (UDP). The documentation states that configuring timeouts at the network interface level allows "more flexibility for timeout than the defaults for the load balancer." For workloads where connections are short-lived, aligning ENI timeouts closer to actual connection lifetimes (rather than the NLB's fixed values) significantly reduces conntrack table pressure.

- **Stale session accumulation** — If `conntrack_allowance_exceeded` drops are observed, AWS recommends "setting a lower TCP established timeout to account for stale TCP/UDP sessions resulting from improper clients or network middle boxes."

- **UDP-heavy workloads (DNS, SIP, SNMP, Syslog, Radius)** — AWS recommends setting `UdpStreamTimeout` to 60s to provide "higher scale/performance for existing capacity and to prevent gray failures."

- **High connection counts from appliances** — For workloads handling greater than 100k connections from appliances like network firewalls (which typically have TCP idle timeouts of 60–90 minutes), AWS advises configuring a similar timeout on the EC2 network interface.

The fundamental problem is that ECS task ENIs are created and destroyed by the ECS service — they are `RequesterManaged` and ephemeral. There is no point in the task lifecycle where a user can declaratively set `ConnectionTrackingSpecification`, even though AWS explicitly recommends tuning these values for the exact workload patterns commonly run on ECS.

**Are you currently working around this issue?**

There is no viable workaround. ECS task ENIs are `RequesterManaged`, which means the `ModifyNetworkInterfaceAttribute` API cannot be called on them by the customer — the call is rejected. Unlike instance-attached ENIs, there is no post-creation mechanism to adjust connection tracking timeouts on a task ENI.

The only mitigation is to structure security group rules to [disable connection tracking entirely](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections) (inbound from `0.0.0.0/0` + outbound to `0.0.0.0/0`), but this:
- Is not viable for workloads that require restricted source CIDRs for access control
- Does not help for NLB-fronted services, since traffic through NLBs is [always tracked](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#security-group-connection-tracking-automatically-tracked) regardless of security group rules

For workloads where connection tracking is forced (NLB, NAT Gateway, PrivateLink, Global Accelerator paths), there is currently **no workaround** — the default 5-day TCP timeout and 180s UDP stream timeout cannot be changed on task ENIs, despite AWS documentation explicitly recommending timeout tuning for these exact scenarios.

**Additional context**
N/A
**Attachments**
N/A

Start with the ECS task definition and ECS service configuration entry points named in the request, then trace how awsvpc task ENIs are created for EC2 launch type. Compare the requested ConnectionTrackingSpecification parameters with the Nitro-instance restriction; done means a documented declarative configuration exists for supported task ENIs and its unsupported cases are defined.

Written by the indexing model from the issue text.