Direct container to container communication isn't the recommended pattern when using ECS. Instead you let ECS associate with either a legacy Elastic Load Balancer, or one of the new Application Load Balancers, which can direct requests to different classes of containers based on the request path, allowing you to take a set of containers of different types and meld their http resources together into one API on one domain.
If one container needs to talk to another container of a certain type it just uses the load balancer, and the load balancer takes care of directing the request to the other container which may be on the same machine, or another machine, or maybe even in a different cluster.
Obviously this forces you into a fully stateless design because the load balancer round robins all the requests across random containers, but its very fail proof, and gives you high resiliency.
That doesn't necessarily give you resiliency or fail proof. It's recommended that way because there is no other way with ECS. The reason is that unlike K8S, ECS does not inherently have a service discovery. K8S solved it well with a notion of services and has a built-in load balancer. The design is very solid and doesn't require you to pay for a set of ELB instances every time you want to do that. That is why I asked if ECS has added this. It sounds like it has not.
Yeah ECS is a pretty much just a dumb layer on top of docker that handles two things: placing your containers onto instances (and restarting them or replacing them if needed), and adjusting the settings on an ELB, or ALB so that the load balancer is pointed at an instance running the container.
The ECS approach is a pretty minimal to glue together a cluster of instances running docker and ELB, while Kubernetes has a lot more baked into the core implementation.
If one container needs to talk to another container of a certain type it just uses the load balancer, and the load balancer takes care of directing the request to the other container which may be on the same machine, or another machine, or maybe even in a different cluster.
Obviously this forces you into a fully stateless design because the load balancer round robins all the requests across random containers, but its very fail proof, and gives you high resiliency.