In 2026, You Might Not Need AWS

What is your team’s reason for choosing AWS?

If the answer is “big companies use it,” “the boss told us to,” or “that’s how we did it at my last job,” this article might offer some food for thought.

The Hidden Costs of AWS

The surface cost of AWS is the number on the bill. The true cost lies elsewhere.

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

• VPC: Network isolation, subnets, and CIDRs
• ALB: Application Load Balancer for traffic distribution and health checks
• ECS Cluster + Service + Task Definition: Core container configurations
• ECR: Container Registry—and you usually need one each for dev, staging, and production
• IAM Roles: Access management across Task Execution Roles, Task Roles, and Service-Linked Roles
• EIP: Elastic IPs (if you need static IPs)
• NAT Gateway: Allowing containers in private subnets to access the external internet
• Route 53: DNS management
• CloudFront: Necessary if you want a CDN or want to avoid exposing your ALB directly to the public internet

And that’s just the infrastructure. You haven’t written a single line of application code yet.

Get a single Action wrong in an IAM Policy, and the container fails to pull the image from ECR. The error message will only show CannotPullContainerError, without telling you it’s a permissions issue.

Forget to configure the NAT Gateway, and the container spins up but can’t reach any external APIs. You might burn half a day debugging before realizing it’s a network route issue.

In mature organizations, these workflows are usually standardized—you just follow the playbook.

At my previous company, we used a private cloud with one-click Kubernetes cluster provisioning. Even with VPS instances, standard configuration scripts were built-in; monitoring, OS tuning, logging, and bastion hosts were automatically set up right after an instance was launched.

Early-stage startups rarely have this level of tooling. These tasks create zero product value, yet they tie up the bandwidth of at least one engineer.

In my article on ECS deployment strategy, I estimated that for a 5-person team, the hidden annual cost caused by overly complex deployment workflows runs around NT$2–2.5 million.

Let’s look at fixed monthly costs first:

• A NAT Gateway costs at least $32 USD/month, regardless of traffic.
• ALB base fees run $16 USD/month.
• A 2 vCPU / 4GB Fargate task costs $70–80 USD/month in compute alone.

Before running any real workload, you’re already past $120 USD/month.

AWS data egress is billed per usage. In the Tokyo region, it’s $0.114 USD per GB. For a typical web service behind a CDN, 400,000–500,000 monthly active users (MAU) will generate roughly 1 TB of egress, translating to about $117 USD/month in bandwidth fees.

Without a CDN, you could hit that same 1 TB with just 15,000–20,000 MAU. Add in NAT Gateway data processing fees ($0.045/GB), and that adds another $46 USD per TB.

These bandwidth fees rarely show up in early estimates because traffic is low at launch. But as user numbers grow, the bill quietly balloons. Between fixed costs and egress, cracking $300 USD/month happens fast.

Simpler Alternatives Exist Today

In the past, people chose AWS because viable alternatives were scarce. Today, things are different.

Vercel deserves a closer look. Next.js has introduced noticeable complexity in recent years: React Server Components require developers to remain aware of client vs. server boundaries, alongside the trade-offs between ISR, CSR, and SSR.

However, Vercel’s integration with Next.js is remarkably polished (by design—it is their core business strategy). A Next.js project deploys with a simple git push.

A few services I personally enjoy:

• Railway: Its UI and deployment experience are exceptional. It offers a solid CLI and native support for multiple environments.
• Supabase: Features built-in auth that hooks directly into client SDKs without custom boilerplate, along with CRUD APIs and a web-based table editor.

I’m keeping a close eye on Zeabur and use it for all my personal side projects. That said, I currently hesitate to recommend it for production setups for a few reasons:

• Product direction: It started by attracting developers with subsidized, free tiers, then pivoted into a deployment service for “vibe coders,” and is now repositioning as AI DevOps. While early-stage startups naturally iterate to find product-market fit, frequent pivots introduce instability for businesses relying on them.
• Recent reliability: I’ve encountered outages on Zeabur a few times recently.

Zeabur has also moved away from shared clusters; you now bring your own servers, and Zeabur provides a unified control plane to manage them. I will continue following their progress.

Another tool I’ve been eager to try is PlanetScale, led by former GitHub VPoE Sam Lambert. Here are the features that stand out:

• Database branching: Branching at the database level. You modify and test schemas in an isolated environment before merging. This is invaluable when shipping feature branches that involve heavy schema migrations.
• Deploy requests: Schema changes aren’t applied directly to production. Instead, you open a deploy request to inspect diffs and review changes before deploying—streamlining what used to be a tedious DBA review process.
• Developer experience: They don’t just provide a database instance; the developer tooling ecosystem is thoughtfully pre-packaged.

AWS is no longer the only viable option. We just tend to forget alternatives exist once AWS becomes the default reflex.

When AWS Still Makes Sense

Choosing AWS remains entirely justifiable in the following scenarios:

• Strict compliance requirements: Fintech, healthcare, or government contracts that demand specific certifications (HIPAA, ISO 27001) and strict data residency rules. AWS offers the most comprehensive documentation and compliance support here.
• Massive traffic scale: Millions of monthly active users, requiring granular traffic routing and aggressive cost optimization. At this scale, AWS Reserved Instances and Savings Plans yield substantial savings, and you have enough leverage to negotiate reseller discounts.
• Dedicated infrastructure engineers on staff: Having full-time engineers dedicated to Terraform, observability, and security allows you to actually harness AWS’s flexibility.
• Deep integration with AWS-proprietary services: Core products built heavily around proprietary services like SageMaker, Kinesis, or DynamoDB that lack direct drop-in replacements.

If none of these apply to you, AWS is likely overkill.

The Cost of Migrating Later

A common counterargument is: “What if we start on a simpler platform and then have to migrate to AWS once traffic explodes? Won’t migration costs be sky-high?”

Migration does carry a cost, but it’s worth breaking down:

• Application layer: If your services are containerized (Docker), running them anywhere is essentially identical. Rewriting CI/CD pipelines takes effort, but it’s a one-off task.
• Database: This is the painful part. But if you have reached a scale where moving databases is mandatory, you generally have the resources and budget to execute it.
• Network architecture: Moving from a PaaS to AWS means setting up VPCs and ALBs from scratch. It takes time, but it’s also a one-time effort.

For most startups, the bottleneck is rarely infrastructure failing to scale; it’s failing to find product-market fit. At this stage, spending two months configuring AWS infrastructure before writing a single line of product code is the truly expensive decision.

Choosing Infrastructure Is a Business Decision

Choosing infrastructure is fundamentally an investment. With any investment, you have to ask for the return: what does this expenditure of capital and engineering bandwidth actually yield for the company? The answer depends on where the company is right now and where it needs to go next.

• Early stage: The objective is finding Product-Market Fit. The most precious resource is time. Every week spent on infrastructure is one less week spent validating product hypotheses. Choose a platform that lets you ship tomorrow, and pour your energy into the product itself.
• Growth stage: User counts are surging, systems begin feeling the strain, and scalability becomes a real challenge. This is when evaluating platforms like AWS is worthwhile, because you now have concrete requirements (traffic growth trajectories, specific performance bottlenecks).
• Preparing for acquisition or IPO: Infrastructure decisions directly affect financial metrics. Gross margins and EBITDA are inextricably tied to your infrastructure cost structure.

Each stage demands different infrastructure, with distinct investment scales and returns. Betting heavily on AWS before product validation is like spending three months on interior design before deciding what kind of restaurant you’re opening.

A common trap for tech leaders is pitching infrastructure budgets in purely technical terms. Executive leadership cares about ROI, operational cost savings, and time-to-market. Learning to communicate in business terms is what makes leadership take modernization proposals seriously.

Infrastructure choices should evolve alongside company stages and strategy. Build the product first, validate it, and take it from there. You don’t need to engineer for decade-ten traffic on day one.