Any diagram like this should include an estimate of usage, and how much that usage will cost, for every "block of architecture" displayed. Absent that, it's impossible to tell whether it's a good idea or a bad idea.
Moreover the cloud providers should make it harder for an uncontrolled "block of architecture" to accidentally spend too much money. The focus seems to be on "always available", but depending on how fast it's spending your money, it might be better if it crashed.
Expanding further, perhaps each "block of architecture" should have a separate LLC dedicated to it to control billing liability. Incorporate your "lambda fanout" to keep it from bankrupting your "certificate manager" when it goes haywire, and let it go out of business separately.
AWS includes a boatload of free calls in both Lambda and API Gateway per account. So set your API Gateway call limit at/below the free limit and Bob’s your uncle.
What’s harder is when your app hits an Amazon limit and you have to figure out if it’s hard or soft, how quickly your TAM can do something about it, etc.
Moreover the cloud providers should make it harder for an uncontrolled "block of architecture" to accidentally spend too much money. The focus seems to be on "always available", but depending on how fast it's spending your money, it might be better if it crashed.
Expanding further, perhaps each "block of architecture" should have a separate LLC dedicated to it to control billing liability. Incorporate your "lambda fanout" to keep it from bankrupting your "certificate manager" when it goes haywire, and let it go out of business separately.