无服务器架构虽然对许多应用有用，但也存在一些明显的限制。第一个主要限制是冷启动（cold starts）。当一个无服务器函数长时间未使用时，云提供商可能会关闭其底层计算实例以节省资源。当新的请求到达时，提供商必须启动一个新的实例，这会引入延迟——通常从几百毫秒到几秒不等。这种延迟对于需要实时响应的应用来说可能是个问题，例如 API 或面向用户的功能。例如，一个流量不稳定的支付处理系统可能会因为冷启动而出现性能不一致的情况。虽然预热（pre-warming）（定期ping函数使其保持活跃）等技术可以缓解这个问题，但这会增加复杂性，并可能抵消成本节省。
另一个限制是执行时间限制。大多数无服务器平台对单个函数强制执行严格的最大执行时间。例如，AWS Lambda 函数在 15 分钟后超时，Azure Functions 或 Google Cloud Functions 等其他服务也存在类似的限制。这使得无服务器不适合长时间运行的任务，例如视频编码、批量数据处理或复杂的机器学习工作流。开发者必须将此类任务分解成更小的块，或将其卸载到替代服务，如 EC2 实例或 Kubernetes 集群。这增加了架构的复杂性，因为工作流现在需要无服务器和非无服务器组件之间的协调。例如，一个数据管道可能需要 Lambda 进行快速转换，但依赖 ECS 容器进行数小时的处理作业。
第三个限制是厂商锁定和有限的控制。无服务器平台与其提供商的生态系统紧密集成，使得跨云迁移应用变得困难。如果迁移到另一家提供商，AWS API Gateway 或 DynamoDB 等专有服务通常需要更改代码和配置。此外，开发者对运行时环境的控制极少——无法安装自定义软件依赖项或调整操作系统级别的设置。调试也更具挑战性，因为传统的工具，如 SSH 或性能分析代理，都不可用。例如，排除 Lambda 函数中的内存泄漏问题，只能依赖云提供商的日志和指标，而这些可能缺乏细粒度。虽然 AWS X-Ray 等工具有所帮助，但它们并不能完全取代直接的服务器访问。这些限制会限制灵活性，并使长期维护复杂化。