Blockchain on Cloud: What's Actually Useful in 2024

Blockchain on cloud infrastructure has had a strange five years. Between 2018 and 2021 every hyperscaler launched a managed blockchain service, most of them are now quietly deprecated, and the hype cycle cooled considerably. What remains is a smaller, more technical set of use cases where distributed ledgers actually earn their place in an architecture. This is worth knowing because clients still ask, and the honest answer matters.

Here is what is actually useful in cloud blockchain in 2023, and what you should skip.

1. The Managed Blockchain Services Are Mostly Dead

Amazon Managed Blockchain shut down Hyperledger Fabric support in early 2023. Azure Blockchain Service was decommissioned in 2021. Google never really had a serious offering. The hyperscalers ran the experiment, found that the customers who wanted blockchain mostly wanted it for non-engineering reasons, and moved on.

What is left on the managed side is AWS Managed Blockchain for Ethereum-compatible networks, which is really a managed node service — you do not get a Fabric network, you get an easy way to run an Ethereum, Polygon, or Hyperledger Besu node without operating the infrastructure yourself. That is a narrower but more honest product.

If you were planning a Hyperledger Fabric deployment on a managed cloud service, the honest recommendation in 2023 is to self-host it on Kubernetes, use a specialty provider like Kaleido, or choose a different architecture.

2. Self-Hosted Ethereum Nodes: Actually Useful

The one place blockchain infrastructure is genuinely valuable in the cloud is running your own Ethereum or EVM-compatible node for read access. If you are building anything that queries on-chain state — price feeds, wallet dashboards, NFT metadata, DeFi analytics — relying on public RPC endpoints like Infura or Alchemy means paying per request and accepting rate limits.

Running your own full node on a cloud VM costs about $150 to $400 a month depending on the chain. You get unlimited queries, lower latency, and no third-party dependency. For any application making more than a few million RPC calls per month, self-hosting pays back quickly.

The storage requirements are real — Ethereum archive nodes are over 12 TB and growing. Full nodes (recent history) are around 1 TB. Plan for NVMe storage because HDD-backed nodes cannot keep up with block propagation.

The infrastructure reality

An Ethereum full node needs 16+ GB of RAM, 4+ CPU cores, and 1 TB of fast NVMe. Add another 500 GB of headroom per year for state growth. Running redundant nodes for HA doubles everything. This is not cheap infrastructure, but it is predictable and the performance is what your application actually needs.

3. Permissioned Chains for Multi-Party Trust

The legitimate enterprise blockchain use case — and it does exist — is multi-party workflows where no single party should control the database. Supply chain provenance where the manufacturer, distributor, and retailer all write to the same ledger. Insurance claims where carriers and reinsurers share a single record. Trade finance where banks need a common view of letters of credit.

In these cases, Hyperledger Fabric or a similar permissioned chain is the right primitive. The alternative — "one party hosts a database, the others trust them" — is what the parties are trying to avoid. The blockchain is the organizational structure, not the database.

Self-host on Kubernetes across the participating parties' clouds. Use AnthosConfig or Argo CD for consistent deployments. The operational complexity is real, which is why most of these efforts fail — but when they work, they work because the underlying trust problem was real.

4. Tokenization Of Real-World Assets

Tokenization — representing real-world assets (securities, real estate, commodities) as on-chain tokens — is genuinely picking up in 2023. The cloud infrastructure side of this is unremarkable: standard web application architecture with blockchain nodes as one of the backend services. The interesting parts are regulatory and custody, not infrastructure.

If you are building in this space, the cloud stack we would recommend is boring: managed Postgres for off-chain data, a self-hosted chain node or a reliable RPC provider, a custody HSM (CloudHSM or dedicated hardware), and standard web application middleware. The blockchain is one database among many, not the center of the architecture.

5. ZK Proofs: The Genuinely New Compute Workload

Zero-knowledge proofs are where the interesting infrastructure engineering is happening in 2023. ZK proof generation is compute-intensive — generating a SNARK for a complex circuit can take minutes on a consumer CPU and seconds on a high-end GPU. This creates demand for dedicated ZK-prover infrastructure as a cloud service.

RiscZero, Succinct, and a handful of others run prover networks. For teams building rollups, privacy-preserving applications, or verifiable computation, these are legitimate cloud workloads that need real GPU capacity. Expect this category to keep growing.

If you are building your own ZK prover, the cloud is the right place to run it — the workload is bursty, GPU-heavy, and fits the spot instance model nicely. Budget for 10-30x the compute of a comparable non-ZK workload.

6. Oracle Infrastructure

Oracles — services that bring off-chain data onto the chain — are boring cloud infrastructure with a blockchain interface. Chainlink nodes, Pyth price feeds, and custom oracle pipelines all live on standard cloud infrastructure: a pool of workers fetching data from external APIs, signing the results, and submitting transactions to the chain.

The engineering challenges are availability (if your oracle goes down, applications depending on it break), accuracy (fetch from multiple sources and reconcile), and gas cost management (batching updates, picking the right time to submit). None of these are blockchain-specific. They are standard distributed systems problems.

For clients building oracles, we recommend the same stack as any production cloud workload: Kubernetes, managed Postgres for audit, Prometheus for monitoring, and a secrets manager for the signing keys. The only blockchain-specific piece is the transaction submission logic.

7. What Is Not Worth Doing

A few patterns where we consistently recommend against blockchain:

• Supply chain tracking where one party is obviously authoritative. If the manufacturer is clearly the source of truth, a signed database is simpler and better than a distributed ledger.
• Customer loyalty points. Standard database. Nobody needs Byzantine fault tolerance for coffee stamps.
• Document hashing for timestamping. A signed certificate authority record is cheaper and has 30 years of legal precedent.
• Anything pitched as "blockchain-enabled" without a specific answer to why a database wouldn't work. If the pitch cannot explain what multi-party trust problem is being solved, there isn't one.

The Honest Summary

Blockchain in the cloud in 2023 is a narrower, more technical field than it was five years ago. The viable use cases are running your own chain nodes, hosting permissioned multi-party workflows where the trust problem is real, tokenization platforms with standard web infrastructure plus a chain backend, and ZK proof generation on GPU clusters. Everything else has either moved off-cloud, been replaced by simpler alternatives, or quietly died.

The infrastructure patterns are also more conventional. Kubernetes, managed storage, HSMs, standard observability. There is very little blockchain-specific cloud engineering that looks different from other distributed systems engineering. The differentiator is the protocol layer, not the infrastructure layer.

This is progress. The category has matured past the hype into a set of tools that solve specific problems. Use them when they fit. Don't reach for them when a Postgres database would do the job.