Loading...
Loading...
Designed and implemented a defence-in-depth security architecture across a multi-region cloud platform — encryption everywhere, network isolation with zero internet access for processing systems, least-privilege access controls, and continuous compliance monitoring against industry frameworks.
Client: Enterprise Client
The challenge
The client was running a growing cloud platform with sensitive employee and business data flowing through multiple services. As the platform expanded, security needed to scale with it. They had basic encryption in some places but not others, IAM roles that were too broad, and processing systems that had unnecessary internet access.
They needed a comprehensive security overhaul: every piece of data encrypted at rest with dedicated keys, every service locked down to only the permissions it actually needs, processing systems isolated from the internet entirely, and continuous monitoring to catch unauthorised access or configuration drift. They also needed to demonstrate compliance with SOC2 and GDPR frameworks for audit purposes.
The challenge was doing all of this without disrupting the existing platform — security had to be layered in progressively, not bolted on as an afterthought.
Architecture diagram: defence-in-depth security layers across the platform
Screenshot coming soon
What we built
We designed and implemented a multi-layered security architecture that protects data at every stage — in transit, at rest, and during processing.
At the encryption layer, we deployed dedicated encryption keys for each service category: one for file storage, one for databases, one for message queues, one for notifications, one for logs, and so on. Each key rotates automatically every year and is locked down so only the specific service that needs it can use it. This means even if one key were compromised, it couldn't be used to access data in other services.
At the network layer, we isolated all processing systems inside private networks with zero internet access. When these systems need to communicate with cloud services (storage, databases, queues), they do so through private endpoints that never touch the public internet. We deployed multiple isolated networks for different workload types — each with its own security boundaries.
At the access control layer, we implemented per-function permissions. Instead of one broad role shared across all processing functions, each function has its own role with only the exact permissions it needs. The file replication service can only read from the source and write to the destination. The data processor can only read from its queue and write to its database. Nothing has more access than it requires.
At the monitoring layer, we deployed three complementary services: threat detection that continuously watches for suspicious activity, data classification that automatically identifies sensitive information, and a compliance hub that evaluates the platform against SOC2 and GDPR frameworks and produces a security posture score.
All of this is backed by comprehensive audit logging. Every API call across the platform is recorded, stored encrypted, and retained according to compliance requirements (security logs kept for 10 years). Dedicated monitoring stacks watch for unusual access patterns to encryption keys and sensitive log groups, alerting immediately on anomalies.
VPC topology: isolated networks with private endpoints and no internet access
Screenshot coming soon
Security Hub dashboard: compliance posture and active findings
Screenshot coming soon
Technical detail
This section is for readers with a technical background who want to understand the architecture and implementation choices.
The security architecture spans 13 CloudFormation stacks managing 36 KMS keys, 56 IAM roles, 33 VPC endpoints, and 4 VPCs across two AWS regions.
KMS Encryption Strategy: 36 customer-managed symmetric keys (ENCRYPT_DECRYPT) with automatic annual rotation. Keys are organised by service: S3, DynamoDB, SQS, SNS, Lambda, CloudWatch Logs, CloudTrail, and per-project keys. Each key policy uses kms:ViaService conditions to restrict usage to requests originating from the intended AWS service (e.g., s3.eu-west-2.amazonaws.com). Deletion protection with 7-day pending deletion window.
IAM Role Structure (56 roles): - Per-function Lambda execution roles with policies scoped to exact resource ARNs - S3 replication roles with cross-region trust and aws:SourceAccount conditions - External access roles gated by sts:ExternalId conditions - Service-linked roles for VPC Flow Logs, EventBridge Pipes - All roles include only AWSLambdaBasicExecutionRole + AWSLambdaVPCAccessExecutionRole managed policies (no wildcards)
VPC Architecture (4 VPCs): - Primary VPC (10.1.0.0/16) — main processing with NAT Gateway for private subnets - Isolated VPC (10.2.0.0/16) — completely air-gapped, no internet route - Replication Security VPC (10.12.0.0/16) — cross-region replication workloads - S3-DynamoDB Processor VPC (10.2.0.0/16) — dedicated processing network
VPC Endpoints (33 total): Gateway endpoints for S3 and DynamoDB (no cost, attached to route tables). Interface endpoints for KMS, CloudWatch Logs, SNS, SQS, and Secrets Manager (placed in dedicated endpoint subnets with security groups). Each endpoint has a resource-scoped policy restricting access to project-specific resources only.
Security Groups & Network ACLs: - Lambda functions: no inbound, outbound TCP 443 to endpoint security group only - VPC endpoints: inbound TCP 443 from VPC CIDR, no outbound (inbound-only) - Network ACLs restrict to HTTPS (443), DNS (53), and ephemeral ports (1024-65535) within VPC CIDR
Audit Logging: - CloudTrail captures all API calls across both regions, encrypted with dedicated KMS key - 41 CloudWatch log groups with tiered retention: processing (365 days), network flow (90 days), application (180 days), security (3,653 days / 10 years), API access (90 days) - VPC Flow Logs enabled on all VPCs, delivered to CloudWatch Logs - KMS access monitoring stack with metric filters and alarms on unusual decrypt/encrypt patterns - CloudWatch Logs access monitoring for sensitive log groups
Enterprise Security Services: - Amazon GuardDuty — continuous threat detection (CloudTrail, VPC Flow Logs, DNS analysis) - Amazon Macie — automated sensitive data discovery and classification in S3 - AWS Security Hub — aggregated findings, SOC2/GDPR compliance evaluation, security posture scoring - All findings flow: GuardDuty/Macie → Security Hub → centralised dashboard
Monitoring: 111 CloudWatch alarms across the platform covering KMS throttling, unauthorised access attempts, VPC endpoint connectivity, security group changes, and IAM policy modifications. Dedicated KMS access monitoring and CloudWatch Logs access monitoring stacks provide anomaly detection.
The results
KMS key management: service-specific keys with automatic rotation
Screenshot coming soon
Interested in something similar?
Book a free 30-minute discovery call. We'll listen to what you need, tell you what's realistic, and give you a straight answer on whether we can help.