Azure Container Registry stores private images, while Container Apps, Container Instances, and Azure Kubernetes Service run containers with different orchestration responsibilities.
Container Apps suits many HTTP, event-driven, and microservice workloads that need revisions and autoscaling without direct Kubernetes management. AKS is appropriate when Kubernetes APIs and ecosystem control are requirements.
Safe container delivery includes an immutable image, registry controls, workload identity, secret management, network boundaries, health probes, scaling limits, and rollback.
Use small reproducible images, non-root execution, pinned dependencies, and vulnerability scanning. Push versioned tags or digests to ACR rather than replacing a mutable production tag.
Use Container Instances for simple isolated jobs, Container Apps for managed revisions and autoscaling, and AKS when direct Kubernetes features or portability justify cluster operations.
Assign a managed identity to the workload, retrieve secrets from Key Vault, and define ingress and egress deliberately. Private registry, private endpoints, and internal environments can reduce public exposure.
Use readiness and liveness probes that reflect application behavior. Release through revisions or controlled Kubernetes rollouts and define the metric and limits used for autoscaling.
Build a minimal runtime image from a reviewed base, run as non-root where possible, and remove compilers and temporary credentials through multi-stage builds. Pin dependencies and rebuild when the base or packages are patched. A vulnerability scan is a decision input, not proof that application behavior is secure.
Push images to Azure Container Registry with a unique release tag and deploy by digest or another immutable reference. Do not deploy a reusable stable tag that can point replicas to different bytes. Lock released versions against accidental mutation or deletion where the registry process requires it, and use retention for unreferenced manifests.
Use managed identity, workload identity, or repository-scoped authorization rather than the registry admin account. Restrict registry networking, exports, and public access according to the design. Track source commit, build, bill of materials, scan, signature or provenance, digest, and deployed revision.
Azure Container Instances runs container groups without managing virtual machines or adopting a full orchestrator. It fits isolated jobs, burst helpers, build agents, and simple services that fit its current platform, network, storage, restart, and availability capabilities. It does not provide the complete service rollout and scheduling model of AKS or Container Apps.
A container group shares lifecycle, host, network, and storage among its containers. Use sidecars only when the group should be scheduled and stopped together. Set CPU, memory, restart policy, environment, identity, image pull, DNS, and logging explicitly. Store durable state outside the group.
Test image pull, startup, exit code, retry, timeout, network, file share, and cleanup. For jobs, record business completion in durable storage so a restarted or duplicated group cannot repeat unsafe effects. Move to an orchestrator when revisions, autoscaling, service discovery, rolling deployment, or fleet policy become required.
Azure Container Apps manages a container application inside an environment with ingress, revisions, scaling, identity, secrets, and observability. Revision-scope changes create immutable revisions, while application-scope settings can affect all revisions. Know which category a change belongs to before assuming rollback isolates it.
Single revision mode moves traffic after the candidate is ready; multiple revision mode can run revisions concurrently and split traffic. Configure startup, liveness, and readiness probes that reflect application behavior. Keep schema, events, secrets, and downstream permissions compatible while old and new revisions coexist.
KEDA-based scale rules can respond to HTTP or supported event sources. Set minimum and maximum replicas from latency and downstream capacity, authenticate scale rules with managed identity where supported, and understand scale-to-zero behavior. A queue can absorb bursts only while message age remains acceptable.
Azure Kubernetes Service manages the control plane under its service contract, while the customer owns node pools, Kubernetes objects, workload identity, network policy, ingress, storage, add-ons, observability, policy, backup, and supported-version upgrades. Managed does not mean Microsoft operates application namespaces and manifests.
Choose AKS when Kubernetes APIs, ecosystem, portability, scheduling, or existing platform skill provide concrete value. Container Apps is often a smaller operating model for HTTP and event-driven containers, while ACI is smaller for isolated execution. Do not adopt Kubernetes only because the artifact is a container image.
Plan cluster API access, Microsoft Entra integration, Azure RBAC or Kubernetes RBAC, workload identity, CNI address capacity, egress, private endpoints, node images, disruption budgets, storage classes, and add-on support. Test node and zone failure plus control-plane and node-pool upgrade.
Use managed identity for Container Apps and ACI where supported and workload identity federation for AKS pods. Separate registry pull identity, deployment identity, node or platform identity, and application data identity. A container should not inherit broad Azure access merely because the cluster can administer resources.
Keep ingress and application backends private when required, restrict outbound paths, and plan DNS, private ACR access, subnet delegation, service CIDRs, load balancers, and private endpoints. Container Apps environments, ACI groups, and AKS have different network models; verify the selected environment rather than reusing one diagram.
Retrieve secrets from Key Vault or the platform secret mechanism with an explicit rotation plan. Environment injection can leave old replicas with old values. Restart or create revisions deliberately, avoid logging configuration dumps, and limit which container or service account can request each identity token.
Use rolling, revision traffic splitting, blue-green, or canary release according to the platform, capacity, data compatibility, and rollback need. Define health, observation window, promotion signal, and automatic stop before release. Keep the previous image and configuration available until the data and message compatibility window closes.
Collect structured stdout and stderr, release identity, request traces, platform events, replica or pod status, restart reason, image pull errors, probe failures, saturation, backlog, and deployment history. Centralize logs with retention and redaction. A running container count does not prove useful service.
Exercise a bad image, unavailable registry, missing secret, failed probe, zone or node loss, scale-out, downstream throttle, and rollback. Track ACR, Container Apps, ACI, AKS, Kubernetes, node image, and add-on support lifecycles. Upgrade a representative environment before production and remove obsolete revisions and images after evidence is retained.
Track ACR API and signing guidance, Container Apps environment and revision features, ACI platform limits, AKS Kubernetes versions, node images, CNI, ingress, CSI drivers, policy add-ons, and workload APIs. A valid image can still fail on an unsupported orchestrator or removed API.
Upgrade a representative environment first, inspect deprecations, replay deployments, and test network, storage, identity, autoscaling, disruption, and rollback. Keep workload manifests and Bicep aligned with supported API versions and remove obsolete images or add-ons after the observation window.
Handle termination signals, stop accepting new work, drain load-balancer connections, finish or checkpoint in-flight jobs within the platform grace period, and close telemetry and data clients. Container Apps scale-in, ACI restart, and AKS pod disruption have different controls, so test the selected platform rather than relying on one local Docker result.
Keep long work recoverable through queues, checkpoints, leases, or idempotent operations. A graceful handler improves normal rollout but cannot guarantee execution during host failure; durable business state must survive abrupt termination.
az containerapp up \
--name orders-api \
--resource-group rg-app-dev \
--location centralindia \
--image tlregistrydev.azurecr.io/orders-api:1.0.0 \
--target-port 8080 \
--ingress externalA new revision shows elevated errors at 10% traffic.
Constraints: Revisions are immutable, secrets are referenced, and rollback must not rebuild an image.
Decision: Hold the new revision at a small weight, compare telemetry by revision, then return all traffic to the known-good revision.
Verification: Error rate returns to baseline and the failed revision keeps logs and configuration for diagnosis.
Failure test: Scale the failed revision to zero and confirm the stable revision handles the full load.Expected evidence: Error rate returns to baseline and the failed revision keeps logs and configuration for diagnosis.Explore 500+ free tutorials across 20+ languages and frameworks.