Money-saving tips for the frugal serverless developer (AWS Community Summit)

Dive into the world of serverless and explore common, costly mistakes and learn actionable tips for cutting down waste and reducing your AWS bill.

Whether you’re looking to cut down on CloudWatch costs or improve cost-efficiency for your serverless application, we’ve got some helpful tips for you.

1. Yan Cui @theburningmonk
2. Yan Cui http://theburningmonk.com @theburningmonk AWS user since 2010
3. Developer Advocate @ Yan Cui http://theburningmonk.com @theburningmonk
4. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant
6. Billing alarms
7. Everyone should use billing alarms.
8. They are not perfect. But they can still save your a$$.
12. Keeping logging cost under control
13. CloudWatch often costs much more than your actual application.
14. As cost goes up, value goes down.
15. How to keep CloudWatch Logs cost under control 1. Do structured logging.
16. How to keep CloudWatch Logs cost under control 1. Do structured logging. DEBUG INFO WARN ERROR Detailed events for debugging application. General information that highlights progress of application. Potential problems, but doesn’t stop application from working. Issues that require immediate attention.
17. How to keep CloudWatch Logs cost under control 1. Do structured logging. Log at INFO or above in production. DEBUG INFO WARN ERROR Detailed events for debugging application. General information that highlights progress of application. Potential problems, but doesn’t stop application from working. Issues that require immediate attention.
18. How to keep CloudWatch Logs cost under control 1. Do structured logging. Log at INFO or above in production. 2. Sample DEBUG logs in production. e.g. 5% of invocations.
19. How to keep CloudWatch Logs cost under control 1. Do structured logging. Log at INFO or above in production. 2. Sample DEBUG logs in production. e.g. 5% of invocations. 3. Set log retention to 30 days.
21. CloudWatch Logs AWS Lambda AWS Lambda stdout asynchronously invokes any log aggregation service
23. CloudWatch Logs AWS Lambda AWS Lambda stdout asynchronously invokes any log aggregation service double paying for ingesting logs
24. Lambda Extensions + Telemetry API
25. https://docs.aws.amazon.com/lambda/latest/dg/telemetry-api.html
27. CloudWatch Logs AWS Lambda
28. https://lumigo.io/blog/lumigo-launches-log-management
29. Remember system messages
36. DEBUG INFO WARN platform.initStart platform.start platform.initRuntimeDone platform.initReport platform.runtimeDone platform.report unhandled exception
37. DEBUG INFO WARN platform.initStart platform.start platform.initRuntimeDone platform.initReport platform.runtimeDone platform.report unhandled exception
38. Tobias Schmidt Sandro Volpicella “de fi nitive guide for learning CloudWatch” - me cloudwatchbook.com
39. Right-sizing Lambda memory
40. More memory = more CPU = more network bandwidth
42. Easy to be wrong by an order of magnitude.
43. STORY TIME
46. Right-sizing Lambda functions
48. https://github.com/alexcasalboni/aws-lambda-power-tuning
49. Use ARM architecture
50. 25% cheaper
51. Performance may vary…
52. Best for functions with a lot of IO wait time.
53. No lambda-to-lambda invocations
58. SYNCHRONOUS Lambda-to-Lambda are almost always a sign of bad design.
60. Double paying for execution time
61. Service Boundary
62. Service Boundary
63. Service Boundary
64. AWS Lambda function !== lambda function in programming
65. Service Boundary Service Boundary
66. Service Boundary Service Boundary Downstream system shouldn’t rely on an implementation detail.
67. Service Boundary Service Boundary HTTP
68. Service Boundary Service Boundary HTTP
69. Service Boundary Service Boundary HTTP Stable interface Implementation detail
70. What about async invocations?
71. HTTP Async invocation Secondary responsibilities Do the thing the user wants
72. HTTP Async invocation Secondary responsibilities Do the thing the user wants Better user experience
73. HTTP Async invocation Secondary responsibilities Do the thing the user wants More robust error handling
74. HTTP Async invocation Secondary responsibilities Do the thing the user wants Service Boundary
75. Service Boundary Service Boundary Never a good idea!
76. Are async Lambda-to-Lambda invocations OK?
77. It depends…
78. Every component in your architecture should serve a purpose and provide a ROI.
80. ?
81. ? ?
83. Caching
84. Caching is a cheat code for building performant & scalable applications.
85. Route53 CloudFront API Gateway Lambda DynamoDB
86. Route53 CloudFront API Gateway Lambda DynamoDB client-side caching
87. Route53 CloudFront API Gateway Lambda DynamoDB client-side caching edge caching
88. Route53 CloudFront API Gateway Lambda DynamoDB client-side caching edge caching application-level caching
89. Route53 CloudFront API Gateway Lambda DynamoDB client-side caching edge caching application-level caching ElastiCache
90. Route53 CloudFront API Gateway Lambda DynamoDB client-side caching edge caching application-level caching Momento
91. Route53 TTL
93. Use longer TTL for stable domains
94. Avoid CORS
95. Enabling CORS for API Gateway is easy
96. Enabling CORS for API Gateway is easy But you still pay for those CORS requests!
98. You might be double paying for every user request to your API…
99. Solution: roll your own OPTIONS methods
100. or…
102. Choose the right service
103. Every architectural decision is a buying decision.
104. Using the wrong service can be very costly.
107. Assuming 1KB per request
108. Assuming 1KB per request
109. Services that charge by uptime are order(s) of magnitude cheaper at scale.
110. Services that charge by uptime are order(s) of magnitude cheaper at scale. But, you must understand the cost dimensions of individual services.
111. Assuming 1MB per request ? ?
112. Assuming 1MB per request 😂 $53,837.87 $68.99
113. www.thefrugalarchitect.com
114. Law I. Make Cost a Non-functional Requirement. Law II. Systems that Last Align Cost to Business. Law III. Architecting is a Series of Trade-offs. Law IV. Unobserved Systems Lead to Unknown Costs. Law V. Cost Aware Architectures Implement Cost Controls. Law VI. Cost Optimization is Incremental. Law VII. Unchallenged Success Leads to Assumptions.
115. Law I. Make Cost a Non-functional Requirement. Law II. Systems that Last Align Cost to Business. Law III. Architecting is a Series of Trade-offs. Law IV. Unobserved Systems Lead to Unknown Costs. Law V. Cost Aware Architectures Implement Cost Controls. Law VI. Cost Optimization is Incremental. Law VII. Unchallenged Success Leads to Assumptions.
116. IOT core AppSync API Gateway Messages Connection Time $2 per million $0.08 per million mins $0.25 per million mins $1 per million $0.08 per million mins $1 per million
117. Users Connection Time
118. Users Connection Time Revenue
119. Users Connection Time Revenue Engagement
120. Users Connection Time Revenue Engagement
121. www.gomomento.com/services/topics
122. No Connection Time cost!
123. IOT core AppSync API Gateway Messages Connection Time $2 per million $0.08 per million mins $0.25 per million mins $1 per million $0.08 per million mins $1 per million Momento $1 per million - Data Transfer - EC2 rates EC2 rates EC2 rates
124. Speaking of picking cost-e ff i cient services…
126. https://www.youtube.com/watch?v=SCIfWhAheVw
127. Lambda: $6 per 100 GB Hrs 🤯 ~7x markup!!!
129. DANGER DANGER DANGER DANGER DANGER
130. Simplify your architecture
131. Avoid unnecessary moving parts to your architecture.
132. ? Synchronous
133. ? ? Synchronous
134. ? Asynchronous
135. ? Asynchronous Not fan-out, just here to avoid Lambda-to-Lambda invocations
136. ? ? Asynchronous
137. Every component in your architecture should serve a purpose and provide a ROI.
138. The most dangerous phrase in the language is "we've always done it this way". - Grace Hopper
139. Function URLs
140. Function URL
141. If you’re not using API Gateway features (e.g. Cognito authoriser, request models, direct integration)
142. Or, if you’re hitting API Gateway limits (e.g. 29s timeout, no response streaming)
143. Have to write Lambdaliths
144. Have to write Lambdaliths (No per-endpoint metrics & alerts, no fi ne-grained access control, no per-endpoint auth)
145. Have to write Lambdaliths (No per-endpoint metrics & alerts, no fi ne-grained access control, no per-endpoint auth) (Large frameworks a ff ect cold start performance)
146. Best for public or internal APIs
148. Functionless
150. No Lambda = no cold starts
151. No Lambda = no Lambda costs
152. EventBridge Pipes
153. EventBridge Pipes
154. EventBridge Pipes Transform
155. Use Lambda functions to transform data, NOT transport data
156. OpenSearch
157. No-Code ETL OpenSearch
158. AppSync EventBridge OpenSearch
159. Step Functions EventBridge OpenSearch
160. Every component in your architecture should serve a purpose and provide a ROI.
162. Direct client access to AWS
168. Only allow access if hash key matches cognito sub
169. Not for the feint hearted…
170. When not to use this:
171. High risk, high reward!
172. https://theburningmonk.com/2023/12/direct-access-for-frontend-apps-to-aws-services
173. 1. Billing alarms 2. Keeping logging cost under control 3. Right-sizing Lambda functions 4. No Lambda-to-Lambda calls 5. Caching 6. Route53 TTL 7. Avoid CORS 8. Choosing the right service 9. Simplify your architecture 10.Function URLs 11. Functionless 12. Direct client access to AWS
174. productionreadyserverless.com Join 20+ AWS Heroes & Community Builders and 1000+ happy students in levelling up your serverless game.
175. Questions?