Azure Cloud Platform and Services

Your application just crashed in production. Azure App Service kept routing traffic to the failing instance for ninety seconds. Users saw timeouts. Your monitoring dashboard stayed green because the web server responded with HTTP 200 while the database connection pool was exhausted.

I’ve watched this exact scenario play out at three different organizations in the past year. Each time, the post-mortem revealed the same root cause: health checks that verified the process was breathing without checking whether it could actually do its job. ISO/IEC 27001 Control A.17.2.1 exists precisely for this reason—availability is a security control, not an operational afterthought.

“We have backups” is the IT equivalent of “thoughts and prayers.” Comforting words that mean nothing when disaster strikes. I’ve watched teams discover their Azure SQL Database backups expired just before an audit, or worse, during an actual outage. The default seven-day retention feels generous until you need data from day eight.

Compliance standards demand information backup in cloud environments, but no standard can enforce what most teams ignore: actually testing those backups. The gap between “we configured backups” and “we can restore our data” has ended careers and companies. This isn’t about checking compliance boxes. It’s about whether your business survives the next outage.

Your cluster will fail. The question is not if, but when, and whether you can recover before customers notice. Most organizations discover their backup strategy does not work during an actual outage, when recovery time matters most and manual heroics cannot save you.

If you run Azure Kubernetes Service (AKS) in production, you need a recovery plan that engineers can execute half asleep at 2 AM. We will go through what to back up, how Velero works in day-to-day operations, when Azure Backup for AKS is enough, and how to design realistic failover with measurable Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The goal is simple: repeatable recovery procedures you have already tested, not a document that looks good in Confluence but fails during an incident.

“Storage is cheap” — until your data retention strategy becomes evidence in a GDPR lawsuit.

After 15+ years in enterprise software, I’ve seen this pattern in project after project: elaborate wiki documentation, a cleanup script nobody runs, and production databases growing exponentially with personal data that should have been deleted years ago. The compliance checkbox is marked, but the actual deletion never happens.

When regulators investigate, they don’t want your policy documents. They want execution logs proving deletion actually happened. Azure Storage lifecycle policies, Cosmos DB TTL, and scheduled Functions give you exactly that — automated retention that runs without human intervention, with full audit trails.

AKS costs are brutally simple: node sizing, pod density, workload sprawl, and reserved capacity. If you don’t have visibility and governance, your cloud bill will punch you in the face—usually when it’s too late to react without pain. I’ve watched teams scramble to cut costs after the invoice lands, breaking production in the process. This guide is for practitioners who want to avoid that mess. No theory, no vendor fluff: just what actually works to keep AKS costs under control without sacrificing reliability.