Cloud Computing and Cloud Architecture
The cloud is not a deployment target. It is a different operating model with different identity primitives, a different cost model, and a different definition of what “available” means. Articles tagged here focus on the platform-specific decisions — Azure managed services, identity federation, regional design, billing — that decide whether a workload behaves like a cloud system or like a lift-and-shift that happens to run in someone else’s data centre.
Managed-service content sits at the centre of the collection. Azure SQL versus a self-managed instance is not only a price comparison; it is a decision about who owns patching, backup, failover, and the audit trail those operations produce. App Service versus Container Apps versus AKS is not a runtime question alone — each tier changes which knobs the platform owns and which the team has to operate. The articles name what each managed boundary actually covers, because the marketing material rarely does.
Identity is the second recurring theme. Managed Identity replaces stored credentials with Azure-attested tokens; Workload Identity Federation extends the same model to AKS and cross-tenant scenarios; conditional access enforces device and location constraints that ASP.NET Core authorization policies cannot see. Articles cover the wiring on both sides — Bicep for the role assignment, DefaultAzureCredential for the consumption — and the failure modes that show up only in production.
Cost-model articles treat consumption pricing as an architectural input. Cold-start latency in Functions, throughput units in Event Hubs, RU/s in Cosmos DB — each is a decision that shows up on the invoice before it shows up in a design review.
For container and twelve-factor patterns that apply across providers, see the cloudnative tag. This collection stays on the cloud-platform side of the line: the managed services, identities, and regional choices that only exist because a hyperscaler runs them.

Pod Identity & Access Control in AKS: What Actually Breaks

AKS Architecture & Operations — The Complete Series

AKS Network Policies: The Security Layer Your Cluster Is Missing
Network segmentation is a fundamental security control for modern Kubernetes environments. AKS supports multiple networking models such as kubenet, Azure CNI, and overlay CNIs. The networking model matters, but the decisive factor for enforcing isolation and compliance is the consistent application of network policies.
This article describes how network policies work in AKS, the available engines, practical examples, and recommended practices for enforcing a zero-trust posture within a cluster.

AKS Networking Clash: kubenet vs. CNI vs. CNI Overlay
Selecting the right network model is arguably one of the most critical architectural decisions you will make when deploying a Kubernetes cluster on Azure Kubernetes Service (AKS). This choice ripples through nearly every aspect of your cluster’s lifecycle, influencing how pods communicate, how efficiently you use your IP address space, which Azure services integrate seamlessly with your workloads, and ultimately, how well your infrastructure scales to meet future demands. It affects scalability, security posture, operational cost, performance characteristics, available integration options, and your long-term operational flexibility.