Software for care, running on AWS

SDB Groep builds software that supports healthcare and childcare professionals every day. CloudNation keeps the AWS platform behind it running. With continuous monitoring, 24/7 support for critical incidents and ongoing optimization, SDB can focus on developing its software while we take care of the cloud infrastructure underneath.

About SDB Group

SDB Groep is a Dutch software company providing workforce and enablement solutions for healthcare and childcare organizations. With more than 45 years of experience and around 450 employees, SDB develops technology that supports professionals in their daily work and helps organizations streamline their processes.

The Challenge

Care workers and childcare professionals use SDB Groep's software to do their jobs. When the platform underneath it has a bad morning, that is felt in care homes and nurseries, not in a dashboard.

SDB Groep had been running on AWS for close to a decade, but inside another provider's managed organisation and deployed with that provider's in-house framework. Moving to us solved the ownership question. It did not solve the running question, and that was the one SDB cared most about.

Their teams build healthcare software. Keeping an AWS platform live, watching it continuously, and responding to events around the clock is a different discipline, and one they explicitly wanted taken off their hands. The agreement we signed says so in as many words: keep the environment live.

Alongside that sat three more needs. Monitoring defined well enough that SDB can stand behind the service levels it promises care organisations. One owner for AWS invoicing, commitments and cost questions. And governance covering access control, change management and platform responsibility, embedded rather than improvised, which matters when your customers are regulated and your data is healthcare data.

What we do

We operate SDB Groep's AWS platform under a managed-services agreement, with a named service manager who owns the operational agreement and reports on service levels.

Critical incidents, covered 24/7. Priority 1 incidents are covered around the clock by standby specialists, and monitoring runs seven days a week. Other incidents and requests run on business hours. We commit to reaction targets, a phone call answered in under a minute and e-mail triaged inside two hours, and to resolution targets: 90% of critical incidents inside four hours, 99% inside eight.

Behind those numbers is a standby rota across our team, staffed by engineers who already know SDB's environment. Diagnosis starts from a known design rather than from discovery, which is most of where the time goes.

Maintenance you can plan around. Scheduled maintenance is announced at least two weeks ahead. Emergency windows exist for when the environment genuinely needs urgent work, and we tell SDB straight away.

AWS billing and cost, in one place. We are SDB's AWS reseller, and Managed Cloud Billing is the FinOps layer we wrap around that. More on how it works below.

A platform that keeps improving. We work with SDB through a Cloud Center of Excellence built around five pillars: architecture, FinOps, security and compliance, operational excellence, and knowledge transfer. Improvements come off a shared backlog that we prioritise together. When an incident happens, we find the root cause, agree the structural fix in governance, and schedule it, so the same problem does not keep coming back. Every quarter we report on the service and review it together.

The modernization work SDB parked during the move lives on that backlog too. It did not disappear when the migration ended.

Growing independence. Knowledge transfer is part of the model: documentation, workshops, and a progression from us doing it, to doing it together, to SDB doing it. Our involvement scales with what they want to own.

How AWS fits in

The production platform runs on Amazon EC2 behind Auto Scaling groups, with Amazon RDS as the transactional store, inside an AWS organisation we manage. AWS Organizations and landing zone tooling provide the account structure, guardrails and centralised logging. AWS Security Hub feeds the security advisory stream we act on. Everything is defined in Terraform and delivered through CI/CD, so there are no console clicks and no undocumented state.

We govern the platform against the AWS Well-Architected Framework, and we only commit 24/7 response to an environment we have reviewed and accepted as well-architected.

Monitoring: alarms on everything that matters

Amazon CloudWatch is the backbone of the service. Every vital service and resource in the accounts under managed scope carries CloudWatch alarms, and not a single alarm apiece: each resource type gets a set of alarms watching several metrics at several thresholds, so the different ways that resource can fail are each covered rather than collapsed into one signal.

For the database tier that means CPU and memory pressure, storage headroom, connection saturation, replica lag, IOPS and burst-balance exhaustion, and backup or snapshot failure. For compute it means instance and status-check failures, CPU and memory saturation, disk-space exhaustion, and scaling events that do not complete. For the front door it means load balancer target health, error rates and latency. Across the accounts it covers service quota headroom, certificate expiry, and scheduled jobs that fail to finish.

Thresholds are layered rather than binary. A warning threshold surfaces degradation into the backlog while there is still time to act; a critical threshold raises a Priority 1 and pages the standby engineer. That layering is what turns monitoring from a dashboard into an early-warning system, and it is a large part of why root cause is reached faster.

None of it is hand-built per environment. Alarms are defined as code and deployed with the infrastructure, so new resources arrive already monitored and coverage cannot quietly drift behind the platform.

Managed Cloud Billing: the FinOps layer

Direct AWS billing gives you cost data. It does not give you clarity about what to do next. Managed Cloud Billing is the service we wrap around SDB's AWS spend to close that gap, and it rests on four things: visibility, expertise, optimisation and governance.

Consolidated billing in euros gives one invoice and one owner for account-level and resource-level cost. AWS Data Exports and the Cost and Usage Report feed the underlying detail, AWS Cost Explorer the analysis and forecasting, and anomaly alerting flags unexpected movement before it reaches a month-end invoice. Tagging health is tracked, because cost you cannot attribute is cost nobody owns.

On optimisation we work from the recommendations AWS itself generates, and then do the part tooling cannot: judge them. AWS Cost Optimization Hub and AWS Compute Optimizer surface rightsizing, idle resources and modernisation candidates. Savings Plans and Reserved Instance recommendations and the AWS Purchase Analyzer support commitment decisions, coverage and term mix. The AWS FinOps Agent keeps that analysis running continuously rather than once a quarter. Recommendations are reviewed with SDB, prioritised on the shared backlog and tracked to an owner, so they turn into actions rather than a report nobody reads.

Governance ties it together: a recurring review cadence, clear ownership of follow-up, and cost as a standing item in the CCoE alongside architecture and security. Because the same team runs the platform, cost advice is grounded in what the workloads actually do.

The result

Most of it, we found ourselves. Over the last twelve months, 84% of all tickets on SDB's platform were opened by our monitoring rather than reported by someone at SDB. The platform tells us it has a problem before a care organisation notices one. That is the number we would most like to be judged on.

Production running continuously under our management since June 2025, with critical incidents covered around the clock and monitoring seven days a week.

SDB's engineers stayed on healthcare software development and are only involved in AWS CCoE-related topics that address expansion, improvement or optimisation, not the day-to-day operations.

And underneath it, a platform that behaves. Production workloads have been steadily available, with almost no downtime experienced. All infrastructure is managed as code, patching is automated and reaches full compliance after every run, and backups run automatically with a 100% success rate and restore procedures that have been tested rather than assumed. For a supplier to regulated care organisations, that last point is not a detail.

And AWS commercials sit with the same partner that runs the platform, so a cost conversation and an engineering conversation are the same conversation.