Three labels, one platform, always on

With CloudNation managing the AWS platform around the clock, Blinqx can focus on what it does best: building software for the mortgage and financial advice market. Proactive monitoring, 24/7 incident response and continuous optimization keep the platform reliable, secure and ready to grow.

About Blinqx

Blinqx provides software solutions for the Dutch mortgage and financial advice market. Through labels including Finly, Yes-co and De Nationale Hypotheekbond, its technology supports advisers, lenders and consumers across the mortgage journey. With software at the heart of these services, Blinqx relies on a secure, scalable and continuously available cloud platform to keep its applications running.

The Challenge

Blinqx's engineers build software for advisers, lenders and consumers. They know their applications and their Kubernetes workloads inside out. What they did not want to build was a second discipline alongside it: a team with deep AWS expertise, on a standby rota, watching a five-account platform at three in the morning.

That was the real question Blinqx put to us. Not "can you build this", because we had already built it, but "will you run it, and stand behind it?"

Three things had to be true. Events on the platform needed to be caught and acted on when they happened, not found the next morning. Monitoring had to be defined closely enough that Blinqx could stand behind the availability it promises its own customers. And because Blinqx sits in the financial chain, the whole arrangement had to hold up under regulatory scrutiny: who is responsible for what, what happens in an incident, and what happens if the relationship ends.

What we do

We operate Blinqx's AWS platform under a managed-services agreement that sets out scope, responsibilities, service levels and escalation, component by component. We own the foundational AWS infrastructure, the Kubernetes control plane and add-ons, infrastructure monitoring, backup, cost governance and the infrastructure pipelines. Blinqx owns its applications and everything it deploys into them. Where the two meet, the agreement says who does what, and for complex incidents we open a joint war room rather than trading tickets.

Incident response, around the clock. We monitor and respond to critical incidents 24x7, with a first response inside 30 minutes and a root cause analysis for every one of them. Lower priorities run during business hours while monitoring continues overnight. Behind that sits a standby rota across our whole team, not a duty phone handed to whoever is free, staffed by engineers who already know the Blinqx estate. That is the difference between diagnosing an alert and recognising it.

Change without drama. Maintenance runs in agreed windows. Changes that could cause downtime need notice and Blinqx's approval. Emergency changes go ahead immediately and are documented within a day. Nobody is surprised.

AWS billing, handled. We are Blinqx's AWS billing partner, and Managed Cloud Billing is the FinOps layer we wrap around that. More on how it works below.

A platform that keeps getting better. Every two weeks we sit down with Blinqx in a jointly staffed Cloud Center of Excellence, built around five pillars: architecture, FinOps, knowledge, operations, and security and compliance. We review platform health, prioritise the backlog together, and decide what happens next. Incidents feed that backlog: find the root cause, agree the structural fix, schedule it. That is why reactive work shrinks over time instead of piling up.

Room to grow into. Knowledge transfer is part of the deal: documentation, workshops, and a deliberate progression from us doing it, to doing it together, to Blinqx doing it. Our involvement scales up or down as that happens. We are not trying to make ourselves indispensable.

How AWS fits in

Blinqx's applications run on Amazon EKS, across five AWS accounts provisioned through an account factory pattern and defined end to end in Terraform. Around them: Amazon RDS, Amazon ElastiCache for Redis, Amazon MQ, Amazon EFS, Amazon S3, Amazon CloudFront with multi-tenant distributions per label, Elastic Load Balancing, AWS Secrets Manager, AWS Backup, AWS CloudTrail and IAM Identity Center.

We govern the platform against the AWS Well-Architected Framework. That is not decoration: we only commit 24x7 response to an environment we have reviewed and accepted as well-architected. We do not promise to stand behind an architecture we cannot stand behind.

Monitoring: alarms on everything that matters

Amazon CloudWatch, with Container Insights for the Kubernetes layer, 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.

On the cluster that means node and pod health, memory-pressure and out-of-memory kills, disk pressure on nodes, scheduling failures, control-plane and add-on health, and scaling that does not complete. For the data tier: CPU and memory pressure, storage headroom, connection saturation, replica lag, cache evictions and queue depth on the message broker. At the edge: load balancer target health, error rates, latency and distribution errors. Across the accounts: backup job failures, service quota headroom, certificate expiry and scheduled jobs that fail to finish.

Thresholds are layered rather than binary. A warning threshold puts degradation on the CCoE 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 Blinqx'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 across all five accounts and three labels. AWS Data Exports and the Cost and Usage Report feed the underlying detail, AWS Cost Explorer the analysis and forecasting, and AWS Budgets with AWS Cost Anomaly Detection flag unexpected movement before it reaches a month-end invoice. Tagging health is tracked, because in a multi-label platform, cost you cannot attribute to a label 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 Blinqx in the CCoE, 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: monthly cost reporting, clear ownership of follow-up, and FinOps as one of the five standing CCoE pillars alongside architecture and security. Because the same team runs the platform, cost advice is grounded in what the workloads actually do.

The result

We see it before Blinqx does. Over the last twelve months, 87% of all tickets on the platform were opened by our monitoring rather than reported by a person. Blinqx raised nine tickets in a year. Everything else, we found first.

Three labels running in production on one platform, with 24x7 cover, since July 2025 and counting.

Blinqx's engineers stayed on software development and are only involved in AWS CCoE-related topics that address expansion, improvement or optimisation, not the day-to-day operations. The platform beneath them is our job, with the boundary written down rather than negotiated during an incident.

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.

And for a company in the financial chain: a documented shared responsibility model, service levels, escalation, change control and an exit plan, the things Blinqx's own auditors ask to see.

The numbers, in one place
Measured over the 12 months to September 2026