If you're still on vanilla AWS, you're on legacy cloud

AWS has turned into a ball of complexity. If you are still on vanilla AWS, you are stuck in configuration hell. For a startup, that is worse than for an enterprise: you do not have a platform team on retainer. The good news: AI-native and serverless-first platforms (what people are calling Cloud 2.0) make it easier to untangle yourself. First you move to lighter-weight, better-abstracted services. Then you step off the platform when you are ready.

Why vanilla AWS is legacy in practice

Hundreds of services and endless knobs. Every new capability adds another IAM shape, another network path, another pricing dimension. The more you customise, the deeper you sink into a maze only a handful of people on your team can navigate. At ten or thirty people, that person is often you, or nobody.

Cost surprise every month is not a personality flaw. It is the product. Per-hour compute, per-GB egress, commitments and tiers: the bill rewards whoever has time to decode it. Startups I speak to in ANZ are not naive. They are tired of FinOps eating the week they needed for product.

Outage fragility is not theoretical. When a major region stumbles, the blast radius is enormous because everything hangs off the same dependency graph. If your whole stack is in one account and one pattern, you learn that lesson in public.

Velocity dies in the gaps. You wanted to ship a feature. Instead you are debugging VPC endpoints, chasing a quota, or explaining to finance why last month looked nothing like the forecast. That is not "being bad at cloud". It is what vanilla AWS optimises for at small scale.

In short, the "cloud" you pay for today often behaves like a glorified data centre that still expects you to manage servers, patch images, and babysit capacity. That is legacy, even when the logo says cloud. For a startup, legacy shows up as runway burned on plumbing.

Configuration hell and the consultancy gravity well

Here is the part founders say quietly. The platform is so wide that "best practice" architectures become bespoke. IAM hierarchies, cross-account patterns, landing zones, guardrails: each layer sounds sensible in isolation. Together they create a system your team cannot change without either a senior hire you cannot afford yet, or a partner on monthly retainer.

Consultancies and partners are not cartoon villains. They are often the only people who can touch the wiring without blowing up prod. The side effect is dependency. Without that help, releases stall. With it, you ship, but portability suffers and your burn includes line items that do not show up on Jira. The build fits AWS the way a custom suit fits one body.

Startups get squeezed twice: you pay for the cloud, then you pay again to keep the cloud understandable. Complexity does not have to be a conspiracy to become a trap. It only has to outpace your headcount.

Naming that pattern is the first step to reversing it. The second step is choosing abstractions that default to boring operations, not bespoke ones.

AI is lowering the exit barrier

Generative AI and agent-style tooling do not erase migration risk. They compress the boring parts: dependency mapping, boilerplate infra, test harnesses, and repetitive refactor. That matters because the old reason to stay was simple: leaving cost too much time and too many specialised heads.

A pragmatic sequence many teams are discussing: get data onto platforms you control or can move (BYOC, portable warehouses, open file formats). Then move compute to services that bill for use and cold-start in seconds, not hours of committee. Then wire security, backup, and observability in a composable way so you are not trading one jail for another.

Cloud 2.0, in this sense, is not a vendor press term you have to worship. It is shorthand for: serverless or edge-first runtimes, AI-aware developer surfaces, per-second or scale-to-zero economics, and architectures that assume multi-cloud or exit as normal, not shameful.

Platforms worth a serious look

None of this is "replace AWS with vibes". It is replace undifferentiated heavy lifting with services that default to good behaviour.

• Daytona. Sandboxes built for agent and CI workloads: fast spin-up, snapshots, Docker-compatible isolation. Useful when you want repeatable environments without nursing clusters.
• Unikraft Cloud. Unikernel-flavoured serverless with very low cold-start latency and a smaller attack surface than generic VMs for many shapes of work.
• Cloudflare. Workers, R2 (egress-friendly object storage), Workers AI, and a growing agent-oriented surface. Global edge and Sydney or Melbourne POPs matter when your users are spread out and you cannot babysit regional VPCs.
• PlanetScale. Serverless MySQL and Postgres ergonomics with branching workflows teams actually use.
• ClickHouse Cloud. Columnar analytics with aggressive performance for the price when your workload fits OLAP.
• VeloDB. Real-time analytics (Apache Doris lineage) with SaaS and BYOC options when you need residency flexibility.
• Snowflake. Elastic SQL data cloud with Iceberg tables, governed sharing, and AI over your own datasets, when one managed surface for analytics and collaboration beats stitching lake, warehouse, and policy stacks yourself.
• Databricks. Lakehouse and AI workloads where that model already matches how your team works.
• RunPod and Modal. GPU capacity billed in small slices, strong for experimentation, fine-tuning, and bursty inference without parking expensive instances.
• Bare metal and orchestration. Providers like Latitude.sh (including Sydney) for metal when you want predictable performance without the hypervisor tax, plus modern GitOps, immutable backups, and OpenTelemetry so you own the story end to end.

Many of these run on top of hyperscale infrastructure somewhere. The point is the abstraction: you buy outcomes and limits you understand, not a thousand services you must integrate by hand.

A pragmatic migration sequence

You do not win a prize for ripping everything out on a long weekend. You win for sequencing risk and proving value.

A twelve-month roadmap might move a large slice of spend to these patterns while keeping a modest footprint for things that truly belong on legacy shapes. The exact percentage is your data, not mine. Run the numbers on your own bill before you promise the board or your investors a percentage.

Why startups should move deliberately, not blindly

Runway is the only metric that cannot be faked. Egress, idle compute, and surprise line items are not "later problems" when you are pre-profit. They are this quarter's problem.

AI workloads are pushing GPU demand and budget volatility. Legacy instance families and egress-heavy patterns are a bad match for bursty experimentation. You want per-second billing and a path back to zero when the experiment ends.

Talent expects usable platforms. Early engineers join to build product. If your internal story is "wait six weeks for a VPC peer", they will join the competitor who ships from a sandbox in an afternoon.

ANZ is a small market with a loud community. Word gets around which teams respect craft and which ones drown in tickets. Getting off vanilla AWS is not about ideology. It is about protecting speed and cash while you still have both.

What you can do today

• Export your cost and usage data. Highlight services that look busy on paper but idle in practice. One clear chart beats six months of vibes.
• Pick one low-risk pilot: an API on Cloudflare or Unikraft Cloud, or a bounded analytics path on ClickHouse Cloud, Snowflake, Databricks or VeloDB. Measure latency and cost before you argue in Slack.
• Write down who on the team can actually operate your current stack in a crisis. If the answer is a vendor or one exhausted person, you already have a hiring problem dressed up as architecture.

If you want help mapping that for your top workloads, reply here or email me at peter@cloudshuttle.com.au. We bring the same data-driven, open-source lens we use in DataEngBytes to migration and architecture work. No theatre, no lock-in fantasy: a concrete plan and honest trade-offs.

If you are still on vanilla AWS, you are on legacy cloud. The fastest way out is to start using Cloud 2.0-style services today, then step off the platform when your data model and your runway say you can.

Peter Hanssens
Principal Consultant, Cloud Shuttle | Founder, DataEngBytes & AIEngBytes