No great service discovery story that I can find. The best approximation is their GCE compute instance metadata service, which can be used as a pseudo-Consul or etcd for discovering active services. This metadata can be used to construct FQDN's for Google's internal DNS service: https://cloud.google.com/compute/docs/internal-dns
Strategies: https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/service-discovery.html
As in typical load balancing story. Reroute clients based on DNS or path. Use router specific hooks to check for service health and to manage load across services.
https://aws.amazon.com/blogs/aws/amazon-ecs-service-discovery/
ECS integrated DNS-based service discovery. Route 53 is a cloud DNS web services. Provides health and load handles to allow dynamic DNS resolution. DNS resolution is done locally within a closed-off AWS VPC.
Route 53 can be coupled with an external load balancer to provide (restricted) public subnet access to VPCs.
CloudWatch monitors container health (using ECS event stream) and fires a Lambda function to update Route 53 DNS entries.
Have microservices register with some CM system (Chef, Puppet) on start up. Requesting microservices then retrieve information about active receiving microservices via the CM.
New services register with DynamoDB. DynamoDB Streams propagates status changes to other services via Kinesis. Similar to Consul's or etcd's service discovery model.
This method avoids some of the issues with DNS-reliant strategies, like DNS caching, but requires applications to be intelligent enough to interpret the status of peer apps.
Some discovery is still needed for the "topic" to publish to, but that is usually considered well known information.