How to Start a FinOps Practice: Access, Data and a Review
Before any optimisation, the people who will own cloud cost need to be able to see it. These are the grants and settings that make that possible.
A FinOps practice is a working agreement between engineering, finance and whoever owns the budget. The agreement fails early for mundane reasons: finance cannot open the billing console, the data is a month late, nobody knows which team owns a line item. This guide fixes those in order. For the concepts behind it, read what FinOps is first.
Step 1: give finance read-only billing access
Grant the smallest role that shows cost, not an admin role.
AWS. IAM users and roles see nothing in the Billing and Cost Management console until the root user activates IAM access to billing information, once per account. Then either write a narrow policy with aws-portal:ViewBilling and budgets:ViewBudget, or attach the AWS managed job-function policy Billing. Note that Billing is not read-only: AWS describes it as viewing usage and viewing and modifying budgets and payment methods.
aws iam attach-role-policy --role-name finance-readonly \ --policy-arn arn:aws:iam::aws:policy/job-function/BillingGoogle Cloud. Grant Billing Account Viewer on the billing account, which Google describes as the role usually given to finance teams:
gcloud billing accounts add-iam-policy-binding 0X0X0X-0X0X0X-0X0X0X \ --member=group:finance@example.com --role=roles/billing.viewerAzure. Assign Cost Management Reader at subscription (or management group) scope:
az role assignment create --assignee finance@example.com \ --role "Cost Management Reader" --scope /subscriptions/SUB_IDVerify by signing in as a finance user and opening each provider’s cost view. If a page loads empty rather than denied, the grant is on the wrong scope.
Step 2: turn on line-item exports
Console charts are enough for a first conversation and not enough for a monthly close. Enable AWS CUR 2.0, the Google Cloud billing export to BigQuery, and an Azure Cost Management export now rather than at month end, so the first review has a full month of line items. The setup for all three is in exporting billing data from AWS, GCP and Azure.
Step 3: agree one ownership key
Choose a single key, such as team, that every resource must carry, and a short list of allowed values. Then make it visible in cost data: activate it as an AWS cost allocation tag, rely on GCP labels in the export, and enable Azure tag inheritance where your agreement type supports it. Details: making tags show up in cost data.
Step 4: put alarms on the edges
One budget per team or account and one anomaly monitor per cloud catch the surprises that would otherwise surface on the invoice. Both are notification-only on every provider; nothing gets stopped.
Step 5: hold the first review
Keep the first monthly review to four questions, each answered with a number from the exports:
- What did each team spend, and how does it compare with last month?
- What share of spend has no owner value?
- Which anomalies fired, and what caused each?
- Which one change will we make before next review, and who owns it?
Write the answers down. The second review is where the practice starts, because it is the first time you can check whether last month’s change happened.
How ZopNight supports the same loop
ZopNight covers these steps across AWS, GCP and Azure in one place: cost visibility from billing data, team showback, budgets with alert thresholds, daily anomaly detection with root cause, and recommendations to rightsize, schedule or clean up resources. Read-only cloud accounts get discovery and recommendations; scheduling and remediation need a read + write account, so a practice can start with visibility and add actions later.