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.