Every day, people generate up to 402 million terabytes of sensitive data. As individuals become increasingly reluctant to share data widely, the need for private computation on this data is growing. These solutions rely primarily on the infrastructure of Amazon Web Services (AWS), which accounts for approximately 30% of the global cloud computing market.
However, AWS has several shortcomings, mainly due to its centralized architecture. Even with the introduction of enhanced secure computation through AWS Nitro Enclaves, it still faces significant challenges in developer adoption and poses a deep barrier to blockchain security and Web3 applications.
This article will analyze the current status of AWS and introduce a decentralized TEE cloud solution that not only addresses the shortcomings of AWS, but also overcomes the limitations of other existing TEEs. Before that, though, we need to explore why AWS and its Nitro Enclaves product have gained such high visibility and market share, and what questions are there behind these advances.
AWS Nitro vs. TEE
AWS is currently the most popular cloud computing platform, offering a rich set of tools. In short, AWS is essentially a cloud infrastructure that meets all the computing needs of developers, including computing, storage, and database services. As we all know, AWS has a market share of about 30% of the cloud infrastructure market, which is quite impressive. Among software engineers or developers, nearly 48% use AWS in some way, so its demand is huge.
As the demand and customer base expands, including large financial institutions, government agencies, and startups with highly sensitive data, questions have been raised about the security of AWS and whether these entities can safely store and use this data for confidential computing.
It was in this context that AWS came up with the idea of implementing TEE on its platform to protect data in use, to complement encryption of data at rest and data in transit.
This new solution that integrates TEE is called AWS Nitro Enclaves, which provides a hardware-backed isolated execution environment. TEE establishes a secure environment within an Amazon EC2 instance, eliminating interactive access, persistent storage, and external network connections. This isolation minimizes the attack surface by separating sensitive workloads from the parent EC2 instance, its operators, and other software.

However, Nitro Enclaves are created and managed entirely within AWS's EC2 service, a highly centralized framework. From creation to termination, all aspects of Enclave management are controlled by AWS's infrastructure, which is inherently centralized given the nature of AWS as a centralized cloud provider.
In short, AWS Nitro Enclaves provides strong isolation through a hardware-based trusted execution environment to protect sensitive workloads. However, its centralized architecture introduces certain limitations and trade-offs.
Limitations beyond AWS centralization
In addition to the centralized drawbacks of all components and data relying on a single system, AWS Nitro Enclaves also bring more challenges and new security considerations. AWS connects multiple Nitro cards (custom hardware) to the CPU to run TEE payloads, which creates a double security risk: both the underlying CPU and the Nitro cards may have vulnerabilities.
A significant problem with Nitro Enclaves is the lack of a sound memory encryption mechanism. Unlike solutions where memory encryption is directly integrated into the CPU, the external nature of the Nitro card makes it difficult to ensure end-to-end encryption of data in memory. This configuration may expose sensitive information to tampering during memory access because encryption relies on the interaction between the CPU and external devices.
In addition, developers still need to use Docker to create and configure Amazon Machine Images (AMIs) that contain the enclave software, which can be difficult for those unfamiliar with containerization. They also need to use the AWS CLI and Nitro Enclaves CLI to launch instances and manage enclaves, navigate the Nitro Enclaves API, and integrate with AWS key management services, which sometimes requires understanding the cryptographic attestation process.
The TEE's reliance on the Nitro card results in unverifiable attestations because the measurement of code integrity comes from the Nitro card, not the CPU itself.
AWS trusts developers and administrators to set identity and access management policies, which may give them access to sensitive data. Their high-level access rights create insider threat risks because they can view or tamper with data.
A look at trust assumptions in AWS Nitro
However, the most significant limitation is that AWS is not optimized for decentralized applications and ecosystems, and it lacks native support for Web3 use cases or governance systems.
For example, AWS Nitro Enclaves lack persistent storage. While this isolation is good for security, it limits use cases such as AI agents that need to store user data in vector databases.
Key management is also not consistent with the “zero trust” scenario. While AWS Key Management Service (KMS) is available, it is designed for Web2 and allows administrators to access private keys. This conflicts with the Web3 requirement that keys must be completely controlled by code and not exposed to anyone (including administrators).
Nitro Enclaves solves the developer distrust problem of the cloud, but Web3 requires a trustless solution between users, developers, and vendors. It does not support secure code upgrades and requires decentralized ownership similar to smart contract governance, and developers must build from scratch, which can take months and the code may be vulnerable if not implemented correctly.
Setting up web services is time-consuming and laborious due to lack of network access, forcing developers to write a lot of code to adapt the application and ensure cryptographic security, which is often not perfect.
Why does Web3 need TEE?
We use TEE because we cannot fully trust developers or administrators. Web3 participants hold a different philosophy and pursue the use of trustless systems: if something has to be trusted, then it seems less reliable. This is why users rely on hardware operators to check and manage applications. Applications can be separated to prevent them from interfering with or grabbing or changing sensitive data during memory access, because encryption relies on smooth cooperation between the CPU and external devices. Users and data providers need clear guarantees and verification of the operations performed on their data.
When developing Phala Network, our original intention was to combine the advantages of AWS with the security of TEE, eliminating complexity through decentralization while enhancing security. This approach is designed to meet the needs of Web3 use cases. As a result, we proposed the concept of a decentralized TEE cloud to provide security and integration for decentralized applications.
Creating a decentralized TEE cloud
To understand the concept of a decentralized TEE cloud, we must first define what a decentralized cloud is. So, what is it?
A decentralized cloud is a computing infrastructure in which data storage, processing, and management are distributed across a network of multiple nodes, rather than being concentrated in a single central server or data center. Unlike traditional centralized cloud systems such as AWS, decentralized clouds do not require a single controlling entity, but instead rely on blockchain to operate.
Decentralized TEE Cloud
Decentralized TEE Cloud is a computing infrastructure that combines TEE with a decentralized node network to provide secure, private and verifiable computing. Each node is equipped with a TEE to protect sensitive code and data from access or tampering by node operators.
Phala Network consists of a decentralized network of worker nodes, each equipped with a TEE. These nodes perform computing tasks for users based on customer needs, such as running smart contracts or processing sensitive data.
The process begins with users deploying their applications or tasks to the network. Computational tasks are performed within the TEEs of these nodes, ensuring that code and data remain confidential and cannot be viewed or tampered with even by node operators.

Phala uses cryptographic proofs to verify that computations within the TEE are executed correctly. Node operators are rewarded for providing honest and secure services, maintaining the integrity of the network through economic incentives. While this sounds simple, implementing this solution is far more complex than it seems.
Why is it so difficult to create a decentralized TEE cloud?
TEE itself is not centralized or decentralized, its degree of centralization depends on how it is implemented and deployed in the system. TEE is a secure isolation area within the processor, designed to protect sensitive code and data from unauthorized access by the operating system or other processes on the same device. Whether a TEE operates in a centralized or decentralized mode depends on the architecture of the wider system in which it is located.
Historically, it has been easier to create centralized systems than decentralized systems because the latter have challenges in implementation and node communication. Prior to Phala Cloud, we have successfully created the fully decentralized Phala Network 1.0 (SGX). Now we are developing Phala Cloud with the same concept, although it will take time. Phala is currently the only platform that combines TEE with full decentralization, unlike centralized providers or partially decentralized protocols.
The advantages of decentralization and TEE are obvious, but they are still not enough in product development. Imagine Alibaba is the world's largest e-commerce platform, occupying a huge market share. If a new product is launched with twice the functionality and a lower price, will it occupy the entire market? Unfortunately, no, because people are used to existing products and will be biased against them even if the new product is better.
This is one of the challenges we face, but we are not pursuing two times improvement, but to ensure that Phala is ten times better and user-friendly than the competition. In addition, as mentioned before, AWS is not suitable for the Web3 environment, and we aim to fill this gap for Web3 applications and developers. In addition to the obvious advantage of decentralization, we also want to highlight other differences between Phala and AWS.
Phala Cloud vs. AWS
First, AWS has a complex setup process for Nitro Enclaves. This involves multiple steps, including installing the Nitro CLI, converting Docker images to Enclave files, and handling file transfers, which are all very time-consuming.
In contrast, Phala allows developers to deploy “migrate and modify” and easily migrate existing Docker containers to secure TEEs. Using the Dstack SDK, developers can convert Docker containers to Confidential VMs with minimal changes and deploy them through the user-friendly Cloud UI, while still supporting templates and custom Docker Compose files.
In terms of security, AWS relies on trusting developers and administrators to properly configure access controls and manage resources. Although AWS uses TEEs for isolated computing, its centralized infrastructure requires trust in AWS and the people who manage the system, which can lead to sensitive data being accessed. Phala adopts a zero-trust model and does not trust any party by default. Sensitive data remains secure within the TEE and is not accessible even to node operators, making it suitable for Web3 applications that require trustless operations.
From a product perspective, AWS primarily serves enterprise customers because of the large number of enterprises in the traditional IT field. Therefore, it does not fully meet the value proposition of Web3 startups in terms of products and technology. In contrast, Phala is built for decentralized applications. It natively supports AI agents that interact with blockchain smart contracts as well as privacy-preserving DApps.
In addition, Phala is deeply integrated into the blockchain ecosystem through partnerships with various protocols and integrations for DApps that want to leverage the security of TEEs.
Phala is positioned as the execution layer for Web3 AI, enabling developers to build, launch, and profit from AI agents that can securely and privately understand and interact with blockchain smart contracts. We support decentralized AI platforms such as NEAR AI and Sentient by leveraging NVIDIA GPU TEEs to run large language models (LLMs) in a secure, verifiable, and privacy-focused environment. For example, our partnership with NOTAI highlights zero-trust execution of AI agents, where we provide trustlessness and privacy protection through TEEs and RA Explorer.
We also support integration with non-AI related applications through Phat Contracts, which are low-cost, low-latency smart contracts with native HTTP request support.
However, given that many crypto-native teams are also building TEEs and other secure computation methods, how does Phala differentiate from these solutions?
Phala Cloud vs. TEE Solutions
Phala Network stands out as the only fully decentralized TEE cloud, providing secure, private, and verifiable computation for DApps. Unlike Oasis Protocol and Secret Network, which focus on implementing privacy-enabled smart contracts using TEEs in their respective blockchains, Phala provides a cross-network decentralized cloud computing platform for off-chain computation. Phala is flexible and customizable, leveraging a wide range of TEE hardware, including Intel SGX, Intel TDX, AMD SEV, and NVIDIA GPU TEEs. Marlin Protocol enhances Web3's network performance but does not provide compute or privacy features, while Oasis and Secret operate in specific blockchain ecosystems. Phala has a unique advantage as the only decentralized TEE cloud with broad hardware support and developer-centric tools such as Dstack. Phala is different in that it provides a general-purpose decentralized TEE cloud, unlike Oasis Protocol, Marlin, and Secret Network, which focus on specific use cases. Phala allows developers to deploy any application, such as AI models, web servers, or databases, in a secure environment. This is achieved through Phata Contracts and Phala Cloud, which supports Dockerized deployments and provides one-click access to CPU and GPU TEEs.
In addition, there are many comparisons about whether TEE or multi-party computation (MPC) is better for specific use cases. In our view, TEE and MPC are not competitors, but complementary partners.
Phala integrates TEE with MPC to create a decentralized root of trust (DeRoT) model, which is an advanced approach for protecting TEE-based applications. MPC runs inside the TEE to reduce node collusion risks, while TEE block proofs are submitted together with MPC proofs to mitigate errors in zero-knowledge proof (ZKP) implementations. Requiring MPC nodes to run inside the TEE further enhances this multi-proof system. The DeRoT model uses TEE, MPC, and ZKP to distribute trust in the network. This approach improves the security of DApps using TEE by addressing potential hardware or node-level threats.
Possibilities of a decentralized TEE cloud
We will dedicate an entire article to this topic, as there are already many applications running on Phala. Therefore, this section may be as long as the entire article. But we hope to outline possible use cases for a decentralized TEE cloud.
First, Phala supports the deployment of AI models within TEEs, ensuring secure and autonomous operations that interact with blockchain networks. This includes AI agents for smart contract enhancement and cross-agent interactions. Developers can leverage GPU TEEs for AI computing, achieving true censorship resistance and privacy protection.
Developers can also migrate traditional applications to a secure and trustless environment for improved security. The platform enables privacy-preserving data analysis through Web3 and traditional analytical tools that analyze data without exposing individual user information. In addition, it can enhance DeFi's secure computing through privacy features, such as confidential trading positions or dark pool transactions. Finally, the decentralized TEE cloud can achieve MEV protection by moving block construction into TEE for fair sorting and execution.
There are many products that use Phala as part of their infrastructure. We will dive deeper into how these products use Phala and what they gain from this integration in another article.
Conclusion
There are fundamental differences in the trust models of Web3 and Web2, which leads to limitations in platforms such as AWS. In Web3, data (including tokens that are essentially data) is truly owned by users, and application developers are untrusted by default. This distrust stems from the potential that developers may attempt to access, modify, or steal user data without authorization.
This paradigm explains several key practices in Web3:
1. Smart contract code must be rigorously reviewed to eliminate backdoors or vulnerabilities.
Ownership (or administrative control) of smart contracts is a key issue, and users value transparency more than allowing developers to have unrestricted control.
2. Ideally, in a Web3 environment, developers should write and deploy smart contract code, then give up all control and no longer retain any privileges over the application.
Unlike smart contracts, TEEs can enforce similar ownership and control principles across a wider range of programs. However, AWS Nitro Enclaves runs within the Web2 framework, where developers retain the ability to log in, access, and modify data and applications. Phala's TEE is designed according to Web3 principles and natively supports smart contracts to manage TEE-based applications, consistent with the decentralized trust model.