How to get Ethrereum Full Node on AWS

• Download Ethereum Full Node AWS Data Sheet

This section describes how to launch and connect to Ethrereum Full Node in Amazon Web Services (AWS).

Note: With the default instance type which is t2.large, syncing is slow. If you want fast syncing then please choose m5a.xlarge instance type.

1. Open Ethereum Full Node with PoS VM listing on AWS marketplace

2. Click on Continue to subscribe.

• Login with your credentials and follow the instruction.

• Subscribe to the product and click on Continue to configuration button.
• Select a Region where you want to launch the VM(such as US East (N.Virginia))

• Click on Continue to Launch Button.
• Choose Action: You can launch it through EC2 or from Website.(Let’s choose Launch from website)

• Optionally change the EC2 instance type. (This defaults to t2.large instance type, 2 vCPUs and 8 GB RAM.)
• Optionally change the network name and subnetwork names.

• Select the Security Group. Be sure that whichever Security Group you specify have ports 22 (for ssh) and 3389 (for RDP) exposed.

• Be sure to download the key-pair which is available by default, or you can create the new key-pair and download it.

• Click on Launch..

• Ethereum Full Node with PoS will begin deploying.

  3. A summary page displays.To see this instance on EC2 Console click on EC2 Console link.

4. On the EC2 Console page, instance is up and running. To connect to this instance through putty, copy the IPv4 Public IP Address

5. Open putty, paste the IP address and browse your private key you downloaded while deploying the VM, by going to **SSH- >Auth **, click on Open. Enter ubuntu as userid

6. Once connected, change the password for ubuntu user using below command

sudo passwd ubuntu

7. Now the password for ubuntu user is set, you can connect to the VM’s desktop environment from any local Windows Machine using RDP protocol or Linux Machine using Remmina.

From your local windows machine, goto “start” menu, in the search box type and select “Remote desktop connection”. In the “Remote Desktop connection” wizard, copy the public IP address and click connect

8. This will connect you to the VM’s desktop environment. Provide the username (e.g “ubuntu”) and the password set in the above “Reset password” step to authenticate. Click OK

9. Now you are connected to the out of box Ethereum Full Node with PoS environment via Windows Machine.

10. To connect using RDP via Linux machine, first note the external IP of the VM from VM details page,then from your local Linux machine, goto menu, in the search box type and select “Remmina”.

Note: If you don’t have Remmina installed on your Linux machine, firstInstall Remmina as per your linux distribution.

11. In the “Remmina Remote Desktop Client” wizard, select the RDP option from dropdown and paste the external ip and click enter.

12. This will connect you to the VM’s desktop environment. Provide “ubuntu” as the userid and the password set in above reset password step to authenticate. Click OK

13. Now you are connected to out of box Ethereum Full Node with PoS environment via Linux machine.

14. Ethereum Full Node directories:

Ethereum home directory location is /home/ubuntu/ethereum

Data directory location is /home/ubuntu/ethereum/datadir

15. Monitoring and managing node sync process :

The VM automatically starts the sync process on startup. To verify if the sync is in progress, run below commands

ps -ef|grep geth

If sync is in progress, you will see the below highlighted process running

You can also verify the sync process by monitoring the sync log as shown below

tail -f /var/log/cloud-init-output.log

You can monitor the lighthouse logs by running -

Note: If you encounter JWT authorization error or connection refused error while running the below command, please follow Lighthouse Troubleshooting Guide. to fix them.

sudo journalctl -f -u lighthousebeacon.service -o cat | ccze -A

To stop the sync process, simply run below command :

sudo killall -HUP geth

To restart the sync process, run below command .

Note: Make sure below command is executed from terminal inside Remote desktop GUI to avoid process termination

sudo nohup geth --http --http.addr "0.0.0.0" --http.port "8545" --http.corsdomain "*" --config /home/ubuntu/ethereum/eth_config.toml >> /var/log/cloud-init-output.log 2>&1 &

16. Tracking sync progress

You can track the sync progress by attaching to the running geth console and running the monitoring script as shown below . Note that if the progress is shown 99% then the node is mostly synced:

sudo geth attach --datadir /home/ubuntu/ethereum/datadir/

this will connect to the console, then run

loadScript("/home/ubuntu/ethereum/sync_status.js")

17. Accessing Metamask Ethereum wallet

The VM comes with Metamask the most popular Ethereum wallet, preinstalled in Firefox browser.
Connect to the VM via Remote desktop, open the Firefox Browser and you will see metamask plugin in the browser

18. Click on the Metamask icon, complete the configuration by following the instructions.
    Once the Metamask is configured, you wil see Metamask is running on Ethereum Mainnet Network.
19. If you want to connect Metamask on localhost, Please add port 8545 to the Security Group of your VM. Follow below steps to open port 8545:

• On your VM’s detail page, navigate to Security tab and click on Security Group as shown below:
• It will open security groups detail page. Click on Edit inbound rules
• click on Add Rule-

• Select Custom TCP from Type dropdown, enter 8545 under port range and other info as shown below. Save the changes.-

• Now select localhost 8545 from Metamask Network dropdown. You should be able to connect to localhost as shown:
• If you don’t see localhost and other testnetwork options under network dropdown, please click on show/hide link as shown below-

• It will take you to setting menu. Here you enable show test network option and save the changes.

• Close the setting page and reopen network dropdown. Now you should be able to see all the networks.

20. This offer now comes with Checkpoint Sync enabled by default. Checkpoint sync prioritises syncing to the head of the chain quickly so that the node can perform its duties. If you need genesis sync then please add –allow-insecure-genesis-sync in lighthousebeacon service file located at /etc/systemd/system/lighthousebeacon.service.

21. The existing beacon database needs to be deleted before Lighthouse will attempt checkpoint sync again. To re-sync using checkpoint sync follow the below steps:

• Connect via terminal and stop the lighthousebeacon service with below command.

sudo systemctl stop lighthousebeacon

• Remove consensus client database directory.

sudo rm -r /home/ubuntu/ethereum/datadir/beacon

• A checkpoint sync server is already configured in the ’lighthousebeacon.service’ file. If you want to change the checkpoint sync url , you can do it by editing this file.

sudo vi /etc/systemd/system/lighthousebeacon.service

• Once done, reboot the VM to apply the changes.

sudo init 6

• To verity the checkpoint sync, connect via terminal and run below command. It should show a line ‘Starting checkpoint sync remote_url: https://mainnet.checkpoint.sigp.io/, service: beacon’.

sudo journalctl -f -u lighthousebeacon.service -o cat | ccze -A

• A new beacon DB will be created after reboot. To check this run -

ls /home/ubuntu/ethereum/datadir/

22. The Checkpoint sync doesn’t come with archival node. If you want to run archival node for analysis purpose then follow below steps:

• Open the lighthousebeacon.service file in the vi editor using below commands

sudo vi /etc/systemd/system/lighthousebeacon.service

• Inside the editor click “i” to enable insert mode and add –reconstruct-historic-states flag in the file as shown in below screenshot. Save the file by pressing ESC then :wq keys.

• Once done run below daemon-reload command to reload the changes.

• Make a note of following important points while opting for historic data:
• Reconstructed states will consume several gigabytes or hundreds of gigabytes of disk space
• Reconstruction will only begin once backfill sync has completed and oldest_block_slot is equal to 0.
• While reconstruction is running the node will temporarily pause migrating new data to the freezer database. This will lead to the database increasing in size temporarily

For more information on Checkpoint Sync and Accessing historical blocks please refer to Official Checkpoint Sync documentation