無服務器架構的弊端有：1、第三方API系統會導致供應商控制、多租戶問題、供應商鎖定及安全缺陷等問題；2、缺失操作工具，調試分布式系統的任務非常困難；3、開發人員需要花費大量時間來評估、實施和測試具體功能；4、實施的難度非常高，需要將大量單元加以集成，才能正常完成測試。
具體內容如下：
1、第三方API系統導致的問題
供應商控制、多租戶問題、供應商鎖定以及安全缺陷等，都有可能是由第三方API所導致的問題。在實施API時放棄系統控制可能會導致系統宕機、強迫性API升級、功能缺失、意外限制以及成本變更等后果。此外，多租戶問題也存在于其他云計算框架之中。Salesforce（PaaS）就因其多租戶云結構而施加了部分監管限制，開發人員在使用Salesforce時必須要盡可能避免相關問題。具體而言，多租戶解決方案往往會在安全性、穩定性以及性能層面存在問題。
2、操作工具缺失
開發人員依賴供應商為其提供調試與監控工具。一般來說，調試分布式系統的任務非常困難，通常需要訪問大量的相關指標才能確定產生問題的根本原因。
3、 架構的復雜性
開發人員通常需要花費大量時間來評估、實施和測試具體功能，才能最終決定這些功能應該如何進行細分。一次應用程序調用操作中所涉及的功能數量應該保持平衡。管理太多功能無疑將使問題變得更加復雜化，而忽略粒度將最終導致微服務架構變為“迷你整體”架構。
目前，Lambda（亞馬遜網絡服務AWS提供的一種計算服務，其能夠以一種大規模并行方式執行代碼，以響應事件）已經對用戶能夠在所有lambda表達式上運行的并發執行總數作出了限制。其中的問題在于，這個限制是適用于整體AWS帳戶的。一些組織會使用相同的AWS帳戶進行生產及測試。這就意味著，如果組織中的某位工作人員著手進行一項新的負載測試，并嘗試執行1000個并發Lambda函數，那么生產應用程序將立即遭遇拒絕服務（DoS）狀況。
4、實施的困難性
集成測試無服務器應用程序的難度非常高。與其他體系機構相比，無服務器FaaS（即每項功能）的集成單元要小得多，因此我們需要將大量單元加以集成，方能正常完成測試。此外，也存在一些與部署、版本控制和打包相關的問題。大家可能需要為整體邏輯應用程序中的每項功能單獨部署一項對應的FaaS組件。這也就意味著，您不能以原子性方式對一組功能進行統一部署，而由于不存在版本化應用程序的概念，所以原子回滾（atomic rollback）也無法實現。這樣的話，您可能需要關閉任何觸發相應功能的事件源、部署整體功能組，然后再重新啟動事件源。
