Following a successful migration from DigitalOcean to AWS, a Berlin-based EdTech company needed to harden its infrastructure security to meet German enterprise requirements and prepare for ISO 27001 certification.
Industry
EdTech
Location
Berlin, Germany
Time
03.2025 - Present (ongoing retainer)
Company
Under NDA
The client is a Berlin-based EdTech company providing a multi-tenant corporate training and learning management platform used by enterprises across the DACH region. The platform handles employee training data for German and European enterprises, which means compliance with German Datenschutz (federal data protection law) and GDPR is a baseline requirement - not optional. The client is actively preparing for ISO 27001 certification to unlock larger enterprise contracts, as German enterprise procurement teams routinely require ISO 27001 before signing.
Devopsity previously delivered the migration of the client’s platform from DigitalOcean to AWS EKS. After the migration completed successfully, the engagement transitioned into security hardening and ISO 27001 preparation, delivered as part of our security and compliance services.
The migration from DigitalOcean to AWS resolved scalability issues and gave the client access to enterprise-grade services. The production infrastructure was running stably on EKS, but from a security perspective, significant gaps remained that blocked onboarding larger enterprise customers.
No environment isolation. Development, staging, and production all ran within a single AWS account. A misconfiguration or compromise in development could reach production data. Enterprise procurement teams flagged this immediately during security assessments.
Incomplete identity management. AWS access was not yet structured to meet enterprise requirements. Enforced MFA across all accounts, centralised permission management with role-based separation, and an audit trail showing who accessed what and when were all missing.
No application-layer protection. No WAF sat in front of the application, leaving it exposed to common web exploits - SQL injection, cross-site scripting, automated bot attacks. For a platform handling employee data for enterprise clients, this was an unacceptable gap.
Limited encryption. German Datenschutz requirements call for demonstrable control over encryption keys - the data controller needs to prove they manage the keys protecting employee data, not just that the cloud provider encrypts by default. The post-migration infrastructure did not yet use KMS customer-managed keys.
No compliance tooling. No continuous compliance monitoring, no security finding aggregation, no configuration drift detection. Preparing for an ISO 27001 audit would have required building evidence manually - a painful, time-consuming process that would need to be repeated for every surveillance audit.
The bottom line: the post-migration infrastructure was stable and scalable, but the client couldn’t pass enterprise procurement security assessments, couldn’t pursue ISO 27001, and couldn’t demonstrate the security controls that German enterprises expect from a vendor handling their employee data.
We separated environments into three distinct AWS accounts within an AWS Organisation - one each for development, staging, and production. This provides hard security boundaries between environments. A compromised development environment cannot reach production data because they’re in different AWS accounts with no cross-account access paths unless explicitly defined.
Service Control Policies enforce organisation-wide guardrails across all three accounts - preventing actions like disabling CloudTrail, deleting Config recorders, creating IAM users with console access, or leaving S3 buckets publicly accessible. These guardrails apply regardless of what permissions an individual IAM role has within an account.
Each account has its own VPC with proper subnet segmentation - public subnets for load balancers, private subnets for compute and data. The architecture is identical across all three accounts, deployed from the same Terraform modules with environment-specific variables.
Human access uses dedicated IAM users with enforced MFA across all three accounts. IAM users are assigned to groups mapped to job functions (engineers, developers, read-only), with permissions attached to groups rather than individual users. aws-vault is mandatory for all CLI access, managing temporary STS session credentials with MFA verification on every operation. IAM Identity Center migration is on the engagement roadmap as the next identity improvement.
Inside the EKS clusters, IAM Roles for Service Accounts (IRSA) provides per-pod IAM scoping. Each workload that needs AWS access has its own Kubernetes service account linked to a dedicated IAM role via OIDC federation. No two pods share an IAM role. No cluster-wide roles exist for application workloads. This means a compromised pod can only access the specific AWS resources its IRSA role allows - not the entire account.
External Secrets Operator bridges AWS Secrets Manager into Kubernetes. Application secrets (database credentials, API keys, integration tokens) are stored in Secrets Manager and synced automatically into native Kubernetes secrets. Developers never interact with Secrets Manager directly and never handle production credentials. The IRSA role for External Secrets Operator itself is scoped to only the specific secrets it needs to sync.
Kubernetes network policies provide an additional identity-aware access control layer inside the cluster. Only pods that need to communicate with each other are permitted to - a compromised pod in one service can’t laterally reach pods in another service, even within the same cluster.
AWS WAF sits in front of the Application Load Balancer, filtering traffic before it reaches the application. Managed rule groups block common web exploits - SQL injection, cross-site scripting, and known malicious bot patterns. This was the specific gap that enterprise procurement teams had flagged.
The WAF integrates with the ALB natively - no additional proxy or appliance is required. Rule groups are managed by AWS and updated automatically as new attack patterns are identified. Customer-specific rules (IP allowlists, rate limiting) are added via Terraform as needed.
All data at rest is encrypted using AWS KMS customer-managed keys. RDS instances (PostgreSQL and MySQL), S3 buckets, and EBS volumes all use KMS encryption. This is a critical distinction for German data protection requirements - the client can demonstrate to regulators and enterprise customers that they control the encryption keys protecting employee data, not just that the cloud provider encrypts by default.
All data in transit uses TLS. Public-facing endpoints use HTTPS with certificates managed through AWS Certificate Manager with automatic renewal. Database connections from application pods to RDS use SSL.
AWS CloudTrail is enabled across all regions in all three accounts, recording every API call. Logs are stored in dedicated S3 buckets with versioning, deletion protection, and log file validation enabled. This provides the complete, tamper-resistant audit trail that ISO 27001 auditors expect.
AWS Config is enabled with continuous recording of all supported resource types. Config tracks every configuration change to every AWS resource, maintaining a timeline that enables point-in-time investigation - “what did this security group look like before last week’s change?” Config rules monitor compliance against security baselines and generate findings when resources drift from compliant configurations.
CloudWatch collects metrics and logs from all infrastructure components. EKS pod logs are shipped via Fluent Bit to CloudWatch Logs, organised by namespace and service. CloudWatch alarms fire on security-relevant thresholds - pod restart loops (potential attack attempt), ALB error rate spikes, and WAF blocked request surges indicating potential attacks.
Custom Lambda functions handle backup automation with cross-region replication for critical data. RDS automated backups provide point-in-time recovery. The entire infrastructure - including all security controls - can be recreated from the Terraform codebase. Recovery procedures are documented in runbooks and reviewed with the client’s engineering team.
Every security control described above is defined in Terraform - the multi-account Organisation structure, SCPs, VPC network architecture, security groups, WAF rules, KMS keys, Secrets Manager configurations, IRSA roles, network policies, CloudTrail, and Config. Changes go through peer-reviewed pull requests with specific attention to security implications. The same Terraform modules deploy identical security baselines across all three accounts, ensuring development and staging have the same security controls as production.
The initial migration focused on shifting workloads, architecture, and economics. Security was good enough for that phase but quickly needed dedicated focus to reach the ISO 27001 standard. Treating security as a separate stream after migration - rather than bolting it on later - saved significant rework.
Security is a journey, not a destination. Regular internal audits and shifting security responsibility left (closer to the development teams) are crucial, but they do not guarantee anything on their own. Configuration drift can and will happen - the question is whether you detect it in hours or months.
The engagement continues as an ongoing retainer. We are preparing for the client’s first ISO 27001 certification audit - the multi-account architecture, encryption controls, access management, audit trails, and compliance monitoring were all designed with ISO 27001 control mapping in mind. Planned improvements include deploying AWS Security Hub with CIS and FSBP standards for centralised security finding management, enabling GuardDuty for ML-based threat detection, and migrating from IAM users to IAM Identity Center for centralised SSO.
AWS Services: Amazon EKS, Amazon ECR, Application Load Balancer, AWS WAF, Amazon RDS (PostgreSQL, MySQL), AWS DMS, AWS Secrets Manager, AWS KMS, AWS IAM, Amazon CloudWatch, AWS CloudTrail, AWS Config, AWS Lambda, Amazon S3, AWS Certificate Manager, Amazon Route53
Tools: Terraform, GitHub Actions, Docker, aws-vault, Fluent Bit, External Secrets Operator, Helm
Following the DigitalOcean to AWS migration, Devopsity hardened the client's infrastructure - implementing a multi-account architecture with environment isolation, KMS customer-managed key encryption, WAF application-layer protection, and continuous compliance monitoring. The platform now passes German enterprise procurement due diligence and is prepared for its first ISO 27001 certification audit.