AWS Architecture

The Virtual Signer on AWS utilises a comprehensive, security-first architecture designed for multi-tenant isolation and hardware-based confidential computing. The infrastructure leverages AWS CDK for deployment and management.

Key Components

The Virtual Signer infrastructure consists of several integrated AWS services working together to provide a secure, scalable signing solution:

Networking Layer

The networking infrastructure centres on Amazon VPC, which provides complete network isolation with private subnets and controlled egress through a NAT Gateway. Security Groups enforce strict firewall rules that control both inbound and outbound traffic, ensuring only authorised connections are permitted. All Virtual Signer instances operate within Private Subnets with no direct internet access, adding an additional layer of network security.

Compute Layer

The compute infrastructure utilises Amazon ECS on EC2 as its container orchestration platform, specifically running on EC2 instances to enable AMD SEV-SNP hardware security features. Auto Scaling Groups provide dynamic capacity management that automatically adjusts based on demand, with configurable minimum and maximum instance limits. Capacity Providers ensure intelligent container placement and infrastructure scaling, optimising resource utilisation across the cluster.

Storage Layer

The storage architecture relies on Amazon S3 to provide encrypted, versioned storage buckets dedicated to each Virtual Signer instance. AWS KMS manages customer-controlled encryption keys with complete per-tenant isolation, ensuring cryptographic separation between instances. CloudWatch Logs serves as the centralised logging solution, storing encrypted logs with configurable retention policies to meet compliance and operational requirements.

Security Layer

The security layer implements defence-in-depth by combining hardware-based protection, encrypted storage, and strict access controls to protect Virtual Signer operations at every level.

AMD SEV-SNP - Hardware-based memory encryption ensures all Virtual Signer operations occur within encrypted memory enclaves that are inaccessible even to the hypervisor
Bottlerocket OS in confidential lockdown mode - Hardened container host with 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, with each tenant having their own dedicated CMK for complete cryptographic isolation
IAM Roles - Fine-grained access control following least-privilege principles, ensuring components only have necessary permissions
SSM Parameter Store - Encrypted runtime configuration management 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

Each Virtual Signer instance maintains complete resource isolation through a comprehensive set of dedicated components. Every instance operates with its own customer-managed KMS key for encryption, an isolated S3 bucket configured with versioning and lifecycle policies, and an independent CloudWatch log group encrypted with the instance's specific KMS key. Additionally, each instance runs as a unique ECS service with its own task definition and service configuration, protected by a distinct IAM role that provides scoped permissions limited to accessing only that instance's specific resources.

Resource Naming Convention

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

Why ECS on EC2?

The Virtual Signer uses ECS on EC2 instances to enable AMD SEV-SNP (Secure Encrypted Virtualisation - Secure Nested Paging). Currently, only ECS on EC2 instances support AMD SEV-SNP, which provides hardware-based security critical for protecting cryptographic operations.

AMD SEV-SNP Benefits

AMD SEV-SNP provides comprehensive hardware-based security through memory encryption, where all Virtual Signer memory is encrypted with a unique, hardware-generated key. The technology enables attestation capabilities for cryptographic verification of the execution environment before any key operations are performed. This confidential computing approach protects against infrastructure-level threats and potentially malicious hypervisors, establishing a hardware root of trust where security guarantees are backed by AMD processor features rather than relying solely on software-based protections.

Bottlerocket OS

The EC2 instances run Bottlerocket, a purpose-built operating system for containers that provides multiple security enhancements. Its immutable root filesystem prevents runtime modifications and protects against rootkits, while automated updates use atomic operations with automatic rollback capabilities on failure. The OS maintains a minimal attack surface by including only essential components, and operates with kernel lockdown configured in confidentiality mode for maximum security.

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 terminated at the application layer
Authentication: API key validation using credentials from environment variables
Authorisation: Policy-based access control for signing operations

Cryptographic Operations

Key Generation: Keys created within AMD SEV-SNP protected memory
Secure Storage: Keys encrypted with KMS before storage in S3
Runtime Protection: Keys only decrypted within SEV-SNP enclave during signing
Audit Trail: All operations logged to encrypted CloudWatch logs

Data Protection

The Virtual Signer implements comprehensive data protection through multiple encryption layers. Encryption at rest is enforced for all data using KMS-managed keys, while encryption in transit secures all network communications with TLS 1.2 or higher. During processing, encryption in use is provided by AMD SEV-SNP memory encryption, ensuring data remains protected even during computation. Automated KMS key rotation policies maintain cryptographic hygiene and compliance with security best practices.

Infrastructure as Code

The Virtual Signer infrastructure is defined and deployed using AWS CDK (Cloud Development Kit):

CDK Benefits

Type-Safe Configuration: TypeScript ensures configuration correctness at compile time
Reusable Components: Modular constructs for consistent deployments
Environment Management: Separate configurations for dev, staging, and production
Automated Best Practices: CDK implements AWS Well-Architected Framework principles

Stack Architecture

VsStack: Main infrastructure stack containing VPC, ECS cluster, and shared resources
VsService: Per-instance construct encapsulating all tenant-specific resources
Custom Constructs: Specialised components for KMS keys, launch templates, and networking

AWS Deployment Options

The Virtual Signer on AWS can be deployed using two primary methods, each suited to different operational needs:

CloudFormation (Recommended for Operations)

CloudFormation provides a streamlined deployment experience ideal for production environments. The one-click deployment via AWS Console offers pre-configured templates with sensible defaults that follow AWS best practices. Parameter-based customisation allows you to adjust key settings without modifying the underlying infrastructure code. The automated resource provisioning ensures AMD SEV-SNP is properly enabled on EC2 instances, providing hardware-based security from the start.

AWS CDK (Recommended for Development)

AWS CDK offers full infrastructure customisation through TypeScript code, enabling precise control over every aspect of the deployment. This approach integrates seamlessly with CI/CD pipelines for automated deployments and testing. Multi-region deployment support allows organisations to deploy Virtual Signers across different AWS regions for geographic redundancy. Advanced configuration options expose all infrastructure parameters for fine-tuning performance, security, and cost optimisation.

Key Benefits of AWS Deployment

The AWS deployment model provides hardware-based memory encryption via AMD SEV-SNP, ensuring cryptographic operations remain protected even from the hypervisor. Managed infrastructure with auto-scaling automatically adjusts capacity based on demand, reducing operational overhead. Integrated CloudWatch monitoring provides comprehensive visibility into system health, performance, and security events. The fully managed approach reduces the operational burden on your team while maintaining high security standards.

Monitoring and Observability

The Virtual Signer provides comprehensive monitoring capabilities through multiple integrated systems, ensuring visibility into system health, performance, and security events.

Prometheus Metrics

Each Virtual Signer instance exposes Prometheus-compatible metrics for monitoring:

Metrics Port: Dedicated port for Prometheus metrics (default: container port + 1300)
Metrics Endpoint: /metrics endpoint exposing metrics in Prometheus format

The metrics cover comprehensive operational insights including application metrics such as signing operations, key generation events, and reshare activities. Performance metrics track request latency, throughput, and queue depths, while resource metrics monitor memory usage, connection pools, and cache statistics. Security metrics provide visibility into authentication attempts, policy evaluations, and approval decisions.

The security group configuration includes ingress rules for the Prometheus port, allowing authorised monitoring systems to scrape these metrics.

CloudWatch Integration

Container Insights

ECS Container Insights is enabled by default, providing comprehensive visibility across the infrastructure. The service delivers task-level metrics including CPU, memory, network, and disk utilisation for each container, along with service-level metrics that aggregate performance data across all Virtual Signer instances. Cluster metrics monitor overall cluster health and resource availability, with automatic collection requiring no additional configuration for basic metric gathering.

CloudWatch Logs

All Virtual Signer logs are automatically sent to CloudWatch through a structured logging pipeline. Each Virtual Signer instance writes to its own encrypted CloudWatch Log Group, with log streams organised by container instance and task for easy navigation. Encryption at rest is enforced using the same KMS key that encrypts the instance's private keys, meaning users need access to this key to view logs. The default retention period is set to 30 days, though this can be adjusted per environment to meet compliance requirements. CloudWatch Log Insights provides powerful query capabilities for troubleshooting and analysis across all log data.

Recommended Monitoring Enhancements

CloudWatch Agent for Prometheus Metrics

While not included by default, organisations can deploy CloudWatch Agent as a sidecar container to collect Prometheus metrics:

Metric Collection: CloudWatch Agent can scrape the Prometheus endpoint
EMF Conversion: Transform Prometheus metrics to CloudWatch Embedded Metric Format
Custom Dashboards: Create CloudWatch dashboards from Prometheus metrics
Unified Monitoring: Combine infrastructure and application metrics in one place

Implementation approach:

Deploy CloudWatch Agent as additional ECS container in task definition
Configure agent to scrape Virtual Signer Prometheus endpoint
Define metric namespace and dimensions for CloudWatch
Create dashboards and alarms based on collected metrics