Azure Container Apps – Serverless Container Deployment & Automation

The application domain is hosted in Azure DNS and resolves to Azure Application Gateway (WAF v2) in the public subnet. The Web Application Firewall runs in Prevention mode with the Microsoft-managed Default Rule Set to block OWASP Top 10 attacks such as SQL injection and cross-site scripting, along with custom rules for rate limiting. Application Gateway terminates TLS using certificates stored in Azure Key Vault and redirects HTTP to HTTPS.

The Container Apps environment is deployed into its own dedicated subnet with internal-only ingress, so it has no public IP address. Application Gateway forwards traffic to the environment through its private address, resolved by an Azure Private DNS zone for the environment domain. Only requests that have passed the WAF can reach the application.

The API runs as a container app on the serverless Consumption profile. CPU and memory are allocated per replica, billing is per second of actual use, and there are no servers, node pools, or clusters to size, patch, or upgrade. Dedicated workload profiles can be added to the same environment for services that need reserved capacity or larger instances.

Scale rules powered by KEDA add replicas when concurrent HTTP requests, CPU, memory, or queue length cross defined thresholds, and remove them when demand falls. Background and event-driven services scale to zero replicas when idle, while latency-sensitive APIs can keep a minimum of one replica to avoid cold starts. Maximum replica limits keep costs predictable.

Each deployment creates a new, immutable revision of the container app. In multiple revision mode, traffic can be split between revisions by percentage to release a new version gradually, and revision labels provide stable test URLs before a version goes live. If a problem appears, traffic is moved back to the previous revision immediately, without rebuilding or redeploying.

Application data is stored in Azure SQL Database with public network access disabled. The app connects through a private endpoint in a separate private subnet, resolved through a private DNS zone, so database traffic never leaves the virtual network. The container app authenticates with its managed identity using Microsoft Entra authentication, removing SQL passwords entirely. Transparent data encryption protects data at rest, and automated backups provide point-in-time restore.

Container images are stored in Azure Container Registry with unique version tags. The container app pulls images using its managed identity with the AcrPull role, so no registry credentials are stored in the app or the pipeline.

Any remaining secrets, such as third-party API keys, are stored in Azure Key Vault. Container Apps secrets reference Key Vault directly and are retrieved with the app’s managed identity, then exposed to the container as environment variables or mounted files, so sensitive values never appear in images, source code, or pipeline definitions.

Source code lives in GitHub. On every merge, an Azure DevOps build pipeline runs tests, builds the container image, and pushes it to Azure Container Registry. An Azure DevOps release pipeline then updates the container app to the new image, creating a new revision, with approvals and checks before production. Pipelines authenticate to Azure through service connections that use workload identity federation, avoiding long-lived secrets.

Container console and system logs are sent to a Log Analytics workspace and queried with Kusto Query Language (KQL). Azure Monitor metrics show replica counts, requests, CPU, and memory for each app and revision. Application Insights, through OpenTelemetry instrumentation, traces requests from the API to Azure SQL and records failures and response times, and alert rules notify the team when error rates or latency rise.