Cloud Cost Optimization - Multi-cloud Dashboard including AWS

**Describe the Issue**
Cloud Cost Management & Optimization - Centralized dashboard enablement for AWS on Azure, allowing all 3 BC Gov current CSP's reporting to a central cost management service

**Additional Context**
Cloud cost management and optimization efforts have highlighted need to have better reporting\alerting\monitoring capability developed for quicker decision making and variance\trend analysis where possible to catch inefficiencies, including a possible centralized anomaly detection capability - ie. Operational improvements around better monitoring of our Cloud costs and how we can possibly improve our use of these with optimizations and automated functionality integrated for easier control, and maintenance of a minimum governance standard across all our Cloud platforms.

We are going to refine this in AWS cost management inside AWS as best as we can, but also want to enable the AWS + GCP cost data streams into Azure Cost Management in parallel as it has many of these capabilities already and we can compare against this on how we'd like to move forward in the future - pre-built\dynamic dashboard's, trend analysis ability, dynamic\intelligent cost alerting, etc.

**Acceptance Criteria**
- Deeper learning of Cost Management aspects for Multi-Cloud
- Review procedure to enable this from previous spike, and work with Warren\Max to enable
- Ensure it's turned properly - Cost Management optimization reporting for AWS (Compare with costs directly in AWS)
- Refine\optimize
- Open tickets if anything more than for this, or for simply better understanding the data feed\process when operating it in the future.

.
.
.
.
.
.
.
.
.
.
.

**Extra Template Info**

***Definition of Ready***
These set of conditions will need to be met in order to bring a ticket into the sprint and start work. Protects the team from unclear requirements.
Issues (Task/Story/Spike) aligned to an EPIC and linked appropriately.
Assigned to the appropriate CPF MEMBER (and is not left blank in ZenHub) at the start of sprint (1st day of the sprint)
Acceptance has been defined for the issue and has been reviewed with CPF team and approved by the necessary approver.
Has been sized and estimated by the delivery team.
Detailed breakdown of the steps required to complete the story in the additional context
Any additional specifications have been documented, reviewed with CPF and approved by the necessary approver.

***Acceptance Criteria***
A set of pre-defined requirement that need to be met in order to mark the user story as “done”.
It should be testable with no room for interpretation
It should be either “pass” or “fail”
It should be clear enough for business stake holders to understand
As part of the user story, it should be written from the user perspective
A well written acceptance criteria is great for
- managing expectations
- defining scope
- reducing ambiguity
- establishing testing criteria for QA
Given (Pre-condition)
When (Action)
Then (Outcome)

***Definition of Done***
These set of conditions are met for work to be considered as complete on an issue.
All acceptance criteria(s) have been validated.
All the necessary documentation for the issue has been uploaded to Teams.
Functionality has been tested when applicable.
Functionality has been demonstrated to the relevant stakeholders (where applicable).
Story has been scheduled for a Sprint Demo/community update and impacted teams invited to the Demo.
Stories accepted by PO and documented for potential sharing with impacted users.
- Documented = Captured in Community Update (CU) deck
- Release notes = aspirational goal of providing a bulleted list of features and changes that our users can touch. Was going to store them in our Cloud Pathfinder repo. Can also display to users in the CU