AWS re:Invent 2025 - Innovating with AWS Confidential Computing: An Integrated Approach (CMP407)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Innovating with AWS Confidential Computing: An Integrated Approach (CMP407)

In this video, Arvind and William Yap explain AWS's confidential computing capabilities, focusing on protecting data in use. They describe how the Nitro System provides zero operator access by default through custom silicon and a lightweight Nitro Hypervisor. The session covers AWS Nitro Enclaves for additional isolation from customer operators, featuring no external network connectivity and cryptographic attestation. They introduce the newly launched EC2 Instance Attestation capability, which brings enclave-like features to GPU and AI accelerator instances through Attestable AMIs, Nitro TPM Attestation Documents, and AWS KMS integration. Use cases include confidential inferencing, federated learning, tokenization, and multi-party computation across healthcare and adtech. The presenters demonstrate how attestation documents work like passports to verify trusted instances before decrypting sensitive data, with practical implementations available in workshops.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Welcome to re:Invent: Setting the Stage for Confidential Computing

Good morning and welcome to re:Invent. Every one of you here has followed the advice I received when I told my friends I was going to Vegas. You made good choices, choices which have led you here to this session today. At an event like re:Invent, you have a variety of interesting options to choose from, but you decided to be here, and for that we are very grateful. My name is Arvind, and I will be jointly presenting this session with William Yap, Principal Product Manager at AWS.

Let me first set the stage and tell you what we're going to talk about. We're going to kick this off by discussing why we are here. We'll share what confidential computing means, what are some of the workloads that require confidential computing, and what are the requirements of these workloads. We'll then proceed to share AWS's perspective on confidential computing and what we have done to make sure confidential computing is always on for our customers.

We will then proceed to talk about additional requirements like enhanced isolation and the workloads that can take advantage of capabilities like AWS Nitro Enclaves. And with that, in the true spirit of Vegas, you will learn that what happens in an enclave stays in an enclave. We will then switch gears and talk a little bit about AI workloads and the requirements that have come with these new workloads and what we have done to respond to that.

William will then take you through and talk about our new capability, EC2 attestation. We launched it earlier this year, and we are very excited about it. This is brand new stuff we're going to be talking to you about. He'll tell you how we've brought enclave-like capabilities to EC2 instances. Then he'll dive deeper into attestation, tell you how to take advantage of attestation, how to use it, and demystify the approach for you.

We'll walk you through some use cases like confidential inferencing, federated learning, and some others. Then we'll close the session out with some resources for you to take advantage of so you can start building when you leave this room. Sound good to you? All right, let's get to it.

Understanding Confidential Computing: Protecting Data in Use

So why are we here? We are here today because you and I share a common goal. We care about building solutions that enable data protection. But let's first talk about data, because just like us, not all data is created equal. I'm just more handsome than some people, that's just it, right? There's innocuous data, and there is sensitive data. When we're talking about data protection, we are talking about data that needs to be protected, sensitive data.

Now if you look at data and you look at what we do with it, everything we do with data can be bucketed under three operations: storing data, moving data, and processing data. Everything we do can fall under one of these three, and data is constantly in that flux. It just keeps moving from data at rest to data in transit and data in use. The mechanisms to protect data while the data is at rest and in transit are fairly mature. They have existed for a long time, are very well documented, and people know how to use them. Many of you probably use them already, I hope.

So what we're going to focus on today is protecting data in use. Confidential computing is the ability to protect data while the data is in use, while the data is being processed. That's what we're going to be talking about today, and that's why we are here. We are here to learn how to build solutions that will enable you to protect data while the data is being processed in memory.

On the screen you see a smattering of some workloads that require confidential computing. It's just a few examples. There are a lot more. Decryption is an operation, right? It could be decrypting data, revealing plaintext. You may want to protect it if it's sensitive data. Signing transactions could be financial transactions or something else. Signing is a very popular workload and use case.

Tokenization could mean many different things depending on the industry or the vertical you're focused on. It could be tokenizing personally identifiable information. It could be tokenizing financial assets or digital assets. Tokenization is a workload that is begging for protection of the data that is being tokenized. Masking is another very popular use case, masking credit card information, masking your name, your Social Security number, whatever it may be. But you can see there's a common theme with all of this. It's the data types. It's either personally identifiable information or protected health care information, financial assets, digital assets, sensitive IP models. It could be a whole bunch of things, and all of these different workloads come with a common set of requirements.

Customers want to make sure that there is no unauthorized access to any of this data. They also want to make sure that only authorized code, code that's already been approved and authenticated, is the only one that has the ability to process this data while keeping their attack surface really low. Because we're processing sensitive data, we want to contain it as much as we can. Some workloads here are more CPU heavy or compute heavy, and certain other workloads are more memory heavy depending on the workload, so customers want flexibility with resources as well. All of these set of requirements need to get fulfilled while making sure we are keeping things easy to use. So these are some common set of requirements that we have had to deal with when we work with confidential computing workloads.

So when I talk to customers, it often comes down to two considerations. What are you looking to protect, and who are you looking to protect it from? The answer to what you're looking to protect has already been established, right? I think we all agreed we're looking to protect sensitive data. So when you're building specialized capabilities to protect data, it better be the case it is for sensitive data, otherwise it may not be worth the effort. So we know we're talking about protecting sensitive data. It's a straightforward answer.

When you get into the question of who you're looking to protect it from, the answer is oftentimes twofold depending on the workload and the customer. They are, at first, looking to protect their content from operators of the cloud provider, AWS operators. Depending on the workload and data types, sometimes in addition to protection from AWS operators, customers want to make sure they're protecting that data even from themselves, from customers' own operators. To summarize everything I just said, if you weren't fully following it, confidential computing is the ability to protect data while the data is in use. Customers want to protect the data from us and from themselves. That's it. That's the summary of everything I just said, protecting data in use.

AWS Nitro System: Reimagining Virtualization for Always-On Confidential Computing

So now let's get into looking at how AWS addresses these considerations. How are we making sure we are protecting the data from AWS operators? Let's start with that, and then I'll segue into how to protect it from yourselves as well. To understand how we have operationalized protecting customer content from AWS operators, we'll have to step back and understand how we reimagined virtualization. On the screen here, you see a representation of what I would like to call classic virtualization. This is still how virtualization looks like in most hyperscalers, in most implementations, and it works fairly well.

If you look at the picture, you have these small white boxes at the top. They're all customer instances. They're your VMs. Then you have these colored boxes at the bottom. Let's just say they're all virtualization functions that need to happen to enable the whole virtualization stack. Between these, you have a full blown hypervisor, the Xen hypervisor, which orchestrates all of these functions, ring fences the VMs, allocates the resources and everything. So now the host, in addition to providing the VMs, has to contend with having to take care of networking and IO functions, storage and device models, and other operational functions like management, security, monitoring, all of that.

You can quickly see that in addition to providing the VMs, there's a lot of resources being spent on operationalizing these virtualization functions, which are all orchestrated by a hypervisor. When we set out on our journey to reimagine this, we challenged the status quo. It's working well, but can we do it better? We wanted to utilize the resources on the host better than we were so we could provide more VMs to you.

In that process, we started looking at how we could abstract these virtualization functions away from the host to free up more resources and basically offer more VMs. We took each of the functions that you're seeing at the bottom, starting with networking and IO functions, and ran them on custom silicon. We hardened them and ran them on custom silicon, abstracting them away from the host into a separate box of its own. We did that first with networking and IO, and we were pretty successful with it. Then we said, okay, let's go and start removing piece by piece. We removed storage and device models, and finally we came to the operational functions like monitoring, management, and security, and removed those as well.

Each of these was hardened in its own separate PCIe card, which we call Nitro cards. We have a series of Nitro cards which, from a mental model perspective, we have in a separate box if you will, which implement all of these functions in tandem with the host. By abstracting all of the virtualization functions away, we were able to remove ourselves from the host as well. You can quickly see that if the host is just left with VMs, it doesn't need a full-blown hypervisor like the Xen hypervisor.

We wrote our own very thin, lightweight hypervisor called the Nitro Hypervisor. It has very little to do actually. It just has to ring-fence the VMs, take care of some IO functions, and allocate the right CPU and memory resources. It doesn't have to do all of the orchestration that the Xen hypervisor had to do, so it's very lightweight with very little overhead. When we developed and deployed the system, in addition to utilizing the resources of the host better, we also ended up with a system which was more performant.

It was more performant because there was very little overhead from this hypervisor. We are able to provide near bare-metal-like performance with our Nitro-based EC2 instances. But most importantly, what's pertinent to what we're talking about today, is we created this natural isolation between us and the host because we removed all of the virtualization functions away from the host. Together, the Nitro cards, the Nitro Security chip, and the Nitro Hypervisor, which make up the Nitro System, provide that isolation by default to our customers.

If you are looking to deploy a workload on AWS and your consideration is to make sure your content remains protected from operators of AWS, then all you have to do is just spin up an EC2 instance and run your workload. You're done. Because in AWS, confidential computing is always on. It's like that switch on the screen. Doesn't matter which way you flip it, it's an on-on switch. It's just going to stay on for you, and you can take advantage of always-on confidential computing.

It comes with no code changes because it's no different for you. All you have to do is spin up a Nitro-based EC2 instance and you're good to go, and it comes at no additional cost to you. Remember the considerations as you start looking into capabilities to implement confidential computing. If your consideration is just that you need to protect your data from the cloud provider, you're all set with us. It's on by default for you.

Now that's just the gist of what this is, but if you want to gather more details about how we have implemented the security design of the Nitro System, what we've done to create that degree of isolation I talked about, and how the Nitro System was built, we have a white paper we published about a couple of years ago. It's good bedtime reading. It's 27 pages long, so if you're really interested in it, I recommend taking a look at that. It gives you a lot of details about how this was implemented.

In addition to the white paper, there is a third-party report that you could refer to by NCC Group, which examined the security design of the Nitro System and has reported that there are no gaps in the Nitro System that would compromise the security claims that we made in that white paper. We have also updated our service terms about two years ago to reflect that there is no operator access to customer content if you're using a Nitro-based EC2 instance. So that's how we've addressed the requirement of making sure your data remains protected from AWS operators.

AWS Nitro Enclaves: Achieving Enhanced Isolation with Cryptographic Attestation

Now let's move on and talk about your additional considerations. What about protecting data from customers' operators, from yourselves? Only when you have such additional considerations do you start thinking about capabilities like AWS Nitro Enclaves. So let's first see why you need the additional isolation. On the screen, what you see is a 30,000-foot level of what an EC2 instance would look like. You have your instance, and within the instance, you have a bunch of different users who have different levels of access to the instance. You have your application and third-party libraries you perhaps leverage to build your application, and then the OS.

Now, if you were to process sensitive data in this instance, assuming you had your data encrypted and stored and everything, and you're moving it still encrypted in transit and bringing it to the instance, when your encrypted data hits the instance, if you want to process it, you have to decrypt it. That's just how things work at scale today. You're going to have to decrypt the data inside the instance. But once you decrypt the data inside your instance, you're revealing plaintext to all of the entities you're seeing in there. And that's really what you're looking to protect from when you're talking about additional isolation. And that's when you start thinking about capabilities like AWS Nitro Enclaves.

With AWS Nitro Enclaves, you have the ability to allocate CPU and memory resources from your own EC2 instance to spin up a hardened and isolated compute environment called Nitro Enclaves. Nitro Enclaves has no external network connectivity. There is no persistent storage. There is no administrator or root user access. There's no way to SSH into the enclave by default. The only communication channel that exists from the enclave is a secure local channel between the enclave and the parent instance. That's it. That's the only channel through which data comes in and goes out.

So now, if we go back to that scenario we talked about where you're bringing encrypted data into the instance and you don't want to unpack the data in the instance, take that encrypted data and continue to pipe it and forward it to the enclave, still keeping it encrypted. Once the data hits the enclave, then proceed to decrypt it within the enclave, at which point nobody has visibility into the data except the trusted application that's running inside the enclave, which can then proceed to process that data. And that's how we achieve additional isolation and fulfill the requirement of protecting content even from yourselves.

Now here's the cool thing, and in my personal opinion, this is the coolest feature that the enclave offers. Nitro Enclaves can provide proof of identity. By doing this, you can be sure that when you're revealing secrets to the enclave, it is the specific enclave running the expected and trusted application to which you are revealing secrets. When you decide to spin up an enclave, you're going to build an enclave image, and when you build the enclave image, you're going to get a set of measurements. Let's call it a reference hash.

And then when you proceed to deploy the enclave, after the enclave has been deployed, the enclave can fetch an attestation document signed by the Nitro hypervisor. The attestation document contains computed values about the enclave that was launched. It includes information about the enclave image, the application in the enclave, the parent instance ID, IAM roles, and a few other things. These are the computed cryptographic hashes. So when the enclave wants to go and access secrets, what it's going to do is present that attestation document to the entity it's requesting secrets from. And that entity is going to compare this attestation document against the reference hash we talked about when you built the enclave. And if the values match,

that is the proof the entity needs to make sure that the enclave has provided proof of its integrity and it can now establish trust with the enclave to share secrets with it. This is a high level of how attestation works. I'm not going to get deeper into this because William's going to come back later and talk to you about attestation in great detail. He's going to show you how to use it, but the mental model for the new capabilities we have launched and capabilities that have existed like Nitro Enclaves, the mental model is the same.

At build time you get a reference hash, at run time you get a set of hashes. Are these two matching? If they match, then you know you can share secrets. That's how we have established trust. Nitro Enclaves come with first class integration with KMS. KMS is our Key Management Service. A lot of customers who use enclaves also use KMS. I was talking to folks in the audience earlier who were inquiring about how to manage keys, how to bring your own keys, so we're happy to talk about that later after the session.

But I just want to leave you with the thought that KMS is how you're going to use keys to bring it inside the enclave so you can then decrypt the data we talked about. But to do this, KMS now is that other entity we discussed earlier with attestation. KMS is going to have to verify that the right enclave with the right application is asking it to share secrets. And with attestation it's able to do that, and what we've done for you is integrated this whole attestation flow. But you're by no means tied to KMS. If you want to use your own key store, feel free to use it. You just have to build the attestation yourself. What we've done with KMS has made it easy for you. That's it.

So here's a quick summary of everything we talked about in terms of protecting content even from yourselves. With Nitro Enclaves you achieve additional isolation and security. There's no external network connectivity, no storage, no administrator or root user access, and the only communication channel is a secure local channel. Nitro Enclaves are highly flexible. They are processor agnostic, so it doesn't matter what instance type, what CPU instance type you're trying to leverage enclaves from. It could be Intel CPUs, it could be AMD, it could be Graviton. Nitro Enclaves are functional in all of those instances.

And more importantly, bringing you back to that flexibility we talked about earlier, you can choose varying combinations of CPU and memory to allocate to your enclave depending on the demands of your workload. So it could be more memory, less CPU, whatever you need, you can choose the combination yourself. It's pretty flexible. And lastly, enclaves come with cryptographic attestation which helps it prove its identity so it can establish trust. And you get all of this isolation again at no additional cost. If you're using your EC2 instance, all you're doing is dedicating CPU and memory from the same instance to create an enclave. So that's the high level of enclaves. I'm more than happy to take questions about it later. We have more planned for you today, so I'm going to keep moving.

Customer Success Stories and Evolving Requirements for AI Workloads

Here are some customers that have used Enclave successfully, and this is just a subset of customers who are using it. The reason we chose to show you this is to give you an idea of the different verticals and segments that take advantage of capabilities like Nitro Enclaves. So you can see that our customers in the ad tech space, customers in traditional financial industry, there are customers within the web3 blockchain space, crypto exchanges, privileged access management customers. There's a wide variety of customers who can take advantage of such foundational capabilities to implement confidential computing.

As you go through this week, I want to direct you to some sessions as well. Two of the large payment processors are presenting this week on their use of confidential compute and Nitro Enclaves at AWS. So both Visa and Mastercard will be talking about real-time payments and how they have leveraged enclaves to build secure and low latency solutions to do payment processing. Coinbase will also be speaking this week, actually with me on Friday, to talk about their implementation of secure wallets with enclaves. It is actually a session focused on agentic payments. So if that's something that tickles your interest, I invite you to join us for that session, and Coinbase will talk about their use of X402 protocol to integrate with agentic payments and how they integrate a Nitro Enclaves-based wallet for the solution.

There's also additional reading on how customers like Fireblocks have implemented custody solutions with enclaves and how Stripe has done key management solutions and Brave rewards computation solutions using blockchain technology. So these are all what we've already done and accomplished with customers, and we'll continue to work with you on these. But now things are starting to shift a little bit. AI is here,

and with AI there are new workloads, and the requirements that we talked about earlier have evolved a little bit. With the new AI workloads, customers want to now make sure they're running their workloads on GPUs and AI accelerators for the large part. So whatever capabilities we talked about earlier need to be made available on all of this. Customers want to protect the models and the weights that they're bringing inside the compute entity. Not only that, they want to be able to seal these models and weights so they can be really sure it is the right instance, it's the right isolated environment that's fetching data and fetching the model.

In addition to that, no surprise with AI, you need greater bandwidth. So this consideration with no external network connectivity was starting to create some friction points. Customers also wanted storage, access to storage, because they need a lot more data now. It's not just about dropping a small payload or a few keys. And all of this again with no code changes. So we started to look into this and launched a new capability which William is now going to come and talk to you about. I invite William to talk to you about EC2 attestation and take you through the rest of the session. I'll come back and close it out with some resources for you later. Thank you.

William Yap Introduces Generative AI Privacy Challenges and Solutions

I got it. Thank you, Irene. Good morning. My name is William Yap. I'm a Principal Product Manager for Compute Services. I've been handling confidential computing for the past six years. So all the stuff that Irene talked about, Nitro Enclaves, NitroTPM, Nitro System, are capabilities that we've worked on building. And so in this talk, I'm going to try to give you some of the insights of what we were thinking about when we're building these capabilities.

Now I've mentioned AI. AI is something that's definitely caught a lot of interest in the last few years. But we're going to use AI as a template, a reference case study to talk about the new confidential computing features that we've built. And 2025 has been a busy year for the Nitro team, and we're excited to tell you all about this. Generative AI is interesting for confidential computing because of the sheer number of sensitive data that you're looking to bring there, as well as the multiple parties that are involved.

I've simplified what it means here for user data, but what I'm talking about could be prompts, it could be your business data, financial information, personal data, things you'll bring through via RAG, knowledge bases, and all. These are things that you want to protect. The second thing that's sensitive is the model itself. For closed models, the model weights represent significant investment to train those models. You would like to protect that too. And depending on the type of outputs that you're producing, it could be sensitive. So as you can see, multiple sources of sensitive data and different parties that are owning each of it, and we want to protect that.

So when you have multiple sources of data that are going into the models for inferencing, we're seeing customers, enterprises who are looking for ways to give stronger data privacy assurances to their end users if they want to hand over their data. What are the assurances that we can give them? So let's break it down. Let's break it down into three goals here. The first goal that we want to solve is we want to make sure at the base foundational infrastructure level, the infrastructure provider has no mechanism to access the data. The cloud provider has no mechanism to access the data.

The second goal they want to make is to make sure that when you go up one level, the service provider, the enterprises also do not have access to the data that's going to be used for inferencing. And lastly, you have encrypted data that's going into this environment. You need a way to prove that this environment is what it says it is, it's isolated before data gets decrypted, before data gets processed. So we're going to tackle this together. We're going to work through this as a group to try to solve this problem. And using AI as a template, we're going to look at how from AI we can look at other case studies as well.

Item number one, we solved that pretty quickly on EC2. As Irene mentioned, the Nitro System has no operator access. It's by design. It's something that we have spent a multi-year investment to build the chips, the software with the number one design principle to making sure that no AWS operator has a mechanism to access the data.

Our EC2 Nitro instance is very different from the classical traditional virtual machines where you get this type of protection, and that's going to give us a very strong foundation to build upon. So number one checks out very easily for you as a customer because on AWS we spend significant investment to make sure that's easy.

EC2 Instance Attestation: Bringing Enclave-Like Capabilities to Regular Instances

Let's focus on number two. How do we make sure there's no mechanism for you as the enterprise, as the service provider, to access the data yourself? I've already mentioned that we needed to evolve. Your requirements are evolving. You want confidential computing in GPUs, you want confidential computing with networking, with storage. When I look at building this on the Nitro Enclaves as a product manager, as we add more and more capabilities to the Nitro Enclaves, it's going to start to look more like an instance. So instead of evolving Nitro Enclaves that way, what we've done is that we've taken the capabilities that you like in Nitro Enclaves and brought it back to the regular Nitro EC2 instance.

This is what we have launched. We call it EC2 Instance Attestation. It's a capability that makes it easier for you to validate that only trusted software, trusted code is running on your EC2 instance. Before this, you could definitely build trusted EC2 instances, you could definitely build an EC2 instance that has no SSH. But what you have over here is a capability to evidence that, to prove that, and to allow decryption of data only when that's true. If you notice one thing, we didn't give it an AI name. It's called EC2 Instance Attestation because we see this as a way that customers are going to use across all different types of use cases. We see this as something very powerful that you're going to use generally.

So what is EC2 Instance Attestation? It comprises of several capabilities and I'm going to talk about them right now. At the base layer, we have the Nitro System. This is a Nitro EC2 instance. It has zero operator access. We have this device that you can attach to an EC2 instance called the Nitro TPM, the Nitro Trusted Platform Module. This is something that we already have. This follows the TPM 2.0 standards, and it does measurements, it does attestation for the EC2 instance. You can do this on an EC2 instance that has an AI accelerator. Many of our GPU instances, our Trainium 2 has this capability. This is the starting point.

Let's look at the new stuff. The first new capability that we have launched is Attestable Amazon Machine Images. This is a new way to build AMIs. When you build it, you'll get a cryptographic hash that represents the content, the boot process of that AMI. We're going to dig deeper into that shortly. The next thing that's new is the Nitro TPM Attestation Document. Now you can generate the same style of attestation document that you get from Nitro Enclaves with Nitro TPM on a regular Nitro EC2 instance. This makes the attestation process very easy to do. You no longer have to do the multi-step dance, you just have a document that's signed with all the necessary information.

The last thing that we have launched is that we know that every customer is going to need to figure out key management and attestation and how you're going to have the data encrypted and only allow decryption when the attestation passes. So we've done the heavy lift for our customers by integrating that with AWS KMS, integrating Nitro TPM with AWS KMS. With these three capabilities combined, this gives you the tools to configure your EC2 instance into an isolated compute environment, an environment you yourself cannot get access to.

Let's dig into each and every one of them in detail. First one, Attestable AMIs. It's a new way of building AMIs where at the time you complete building and creating that AMI, you get a corresponding hash. This contains a measurement of everything you have put inside the AMI. The hash that you get from this AMI is your reference measurement. This is the true hash because you know all the ingredients that you have put inside the AMI.

You know that this is the true one, and you're going to keep it securely to validate against later. Let's keep that in mind.

Building Isolated Compute Environments with Attestable AMIs

So if I go back to the problem that we're trying to solve here, you now have an inferencing environment where you want to lock yourself out. What kind of configurations can I do here? How should I set it up in a way that I don't have access? Well, we do have some best practices to share here, and this is documented as well. And I say best practices because it does vary according to the type of use cases, depending on how you're planning to use it.

But the first one, the most important one, is you want to remove all forms of interactive access. What I mean by interactive access is no SSH, no serial console, no SSM, and the like. And we're not talking just about disabling a user's access to the SSH function. What we're talking about is the SSHD daemon is not even installed. There's no mechanism at all. The first one is removing that access.

The second thing is that you want to validate and ensure that only trusted code is running inside that instance, inside your AMI. Because you're doing highly sensitive processing, you don't want to install all types of packages that may or may not be necessary. You're going to look at only the necessary packages, only the necessary tools to be able to run that workload.

The third thing is you want to have a network firewall within the instance boundary, since you have networking right now, to make sure you get protected access there. Number four, you want to make sure that all storage and file systems are immutable and read-only.

So now you have an isolated environment. You can't get in, nobody can get in. How do you make good use of it? So borrowing the stuff we did with the Nitro System, we can look at building APIs, not just any APIs, but trusted APIs that need to be authenticated, that need to be verified, that are going to be logged and authorized before they can be used. And ensure, because you are the designer of these APIs, that these APIs don't do anything that's not supposed to do, that's not documented, that doesn't interact with customer data or user data in an unapproved way.

So these are the five best practices, and you can put these ingredients into an isolated compute configuration file. That's the ingredients. Let's put it into a recipe. At the base layer, you have an Amazon Linux, just a base image, very minimal. You have your trusted code. And then you've got your configuration.

Now, we work with an open-source tool called Kiwi. This is an open-source tool that allows you to build images where you can provide the recipe to the Kiwi tool that we have integrated with and generate the trusted AMI with the corresponding hash. Now, remember, this is your reference hash. This is the hash that you trust. You provided the ingredients, you verified the ingredients. This is the hash you trust. Let's keep that in mind because we're going to use that.

With NitroTPM, when you launch an EC2 instance and you enable NitroTPM, the NitroTPM device gets attached there to your EC2 instance, and at launch, it will measure everything about that EC2 instance. And notice something, the GPU and AI chip are within the protected boundary of the EC2 instance. When you measure it, you get a calculated hash. And you can compare this calculated hash of this instance, check it against your reference hash to see, is this the instance running the configurations that I have stated that have zero operator access? If it's true, I've done it the right way.

Cryptographic Attestation Flow: Integrating NitroTPM with AWS KMS

So before this, you could absolutely create an EC2 instance that has no SSH. The difference here is that you can get the measurements and compare against them. That's how we solve goal number two. No mechanism for you to access user data, the isolated compute environment. Now we're going to talk a bit more about how we're going to solve number three. And in order to do three, let's go back from the beginning. How does cryptographic attestation work? Well, the reason why you want to know why attestation is, is how do you know your instance is truly yours?

How do you know instance I-123 or instance A here has the right code, right measurements that you have stated? I think if you spend time you can definitely figure that part out. But imagine if you have hundreds, thousands, hundreds of thousands of instances. That problem gets multiplied. We need a more scalable way to determine whether this is the right instance, your trusted instance, before you're sending highly sensitive data to it.

For the humans, we kind of solved this problem already. I know most of us who travel into Vegas by plane have to go through, everybody has the passport or identity card, Real ID to get over here in Vegas. If you think about that, an attestation document is kind of like a passport to an EC2 instance or to an enclave. Instead of a name, instead of the date of birth and location, you get measurements, and it contains measurements of the code that's present at boot, the bootup process, all the configurations. And the passport has to be issued by an authorized authority. Anyone cannot just issue it. And so the attestation document that you're getting here is going to be signed by the Nitro hypervisor, the Nitro System.

That is the first part of attestation, being able to generate the attestation document, to produce it. That's the other side, another side of attestation. How do I verify it? Once you present the passport, which database do I check against to make sure that the values that I'm looking at in the passport are correct? That's the validation piece. And you can figure out the validation piece by having your service refer to the reference hash. Remember at the beginning when we build an AMI, you get that reference hash? You can take note of that, get your service to look at it or to check against that.

But the challenge there is that remember we want to encrypt the data and send it to the isolated compute environment for processing. So it's not just sufficient to do that. You kind of need to figure it out and add key management somewhere in between as well. So borrowing what Arvind said, with what we have done with Nitro Enclaves, we know every customer is going to try to figure that part out, so we have done the heavy lifting for you as well. So we've integrated attestation with AWS KMS. When I say integration, what I mean here is that AWS KMS has the ability to ingest attestation documents. It knows how to compare the measurements against your trusted measurements.

You would place your trusted measurement as just a KMS key policy. It will compare against that. The other thing it does as well, it knows how to compare that and check the validation of the Nitro System that it's correctly signed. This is the capability that makes it easy for you to do multi-party computation with an EC2 instance. Now we've looked through all the pieces that we have launched. Let's put it all together and look at how we can make a flow there, and the flow is going to be simple because it's designed to be simple.

So if user data that you want to protect, you encrypted it and you're sending it to an EC2 instance where you have configured no SSH, no interactive access, we have built that isolation. It goes to the EC2 instance. The EC2 instance will then send the attestation document to AWS KMS that says, hey, I'm the real instance, check out my configuration, here's the measurement. AWS KMS takes that, compares that against your key policy, compares that against your reference measurement there. If it checks out, it will release the encrypted data key back to the EC2 instance where only the EC2 instance can decrypt it. So now you have user data that have been decrypted.

You can process it in that LLM, do that inferencing. And depending on whether the outputs are sensitive or not, you can encrypt it and send it back out. This is the flow that we think is very powerful for customers. By the end of this week, as I mentioned, we have workshops, we have chalk talks. Everyone can leave Vegas with an application that does this. And we're going to have the workshop online as well if we don't get to it.

Multi-Party Computation Use Cases: From Healthcare to Federated Learning

This is how we solve the three privacy goals, and we've made that process very easy for our customers by providing the combination of these tools to do it. Now, I promised at the beginning of my talk that we're going to talk more about AI, and we're just using this as a reference case study. So let's talk a bit more about how we're going to look at this and how does this vary.

In the example that I provided earlier, you have this flow here. You have the end user data you want to protect, you have the model data you want to protect, and the processing in the middle is inferencing. But let's say we take away inferencing for a second here. Instead of the model provider and user data, let's say we have two hospitals. They have patient data, and Hospital A and Hospital B are saying that if we can find a way to collaborate and share some patient data, we can get some metrics and information that's going to help with our research.

This is a privacy-preserving way of doing it where you can encrypt the data, send it to an environment that neither party can get access to, do the processing that both parties have agreed to, and only allow decryption of data when that's true. So if we have changed the processor in the middle and changed the parties, the diagram looks similar. It's a multi-party computation process.

Now, let's change the hospitals to something else, consumer goods. Let's say you have two different companies that are processing user preferences. In the adtech space, they want to tokenize user identity. So instead of looking at William's preferences for shoes, they're going to look at token ABC's preferences for shoes. The sensitive processing part of this is a tokenization process, changing the name William into a token, because if I get access to that tokenization engine, I can reverse it and see it. You want to run that in an isolated compute environment in a way that neither party can do it. So we're seeing a lot of interest in the adtech space.

Federated learning. Let's say you can't send the patient data out. Cancer centers and hospitals sometimes have a requirement that they can't do that. So with federated learning, what they're doing instead is that they're training the data locally, building the models locally, and just sending the model weights out to a central location. The central location will be an aggregator that combines all the model weights together to get a global model where all the parties can use and gain benefits too.

What I've changed here in this diagram is just the number of users and the processing. The concept that we have here is still the same: multi-party computation, building the isolated environment that no party can get access to, encrypting the data whether it's model weights or sensitive data, sending it to the environment, and decrypting it when it's proven to be true. So I hope we learned a new process today. As I mentioned, everyone here can leave Vegas with a new application that does this with a confidential computing application.

Summary and Resources: Zero Operator Access Across All AWS Confidential Computing Capabilities

I'm going to hand it over to my colleague Arvind, who will give you more resources on how you can leverage those capabilities. Thank you, William. So moving forward, let's talk about, let's summarize everything we talked about over here about confidential compute. You heard us talk about different capabilities for different considerations. We have the Nitro System upon which our EC2 instances are based on. So if you're just looking to protect from us and spin up an instance, you're good to go.

Now, if you're looking for a very opinionated, isolated compute environment that's hardened already for you, you have Nitro Enclaves. If you're looking for AI use cases and you're looking to protect your models and protect your weights on GPUs and accelerators, William talked to you at great length about EC2 attestation and how to use that on GPU and AI accelerator-enabled instances. All of this, however, comes with a common theme, and the common theme is Nitro. What makes it really special is that with any of these that we talked about, it comes with the assurance of zero operator access, no mechanism whatsoever.

If you notice, the language is a little bit different from "no operator access" to "zero," because if you're just using an EC2 instance, you're protected from us. But now when you add on the additional capabilities, you're also protected from yourself. That's really how we're trending towards that zero operator access.

As I mentioned earlier, with all of this, you get near bare metal-like performance because of the way we architected it. Between the virtualized instances and the bare metal, it's like a single digit percentage difference, which is highly performant. So it's very well suited for your AI workloads. With the new launch, we have now supported it across all of our instance types. You're not restricted to CPUs. You could use GPUs, AI accelerators, or any CPU if you choose to use enclaves. There's a lot of flexibility with the instance types we're offering.

As I mentioned with attestation, we have already ensured we are integrating all of this with KMS. For most customers who leverage these capabilities with our Key Management Service, it's already built out for you. But you're not bound to it. You can always use your own key stores or use your own external services. You just have to learn how to consume that attestation document and then build it out yourself. With the new capabilities that William talked about today, we have launched it in all commercial regions and GovCloud as well. So if you are working on mission critical applications and workloads and you're leveraging GovCloud, all of this is now available on GovCloud in addition to commercial regions.

Now if any of this piqued your curiosity and you were looking to build more, we do have a couple more sessions specifically on this topic. One is a code talk where we will deep dive into demystifying attestation. We'll actually open the attestation code and walk you through what's been implemented and how to use it. There's another workshop that you're welcome to join tomorrow on creating trusted execution environments specifically for generative AI applications. We will show you how to stand up the whole thing with a GPU or Inferentia or a training based instance.

I would like to thank all of you for taking the time to listen to us today and come join the discussion for confidential compute at re:Invent 2025. Thank you so much.

---

; This article is entirely auto-generated using Amazon Bedrock.