Comment by Atul Vishwakarma on "From Azure VM to Azure Container Apps: How We Reduced Hosting Costs by 70% Without Rewriting Our FastAPI Backend"

Really liked this breakdown. Most “we cut costs by X%” posts stay very high-level, but you actually walked through the trade-offs of moving from a VM to Azure Container Apps without rewriting the FastAPI backend, which is the part teams worry about the most.

The way you leveraged ACA’s scale-to-zero and per-second billing model makes a lot of sense for APIs that aren’t constantly hammered with traffic. It’s a good reminder that infra cost is not just about instance size, but about how the platform scales your workload over a 24/7 cycle.

I’m curious how the migration felt from an operational point of view:

Did observability/logging get simpler or more fragmented after moving off the VM?
And have you hit any limits or “gotchas” with ACA yet (cold starts, networking, private access, etc.) that teams should be aware of before jumping in?

Overall, this is exactly the kind of honest, numbers-backed story that helps engineers justify a platform change to their teams. Thanks for sharing the journey!

Thanks, Atul. Glad you found it useful.

From an operational perspective, I'd say observability became simpler overall. We now rely primarily on Azure Log Analytics and Container Apps diagnostics instead of SSH-ing into a VM and inspecting logs directly. There was a bit of a learning curve initially, but once everything was wired up, troubleshooting became more centralized.

As for gotchas, the biggest ones for us were actually during deployment rather than runtime:

• Azure Student subscription restrictions around ACR cloud builds ("az acr build") • ARM64 vs AMD64 image compatibility when building on Apple Silicon • Rethinking configuration management when moving away from server-hosted ".env" files

Regarding cold starts, we chose not to scale to zero. We configured a minimum replica count of 1 because API responsiveness was more important for us than squeezing out every last bit of cost savings. Given our current traffic profile, that felt like the right tradeoff.

So far, ACA has been a good fit because it removes most of the infrastructure management overhead while still letting us keep a container-centric deployment model. I'm sure we'll discover more tradeoffs as the platform grows, but the migration has been positive overall.

Thanks a lot for the detailed reply — really appreciate you sharing the operational side too.

Your point about observability becoming simpler definitely resonates with me. In our case, when our app was still on AWS EC2, we were already shipping logs to CloudWatch, so we weren’t fully dependent on SSH for troubleshooting. But even then, there was still more server-level thinking involved compared to a platform like ECS Fargate, where the deployment and runtime model feels more centralized.

We recently moved one of our production applications from AWS EC2 to AWS ECS Fargate, and that migration also taught us that the real work is not just “moving the app,” but rethinking networking, container images, task definitions, logging, and deployment flow. So I completely get what you mean about deployment gotchas being the bigger challenge.

The cold start decision also makes sense. For production APIs, keeping a minimum replica count of 1 is often the more practical choice when response time matters more than maximum cost savings.

I’ve also started writing technical blogs around DevOps and cloud migration learnings, mainly to share what I’m learning and connect with more people in the space. Posts like yours are exactly the kind of real-world experience that help a lot.

Thank you Atul. Appreciate the thoughtful feedback.

Completely agree that most of the work in these migrations ends up being around the platform and deployment model rather than the application itself. Interesting to hear about your EC2 → ECS Fargate experience as well.

Glad you found the post useful, and all the best with your technical writing journey! I will check those for sure

Thank you, really appreciate that.

Our EC2 to ECS Fargate move was one of those migrations that looked simpler from the outside than it actually was. On EC2, we had a very familiar setup — a server, an app running on it, logs going to CloudWatch, and enough manual control that things felt straightforward. But that also meant we were still thinking in terms of servers, even if we weren’t SSH-ing in all the time.

Once we moved toward ECS Fargate, the whole mindset shifted. We had to think more in terms of containers, task definitions, networking, IAM roles, service stability, and how the app should behave in an orchestrated environment. The application code itself didn’t change much, but the surrounding platform absolutely did. That was the biggest lesson for me — the real complexity is usually not the app, it’s the operational model around it.

We also had to rework a few things that were easy on EC2 but needed a cleaner approach in Fargate, especially around environment configuration, deployment flow, and making sure the service stayed healthy without manual intervention. But after the initial learning curve, it started to feel much cleaner and more scalable.

What I liked most was that Fargate removed a lot of the server management overhead. We no longer had to care about instance patching, capacity planning in the same way, or keeping one machine alive just because the app lived there. That shift made the platform feel much more modern and easier to reason about long term.

So overall, I’d say the migration was definitely worth it. It was not just “move the app from one place to another” — it was more like moving from server thinking to platform thinking.

Search Hashnode