It depends on the AWS product.
For the container systems e.g. ECS, EKS, Fargate they have an open roadmap where they drive much of the direction from the community:
https://github.com/aws/containers-roadmap
For others it's completely closed off. At my last company we spent tens of millions a year with AWS and they never listened to us. The account managers have zero pull.
In Amazon RDS on Graviton2 Processorsaws
containers-roadmap
Shell2018–2026
aws / containers-roadmap
containers-roadmap
This is the public roadmap for AWS container services (ECS, ECR, Fargate, and EKS).
32Distinct people
35Mentions
0Explicit recommenders
5.4KGitHub stars
What to know before exploring
What it is
This is the public roadmap for AWS container services (ECS, ECR, Fargate, and EKS).
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year35 dated mentions
Observed mentions: 2018-12-12 11:04:40 UTC to 2026-07-21 19:57:17 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 3 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Containers Roadmap
This is the public roadmap for AWS container services (ECS, ECR, Fargate, and EKS).
Introduction
This is the public roadmap for AWS Container services.
Knowing about our upcoming products and priorities helps our customers plan. This repository contains information about what we are working on and allows all AWS customers to give direct feedback.
See the roadmap »
Other AWS Public Roadmaps
AWS Proton
CloudFormation coverage
AWS Elastic Beanstalk
Amazon EC2 Spot Instances integrations
AWS Controllers for Kubernetes (ACK)
AWS CDK
AWS App Runner
Developer Preview Programs
We now have information for developer preview programs within this repository. Issues tagged Developer Preview on the public roadmap are active preview programs.
Current Programs
There's more to come! Stay tuned!
Past Programs
EKS on ARM - EKS on AWS Graviton2 is generally available
ECS Multiple Target Groups - Support for multiple target groups on ECS is generally available
Firelens - Support for custom log routing is generally available
EKS Windows - Support for Windows on EKS is generally available
Security disclosures
If you think you’ve found a potential security issue, please do not post it in the Issues. Instead, please follow the instructions here or email AWS security directly.
FAQs
Q: Why did you build this?
A: We know that our customers are making decisions and plans based on what we are developing, and we want to provide our customers the insights they need to plan.
Q: Why are there no dates on your roadmap?
A: Because job zero is security and operational stability, we can't provide specific target dates for features. The roadmap is subject to change at any time, and roadmap issues in this repository do not guarantee a feature will be launched as proposed.
Q: What do the roadmap categories mean?
Just shipped - obvious, right?
Coming soon - coming up. Think a couple of months out, give or take.
We're working on it - in progress, but further out. We might still be working through the implementation details, or scoping stuff out.
Researching - We're thinking about it. This might mean we're still designing, or thinking through how this might work. This is a great phase to send how you want to see something implemented! We'd love to see your usecase or design ideas here.
Q: Is everything on the roadmap?
A: The majority of our development work for Amazon ECS, Fargate, ECR, EKS and other AWS-sponsored OSS projects are included on this roadmap. Of course, there will be technologies we are very excited about that we are going to launch without notice to surprise and delight our customers.
Q: How can I provide feedback or ask for more information?
A: Please open an issue!
Q: How can I request a feature be added to the roadmap?
A: Please open an issue! You can read about how to contribute here. Community submitted issues will be tagged "Proposed" and will be reviewed by the team.
Q: Will you accept a pull request?
A: We haven't worked out how pull requests should work for a public roadmap page, but we will take all PRs very seriously and review for inclusion. Read about contributing.
License
This library is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.
To learn more about the services, head here: http://aws.amazon.com/containers
Read the full README on GitHubWhat Hacker News says
10 sourcesECS is a joke. Implementing scaling policies is way too complicated, don't even get me to talk about scaling out with EC2-based capacity providers [1]. Combine that with the mediocre job cloudwatch does at collecting and allowing to act on realtime metrics, you end up with a solution where you still have to do everything yourself. And the tooling and integration is not on par with what the k8s ecosystem is sporting nowadays.
What people want is a cluster engine they shove a bit of text into and it does the rest. Integrated k8s does a job well enough with that, as does ECS. The difference is, k8s knowledge is transferrable to a growing number of businesses, ECS knowledge is not. Something to keep in mind if you're looking for employment in that area.
k8s also has the beauty of being able to exist completely disjointed from AWS infrastruct
Read the rest
ure. Nothing better than being able to lock in clueless product teams -- not every dev is interested in that whole "service ownership" idea -- into their clusters and let them bear the responsibility. ECS is way too tightly integrated with AWS, and requires changing a lot more infrastructure. This is not easy to allow in an org where the NOC assigns VPC and general network layout.
---
[1] Fargate still does not support CMK encrypted ephemeral volumes https://github.com/aws/containers-roadmap/issues/915. From which you can tell, nobody who is spending serious money with AWS is using ECS too much based on this, as they would have hopped on implementing it by now. And using AWS integrated containers without fargate is pointless IMO, as that's exactly the kind of service you'd be looking to get from paying extra for big cloud.
I was expecting this to be about the NLB's strange "lag" in updating its flows, wreaking havoc when it comes to changes in the target group, and possibly also relating to weirdly long delays before starting health checks of newly registered targets. I'm bewildered why this hasn't been more of a problem for others, and also why AWS seem to have kind of silently acknowledged the issue (by not closing them), while not coming up with a fix, even after a year. Am I the only one seeing this problem? Ref: https://github.com/aws/containers-roadmap/issues/470 and https://github.com/aws/containers-roadmap/issues/469
In AWS NLBs and the mixed up TCP connectionsReally? I'd found even simple things like volume mounted secrets a pain to use.
https://github.com/aws/containers-roadmap/issues/56
In A Kubernetes operator to sync secrets from AWS Secrets ManagerIf you use ECS/EKS:
Customer action is required, and steps for immediate mitigation are available at
https://github.com/aws/containers-roadmap/issues/976
All Amazon ECS and Amazon EKS customers should update to the latest AMI.
In Container Networking Security Issue (CVE-2020-8558)I looked into this some time ago and found that wireguard cannot run on fargate due to requiring kernel modifications and the userspace implementation[0] has similar blockers.
[0]: https://github.com/aws/containers-roadmap/issues/239
In Bastions on demand in an AWS VPCI don't really agree that it's been abandoned, nothing suggest that this is true. They're not known for just abandoning established services, there's a public roadmap[0] that you can follow. Like all services there are pros and cons. Up until very recently EKS lacked more or less everything ECS has in tight integration with other AWS services, so there's that.
[0] https://github.com/aws/containers-roadmap/projects/1
In AWS services to avoidWhile CloudFormation is annoying to use without extra tooling (like Sceptre -- makes management of dependencies between outputs and inputs go away easily, and it's extensible with plain Python), Terraform is horrible in its own ways. The AWS provider has many consistency issues, even glaring ones like not detecting that IAM policy documents have not changed when using lists in actions=[] and resources=[], and after having tried it, it makes me uncomfortable managing large landscapes with it.
Terraform makes mostly sense -- because there is good tooling around CloudFormation, and CFN more often than not does the well enough -- when you find out that CloudFormation is like Terraform just a driver for AWS APIs, likely developed by a dedicated team, and as such features of the underlying APIs are often not exposed at release time in CloudFor
Read the rest
mation. I noticed this especially when experimenting with EKS: There's eksctl, which integrates with CloudFormation (generates some stacks) but is utterly useless for integration because you can't import outputs or exports, so you have to hardcode all your SG IDs, VPC IDs, Subnet IDs if you want to integrate with existing infrastructure (https://github.com/weaveworks/eksctl/issues/1141). Dealbreaker, waste of time, disappointing for an "official" CLI. Next, there's pure CloudFormation -- but no luck for you, to this day AWS doesn't support EKS endpoint access control settings through CloudFormation (https://github.com/aws/containers-roadmap/issues/242 - dealbraker, if you need that and are allergic against public control endpoints in your infrastructure. Looking at Terraform -- it supports integration with existing CloudFormation infrastructure and can access CFN exports, it supports all the EKS settings you'd want, it offers a consistent interface to these features, so you got something to use, short of rolling your own.
Mind you, CloudFormation is extensible using Custom resources, but hacking around CloudFormation is likely not worth your time and something Amazon should do. Anyway, CloudFormation is likely one of the most tested and well-working parts of AWS, so I'd prefer it over third-party state management unless I find a very good reason to do so.
More broadly it just has so many rough edges and unfinished things. You can now do audit logging but you can't set an audit configuration so it logs everything (I think we had 200k events a day on a tiny cluster). You can tie service accounts to IAM roles but only if you cluster was created or upgraded after a certain date. You can't change or add subnets to the cluster without recreating it. Can't back a cluster or restore a cluster. Private load balancers require a non-standard configuration. EKS is still on 1.14 even though 1.17 is already out. The list goes on. Here's the current list of big and small issues people have with EKS: https://github.com/aws/containers-roadmap/issues?q=is%3Aopen...
In Kops – Kubernetes OperationsHeads up, AWS has a public GitHub repo (https://github.com/aws/containers-roadmap) where users can submit bugs and feature request for managed Kubernetes (EKS). It is quite robust and actively maintained by AWS engineers.
Recently managed Kubernetes on AWS (EKS) rolled out the ability to make your master public or private. Previously if you set it to private, you were only able to lookup the master endpoint DNS entry within the VPC. After much backlash[1], they now advertise the private ip publically which allows much greater flexibility. A highly anticipated and nice change.
[1] https://github.com/aws/containers-roadmap/issues/221
In Kops – Kubernetes Operations