[FEAT] ECS: EC2 launch-type services need container instances so tasks can place and reach steady state

[matanbaruch]

Service

ECS

API Action / Feature

EC2 launch-type support for services: RegisterContainerInstance (or an emulated equivalent), task placement onto container instances, and services reaching a steady state (runningCount >= desiredCount) so DescribeServices/waiters complete.

AWS Documentation

• https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterContainerInstance.html
• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html

Why is this needed?

A CreateService with launchType: EC2 never reaches steady state: with no registered container instances in the cluster there is nowhere to place tasks, so tooling that waits on the service (terraform/pulumi with wait_for_steady_state, CLI waiters) hangs until timeout and the deployment fails.

Repro:

1. Create a cluster and a task definition (both work fine today).
2. aws ecs create-service --launch-type EC2 --desired-count 1 ...
3. aws ecs describe-services ... stays at runningCount 0 forever; a steady-state waiter times out.

Fargate-style placement without instances is not a workaround for tooling that pins launchType: EC2.

For the emulator a faithful ECS agent is probably out of scope; an emulated registration path (e.g. an implicit default container instance per cluster, or a lightweight RegisterContainerInstance that makes placement succeed) would be enough for EC2-launch services to run their containers and report steady state.

#2482 is active on ECS services but does not touch container instances or placement.

Are you willing to contribute a PR?

• Yes
• No

Happy to take a run at it if you can sketch the direction you would accept (implicit default instance vs a real RegisterContainerInstance surface).

[github-actions]

👋 Thanks for opening your first issue in Floci!

A maintainer will triage this and add the right service label. If you included a minimal reproduction and the Floci version, that is everything we need — no action required from you right now.

Come say hi in Slack if you want to talk it through with maintainers and other contributors. Questions about AWS behaviour, design tradeoffs, and rough proposals are all welcome there.

[AbarnaaSree]

I’d be interested in taking this up. I think an explicit lightweight RegisterContainerInstance model would be a good direction, with the emulator using registered instances for EC2 task placement and service reconciliation. This would keep the behavior closer to ECS while avoiding the complexity of implementing a full ECS agent. I’d be happy to work on the container-instance state, placement, and steady-state flow if that direction fits the maintainers’ expectations.

[matanbaruch]

Closing: this is fixed on current main. Re-tested against a build of main (ed16713): a launch-type EC2 service with zero container instances now reaches steady state. The aws ecs wait services-stable waiter passes with runningCount 1 / desiredCount 1 / one deployment, and a real container runs behind the task. The ECS service reconciliation overhaul that landed after 1.7.0 (service-owned task tracking via owningServiceArn, plus RegisterContainerInstance/DeregisterContainerInstance now existing) resolved the scenario this issue described.

@AbarnaaSree thanks for offering to pick this up. If strict AWS-fidelity placement (EC2 tasks refusing to run without registered container instances) is still wanted, that is a separate behavior discussion now, since enforcing it would break emulation setups that never register instances.