When you'll mature from using Docker to high volume production, you should ditch containers at all, they are good for prototyping and testing, but not for production loads and production security.
Also containers are better for production security than just having apps sitting side by side on the same disk.
I can provide more specific details if there’s questions.
In general ECS is fine when you have 1 or 2 services, but once you have 10s or 100s it gets pretty unusable.
Logging: While ECS ships everything to cloudwatch, actually accessing them is a nightmare and usually more effort than it's worth. It's very easy on k8s to get logs shipped from every container to elasticsearch and browse with kibana.
Autoscaling: Possibly less of an issue now that fargate's a thing - but fargate's expensive. Kubernetes makes it easy to set up both node level autoscaling, and deployment level autoscaling
Ingress: With ECS you have to set up loadbalancers for every service individually - in k8s once the controller's properly set up every service defines its own ingress, and the only manual change you have to do is create a DNS entry (only if you can't use a wildcard)
Metrics: Prometheus is very ingrained in kubernetes, and you get a wealth of information from every service almost "for free" once you've installed it.
And more: service meshes, secret control (through e.g. vault), declarative definitions, provider agnostic
Kubernetes has a huge startup cost and learning curve, but is incredibly powerful once you're up and running
Logging: Subscribe the ElasticSearch Lambda to CloudWatch Logs group to have all logs in ElasticSearch domain. Kibana is included in 'AWS::Elasticsearch::Domain' resource.
Ingress: Yes, one ALB per one autoscaled ECS Service, I don't see it as a problem.
Metrics, And more: not sure I see the benefits. CloudWatch has miriad of metrics, you can get lost there :)
It might look hard, but here is great starting point : https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui....
Yes, if you want to use AWS, use Cloudformation templates, there is no way around it :)
If your app, running in Docker container, is compromised, like PHP webshell, it might try to escape the container. What capabilities you granted for your containers? CAP_SYS_ADMIN, CAP_NET_ADMIN or you have no idea? This is just one example of escaping https://www.twistlock.com/2017/12/27/escaping-docker-contain... and lets talk about namespaces, like user namespace. Is root inside container is a root user on host system?
Does it feels like production ready system?
2. Not running docker means you can lock your httpd by chroot, FreeBSD jail or OpenBSD pledge.
1. Every system has vulnerabilities. You can defend against them.
2. Any improperly configured system can be abused. In particular, the exploit you linked can be completely stopped with a litany of ways. https://news.ycombinator.com/item?id=16030107
Your argument going from "containers are unfit for production, you'll mature out of them one day" to "here's a small, preventable vulnerability" seems more like a security non-sequiter than an actual argument against containerization.
Further, claiming containers are not production ready is empirically and literally negated by them used, in production, by the largest tech companies that have ever existed.
If that's not enough, it's easy enough to ensure that a Pod is scheduled to run by itself in an otherwise unoccupied VM.
If that's not enough, the IaaS providers can be paid extra to ensure yours is the only VM on the physical machine.
You can have the same expensive guarantees, if you need them, but with a uniform control plane for all workloads. That's pretty attractive.
Also, this is not an argument _against_ containerization. You make no argument or show any evidence of performance benefits bare v. docker.
It's in this kind of a world that elastic compute provided by a cluster scheduler with efficient packing looks really appealing. And our jobs, while meaty in time and space, are stateless once the initial data is poured in, up until the results pop out - they are big functions, basically. Good match for a stateless container.
So k8s looks quite attractive.