Infrastructure
Percus runs entirely on AWS. The choice of AWS managed services is a deliberate security decision: it shifts infrastructure patching, physical security, and availability management to AWS, while Percus focuses on application-level security.
Services and their security properties
AWS Lambda
Application logic runs as serverless functions. There are no long-running EC2 instances to patch or harden at the OS level. Each invocation runs in an isolated, ephemeral execution environment. AWS manages the underlying compute infrastructure, including OS updates and hypervisor security.
Amazon Aurora Serverless v2
The Identity Service and Campaign Service each use a dedicated Aurora Serverless v2 (PostgreSQL-compatible) database cluster.
| Property | Detail |
|---|---|
| Encryption at rest | Enabled by default using AWS-managed keys (AES-256) |
| Encryption in transit | TLS required for all database connections |
| Patching | Managed by AWS; minor version patches applied automatically |
| Access | Databases are not publicly accessible — reachable only from within the VPC |
| Automated backups | Enabled by default; point-in-time recovery (PITR) available within the backup retention window |
| Continuous backup | Aurora continuously backs up transaction logs to S3, enabling recovery to any second within the retention window |
Specific Recovery Time Objective and Recovery Point Objective targets are under definition. Aurora's continuous backup model provides near-zero RPO within the retention window. Formal targets will be published in a future update.
Amazon S3
Template files and assets are stored in S3.
| Property | Detail |
|---|---|
| Encryption at rest | Server-side encryption enabled on all buckets (SSE-S3) |
| Access control | Buckets are private; access is granted via IAM roles scoped to the application |
| Object versioning | Enabled — accidental deletion or overwrite can be recovered |
Amazon CloudFront
CloudFront sits in front of all public-facing endpoints.
| Property | Detail |
|---|---|
| TLS termination | All traffic served over HTTPS; HTTP redirected to HTTPS |
| DDoS protection | AWS Shield Standard is included with CloudFront at no extra cost — provides always-on protection against common network and transport layer attacks |
| Edge caching | Static assets (templates, player runtime) cached at edge — reduces origin load and improves availability |
AWS Secrets Manager
All sensitive runtime credentials are stored in AWS Secrets Manager — they are never hardcoded in application code or environment variables.
| Secret | Used by |
|---|---|
| Database credentials (username + password) | Identity Service and Campaign Service — retrieved at startup via DATABASE_SECRET_ARN |
| JWT signing key | Campaign Service — used to sign and verify session tokens, retrieved via JWT_SECRET_ARN |
| Embed session signing key | Campaign Service — used to sign public video share session tokens |
Secrets are fetched at Lambda cold start via the AWS SDK. IAM roles grant each service access only to its own secrets — the Identity Service cannot read Campaign Service secrets and vice versa.
Amazon CloudWatch Logs
Application logs are collected in CloudWatch Logs.
| Property | Detail |
|---|---|
| Log retention | AWS default (logs do not expire — indefinite retention) |
| Audit events | Business-level audit events (who did what and when) are recorded by the Campaign Service and stored in the database |
| Access | Log access is restricted to IAM roles with explicit CloudWatch permissions |
Network isolation
Application services run inside an Amazon VPC. Databases and internal services are not exposed to the public internet. Only CloudFront and API Gateway endpoints are publicly reachable, and all traffic through them is authenticated at the application layer.
Vulnerability management
Trivy filesystem scans run automatically on every pull request targeting main or develop. Scan results cover CRITICAL and HIGH severity vulnerabilities and are uploaded to the GitHub Security tab in SARIF format for review.
| Property | Detail |
|---|---|
| Tool | Trivy (aquasecurity/trivy-action) |
| Trigger | Every PR to main or develop |
| Scope | Full repository filesystem scan |
| Severity threshold | CRITICAL and HIGH |
| Unfixed vulnerabilities | Ignored (only actionable findings reported) |
| Results | Uploaded to GitHub Security tab via SARIF |
AWS shared responsibility model
AWS and Percus share responsibility for security under the AWS shared responsibility model:
| Layer | Who is responsible |
|---|---|
| Physical data centers | AWS |
| Network infrastructure | AWS |
| Hypervisor and host OS | AWS |
| Managed service patching (Aurora, Lambda runtime) | AWS |
| Application code | Percus |
| IAM policies and permissions | Percus |
| Data encryption configuration | Percus (using AWS-provided tools) |
| Access control and authentication | Percus |
| Customer data within the application | Client |
Deployment
Infrastructure is defined and deployed using AWS CDK through GitHub Actions CI/CD pipelines. Changes to infrastructure go through the same code review process as application code.