Guidance for Running Ethereum Clients on AWS
Overview
How it works
These technical details feature an architecture diagram to illustrate how to effectively use this solution. The architecture diagram shows the key components and their interactions, providing an overview of the architecture's structure and functionality step-by-step.
Well-Architected Pillars
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
Operational Excellence
The deployment is fully automated with infrastructure as code (IaC). IaC allows you to define your entire workload as code, helping you to automate procedures, quickly implement changes, and consistently respond to events.
Security
You can use security groups on AWS to control traffic to associated resources. The solution uses a default VPC but creates new security groups, limiting Internet access only to the ports required for peer-to-peer communication. These security groups help ensure that only specific instances on AWS can access the JSON RPC ports on Ethereum nodes.
Reliability
The sync node is periodically stopped to copy data to an S3 bucket. In case the RPC nodes in the EC2 Auto Scaling group fails, it can use the most recent copy of the data to restore the latest state and avoid a long sync time for data recovery.
Performance Efficiency
Because Ethereum nodes run stateful, long-running and monolithic software, EC2 instances are the optimal choice for compute. Amazon Elastic Block Store (Amazon EBS) gp3 volumes use higher than standard IOPS and throughput to provide better response times. An Application Load Balancer ensures requests are spread across a highly available EC2 instances running RPC nodes.
Cost Optimization
AWS Compute Optimizer assists in finding the right sizing for the Ethereum Sync and RPC nodes. The RPC nodes are inside an EC2 Auto Scaling group, which scales according to the demand.
Sustainability
Use instances powered by Graviton2 and Graviton3 instance types with lower specifications for sync nodes. You need only one node to stay in sync. The RPC nodes usually require more resources, so using instances powered by Graviton 3 processers are more preferrable. All RPC nodes are also inside an Autoscaling Group, which allows RPC nodes to scale according to the demand. Use Compute Optimizer to verify the initial choice.
Disclaimer
Did you find what you were looking for today?
Let us know so we can improve the quality of the content on our pages