{"id":405,"date":"2026-04-13T22:54:23","date_gmt":"2026-04-13T22:54:23","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-container-apps-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-containers\/"},"modified":"2026-04-13T22:54:23","modified_gmt":"2026-04-13T22:54:23","slug":"azure-container-apps-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-containers","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-container-apps-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-containers\/","title":{"rendered":"Azure Container Apps Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Containers"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Containers<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Azure Container Apps is a fully managed way to run containerized applications and jobs on Azure without needing to manage Kubernetes clusters, node pools, or underlying infrastructure.<\/p>\n\n\n\n<p>In simple terms: you bring a container image (for example, from Azure Container Registry or Docker Hub), and Azure Container Apps runs it for you with built-in HTTPS ingress, autoscaling (including scale-to-zero), traffic splitting, and observability integrations.<\/p>\n\n\n\n<p>Technically, Azure Container Apps is a managed container platform designed for modern application patterns\u2014microservices, APIs, background workers, event-driven processing, and scheduled jobs\u2014using Kubernetes-style constructs behind the scenes while exposing a simplified developer and operations experience. It integrates with key Azure services for identity, networking, secrets, monitoring, and CI\/CD.<\/p>\n\n\n\n<p>The main problem it solves is the operational overhead gap between \u201csimple container hosting\u201d and \u201cfull Kubernetes\u201d: teams want Kubernetes-like capabilities (revisions, autoscaling, service-to-service communication, secure networking) but don\u2019t want to own cluster lifecycle management, upgrades, node security patching, or platform engineering from day one.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure Container Apps?<\/h2>\n\n\n\n<p><strong>Official purpose (what it\u2019s for):<\/strong><br\/>\nAzure Container Apps is a managed service for running containerized applications and jobs with autoscaling, built-in service discovery patterns, and optional microservices capabilities. It\u2019s positioned for teams that want to deploy and operate containers without managing Kubernetes directly.<\/p>\n\n\n\n<p><strong>Core capabilities (high level):<\/strong>\n&#8211; Run containerized apps with HTTP ingress or internal-only endpoints.\n&#8211; Autoscale based on HTTP traffic and event-driven triggers (via KEDA-style scaling concepts).\n&#8211; Deploy new versions safely using revisions and traffic splitting.\n&#8211; Support background processing with \u201cjobs\u201d (for on-demand, scheduled, or event-driven tasks).\n&#8211; Integrate with Azure networking, identity, and monitoring.<\/p>\n\n\n\n<p><strong>Major components (you\u2019ll see these in Azure and the CLI):<\/strong>\n&#8211; <strong>Container Apps environment<\/strong>: The secure boundary that hosts one or more container apps (and jobs) in a specific Azure region. This is where networking and logging integration are typically configured.\n&#8211; <strong>Container app<\/strong>: The deployed workload definition (container image, CPU\/memory, ingress, scaling rules, secrets, environment variables, identity).\n&#8211; <strong>Revision<\/strong>: An immutable snapshot of your container app configuration. New deployments typically create new revisions. You can route traffic between revisions.\n&#8211; <strong>Replica<\/strong>: A running instance of a revision that can scale up\/down.\n&#8211; <strong>Ingress<\/strong>: Configuration for external or internal HTTP(S) exposure and routing.\n&#8211; <strong>Jobs<\/strong>: A workload type for run-to-completion tasks (for example, scheduled maintenance, queue processing bursts, batch-like tasks). (Verify current job trigger types in official docs if you rely on a specific trigger.)<\/p>\n\n\n\n<p><strong>Service type:<\/strong><br\/>\nPlatform-as-a-Service (PaaS) for containers (often described as \u201cserverless containers\u201d in the consumption model), with options that can align to more dedicated capacity approaches depending on environment configuration.<\/p>\n\n\n\n<p><strong>Scope and locality:<\/strong>\n&#8211; <strong>Regional<\/strong>: Container Apps environments are created in an Azure region, and the apps within run in that region.\n&#8211; <strong>Azure resource scope<\/strong>: Managed via Azure Resource Manager (ARM) in a <strong>subscription<\/strong>, within a <strong>resource group<\/strong>, with standard Azure RBAC and policies.<\/p>\n\n\n\n<p><strong>How it fits into the Azure ecosystem:<\/strong>\n&#8211; <strong>Images<\/strong>: Commonly pulled from <strong>Azure Container Registry (ACR)<\/strong> or public registries.\n&#8211; <strong>Identity<\/strong>: Uses <strong>managed identities<\/strong> to access Azure resources without storing credentials in code.\n&#8211; <strong>Secrets<\/strong>: Supports secrets at the app level, and integrates with <strong>Azure Key Vault<\/strong> patterns (implementation approach varies; verify the exact supported mechanisms in official docs for your version and scenario).\n&#8211; <strong>Observability<\/strong>: Integrates with <strong>Azure Monitor \/ Log Analytics<\/strong> for logs and metrics.\n&#8211; <strong>Networking<\/strong>: Works with Azure networking constructs and can be configured for internal-only access; environment-level networking capabilities depend on configuration and region (verify advanced networking options in official docs).<\/p>\n\n\n\n<blockquote>\n<p>Service name check: <strong>\u201cAzure Container Apps\u201d<\/strong> is the current, active product name in Azure and is not a retired service name.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure Container Apps?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster time to production<\/strong>: Avoid building and operating Kubernetes platform capabilities before the workload proves its value.<\/li>\n<li><strong>Lower platform overhead<\/strong>: Reduce cluster operations tasks (node upgrades, control plane operations, cluster add-ons).<\/li>\n<li><strong>Elastic costs<\/strong>: For spiky workloads, scaling to zero and event-driven autoscaling can reduce idle costs (subject to pricing model and environment type).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Container-native deployment<\/strong>: You deploy any Linux container image that follows OCI container standards (Windows container support should be verified in official docs; do not assume).<\/li>\n<li><strong>Revision-based releases<\/strong>: Safer rollouts with revision history and traffic splitting.<\/li>\n<li><strong>Event-driven autoscaling<\/strong>: Scale based on HTTP traffic and other triggers (depending on supported scalers).<\/li>\n<li><strong>Jobs support<\/strong>: Run-to-completion workloads without building custom schedulers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed runtime and infrastructure<\/strong>: Less cluster management than AKS.<\/li>\n<li><strong>Simplified operational model<\/strong>: Apps, revisions, replicas, and scaling rules are first-class service concepts.<\/li>\n<li><strong>Integrated logging\/metrics<\/strong>: Azure-native integration for monitoring and diagnostics.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure RBAC<\/strong>: Standard permission model for controlling who can deploy\/update apps and environments.<\/li>\n<li><strong>Managed identities<\/strong>: Reduce secret sprawl and long-lived credentials.<\/li>\n<li><strong>Network boundary<\/strong>: An environment provides a boundary for apps; you can choose external ingress or internal-only patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Autoscaling<\/strong>: Reactive scaling based on demand.<\/li>\n<li><strong>Scale-to-zero<\/strong>: For supported configurations, reduce idle compute.<\/li>\n<li><strong>Traffic management<\/strong>: Split traffic across revisions to implement canary deployments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Azure Container Apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You want <strong>container flexibility<\/strong> with <strong>PaaS simplicity<\/strong>.<\/li>\n<li>You need <strong>microservices-like deployment patterns<\/strong> without owning Kubernetes.<\/li>\n<li>You have <strong>spiky<\/strong> or <strong>event-driven<\/strong> workloads.<\/li>\n<li>You want <strong>blue\/green or canary<\/strong> deployments with revisions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose Azure Container Apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need full Kubernetes control: custom CRDs, daemonsets, host-level access, GPU scheduling, or deep networking plugins. In those cases, evaluate <strong>Azure Kubernetes Service (AKS)<\/strong>.<\/li>\n<li>You require features not exposed by Container Apps (for example, specific Kubernetes admission controllers, advanced service mesh customization).  <\/li>\n<li>You want a purely code-first \u201cfunctions-only\u201d model with minimal container ownership\u2014then <strong>Azure Functions<\/strong> may be a better fit.<\/li>\n<li>You need long-running workloads with strict, predictable reserved capacity economics and are already standardized on Kubernetes\u2014AKS or dedicated compute may be preferable.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure Container Apps used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and B2B software<\/li>\n<li>Finance (internal APIs, batch integrations, secure workloads)<\/li>\n<li>Retail\/e-commerce (APIs, promotions traffic spikes, event-driven integrations)<\/li>\n<li>Media and gaming (spiky workloads, backend APIs)<\/li>\n<li>Healthcare and life sciences (regulated environments\u2014ensure compliance mapping with your controls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Product engineering teams that want to own deployment but not clusters<\/li>\n<li>DevOps\/SRE teams supporting multiple small services<\/li>\n<li>Platform teams offering \u201ccontainer platform\u201d to developers with guardrails<\/li>\n<li>Data\/ML engineering teams packaging services as containers (model inference APIs\u2014verify performance requirements)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>REST APIs and GraphQL APIs<\/li>\n<li>Microservices<\/li>\n<li>Internal services (private ingress patterns)<\/li>\n<li>Background workers (queue consumers)<\/li>\n<li>Scheduled or on-demand jobs (maintenance, migrations, data sync)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices with API gateway + internal services<\/li>\n<li>Event-driven architectures (queue\/topic triggered processing)<\/li>\n<li>Hybrid patterns with some services in AKS and some in Container Apps<\/li>\n<li>Multi-environment SDLC (dev\/test\/prod) using separate Container Apps environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production APIs with canary releases and autoscaling<\/li>\n<li>Dev\/test sandboxes where scale-to-zero reduces idle cost<\/li>\n<li>Regional deployments with CI\/CD pipelines pushing containers to ACR and deploying to Container Apps<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic, commonly implemented use cases for <strong>Azure Container Apps<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Public HTTP API with autoscaling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need to host an API that scales with traffic spikes.<\/li>\n<li><strong>Why this fits<\/strong>: Built-in ingress and autoscaling reduce ops overhead.<\/li>\n<li><strong>Example<\/strong>: A <code>\/checkout<\/code> API scales from 0 to N replicas during promotions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Internal-only microservice behind a private boundary<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want internal services not exposed to the public internet.<\/li>\n<li><strong>Why this fits<\/strong>: Container Apps supports internal ingress patterns (environment configuration matters; verify networking prerequisites).<\/li>\n<li><strong>Example<\/strong>: An internal pricing service only accessible by other apps in the same environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Canary deployments with traffic splitting<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want low-risk rollouts.<\/li>\n<li><strong>Why this fits<\/strong>: Revisions and weighted routing enable canary.<\/li>\n<li><strong>Example<\/strong>: Route 5% of traffic to revision <code>v2<\/code> while monitoring errors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Background worker for queue processing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Work arrives intermittently; you don\u2019t want idle VMs.<\/li>\n<li><strong>Why this fits<\/strong>: Event-driven autoscaling can scale workers based on queue depth (depends on supported scalers).<\/li>\n<li><strong>Example<\/strong>: A worker scales based on messages in Azure Service Bus.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Scheduled maintenance jobs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need periodic tasks like cleanup or report generation.<\/li>\n<li><strong>Why this fits<\/strong>: Container Apps jobs can run on schedules (verify scheduling support in the jobs documentation for your region\/version).<\/li>\n<li><strong>Example<\/strong>: Nightly data cleanup job runs at 02:00.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Multi-service application (API + worker + UI)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want consistent deployment and scaling across components.<\/li>\n<li><strong>Why this fits<\/strong>: Multiple apps can share an environment, logging, and network boundary.<\/li>\n<li><strong>Example<\/strong>: Web frontend + API + async worker all deployed as separate container apps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Blue\/green releases with quick rollback<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need fast rollback without redeploying.<\/li>\n<li><strong>Why this fits<\/strong>: Keep old revision active and switch traffic back instantly.<\/li>\n<li><strong>Example<\/strong>: A faulty revision gets 0% traffic within seconds.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Partner integration webhook receiver<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: External partners call your endpoint unpredictably.<\/li>\n<li><strong>Why this fits<\/strong>: Autoscale + HTTPS ingress reduces always-on cost.<\/li>\n<li><strong>Example<\/strong>: A webhook receiver that scales to zero overnight.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) API modernization (lift-and-shift containerization)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Legacy API runs on a VM; you want containers with minimal platform rebuild.<\/li>\n<li><strong>Why this fits<\/strong>: Container Apps supports containerized workloads without Kubernetes expertise.<\/li>\n<li><strong>Example<\/strong>: Containerize a .NET\/Node service and deploy with managed ingress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Edge-adjacent regional deployments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need low latency to customers in multiple geographies.<\/li>\n<li><strong>Why this fits<\/strong>: Deploy to multiple regions with consistent configuration and CI\/CD.<\/li>\n<li><strong>Example<\/strong>: Deploy the same container app to East US and West Europe with region-specific settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Dev\/test ephemeral environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need short-lived environments for feature branches.<\/li>\n<li><strong>Why this fits<\/strong>: Infrastructure is lighter than Kubernetes clusters; scale-to-zero can reduce cost.<\/li>\n<li><strong>Example<\/strong>: Create per-PR container apps and delete them after merge.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Secure service-to-service calls using identities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want to call Azure resources without embedding secrets.<\/li>\n<li><strong>Why this fits<\/strong>: Managed identities can be assigned to apps.<\/li>\n<li><strong>Example<\/strong>: An API uses a managed identity to read from Key Vault or access Storage (verify supported auth patterns in your design).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on important, current features of <strong>Azure Container Apps<\/strong>. Availability can vary by region and by environment configuration\u2014verify in official docs for your target region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Managed environments (Container Apps environment)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a logical boundary for one or more container apps, commonly centralizing networking and logging integration.<\/li>\n<li><strong>Why it matters<\/strong>: You manage fewer moving parts and keep apps grouped by lifecycle (dev\/test\/prod).<\/li>\n<li><strong>Practical benefit<\/strong>: Consistent policy, monitoring, and network settings across many apps.<\/li>\n<li><strong>Caveats<\/strong>: Environment capabilities (for example, advanced networking) may require specific configuration at creation time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Containerized app hosting with revisions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Each configuration change can create a new revision; old revisions can remain active.<\/li>\n<li><strong>Why it matters<\/strong>: Enables controlled rollouts and quick rollbacks.<\/li>\n<li><strong>Practical benefit<\/strong>: Run A\/B testing or canary releases without standing up multiple services.<\/li>\n<li><strong>Caveats<\/strong>: Managing many active revisions can increase cost and operational complexity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Ingress (external and internal)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Exposes HTTP(S) endpoints, supports routing to revisions, and can be restricted to internal access depending on environment setup.<\/li>\n<li><strong>Why it matters<\/strong>: Most services need secure HTTP exposure without custom ingress controllers.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster publishing of APIs and web apps.<\/li>\n<li><strong>Caveats<\/strong>: Non-HTTP protocols may require alternative approaches (verify supported transports and options).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Autoscaling (including scale-to-zero)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Scales replicas based on demand; can scale to zero for supported configurations.<\/li>\n<li><strong>Why it matters<\/strong>: Avoid paying for idle capacity and handle bursts automatically.<\/li>\n<li><strong>Practical benefit<\/strong>: Good for spiky APIs and event-driven workloads.<\/li>\n<li><strong>Caveats<\/strong>: Cold-start latency can exist when scaling from zero; design with retries\/timeouts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Event-driven scaling rules (KEDA-style)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses triggers (for example, queue depth) to scale workloads.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents over-provisioning and improves responsiveness to event streams.<\/li>\n<li><strong>Practical benefit<\/strong>: Workers scale with backlog automatically.<\/li>\n<li><strong>Caveats<\/strong>: Supported scalers and configuration details vary; always validate with the official list of supported scalers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Jobs (run-to-completion workloads)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Runs containers as jobs rather than long-lived services.<\/li>\n<li><strong>Why it matters<\/strong>: Many production workloads are batch-like or scheduled, not HTTP services.<\/li>\n<li><strong>Practical benefit<\/strong>: Less custom orchestration for periodic tasks.<\/li>\n<li><strong>Caveats<\/strong>: Understand retry semantics, concurrency, and trigger types from the jobs documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets and configuration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Store secrets at the container app level and reference them as environment variables.<\/li>\n<li><strong>Why it matters<\/strong>: Keeps sensitive values out of images and code.<\/li>\n<li><strong>Practical benefit<\/strong>: Centralized secret updates without rebuilding images.<\/li>\n<li><strong>Caveats<\/strong>: Secret rotation and Key Vault integration patterns must be designed carefully; do not assume automatic rotation unless documented.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Managed identities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Assigns an Azure identity to the container app to access other Azure resources.<\/li>\n<li><strong>Why it matters<\/strong>: Eliminates static credentials and reduces credential leakage risks.<\/li>\n<li><strong>Practical benefit<\/strong>: Secure access to ACR, Key Vault, Storage, Service Bus, and more.<\/li>\n<li><strong>Caveats<\/strong>: Requires correct RBAC roles and sometimes resource-specific access policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Observability (logs and metrics via Azure Monitor)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Sends logs to Log Analytics and emits metrics for scaling and health.<\/li>\n<li><strong>Why it matters<\/strong>: Operations depends on visibility: errors, latency, scaling, restarts.<\/li>\n<li><strong>Practical benefit<\/strong>: Central queryable logs with Kusto Query Language (KQL).<\/li>\n<li><strong>Caveats<\/strong>: Log Analytics ingestion and retention cost money.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Traffic splitting between revisions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Weighted routing between revisions.<\/li>\n<li><strong>Why it matters<\/strong>: Enables safe progressive delivery.<\/li>\n<li><strong>Practical benefit<\/strong>: Canary, blue\/green, and quick rollback patterns.<\/li>\n<li><strong>Caveats<\/strong>: Requires good monitoring to decide when to shift traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Container registry integration (including private images)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Pull images from registries like ACR.<\/li>\n<li><strong>Why it matters<\/strong>: Production workloads use private images.<\/li>\n<li><strong>Practical benefit<\/strong>: Secure supply chain and image governance.<\/li>\n<li><strong>Caveats<\/strong>: Requires correct auth (managed identity recommended) and network access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Optional microservices building blocks (Dapr integration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports Dapr patterns (service invocation, pub\/sub, state stores) when enabled and configured.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces boilerplate for distributed systems.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster microservices development.<\/li>\n<li><strong>Caveats<\/strong>: Dapr adds complexity; use only if you need it. Verify current Dapr feature support in Container Apps docs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>At a high level:\n&#8211; You create a <strong>Container Apps environment<\/strong> in a region.\n&#8211; You deploy one or more <strong>container apps<\/strong> into that environment.\n&#8211; Each app can have <strong>ingress<\/strong>, <strong>revisions<\/strong>, and <strong>scaling rules<\/strong>.\n&#8211; Logs typically flow to <strong>Log Analytics<\/strong>.\n&#8211; Container images are pulled from a registry (often <strong>ACR<\/strong>).\n&#8211; Access to Azure resources uses <strong>managed identities<\/strong> and <strong>Azure RBAC<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request flow (HTTP service)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Client sends HTTPS request to the Container Apps app endpoint.<\/li>\n<li>Ingress routes traffic to the active revision(s) based on weights.<\/li>\n<li>The platform scales replicas based on rules (HTTP concurrency, CPU, or event triggers).<\/li>\n<li>App writes logs to stdout\/stderr (captured by platform).<\/li>\n<li>Logs are shipped to Log Analytics for querying and alerting.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Data\/control flow (deployment)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>CI\/CD pipeline builds an image and pushes to ACR.<\/li>\n<li>Deployment updates the Container App configuration to reference the new image tag\/digest.<\/li>\n<li>A new revision is created (depending on configuration).<\/li>\n<li>Traffic is shifted gradually (or immediately) to the new revision.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related Azure services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Azure Container Registry (ACR)<\/strong>: private image hosting.\n&#8211; <strong>Azure Monitor \/ Log Analytics<\/strong>: logs and diagnostics.\n&#8211; <strong>Azure Key Vault<\/strong>: secrets management patterns (verify exact supported integration mechanism).\n&#8211; <strong>Azure Virtual Network (VNet)<\/strong>: internal ingress and controlled egress depending on environment configuration.\n&#8211; <strong>Azure DevOps \/ GitHub Actions<\/strong>: CI\/CD pipelines.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Log Analytics workspace<\/strong> is commonly used for logs (and is used by many quickstarts).<\/li>\n<li><strong>ACR<\/strong> is commonly required for private images.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Management plane<\/strong>: Azure RBAC controls who can create\/update environments and apps.<\/li>\n<li><strong>Data plane<\/strong>:<\/li>\n<li>Ingress can be public or internal.<\/li>\n<li>App-to-Azure-resource access is typically via managed identity + RBAC.<\/li>\n<li>Secrets are stored in the app configuration and injected at runtime.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (practical view)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You choose whether your app has <strong>external ingress<\/strong> (public endpoint) or <strong>internal<\/strong>.<\/li>\n<li>Environment-level networking decisions can affect whether apps can be private-only and how they access internal resources.<\/li>\n<li>Outbound connectivity (egress) exists for typical scenarios (calling APIs, databases). For strict egress control, validate environment networking features in the official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Log Analytics for centralized logs, queries, alerting.<\/li>\n<li>Standardize tags, naming, and resource group layout.<\/li>\n<li>Use Azure Policy to enforce allowed SKUs\/regions, required tags, and private networking requirements (where applicable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User \/ Client] --&gt;|HTTPS| CA[Azure Container Apps&lt;br\/&gt;Container App (Ingress)]\n  CA --&gt; R[Active Revision]\n  R --&gt; L[Logs\/Metrics]\n  L --&gt; LA[Azure Monitor&lt;br\/&gt;Log Analytics]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Internet\n    C[Clients]\n  end\n\n  subgraph Azure[\"Azure Subscription\"]\n    subgraph RG[\"Resource Group\"]\n      subgraph ENV[\"Azure Container Apps Environment (Region)\"]\n        GW[Ingress \/ Routing]\n        API[Container App: API Service]\n        WRK[Container App: Worker Service]\n        J[Container Apps Job: Nightly Maintenance]\n      end\n\n      ACR[Azure Container Registry]\n      LA[Log Analytics Workspace]\n      KV[Azure Key Vault]\n      SB[Azure Service Bus]\n    end\n  end\n\n  C --&gt;|HTTPS| GW --&gt; API\n  API --&gt;|enqueue| SB\n  SB --&gt;|trigger\/scale| WRK\n  API --&gt;|pull image| ACR\n  WRK --&gt;|pull image| ACR\n  J --&gt;|scheduled run| KV\n\n  API --&gt;|logs| LA\n  WRK --&gt;|logs| LA\n  J --&gt;|logs| LA\n\n  API --&gt;|secrets\/keys| KV\n  WRK --&gt;|secrets\/keys| KV\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before starting the hands-on lab, make sure you have the following.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Azure account and subscription<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Azure subscription<\/strong> with billing enabled.<\/li>\n<li>Ability to create resources in a resource group.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>At minimum, for the target subscription or resource group:\n&#8211; <strong>Contributor<\/strong> (or equivalent) to create:\n  &#8211; Resource group\n  &#8211; Log Analytics workspace\n  &#8211; Container Apps environment and container apps\n&#8211; If using ACR with private images, you also need permissions to create ACR and assign roles (for example, <strong>AcrPull<\/strong> to the managed identity you use).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Container Apps, Log Analytics ingestion\/retention, and any registry\/network usage will incur cost.<\/li>\n<li>To keep the lab low-cost, prefer:<\/li>\n<li>Consumption-style configuration where feasible<\/li>\n<li>A public sample image (no ACR build required)<\/li>\n<li>Scale-to-zero or low min replicas<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure CLI<\/strong> (latest available recommended): https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<\/li>\n<li>Container Apps CLI support:<\/li>\n<li>Run <code>az extension add --name containerapp --upgrade<\/code> (if commands are already built-in for your CLI version, this will either succeed or indicate it\u2019s already present).<\/li>\n<li><code>curl<\/code> (or a browser) to test the endpoint.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Container Apps is regional; not every feature is available in every region.<\/li>\n<li>Choose a region where Container Apps is supported and where your organization allows deployments.<\/li>\n<li>Verify regional availability in official docs for features like advanced networking or specific scaling triggers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>There are quotas\/limits for environments, apps, revisions, and scaling.<br\/>\n  Verify current values in official docs: https:\/\/learn.microsoft.com\/azure\/container-apps\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For this tutorial, you will create:\n&#8211; Resource group\n&#8211; Log Analytics workspace\n&#8211; Container Apps environment\n&#8211; Container App<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Azure Container Apps is billed using a usage-based model, with important differences depending on how your environment is configured. Pricing varies by region and can change; always confirm using official sources.<\/p>\n\n\n\n<p><strong>Official pricing page:<\/strong><br\/>\nhttps:\/\/azure.microsoft.com\/pricing\/details\/container-apps\/<\/p>\n\n\n\n<p><strong>Azure Pricing Calculator:<\/strong><br\/>\nhttps:\/\/azure.microsoft.com\/pricing\/calculator\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>Common cost dimensions include (verify exact meters on the pricing page for your region):\n&#8211; <strong>Compute usage<\/strong>: vCPU and memory consumption over time (often billed in vCPU-seconds and GiB-seconds).\n&#8211; <strong>Requests<\/strong>: In some models, HTTP requests may be a billable dimension.\n&#8211; <strong>Provisioned\/dedicated capacity (if using dedicated\/workload profile style environments)<\/strong>: You may pay for allocated capacity regardless of utilization.\n&#8211; <strong>Observability<\/strong>:\n  &#8211; <strong>Log Analytics ingestion<\/strong> (GB ingested)\n  &#8211; Retention beyond included retention period\n&#8211; <strong>Container registry<\/strong> (if using ACR):\n  &#8211; Storage (GB-month)\n  &#8211; Operations (push\/pull)\n  &#8211; Network egress\n&#8211; <strong>Networking<\/strong>:\n  &#8211; Data transfer (egress) out of Azure or across regions\n  &#8211; NAT gateway, firewall, private networking components (if used)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier \/ free grant<\/h3>\n\n\n\n<p>Azure Container Apps pricing typically includes some form of <strong>monthly free grant<\/strong> in the consumption model (amounts and eligibility can vary).<br\/>\nDo not rely on memory\u2014verify the exact free grant on the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what increases your bill)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keeping <strong>minimum replicas<\/strong> &gt; 0 for many apps.<\/li>\n<li>Running <strong>multiple active revisions<\/strong> with non-zero traffic or replicas.<\/li>\n<li>High <strong>request volume<\/strong> and high <strong>CPU\/memory<\/strong> usage.<\/li>\n<li>High <strong>log volume<\/strong> (chatty logs can dominate total cost).<\/li>\n<li>Pulling large images frequently (inefficient CI\/CD patterns).<\/li>\n<li>Cross-region calls and outbound internet egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Log Analytics<\/strong> can become a top cost item if you ingest large volumes and keep long retention.<\/li>\n<li><strong>CI\/CD<\/strong> build infrastructure (GitHub Actions runners, Azure DevOps agents) and ACR build tasks.<\/li>\n<li>Network security controls (Azure Firewall, NAT Gateway) if you need controlled egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ingress data is generally not the main cost driver, but <strong>egress<\/strong> out of Azure is commonly billable.<\/li>\n<li>Cross-region calls (for example, app in Region A calling a database in Region B) can add both latency and cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>scale-to-zero<\/strong> where acceptable; set low max replicas initially.<\/li>\n<li>Keep <strong>min replicas<\/strong> low (often 0 or 1 depending on latency SLO).<\/li>\n<li>Reduce log ingestion:<\/li>\n<li>Log at INFO sparingly in production<\/li>\n<li>Use sampling for high-volume endpoints<\/li>\n<li>Route structured logs and tune verbosity<\/li>\n<li>Prefer <strong>image digests<\/strong> and consistent tags; avoid re-pulling large layers unnecessarily.<\/li>\n<li>Right-size CPU\/memory; measure and adjust.<\/li>\n<li>Use canary carefully: too many active revisions can double compute.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A typical lab or small dev API might cost mainly:\n&#8211; Container Apps compute (often near-zero if scaled to zero most of the time)\n&#8211; Log Analytics ingestion (small but non-zero)\n&#8211; Minimal data egress<\/p>\n\n\n\n<p>Because prices vary by region and change over time, use the Pricing Calculator with:\n&#8211; One container app\n&#8211; Low CPU\/memory\n&#8211; Low request volume\n&#8211; Minimal log ingestion and short retention<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations (conceptual)<\/h3>\n\n\n\n<p>For production:\n&#8211; Plan for baseline replicas (to reduce cold starts) and higher compute.\n&#8211; Include logging\/monitoring budgets and retention.\n&#8211; Consider dedicated capacity approaches if you require predictable performance and spend (verify if a dedicated\/workload profile environment matches your needs).\n&#8211; Add cost for private images (ACR), network controls, and multi-region deployments.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab deploys a real container app using a public Microsoft sample image, configures ingress and scaling, demonstrates revisions, and shows how to query logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy a public \u201chello world\u201d container image to <strong>Azure Container Apps<\/strong>, expose it via HTTPS, configure autoscaling, create a new revision with a configuration change, and validate logs\u2014then clean up safely.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare Azure CLI and register providers.\n2. Create a resource group and Log Analytics workspace.\n3. Create a Container Apps environment.\n4. Deploy a container app with external ingress.\n5. Update configuration to create a new revision and split traffic (basic canary).\n6. Validate the endpoint and query logs.\n7. Clean up all resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Prepare your terminal and Azure CLI<\/h3>\n\n\n\n<p>1) Install or update Azure CLI:\n&#8211; https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<\/p>\n\n\n\n<p>2) Sign in and select a subscription:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az login\naz account show\naz account set --subscription \"&lt;SUBSCRIPTION_ID_OR_NAME&gt;\"\n<\/code><\/pre>\n\n\n\n<p>3) Ensure Container Apps CLI support is available:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az extension add --name containerapp --upgrade\n<\/code><\/pre>\n\n\n\n<p>4) Register required resource providers (safe to run even if already registered):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az provider register --namespace Microsoft.App\naz provider register --namespace Microsoft.OperationalInsights\naz provider register --namespace Microsoft.Insights\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Providers register in the background. It can take a few minutes.<\/p>\n\n\n\n<p>Optional: confirm registration state:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az provider show --namespace Microsoft.App --query \"registrationState\" -o tsv\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Set variables for repeatability<\/h3>\n\n\n\n<p>Choose a region that supports Azure Container Apps in your subscription.<\/p>\n\n\n\n<pre><code class=\"language-bash\">LOCATION=\"eastus\"\nRG=\"rg-aca-lab\"\nLAW=\"lawAcaLab$RANDOM\"\nENV=\"aca-env-lab\"\nAPP=\"aca-hello\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have consistent names to copy\/paste for later steps.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a resource group<\/h3>\n\n\n\n<pre><code class=\"language-bash\">az group create --name \"$RG\" --location \"$LOCATION\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A resource group is created.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group show --name \"$RG\" --query \"{name:name, location:location}\" -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Log Analytics workspace<\/h3>\n\n\n\n<p>Container Apps commonly integrates with Log Analytics for logs.<\/p>\n\n\n\n<pre><code class=\"language-bash\">az monitor log-analytics workspace create \\\n  --resource-group \"$RG\" \\\n  --workspace-name \"$LAW\" \\\n  --location \"$LOCATION\"\n<\/code><\/pre>\n\n\n\n<p>Fetch the workspace ID and shared key (needed for environment creation in many workflows):<\/p>\n\n\n\n<pre><code class=\"language-bash\">LAW_ID=$(az monitor log-analytics workspace show \\\n  --resource-group \"$RG\" \\\n  --workspace-name \"$LAW\" \\\n  --query customerId -o tsv)\n\nLAW_KEY=$(az monitor log-analytics workspace get-shared-keys \\\n  --resource-group \"$RG\" \\\n  --workspace-name \"$LAW\" \\\n  --query primarySharedKey -o tsv)\n\necho \"$LAW_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Workspace exists, and you have its ID and key.<\/p>\n\n\n\n<blockquote>\n<p>Cost note: Log Analytics ingestion and retention can incur cost. Keep the lab short and clean up at the end.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create an Azure Container Apps environment<\/h3>\n\n\n\n<p>Create an environment and connect it to Log Analytics.<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp env create \\\n  --name \"$ENV\" \\\n  --resource-group \"$RG\" \\\n  --location \"$LOCATION\" \\\n  --logs-workspace-id \"$LAW_ID\" \\\n  --logs-workspace-key \"$LAW_KEY\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The environment is created.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp env show \\\n  --name \"$ENV\" \\\n  --resource-group \"$RG\" \\\n  --query \"{name:name, location:location, provisioningState:provisioningState}\" -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Deploy a container app with external ingress<\/h3>\n\n\n\n<p>Deploy a sample image from Microsoft Container Registry (public).<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp create \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --environment \"$ENV\" \\\n  --image \"mcr.microsoft.com\/azuredocs\/containerapps-helloworld:latest\" \\\n  --target-port 80 \\\n  --ingress external \\\n  --query properties.configuration.ingress.fqdn -o tsv\n<\/code><\/pre>\n\n\n\n<p>Store the FQDN:<\/p>\n\n\n\n<pre><code class=\"language-bash\">FQDN=$(az containerapp show \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --query properties.configuration.ingress.fqdn -o tsv)\n\necho \"https:\/\/$FQDN\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You get a public HTTPS endpoint.<\/p>\n\n\n\n<p>Verify by calling the endpoint:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"https:\/\/$FQDN\"\n<\/code><\/pre>\n\n\n\n<p>You should see an HTTP status code (often <code>200 OK<\/code>) and response content from the sample app.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Configure autoscaling (basic HTTP scaling)<\/h3>\n\n\n\n<p>Container Apps supports scaling rules; a simple one is scaling based on HTTP concurrency.<\/p>\n\n\n\n<p>Set min replicas to 0 (scale-to-zero) and max to 3 for the lab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp update \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --min-replicas 0 \\\n  --max-replicas 3\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The app can scale down when idle (depending on platform behavior and configuration) and scale out under load.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp show \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --query \"properties.template.scale\" -o json\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Note: Exact autoscaling knobs and supported rules vary. For production scaling design, validate supported scalers and rule syntax in official docs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a secret and a new revision (configuration change)<\/h3>\n\n\n\n<p>You\u2019ll add a secret and an environment variable referencing it. Even if the sample image doesn\u2019t use it, this shows the workflow.<\/p>\n\n\n\n<p>1) Set a secret:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp secret set \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --secrets \"apiKey=SuperSecretValue123\"\n<\/code><\/pre>\n\n\n\n<p>2) Update the app to add an environment variable from the secret:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp update \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --set-env-vars \"API_KEY=secretref:apiKey\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A new revision is created (typical behavior when configuration changes). The app runs with <code>API_KEY<\/code> set at runtime.<\/p>\n\n\n\n<p>List revisions:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp revision list \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Demonstrate traffic splitting (basic canary)<\/h3>\n\n\n\n<p>If you have at least two revisions, you can split traffic. The exact revision names are shown in the revision list.<\/p>\n\n\n\n<p>1) Capture the latest two revision names:<\/p>\n\n\n\n<pre><code class=\"language-bash\">REVS=($(az containerapp revision list \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --query \"[].name\" -o tsv))\n\necho \"Revisions:\"\nprintf '%s\\n' \"${REVS[@]}\"\n<\/code><\/pre>\n\n\n\n<p>If you see two revisions, pick them as:\n&#8211; <code>REV_OLD<\/code> = first revision\n&#8211; <code>REV_NEW<\/code> = second revision<\/p>\n\n\n\n<blockquote>\n<p>If the ordering is not what you expect, use <code>az containerapp revision list ... --query<\/code> to inspect properties and pick explicitly.<\/p>\n<\/blockquote>\n\n\n\n<p>2) Example traffic split (adjust revision names):<\/p>\n\n\n\n<pre><code class=\"language-bash\">REV_OLD=\"${REVS[0]}\"\nREV_NEW=\"${REVS[1]}\"\n\naz containerapp ingress traffic set \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --revision-weight \"$REV_OLD=80\" \"$REV_NEW=20\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> 80% of traffic goes to the older revision and 20% to the newer revision.<\/p>\n\n\n\n<p>Verify traffic weights:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp show \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --query \"properties.configuration.ingress.traffic\" -o json\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: View logs (Log Analytics and CLI)<\/h3>\n\n\n\n<p>For quick inspection, use built-in log streaming:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp logs show \\\n  --name \"$APP\" \\\n  --resource-group \"$RG\" \\\n  --follow\n<\/code><\/pre>\n\n\n\n<p>Stop following with <code>Ctrl+C<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see application logs (stdout\/stderr) for active replicas.<\/p>\n\n\n\n<p>For deeper analysis, query Log Analytics in the Azure portal or via <code>az monitor log-analytics query<\/code> (requires knowing the appropriate tables and schema). The table names and fields can change; verify in your workspace\u2019s \u201cLogs\u201d blade and official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use the following checks:<\/p>\n\n\n\n<p>1) Endpoint responds:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -sS \"https:\/\/$FQDN\" | head\n<\/code><\/pre>\n\n\n\n<p>2) App is provisioned:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp show --name \"$APP\" --resource-group \"$RG\" \\\n  --query \"{name:name, state:properties.runningStatus, fqdn:properties.configuration.ingress.fqdn}\" -o table\n<\/code><\/pre>\n\n\n\n<p>3) Revisions exist:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp revision list --name \"$APP\" --resource-group \"$RG\" -o table\n<\/code><\/pre>\n\n\n\n<p>4) Traffic split configured (if you performed it):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az containerapp show --name \"$APP\" --resource-group \"$RG\" \\\n  --query \"properties.configuration.ingress.traffic\" -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>az: 'containerapp' is not in the 'az' command group<\/code><\/strong><\/li>\n<li>\n<p>Install\/upgrade the extension:\n    <code>bash\n    az extension add --name containerapp --upgrade<\/code><\/p>\n<\/li>\n<li>\n<p><strong>Provider not registered \/ deployment fails<\/strong><\/p>\n<\/li>\n<li>Register providers and wait a few minutes:\n    <code>bash\n    az provider register --namespace Microsoft.App\n    az provider register --namespace Microsoft.OperationalInsights<\/code><\/li>\n<li>\n<p>Re-run the create command after registration completes.<\/p>\n<\/li>\n<li>\n<p><strong>Log Analytics workspace key retrieval fails<\/strong><\/p>\n<\/li>\n<li>Confirm you have permission on the workspace\/resource group.<\/li>\n<li>\n<p>Ensure the workspace exists in the same subscription context.<\/p>\n<\/li>\n<li>\n<p><strong>Ingress URL not reachable<\/strong><\/p>\n<\/li>\n<li>Confirm <code>--ingress external<\/code> was used.<\/li>\n<li>Check the FQDN:\n    <code>bash\n    az containerapp show --name \"$APP\" --resource-group \"$RG\" \\\n      --query properties.configuration.ingress.fqdn -o tsv<\/code><\/li>\n<li>\n<p>Wait a minute after deployment; DNS and routing can take time.<\/p>\n<\/li>\n<li>\n<p><strong>Revisions not appearing<\/strong><\/p>\n<\/li>\n<li>Some updates may not create a new revision depending on which properties changed and revision mode. Verify revision settings in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the entire resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete --name \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> All resources created in the lab (Container Apps environment, container app, Log Analytics workspace) are deleted.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use separate environments for dev\/test\/prod<\/strong> to isolate networking, logging, and blast radius.<\/li>\n<li><strong>Separate apps by trust boundary<\/strong>: do not mix public internet-facing apps with highly sensitive internal apps in the same environment unless your controls and policies allow it.<\/li>\n<li><strong>Design for statelessness<\/strong>: store state in managed services (Azure SQL, Cosmos DB, Storage, Redis). Containers should be replaceable.<\/li>\n<li><strong>Use managed identities<\/strong> for Azure resource access and minimize secrets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apply <strong>least privilege<\/strong>:<\/li>\n<li>Restrict who can create\/update environments and apps.<\/li>\n<li>Use resource-group-scoped RBAC where possible.<\/li>\n<li>Prefer <strong>managed identities<\/strong> over registry passwords and connection strings.<\/li>\n<li>Restrict ingress:<\/li>\n<li>Use internal ingress for internal services.<\/li>\n<li>Add additional gateway\/WAF controls for public endpoints (for example, front with Azure Front Door or Application Gateway where appropriate\u2014verify best-fit for your scenario).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Set <strong>min replicas = 0<\/strong> for dev\/test or low-SLO services (accept cold starts).<\/li>\n<li>Avoid keeping many <strong>active revisions<\/strong> if not needed.<\/li>\n<li>Control <strong>Log Analytics<\/strong> ingestion:<\/li>\n<li>Reduce verbosity<\/li>\n<li>Set sensible retention<\/li>\n<li>Use alerts to detect log spikes<\/li>\n<li>Use the Azure Pricing Calculator and track cost by tags.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size CPU\/memory based on load testing.<\/li>\n<li>Reduce cold starts by setting <strong>min replicas<\/strong> to 1 for latency-sensitive APIs.<\/li>\n<li>Tune timeouts and retries for upstream dependencies, especially when scale-to-zero is enabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Implement health endpoints and graceful shutdown in your container.<\/li>\n<li>Use revision-based rollouts with canary traffic splitting.<\/li>\n<li>Build idempotent workers (retries happen).<\/li>\n<li>Use multi-region deployment for high availability if required (requires additional design and data replication strategy).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize:<\/li>\n<li>Naming conventions (rg-<em>, aca-env-<\/em>, app-*).<\/li>\n<li>Tagging (env, owner, costCenter, dataClassification).<\/li>\n<li>Implement CI\/CD:<\/li>\n<li>Build images with pinned base images and vulnerability scanning.<\/li>\n<li>Deploy using immutable tags or digests.<\/li>\n<li>Define runbooks:<\/li>\n<li>Rollback using traffic weights.<\/li>\n<li>Incident response using logs and metrics.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce tags with Azure Policy.<\/li>\n<li>Use separate subscriptions or management groups for prod vs non-prod when mature.<\/li>\n<li>Track resource ownership and lifecycle for cleanup.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Management plane<\/strong>: Azure RBAC controls who can manage Container Apps resources.<\/li>\n<li><strong>Workload identity<\/strong>:<\/li>\n<li>Use <strong>system-assigned<\/strong> or <strong>user-assigned managed identities<\/strong> for apps.<\/li>\n<li>Assign least-privilege roles (for example, <code>AcrPull<\/code> on ACR, read secrets from Key Vault using the appropriate model).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data in transit: HTTPS ingress (TLS) for external endpoints.<\/li>\n<li>Data at rest:<\/li>\n<li>Logs stored in Log Analytics are encrypted at rest under Azure\u2019s platform controls.<\/li>\n<li>Secrets are stored as part of the app configuration; design as if compromise of the app config is a risk and limit access accordingly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>internal-only<\/strong> ingress for back-end services.<\/li>\n<li>For internet-facing apps:<\/li>\n<li>Consider placing a WAF in front (Front Door\/App Gateway) depending on requirements.<\/li>\n<li>Restrict allowed origins and implement authn\/authz at the app layer.<\/li>\n<li>Validate environment networking settings early\u2014some network decisions are difficult to change later.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use secrets only when necessary; prefer managed identity.<\/li>\n<li>Never bake secrets into container images.<\/li>\n<li>Rotate secrets regularly and automate rotations where possible (implementation depends on your chosen secrets approach; verify Key Vault integration patterns).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Azure Activity Log for management operations auditing.<\/li>\n<li>Centralize logs and use alerts for:<\/li>\n<li>Auth failures<\/li>\n<li>Unexpected scale-outs<\/li>\n<li>Error rate spikes<\/li>\n<li>Avoid logging secrets or PII.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm region, data residency, logging retention, and access controls align to your policies.<\/li>\n<li>Map controls (identity, logging, network) to your compliance framework (ISO, SOC, PCI, HIPAA). Azure provides compliance documentation, but you still own configuration and operational controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Exposing internal services publicly with external ingress.<\/li>\n<li>Using registry admin credentials instead of managed identities.<\/li>\n<li>Over-permissive RBAC at subscription scope.<\/li>\n<li>Logging sensitive data to Log Analytics.<\/li>\n<li>Not controlling outbound access for sensitive workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use private images in ACR with managed identity-based pulls.<\/li>\n<li>Use internal ingress for internal APIs.<\/li>\n<li>Add WAF and DDoS protections where required (service choice depends on architecture).<\/li>\n<li>Use signed images and vulnerability scanning in CI\/CD (tooling choice varies).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Azure Container Apps is designed to simplify operations, but that means some constraints compared to raw Kubernetes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Not full Kubernetes<\/strong>: You don\u2019t get direct access to Kubernetes API objects, custom controllers, or node-level tuning.<\/li>\n<li><strong>Protocol expectations<\/strong>: The most straightforward path is HTTP-based services. Non-HTTP workloads may require additional validation and potentially different services.<\/li>\n<li><strong>Feature availability varies<\/strong> by region and environment configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>There are quotas for number of apps\/environments\/revisions\/replicas and resource sizing.<\/li>\n<li>Verify current quota values and how to request increases in official docs:<\/li>\n<li>https:\/\/learn.microsoft.com\/azure\/container-apps\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all regions support all capabilities (especially newer features).<\/li>\n<li>Plan region selection early and confirm compliance requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Log Analytics<\/strong> is often the surprise cost.<\/li>\n<li>Running many active revisions or non-zero min replicas increases compute charges.<\/li>\n<li>Data egress costs can be significant for chatty external dependencies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Containers must be built correctly (listen on the expected port, write logs to stdout\/stderr, handle SIGTERM for graceful shutdown).<\/li>\n<li>If you depend on privileged containers, host-level mounts, or custom kernel features, validate support\u2014many PaaS container services restrict these.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Scale-to-zero can introduce cold-start latency.<\/li>\n<li>Revision sprawl can make troubleshooting confusing; keep revision naming and rollout discipline.<\/li>\n<li>Debugging \u201cit works locally but not in Container Apps\u201d often comes down to:<\/li>\n<li>Wrong target port<\/li>\n<li>Missing environment variables<\/li>\n<li>Network restrictions (internal-only services)<\/li>\n<li>Missing RBAC for managed identity<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Teams moving from AKS might assume they can reproduce every Kubernetes pattern; Container Apps is intentionally opinionated.<\/li>\n<li>Teams moving from App Service might underestimate container operational needs (image updates, base image patching, vulnerability management).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some operational tasks are done differently than Kubernetes (for example, you manage revisions\/traffic rather than Kubernetes deployments\/services).<\/li>\n<li>Always validate CLI and API versions; commands and behaviors evolve.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure offers multiple container-related options, and other clouds have similar managed container platforms. The best choice depends on control requirements, operational maturity, and workload shape.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Azure Container Apps<\/strong><\/td>\n<td>APIs, microservices, workers, jobs without managing clusters<\/td>\n<td>Autoscaling incl. scale-to-zero, revisions &amp; traffic splitting, managed experience<\/td>\n<td>Less control than AKS; feature set differs from raw Kubernetes<\/td>\n<td>You want Kubernetes-like patterns with PaaS simplicity<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Kubernetes Service (AKS)<\/strong><\/td>\n<td>Full Kubernetes control and complex platforms<\/td>\n<td>Maximum control, ecosystem compatibility, advanced networking\/service mesh options<\/td>\n<td>Higher ops burden (upgrades, node pools, governance)<\/td>\n<td>You need Kubernetes API access, CRDs, custom networking, or platform standardization<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure App Service (Web App for Containers)<\/strong><\/td>\n<td>Web apps\/APIs with simpler hosting model<\/td>\n<td>Strong App Service ecosystem, deployment slots, easy SSL\/custom domains<\/td>\n<td>Less flexible for event-driven scaling; container orchestration features limited<\/td>\n<td>You mainly host HTTP web apps and prefer App Service features<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Functions (custom container)<\/strong><\/td>\n<td>Event-driven functions with minimal infra<\/td>\n<td>Serverless triggers, pay-per-execution patterns (model-dependent), quick integration<\/td>\n<td>Function runtime constraints; not always ideal for long-lived services<\/td>\n<td>Workload is function-shaped and integrates with triggers well<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Container Instances (ACI)<\/strong><\/td>\n<td>Simple, single-container execution without orchestration<\/td>\n<td>Quick start, straightforward, good for bursty tasks<\/td>\n<td>Limited orchestration, scaling, traffic management<\/td>\n<td>You need \u201crun a container now\u201d simplicity, not a microservices platform<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS App Runner<\/strong><\/td>\n<td>Managed web apps from containers\/source<\/td>\n<td>Simple deployment, managed scaling<\/td>\n<td>AWS-specific; feature differences vs Azure<\/td>\n<td>You\u2019re on AWS and want similar simplicity for web apps<\/td>\n<\/tr>\n<tr>\n<td><strong>Amazon ECS on Fargate<\/strong><\/td>\n<td>Managed containers with more control<\/td>\n<td>Strong orchestration, AWS ecosystem<\/td>\n<td>More configuration than App Runner\/Container Apps<\/td>\n<td>You want managed containers with more knobs on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Run<\/strong><\/td>\n<td>Serverless HTTP containers<\/td>\n<td>Excellent scale-to-zero, simple deployment<\/td>\n<td>GCP-specific; feature differences<\/td>\n<td>You want serverless HTTP containers on GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed Kubernetes (anywhere)<\/strong><\/td>\n<td>Maximum portability\/control<\/td>\n<td>Full control, consistent across environments<\/td>\n<td>Highest ops overhead<\/td>\n<td>You must run on-prem\/hybrid with full control and have platform maturity<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: internal microservices platform for line-of-business APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A large enterprise has dozens of small internal APIs maintained by different teams. They want consistent deployment, autoscaling, secure internal access, and centralized logging without every team running Kubernetes clusters.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>One Container Apps environment per environment tier (dev\/test\/prod) per region.<\/li>\n<li>Internal-only ingress for most services; a single controlled entrypoint (API gateway\/WAF layer) for public exposure where needed.<\/li>\n<li>ACR for private images; managed identities for ACR pulls and Key Vault access.<\/li>\n<li>Azure Monitor \/ Log Analytics with standardized dashboards and alerts.<\/li>\n<li><strong>Why Azure Container Apps was chosen<\/strong>:<\/li>\n<li>Reduces Kubernetes operations burden while keeping revision-based releases and autoscaling.<\/li>\n<li>Fits microservices rollout patterns without platform team overhead of AKS clusters for every department.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster onboarding for new services<\/li>\n<li>Improved release safety via revisions and traffic splitting<\/li>\n<li>Lower idle cost for low-traffic internal services (with scale-to-zero where acceptable)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS API + worker with event-driven scaling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup runs a SaaS backend with an API and an asynchronous worker that processes tasks from a queue. Load is unpredictable, and the team is small.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>API in Azure Container Apps with external ingress.<\/li>\n<li>Worker in Azure Container Apps scaled by queue depth (validate supported scaler for your chosen queue).<\/li>\n<li>Azure Service Bus or Storage Queue for async tasks.<\/li>\n<li>Azure Monitor logs for debugging incidents.<\/li>\n<li><strong>Why Azure Container Apps was chosen<\/strong>:<\/li>\n<li>Simple operations: no Kubernetes cluster management.<\/li>\n<li>Autoscaling handles spikes without constant overprovisioning.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Reduced operational burden and faster iteration<\/li>\n<li>Lower costs during low usage periods<\/li>\n<li>Clear path to canary deploys as the product matures<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Azure Container Apps the same as AKS?<\/strong><br\/>\nNo. Azure Container Apps is a managed container platform that abstracts Kubernetes operations. AKS is managed Kubernetes where you still manage cluster-level concerns (node pools, upgrades, add-ons).<\/p>\n\n\n\n<p>2) <strong>Do I need to know Kubernetes to use Azure Container Apps?<\/strong><br\/>\nNot strictly. Understanding containers, ports, environment variables, and basic scaling concepts is enough to start. Kubernetes knowledge helps with advanced patterns, but it\u2019s not required.<\/p>\n\n\n\n<p>3) <strong>Can Azure Container Apps scale to zero?<\/strong><br\/>\nYes, scale-to-zero is a common pattern, especially in usage-based models. Cold-start latency is a tradeoff.<\/p>\n\n\n\n<p>4) <strong>How do I deploy my app?<\/strong><br\/>\nYou deploy a container image (public or private). Many teams build in CI\/CD, push to ACR, then update the Container App to the new image tag\/digest.<\/p>\n\n\n\n<p>5) <strong>How do revisions work?<\/strong><br\/>\nA revision is an immutable snapshot of configuration. Updating the app can create a new revision, and you can split traffic across revisions.<\/p>\n\n\n\n<p>6) <strong>Can I do canary releases?<\/strong><br\/>\nYes. You can use weighted traffic splitting between revisions.<\/p>\n\n\n\n<p>7) <strong>How do I secure access to Azure resources like Key Vault or Storage?<\/strong><br\/>\nUse managed identities and Azure RBAC (and resource-specific access policies where applicable). Avoid embedding secrets in code.<\/p>\n\n\n\n<p>8) <strong>Can I run background jobs?<\/strong><br\/>\nYes. Azure Container Apps supports jobs for run-to-completion tasks. Verify the current supported job triggers and scheduling options in official docs.<\/p>\n\n\n\n<p>9) <strong>Is Azure Container Apps good for long-running services?<\/strong><br\/>\nYes. It can run always-on services, but you should consider min replicas and cost. For strict performance control, consider dedicated capacity approaches or AKS.<\/p>\n\n\n\n<p>10) <strong>What about custom domains and certificates?<\/strong><br\/>\nAzure Container Apps supports custom domain configurations and certificate management options. Verify the current recommended approach (managed certificates vs uploaded) in official docs.<\/p>\n\n\n\n<p>11) <strong>Where do logs go?<\/strong><br\/>\nTypically to Azure Monitor \/ Log Analytics if configured. You can also stream logs via Azure CLI.<\/p>\n\n\n\n<p>12) <strong>What are the main cost drivers?<\/strong><br\/>\nCompute (CPU\/memory time), request volume (depending on model), Log Analytics ingestion\/retention, and data egress. Also ACR storage\/operations if used.<\/p>\n\n\n\n<p>13) <strong>Can I connect Azure Container Apps to a VNet?<\/strong><br\/>\nSome networking options exist at the environment level. The exact capabilities and setup steps can vary; verify the latest networking docs before committing to a design.<\/p>\n\n\n\n<p>14) <strong>How do I roll back a bad deployment?<\/strong><br\/>\nIf the previous revision is still available, shift traffic back (set weights to route 100% to the known-good revision).<\/p>\n\n\n\n<p>15) <strong>How do I choose between Azure Container Apps and Azure Functions?<\/strong><br\/>\nIf your workload is function-shaped with event triggers and you want minimal container ownership, choose Functions. If you want more control over the runtime and containerization across services, choose Container Apps.<\/p>\n\n\n\n<p>16) <strong>How do I control outbound access (egress)?<\/strong><br\/>\nEgress control depends on your environment networking design and Azure network components (NAT, firewall, routing). Verify the supported options for Container Apps environments in your region.<\/p>\n\n\n\n<p>17) <strong>Can I run multiple containers in one app?<\/strong><br\/>\nAzure Container Apps supports multi-container patterns in some scenarios. Verify current support and limitations (sidecars, resource allocation, and networking) in official docs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure Container Apps<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Container Apps documentation<\/td>\n<td>Primary source for concepts, how-to guides, networking, scaling, and security: https:\/\/learn.microsoft.com\/azure\/container-apps\/<\/td>\n<\/tr>\n<tr>\n<td>Official overview<\/td>\n<td>Azure Container Apps overview<\/td>\n<td>Clear service scope and core capabilities: https:\/\/learn.microsoft.com\/azure\/container-apps\/overview<\/td>\n<\/tr>\n<tr>\n<td>Official quickstart<\/td>\n<td>Deploy your first container app<\/td>\n<td>Step-by-step first deployment patterns (portal\/CLI): https:\/\/learn.microsoft.com\/azure\/container-apps\/get-started<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Azure Container Apps pricing<\/td>\n<td>Up-to-date meters, free grants, and region notes: https:\/\/azure.microsoft.com\/pricing\/details\/container-apps\/<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Azure Pricing Calculator<\/td>\n<td>Build scenario-based cost estimates: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Azure Architecture Center<\/td>\n<td>Reference architectures and best practices across Azure services: https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Scaling guidance<\/td>\n<td>Container Apps scaling documentation<\/td>\n<td>Details on autoscaling concepts and configuration: https:\/\/learn.microsoft.com\/azure\/container-apps\/scale-app<\/td>\n<\/tr>\n<tr>\n<td>Networking guidance<\/td>\n<td>Container Apps networking documentation<\/td>\n<td>Understand ingress, internal access, and environment networking: https:\/\/learn.microsoft.com\/azure\/container-apps\/networking<\/td>\n<\/tr>\n<tr>\n<td>Jobs documentation<\/td>\n<td>Container Apps jobs documentation<\/td>\n<td>Run-to-completion workloads, triggers, and operations: https:\/\/learn.microsoft.com\/azure\/container-apps\/jobs<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>Azure Monitor for Container Apps<\/td>\n<td>Logs\/metrics integration and troubleshooting patterns: https:\/\/learn.microsoft.com\/azure\/container-apps\/logging-monitoring<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>Azure CLI <code>az containerapp<\/code> reference<\/td>\n<td>Command syntax and examples: https:\/\/learn.microsoft.com\/cli\/azure\/containerapp<\/td>\n<\/tr>\n<tr>\n<td>Samples<\/td>\n<td>Microsoft samples on GitHub (search: Azure Container Apps)<\/td>\n<td>Practical examples and templates; validate repo ownership and maintenance: https:\/\/github.com\/Azure-Samples<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following providers may offer training related to Azure, Containers, and Azure Container Apps. Validate course outlines and recency on each website.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams, developers<\/td>\n<td>DevOps practices, CI\/CD, containers, cloud fundamentals, Azure tooling<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Developers, DevOps beginners, build\/release engineers<\/td>\n<td>SCM, CI\/CD pipelines, DevOps foundations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud engineers, operations teams<\/td>\n<td>Cloud operations, monitoring, automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations, reliability engineers<\/td>\n<td>Reliability engineering, monitoring, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams, SREs, automation engineers<\/td>\n<td>AIOps concepts, observability automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites are presented as training resources or platforms. Validate offerings, trainer profiles, and course recency directly on each site.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training topics (verify specifics)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tools and practices (verify specifics)<\/td>\n<td>DevOps practitioners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps help\/training (verify specifics)<\/td>\n<td>Teams needing short-term guidance<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and enablement (verify specifics)<\/td>\n<td>Ops\/DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These organizations may provide consulting services relevant to Azure, Containers, and platform engineering. Confirm capabilities and references directly with each company.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>DevOps, cloud consulting (verify exact offerings)<\/td>\n<td>Delivery pipelines, cloud migration, container adoption<\/td>\n<td>Containerization roadmap, CI\/CD setup, operational runbooks<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify exact offerings)<\/td>\n<td>DevOps transformation, tooling, coaching<\/td>\n<td>Azure CI\/CD implementation, container platform enablement<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact offerings)<\/td>\n<td>Automation, CI\/CD, operations maturity<\/td>\n<td>Build\/release automation, monitoring strategy, container operations<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Azure Container Apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Containers fundamentals<\/strong>:<\/li>\n<li>Docker basics, images, registries, tags vs digests<\/li>\n<li>Exposing ports, environment variables, logging to stdout\/stderr<\/li>\n<li><strong>Azure fundamentals<\/strong>:<\/li>\n<li>Resource groups, regions, subscriptions<\/li>\n<li>Azure RBAC, managed identities<\/li>\n<li>Basic networking (VNets, DNS basics, ingress vs egress)<\/li>\n<li><strong>CI\/CD basics<\/strong>:<\/li>\n<li>Build container images<\/li>\n<li>Push images to a registry (ACR)<\/li>\n<li>Deploy via CLI or pipelines<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure Container Apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Advanced scaling and resiliency<\/strong>:<\/li>\n<li>Event-driven autoscaling patterns<\/li>\n<li>Retries, backoff, idempotency<\/li>\n<li><strong>Secure networking<\/strong>:<\/li>\n<li>Internal ingress and private architecture patterns<\/li>\n<li>WAF and gateway designs<\/li>\n<li><strong>Platform engineering<\/strong>:<\/li>\n<li>Azure Policy guardrails<\/li>\n<li>Central logging standards and SRE practices<\/li>\n<li><strong>AKS (optional)<\/strong>:<\/li>\n<li>If you need deeper control later, learning AKS becomes a natural next step.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use Azure Container Apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Backend Developer (especially for microservices)<\/li>\n<li>Solutions Architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Azure certifications change over time, but common relevant ones include:\n&#8211; <strong>AZ-900<\/strong> (Azure Fundamentals) for beginners\n&#8211; <strong>AZ-104<\/strong> (Azure Administrator) for operations and governance\n&#8211; <strong>AZ-305<\/strong> (Azure Solutions Architect) for architecture design\n&#8211; <strong>AZ-400<\/strong> (DevOps Engineer Expert) for CI\/CD and operations<\/p>\n\n\n\n<p>Verify the current certification details on Microsoft Learn: https:\/\/learn.microsoft.com\/credentials\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploy an API with revisions and canary rollouts.<\/li>\n<li>Build a worker that scales from queue depth (Service Bus).<\/li>\n<li>Create a scheduled job for nightly tasks.<\/li>\n<li>Implement managed identity access to Key Vault and Storage.<\/li>\n<li>Create a multi-region deployment with DNS-based routing (requires careful data design).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Container Apps environment<\/strong>: A regional boundary that hosts container apps and centralizes configuration like logging and networking.<\/li>\n<li><strong>Container app<\/strong>: A deployed containerized service configuration (image, resources, scaling, ingress).<\/li>\n<li><strong>Revision<\/strong>: An immutable version of a container app configuration. You can route traffic between revisions.<\/li>\n<li><strong>Replica<\/strong>: A running instance of a revision; scaling adjusts the number of replicas.<\/li>\n<li><strong>Ingress<\/strong>: How HTTP(S) traffic enters the app (external\/public or internal-only depending on config).<\/li>\n<li><strong>Scale-to-zero<\/strong>: Automatically reducing replicas to zero when idle (tradeoff: cold start).<\/li>\n<li><strong>KEDA<\/strong>: Kubernetes-based Event Driven Autoscaling concepts used broadly in cloud-native platforms; Container Apps uses event-driven scaling patterns inspired by KEDA.<\/li>\n<li><strong>Managed identity<\/strong>: Azure-managed identity for workloads to access Azure resources without storing credentials.<\/li>\n<li><strong>Azure RBAC<\/strong>: Role-Based Access Control for Azure resources.<\/li>\n<li><strong>Log Analytics<\/strong>: Azure service for log ingestion, retention, and querying (KQL).<\/li>\n<li><strong>KQL<\/strong>: Kusto Query Language used to query logs in Log Analytics.<\/li>\n<li><strong>ACR (Azure Container Registry)<\/strong>: Private registry for container images.<\/li>\n<li><strong>Canary deployment<\/strong>: Gradual rollout where a small percentage of traffic goes to the new version first.<\/li>\n<li><strong>Blue\/green deployment<\/strong>: Two environments\/versions; traffic switches from old (blue) to new (green) with quick rollback.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure Container Apps is an Azure <strong>Containers<\/strong> service that runs containerized applications and jobs with built-in ingress, autoscaling (including scale-to-zero), revisions, and integrated observability\u2014without requiring you to manage Kubernetes clusters.<\/p>\n\n\n\n<p>It matters because it helps teams deliver microservices, APIs, workers, and scheduled tasks faster with fewer platform operations. Architecturally, it sits between \u201crun a container\u201d services and full Kubernetes: it offers many Kubernetes-style deployment benefits (revisions, scaling, traffic control) while keeping the operational surface area smaller.<\/p>\n\n\n\n<p>Cost and security deserve upfront attention:\n&#8211; Cost is driven by compute usage, scaling choices, logs (Log Analytics), and data egress.\n&#8211; Security is driven by RBAC, managed identities, secrets handling, and ingress exposure.<\/p>\n\n\n\n<p>Use Azure Container Apps when you want a practical, production-ready container platform with strong scaling and release controls, and choose AKS when you need full Kubernetes control.<\/p>\n\n\n\n<p>Next step: follow the official docs to deepen skills in scaling, jobs, networking, and identity, starting here: https:\/\/learn.microsoft.com\/azure\/container-apps\/overview<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Containers<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,27,42],"tags":[],"class_list":["post-405","post","type-post","status-publish","format-standard","hentry","category-azure","category-containers","category-web"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/405","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=405"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/405\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}