A UK healthcare platform handling sensitive health data with NHS integrations required a full security transformation - from shared IAM keys and no logging to layered infrastructure protection, encryption, and continuous monitoring.
Industry
Medtech, Healthcare
Location
United Kingdom
Time
06.2025 - Present (ongoing retainer)
Company
Under NDA
The client is a UK-based healthcare and wellbeing platform that connects users with health professionals and community services. The platform handles sensitive health data with integrations to NHS systems, requiring compliance with UK Cyber Essentials Plus and GDPR. Features include care facility listings, professional referrals, calendar management, and an AI-powered search and recommendation engine. The engineering team is small and had no dedicated security or infrastructure function - Devopsity serves as the sole cloud infrastructure and security operations partner.
Devopsity previously delivered the modernisation of the client’s infrastructure from EC2 to ECS Fargate with RDS. After the modernisation completed, the engagement transitioned into security hardening, which is the subject of this case study. This engagement is delivered as part of our security and compliance services.
When we first engaged, the client’s AWS environment had no formal security posture. The platform was running on bare EC2 instances with manual SSH deployments. From a security perspective, the problems were significant:
No identity governance. AWS access was managed through shared IAM users with long-lived access keys. There was no MFA enforcement, no separation of duties between development and production, and no audit trail of who accessed what. Credentials were stored in plaintext configuration files and passed between team members via chat.
No infrastructure protection. Security groups were overly permissive, with some allowing broad inbound access. There was no WAF, no encryption at rest on several data stores, and no network segmentation between services. The database accepted connections from any source within the VPC rather than being restricted to application workloads.
No visibility. CloudTrail was not enabled, so there was no record of API activity. CloudWatch monitoring was minimal. There was no vulnerability scanning, no compliance baseline, and no centralised view of the security posture. If a credential had been compromised, there would have been no way to detect it.
The compliance gap was the most urgent business concern. The client handles NHS-adjacent healthcare data and needed to demonstrate compliance with Cyber Essentials Plus and GDPR. Without access controls, encryption, audit logging, and documented security practices, they couldn’t satisfy the requirements - and couldn’t credibly assure their partners and users that health data was being handled responsibly.
We replaced the entire access model. Shared IAM users were eliminated and replaced with dedicated, individually accountable access:
Human access - SSO setup and in use by everyone that needs access. Engineers use aws-vault for all CLI access, which manages temporary STS session credentials and prevents long-lived keys from being stored on disk. The standard invocation pattern - aws-vault exec profile-prod -- <command> - ensures every operation uses short-lived credentials with MFA verification.
Service access - every ECS Fargate service received a dedicated IAM role pair: a task execution role (for pulling images from ECR and writing logs to CloudWatch) and a task role (for application-level access to Secrets Manager, SSM Parameter Store, and other AWS APIs). No two services share a role. Each role follows least-privilege - specific API actions scoped to specific resource ARNs, no wildcards. When a new service is added to the platform, a new role is created with only the permissions that service needs.
CI/CD access - GitHub Actions authenticates to AWS via OIDC federation with a dedicated github-deployer-production IAM role. The trust policy is scoped to the specific GitHub organisation, repository, and deployment branch. No AWS access keys are stored in GitHub - credentials are generated at runtime via STS and expire when the pipeline completes. The deployer role’s permissions are updated via Terraform whenever a new service is added to the pipeline.
Secrets management - we migrated all credentials out of plaintext files and environment variables into AWS Secrets Manager. Database passwords, API keys (including OpenAI keys for the enrichment service), Redis connection strings, and third-party integration tokens are stored in Secrets Manager and injected into ECS task definitions at runtime. SSM Parameter Store handles non-sensitive configuration using a /{environment}/{service-name}/{parameter-name} convention. Nothing is hardcoded in container images - the same image runs in staging and production with environment-specific configuration injected at launch.
We redesigned the network architecture to enforce defence in depth:
Security groups form a strict inbound chain. The Application Load Balancer is the only component exposed to the internet (HTTPS on port 443). Each ECS service has a dedicated security group that only accepts traffic from the ALB security group on its specific service port. RDS only accepts MySQL connections (port 3306) from ECS service security groups. OpenSearch only accepts connections from ECS service security groups. No database or search cluster is reachable from the internet or from services that don’t need access. All security groups are defined in Terraform - no rules are created or modified through the console.
Encryption covers all data paths. RDS MySQL uses encryption at rest via AWS KMS. OpenSearch uses encryption at rest across all index data and automated snapshots. S3 buckets (including Terraform state) use server-side encryption. ECS Fargate ephemeral storage is encrypted at rest by default. All public-facing endpoints use HTTPS with SSL/TLS certificates managed through AWS Certificate Manager with automatic renewal.
We enabled comprehensive logging and monitoring where none previously existed:
AWS CloudTrail records all API activity across all regions, with logs stored in a dedicated S3 bucket with versioning enabled and deletion protection. This provides a complete audit trail of every IAM change, security group modification, ECS deployment, and data access operation. CloudTrail log file validation is enabled to detect tampering.
Amazon CloudWatch collects metrics across all infrastructure components - ECS service health (CPU, memory, task count), RDS performance (connections, IOPS, free memory), OpenSearch cluster health (memory pressure, search latency, cluster status), and ALB metrics (response times, error rates, healthy host count). CloudWatch Container Insights provides per-container granularity.
CloudWatch alarms fire on critical security-relevant thresholds - ECS tasks failing health checks, OpenSearch memory pressure exceeding safe limits, RDS connection saturation, and ALB 5xx error rate spikes. These alarms enabled us to proactively detect and resolve an OpenSearch memory pressure issue (90-95% SysMemoryUtilization) before it caused a production search outage.
All ECS services ship structured application logs to CloudWatch Logs via the awslogs driver, organised by service and environment. Log groups follow a consistent naming convention, enabling cross-service request tracing for incident investigation.
Every security control described above is defined and managed in Terraform/Terragrunt. The infrastructure repository is organised by account, region, and environment, with reusable modules for security groups, IAM roles, KMS keys, and Secrets Manager configurations. Changes to security infrastructure go through the same peer-reviewed pull request process as any other infrastructure change - a reviewer verifies that IAM policies are least-privileged, security group rules are minimal, and encryption settings are correct before the change is applied.
This approach means the security posture is version-controlled, auditable (every change is a git commit with an author and a review), and reproducible. If a security group rule needs to be investigated, we can trace it to the exact pull request, reviewer, and Terraform apply that created it.
The legacy portion of this project required more effort than initially estimated. Security competes with business economics for attention and budget, and this creates a unique set of constraints. Those constraints can be challenging, but they also push you to find pragmatic solutions - and that makes the work genuinely rewarding.
The security foundation is in place and the engagement continues as an ongoing retainer. We continue to manage production security operations, deploy new services with the same security controls applied from day one, and evolve the security posture as the platform grows. IAM Identity Center migration is planned to replace IAM users with centralised SSO. AWS Security Hub, GuardDuty, and Inspector are on the roadmap to add ML-based threat detection, centralised security finding management, and continuous container vulnerability scanning.
AWS Services: Amazon ECS (Fargate), Amazon ECR, Application Load Balancer, Amazon RDS (MySQL), Amazon OpenSearch Service, AWS Secrets Manager, AWS Systems Manager Parameter Store, AWS KMS, AWS Certificate Manager, AWS IAM (OIDC Federation), Amazon CloudWatch, AWS CloudTrail, Amazon Route53, Amazon S3
Tools: Terraform, Terragrunt, GitHub Actions, Docker
Devopsity transformed the client's AWS environment from zero security posture to a fully governed infrastructure with individually accountable access, layered network isolation, encryption across all layers, and a complete audit trail. The platform now meets Cyber Essentials Plus and GDPR requirements with auditable evidence at every layer.