How to run AWS nodes
Last updated
Was this helpful?
Last updated
Was this helpful?
This blueprint has two options for running nodes. You can set up a single JSON RPC node or multiple nodes in highly-available setup. The details are below.
This setup is for small scale PoC or development environments. It deploys a single EC2 instance with both consensus and execution clients. The RPC port is exposed only to internal IP range of the VPC, while P2P ports allow external access to keep the clients synced.
An ongoing data synchronization process is configured with nodes in the Ethereum network with a sync node and RPC nodes.
The sync node is used to create a copy of node's state data in Amazon S3 bucket.
When new RPC nodes are provisioned, they copy state data from Amazon S3 bucket to speed up the initial sync process.
Applications and smart contract development tools access highly available RPC nodes behind the Application Load Balancer.
To begin, ensure you login to your AWS account with permissions to create and modify resources in IAM, EC2, EBS, VPC, S3, KMS, and Secrets Manager.
Once ready, you can run the commands to deploy and test blueprints in the CloudShell.
Make sure you are in the root directory of the cloned repository
If you have deleted or don't have the default VPC, create default VPC
Configure your setup.
To specify the Ethereum client combination you wish to deploy, create your own copy of .env file and edit it using your preferred text editor. The contents of your file for a Erigon / Lighthouse node deployment is as follows, which uses a sample config from the repository:
NOTE: You can find more examples inside the sample-configs directory, which illustrate other Ethereum client combinations.
Deploy common components such as IAM role, and Amazon S3 bucket to store data snapshots
Deploy Single RPC Node
After starting the node you need to wait for the inital syncronization process to finish. It may take from half a day to about 6-10 days depending on the client combination and the state of the network. You can use Amazon CloudWatch to track the progress. There is a script that publishes CloudWatch metrics every 5 minutes, where you can watch sync distance for consensus client and blocks behind for execution client. When the node is fully synced those two metrics shold show 0. To see them:
Open Dashboards and select eth-sync-node-<your-eth-client-combination> from the list of dashboards.
Once the initial synchronization is done, you should be able to access the RPC API of that node from within the same VPC. The RPC port is not exposed to the Internet. Turn the following query against the private IP of the single RPC node you deployed:
The result should be like this (the actual balance might change):
Deploy Sync Node
After starting the node you need to wait for the inital syncronization process to finish. It may take from half a day to about 6-10 days depending on the client combination and the state of the network. You can use Amazon CloudWatch to track the progress. There is a script that publishes CloudWatch metrics every 5 minutes, where you can watch sync distance for consensus client and blocks behind for execution client. When the node is fully synced those two metrics shold show 0. To see them:
Open Dashboards and select eth-sync-node-<your-eth-client-combination> from the list of dashboards.
Once synchronization process is over, the script will automatically stop both clients and copy all the contents of the /data directory to your snapshot S3 bucket. That may take from 30 minutes to about 2 hours. During the process on the dashboard you will see lower CPU and RAM utilization but high data disc throughput and outbound network traffic. The script will automatically start the clients after the process is done.
Configure and deploy 2 RPC Nodes
Give the new RPC nodes about 30 minutes (up to 2 hours for Erigon) to initialize and then run the following query against the load balancer behind the RPC node created
The result should be like this (the actual balance might change):
If the nodes are still starting and catching up with the chain, you will see the following repsonse:
Destroy RPC Nodes, Sync Nodes and Common components
How to check the logs of the clients running on my sync node?
How to check the logs from the EC2 user-data script?
I'm running sync node with Ethereum and Prysm or Lighthouse and it gets stuck during syncing, what should I do?
Usually restart helps Erigon client to re-connect with other nodes and continue syncing. To restart do the following:
This is the Well-Architected checklist for Ethereum nodes implementation of the AWS Blockchain Node Runner app. This checklist takes into account questions from the which are relevant to this workload. Please feel free to add more checks from the framework if required for your workload.
Data is backed up to Amazon S3 using tool.
From the AWS Management Console, open the , a web-based shell environment. If unfamiliar, review the for an overview and check out that we'll use to test nodes API from internal IP address space.
With the , you can deploy both single Ethereum nodes and multi-node high-availability configurations on AWS. Furthermore, Node Runners is designed to support client diversity, with configurations available for a variety of client combinations for the Execution Layer (EL) and Consensus Layer (CL).
Don’t see a client or client combination you would like supported? Open a GitHub or , we encourage to Node Runners!
Navigate to (make sure you are in the region you have specified for AWS_REGION)
Copy output from the last echo command with NODE_INTERNAL_IP=<internal_IP> and open to access internal IP address space. Paste NODE_INTERNAL_IP=<internal_IP> into the new CloudShell tab. Then query the API:
Navigate to (make sure you are in the region you have specified for AWS_REGION)
Visit the page to learn more about the Node Runners project. If you have questions, you can ask them on , with a “blockchain” tag.
NOTE: In this tutorial we chose not to use SSH and use Session Manager instead. That allows you to log all sessions in AWS CloudTrail to see who logged into the server and when. If you receive an error similar to SessionManagerPlugin is not found,
