When I was researching tools and services for launching a SaaS app, I was pretty clear that I wanted to use Laravel Vapor to manage the Amazon Web Services deployment. The main mystery about that decision was what it would actually cost to have a Vapor-managed deployment on AWS for the size of my application and my expected usage levels.
I found a few articles and blog posts about that topic (the most helpful was Cost & Performance optimization in Laravel Vapor) but, as is the case with AWS hosting in general, there was no clear formula that would lead me to a precise monthly hosting cost for a brand new web application.
In hopes that it helps someone else in a similar situation, I’d like to add one more data point to the mix. Here are some details about what it’s costing me (so far) to host my Laravel-powered application on AWS as managed by Vapor.
Vapor itself is $39/month. This cost does not change if you use Vapor across multiple projects, so your per-project cost can go down over time if you plan to launch more than one project. Some people have raised eyebrows at this baseline cost but as anyone who has ever had to manage their own hosting server infrastructure and worry about upgrades, security issues, configuration management, etc. knows, it feels like a great deal. I wrote about that more in my other post on launching a SaaS business, but this sentiment remains true:
It felt like the magical world of cloud hosting that was always promised but never quite delivered had finally become reality. Even a month later I’m still constantly amazed by it. Huge kudos to the Vapor team.
Now, on to AWS itself. I’m currently paying approximately $1.00 per day for AWS services, and the monthly bill ends up being about $33.00.
A quick profile of the application: there’s a web-based interface that users don’t log in to that often once they set up their account. There’s an API that is used by the web interface, users and a companion WordPress plugin. The app serves up RSS feeds that are presumably refreshed hourly, but are probably not heavily used right now. The most significant activity comes from scheduled jobs that make remote web requests and, depending on the results, queue up lots of other jobs that may themselves spin up a bunch of notifications that go out via email, Slack and webhook.
So with that in mind, and knowing that I’m fairly early in the life of this project with under 100 active users and no sustained spikes in usage yet, here’s what my Vapor metrics look like for a 30-day period:
Here’s how the AWS costs break down for a monthly bill:
- API Gateway: ~37K requests, free tier, $0
- CloudFront: negligible requests, free tier, $0
- CloudWatch: a handful of alarms, 72 requests, 0.118GB of PutLogEvents, 0.313GB of log storage, free tier, $0
- Data Transfer: negligible, free tier, $0
- DynamoDB for caching: ~500K read requests, ~3.3million write requests, $4.22
- Key Management: $0.02
- Lamda: ~84K Lamda-GB-Seconds, ~307K requests, free tier, $0
- RDS: MySQL db.t3.micro x 2 (one for prod, one for staging), $25.30 for the hours running and $2.30 for the storage.
- Route 53: $0.50
- SES: Free tier, $0.00
- SNS: ~960 notifications, free tier, $0.00
- SQS: ~1 million requests, $0.38
- S3: $0.03
Hmm, I think there’s something with caching I need to fix. 🙂
So, most of the cost comes from running two MySQL DB instances in their RDS service. At some point that cost will go up when I need more storage and add at least one more availability zone. At some point I may even go to their Aurora Serverless option.
I expect that at some point I will also move to using Redis for more flexible caching, which will add $10-20/month in costs as well.
Note again that these costs include both a production and a staging environment. Here are the relevant parts of my vapor config for those environments:
- memory: 1024 (prod and staging)
- cli memory: 512 (prod and staging)
- concurrency: 50 prod, 10 staging
- queue-concurrency: 20 prod, 5 staging
- warm: 1 prod, 0 staging
- gateway-version: 2 (prod and staging)
Finally, it’s worth noting that there are cost savings to be had by committing to paying for some of these resources over the course of a year or more. For Vapor, you end up paying the equivalent of $33.25/month if you pay for a full year at a time. For AWS, there are various savings available depending on your setup and services in use.
All in all, I feel like what I’m paying — about $72 per month for hosting-related infrastructure and tooling — is very reasonable for what I’m getting. I realize there are cheaper ways to do it, and that choice of cloud service and configuration is a very subjective thing. For me, the main value comes in the tight integration with my application framework (Laravel) and in the peace of mind knowing that the infrastructure requires very minimal maintenance while being able to scale up on demand.
I hope this helps. If you are using or have used Vapor and feel like sharing your AWS costs, please do!
Updated Nov 20: clarification that these costs are the total for a production and staging environment combined, adding resource config details from vapor.yml
.
Thanks for the insights!
thanks for sharing! Did you go Serverless on the DB just curious. And have you needed Vapor support at all?
The DB is just a standard RDS instance for now, mostly because it worked and seemed like it would be lower cost. It looks like it wouldn’t be a big deal to transition to serverless.
I’ve opened ~10-15 support requests with Vapor support since the start, mostly at the beginning when I was new to how everything fit together. They are usually helpful but the response times can feel slow and sometimes it takes 2-3 back and forth exchanges to get questions answered. I think there’s also a bit of an expectation that you are already knowledgeable about the nuances of hosting Laravel-on-AWS, so if the support question is “basic” for them the response might be a bit terse. Overall it has been fine but not quite what I expected at the Vapor price point.
Great info thanks again.
Thank you for this, a great help. I am trying to cost hosting and migration of a Laravel project to Vapor where the old developer has told the client it autoscales, but they have just stuck the client on a large EC2 instance with RDS. The event booking site becomes unresponsive every time a new event is listed, as you can imagine.
How big (size) was your database? Thanks!