AWS architecture

The Virtual Signer on AWS uses a security-first architecture designed for multi-tenant isolation and hardware-based confidential computing. The infrastructure is deployed and managed with AWS CloudFormation.

Key components

The Virtual Signer infrastructure combines several AWS services to provide a secure, scalable signing solution.

Networking layer

Amazon VPC provides complete network isolation with private subnets and controlled egress through a NAT Gateway. Security Groups enforce strict firewall rules that control inbound and outbound traffic, permitting only authorised connections. All Virtual Signer instances operate within private subnets with no direct internet access.

Compute layer

Amazon ECS on EC2 orchestrates the containers. The deployment uses EC2 rather than Fargate because AMD SEV-SNP hardware security features require access to the underlying instance. Auto Scaling Groups adjust capacity based on demand within configurable minimum and maximum limits. Capacity Providers handle intelligent container placement and infrastructure scaling across the cluster.

Storage layer

Amazon S3 provides encrypted, versioned storage buckets for each Virtual Signer instance. AWS KMS manages customer-controlled encryption keys with per-tenant isolation, ensuring cryptographic separation between instances. CloudWatch Logs stores encrypted logs with configurable retention policies.

Security layer

The security layer implements defence-in-depth by combining hardware protection, encrypted storage, and strict access controls.

AMD SEV-SNP encrypts all Virtual Signer memory at the hardware level, making it inaccessible even to the hypervisor.
Bottlerocket OS in confidential lockdown mode provides a hardened container host with an immutable root filesystem, kernel lockdown enforcement, and minimal attack surface.
AWS KMS with customer-managed keys (CMKs) encrypts all data at rest including S3 buckets. Each tenant has a dedicated CMK for complete cryptographic isolation.
IAM Roles enforce least-privilege access, limiting each component to only its required permissions.
SSM Parameter Store manages encrypted runtime configuration, allowing secure updates without code changes or container restarts.

Multi-tenant architecture

Each Virtual Signer instance operates in complete isolation, ensuring data privacy and operational independence.

Per-instance resources

Every instance has its own:

Customer-managed KMS key for encryption
Isolated S3 bucket with versioning and lifecycle policies
Independent CloudWatch log group encrypted with the instance's KMS key
Unique ECS service with its own task definition
Distinct IAM role scoped to access only that instance's resources

Resource naming convention

All resources follow a consistent naming pattern based on the instance identifier. This enables clear resource ownership identification, simplified cost allocation, automated resource management, and streamlined troubleshooting.

Why ECS on EC2?

The Virtual Signer uses ECS on EC2 because AMD SEV-SNP (Secure Encrypted Virtualisation, Secure Nested Paging) currently requires EC2 instances. SEV-SNP provides hardware-based security that protects cryptographic operations.

AMD SEV-SNP benefits

AMD SEV-SNP encrypts all Virtual Signer memory with a unique hardware-generated key. It enables cryptographic attestation of the execution environment before any key operations run. This protects against infrastructure-level threats, including potentially malicious hypervisors, because the security guarantees come from AMD processor features rather than software alone.

Bottlerocket OS

The EC2 instances run Bottlerocket, a purpose-built container operating system. Its root filesystem is immutable, preventing runtime modifications and rootkits. Updates use atomic operations with automatic rollback on failure. The OS includes only essential components and runs with kernel lockdown in confidentiality mode.

Data flow and security

The Virtual Signer implements defence-in-depth with multiple security layers.

Request processing

Ingress control. All inbound traffic passes through VPC security groups with allowlisted IPs.
TLS termination. HTTPS connections terminate at the application layer.
Authentication. The application validates API keys from environment variables.
Authorisation. Policy-based access control governs signing operations.

Cryptographic operations

Key generation. Keys are created within AMD SEV-SNP protected memory.
Secure storage. KMS encrypts keys before writing them to S3.
Runtime protection. Keys are only decrypted within the SEV-SNP enclave during signing.
Audit trail. All operations are logged to encrypted CloudWatch logs.

Data protection

All data at rest is encrypted with KMS-managed keys. All network communication uses TLS 1.2 or higher. AMD SEV-SNP encrypts data in memory during processing, so it remains protected even during computation. Automated KMS key rotation policies maintain cryptographic hygiene.

Infrastructure as code

The Virtual Signer infrastructure is defined and deployed using AWS CloudFormation.

CloudFormation

We provide a one-click deployment via the AWS Console with pre-configured templates that follow AWS best practices. Parameter-based customisation lets you adjust key settings without modifying the underlying infrastructure code. The automated provisioning ensures AMD SEV-SNP is properly enabled on EC2 instances from the start.

Benefits of the AWS deployment

AMD SEV-SNP encrypts memory at the hardware level, protecting cryptographic operations even from the hypervisor.
Auto-scaling adjusts capacity based on demand, reducing operational overhead.
Integrated CloudWatch monitoring provides visibility into system health, performance, and security events.
The fully managed approach reduces the operational burden while maintaining high security standards.

Monitoring and observability

The Virtual Signer exposes Prometheus-compatible metrics for real-time operational visibility.