ECS service discovery: Can I use short for inter-service communication?

The shortnames for service to service communication is something that really only works - in my exp - on a single host or at least in an environment where docker will have control over DNS on all hosts etc. In ECS + bridge networking mode you can set extra hosts and links, but then again that's not going to scale too well IMHO.

Now, where I certainly see the value in local dev with docker-compose to have links / aliases to make it easy to have service A and B talk to each other, in a highly distributed environment, I much prefer to rely on a proper service discovery.

When I have services that need to discover each other, I use AWS Cloudmap + ECS (some might use Consul) and let these two deal with DNS registration between each other. Now, yes that means you need FQDN, and maybe with a VPC DHCP Option setting the search domain you can get away with short names, but I have to admit that FQDN is nice.

But then also, one thing that a service discovery service does that DNS won't do, is provide client side discovery: instead of relying on DNS to find targets, and this can help achieve costs reductions too for traffic, have your client try first to do "list me all the instances / tasks for service A". To that query you can add "AND subnet == $(same_as_mine)". It will return a list of nodes, if empty, make the same request, without the condition, and so on. Active service discovery means extra steps to write in the code but I find it well worth it.

And then another thing you could use is a mesh which itself will use service discovery. It is a bit more work but also well worth it to be able to define application rules at the Layer7 (or layer 4 if you do TCP) and let the services work for you.