![]() The high level solution is depicted on the following diagram: We run the AWS Lambda in this account and provide access to the billing information via cross account access. To comply with the best practices we have an AWS account for “internal services”. In our AWS organisation where we use consolidated billing we don’t want to run this AWS Lambda in the root account. ![]() Naturally we choose to run this service as a weekly task using AWS Lambda. This is not a replacement for setting budget alarms in the AWS Budgets service, but rather provides additional insight in the spending in a frictionless way, even when the forecast budget is not reached. Developers and budget owners are members of this channel to ensure complete visibility across the organisation and creating a culture where necessary action can be taken on a regular basis. To have this information pushed, we have created an automated service which sends a weekly spending report to a shared slack channel. We don’t look that often at the AWS spend we have in the multiple AWS accounts, and sometimes we overspend because we forget to delete a (set of) resource(s) which will cost the company unnecessary money. Actually this is something which Merapar promotes, don’t do repetitive tasks yourself but automate them wherever possible. It might be a stigma, but we developers are lazy by nature and not very interested in accounts and budgets. In this blog post we focus on how we increase our (developers) cost awareness of the ongoing spend we have in our development AWS accounts. ![]() Why? Because we think it’s fun to share knowledge and to learn from others in the industry! Situation In a series of blog posts we will focus on some of the best practices we use within Merapar to evolve our DevOps practices we have built around the AWS platform.
0 Comments
Leave a Reply. |