# Elasticsearch EC2 setup across multiple regions

**URL:** <https://discuss.elastic.co/t/elasticsearch-ec2-setup-across-multiple-regions/9170>\
**Category:** Elasticsearch\
**Created:** [September 27, 2012, 2:52pm UTC](https://discuss.elastic.co/t/elasticsearch-ec2-setup-across-multiple-regions/9170 "2012-09-27T14:52:08Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![Derry\_O\_Sullivan](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@Derry\_O\_Sullivan](https://discuss.elastic.co/u/Derry_O_Sullivan)\
**Post date:** [October 4, 2012, 4:08pm UTC](https://discuss.elastic.co/t/elasticsearch-ec2-setup-across-multiple-regions/9170/14 "2012-10-04T16:08:07Z")

</div>

To add to this, the EC2 plugin also works ok. It also seems to work fine  
without security groups too.

On the timeouts, i suspect 60s is slightly high given the fact that  
cross-region AWS comms are actually very fast but for 'uncontrollable'  
latency purposes, i've left it at a minute.

Done some wikipedia river testing on the setup and works perfectly with  
000's of docs.

On 4 October 2012 16:42, Drew Raines [aaraines@gmail.com](mailto:aaraines@gmail.com) wrote:

> Derry O' Sullivan wrote:
> 
> > For anyone who is interested, the problem was to do with my  
> > network.publish\_host setting. It was not being set correctly so  
> > both nodes could not contact each other. Once that was set  
> > correctly, all worked perfectly.
> 
> Here's a minimal 2-node zen config similar to what worked for him:
> 
> ```
> cluster.name: foo
> node.name: alice
> network.publish_host: 23.20.100.100
> discovery.zen.ping_timeout: 60s
> discovery.zen.ping.multicast.enabled: false
> discovery.zen.ping.unicast.hosts: ["54.247.55.55"]
> 
> cluster.name: foo
> node.name: bob
> network.publish_host: 54.247.55.55
> discovery.zen.ping_timeout: 60s
> discovery.zen.ping.multicast.enabled: false
> discovery.zen.ping.unicast.hosts: ["23.20.100.100"]
> 
> ```
> 
> If alice is in us-east and bob in eu-west, they won't be able to  
> communicate by 10/8 addresses[1]. Since an individual ec2 node knows  
> nothing about its public IP, its local interface is identified by a  
> 10/8 address.
> 
> When alice looks through the unicast list to try and join bob, she  
> will connect to bob's internal interface (due to his auto-resolved  
> network.bind\_host[2]) through the AWS perimeter by his public IP.  
> During the transport handshake, bob needs to tell her how to get  
> _back_ to him to communicate further, and that's what the  
> network.publish\_host is for. alice also tells bob about her  
> publish\_host, and they're off to the races.[3]
> 
> Derry originally was trying to get this working with ec2 discovery  
> and reported that correctly supplying publish\_host and his security  
> group caused it to work as well. So if you want a simpler  
> alternative to zen for this particular case, you should try that.
> 
> -Drew
> 
> Footnotes:
> 
> [1] They have to talk over public nets.
> 
> [2] In order to open a socket, ES has to bind to an interface. ES  
> can use the network.bind\_host setting if you don't want it to  
> resolve it for itself. And if you supply simply network.host  
> without the other two, it will use that IP to bind to an  
> interface and talk to peers.
> 
> [3] Note that this technique should also work across generic NATs if  
> you supplied appropriate host:port combinations in the unicast  
> list and then told your router to redirect those ports to  
> appropriate nodes.
> 
> --

--

---

_[View the full topic](https://discuss.elastic.co/t/elasticsearch-ec2-setup-across-multiple-regions/9170)._