DEV Community: Quang Chien TRAN

How I Optimized Our Cloud, Git Workflow, and Infrastructure

Quang Chien TRAN — Wed, 25 Mar 2026 15:15:01 +0000

In the previous article, I shared how I optimized the cloud bill for the company. But in reality, there were still many things that needed improvement.

Pipeline to Deploy Code

Our company uses Jenkins to run pipelines.

Of course, I have worked with GitLab CI/CD before, but for me they are all just tools.

Argo CD, GitHub Actions, or AWS CodePipeline — in the end they are simply tools to build and deploy code.

At the beginning, our pipeline only had a build stage for backend projects. Deployments were still done mostly by hand.

So I added new steps to automatically deploy to staging and production.

Now everything is fully automated after a simple git push.

Pretty nice 😄

At the moment, all the projects I work on already have automatic deployment pipelines. My job now is simply to change the code and push it to git.

Working with Git

I have to admit something.

Even though I had used git for a long time, I never really had an effective workflow.

In a team with many developers, things could easily become messy and hard to manage.

Every time we wanted to test a new feature, we had to ask questions like:

Can we deploy now?
Will it overwrite someone else’s code?
Is another feature still being tested?
Is it my turn to test?

The main problem was simple:

we only had one dev environment.

At that time, my understanding of an effective git workflow was still very vague.

Then one day, while walking home from work along the river, without looking at my phone, just enjoying the fresh air and thinking randomly about git workflows… suddenly an idea came to me. Haha.

Later I found a blog post online that described almost exactly the same workflow.

That’s when I realized:

it wasn’t a new idea — I just hadn’t been exposed to it before.

In the end, everything is about what works best for your team.

My principles are very simple:

The master branch is always the most stable and correct version of the system.
All new features and bug fixes must start from this branch.
The develop branch is used for testing.
Feature branches and bug-fix branches must merge into develop to be deployed to the testing environment.
After testing is successful on develop, the feature branch can then be merged into master and deployed to production.

With this workflow, our team has been working very smoothly so far.

If problems appear later…

maybe I will just go walk along the river again to think about it. 😄

Infrastructure (Infrastructure as Code)

The benefits of Infrastructure as Code are well known, so I probably don’t need to explain them much. You can easily find plenty of information online or just ask AI.

After finishing the deployment of the backend infrastructure on Amazon Web Services, the next thing I did was write IaC for all the projects I worked on.

The idea was simple.

One day, if I am no longer working here, at least the people who stay — or new engineers joining the company — will have something that helps them understand the infrastructure that was built.

And if something goes wrong, they can quickly rebuild it.

I use OpenTofu, which is a fork of Terraform. Everything is basically the same.

Sorry AWS, but I’m not a big fan of AWS CloudFormation.

Terraform code just looks much nicer to me 😄

Monitoring

I will probably write a separate article about this topic.

For me, after one year at this company, the thing I’m most proud of is not AWS infrastructure, but building a monitoring platform for the company.

At my previous company, I worked with Datadog, but at that time my understanding of monitoring was still very basic. I mostly just used it to read logs.

Back then I was just a developer, and honestly no one really guided me to explore the system deeply.

When I joined this company, I was surprised to see that there was no monitoring platform at all.

If developers wanted to read logs, they had to SSH into the server.

At that moment I felt that monitoring was absolutely necessary.

Without it, debugging production systems feels like fighting enemies with bare hands.

Today, monitoring takes a significant part of my daily work. But the value it brings has helped me learn many new things.

Backup

Do you know what the most valuable asset of a company is?

For me, it’s data.

As long as the data still exists, the company can survive.

If the data disappears, the company may disappear too.

There was a company that lost all its data after hackers gained root access and deleted everything. They asked AWS for help to recover it, but it wasn’t possible. Eventually the company had to shut down.

That story made me think a lot about how to protect our data.

Our company uses Amazon RDS with PostgreSQL.

But what happens if someone gains root access?

Everything could disappear instantly.

Eventually I learned about AWS Backup. With this service, backups are protected and cannot easily be deleted — even with root access.

At least, within my current understanding, this feels safer.

Unless the entire AWS infrastructure collapses… which hopefully is very unlikely.

Cron Jobs

This is something almost every company needs — processing large datasets periodically.

In our company, we originally used the Spring Boot scheduled annotation to run these jobs.

It worked well.

But there were two problems:

Debugging these jobs could be difficult.
Horizontal scaling becomes problematic. If multiple servers run at the same time, the same job might execute twice.

My solution was quite simple.

Instead of refactoring everything, I moved job scheduling to:

AWS Lambda
Amazon EventBridge

EventBridge triggers Lambda, which then calls a HTTP API endpoint in our Spring Boot service. The controller routes the request to the appropriate job based on parameters.

Everything became much easier to manage.

Conclusion

I’m always thinking about ways to improve the systems I work on.

Maybe some of these solutions look simple to others.

But for me, every time I find a solution, it brings a small sense of joy.

And honestly, I’m always a little proud of that. 😉

(And yes, I still take walks by the river to brainstorm!) 😊

(If you enjoy these kinds of engineering stories, you can subscribe or visit my blog to receive the next ones.)
Connect me on LinkedIn :D

How I Reduced Cloud Costs by 40% Using the "Clean & Think" Method

Quang Chien TRAN — Sat, 21 Mar 2026 13:16:01 +0000

Actually, there have been tons of posts about how to optimize AWS costs. I’ve read them, analyzed them, and applied what makes sense for the cloud infrastructure I manage.

At some point, your cloud infra is stable, services run smoothly, no errors, the team is happy… but then at the end of the month, you look at the bill and—well… why are you paying a few thousand dollars for just a handful of services?

Whether it’s a big company or a small one, optimizing costs for any expense always needs careful consideration. Cloud cost is no exception. If you control it well, cloud is an amazing tool. If not… your wallet slowly bleeds every month and you don’t even know why.

How I optimize my infrastructure

Clean up the garbage

Yep, you read that right. In almost every infrastructure, if you don’t clean regularly, there will be a bunch of unused stuff still sitting around—and you’re paying for things that bring zero value.

My approach:

S3 buckets: Delete buckets or objects from non-production environments that are no longer in use.
ECR (Docker images): Implement lifecycle policies to prune old versions. By keeping only the latest 10–12 images, I stopped storage costs from ballooning and cut “zombie” storage waste by over 90%.
Networking & Storage: Periodically audit for Elastic IPs and EBS volumes that exist but are not attached to any instance.

If you don’t use it, turn it off

Simple logic: you work 8 hours a day. After that, you don’t use the system—but if services are still running, you’re still paying :D

For example, non-production environments can be stopped from 8 PM to 7 AM.

ECS → set desired count = 0
RDS → stop at night, start in the morning
EC2 → stop/start or scale auto scaling down to 0

All of this is super easy. Just combine Lambda + EventBridge to schedule it. Fully automated, no need to click manually.

Use less, pay less

This one is obvious for S3. Setting lifecycle policies can save you quite a bit.

Hot data → keep in standard storage
Cold data / logs backup → move to Glacier

You can also set lifecycle rules for ECR to auto-delete old images instead of doing it manually.

Ask: "Can this be optimized further?"

This mindset applies to almost everything I do, not just AWS.

I’m a backend dev. Sometimes I finish a task but still feel the code isn’t clean enough, naming isn’t right, or it doesn’t follow SOLID / reusable principles → I refactor.

Same with AWS cost optimization, but even more frequently.

When deploying systems (EC2, ECS, EKS, RDS), we often over-provision resources “just to be safe.” But you still pay for all of it.

Example:

With ECS Fargate, I've seen payment services set to 4 vCPU, 8GB RAM. After running, CPU and memory usage were only ~10–20%. So I cut the config in half, then monitored again. Around 50–70% utilization is a good balance.

So the question I always keep in mind is:

“Can this system (or task) be optimized further?”

And optimization isn’t just about cost—it’s also performance, scalability, and clean code.

If AWS recommends it, just follow

Honestly, AWS engineers know their stuff. They’ve laid out best practices in the Well-Architected Framework, and tools like Amazon Q can guide you. Here’s what I implemented:

Use S3 Gateway Endpoints: This is a total “cheat code.” By adding a Gateway VPC Endpoint to your routing table, traffic to S3 stays within the AWS internal network. It doesn’t go over the public internet, it’s more secure, and most importantly—S3 Gateway Endpoints are free. No data transfer markers, no hourly fees. (Just be careful not to choose the “Interface” type unless you specifically need it, as those do have a cost!)
Switch ECS Fargate to ARM: I converted our Fargate tasks from x86_64 to ARM (Graviton). It’s the “good-cheap-better” standard: it usually performs better for backend workloads and is roughly 20% cheaper right out of the box.
Reserved Instances & Savings Plans: For stable workloads like RDS or baseline EC2, this is a no-brainer. If you know you’ll be running it for a year, commit to it and take the 30–60% discount.
Ditch Public IPs: Since 2024, AWS charges for every public IPv4 address (~$3.60/month per IP). By keeping resources in private subnets and using internal communication, you save money and harden your security at the same time.
Free tier is great. A lot of my Lambda, SNS, SQS, and CloudWatch usage stays within the Free Tier, so I barely pay anything.
Keep a close eye on the AWS bill and set up an AWS Budget to avoid catching issues too late. Once you notice a service suddenly getting expensive, you need to understand exactly why. In general, checking Cost Explorer every 2 or 3 days is a safe habit.
If your application uses an RDS Cluster with heavy read/write activity, leading to high I/O costs (more than 25% of the total RDS bill), it may be worth considering AWS I/O Optimized storage. In that case, storage is about 30% more expensive, but I/O cost becomes 0.

In short, there are still many ways to save AWS costs. The most important thing is to understand the service and its pricing. Before using a service, you should first understand how it’s priced and analyze it carefully, because sometimes you jump in first, and only when the bill arrives do you ask why it’s so expensive.

Conclusion

With what I’ve done above, the AWS bill has dropped by 40% compared to before. I’m happy that everything is still running well, especially for small and medium businesses, where cost should be a top priority. Running well and cheap is still better than running well and expensive, right? 😅

“The views and optimizations shared here are my own personal engineering perspectives and do not represent the specific data or policies of any employer.”

(If you enjoy these kinds of engineering stories, you can subscribe or visit my blog to receive the next ones.)
Connect me on LinkedIn :D

Choosing Between EKS, ECS, and EC2 for My First Real Deployment

Quang Chien TRAN — Fri, 20 Mar 2026 16:08:24 +0000

I started at my new company at the beginning of last year. The reason I changed jobs was already explained in a previous article.

Calm Before the Storm

When I first joined, I spent time getting familiar with the system, new colleagues, new projects, and the company culture.

In real life, I’m quite an introverted person. But at work… not really 😄

Whenever I don’t understand something, I ask immediately so I don’t get blocked.

Luckily, after about one month, I had already integrated quite well with the project and the team.

That’s when the tasks mentioned during my recruitment process started to arrive.

What Did the System Look Like at That Time?

At that moment, the backend system had around 10 small microservices written with Spring Boot.

The system used RabbitMQ to send events between services.

When we needed to update a service, all services were dockerized and deployed together using AWS Elastic Beanstalk.

Each deployment caused about 4–5 minutes of downtime.

Because of that, deployments were usually done during low-traffic periods, except for urgent hotfixes.

My First Assigned Task

The CTO gave me a task:

With your AWS experience, find another way to deploy services individually without interrupting the system.
Use Kubernetes if necessary.

For experienced engineers, this might sound easy.

But for me at that moment, it wasn’t.

Before that, I was mostly a backend developer. My DevOps experience was limited to small personal projects, never real production systems.

What Did I Actually Have?

I had the AWS Certified Solutions Architect – Associate certificate.

Other than that… not much.

I spend a lot of time reading tech blogs and watching tutorials on YouTube.

I also want to thank Viet Tran for his AWS tutorial videos, and Nguyen Van Manh for sharing many DevOps insights.

One mindset that stuck with me from his talks was:

Don’t make things complicated.
A pipeline only has two important stages: build and deploy.
Everything else is secondary.

The AWS explanations and advice from Viet Tran also helped me understand which services to choose and how to approach the problem.

Let’s Start

Now I was standing in front of three options for deploying Docker containers on Amazon Web Services:

Amazon EKS
Amazon ECS
Amazon EC2

EC2

I quickly rejected this option.

Using EC2 with docker-compose or docker-swarm would require a lot of effort to deploy and maintain.

Maybe it could be the cheapest option, but for someone with limited DevOps experience like me, it felt risky.

Actually, the existing Beanstalk deployment was already similar to this model.
Beanstalk created ECS clusters and deployed services on EC2 instances.

EKS

Even though I had no Kubernetes experience, I believe I could learn it if I had enough time.

After all, AWS already manages the hardest parts.

Using EKS would also look great on my CV and allow me to explore Kubernetes more deeply.

But this was clearly a trade-off.

If you only have a small number of services, using EKS can feel like using a huge knife just to kill a fly.

It’s powerful, but maybe too complex.

Managing Kubernetes properly also requires someone with solid experience. Otherwise, you might spend all day debugging infrastructure issues.

And the cost isn’t small either.

Even if you do nothing, maintaining a cluster already costs around $100 per month 😄

ECS Fargate

In the end, I chose AWS Fargate with ECS.

It’s an AWS-native service and already provides everything I needed:

Load balancer
Auto scaling
Rolling updates
Blue-green deployments

It’s lightweight and serverless.

Basically, I let AWS handle most of the infrastructure and focus on developing the application instead 😄

The cost was reasonable and the service was very beginner-friendly.

After about three weeks, I managed to bring the system to production.

Of course, there were still adjustments later, but overall it integrated quite smoothly with our real project.

Today

Today the ECS infrastructure is still running well and fits the company’s needs.

I believe choosing ECS was a reasonable decision.

Sometimes it’s not about choosing the most powerful technology.

It’s about choosing what fits the situation best.

I sometimes wonder what would have happened if I had chosen EKS.

Maybe everything would still work fine.

But every time I looked at the AWS bill, I might get a little shocked 😄

(If you enjoy these kinds of engineering stories, you can subscribe or visit my blog to receive the next ones.)
Connect me on LinkedIn :D

Everything Was Stable… So Why Did I Leave

Quang Chien TRAN — Fri, 20 Mar 2026 15:55:50 +0000

Last year, I moved to a new company.

But a few months before that, I had already started thinking about finding another job instead of staying where I was.

The decision happened quite quickly. I prepared my CV and started applying to job posts on LinkedIn.

After a little more than one month and a few interviews, I found a new company.

Behind this quick decision was actually a trade-off:
being willing to step out of my comfort zone.

The Old Company Was Completely Fine

At my previous company, everything wasn’t just fine — it was very good.

My manager and colleagues appreciated me, and I also felt that I was bringing real value to the company.

I had worked there for more than three years. I knew the projects very well, almost every line of code felt familiar, and the technologies we used were modern.

The salary was good, and there were yearly bonuses.

Overall, there was nothing to complain about regarding the working environment or the company culture.

One Small Problem…

The only issue for me was this:

The company was a subsidiary of a large corporation, and all compliance rules were decided at the group level.

I understand that when an organization becomes very large, clear processes are necessary to keep things running smoothly.

So the organization was divided into many specialized teams, each responsible for a specific area.

My role was simply developer.

That meant my job was to build features and push the code to git.

After that, I just waited for the pipeline to deploy to staging or production.

If something went wrong, I had to send a message to another team so they could debug it.

Even a small feature required creating a ticket and getting approval from another team before deploying to production.

What Started to Frustrate Me

Because of this process, many things felt slow.

Whenever there was a problem, I had to ask another team to help. I couldn’t touch anything except the code.

It made me feel a bit restricted.

Sometimes a very small change could take a whole week before reaching production.

Another issue was learning.

Outside of coding, I also wanted to understand:

infrastructure
databases
cloud systems
monitoring

But if I was always asking someone else to debug things, and never doing it myself, I felt that I would never really understand those areas deeply.

What Did I Actually Have at That Time?

To be honest, not that much.

I had experience as a full-stack developer:

Java with Spring Boot
JavaScript with React

And I had the AWS Certified Solutions Architect – Associate certification.

I studied and prepared for that exam on my own and managed to pass it.

Honestly, I should also thank that certification — because it helped me realize how little I actually knew 😄

What Did the New Company Offer?

Interestingly, the technology stack was almost exactly the same as my old company.

The main difference was that they were building their system with microservices, something I had never worked with before.

The new company also needed someone with AWS experience to help modernize their infrastructure.

That sounded exactly like what I was looking for.

Since it was a startup, I knew I would have the opportunity to touch many parts of the system and learn much more.

Stepping Out of My Comfort Zone

In the end, I decided to leave my old company.

I wanted to step out of my comfort zone and challenge myself.

I wanted to improve, learn more things, and understand systems beyond just writing code.

At my new company, I always try to work with a learning mindset.

Technology moves very fast, and I hope I don’t fall too far behind.

Conclusion

So far, everything has been going well.

Hopefully it will continue that way in the future 😉

(If you enjoy these kinds of engineering stories, you can subscribe or visit my blog to receive the next ones.)