Cloud primitives are not a hosting strategy

This is for engineering leads and CTOs whose application is running on AWS and has been for long enough that nobody questions it anymore. Not for teams in the early stages of evaluating infrastructure options. Not for engineers building platforms for others to use. For the teams where AWS is simply the environment the application lives in, inherited and maintained, and where the question of whether it should stay that way has never been asked directly.

Here is the distinction that changes how you read everything that follows. AWS sells primitives. Sevalla sells outcomes. Most teams on AWS have spent years paying for primitives and doing the work of converting them into outcomes themselves, without ever recognising that the conversion work was optional.

The application is running. That is not the same thing as having a hosting strategy. And the difference between those two things is costing your team more than it looks.

The distinction nobody makes#

A hosting strategy is a deliberate answer to a specific question: how does this application get from code to production reliably, and who is responsible for keeping it there?

A collection of cloud primitives is an answer to a different question: what AWS services did we need to provision to make the application start?

Most teams on AWS have the second thing and call it the first. They have an ALB because the application needs load balancing. They have RDS because it needs a database. They have ElastiCache because it needs Redis. They have SQS because it needs a queue. They have CloudWatch because they needed some kind of logging. They have IAM because everything else requires it.

Each of those decisions was made in response to an immediate need. None of them were made as part of a coherent answer to how the application should be operated over time. The result is not a hosting strategy. It is an accumulation.

The difference matters because an accumulation has no owner. When a service at the edge of that accumulation starts behaving unexpectedly, someone has to understand how it connects to everything else before they can diagnose what is wrong. That knowledge does not live in the services. It lives in the engineers who assembled them, and only there.

What AWS is actually selling#

AWS is a platform for building infrastructure products. It gives teams the primitive components they need to construct whatever they want at whatever scale they need. That flexibility is genuinely valuable. It is also not the same thing as hosting.

When you buy a hosting outcome from a platform designed to deliver one, you are buying a result: the application runs, deployments work, availability is managed. When you provision AWS services, you are buying the inputs required to produce that result yourself. The outcome is yours to assemble and yours to maintain indefinitely.

A production web application typically needs ALB for load balancing, EC2 or ECS for compute, RDS for the database, ElastiCache for Redis, SQS for queues, S3 for file storage, CloudWatch for logs and alerting, Route 53 for DNS, ACM for TLS certificates, and IAM to wire permissions between all of it.

AWS is overkill for most product teams, and that list is exactly why. With Sevalla, you do not need or manage any of those services. Sevalla handles the infrastructure.

Sevalla exists for the 90% of teams who should not be running AWS at all. It is a production-grade platform built for product engineering teams. The outcome — the application runs, deployments work, availability is managed — is what you are purchasing directly. The layer of assembly work that AWS requires between the primitives and that outcome does not exist.

The question worth sitting with is why most teams on AWS have never framed their infrastructure this way. The answer is usually that the primitives were assembled early, they worked well enough, and the cost of running them became invisible through repetition.

The strategy that never got written#

Most teams running on AWS could not write down their hosting strategy in a document that would survive the departure of the engineers who built it. Not because the engineers are not capable of documenting it, but because what they have is not a strategy. It is a set of decisions that made sense individually and are now interdependent in ways that are difficult to articulate without the full context of how they evolved.

The VPC has the subnet structure it does because of a decision made three years ago that nobody fully remembers. The IAM roles have the permissions they do because someone added access incrementally as new features required it and nobody has audited the cumulative result. The CloudWatch alarms fire on the thresholds they do because they were set up during an incident and never revisited. The deploy pipeline has the shape it does because it grew alongside the application one step at a time.

None of this is negligence. It is the natural result of building on primitives without a hosting strategy. The primitives give you the flexibility to assemble exactly what you need in the moment. They do not give you the discipline to ensure that what you have assembled is coherent, documented, and operable by someone who was not there when it was built.

That gap is where your operational risk lives. Not in any individual service, but in the space between them, where the knowledge required to keep everything running is informal, distributed across the people who happen to still be on the team, and fragile in a way that no runbook fully closes.

What a strategy actually requires#

A hosting strategy has three properties that an accumulation of cloud primitives does not.

It has a defined operational owner. Not the engineer who happens to know the most, but an explicit answer to who is responsible for the health of the hosting environment and what that responsibility includes. On most teams running self-managed AWS infrastructure, this is implicit at best and absent at worst.

It has comprehensible failure modes. When something goes wrong, the path from symptom to diagnosis to resolution should be followable by any engineer on the team with appropriate context, not exclusively by the person who built the component that is failing. AWS primitives fail in ways that require AWS-specific knowledge to diagnose. That knowledge is not uniformly distributed across product engineering teams, and the gap surfaces at the worst possible times.

It has a maintenance plan that is actually executed. Every primitive in a self-managed stack has a maintenance surface. AMI patching, RDS version upgrades, ElastiCache engine updates, IAM audits, security group reviews. A strategy acknowledges these and accounts for them explicitly. An accumulation defers them until they become urgent, which is when they are most expensive to address.

Sevalla closes all three gaps by removing the layer that creates them. The operational owner is Sevalla. The failure modes surface at the application layer, where your team already has the context to diagnose them. The maintenance surface is managed, not deferred. Your team's responsibility is the application code, and the hosting strategy is not a document anyone needs to write because it is not a thing anyone needs to maintain.

The cost of mistaking one for the other#

The practical cost of running an accumulation of AWS primitives instead of a hosting strategy is paid every time the accumulation demands attention.

Every incident that requires an engineer to trace through multiple AWS services before they can understand what is failing. Every deployment that breaks in a way that needs AWS-specific knowledge to diagnose. Every new engineer who spends their first weeks acquiring context about the infrastructure rather than contributing to the product. Every sprint where maintenance work displaces feature work because a deferred upgrade can no longer be deferred.

These costs are individually manageable. Each one looks like a normal part of running software in production. The cumulative effect is a product team that is permanently running below its capacity because a meaningful fraction of its engineering attention is consumed by the operational overhead of a hosting environment it assembled rather than chose.

The teams that address this directly do not do it by improving their runbooks or hiring a dedicated DevOps engineer. They do it by changing the answer to the underlying question. Instead of maintaining an accumulation, they choose a platform that delivers the outcome directly.

The question you have not been asking#

The application is running. That will continue to feel like success until the moment it does not, and by then the cost of what you have been running will have been paid many times over in engineering hours and roadmap delays that were never attributed to the right cause.

The question worth asking now, before that moment arrives, is not whether your AWS setup is working. It is whether what you have is a hosting strategy or an accumulation, and whether the difference matters to your team's ability to ship.

For most product teams, the answer to the second question is yes, it matters significantly, and the answer to the first is that what they have is an accumulation held together by institutional knowledge that lives in the heads of engineers they cannot afford to lose.

That is not a hosting strategy. It is a liability. Sevalla is what a hosting strategy looks like when the outcome is the product, and your team's only job is to deploy the application.