[ECS] [request]: Add Instance-Level Metadata and Daemon Service Support to ECS Managed Instances

### 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

## Description

ECS Managed Instances is a powerful new capacity provider that simplifies EC2-backed ECS workloads by removing the need to manage EC2 instances, Auto Scaling Groups, and launch templates directly. However, customers migrating from traditional EC2 capacity providers are losing critical observability capabilities that they depend on for production operations.

This feature request covers three related gaps that significantly impact customers' ability to monitor task placement, troubleshoot AZ imbalances, and implement per-host observability agents.

---

## Gap 1: Add `ec2InstanceId` and `containerInstanceArn` to ECS Task Metadata V4 Endpoint

### Problem

The ECS Task Metadata V4 endpoint (`$ECS_CONTAINER_METADATA_URI_V4/task`) provides useful metadata including `AvailabilityZone`, `TaskARN`, `Cluster`, and `ServiceName`. However, it does **not** include the `ec2InstanceId` or `containerInstanceArn` of the host the task is running on.

For customers using traditional EC2 capacity providers, this gap can be worked around by:
- Querying the EC2 Instance Metadata Service (IMDS) at `169.254.169.254` from within the container
- Running a daemon service (e.g., CloudWatch Agent) on each host that collects and enriches metrics

**Neither workaround is available on Managed Instances:**
- **IMDS is blocked**: Managed Instances enforce `HttpPutResponseHopLimit=1`, which prevents containers from reaching IMDSv2 (the token PUT request's TTL expires before reaching the container network namespace). Customers have no control over this setting since they don't manage the launch template.
- **Daemon services are not supported**: ECS Managed Instances do not support daemon scheduling strategy, so customers cannot run a per-host sidecar to enrich metrics.

### Current Workaround

Customers must use a **Lambda poller** that calls `DescribeContainerInstances` and `DescribeTasks` APIs to build a task-to-instance-to-AZ mapping externally. This adds:
- Additional Lambda costs and operational overhead
- 1-minute polling delay (not real-time)
- Extra API calls that count toward ECS API throttling limits

### Requested Change

Add the following fields to the ECS Task Metadata V4 endpoint response (`/task`):

```json
{
"ec2InstanceId": "i-0abc123def456789",
"containerInstanceArn": "arn:aws:ecs:us-east-1:123456789012:container-instance/cluster/abc123..."
}
```

This would allow tasks to self-identify their host instance at runtime, enabling:
- Custom metrics with instance-level dimensions (via EMF or SDK)
- Real-time task-to-instance correlation without external polling
- AZ-aware connection routing and failover logic within application code

### Impact

This is especially critical for workloads like **PgBouncer / connection poolers** where customers need to:
1. Monitor how many connections each instance is handling
2. Detect AZ imbalance in task placement
3. Correlate application-level metrics (connections, latency) with infrastructure-level placement

---

## Gap 2: Add Per-Instance Metrics to Container Insights for Managed Instances

### Problem

Container Insights currently provides metrics at the **cluster**, **service**, **task-definition**, and **capacity-provider** level — but not at the **per-instance** level for Managed Instances. For traditional EC2 capacity providers, customers can run a CloudWatch Agent daemon service to collect and publish per-instance metrics. This is not possible on Managed Instances (see Gap 3: no daemon support).

As a result, customers have no out-of-the-box way to answer basic operational questions like:
- How many tasks are running on each instance?
- Are tasks evenly distributed across instances and AZs?
- Which instances are approaching resource limits?
- Is there a hot-spot instance handling disproportionate load?

### Current Workaround

Customers must build a Lambda poller that calls `DescribeContainerInstances` and `DescribeTasks` APIs every minute and publishes custom CloudWatch metrics. This is operational overhead that should be unnecessary for a managed service.

### Requested Change

Add the following **out-of-the-box Container Insights metrics** for ECS Managed Instances, with dimensions `{ClusterName, InstanceId, AvailabilityZone}`:

| Metric | Description |
|---|---|
| `RunningTaskCount` | Number of running tasks on the instance |
| `PendingTaskCount` | Number of pending tasks on the instance |
| `CpuRegistered` | Total CPU units registered on the instance |
| `CpuRemaining` | Remaining CPU units available on the instance |
| `MemoryRegistered` | Total memory (MiB) registered on the instance |
| `MemoryRemaining` | Remaining memory (MiB) available on the instance |
| `CpuUtilization` | CPU utilization percentage per instance |
| `MemoryUtilization` | Memory utilization percentage per instance |

These metrics are already available via the `DescribeContainerInstances` API — publishing them as first-class Container Insights metrics would eliminate the need for custom polling infrastructure and bring Managed Instances to parity with what's achievable on EC2 capacity providers via daemon CW Agent.

### Impact

This is the single most impactful change for Managed Instances observability. Customers migrating from EC2 capacity providers expect per-instance visibility in CloudWatch dashboards without building custom infrastructure.

---

## Gap 3: Support Daemon Services on ECS Managed Instances

### Problem

ECS Managed Instances do not support the `DAEMON` scheduling strategy. This means customers cannot run exactly-one-per-host services such as:
- **CloudWatch Agent** for custom metric collection and host-level monitoring
- **Log routers** (Fluent Bit, Fluentd) with host-level context
- **Monitoring agents** (Datadog, New Relic) that aggregate per-host metrics
- **Security agents** for host-level intrusion detection

On traditional EC2 capacity providers, daemon services are a standard pattern for per-host observability. Without this capability, customers on Managed Instances must either:
- Use sidecars in every task definition (increasing resource usage by N× instead of 1×)
- Use external Lambda pollers (delayed, adds cost and complexity)
- Emit metrics from within task containers using EMF (limited to what the application can observe)

### Requested Change

Enable `DAEMON` scheduling strategy for services using ECS Managed Instances capacity providers, behaving the same as daemon services on EC2 capacity providers: one task placed on each container instance, automatically scaling with the fleet.

### Impact

This would unlock the standard ECS observability pattern of running a single monitoring agent per host, which is more cost-efficient and operationally simpler than sidecar-per-task approaches.

---

## Summary of Gaps: EC2 Capacity Provider vs Managed Instances

| Capability | EC2 Capacity Provider | Managed Instances |
|---|---|---|
| IMDS access from containers | Configurable (HttpPutResponseHopLimit) | Blocked (HopLimit=1, not configurable) |
| Instance ID in task metadata | Not available | Not available |
| Daemon services | Supported | **Not supported** |
| Launch template control | Full control | **No control** |
| Container Insights per-instance metrics | Via daemon CW Agent | **Not available (no daemon, no out-of-box)** |

## Customer Use Case

A customer running PgBouncer on ECS Managed Instances needs to monitor connection distribution across instances and AZs. They emit custom metrics from containers using the CloudWatch Embedded Metric Format (EMF), enriched with AZ info from the ECS Task Metadata V4 endpoint. However, they cannot include instance-level dimensions because:

1. The task metadata endpoint doesn't expose `ec2InstanceId`
2. IMDS is blocked by `HopLimit=1` on Managed Instances
3. Daemon services (CW Agent) aren't supported to provide this enrichment

The customer currently relies on a Lambda function polling `DescribeContainerInstances` every minute to build the task-to-instance mapping, which adds cost, latency, and operational complexity.

**Ideally, Container Insights would provide per-instance metrics (task counts, CPU/memory utilization) as out-of-the-box metrics for Managed Instances (Gap 2), eliminating the need for custom infrastructure entirely. Additionally, adding `ec2InstanceId` to the task metadata endpoint (Gap 1) would allow customers to enrich their own application-level metrics with instance dimensions.**

## Priority

High - This is blocking adoption of Managed Instances for customers with per-instance observability requirements.