Exploring the Future of Serverless with Sheen Brisals: Why It's Becoming the New Norm
Since serverless is designed to scale to infinity, one of the questions we get asked very often is whether a DDoS attack on the serverless application can result in a hefty Cloud Bill. One way to prevent this is to have rate limiting on API Gateway in place so that the serverless application doesn’t scale to unexpected levels and end up using all underlying resources.
Other than rate limiting at the API Gateway level, AWS offers a service called WAF (Web Application Firewall) that is dedicated to protecting the internet-facing services of AWS like API Gateway, AppSync, App Runner, Application Load Balancer, CloudFront, and Cognito.
WAF offers various predefined configurations to protect the applications from known threats like DDoS, SQL Injection, and XSS. WAF calls these configurations Managed Rules. You could write up your own Rules, or use various rules that are available to use on the WAF Console. A few of these are free to use and provided by AWS, while you could find advanced rules from third-party providers through AWS Marketplace.
Custom WAF Rules allow us to build for the use cases like Geographical and IP Based Restrictions for AWS Serverless applications. Even though scaling is the main feature of serverless architecture, an underrated feature of serverless is pay-per-use. This makes serverless go-to architectural patterns for building internal applications that might not expect a large amount of traffic. In a few such use cases, due to security and privacy reasons, users would expect the applications to be limited to their private networks. That can be achieved by creating an IP-based rule on WAF.
First, we create an IP Set that lists the IP Range where requests are expected to originate. This could be the IP range from a VPN Service, Private network, etc. Once that is created, we add a custom rule on the WAF Web ACL that enables only requests from the IP Set to be forwarded to the service and block the rest of the requests.
As a last step, we have to associate the WAF Web ACL with any of the services that need to be restricted. Once the setup is complete, we can continue to monitor the requests coming in and what percentage of requests are allowed or blocked on the WAF console or the CloudWatch Logs. If you want to handle the errors thrown from WAF for blocking the requests separately, you can configure the WAF Rule to add additional headers and responses when it rejects the request.
An additional scenario where WAF proves beneficial for serverless applications is in protecting against web scraping and automated bots. The AWS Managed Rule - Bot Control can effectively block such activities. Further bolstering these defenses is WAF’s new feature, Application Integration. By incorporating the WAF SDK into client applications (web or mobile), you can ensure API requests originate from authenticated clients, analyze usage patterns, and gather valuable telemetry. This feature also facilitates seamless CAPTCHA integration into your application’s forms or functions.
It’s worth noting that AWS WAF pricing is based on the number of Web ACLs and requests processed. The cost structure includes a fixed rate of $5 per month per Web ACL and $0.60 per million requests. To help you plan your expenses, make sure to estimate your application’s traffic and the number of Web ACLs needed. For up-to-date pricing information, you can check out the AWS WAF Pricing page
You can find SAM Template for the whole setup on this GitHub Repository.
For more security best practices about Serverless on AWS, you can watch our past webinar - Demystifying Serverless Security on AWS: Increase your Serverless Application Security
