[Feature Request] Support EC2 to Windows Fargate migration via UpdateService capacity provider update
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### 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 updating an existing EC2-based ECS service to Windows Fargate by updating the capacity provider strategy, with automatic detection of platform family from the task definition's `runtimePlatform`.
Alternatively, add support for `--platform-family` parameter in the UpdateService API to explicitly set the platform family (Linux/Windows) when updating capacity providers.
**Which service(s) is this request for?**
ECS, Fargate
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Per the [June 2025 announcement](https://aws.amazon.com/about-aws/whats-new/2025/06/amazon-ecs-capacity-provider-configuration-ecs/), Amazon ECS now supports updating capacity providers for existing services, allowing customers to "seamlessly switch compute configuration of their ECS services by updating capacity providers, without any operational overhead or service disruption."
However, this feature does not work for Windows Fargate workloads.
**Scenario:**
1. I have an existing EC2 Windows service using `ec2-windows-on-demand` capacity provider.
2. I want to migrate to Windows Fargate.
3. I update the service with:
- Task definition with `runtimePlatform.operatingSystemFamily: WINDOWS_SERVER_2022_CORE`.
- Capacity provider strategy: `FARGATE`.
**Result:**
- Service's `platformFamily` defaults to `Linux` instead of detecting from task definition.
- Deployment stuck with no tasks provisioning (platform mismatch).
- Attempting to set `platformVersion: 1.0.0` fails with error: `"The specified platform does not exist"`.
**Evidence from testing:**
```s
**Migration Path** **Platform Family After Update** **Result**
EC2 Linux → Fargate Linux Linux ✅ ✅ Works
EC2 Windows → Fargate Windows Linux ❌ (incorrect, should be Windows) ❌ Stuck, no tasks
```
The capacity provider update feature works for Linux Fargate but not Windows Fargate because:
1. Platform family always defaults to `Linux`.
2. Platform family is NOT auto-detected from task definition's `runtimePlatform`.
3. UpdateService API has no `--platform-family` parameter to explicitly set it.
4. Windows Fargate requires `platformVersion: 1.0.0`, which is invalid for Linux platform family.
**Are you currently working around this issue?**
Yes. The workaround is to **create a new service** instead of updating the existing one:
```s
aws ecs create-service \
--cluster my-cluster \
--service-name my-service-new \
--task-definition my-windows-fargate-td \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[subnet-xxx],securityGroups=[sg-xxx],assignPublicIp=DISABLED}" \
--region us-east-1
```
When creating a NEW service, platform family is correctly auto-detected from the task definition's `runtimePlatform`. No explicit `platformVersion` is required.
**Note:** The issue only occurs when UPDATING an existing Windows EC2 service to Windows Fargate. Updating EC2 Linux services to Linux Fargate works correctly.
However, this workaround contradicts the announcement promise of "without any operational overhead or service disruption" and requires:
- Creating a new service
- Migrating traffic
- Deleting the old service
- Updating any references to the service
**Additional context**
- Related FR: #2312 (Windows platform family version upgrade in place).
- This is a different scenario: EC2 → Windows Fargate migration (not Windows 2019 → Windows 2022).
- Both issues share the same underlying limitation: inability to set/change platform family on existing services.
**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
Contributor guide
Research direction
Start by reproducing the EC2 Windows to Windows Fargate migration through the UpdateService API, using a task definition with runtimePlatform.operatingSystemFamily set to WINDOWS_SERVER_2022_CORE and a FARGATE capacity provider strategy. Done means the existing service detects or accepts the Windows platform family and provisions tasks successfully without requiring a replacement service.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- backend-api-design, cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100