Overview
IMPORTANT NOTICE: Please Use Our Updated AWS Marketplace Listing:
https://aws.amazon.com/marketplace/pp/prodview-ebibeg6eyrats
This AWS Marketplace listing for Serverless Framework is no longer active for new purchases. To ensure a seamless experience, please visit our updated AWS Marketplace listing, which supports both pay-as-you-go and reserved options, offering greater flexibility to meet your needs.
While existing customers using this listing can continue without disruption, new purchases or transactions through this listing will not be processed. The updated listing provides the same powerful features of Serverless Framework, including deployment, monitoring, and management of serverless applications, with the added benefit of improved purchasing options.
If you have any questions or need assistance, please contact us at awsmarketplace@serverless.com . We're here to help ensure a smooth transition to the updated listing.
Highlights
- Develop - Simplifies serverless development on AWS Lambda by allowing users to define applications as functions and events, deploy infrastructure and code with a single command, and extend capabilities with plugins and extensions.
- Troubleshoot - Provides built-in top-tier debugging tools, including metrics and alerts for tracking performance and errors, and the ability to query and inspect every request for detailed issue analysis.
- Collaborate - Facilitates team collaboration by managing all serverless applications in one place, securely sharing secrets, outputs, and AWS accounts, and sharing AWS Lambda function tests.
Details
Introducing multi-product solutions
You can now purchase comprehensive solutions tailored to use cases and industries.
Features and programs
Buyer guide

Financing for AWS Marketplace purchases
Pricing
Dimension | Description | Cost/month |
|---|---|---|
15 Credits | Base price with no discount. | $60.00 |
50 Credits | 12.5% volume discount. | $175.00 |
300 Credits | 37.5% volume discount. | $750.00 |
15 Credits (20% Small Business Discount) | Additional 20% discount if you qualify as a small business. | $48.00 |
50 Credits (25% Small Business Discount) | Additional 25% discount if you qualify as a small business. | $131.00 |
300 Credits (50% Small Business Discount) | Additional 50% discount if you qualify as a small business. | $375.00 |
Vendor refund policy
This service is a pay-as-you-go monthly service. Refunds are not available. Please visit https://app.serverless.com/ for more payment schedule options.
How can we make this page better?
Legal
Vendor terms and conditions
Content disclaimer
Delivery details
Software as a Service (SaaS)
SaaS delivers cloud-based software applications directly to customers over the internet. You can access these applications through a subscription model. You will pay recurring monthly usage fees through your AWS bill, while AWS handles deployment and infrastructure management, ensuring scalability, reliability, and seamless integration with other AWS services.
Resources
Support
Vendor support
For support, please contact awsmarketplace@serverless.com .
AWS infrastructure support
AWS Support is a one-on-one, fast-response support channel that is staffed 24x7x365 with experienced and technical support engineers. The service helps customers of all sizes and technical abilities to successfully utilize the products and features provided by Amazon Web Services.
Similar products

Customer reviews
Serverless workflows have boosted rapid AWS development but still need better CI and automation
What is our primary use case?
My main use case for Serverless is that I mainly worked on Node.js serverless applications for my platforms, and I have worked with different domains, spanning three or four domains with Serverless .
A specific example of how I used Serverless in one of those domains is that I mainly worked with AWS infrastructure using the AWS stack, including S3 , AWS Auth, and Cognito. I use several AWS services with Serverless and Node.js.
What is most valuable?
Serverless helps me with data processing in AWS by making infrastructure deployment very easy. With a single click, it automates everything when I am working inside AWS infrastructure. The development is also very fast and easy to implement, and it is not a complex architecture compared to Spring Boot , MVC, or other infrastructures.
The best features Serverless offers for me include automated deployments, which are very smooth and interesting. As a full-stack engineer, Serverless really helps me to reduce my DevOps cost. Another valuable feature is the offline mechanism, and I have used AWS LocalStack with Serverless Offline, which is really interesting and helps me to simulate cloud infrastructure without any cost on my machine.
Automated deployments and the offline mechanism impact my workflow positively because when I configure the Serverless application in the serverless.yml file, I can configure everything, such as AWS services I have used in my application, including S3 configuration, Cognito configurations, and database configuration as separate YAML files integrated into one Serverless file. Then I just click on the NPM deploy, develop, or any staging option, and it automatically deploys to my AWS CloudFormation stack, creating the entire service.
Serverless positively impacts my organization by allowing us to work as a startup with very limited resources and costs. When we go with a Serverless infrastructure, we reduce the need for specialized resources, especially on the DevOps side, because everything becomes automated, enabling our full-stack engineers to perform that work. Reducing resources means we reduce cost as well, and it is time-saving since deployment does not take hours but rather depends on our network speed.
Serverless helps with scaling my applications as the organization grows by not restricting the inclusion of more components or modules in the Serverless applications. However, there can be some restrictions. For example, AWS S3 only supports a maximum file upload of 250 MB using Serverless. Despite a few concerns, from a Serverless point of view, integration and implementation of our logic into applications remain very easy.
What needs improvement?
Serverless has many advantages, and it is very easy to handle with a cloud solution. However, there are a few concerns about the limitations. Especially when I work with Lambdas, there are maximum Lambda timeouts. Likewise, there are several things from Serverless, such as maximum file uploads.
Serverless can be improved by addressing the challenges faced when we have the first infrastructure. Sometimes it is hard because we need to manually create things such as Cognito pools. While 90 percent of the time is automated, more automation would be better. If Serverless provided CI/CD capabilities, that would also be great, as currently it only allows for manual deployments. Additionally, when working with cloud services, Serverless allows the use of LocalStack or Serverless Dev, but I think Serverless Dev might need simplification for easy access without organization registration.
When considering needed improvements, I get frustrated with Lambda time and similar issues, which are actually not related to Serverless but rather are AWS issues. However, when discussing Serverless, the main points I see require improvement from the Serverless end.
For how long have I used the solution?
I have been using Serverless for almost close to two years.
What do I think about the stability of the solution?
Serverless is stable. With the arrival of Serverless v4, I observe it has good features and improvements over the past few years, hence it appears stable for specific domains and applications.
What do I think about the scalability of the solution?
Serverless helps with scaling my applications as the organization grows by not restricting the inclusion of more components or modules in Serverless applications. However, there can be some restrictions. For example, AWS S3 only supports a maximum file upload of 250 MB using Serverless. Despite a few concerns, from a Serverless point of view, integration and implementation of our logic into applications remain very easy.
Which solution did I use previously and why did I switch?
I have used several solution frameworks previously, including Java Spring Boot and NestJS with EC2 , among others. The decision to switch to Serverless is based on the project or company requirements. If I was working in a very large enterprise application, I would choose Java over Serverless. However, for this startup, we determined that Serverless was the most suitable framework, and I am open to switching frameworks in the future as per the architecture needs of the application.
What was our ROI?
In terms of time or cost saved compared to before using Serverless, I save approximately 60 percent of my development time because everything is very lightweight and gives me the freedom to work within Serverless. Similarly, regarding cost, when I reduce time, I should automatically reduce cost as well. About deployment, we handle deployment more than 80 percent faster, so we do not need to have a specialized DevOps engineer as my full-stack skills cover it.
What's my experience with pricing, setup cost, and licensing?
Regarding pricing, setup cost, and licensing experience, I find the application to be very cost-effective. The headcount needed is much lower compared to supporting services in software development, particularly in DevOps or technical writing roles. Overall, it is lightweight and should be cost-effective compared to other frameworks, which is why we choose Serverless for its suitability in small applications that need to be lightweight and quickly delivered.
Which other solutions did I evaluate?
Before choosing Serverless, I considered other solutions such as Express with AppRunners, but I found that version to be time-consuming compared to traditional Serverless with more manual interference, especially regarding deployment and DevOps. I also checked Spring Boot, but it did not match our application needs, focusing instead on AppRunners with Express as a viable alternative.
What other advice do I have?
Serverless affects my team's productivity and collaboration by presenting some challenges. For instance, when we work in parallel, deploying two different versions at the same time can lead to issues or conflicts, where resources may not be generated successfully. However, these challenges are manageable since we typically avoid deploying two versions at the same time in actual production development.
Serverless handles monitoring and troubleshooting effectively by integrating with CloudWatch, allowing for easier understanding of logs. Serverless also possesses extensive documentation and references, making it easy to resolve any issues related to its functionality, although logic issues might require different handling.
My advice to others looking into using Serverless is that you need to understand your requirements and ensure Serverless aligns with your solutions. It depends on your application, the cloud solution being utilized, and the services required. Throughout my experience with Lambda, I always tie it back to that. While it works for me, others might have different needs or infrastructures, hence it is crucial to have an open mindset and determine what framework truly suits you rather than sticking to one blindly, as that could lead to frustrations. I would rate my overall experience with Serverless as a seven out of ten.
Serverless architecture has accelerated delivery and drives cost-efficient event-based backends
What is our primary use case?
Serverless is primarily used for creating backend services, with the most common use being REST APIs without running a full server. Each API endpoint is a function that scales automatically with traffic, such as login, signup, and payment APIs. File processing is triggered when a file is uploaded and automatically resizes, compresses, and converts the image, for example when a user uploads a profile picture. Event-driven automation runs when something happens on an event basis, eliminating the need to continuously run the server, such as sending an email after registration or triggering an SMS when an order is placed. Serverless is mainly utilized when you want a scalable backend and logic that runs only when needed to save cost and effort. It is also used for chatbots and AI integration, processing the user's message instantly and integrating with AI and APIs, such as a WhatsApp bot and support chatbot.
The API and backend play the most important roles in my focus, as you can build a backend without a server for login, signup, APIs, CRUD operations, and payment endpoints, which are the most common real-world use cases. File and image processing involves a trigger that enables resizing an image, compressing a file, or converting formats. Event-based automation includes sending an email after signup or an order confirmation and SMS for data processing. Scheduling jobs with a cron task can run daily reports, backup jobs, or data cleanup at a specific time. Chatbot and AI integration, such as AI and API integration for customer support bots, represents another use case. Microservices are also needed, breaking the app into small services like auth services and payment services.
In day-to-day use of Serverless in our software company, we mostly rely on it for forms, contact forms, e-commerce, image optimization, and notification alerts. When a user fills out a contact form, a serverless function is triggered to send an email and store the data, which removes the need to build a full backend. E-commerce automation is significant, as when an order is placed, it triggers a function to send the invoice, confirmation emails, and update the database in the CRM , which we use with WooCommerce and Shopify integrations. We utilize WordPress and Shopify websites, making this approach very beneficial. Image optimization occurs when you upload an image, as it is automatically resized and compressed, thereby improving website performance, which is useful for websites and blogs. Notifications and alerts enable the sending of emails, SMS, push notifications, login alerts, payment success notifications, and scheduling tasks. Automatic scaling is particularly helpful in our day-to-day work.
How has it helped my organization?
Serverless has positively impacted our organization, particularly in saving costs, improving speed, and making development easier. It saves time because there is no server setup, configuration, or maintenance, allowing developers to directly write and deploy code, resulting in projects finishing faster over time and enabling the team to deliver features quickly. Cost optimization and long-term savings occur since there are no idle servers, as you only pay for execution, which leads to significant savings for startups and businesses and improves ROI (Return on Investment). Effortless scaling accommodates the increase in user numbers as our company grows automatically, which means there is no need to redesign the system if traffic increases, allowing for smooth growth without downtime. Reduced maintenance and effort result from the absence of patching, updating, or server monitoring, making the operational overhead less burdensome. Smaller teams can manage larger systems, leading to faster innovation as testing new ideas becomes easy and quick, improving product timelines. Better resource utilization means server resources are used only when needed, resulting in a more efficient system with lower infrastructure costs. These outcomes and metrics present significant time savings for our company, highlighting how beneficial Serverless is.
What is most valuable?
Serverless works smoothly with services like Amazon Web Services , S3 , DynamoDB, API Gateways, Google Cloud , and Microsoft Azure . Serverless provides no server management, pay-as-you-go pricing, automatic scaling, fast deployment, event-driven execution, high availability, and easy integration with cloud services. It provides automatic scaling, pay-per-use pricing, and offers fast, cost-effective, and highly scalable operations.
Third-party API integration is an important feature, as you can connect the app via APIs, payment gateways, webhooks, CRM integration, and the WhatsApp API. Chatbots and automation bots handle user queries automatically for customer support and lead generation.
What needs improvement?
Several features could be improved in Serverless, such as reducing cold start time. Cold start refers to the delay that occurs when the function runs for the first time, which can be mitigated by keeping the function lightweight, avoiding heavy libraries and large NPM packages, using warm triggers or periodic pings, utilizing faster runtimes like Node.js and Go, and optimizing the function size by removing unused dependencies and applying bundlers. Employing an efficient architecture, for example using SQS event triggers to avoid polling, results in better scalability and reliability. Additionally, optimizing cost usage involves properly adjusting the memory and timeout, steering clear of long-running functions, and using caching, where a right-sized function can lead to a 50% cost reduction. Utilizing caching and a CDN to cache API responses and employing the CDN for static content reduces function calls and latency significantly. Breaking logic into small functions, where each function serves a single task, makes management and debugging easier, improving performance and maintainability. For monitoring and logging, tracking errors, latency, and usage through tools like AWS CloudWatch and Google Cloud Monitoring enables faster debugging and continuous performance improvement. To enhance Serverless, we focus on optimizing function size, reducing cold starts, leveraging event-driven architecture, implementing caching, monitoring performance, and tuning the memory and timeout to improve speed and reduce costs.
In terms of security, Serverless security best practices need to be implemented. This includes applying least privilege access through IAM , granting only the necessary permissions to the function and avoiding full-access policies; for instance, if a function reads from S3 , it should not have delete or write access, which can be managed through IAM rules. Additionally, securing your API gateways is essential; protect it using JWT tokens, OAuth, and API keys to prevent unauthorized access to your functions. It is crucial to validate all inputs and never fully trust user input; validating and sanitizing everything helps protect against SQL injection and XSS attacks. Management of environment variables should be secure, avoiding hardcoded secrets, instead employing secret managers and encrypted environment variables for API keys and database credentials. Enhancing logging and monitoring practices involves keeping an eye on logs for suspicious activities and establishing alerts for abnormal behavior, where tools from AWS like CloudWatch can be quite useful. Protecting against DDoS attacks and abuse is necessary; employing rate limiting, throttling, and firewalls prevents excessive requests and high costs. It is important to keep dependencies updated, utilize HTTPS and TLS, and encrypt the database and storage. To improve Serverless security, we leverage least privilege IAM rules, secure API authentications, effective input validation, secret management, robust logging, rate limiting, and dependency updates.
For how long have I used the solution?
I have been using this technology for five to six months.
What do I think about the scalability of the solution?
Among all those use cases, the biggest impact is the massive cost-efficiency, which is one of the most effective points. A traditional server runs 24/7, even when idle, while Serverless runs only when you trigger it, impacting startups and small teams by saving huge amounts of money since you do not need to pay for unused resources. Instant scalability is the second significant point; there is no limit, as it handles from one request to one million requests automatically, with no manual scaling or DevOps setup. Our app can go viral during high traffic, making it perfect for viral apps, marketing campaigns, and e-commerce. Faster development and deployment occur since there is no server setup, configuration, or maintenance; you just write a function and deploy it. This leads to a faster time to market and allows more focus on features with less infrastructure. Serverless has changed how we use event-driven architecture, which is useful for modern apps as they react to events like clicks, uploads, and payments, improving real-time systems with better performance and responsiveness in apps.
Serverless's scalability is characterized by its ability to handle more user requests automatically, without any manual intervention. Serverless scaling works whereby each request prompts the creation of a new function instance, with platforms like AWS managing this process seamlessly, whether handling one request or thousands or millions. Horizontal scaling occurs, where Serverless adds more instances, with practically no limits, making the scaling capacity very high. For example, ten users may utilize ten functions, while ten thousand users would engage ten thousand functions. Concurrency scaling enables multiple executions simultaneously, as managed by the cloud provider. A practical scenario illustrates that manually increasing servers requires thoughtful time and cost planning, but because of Serverless, when traffic spikes, it scales automatically and instantly. The paramount benefit of this scaling is that there is no downtime during sudden traffic surges, which means no manual configuration is necessary; you pay solely for actual usage, and it performs exceptionally for unpredictable traffic. Serverless offers automatic horizontal scaling by generating function instances for incoming requests, facilitating its ability to manage sudden traffic spikes without need for manual intervention.
How are customer service and support?
My overall sentiment is positive, as customer support is very good and beneficial.
How was the initial setup?
I estimate that the development process with Serverless is now 30% to 60% faster compared to before I started using it, primarily due to faster deployment. The setup time has reduced from days to minutes; traditionally, a backend setup takes three to five days, whereas a Serverless setup takes about two to four hours, showcasing great time savings. Over time, a project that would take two months can now be achieved in just one to one and a half months.
What was our ROI?
Return on investment is realized through significant savings in infrastructure costs since the server is not constantly running; you only pay during actual usage, typically realizing 40% to 80% lower costs. There is also a faster time to market facilitated by quicker build and deployment times, which allows products to launch sooner and start generating revenue earlier. Time savings stem from faster development cycles, as maintenance costs drop due to a lack of server patching, requiring less DevOps effort. Smaller teams are required, contributing to lower salary and operational costs, complemented by automatic scaling that prevents the need to over-invest. You do not need to acquire additional servers, thus avoiding wasted funds. A straightforward ROI scenario highlights that with a conventional setup the server's monthly cost is $3,000, in addition to $10,000 for DevOps, reaching a total of $30,000 per month. Contrastingly, with a Serverless setup, the usage cost reduces to $1,000 with minimal maintenance, leading to $1,000 to $3,000 monthly expenses. ROI calculations indicate a savings of $10,000 each month, representing a 300% to 500% improvement. Serverless significantly boosts ROI by lowering infrastructure expenses by 40% to 80%, enhancing development speed by 30% to 60%, and minimizing maintenance requirements, translating to faster delivery and decreased operational costs.
What's my experience with pricing, setup cost, and licensing?
My experience with pricing reveals that it operates on a pay-per-use basis, which depends on the number of requests, execution time, memory utilized, and similar factors.
What other advice do I have?
Serverless as a Function-as-a-Service (FaaS) effectively runs small functions on demand, where each task is executed as a function through trigger-based activation, exemplified by an API endpoint that instigates a function. From an event-driven architectural perspective, the system reacts to events like file uploads, API calls, or successful payments, with everything executed as a function triggered by specific activities. Adopting a microservices model divides the application into small, independent services such as auth services, payment services, and notification services, where each function qualifies as a microservice. Under a cost optimization strategy, it emphasizes economical operations without idle costs, requiring payment strictly for execution, which renders it an optimal solution for startups and low-traffic applications. Moreover, as a scalability engine, it includes built-in automatic scaling to manage unpredictable traffic without human intervention, acting as a beneficial tool to enhance developer productivity.
Serverless is optimal for our organization, making it exceptionally helpful. I give this solution a rating of 10 out of 10.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Auto-scaling has ensured reliable order processing and has reduced costs for unpredictable traffic
What is our primary use case?
The main use case we are using is auto-scaling and cost-effectiveness. Some of our use cases involve unpredictable traffic. For example, during Eid events, I am from the QSR domain, so traffic on Eid day is not predictable. When using Serverless , it auto-scales, and I pay based on actual usage.
In my case, I use everything on my main server for what we build, but for order processing, we are using Serverless where we do not want any hassle of server management, such as upscaling. Order processing is the key part of my application. I preferred to use Serverless for this part so that none of my customers face any problems processing orders, because if any order fails, it loses the customer's confidence or trust.
I suggested my team use auto-scaling and Serverless for order processing and notifications, with auto-adjusting features to auto-manage traffic. For this feature, we are using Serverless.
What is most valuable?
There is a huge impact as my traffic gets auto-adjusted. I do not have to worry about whether my server is capable of handling the traffic or not. Serverless servers are much more capable. I do not have to bear the cost burden. I just need to pay for whatever I am using.
Serverless has definitely improved cost savings and there are fewer order failures due to high traffic.
What needs improvement?
Serverless is a very comprehensive platform. I have not explored everything, but I use it only for traffic management and the auto-scaling features. That is why I deducted one point.
For how long have I used the solution?
My team has been using Serverless for the last three to four years.
What other advice do I have?
If you are a startup or have any stable product and you want on-traffic payment, then you should definitely use Serverless. If you are not able to predict your traffic, then you should definitely use Serverless. For example, some days we have one hundred orders, but on a big day, we may have hundreds of thousands of orders. You cannot upscale your server from day one. You should definitely shift to Serverless. It will definitely help you reduce your costs and you can easily manage your traffic. I would rate this product as a 9 out of 10.
Serverless architecture has reduced idle resource costs and supports concurrent backend AI workloads
What is our primary use case?
I use Serverless to deploy back-end APIs and to run serverless applications, which are basically microservices.
I make use of AWS Lambda to deploy back-end for artificial intelligence applications. For instance, one example I deployed using AWS Lambda was for the back-end of an application where the front-end calls the back-end to return data. This helps ensure that the back-end operates separately, and resources are not being used when not needed.
I run serverless applications on AWS , and I believe the main use case is to ensure that application back-ends are not being used unless they are specifically called or unless they are specifically needed for use.
What is most valuable?
I believe the best features Serverless offers are the very quick ability that enables individuals to quickly make calls to their back-end or to quickly make calls to their services. Additionally, Serverless is very useful when it comes to running simultaneous jobs at the same time without breaking.
Serverless helps run simultaneous jobs. For instance, when you need to make a back-end API call, multiple people can make such calls at the same time. What happens at the Serverless back-end is it creates something similar to multiple instances or multithreading that allows each Serverless Lambda or each Serverless resource to run concurrently without affecting one another.
It has helped a lot in saving costs because, as I mentioned initially, it makes sure services are not being used unless they are being invoked. It has really helped in making sure costs are well managed and also making sure we do not make use of resources that are not needed at a particular point in time.
Making use of Serverless has at least helped us save 50% in cost spending on resources.
Because I believe Serverless has had a very positive impact on myself and also on the company I work for, especially on the cost side. It is very cost-effective and has helped us to save a lot, I believe up to 50% on cost savings and also has helped us to really save a lot of money when it comes to deploying back-end and managing back-end services.
What needs improvement?
Serverless can be improved by making it more independent from particular bigger providers. Serverless can be better if it is more decentralized and individuals are allowed to probably have full access to their own serverless machines.
For how long have I used the solution?
I have been using Serverless for about five years.
What do I think about the stability of the solution?
Serverless is pretty much stable, but I believe the only downside is when it has to do some kind of cold warming, which might actually take some time.
What do I think about the scalability of the solution?
It is very much scalable. As I mentioned earlier, it allows users to run multiple requests at the same time and is able to handle even thousands of requests concurrently.
Which solution did I use previously and why did I switch?
I had not used a different solution.
Which other solutions did I evaluate?
I also evaluated making use of EC2 .
What other advice do I have?
I would tell them that if they want something quick, portable, and fast, they can make use of Serverless. However, if what they want is something that has to do with data that is needed in real time, then they should look for a different solution. I give this product a rating of 8.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Event-driven workflows have transformed image processing and now reduce load times effortlessly
What is our primary use case?
My primary use case for Serverless is handling asynchronous data processing and event-driven workflows. I typically use it to trigger background tasks like image processing or data transformation whenever a file is uploaded to S3 , which keeps our main application responsive.
In my last role, I used Serverless to address an issue where users were uploading high-resolution images that were slowing down our main site. I set up an S3 trigger that automatically invoked a Lambda function the moment a file hit the bucket, and the function resized the image into three different formats and stored them back to a separate bucket, which reduced our page load time by about 40% and significantly lowered our storage cost.
By offloading that processing to the background, we ensured that the main application remained responsive while the images were handled asynchronously, turning a major performance bottleneck into a seamless, automated workflow for our users.
What is most valuable?
The best features Serverless offers beyond image processing include building event-driven APIs and cron-like automations. For instance, I set up scheduled Lambda functions to handle daily database cleanup and report generation. For me, the biggest advantage is the automatic scaling and the pay-per-execution model, allowing us to handle massive traffic spikes without manual intervention.
During high traffic periods, I found that automatic scaling has helped us immensely. We had a major marketing campaign launch last year that drove a sudden 10x spike in traffic to our platform, and because our backend was built on Serverless functions, the infrastructure scaled out instantly to handle the concurrent requests without me having to provision a single extra server or worry about downtime.
Serverless has positively impacted my organization by shifting our focus from infrastructure management to pure product delivery. By offloading the operational overhead to the cloud provider, my team has been able to cut our time to market for new features by nearly 30%.
What needs improvement?
The biggest area for improvement in Serverless is around cold start latency, especially for applications that aren't constantly active. While providers are making strides, it still forces us to choose between cost efficiency and instant responsiveness, and I would love to see more mature, built-in support for pre-warmed instances or predictive scaling to bridge the gap.
Beyond latency, I believe better observability and debugging tools for distributed Serverless architecture are critical. It is often difficult to trace a single request across multiple functions, so having a more unified, native tooling would significantly reduce the time we spend troubleshooting complex event-driven flows.
For how long have I used the solution?
I have been working with Serverless architecture for about a year and a half.
What do I think about the stability of the solution?
Serverless is incredibly stable for us. We have seen significantly higher uptime compared to our previous setup because the platform handles all the underlying patching and scaling automatically.
What do I think about the scalability of the solution?
Scalability of Serverless is honestly one of the biggest wins for us, as it handles traffic spikes automatically without any manual intervention. We do not have to worry about over-provisioning or under-provisioning. Regarding customer support, it has been very responsive; we have found the documentation and resources to be thorough enough that we rarely run into blockers that we cannot solve quickly.
How are customer service and support?
I would rate customer support around 8 out of 10 because it is consistently quick, the documentation is comprehensive, and all customer support is quite responsive, so there is not much of a blocker.
Which solution did I use previously and why did I switch?
Before moving to Serverless, we were running a monolithic application on standard EC2 instances. We decided to switch because scaling was manual and reactive, which led to significant downtime during traffic spikes and high operational overhead for our engineering team.
How was the initial setup?
We did not purchase Serverless through the AWS Marketplace ; we manage our infrastructure directly through AWS accounts using Terraform for our IAC, which gives us better control over environment configuration and deployment pipelines.
What was our ROI?
We definitely saw a strong return on investment after moving to Serverless architecture. By reducing our monthly infrastructure spend by about 30%, we eliminated the idle capacity costs we were previously paying for underutilized EC2 instances.
What's my experience with pricing, setup cost, and licensing?
Regarding pricing, setup cost, and licensing, I find the pricing model quite efficient for us, as we only pay for execution time in a pay-per-use model, eliminating the idle costs we saw with traditional servers. While some investment was needed in defining our Terraform modules and CI/CD pipelines, it significantly reduced our long-term licensing overhead compared to managing proprietary on-premise software.
Which other solutions did I evaluate?
Before choosing Serverless, we evaluated other options and looked into containerizing our monolith with Kubernetes on EKS. While Kubernetes offered great portability, we ultimately decided against it because the operational overhead of managing clusters did not solve our core problem of wanting to focus purely on feature development rather than infrastructure maintenance.
What other advice do I have?
My biggest piece of advice for others looking into using Serverless is to prioritize observability from day one because you lose visibility into the underlying infrastructure, so you need to have robust logging and distributed tracing in place immediately, or debugging becomes a nightmare.
One final point about Serverless is that while it is incredible for scaling, I think it is crucial to be mindful of cold starts and vendor locking early on; if you design your architecture to be modular from the start, you keep your options open as the system grows. I would rate this product an 8 out of 10 overall.