Yeah, it's really just a way to talk through cloud architectural choices when you're designing for cost: committing to reserved instances for VMs (goodbye, eternal soul -- for at least the next three years), minimizing your data retention or migrating through storage classes for bucket data, and ruthlessly optimizing your use of per-usage services (bucket ops, API calls, serverless functions, and charge-per-op databases like Firebase, to name a few). Bandwidth and network services, however, are insanely expensive for what you get, show up all over your service architecture,
and are hard to forecast, so they like to jump out of dark corners at the end of your billing cycle and mug you. (The ever-invaluable Duckbill does a nice job of laying out all the places where AWS levies its bandwidth tax:
https://www.duckbillgroup.com/wp-content/uploads/2019/12/dbg...).
Depending on what your application is, this may never be an issue, or, if you're pushing heavy file and content traffic, it could form a huge chunk of variable costs that you need to figure out cost recovery for in your business model.
(All this gets upended if you're on something like SFDC or Dynamics, though, where costs looks nice and forecastable until you get to disk storage, where their pricing models appear to be put together by the kind of guys who usually present their invoices alongside a menacingly-brandished lead pipe.)