Amazon
亚马逊技术长Werner Vogels提出的节约架构（Frugal Architect），由三大类、七项软体架构设计法则所组成，在第三部分谈及架构与成本最佳化（Optimize），其中包含两项法则。
首先，第六项法则－「成本最佳化是渐进的」，指出成本最佳化并非一蹴可几，而是持续调整，逐步完善。Vogels表示，由于过往技术上的限制比较多，IT人员往往只能在较小的层面上持续修修补补，而这种从小地方逐步改善的作为，也让他们练就了成本最佳化的能力。
但是，在运算资源容易取得的情况下，软体开发团队过于追逐速度，在快速开发之下，逐渐不再重视细节，然而一些不起眼的事情累积起来，就会造成很大的数位浪费。例如网站开发没有重视档案大小的问题，那么使用者就有可能上传解析度过高的照片或影片，而实际上对终端用户体验毫无助益却徒增频宽浪费；又或是开发人员为了方便，下班后不关闭测试环境的主机，让它空转浪费资源，而若有维持开机的必要，其实也可借由缩减主机规格来降低成本与减少浪费。这些虽然都只是小事情，但若不加以重视，无形中就会造成很多隐藏的数位浪费。
至于软体系统，则可透过应用程式效能分析（Profiling），以了解隐藏的数位浪费。Vogels表示，应用程式效能分析这项技术几乎可说快要失传了，但它却是软体持续最佳化的重要工具之一。他举亚马逊的某一项服务为例，效能分析让他们发现网路通讯竟然占了整体耗能的四成以上，然而这个现象对该应用程式而言不合理，于是他们回头检视程式码，才发现原来只是因为一个条件判断陈述语法写错，经修改后耗能就降到三成以下。因此，要确保软体系统没有隐藏的数位浪费，就要持续进行效能分析与最佳化。
节约架构的最后一项、第七项法则：「无庸置疑的成功必将导致错误的臆断」，如果软体开发团队未曾遭遇什么困难就成功了，往往会因为复制过往成功经验而埋下骄傲自满的种子，无法持续精进与改善。Vogels以COBOL之母美国海军准将Grace Hopper的名言：「英语中最危险的一句话就是：我们一直都是这样做的。」提醒软体开发团队要打破技术本位的思维，以保持进步。
技术本位常见于软体开发团队固守擅长的程式语言，毫不考虑是否有更好的选择，然而，殊不知程式语言也与成本效益有关。2017年有一项学术研究分析27种程式语言的能源消耗程度，发现C语言是其中最省电的程式语言，排名第二的是Rust，而Ruby的耗电量是C语言的69倍，Python的耗电量是C语言的75倍，分别排名倒数第三与倒数第二。Vogels指出，亚马逊在开发Firecracker时就采用Rust，而S3后来也有很大的比例以Rust改写，这除了考量成本与永续，还包括Rust的强型别、高效能与记忆体安全性等优点。
在演讲最后，Vogels期许IT人员：「我们身处快速变动的时代，在不断学习的同时，也要一直否定既有信念，把自我摆在一边，重拾成本意识这个即将失传的技艺，因为永续的需求已经如同一列货运火车直驶而来，你既逃不掉，也不该逃避永续的趋势，而在云端架构中，从运算成本著手将会是最接近达成永续目标的作法。」他也说：「没有人想要有限制，成本与永续固然会为软体架构与营运带来不少限制，然而创意往往就随著突破这些限制而到来。」