AWS Blockchain Node Runners #1681
Conversation
Signed-off-by: Varsha Narmat <[email protected]>
Signed-off-by: Varsha Narmat <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Signed-off-by: Joan E <[email protected]>
Signed-off-by: Joan E <[email protected]>
Signed-off-by: Alexandra Tran <[email protected]>
|
|
||
| This single node setup is for small-scale 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. |
There was a problem hiding this comment.
| The RPC port is exposed only to internal IP range of the VPC, while P2P ports allow external access to keep the clients synced. | |
| The RPC port is exposed only to the internal IP range of the VPC, while P2P ports allow external access to keep the clients synced. |
| </tr> | ||
| <tr> | ||
| <td colspan="2" align="center">Estimate costs</td> | ||
| <td>One sync node with m7g.2xlarge for geth-Lighthouse configuration (2048 GB SSD) will cost around $430 per month in the US East region. Additional charges apply if you deploy RPC nodes with a load balancer.</td> |
There was a problem hiding this comment.
Any chance theres a link to the pricing? so we don't need to maintain it if it changes drastically
| </tr> | ||
| <tr> | ||
| <td colspan="2" align="center">How are workload resources monitored?</td> | ||
| <td>Resources are monitored using Amazon CloudWatch dashboards. Amazon CloudWatch custom metrics are pushed via CloudWatch Agent.</td> |
There was a problem hiding this comment.
| <td>Resources are monitored using Amazon CloudWatch dashboards. Amazon CloudWatch custom metrics are pushed via CloudWatch Agent.</td> | |
| <td>Resources are monitored using Amazon CloudWatch dashboards. Amazon CloudWatch custom metrics are pushed through CloudWatch Agent.</td> |
| This means that he default VPC must have at least two public subnets in different Availability | ||
| Zones, and public subnet must set `Auto-assign public IPv4 address` to `YES`. |
There was a problem hiding this comment.
| This means that he default VPC must have at least two public subnets in different Availability | |
| Zones, and public subnet must set `Auto-assign public IPv4 address` to `YES`. | |
| This means that the default VPC must have at least two public subnets in different availability | |
| zones, and public subnet must set `Auto-assign public IPv4 address` to `YES`. |
| The following example uses a sample configuration from the repository for a Besu and Teku node deployment: | ||
|
|
||
| ```bash | ||
| # Make sure you are in aws-blockchain-node-runners/lib/ethereum |
There was a problem hiding this comment.
| # Make sure you are in aws-blockchain-node-runners/lib/ethereum | |
| # Ensure you're in aws-blockchain-node-runners/lib/ethereum |
| ``` | ||
|
|
||
| ### 3. Deploy nodes | ||
|
|
There was a problem hiding this comment.
Can we perhaps add a sentence introducing the 2 options, so that users can decide up front which option to take?
| ::: | ||
|
|
||
| 1. After starting the node, wait for the initial synchronization process to finish. | ||
| It can take from half a day to approximately 6-10 days, depending on the client combination and |
There was a problem hiding this comment.
| It can take from half a day to approximately 6-10 days, depending on the client combination and | |
| It can take half a day to approximately 6-10 days, depending on the client combination and |
| - Navigate to [CloudWatch service](https://console.aws.amazon.com/cloudwatch/) (make sure you are | ||
| in the region you have specified for `AWS_REGION`). |
There was a problem hiding this comment.
| - Navigate to [CloudWatch service](https://console.aws.amazon.com/cloudwatch/) (make sure you are | |
| in the region you have specified for `AWS_REGION`). | |
| - Navigate to [CloudWatch service](https://console.aws.amazon.com/cloudwatch/) (ensure you're | |
| in the region you specified for `AWS_REGION`). |
| 1. Once the initial synchronization is done, you can 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: |
There was a problem hiding this comment.
| Turn the following query against the private IP of the single RPC node you deployed: | |
| Run the following query against the private IP of the single RPC node you deployed: |
| To clear and undeploy the RPC nodes, sync nodes, and common components, use the following commands: | ||
|
|
||
| ```bash | ||
| # Set the AWS account ID and region in case the local .env file is lost. |
There was a problem hiding this comment.
These comments should probably be steps.
@varnarmat thanks for your contrib - super detailed! I'm actually reluctant to add this level of detail to the docs directly. Maybe it's better as a guide in wiki or similar? @siladu - thoughts? |
|
Thanks for the contribution @varnarmat. No strong opinion on docs vs wiki, but I'd be fine with it as part of the docs. I think this page is better suited under the Tutorials section, alongside Deploy Besu using Kubernetes. I am curious what the intended audience/users are for this? Presumably public/mainnet Ethereum, but what sort of node operator, individuals or institutions for example? |
Thank you. I am open to where we would to put the AWS Blockchain Node Runners (Node Runners) documentation. Node Runners is experimental in nature and is intended for non-production use in proof of connects and pilots. |
Description
Issue(s) fixed
No issues
Fixes #
Preview