What should an AWS-focused cloud engineer know before adopting Azure Container Apps?

Pay close attention to scaling behavior. New replicas may not start quickly enough for sudden traffic spikes, so scale-to-zero or a very low minimum replica count can create a delayed outage rather than a graceful scale-up. Load-test the startup path and consider keeping a suitable minimum number of warm replicas if latency and burst handling matter. Container Apps can still be cheaper than App Service in some workloads, but the savings may shrink when you overprovision for reliable scaling.

There are a few platform limitations to check before committing. Managed TLS certificates are convenient for publicly exposed custom domains, but private deployments make certificate and DNS management more involved. Also verify any filesystem or volume-mount requirements: some scenarios, particularly mounts using managed identities, may not be supported or may lack feature parity with more mature container platforms. Treat the service roadmap and current documentation as part of your design review.

Terraform and Azure DevOps are both viable. A pipeline can build the image, push it to Azure Container Registry, and deploy a new Container Apps revision using the Azure CLI or the relevant IaC provider. Some convenience integrations may be more limited than their GitHub equivalents, but ADO itself is not a blocker. I’d validate the exact provider and CLI features you need early, especially around revisions, secrets, ingress, private endpoints, and networking.