In 2026, You May Not Need AWS

What’s the reason your team chose AWS?

If the answer is because big companies use it, the boss said so, or the last job used it too, then this article can serve as a reference.

The hidden cost of AWS

The obvious cost of AWS is the number on the bill. The real cost is hidden elsewhere.

For a team of 3–5 people, just getting the infrastructure up and running requires setting up:

• VPC: network isolation, subnet and CIDR configuration
• ALB: Load Balancer, for traffic distribution and health checks
• ECS Cluster + Service + Task Definition: the core container setup
• ECR: Container Registry, and usually you need one each for dev / staging / production
• IAM Role: permission management, Task Execution Role, Task Role, Service-Linked Role
• EIP: static IP (if you need one)
• NAT Gateway: allows containers in a private subnet to access external networks
• Route 53: DNS management
• Cloudfront: if you want to connect a CDN, or avoid exposing the ALB to the public internet, you need extra configuration

And this is only infrastructure. You haven’t written a single line of application code yet.

If you write one Action wrong in an IAM Policy, the container won’t be able to pull the image from ECR. The error message will only say CannotPullContainerError; it won’t tell you it’s a permissions issue.

If you forget to set up a NAT Gateway, the container may start, but it won’t be able to reach any external API. You might spend half a day debugging before realizing the network isn’t connected.

In larger companies, these processes are usually standardized, so you just follow the playbook.

My previous company used a Private Cloud and could create a K8S cluster with one click. Even with VPS, common scripts were already built in: monitoring, OS parameters, logging, and bastion host setup were all configured immediately after creating the instance.

A startup that’s just getting off the ground is unlikely to have that kind of scale. None of this work creates product value, yet it can easily consume the output of at least one engineer.

In the article ECS deployment strategy, I estimated that for a 5-person team, the hidden cost of a complex deployment process is around NT$2–2.5 million per year.

Let’s start with fixed costs:

• NAT Gateway costs at least $32 USD per month, whether or not there is traffic.
• ALB base cost: $16 USD
• A 2 vCPU / 4GB Fargate task costs $70–80 USD per month just for compute

Add these up, and you’re already over $120 USD/month before anything is even running.

AWS egress (data transfer out) is billed by volume. In the Tokyo region, it costs $0.114 USD per GB. For a typical web service with a CDN, 400k–500k monthly active users can generate about 1 TB of egress, which translates to roughly $117 USD/month in traffic costs.

If you don’t use a CDN, the same amount of traffic can be reached by just 15k–20k MAU. Add the NAT Gateway data processing fee ($0.045/GB), and 1 TB costs another $46 USD.

These traffic costs won’t show up in your initial estimate, because traffic is low when a product first launches. But as users grow, the bill quietly swells. With fixed costs plus traffic costs, it’s easy to break $300 USD per month.

There are simpler options now

In the past, people chose AWS because there weren’t many alternatives. That’s no longer true.

Vercel is worth talking about a bit more. Next.js has introduced a fair amount of complexity in recent years. React Server Components require developers to be aware of the differences between browser-side and server-side execution, and ISR/CSR/SSR each come with trade-offs.

But Vercel integrates very well with Next.js (which is, of course, part of their business strategy), and you can deploy a Next.js project with a single push.

A few services I personally like:

• Railway: its UI and deployment experience are excellent, it has a CLI, and multi-environment support is built in
• Supabase: it includes built-in auth, can be connected via SDK, and requires very little custom implementation; it also offers CRUD API support and an editor for modifying tables in the browser

I’m very excited about Zeabur. I also use Zeabur for all my personal projects. The reasons I don’t currently recommend it are:

• Product direction: it started by attracting developers with subsidized/free pricing in the early days; later it shifted to a deployment service for vibe coders; and now it has become AI DevOps. Startups need to keep changing product direction to explore the market, but that is an unstable factor for the company
• Recent error rate: I’ve experienced a few Zeabur outages

Zeabur no longer uses a shared cluster model. Instead, you buy your own host machine first, and Zeabur provides a unified interface to manage it for you. I’ll keep watching how Zeabur develops.

Another product I’ve always wanted to try is PlanetScale. It’s led by former GitHub VPoE Sam Lambert, and these are the features I’d really like to use:

• Database branching: branching at the database level. Make schema changes and test them in an isolated environment first, then decide whether to merge. This is especially useful when different features require major schema changes
• Deploy requests: schema changes don’t go straight to production; instead, you create a deploy request, review the diff, approve it, and then deploy. This simplifies the old process of having a DBA review changes
• Developer experience: they don’t just provide DB instances; they also prepare the development tools for you

AWS is no longer the only option. It’s just easy to forget there are other paths when you’ve used it for a long time.

When AWS still makes sense

Choosing AWS is reasonable in the following situations:

• Compliance requirements: finance, healthcare, and government bids may require specific certifications (HIPAA, ISO 27001) and data residency requirements. AWS has the most complete documentation and support in this area
• Large enough traffic scale: monthly active users exceed one million, and you need fine-grained traffic control and cost optimization. At this scale, AWS Reserved Instances and Savings Plans can save a significant amount of money, and you also have enough bargaining power to negotiate discounts with resellers
• You have dedicated infrastructure engineers: if someone is full-time on Terraform, monitoring, and security, then AWS’s flexibility can actually be fully utilized
• You deeply depend on AWS-specific services: services like SageMaker, Kinesis, and DynamoDB have no direct substitutes, and they are core to your product

If none of the above applies, AWS is overkill.

The cost of migrating later

A common counterargument is: “Then start with a simpler platform, and migrate to AWS later when traffic grows. Isn’t migration expensive?”

Migration does have costs, but they need to be broken down:

• Application layer: if your service is containerized (Docker), it can run anywhere. The CI/CD pipeline needs to be rewritten, but that’s a one-time task
• Database: this is the painful part of migration. If the scale is already big enough that database migration must be considered, then the migration itself usually isn’t the problem anymore (you already have the resources and budget to handle it)
• Network architecture: moving from a simple platform to AWS means setting up VPC and ALB from scratch. That does take time, but it’s also a one-time cost

For most startups, the bottleneck isn’t infrastructure failing to scale; it’s that the product hasn’t found product-market fit yet. At that stage, spending two months on AWS infrastructure while not writing a single line of product code is the truly expensive choice.

Infrastructure choices are business decisions

Choosing infrastructure is essentially an investment. And every investment should be judged by its return: what does this money and manpower buy for the company? The answer depends on the company’s current stage and where it needs to go next.

• Early stage: the goal is to find product-market fit. At this stage, the most expensive resource is time. Every extra week spent on infrastructure is one less week validating product hypotheses. Choose a platform that lets you launch tomorrow, and put all your energy into the product itself
• Growth stage: users are increasing rapidly, and the system is starting to feel pressure. Scalability becomes a real issue. This is when it makes sense to evaluate platforms like AWS, because you now have concrete needs (traffic growth curves, performance bottlenecks)
• Preparing for acquisition or IPO: infrastructure choices directly affect financial metrics. Gross margin, pre-tax net profit, and similar numbers are all tied to the cost structure of your infrastructure

Each stage has different infrastructure needs, and the investment scale and return are different too. Betting heavily on AWS before the product is even stable is like spending three months decorating a restaurant before you’ve even decided what kind of restaurant to open.

A trap technical leaders often fall into is using technical language to fight for infrastructure budget. But for executives, what matters is how much ROI the investment brings, how much operating cost it saves, and how quickly it can get the product to market. Learn to communicate in business language, and leadership will take modernization proposals seriously.

Infrastructure choices should evolve with the company’s stage and strategy. Build the product first, validate it, and then decide. You don’t need to prepare for ten years of traffic on day one.