The true cost of owning your Laravel infrastructure

This is for engineering leads and CTOs at product companies running Laravel applications on self-managed AWS infrastructure. Not for teams considering AWS for the first time. For the teams already on it, already feeling the drag, and still treating the infrastructure overhead as a fixed cost of doing business rather than an active choice with visible consequences.

Most product teams running on AWS did not set out to become infrastructure operators. They set out to build a product. Somewhere along the way, provisioning cloud services became maintaining cloud services, and maintaining cloud services became a permanent part of how the engineering team spends its time. That transition happened gradually enough that nobody declared it, and it has been running in the background ever since.

The AWS bill is not the cost of that transition. It is the smallest part of it. The full cost is engineering hours, deployment friction, on-call burden, environment drift, and the compounding drag on product velocity that most teams have never added up. When they do, the decision to keep running self-managed infrastructure becomes much harder to defend.

The invoice you already know#

Start with the AWS bill because it is the only part most teams have measured. A typical mid-sized Laravel application in production runs on a stack that includes an Application Load Balancer, two EC2 instances in an Auto Scaling Group, RDS for the primary database with a read replica, ElastiCache for Redis, SQS for queue processing, S3 for file storage, CloudWatch for logs and alerting, Route 53 for DNS, and ACM for TLS.

At modest but real production scale, that stack costs somewhere between $600 and $1,500 per month depending on instance sizes, data transfer volume, and retention settings. Call it $1,000 as a working number. That is $12,000 per year in cloud spend for an application that is not particularly large or complex by the standards of a growth-stage product company.

That number is real and it belongs in the calculation. It is also the smallest line item on the true ledger.

The engineering hours nobody is counting#

The second line item is engineering time, and it is the one that changes the calculation entirely.

Self-managed infrastructure does not maintain itself. Someone on the team is absorbing the work of keeping it running, and that work is ongoing regardless of whether the system is healthy or not. It shows up in ways that are easy to normalise because they happen regularly enough to feel routine.

Deployment friction is the most visible. The pipeline fails and someone has to diagnose it. The failure might be an expired IAM credential, a changed security group rule, a Docker layer cache miss, or an ECS health check timing out because the new container takes slightly longer to boot than it did last week. Each failure mode lives in a different part of the stack. Each diagnostic process requires context that not everyone on the team has. What should be a fifteen-minute deploy becomes a two-hour investigation, and it happens often enough that engineers start batching changes to reduce how frequently they have to deploy at all. That is deployment friction becoming deployment avoidance, which is continuous delivery running in reverse.

Environment drift is slower but more expensive. Staging and production start identical and diverge over time. A configuration change gets applied in production during an incident and never makes it back to staging. An environment variable gets added to the dashboard and never makes it into Terraform. A security group rule gets loosened temporarily and stays that way. None of these are disasters individually. Together they create a staging environment that is no longer a reliable proxy for production, which means bugs get caught later, surprises happen at deployment time, and the confidence the team is supposed to get from testing against staging quietly erodes.

Initial setup is a sunk cost but it is worth naming. A senior engineer who knows AWS well spends two to three weeks getting a production-grade stack provisioned correctly: infrastructure as code, VPC and subnet design, security group configuration, IAM roles for every service-to-service permission, CI/CD pipeline wiring, database and cache connection configuration, environment variable management across staging and production. That is 80 to 120 hours of senior engineering time that produced zero features and zero product progress.

Ongoing maintenance is where the recurring cost lives. A conservative estimate for a team that is reasonably disciplined about infrastructure work: two to four hours per week on routine tasks, IAM policy reviews, dependency and AMI updates, CloudWatch alarm tuning, deployment pipeline fixes, certificate renewals, and the configuration work that accumulates when you own the stack. That is 8 to 16 hours per month.

Incident response adds to that. Not every month produces a significant incident, but over the course of a year a self-managed AWS stack will generate a meaningful number of unplanned interruptions. A failed deployment that requires an hour to diagnose. A database connection pool issue that takes two hours to trace and resolve. An Auto Scaling event that behaves unexpectedly under a traffic spike and pulls in three engineers for an afternoon. Averaged across the year, incident response typically adds four to eight hours per month of unplanned engineering time.

Total recurring engineering cost: 12 to 24 hours per month. At a loaded engineering cost of $150 per hour, a conservative figure for a senior engineer at a growth-stage company when salary, benefits, equity, and overhead are factored in, that is $1,800 to $3,600 per month in engineering time. Per year: $21,600 to $43,200.

Add that to the AWS bill and the true cost of running a mid-sized Laravel application on self-managed AWS infrastructure is between $33,600 and $55,200 per year. Not $12,000. The invoice is less than a third of the actual cost.

There is a different operational model where deployment friction does not exist because the deployment surface is a Git push, and environment drift does not accumulate because the platform manages configuration consistency across environments. That model is not hypothetical. It is what teams are choosing when they move off self-managed infrastructure. The cost accounting above is part of why.

The on-call tax#

The engineering hours calculation above captures planned work and typical incident response. It does not capture what carrying on-call responsibility for complex infrastructure actually costs the people who carry it.

Most product companies running self-managed AWS do not have a formal on-call rotation with compensation. The expectation is informal: the engineers who know the infrastructure are available when something goes wrong. That availability is always on, even when nothing is going wrong, because the engineers carrying it cannot fully switch off. They know that a deployment might have had an unexpected side effect. They know that a traffic spike can surface a configuration problem that was invisible at normal load. They know that the database maintenance window is this weekend and something could go wrong.

That background readiness has a cost that does not appear in any time tracking system. It affects the quality of evenings and weekends. It creates a low-grade anxiety that does not disappear when the laptop closes. Over months and years, it contributes to burnout in the engineers carrying the most infrastructure context, which are almost always the most experienced and most valuable engineers on the team.

The downstream cost is turnover. When an engineer who carries significant infrastructure knowledge leaves, the team does not just lose a developer. It loses the operational knowledge that kept the system running in ways that no documentation fully captures. Replacing that engineer costs recruiting fees, onboarding time, and a period of elevated operational risk while their replacement acquires the context they need. A conservative estimate for the cost of replacing a senior engineer at a growth-stage company is $50,000 to $100,000 when all of those factors are included.

Infrastructure ownership does not cause all engineer turnover. But it contributes to it, and teams that carry significant infrastructure complexity have a higher risk of losing the people most critical to operational stability.

The opportunity cost nobody calculates#

The most significant cost of infrastructure ownership is the one that is hardest to quantify because it is invisible: the product work that does not happen because engineering time is consumed by infrastructure instead.

Every hour a senior engineer spends on IAM policy reviews, deployment pipeline debugging, CloudWatch alarm configuration, or incident response is an hour not spent on architecture decisions, code review, performance improvements, or feature development. That substitution happens quietly, sprint by sprint, in the routine allocation of engineering attention.

The backlog items that keep getting pushed are not random. They are disproportionately the work that requires deep, uninterrupted focus from experienced engineers: architectural improvements, performance work, the features that require careful design before implementation. Infrastructure overhead does not displace the routine work. It displaces the high-leverage work, because high-leverage work is what experienced engineers do and experienced engineers are the ones absorbing the infrastructure burden.

The compounding effect runs over years. A team shipping 80% of its potential product velocity because 20% of engineering attention goes to infrastructure does not fall 20% behind its competition. It falls further behind, because the work not getting done is not evenly distributed. The architectural decisions not made thoughtfully become technical debt. The performance improvements not shipped become user experience problems that drive churn. The features that arrive late because infrastructure work ran over are the features that were supposed to drive growth this quarter.

That is the cost that does not appear in any calculation most teams have done. It is also the cost that matters most.

What the ledger actually shows#

Bring the full accounting together. A typical mid-sized Laravel application on self-managed AWS costs approximately $12,000 per year in cloud spend. It costs an additional $21,600 to $43,200 per year in engineering time for routine maintenance and incident response. It carries ongoing deployment friction and environment drift that quietly reduce team velocity every sprint. It carries on-call risk that contributes to engineer burnout and turnover, with replacement costs of $50,000 to $100,000 per departing infrastructure-knowledgeable engineer. And it consumes a fraction of senior engineering attention that would otherwise go to the product work that drives business outcomes.

The AWS invoice is the visible part. The rest of the ledger is what most teams have never added up. And the teams carrying this cost are not getting anything from it that a better-matched platform would not give them more reliably for less.

With Sevalla, the cloud spend is lower, the engineering time cost is near zero, and the on-call risk is bounded to the application layer. Your team deploys from Git. Sevalla handles runtime orchestration, networking, scaling, failover, observability, and deployment workflows behind the platform boundary. The deployment friction does not exist. The environment drift does not accumulate. The infrastructure maintenance surface that AWS asks your team to own permanently simply does not exist.

Sevalla exists for the 90% of teams who should not be running AWS at all. The full-cost comparison is not close.

The calculation your team has not done#

Before the next infrastructure budget conversation, put the full ledger on paper. The AWS bill is already there. Estimate the engineering hours honestly: routine maintenance, incident response, deployment debugging, security reviews. Apply your team's loaded engineering cost. Add an honest assessment of the on-call burden and what it is doing to your most experienced engineers.

Then look at your product backlog and identify the items that keep getting displaced. Assign them a business value. That is the opportunity cost column.

The total is the true cost of owning your Laravel infrastructure. For most teams that do this calculation honestly, the number makes the decision straightforward. Sevalla is worth the comparison.