ECS 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 infrastructure. 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.
Secrets to be fetched by CFN of the Service. "define a config file as a "volume" and mount into the container" is very unusual. Store it in S3, and give your Task's IAM Role permission to fetch it.
none of options are easy to use for a secret or a simple configuration file. If I have a configuration file, I can easily mount it with --volume option with docker run. But to get the same on ECS - requires a much more complex setup than what is needed for k8s. Why do I need EFS/EBS volumes? Why doesn't this work well with Secret Manager or Parameter Store?
Yes, k8s is a complex beast - but ECS isn't as clean as it looks.
One thing I do like in ECS is that you can specify an environment variable to be fetched from parameter store or KMS, without seeing it. A convenient balance.
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 infrastructure. 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.