Using an AWS EC2 as a Cosmos Node

Using an AWS EC2 Instance as a Cosmos Full-Node

Things I found helpful…

Just to share with the community, I learned the following when attempting to use an AWS EC2 as a Cosmos Full-Node to join the Cosmos Testnet. I hope that this information is helpful to others embarking on the journey.

Need more than an AWS EC2 type “t” instance

The EC2 instance types that begin with the letter ‘t’ don’t allow for continuous compute as needed to join the network. Using an m5.large seems to suffice.

Need a static IP address

The EC2 instance will grab a new IP address with every restart – unless you allocate and associate an Elastic IP address with the instance. Elastic IP is AWS’ name for a static IP address.

Since peers keep track of your IP address, it needs to remain constant to avoid confusion.

Need a bigger disk than 8GB

By default, EC2 instances come with an 8 GB disk (aka AWS Elastic Block Storage). This is not enough to store the data for the Cosmos Testnet. It looks like 32 GB should be enough. So you’ll need to both upgrade and expand the disk (following AWS procedures).

Need to publish the public IP address (not the private)

By default, the EC2 instance is on a Virtual Private Network (VPN) aka AWS Virtual Private Cloud (VPC). And as such, it is not reachable by peer nodes on the internet. The config/config.toml file must be modified to publish the node’s public IP address.

For example (assuming your IP address is

# Address to advertise to peers for them to dial
# If empty, will use the same port as the laddr,
# and will introspect on the listener or use UPnP
# to figure out the address.
external_address = "tcp://"

Need to open firewall for Cosmos ports

By default, AWS EC2 Instances have firewall settings that are closed to inbound connections (but open to outbound). Rules need to be added to open ports 26656 to inbound connections.

In AWS, the firewall settings are known as Security Groups. A Security Group with inbound All to 26656 must be associated with the AWS EC2 instance.

See What ports does `gaiad` use? for more information about the ports used.

Need to allow for more than 1024 open files

By default, Linux limits you to 1024 open files. Cosmos needs more than that. Raise the limit to 4K.

> ulimit -n 4096

Need to have good seeds to join the network

The GAIA Testnets are full of nodes in various states. You’ll need to use Cosmos Explorer ( to find full nodes and then paste their Persistent Peer Addresses into the seeds= setting in config/config.toml. It is a comma-separated list of persistent peer addresses in the format of <node_id>@<ip_address>:<port_number> where port_number is almost always 26656.

Once you connect with a good peer, the list expands itself through a gossip protocol. But getting started can take some time. If you’re restarting with a changed list of seeds, it’s helpful to delete the config/addrbook.json file to avoid confusion.

Some useful commands

I found these commands very helpful.

Important to save the results of the init command

When you do the initial gaiad init on your node it will emit a JSON with some important information in it. You should store this information safely as you may need it in the future. I used something like this.

gaiad init | tee $HOME/gaiad-init-result-`hostname`-`date +%Y%m%d%H%M%S`.json

Tail’ing the log

The gaiad program spits out a ton of log information. I found it useful to use something like this to filter only the Ensure peers and every 10th Indexed block lines. (assumes log is in $HOME/nohup.out)

tail -n 10000 -f $HOME/nohup.out | grep 'Indexed block.*height=[1-9][0-9]*[0-9]0$\|Ensure peers'

Listing current node status

This one will list out the status of your node’s software etc.

gaiacli status

Listing current peers info

This one will list out the status of your peers and connections.

curl http://localhost:26657/net_info

Very good writeup for beginners who want to join the testnet! Just a slight comment on opening ports for Cosmos: You don’t need to open port 26657 to the public. If you’re running sentry nodes, this should actually be avoided, because it opens access to the RPC and therefore could leak the IP address of your validator node. Here is a good thread about what ports gaiad is using and if they should be opened or not.

Yep! I’m in the middle of setting up a bank of nodes and this was all spot on. The t2 instance really got me, because gaiad is just a compute hot. Even on a t2.large, there never seemed to be enough computer. Once I switched to the C series, though, everything went smoothly. Great writeup.

I added your suggestions and link to the above. Thanks for clarifying.

I added a paragraph about expanding the 1024 Open Files Limit to 4096.

Very helpful!

Is there is any minimum recommended configuration for running a full node. I can see they mentioned about RAM and Storage but did not about CPU. Are 2 cores are sufficient?