The October 20, 2025 AWS outage exposed a critical weakness in the cryptocurrency ecosystem: over one-third of Ethereum nodes run on centralized cloud infrastructure, creating a single point of failure for an otherwise decentralized network. When AWS’s US-EAST-1 region experienced DNS resolution failures, RPC endpoints went dark, price feeds froze, and decentralized exchanges saw trading volumes plummet. For developers, validators, and power users who depend on reliable blockchain access, the lesson is clear — running your own self-hosted node is not optional. It is a prerequisite for operational resilience. This tutorial walks you through building a production-grade, self-hosted Ethereum node setup that would have remained fully operational during the October 20 outage.
The Objective
By the end of this tutorial, you will have a fully synchronized Ethereum execution and consensus layer node running on dedicated hardware, configured with automatic failover, monitoring, and backup RPC endpoints. This setup provides reliable, trustless access to the Ethereum blockchain independent of any cloud provider. The total cost ranges from $500 for a budget setup using repurposed hardware to $2,000 for a new machine optimized for node operations.
Prerequisites
Before starting, ensure you have the following: a dedicated machine with at least 16 GB RAM (32 GB recommended), a 2 TB NVMe SSD (sync speed depends heavily on storage I/O), a reliable internet connection with at least 25 Mbps upload speed, and a basic understanding of Linux command-line operations. You will also need a machine running Ubuntu 22.04 LTS or later. While this tutorial focuses on Ethereum, the principles apply to any blockchain node including Bitcoin, Solana, and Arbitrum.
Required software: Geth (execution client), Lighthouse or Nimbus (consensus client), Prometheus and Grafana (monitoring), Nginx (reverse proxy for RPC access), and Docker for containerization.
Step-by-Step Walkthrough
Step 1: Hardware preparation and OS setup. Install Ubuntu Server 22.04 LTS on your dedicated machine. During installation, select the minimal server profile and enable OpenSSH. After installation, update all packages and configure a static IP address to ensure your node remains accessible. Set up a non-root user with sudo privileges for daily operations and disable root SSH login.
Step 2: Storage configuration. Mount your NVMe SSD with optimal filesystem settings for blockchain workloads. Use ext4 with the noatime mount option to reduce unnecessary write operations. For machines with multiple drives, consider a RAID-0 configuration for the chain data directory to maximize read throughput — Ethereum’s chain data now exceeds 1 TB and grows steadily.
Step 3: Execution client setup. Install Geth using the official PPA repository. Configure it with the following flags: –syncmode snap for fastest initial synchronization, –cache 8192 to allocate 8 GB of RAM to the database cache, and –http –http.addr 0.0.0.0 –http.port 8545 to enable RPC access. For security, bind the HTTP address to localhost and use Nginx as a reverse proxy with authentication for remote access.
Step 4: Consensus client setup. Install Lighthouse as your consensus client. Configure it to connect to your local Geth instance using –execution-endpoint http://localhost:8551. If you plan to validate, import your validator keys. For non-validating nodes, run in watch-only mode to reduce resource consumption while maintaining full chain awareness.
Step 5: Monitoring and alerting. Deploy Prometheus to collect metrics from both Geth and Lighthouse. Configure Grafana with a pre-built Ethereum node dashboard to visualize sync status, peer count, block processing speed, and resource utilization. Set up alerts for critical conditions: sync stalls, peer count dropping below 10, disk space warnings at 80% capacity, and CPU temperatures exceeding safe thresholds.
Step 6: Backup RPC configuration. Configure your applications with a fallback RPC strategy. Your primary endpoint should be your self-hosted node, with secondary endpoints pointing to alternative providers like Alchemy, Infura, or public RPC endpoints. In ethers.js or web3.py, implement automatic retry logic with provider switching on connection failure — this ensures your applications remain functional even if your local node requires maintenance.
Troubleshooting
Slow synchronization: Snap sync typically completes in 12-24 hours depending on hardware. If it takes longer, check your disk I/O performance using iostat. NVMe SSDs should deliver sequential reads above 2,000 MB/s. HDDs and SATA SSDs will struggle significantly. Also verify that your machine has sufficient RAM — Geth with 8 GB cache requires at least 16 GB total system RAM.
Peer connectivity issues: If your peer count remains low, ensure that your firewall allows incoming connections on port 30303 (TCP and UDP) for the execution client and port 9000 for the consensus client. Check your NAT configuration if you are behind a router. Use the Geth console command admin.peers.length to monitor peer count in real time.
RPC connection failures from external applications: Verify that Nginx is properly configured and running. Check authentication credentials and ensure your SSL certificates are valid if you are using HTTPS. Test connectivity with curl -X POST -H “Content-Type: application/json” –data ‘{“jsonrpc”:”2.0″,”method”:”eth_blockNumber”,”params”:[],”id”:1}’ http://your-node-ip:8545.
Mastering the Skill
Once your basic node is operational, consider these advanced enhancements. Set up a secondary node at a different physical location or on a different ISP for geographic redundancy. Implement automated failover using a load balancer like HAProxy that detects when your primary node is unresponsive and routes traffic to your backup. Explore running an Ethereum validator to earn staking rewards while contributing to network security. Finally, contribute your node’s capacity to public RPC pools to help decentralize access for users who cannot yet run their own infrastructure.
The October 20 AWS outage was a wake-up call. Running your own node transforms you from a passive consumer of centralized infrastructure into an active participant in the decentralized network. The upfront investment in hardware and time pays dividends in resilience, privacy, and sovereignty over your blockchain access.
Disclaimer: This article is for educational purposes only. Always verify instructions against official documentation before deploying to production environments.
ETH is undervalued relative to its developer activity and TVL
william davis undervalued relative to developer activity is an understatement. one third of nodes running on AWS is the real undervaluation problem
Layer 2 adoption is finally starting to reflect in L1 metrics
the 2TB NVMe requirement is the real cost. sync speed depends on storage IO and cheap SSDs will make you suffer for weeks
Fatou D. 2TB NVMe is the bare minimum now. tried syncing on a SATA SSD and gave up after 3 weeks. the IOPS difference is not optional anymore
nvme_life_ tried syncing on SATA SSD and quit after 3 weeks. the IOPS gap between SATA and NVMe for ETH state is not a recommendation, its a requirement
Fatou D. 2TB NVMe is the floor for mainnet now. tried with a 1TB SATA and the prune still couldnt keep up with state growth. IO kills you before space does
Svein E. tried 1TB SATA last year and the prune couldnt keep up either. switched to a 2TB NVMe and sync went from weeks to 3 days. the IO gap is not subtle
ETH supply is deflationary during high-activity periods — unique value prop
Ethereum’s rollup-centric roadmap is the right approach
the AWS outage proved that 33% of ETH nodes on one cloud provider is a decentralization failure in practice even if the protocol itself is fine. running your own node is the actual decentralized thing to do
$500 for the budget setup is way better than paying Alchemy or Infura monthly for rate-limited RPC calls. self-hosting pays for itself in a few months if you build on ETH regularly
rpc_indie_ the break even on self hosting is even faster now. Alchemy raised their prices again last quarter. a 500 dollar node pays for itself in 2 months
Stefan H. Alchemy raised prices AND still had downtime during the AWS outage. paying more for centralized RPC that fails when us-east-1 sneezes
rpc_dropout_ Alchemy raising prices while going down during the AWS outage is peak centralized infrastructure. paying more for less reliability
rpc_indie_ the math gets even better when you factor in rate limits. Alchemy free tier caps at 100M compute units. one busy weekend of indexing and youre paying enterprise rates
The Pectra upgrade is going to be huge for staking and UX
ran my own erigon + lighthouse setup during that october outage and it was night and day. alchemy went down and my validators kept running fine
node_op_ erigon plus lighthouse on a dappnode for 8 months now. zero downtime including the october AWS outage. the setup cost stings but alchemy bills wouldve been double by now
500 bucks for the budget setup is misleading tbh. by the time you add a decent NVMe and enough RAM for a full archive node you are closer to 1500
Soren H. 500 to 1500 is real. by the time you spec a 2TB NVMe plus 32GB RAM for a full node your budget doubles. the article undersells the storage costs
october 2025 aws outage showed how centralized ethereum nodes really are
self-hosted nodes are crucial for operational resilience
33 percent of ETH nodes on AWS and people still call ethereum decentralized. the protocol is fine but the infrastructure layer is not
the article misses reth as an option. way smaller disk footprint than erigon and faster sync. running it on 1TB NVMe no problem for 4 months