Except when for example rsyslog caches DNS resolution forever. Or the log forwarded doesn't have a buffer and logs get lost.
That chances of failure go up dramatically if 2+ hosts behind round robin fail, etc.
Not to mention once hosts resolve this to an IP they will re-use the route. This approach is not balanced.
I don't want to be /that/ guy but if they can't scale with ELB they should invest in a dedicated load balancer infrastructure that can offload requests to their cloud instances.
This is a really bizarre post.
The 2+ hosts failing should not be much of a problem if you have a separate health checker host which does nothing except gathering heart-beats from all the hosts in your fleet and updating the DNS periodically.
If you have 3 hosts and 2 of them go down, in this setup there is more than 50% chance that cached hosts will be trying to connect to a non-existing server.
Also expecting client to perform a DNS lookup every time there is an outgoing log packet is pretty shitty for performance. You can't guarantee near instant DNS server availability for every client.
EDIT: To reply to myself http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hea... http://docs.aws.amazon.com/Route53/latest/APIReference/API_C...
Complementary to that it's also possible to assign reserved IPs to machines so that at least the set of IP is always the same even if the hosts get rotated. Assigning IPs to hosts is not instantaneous either and depends on an API call. Also IPs are tied to a specific region.
In a real datacenter other options are possible like sharing IP addresses between multiple devices and having lower-latency failover. These aren't perfect either and have different failure scenarios.