Java Transport Client vs. Node Client on EC2

I've been attempting to do some cursory research on how best to create
clients for an Elasticsearch cluster on EC2. In reading through
http://www.elasticsearch.org/guide/en/elasticsearch/client/java-api/current/client.html
it would appear that having a Node client on our ES client applications
that is cluster aware would be ideal since it would (hypothetically) avoid
two hop requests. Is that a correct assumption? If one always has the
option, is there ever a situation where it is more desirable to use the
Transport client over the Node client?

Now, if we also assume that EC2 is the target deployment environment, where
being a part of an ES cluster involves discovery using the AWS API instead
of multi/unicast, is using a Node client problematic in this scenario?

Additionally for EC2, are there any other topologies one can consider for a
single cluster other than just having a homogenous set of instances that
are data nodes and then client applications with Node clients? For
instance, would there be any advantage to having a dedicated number of
instances that are data=false Nodes that use an EC2 instance type that
support high network performance (with enhanced networking, see
https://aws.amazon.com/ec2/instance-types/) that join the cluster of a
large number of less powerful instances that are data nodes and then have
ElasticSearch client applications just round-robin with transport clients
to those data=false Nodes?

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/71365346-440d-4214-a5c4-db2ccc2ecd64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.