Deploying on AWS
AWS runs Polaris on AMD SEV-SNP confidential EC2 instances. Read Deploying Polaris first for the choices common to every cloud; this page covers what is specific to AWS.
Before you start
You deploy into your own AWS account and region. You need an account that can create EC2 instances, a VPC with its endpoints, KMS grants, and the IAM roles the components use. Pick a region that offers AMD SEV-SNP EC2 shapes, and settle that together with the TEE choice.
Two things you provide up front on AWS:
- A base AMI. The confidential VM boots from a Polaris machine image. You reference the AMI for your region in the config.
- A key pair. Standard EC2 SSH key-pair name, for operator access to the instances.
On AWS, confidential protection is a per-instance launch setting. An EC2 instance runs as a confidential VM only when AMD SEV-SNP is enabled at launch. Leave it off and the instance boots as an ordinary VM, with no memory encryption and no SEV-SNP attestation report, and AWS raises no error. The workload still runs, so the downgrade is easy to miss.
The Polaris Terraform module and the marketplace listing set this for you. If you launch the Polaris AMI any other way, from the console, the CLI, or your own automation, you have to enable AMD SEV-SNP on the instance yourself. The safe way to confirm it is to verify attestation against the deployment before sending real traffic: a non-confidential instance cannot produce a valid report, so the check fails cleanly. See Verifying a Deployment.
TEE options
| Choice | Hardware | Instance family |
|---|---|---|
| AMD SEV-SNP | AMD EPYC | m6a and other SEV-SNP-capable shapes |
AWS today exposes AMD SEV-SNP only; Intel TDX and confidential GPUs are not available on AWS confidential instances. If you need those, see the Google Cloud or Microsoft Azure pages.
Verification path
Polaris verifies the AMD SEV-SNP report against AMD's published keys. The workload VM reaches AWS services through VPC endpoints rather than the open internet, so the deny-by-default egress holds while KMS and the other control-plane calls still work.
Key management
The Policy Manager gates an AWS KMS key. You reference the key by its ARN in the config, so you can bring an existing customer-managed key or point at one created for the deployment. Access is managed through KMS grants that follow the attestation verdict: the grant stands while appraisal passes and is pulled when it fails. The key never leaves your account.
Sizing
You set the instance type for the workload VM and for the Policy Manager VM. The workload runs on a SEV-SNP-capable shape sized to your application; the Policy Manager is light and runs on a smaller instance of the same family.
How you deploy
- Command line. Point the deploy script at an AWS config file with your region, AMI, key pair, and KMS key ARN. The workload is normally a prebuilt image in ECR; a registry outside the deployment region needs its address range allowlisted, or the boot-time pull hangs against the deny-by-default egress.
Notes
- Instance-metadata credentials are firewalled off from the workload container by design, so a compromised workload cannot borrow the instance's IAM identity to reach KMS behind Polaris's back.
- Tearing down the deployment removes the instances, the VPC resources, and the KMS grants. The KMS key itself stays, since you own it.