theburningmonk.com
I help engineers build better software faster with serverless | AWS Serverless Hero
Newsletter: https://theburningmonk.com/subscribe
195 posts
1,895 followers
333 following
Regular Contributor
Active Commenter
comment in response to
post
did he say what caused the spike?
comment in response to
post
Thank you 🙏
comment in response to
post
If you liked this, then you might also enjoy the tips and tutorials I publish every week about AWS and serverless.
Subscribe to my free newsletter and level up your AWS game: theburningmonk.com/subscribe
comment in response to
post
You can also put CloudFront in front of your API and cache and handle these preflight requests at a lower cost. This doesn’t eliminate preflight request-related charges entirely, but it goes a long way to minimize it.
comment in response to
post
But for personal projects or side hustles, where margins are tight, cutting these unnecessary costs can make a meaningful difference.
comment in response to
post
Of course, subdomains aren’t inherently bad, and many organizations prefer them to organize multiple APIs and environments. And maybe even let teams have their own subdomains and allow them to be more autonomous.
comment in response to
post
Now, here’s the thing that surprises most folks.
Even if your API is hosted on a subdomain, e.g. api.example.com, the browser still sees it as a cross-origin request from example.com.
Moving the API to example.com/api will eliminate the need for preflight requests altogether.
comment in response to
post
Every time the browser makes a cross-origin request, it first makes a preflight request to make sure it can actually send the request.
Since API Gateway charges per request, you’re billed for both the preflight and the main request.
comment in response to
post
OpenSearch serverless?
comment in response to
post
comment in response to
post
And if you need to migrate them to AWS WAF v2, then here's a handy migration guide:
https://buff.ly/4gKjuDZ
Ok, hope this helps you save a few $$!
comment in response to
post
I saw some WAF charges on my bill and it took me a while to work out where they came from because I couldn't see any web ACLs in the WAF console!
To see if you have any classic web ACLs, go to the WAF Classic console:
https://buff.ly/4gElXQa
and either delete or migrate them before Sep 30, 2025.
comment in response to
post
AWS WAF Classic (or v1) was recently deprecated, and classic Web ACLs no longer appear in the new WAF console.
So it's easy to miss any classic web ACLs you have that are no longer in use, especially if you don't spend much time in the AWS console because you do everything through IaC!
comment in response to
post
Enjoy the shrimp cruise!
comment in response to
post
We only ran ads on Meta platforms, and the numbers looked ok, but almost no conversion.
The 10k was just paying the ad agency to help put the ad together, monitor its performance, tune it, find different audience, etc. Prob spent another 4-5k on ad spend as well.
Very expensive lesson!
comment in response to
post
Here’s what I learned (the hard way)...
1) Online ads are easy to measure, but they are not always the most effective channels.
2) Clicks is a bullsh*t metric; don't get distracted by it.
3) Trust beats clicks/impressions. The most powerful marketing comes from relationships, not campaigns.
comment in response to
post
100%!
comment in response to
post
It was another FaaS that had in-process concurrency to begin with, interesting tech, but maybe too early. They focused more on the data eng space because not many people were using Lambda at scale yet, so the kind of optimization problem they were solving just wasn't commonplace.
comment in response to
post
And that's where I hope they'd copy Vercel functions (and other earlier examples of this, like Binaris) and introduce in-process concurrency, so you can get more out of the Lambda workers. That'd solve a lot of these cost concerns of using Lambda at scale.
comment in response to
post
As far as cost is concerned, very rarely is Lambda an issue, other things like CloudWatch and even API Gateway or VPC-related costs show up long before Lambda itself.
Having said that.. there are use cases where Lambda will legit be expensive, e.g. high traffic websites
comment in response to
post
I find that, most of the time people think Lambda is gonna be expensive for their workload, but they haven't actually done the calculation, probably because they don't know their traffic pattern.
comment in response to
post
I'd argue they already incentivize the use of Lambda by making it very cheap. Not to mention a free tier that doesn't expire after one year of account opening.
AFAIK Lambda is a loss leader and AWS doesn't make money from the Lambda service
comment in response to
post
* retries & DLQ for async invocations
* ESM for polling event sources
* blue-green deployment
there're probably others, but those are things I no longer have to worry about and AWS is taking care of for me
comment in response to
post
2. you get a lot of things out-of-the-box, e.g.
* multi-az redundancy
* load balancing across AZs
* large pool of capacity to scale into on-demand (that you're not paying for when you're not using)
* OS patching on the host
* network security on the host
* patching for managed runtimes
comment in response to
post
Two things:
1. it doesn't necessarily cost more per unit of work. I have seen large EC2 clusters avg sub 5% CPU, if you move those workloads to Lambda, cost per unit of work would be lower because you carry less waste.
comment in response to
post
I typically classify "average 1,000 rps" as "high throughput" and that's when I'd switch to containers
most websites are barely doing 100 rps and can run happily against Lambda and API Gateway
comment in response to
post
for someone else, who have in-house containers expertise, and the dev teams are familiar with both containers and Lambda and can easily switch between the two, they might have a lower threshold for when to switch to containers
comment in response to
post
for Fathom, even at billions of invocations per month, it still makes sense to run Lambda youtu.be/WC4xnBXOT8g
they have a small team, they wanna move fast, and have no specialist ops person, so Lambda is better in total cost of ownership (TCO) terms
comment in response to
post
absolutely, lots people use Lambda as their backend for websites and it works great
stable is the anthesis to burst
but what qualifies as "high-traffic" means different things to different people
comment in response to
post
You missed the "high-traffic" bit.
comment in response to
post
You should use AppSync instead. But there are valid use cases for running Apollo in Lambda if you can't use AppSync for whatever reason.
youtu.be/LBMDewzMShE