I never thought my small site would get DDOS’d, but I guess anything that is public is ripe for abuse. Last week, I had launched 24hourwebhook.com, which provides a free webhook URL that then shares the event data by email or in a Google Sheet. I had set up an SNS topic attached to my email address to let me know when people had signed up.

I was super excited when I received an email about a new signup. The next thing I knew, my email address started getting flooded with hundreds of emails. I quickly noticed that it was just the same request coming in over and over. It was very clear that some funny business was going on.

Thank goodness for CloudWatch metrics. It became pretty clear from CloudWatch that I was receiving 60K+ requests per minute.

24hourwebhook.com is built using 100% serverless technologies: Lambda, DynamoDB, and API Gateway, and it was clear that these services had no problem keeping up with the demand. At first there was a small amount of throttling of requests by DynamoDB, but when going from 0 traffic to 60K+, a little bit of throttling is understandable. I had read about serverless scaling, but I had never experienced it first hand. It is impressive!

But every request technically costs money, so how do I make it stop? All requests were coming through API Gateway. API Gateway only has one way to throttle traffic, through Burst/Rate limit. I ended up setting up a very low limit. This seemed to make the DDOS’er think they had accomplished the tasks of taking down the site and the requests stopped.

So what were the lessons learned?

1. API Gateway - if your endpoint doesn’t have any authentication, make sure you set a Throttling Burst/Rate limit that is reasonable for your use case.

2. While API Gateway doesn’t support WAF, you can put CloudFront in front of API Gateway and add WAF there. That way, you can easily restrict the amount of traffic from a single IP without restricting traffic to all users.

3. While Lambda, DynamoDB, and API Gateway scale amazingly well, email does not. Email through SNS is rate limited, so I was still receiving emails for about a day afterwards. SNS seems to have a fail-safe if too many email requests are sent, as my SNS confirmation was turned off. I learned to be careful when setting up email triggers on user actions. Switching this to CloudWatch Metrics / Alerts is a much better system to use.

4. Billing - I found the bill quite interesting. Since I caught the abuse quite early on, it ended up being around $10, with 80% of that being DynamoDB. I don’t know why, but seeing DynamoDB take so much of the cost surprised me. I guess any database is always the most expensive part.

Hopefully these lessons will help other to avoid the mistakes that I made.

I run a web platform serving 15K+ users. Originally built on EC2 (Node.js monolith), I migrated my background processing and several API endpoints to Lambda over the past year. Here's the real-world experience:

What I moved to Lambda:

• All cron/scheduled jobs (via CloudWatch Events)

• Image processing pipeline

• Email sending

• Webhook handlers

• CSV import/export

What I kept on EC2:

• Main API server (Express.js)

• WebSocket connections

• Long-running processes (>15 min)

What went well:

1. Cost savings were massive Background jobs that ran ~3 hours/day on a t3.medium ($65/mo) now cost ~$12/mo on Lambda. That's an 80% reduction for the same workload.

2. Zero maintenance for scaling During traffic spikes, Lambda just handles it. No auto-scaling groups to configure, no capacity planning. It just works.

3. Forced better architecture Lambda's constraints (cold starts, 15-min timeout, stateless) forced me to write cleaner, more modular code. Each function does one thing well.

4. Deployment is simpler Update one function without touching the rest of the system. Rollbacks are instant.

What I'd do differently:

1. Cold starts are real For user-facing API endpoints, cold starts of 500ms-2s were noticeable. I ended up keeping those on EC2. Provisioned concurrency helps but adds cost.

2. Debugging is harder Distributed tracing across 20+ Lambda functions is painful. Invested heavily in structured logging and X-Ray, but it's still harder than debugging a monolith.

3. VPC Lambda = hidden costs Putting Lambda in a VPC for database access added complexity and cold start time. ENI attachment delays were brutal early on. VPC improvements have helped but it's still not instant.

4. Don't migrate everything My initial plan was to go 100% serverless. That was naive. Some workloads (WebSockets, long-running processes, stateful operations) are genuinely better on traditional servers.

Current monthly cost comparison:

• Before (all EC2): ~$450/mo

• After (hybrid): ~$190/mo

• Savings: ~58%

The hybrid approach — EC2 for the main API, Lambda for everything else — ended up being the sweet spot for my use case.

Anyone else running a hybrid serverless setup? What's your split between traditional and serverless?

Read about when to choose either SQS or SNS for your Serverless applications on AWS. https://blog.theserverlessterminal.com/when-to-sns-or-sqs

Hi everyone!

With Golem Cloud, we’ve introduced a durable computing platform, empowering devs to build invincible applications without traditional DevOps burdens.

In this blog post, you can read more about serverless computing and how it promises a world of NoOps. Explore how you might architect e-commerce checkout, shopping carts, and auctions.

To master serverless, follow Yoda’s advice: “You must unlearn what you have learned.”

Read the blog post here: https://www.golem.cloud/post/serverless-with-golem-cloud

The simplicity of setting up a Kinesis trigger for AWS Lambda function may be deceptive.

This article discusses the 6 most common pitfalls that can cause problems but are usually spotted later in production.

https://dashbird.io/blog/lambda-kinesis-trigger/

We've been working for past 6 months on our serverless headless CMS and just launched it today on Product Hunt.

So why you need another Headless CMS? For a change, with this one you won't worry about scaling, installing, configuring and managing infrastructure. On top of it, Webiny cuts your cloud hosting bill by anywhere between 60% and 80%! You will stop paying for resources you do not use. Now, who doesn't want all that?! I'm sure serverless isn't something I need to explain to this group here :)

Here are some of its features:
✅ Powerful content modelling UI
✅ GraphQL API
✅ Multi-language support
✅ 100% Javascript
✅ Microservices architecture
✅ Support for multiple environments and aliases
... and much more. For a full set of features check out the product landing page

How do we differ from Strapi: Strapi runs on the "traditional" infrastructure, such as virtual machines and similar. That infrastructure is hard to maintain and scale without hiring a big team of expert engineers. Since Webiny runs on serverless infrastructure such as AWS Lambda, it can scale to handle millions of requests out of the box. No need for any performance, devops or network engineers. The other beautiful thing is that with serverless you pay per request. No need to heavily over-provision your infrastructure ahead of peak demand events, such as Black Friday and similar. Stop paying for stuff you don't use*.

How do we differ from Contentful and GraphCMS: Webiny is open-source and you host it yourself. This means you own and have full control over your data. On top of that, you can build custom apps and change any part of the system. Unlike Contentful or GraphCMS where they are a black-box SaaS product which you can't modify.

How do we differ from Netlify CMS: Netlify CMS is a great solution but it lacks many of the features you'll find in Webiny. Netlify CMS caters for more simple sites. For example, a feature like content modelling is done code and configuration files. There is no multi-language support, no environments and aliases. Managing users and permissions is very rudimentary.

----

I would love to hear your feedback on what you think about the product and how we potentially improve it for the whole community. Also happy to answer any questions.

Hi everyone,

We surveyed 278 professionals about serverless technology and adoption and I thought to highlight some of the results here.

Whats's covered in this report?

The first section of the report is focusing on adoption-related questions such as usage of serverless technologies, organizational experience, and more.

The second section covers the benefits and downsides of the technology as well as the most popular use cases and tools to get the most out of serverless technology.

The final part of this report highlights the key decision-makers when it comes to adopting serverless technology. We also wanted to hear the opinions of those who are not using serverless technology, to learn more about the reasons why they haven’t adopted it.

Here's a collection of several key findings based on the community's answers:

1. Currently AWS is the leading provider followed by Azure and Google Cloud.

2. The two biggest benefits of using serverless architecture are flexibility in scaling and speed of development.

3. Node**.js** is the most widespread programming language when it comes to serverless, with Python in second place.

4. The most common use case for serverless is rest APIs, and the second is data processing tasks.

5. The biggest challenge for developers working with serverless is debugging. By far. Architectural complexity is not even close in second place.

We have a bit more stats highlighted in this blog post and many more in the PDF report. See them here: https://codingsans.com/blog/serverless-trends

So as per their documentation, v3 will only be maintained through 2024. So eventually you will have to move to v4 which is now paid unless you fall in certain special category.

Possibly there were seeing good customer traction and now that our APIs are dependent on serverless, they make it paid. What a shit move!

Those who has faced the same issue:

1. What have you done to mitigate the issue?

2. Are there any other good free alternatives? Is AWS cloud formation stack that bad to write IAC?

3. Can someone guide how to do cost estimates for the serverless license?

TIA 🙏