Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
Since our latest update, Dashbird also gives you insights into HTTP API Gateway. Let’s look at the differences between REST vs. HTTP; HTTP API Gateway pricing, integrations and monitoring.
Back in the days when AWS released the first version of API Gateway, they tried to make it a higher level than the phalanx of load balancers they already offered. It’s serverless and follows a RESTful approach to API modeling, allowing users to use the OpenAPI spec to define their APIs.
While REST is an excellent approach for most APIs, it isn’t for everyone, and also, WebSockets were missing from the service. This meant people had to either go with REST and without WebSockets when they wanted a serverless proxy, or they had to go for the application load balancer, which was more low-level but not serverless.
These drawbacks were why they built a new version of API Gateway, called HTTP API Gateway, or API Gateway V2. It comes with the same serverless goodies as automatic scaling and on-demand pricing but offers WebSocket support and isn’t bound to REST API design.
REST is an API design paradigm created by Roy Fielding. His goal was to give people a tool to design APIs on top of HTTP without all the issues other paradigms like SOAP had in the past. So, REST tries to formalize HTTP to make it more usable for API use-cases.
In turn, HTTP is more flexible; there are other ways to build an API on HTTP that don’t follow the REST approach. These include AsyncAPI and GraphQL. In contrast to REST, they have different opinions on endpoint design and using WebSockets to allow real-time interactions.
So, if you’re building a simple CRUD API, you can save much time by just going with the REST API Gateway. But if you need to be more flexible, use the HTTP version, but keep in mind that it comes with less help out of the box.
API Gateway has a 12-month free tier. That includes these limits for every month:
For the first 300 million requests after the free tier, you pay $1 per million; after that, $0.90.
For the first 1 billion (yes, billion) WebSocket messages, you also pay $1 per million; after that, $0.80 for the next million.
So, the HTTP API Gateway is quite a bit cheaper than the REST version, which costs about $3.50 per one million requests.
The integration options of the HTTP API Gateway are also a bit limited. While the REST API offers direct integrations with dozens of AWS services, the HTTP version only offers Lambda and HTTP integration. This means if you don’t want to integrate with Lambda, your downstream service has to provide an HTTP API.
The Lambda integration is a one-click solution to map a route to a Lambda function; it will automatically forward headers, body, query parameters, etc. Lambda is seen as the default backend for serverless applications, so AWS made its configuration as straightforward as possible.
The HTTP is the catch-all solution. If you want to pipe your requests to another service, HTTP API Gateway will simply proxy it via HTTP. Luckily, you can ensure the downstream service gets the information it needs with parameter mappings.
HTTP API Gateway lets you authorize users for your APIs via JSON Web Tokens or an Authorizer Lambda function, which will be called alongside every request. This can get quite expensive; that’s why the Lambda response can be cached. All this can be configured; for some APIs, authorization caching isn’t an option for security reasons; for others, it might not pose an issue.
The Lambda function can return either a simple boolean value, true for “has access” and false for “doesn’t have access,” or an IAM document that goes into more detail about what the client is allowed to do. This lets you add authorization features to all your HTTP backends with just a few clicks.
The whole HTTP approach is more flexible and, what’s probably most interesting, it’s much cheaper than REST. That alone is perhaps enough to migrate away from the REST version.
But things are different enough between the two that you should consult a migration guide before doing so. The web console looks different; CloudFormation requires you to use other resources, the Lambda integration works differently, etc.
So, sadly, it isn’t just incrementing a version number, adding an HTTP switch, and things are done. But people have already written several articles about this migration and its gotchas. Check out this excellent migration guide from Serverless Guru to get things sorted.
Last month, Dashbird released a big update that includes more services to their monitoring. HTTP API Gateway is one of them. Historically, API Gateway was one of the more expensive parts of serverless architectures, and with Dashbirds new update, you can now get those sweet savings while still maintaining insights.
With the new integration, you can ensure that your gateways won’t go down without notice.
Dashbird gives you the current errors and alerts you when the error percentage rises to a critical level. This includes 4XX and 5XX HTTP errors.
You also get insights into your latency over time and notifications if it increases or is about to hit a timeout.
Last but not least, you get notified of abandoned gateways. That is, gateways you deployed to the cloud, but that aren’t used anymore.
HTTP API Gateway is more flexible for non-REST API design and cheaper than the REST version. If you only have a few routes that need to be handled by a Lambda function, it is your best bet.
But HTTP API Gateway integrations are limited to HTTP services, which takes away from that flexibility again. If you see yourself putting Lambda functions between your gateway and your services by the dozen, you might not save any money and raise the complexity of your stack needlessly. That’s when you can be better served by a REST API Gateway that offers cheaper integrations to other AWS services.
But independent of HTTP and REST, Dashbird got you covered.
Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.
In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.
In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.