iTranslated by AI
re:Invent 2025: Protecting Data in Use with Nitro Enclaves and EC2 Instance Attestation
Introduction
This project aims to make valuable hidden information more accessible by transcribing various overseas talks into Japanese articles. The presentation we're covering in this installment is:
For re:Invent 2025 transcription articles, please refer to this Spreadsheet for compiled information.
📖re:Invent 2025: AWS re:Invent 2025 - Innovating with AWS Confidential Computing: An Integrated Approach (CMP407)
In this video, AWS Principal Product Managers Arvind and William Yap explain Confidential Computing. They start by discussing the importance of protecting data in use, achieving zero operator access with the Nitro System, and providing enhanced isolation environments with Nitro Enclaves. Of particular note is the newly launched EC2 Instance Attestation feature in 2025, which enables the protection of models and and data on GPUs and AI accelerators. By leveraging Attestable AMIs and Nitro TPM Attestation Document and integrating with AWS KMS, it supports use cases such as multi-party computation, federated learning, and tokenization. It is available in all commercial regions and GovCloud, offering near bare-metal performance.
- Please note that this article is automatically generated, aiming to preserve the content of the original presentation as much as possible. There may be typos or incorrect information.
Main Content
re:Invent Session Start and Overview of Confidential Computing
Good morning, and welcome to re:Invent. All of you here have followed the advice I got when I told my friends I was coming to Las Vegas. You made a good choice, and that choice has led you to this session today. At an event like re:Invent, you have a plethora of interesting options to choose from, and you decided to be here. And for that, we are immensely grateful. My name is Arvind. I will be presenting this session jointly with William Yap, a Principal Product Manager at AWS.
First, let me set the stage for what we're going to talk about. We're going to start by discussing why we are here. What do we mean by confidential computing, what are some of the workloads that require confidential computing, and what are the requirements of those workloads? Then we'll give you AWS's perspective on confidential computing and what we've done to make sure confidential computing is always on for our customers.
Next, we'll talk about additional requirements, such as enhanced isolation, and workloads that can leverage features like AWS Nitro Enclaves. And then, in true Las Vegas spirit, you'll learn that what happens in an enclave stays in an enclave. Then we'll pivot, and we'll talk a little bit about AI workloads, the requirements that have come about with these new workloads, and how we've addressed them.
After that, William is going to come up and talk about our new feature, EC2 attestation. It's something we launched earlier this year, and we are super excited about it. It's something brand new for us to talk to you about. He'll walk you through how we've brought features like enclaves to your EC2 instances. And then he'll take a deeper dive into attestation, how you can leverage attestation, how you can use it, and demystify that approach for you.
We'll walk you through confidential inference, federated learning, and a couple of other use cases. And then, to close out the session, I'll come back and give you some resources you can leverage so you can start building as soon as you leave this room. How does that sound? Let's get started.
The Need for Data Protection and Protecting Data in Use
So, why are we here? We are here today because you and I have a common goal. We are interested in building solutions that enable data protection. But first, let's talk about data, because just like us, not all data is created equal. Some data is innocuous, and some data is sensitive, just like I'm more handsome than some, right? That's all there is to it. When we talk about data protection, we're talking about data that needs to be protected, which is sensitive data.
Now, when we look at data and how we operate on it, all the things we do to data can be bucketed into three operations: data at rest, data in transit, and data in use. Everything we do falls into one of these three. And data is always in that flow. It's constantly moving from data at rest to data in transit to data in use. The mechanisms for protecting data at rest and data in transit are quite mature. They've been around for a long time, they're very well documented, and people know how to use them. Many of you are probably already using them, and I hope you are.
So, today, what we're going to focus on is protecting data in use. Confidential computing is the ability to protect data while it is being used, while it is being processed. That is what we are going to talk about today, and that is why we are here. We are here to learn how to build solutions that can protect data while it is being processed in memory.
Workloads Requiring Confidential Computing and What to Protect
On the screen are just a few examples of workloads that require confidential computing. There are many more. Decryption is an operation, right? It could be decrypting data to reveal plaintext. If it's sensitive data, you'll want to protect it. Signing transactions could be for financial transactions or something else. Signing is a very popular workload and use case.
Tokenization can mean many different things depending on the industry or area you're focusing on. It could be tokenizing personally identifiable information. It could be tokenizing financial or digital assets. Tokenization is a workload that desperately needs the protection of the data being tokenized. Masking is also a very popular use case: masking credit card information, your name, social security numbers, whatever it might be. But you'll notice a common theme among all these: the data type. It's either personally identifiable information, protected health information, financial or digital assets, or highly sensitive IP models. There's a variety of things it could be. And with all these different workloads comes a common set of requirements.
Customers want to make sure there's absolutely no unauthorized access to this data. They also want only code that has been approved and attested to—approved code—to have the ability to process this data, keeping the attack surface very low. Because they're processing sensitive data, they want it to be as contained as possible. Customers also want resource flexibility, as some workloads here are more CPU-intensive, meaning more compute-intensive, while other workloads might be more memory-intensive. All these requirements need to be met while maintaining ease of use. These are the common requirements we've addressed when working on confidential computing workloads.
When we talk to customers, it often boils down to two considerations: what are you trying to protect, and from whom are you trying to protect it? The answer to the question of what you're trying to protect is already well-established, right? I think we can all agree that we're trying to protect sensitive data. So if you're building specialized capabilities to protect data, it's probably not worth the effort unless it's for sensitive data. So we're talking about protecting sensitive data. That's a clear answer.
When it comes to the question of from whom you're trying to protect it, the answer often splits into two, depending on the workload and the customer. First and foremost, they're trying to protect their content from the cloud provider, from AWS operators. And depending on the workload or data type, in addition to protecting it from AWS operators, customers sometimes want to protect that data from themselves, from their own operators. So bringing all that I've spoken about together, for those of you who haven't fully grasped it, confidential computing is the ability to protect data while it's in use. Customers want to protect data from us and from themselves. That's it. That's the summary of everything I've just spoken about: protecting data in use.
Reimagining Virtualization with the Nitro System and Protection from AWS Operators
So let's look at how AWS addresses these considerations. How do we protect data from AWS operators? Let's start there, and then we'll also talk about how we protect it from yourselves, from your own operators. To understand how we've operationalized protecting your content from AWS operators, we need to take a step back and understand how we've reimagined virtualization. On the screen, you see a representation of what I would like to call classic virtualization. This is how virtualization still looks in most hyperscalers and most implementations, and it works pretty well.
When you look at the diagram, you see those little white boxes at the top. Those are all your instances. So those are VMs. And then at the bottom, you have those colored boxes. Let's just call them all virtualization functions that are needed to enable the entire virtualization stack. In between these, you have a full hypervisor, a Xen hypervisor, which orchestrates all these functions, isolates the VMs, allocates resources, and does all that. So the host has to take care of networking and IO functions, storage and device models, and other operational functions like management, security, and monitoring, in addition to serving up VMs.
You can immediately see that a lot of resources are spent on the host to serve up these virtualization functions, in addition to serving up VMs. And they're all orchestrated by the hypervisor. When we went on this journey of reimagining this, we challenged the status quo. It works well, but can we do better? We wanted to better utilize the resources on the host to provide more VMs to you.
In that process, we started looking at how can we abstract these virtualization functions from the host to free up more resources and essentially serve up more VMs. And each of the functions that you see at the bottom, starting with networking and IO functions, we ran them on custom silicon. We hardened them, and by running them on custom silicon, we abstracted them from the host and moved them into independent boxes. We did this for networking and IO first, and that was pretty successful. And we said, okay, let's take them out one by one. We took out storage and device models, and eventually, we got to operational functions like monitoring, management, and security, and we took those out as well.
Each of these was hardened in independent PCIe cards called Nitro cards. We have a series of Nitro cards, and in terms of a mental model, just think of them as sitting in independent boxes. And they interface with the host to implement all these functions. By abstracting all the virtualization functions, we were also able to remove ourselves from the host. And you can immediately see that if the host has only the VMs left, we don't need a full-blown hypervisor like a Xen hypervisor.
We wrote our own hypervisor, which is very thin and lightweight, called the Nitro Hypervisor. It does very little, actually. It just isolates the VMs, handles some IO functions, and allocates the right CPU and memory resources. It doesn't have to do all the orchestration that the Xen hypervisor had to do, so it's very lightweight and has very little overhead. When we built and deployed this system, in addition to better utilizing the resources on the host, we also got a higher-performing system.
It was high-performing because there's very little overhead from this hypervisor. We can provide near bare-metal performance on Nitro-based EC2 instances. But most importantly, and this is relevant to what we're talking about today, by taking all the virtualization functions out of the host, we created this natural separation between us and your host. The Nitro cards, the Nitro Security chip, and the Nitro Hypervisor all come together to form the Nitro System, and they provide that separation to you by default.
If you have a requirement that you're trying to deploy a workload on AWS and you want to ensure that your content is protected from AWS operators, all you have to do is launch an EC2 instance and run your workload. That's it. Because at AWS, confidential computing is always on. It's like the switch you see on the screen. No matter which way you turn it, it's an on-on switch. It stays on, and you can leverage always-on confidential computing.
No code changes are required because nothing changes for you. All you have to do is launch a Nitro-based EC2 instance, and there's no additional cost. Remember the considerations when you start looking at capabilities to implement confidential computing. If your consideration is just that you need to protect your data from the cloud provider, we've got you all set. It's on by default.
Now, this is just an overview, but if you want to gather more detailed information on how we implemented the security design of the Nitro System, how we created that degree of separation that I spoke about, and how the Nitro System is built, there's a whitepaper that we published about two years ago. It's a great bedtime read. It's 27 pages, so if you're really interested, I recommend you go check it out. It has a lot of details on how this was implemented.
In addition to the whitepaper, you can also look at a third-party report by NCC Group. The report validates the security design of the Nitro System and reports that the Nitro System does not have any gaps that compromise the security requirements we claimed in the whitepaper. We also updated our terms of service about two years ago, explicitly stating that if you're using a Nitro-based EC2 instance, our operators will not access your content. This is how we've addressed the requirement of ensuring that your data is protected from AWS operators.
Enhanced Isolation and Attestation Capabilities with AWS Nitro Enclaves
So let's move on to the next one and talk about additional considerations. What about protecting data from your operators, from yourselves? Only when you have these additional considerations do you start thinking about capabilities like AWS Nitro Enclaves. So let's first look at why you might need additional separation. What you see on the screen is a 30,000-foot level view of what an EC2 instance looks like. You have your instance, and within your instance, you have various users with different levels of access to the instance. You have your application, and the third-party libraries that you leverage to build your application, and then you have your OS.
Now, if you're dealing with sensitive data on this instance, you've encrypted it at rest, you have everything in place, you're moving it in transit encrypted all the way into the instance, but when the encrypted data gets to the instance, if you want to process it, you have to decrypt it. That's how it works in today's large environments. You have to decrypt the data within the instance. But when you decrypt the data within the instance, it exposes the plaintext to all the entities that are present there. And that's exactly what we want to protect against when we talk about additional separation. And that's where you start thinking about capabilities like AWS Nitro Enclaves.
With AWS Nitro Enclaves, you can carve out CPU and memory resources from your EC2 instance to spin up an enhanced, isolated computing environment called Nitro Enclaves. Nitro Enclaves have no external network connectivity. They have no persistent storage. They have no admin or root user access. There's no way to SSH into an enclave by default. The only communication channel that exists from an enclave is a secure local channel between the enclave and the parent instance. That's it. That's the only channel through which data can go in and out.
So going back to the scenario that I just spoke about. If you have encrypted data coming into your instance and you don't want to unpackage it in your instance, you take that encrypted data, you pipe it and continue to transfer it encrypted into the enclave. And once the data gets to the enclave, you proceed to decrypt it within the enclave. At this point, nobody can see the data except for the trusted application running within the enclave. And that application can then proceed to process the data. This is how you achieve that additional separation and meet the requirement of protecting content from yourself.
Now, here's the cool part. And this, in my personal opinion, is the coolest feature that enclaves provide. Nitro Enclaves can provide attestation. This allows you to verify that when you're disclosing secrets to an enclave, it is indeed the specific enclave running the expected trusted application. When you decide to spin up an enclave, you build an enclave image. And when you build an enclave image, you get a set of measurements. Let's call them reference hashes.
And when you proceed to deploy the enclave, once the enclave is deployed, the enclave can obtain an attestation document, which is signed by the Nitro hypervisor. The attestation document contains calculated values about the enclave that was launched. It contains the enclave image, the application within the enclave, the parent instance ID, IAM roles, and a few other pieces of information. These are calculated cryptographic hashes. And when the enclave wants to access secrets, it presents this attestation document to the entity that is requesting the secret. And that entity compares this attestation document to the reference hashes that we spoke about when you built the enclave. And if the values match,
That's the proof, that's what the entity needs to verify that the enclave has provided proof of its integrity, and that allows you to establish a trust relationship with the enclave and now share secrets. So that's the high-level explanation of how attestation works.
I'm not going to dive any deeper into this because William is going to come back later and talk a lot more about attestation. He's going to show you how it works in practice, but the mental model for the new capabilities that we've launched and for existing capabilities like Nitro Enclaves are the same.
At build time, you get a reference hash, at runtime, you get a set of hashes. Do these two match? If they do, then you know you can share secrets. That's how you establish trust. Nitro Enclaves have first-class integration with KMS. KMS is our Key Management Service. Many customers using enclaves also use KMS. I was talking to folks in the room earlier, asking how they manage their keys, how they bring their own keys. Happy to talk to you after the session.
But just want to say that KMS is what we use to bring keys into the enclave, which then allows us to decrypt the data that we spoke about earlier. But in order to do that, KMS needs to be the other entity that I described in attestation. KMS needs to verify that it is the right enclave and the right application that is asking for the secret to be shared. And attestation allows us to do that, and what we've done for you is we've integrated this entire attestation flow.
But you're by no means tied to KMS. If you want to use your own key stores, you're free to do that. However, you will have to build the attestation yourself. What we've done with KMS is made it easy. That's it.
So let's do a quick recap of everything that we spoke about in terms of protecting content from yourself. Nitro Enclaves allow you to achieve additional separation and security. There's no external network connectivity, there's no storage, there's no admin or root user access. The only communication channel is a secure local channel. Nitro Enclaves are very flexible. They're processor agnostic, so no matter which instance type, which CPU instance type you try to leverage an enclave from, it doesn't matter. It could be Intel CPU, it could be AMD, it could be Graviton. Nitro Enclaves work on all these instances.
And most importantly, going back to flexibility, as I said earlier, depending on the demands of your workload, you can choose various combinations of CPU and memory that you want to allocate to the enclave. You could have more memory, less CPU, and so forth, so you pick your own combination that you need. So it's very flexible. And finally, enclaves come with cryptographic attestation, which allows you to prove your identity and establish trust. And all of this separation comes at no additional cost. If you're using an EC2 instance, all you're doing is carving out dedicated CPU and memory from the same instance to create an enclave. So that's the high-level explanation of enclaves. Happy to take any questions later on.
We have more in store for you today, so I'm going to keep us moving.
Use Cases for Nitro Enclaves and Addressing AI Workloads
These are some of our customers who are successfully using enclaves. This is just a small subset of the customers who are using them in practice. I show this to give you a flavor of the various industry verticals and segments that are leveraging capabilities like Nitro Enclaves to implement confidential computing. You have customers in the AdTech space, customers in the traditional financial industry, customers in the web3 blockchain space, crypto exchanges, privileged access management customers, all sorts of different customers leveraging these foundational capabilities to implement confidential computing.
Let me also tell you about some of our sessions this week. Two large payment processors are going to be speaking this week about how they're using confidential compute and Nitro Enclaves at AWS. Both Visa and Mastercard are going to be talking about real-time payments and how they built a secure, low-latency payment processing solution leveraging enclaves. Coinbase is also going to be speaking this week, actually on Friday with me, about their secure wallet implementation using enclaves. It's actually a session focused on agent payments. If that's of interest to you, I would encourage you to attend. Coinbase is going to be talking about how they integrated X402 protocol with agent payments and how they integrated Nitro Enclaves based wallets into their solution.
And there's additional material on how Fireblocks implemented their custody solution using enclaves, how Stripe enabled their key management solution, how Brave enabled their reward calculation solution using blockchain technology. All of these are things that we've already done and achieved with our customers, and we'll continue to work with you. But now, things are starting to change a little bit. AI is here,
And with AI comes new workloads, and the requirements that I spoke about earlier have also evolved a little bit. With the new AI workloads, customers now want to run workloads on GPUs and AI accelerators. So all of the capabilities that I spoke about earlier, we need them to be available on all of these. Customers want to protect the models and the weights that they bring into the compute environment. Not only that, they want to seal these models and weights, making sure that it is indeed the right instance, the right isolated environment that's getting the data and the models.
And additionally, with AI, as you would imagine, there's a need for higher bandwidth. So the consideration of no external network connectivity was starting to create a few friction points. Customers also wanted access to storage because now you need a lot more data. It's not just passing tiny payloads or a few keys. And all of this again needs to happen with no code changes. So we took a look at this, and we launched new capabilities. And William is going to talk to you about them right now. I'm going to hand it over to William for EC2 attestation and the rest of the session. I'll come back later to give you some resources and close out the session. Thank you.
Introduction to New Features by William Yap and Data Protection in Generative AI
All right. Thank you, Irene. Good morning, everyone. My name is William Yap. I'm a Principal Product Manager in Compute Services. I've been on confidential computing for the last six years. So everything that Irene talked about, Nitro Enclaves, NitroTPM, Nitro System, these are capabilities that we've been working on building. And I hope to give you some insights on this talk here on what our thinking was when we built these capabilities.
All right. So I touched on AI. AI is definitely something that has gained a lot of interest in the last few years. But we'll use AI as a template, as a reference case study, to talk about the new confidential computing capabilities that we've built. And 2025 is a very busy year for the Nitro team, and we're excited to talk to you about this. What makes Generative AI interesting for confidential computing is the sheer amount of sensitive data that you're trying to bring into it and the multiple parties involved.
So I simplified what user data means here, but what I'm talking about could be your prompts, could be business data, financial information, personal data, whatever you bring in through RAG, knowledge bases. These are things that you want to protect. The second piece of sensitive information is the model itself. For closed models, the model weights represent a significant investment in training those models. You want to protect that as well. And depending on the type of output you generate, that could be confidential. So you can see, there are multiple sources of sensitive data, with different parties owning each, that we want to protect.
So when you have multiple data sources coming into the model for inference, we are seeing customers, enterprises, looking for ways to provide stronger data privacy guarantees when their end users want to hand over data. What kind of guarantees can we provide? So let's break it down. Let's break it down into three goals here. The first goal we want to solve is at the underlying infrastructure level, ensuring that the infrastructure provider does not have a mechanism to access the data. The cloud provider does not have a mechanism to access the data.
The second goal they want to achieve, when you go one level up, is that the service provider, the enterprise, also does not have access to the data that is used for inference. And finally, you have encrypted data coming into this environment. You need a way to prove that this environment is what it says it is, and it's isolated, before the data is decrypted, before the data is processed. So we're going to work on this together. We're going to work as a group to solve this. And we'll use AI as a template, and we'll look at other case studies from AI as well.
For the first item, we solved this very quickly on EC2. As Irene mentioned, the Nitro System has no operator access. This is by design. We've made a multi-year investment, building chips, building software. The number one design principle for that is that AWS operators do not have a mechanism to access your data.
Our EC2 Nitro instances are very different from traditional classical virtual machines that provide this kind of protection. This gives us a very strong foundation to build on. So for customers, the first one is a very easy check. Because on AWS, we have made significant investments to make it easy for you.
Introducing EC2 Instance Attestation and Attestable AMIs
So let's focus on the second one. As an enterprise, as a service provider, how do you ensure that you yourself don't have a mechanism to access the data? I already mentioned that we need to evolve. Your requirements are evolving. You need confidential computing on GPUs, you need confidential computing with networking and storage. As product managers, when we thought about building this into Nitro Enclaves, if we kept adding more and more capabilities to Nitro Enclaves, it would start looking like an instance. So instead of evolving Nitro Enclaves that way, what we've done is we brought the capabilities that you love in Nitro Enclaves back to your regular Nitro EC2 instances.
This is what we've launched. We call this EC2 Instance Attestation. This is a capability that makes it easier for you to verify that only trusted software, trusted code, is running on an EC2 instance. You could certainly build trusted EC2 instances before, and you could certainly build EC2 instances without SSH. But what we have here is the ability to attest to that, to prove it, and only then allow decryption of data if that is true. One thing you might notice, we didn't call it AI. It's called EC2 Instance Attestation. Because we see this as a way for customers to use it for different kinds of use cases. We see this as something very powerful for you to use generically.
So what is EC2 Instance Attestation? It's made up of a few capabilities, and I'll talk about them right now. At the foundational layer, you have the Nitro System. This is your Nitro EC2 instance. Zero operator access. You have the Nitro TPM, what we call the Nitro Trusted Platform Module, which is a device that you can attach to your EC2 instance. This is something you already have. It complies with TPM 2.0 standards and it measures and attests to your EC2 instance. You can do this on EC2 instances with AI accelerators. Many of our GPU instances, Trainium 2, have this capability. This is the starting point.
So let's look at the new capabilities. The first new capability that we launched is Attestable Amazon Machine Images. This is a new way to build your AMI. And when you build it, you will get a cryptographic hash that represents the content of your AMI, the boot process. We'll dive into that in a little bit more detail. The next new capability is the Nitro TPM Attestation Document. This now allows you to generate the same style of attestation document that you get from Nitro Enclaves, using the Nitro TPM, on your regular Nitro EC2 instances. This makes the attestation process very easy. You no longer need to do multiple steps of dances, you just get a signed document with all the information you need.
And finally, the last piece we launched, we understand that all customers need to think about key management. Attestation and how to encrypt data and only allow decryption if attestation passes. So we've integrated with AWS KMS to do the heavy lifting for you. We've integrated Nitro TPM with AWS KMS. So combining these three capabilities gives you the tools to configure your EC2 instances to be an isolated computing environment, an environment that even you don't have access to.
So let's dive into each one of these a little bit more detail. So the first one is Attestable AMIs. This is a new way to build your AMI, and when you finish building and creating your AMI, you get a corresponding hash. And this contains the measurements of everything you placed inside the AMI. The hash that you get from this AMI, that is your reference measurement. That is the true hash. Because you know all the ingredients you placed inside the AMI. You know that it is true, so you're going to keep that safely for later verification. Remember that.
Building an Isolated Computing Environment and Measurement with Nitro TPM
So going back to the problem that we are trying to solve here, you have an inference environment that you want to lock yourself out of. What kind of configuration can you put in? How do you set it up such that you can't access it? So there are some best practices that we can share here, and it's also documented. I say best practices because it varies depending on your type of use case. It varies depending on how you use it.
But the first one, the most important one, you want to remove all forms of interactive access. What do I mean by interactive access? No SSH, no serial console, no SSM. And it's not just a matter of disabling access to your users' SSH capability. What we're talking about is the SSHD daemon is not even installed to begin with. There's no mechanism there whatsoever. So the first one is to remove that access.
Number two, you want to verify and make sure that only trusted code is running within that instance, within that AMI. Because you're doing very sensitive processing, you don't want to install all sorts of packages that you may or may not need. You're going to look at only the packages you need, only the tools you need to enable that workload to run.
Number three, because there's networking now, you want to have network firewalls within the instance boundary to make sure that you get protected access there. And number four, you want to make sure all your 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. So how do you make use of it? So you can borrow from what we did in the Nitro System, and we look at building APIs. Not just any API, but trusted APIs that require authentication, that require verification, that are logged and approved before they are used. And because you are the designer of these APIs, you ensure that these APIs do not interact with customer data, with user data, in any way that is not intended, not documented, not approved.
These are the five best practices, and you can put these ingredients into your isolated compute configuration file. So those are the ingredients. Let's put it into a recipe. At the base layer, you have Amazon Linux. Just a barebones image, very minimal. You have your trusted code. And you have your configuration.
Now, we're working with an open source tool called Kiwi. It's an open source tool that allows you to build images, and you can provide a recipe to the Kiwi tool. We've integrated this, and we generate an Attested AMI with a corresponding hash. Now, remember, this is your reference hash. This is the hash that you trust. You provided the ingredients, you validated the ingredients. This is the hash that you trust. Keep this in mind, because you're going to use it.
With NitroTPM, when you launch your EC2 instance, you enable NitroTPM, it attaches a NitroTPM device to your EC2 instance, and at boot time, it measures everything about that EC2 instance. And notice something, your GPUs and AI chips are within the protected boundary of your EC2 instance. When you measure it, you get a calculated hash. And you can take the calculated hash for this instance and compare it with your reference hash to verify. Is this indeed an instance running with the configuration that I stated with zero operator access? And if it is true, then you've done it the right way.
How Cryptographic Attestation Works and Integration with AWS KMS
So you could absolutely create EC2 instances without SSH before. The difference here is you can take the measurements and compare against that. So that's how we solve goal number two. An isolated computing environment with no mechanism to access user data. So now let's talk a little bit more about how to solve number three. And to do number three, let's go back to the beginning. How does cryptographic attestation work? So the reason you need attestation is, how do you know your instance is really yours?
How do you know that instance I-123, or instance A in this case, has the right code, the right measurements that you stated? If you take your time, you can certainly figure that part out. But imagine hundreds, thousands, hundreds of thousands of instances. The problem multiplies. You need a more scalable way to figure out if this is the right instance, your trusted instance. Before you send it very sensitive data.
For humans, we've already solved this problem. Most of us who flew here to Vegas, you have to go through a passport or an identity card, a Real ID. To come to Vegas. If you think about it, the attestation document is like a passport for your EC2 instances or your enclaves. Instead of a name, instead of your date of birth and location, you get measurements. And it contains the measurements of the code that's present at boot time, the boot process, all the configuration. And the passport has to be issued by an authorized entity. Not just anyone can issue it. So the attestation document you get here is going to be signed by the Nitro hypervisor, the Nitro system.
So that's the first part of attestation. Is to generate an attestation document, and to be able to create it. That's the other side, the other aspect of attestation. How do you verify it? If I give you a passport, which database do you check against to make sure that the values on the passport are true? That's the verification part. And the verification part, you can solve it by having your service refer to the reference hash. Remember when you built your AMI at the very beginning, you got a reference hash? You can just keep that down and have your service refer to it, or check against it.
But the challenge there is, remember that we want to encrypt data, send it into an isolated computing environment to be processed. So that's not enough. Understanding that, we also need to add key management somewhere in between. So borrowing from what Arvind said, what we did for Nitro Enclaves, knowing that all customers would try to figure out that piece, we also did the heavy lifting for you. So we integrated attestation with AWS KMS. When I say integrated, what I mean here is that AWS KMS has the capability to ingest attestation documents. It knows how to compare the measurements against your trusted measurements.
You simply place your trusted measurements as a KMS key policy. It compares against that. And the other thing it does is, it also knows how to compare it and check for the signature to make sure that the Nitro system has signed it correctly. So this is the capability that will make multi-party computation on EC2 instances easy for you. So now we've looked at all the pieces that we've launched. Let's put them all together and see how we can make a flow. And the flow becomes simple. Because we designed it to be simple.
When you have user data that you want to protect, you encrypt it, you send it into an EC2 instance that you've configured with no SSH, no interactive access. We've built that separation. It gets sent into the EC2 instance. The EC2 instance then sends an attestation document to AWS KMS and says,
"Hey, I'm a real instance, please check my configuration, here are my measurements." AWS KMS receives that, compares it against the key policy, and compares it against the reference measurements that are there. If that checks out, it returns the encrypted data key to the EC2 instance, where only the EC2 instance can decrypt it. Now you have decrypted user data.
You can process it with that LLM, and you can do your inference. And depending on whether the output is confidential or not, you can encrypt it and send it back out. So this is the flow that we believe is very powerful for customers. By the end of this week, as I said, we have workshops, we have chalk talks. Everyone can leave Vegas with an application that does this. And if you can't make it, we will also have workshops online.
Applications to Multi-Party Computation and Federated Learning
This is how we solve the three privacy goals. And we've made this process very easy. We've done it by giving customers a combination of these tools. Now, as I promised you at the outset, I'll talk more about AI. This is just a reference case study. So let's dive a little deeper into how we're going to look at this and how it changes.
In the example I gave earlier, we have this flow. We have user data that we want to protect, we have model data that we want to protect, and the processing in the middle is inference. But let's take inference out for a second. Instead of a model provider and user data, let's say we have two hospitals. They have patient data, and Hospital A and Hospital B say, if we can find a way to collaborate and share our patient data, we can derive some metrics and information that will help our research.
This is a privacy-preserving way, where you encrypt the data, send it to an environment that neither party can access, perform the agreed-upon processing, and only allow decryption of the data if it is true. So, even if you change the processor and the parties in the middle, the diagram looks similar. This is a multi-party computation process.
So let's change hospitals to something else, consumer goods. Let's say we have two different companies processing user preferences. In the ad-tech space, they want to tokenize user identities. So, instead of looking at William's preference for shoes, they're looking at token ABC's preference for shoes. The confidential part of this processing is the tokenization process, taking the name William and converting it to a token. Because if I can access that tokenization engine, I can reverse it and see it. You want to run this in an isolated computing environment in a way that neither party can do this. So, there's a lot of interest in the ad-tech space.
Federated learning. Let's say you can't send patient data outside. Cancer centers and hospitals sometimes have requirements where they cannot do that. So, in federated learning, instead, you train the data locally, you build the model locally, and you only send the model weights to a central location. The central location is an aggregator that combines all the model weights to create a global model that all parties can use and benefit from.
All we've changed in this diagram is the number of users and the processing part. The concept here is still the same: multi-party computation, building an isolated environment that no party can access, encrypting the data—whether it's model weights or confidential data—sending it to that environment, and decrypting it when its authenticity has been attested. So, I hope today you've learned a new process. As I said, everyone here can leave Vegas with a new confidential computing application that makes this happen.
Summary of Confidential Computing Features and Future Resources
So, I want to hand it over to my colleague, Arvind, who's going to give you more resources on how you can leverage these capabilities. Thank you, William. So let's move forward. Let's recap what we've talked about today when it comes to confidential compute. We've talked about different capabilities for different considerations. We have the Nitro System, and your EC2 instances are built on top of that. So if you just want to protect from us and just want to launch an instance, you're good to go.
Now, if you're looking for an enhanced, very opinionated, isolated compute environment, we have Nitro Enclaves. If you're looking for AI use cases, protecting your models, protecting the weights on your GPUs, or your accelerators, William talked at length about EC2 attestation and how to use that on your GPU and AI accelerator-enabled instances. But there's a common theme to all of this, and the common theme is Nitro. What's truly special is that with any of these that we've talked about, they all come with zero operator access guarantees. No mechanism whatsoever.
You might notice that I've shifted my language a little bit from "no operator access" to "zero." Because if you're just using an EC2 instance, you're protected from us. But when you add the additional capabilities, now you're also protected from yourselves. So this is how we're moving towards zero operator access.
As I mentioned earlier, with all of this, because of the way we architected it, you get near bare metal performance. The delta between a virtualized instance and a bare metal is like single-digit percentages, so it's very high performance. So it's very suitable for your AI workloads. With the new launch, it's supported across all instance types. You're not restricted to CPU. You can use GPUs, AI accelerators, or any CPU if you're using enclaves. There's a lot of flexibility in the instance types we provide.
As I mentioned with attestation, we've made sure to integrate all of this with KMS already. For most customers who are leveraging these capabilities with our Key Management Service, it's already built. But you're not restricted to that. You can always use your own key store, or use your own external service. You just have to learn how to use that attestation document and build it yourself. For the new capabilities that William talked about today, we've also launched them across all commercial regions and GovCloud. So if you're working on mission-critical applications or workloads and leveraging GovCloud, all of this is available in GovCloud in addition to the commercial regions.
Now, if any of this has piqued your interest and you want to build further, we have two more sessions dedicated to this topic. One is a Code Talk, which is a deep dive where we demystify attestation. We'll actually open up the attestation code and show you what's implemented and how to use it. The other one is a workshop that you can attend tomorrow, specifically on creating a Trusted Execution Environment for Generative AI applications. We'll show you how to get the whole thing up and running using GPU or Inferentia or training-based instances.
Thank you all for taking the time to listen to us today and for joining us for our confidential compute discussion at re:Invent 2025. Thank you very much.
※ This article is automatically generated using Amazon Bedrock, while maintaining the information from the original video as much as possible. Please note that there may be typos or incorrect information.
Discussion