# Access Policies Source: https://docs.vantage.sh/access_policies Restrict which cost and resource data each team can see using Vantage Access Policies. > [!NOTE] > > Access Policies are generally available to Vantage Enterprise customers with contracted Build Hours. If you are not currently eligible, contact the Vantage sales team at [sales@vantage.sh](mailto:sales@vantage.sh). An **Access Policy** limits which cost and resource data the members of a team can see. You build a policy out of filter rules, such as *Provider is AWS*, and assign it to one or more teams. From then on, everyone on those teams sees only the data that matches those rules, no matter which report they open. > [!NOTE] > > Access Policies apply to most cost and resource views, but not to every part of the console. See [which parts of Vantage are covered](/access_policies#coverage) for the full list of what is and isn't included. ## What an Access Policy Does The RBAC features described in [Role-Based Access Control](/rbac) answer one question: **what is this person allowed to open?** Roles, teams, and workspace access all decide which Cost Reports, Dashboards, and other items appear for a user. Access Policies answer a completely different question: **once they've opened it, what are they allowed to see inside it?** It helps to think of the two as a keycard and a redaction. Your existing RBAC setup is the keycard that decides which rooms of the building a person can walk into. An Access Policy is a filter applied to every document in whichever room they enter. They are standing in the room, but they only see the pages that belong to them. Because these are two separate layers, adding an Access Policy changes nothing about your existing setup. All of the following work exactly as they did before: * Organization-level and team-level roles * Team workspace access levels (**Can Edit**, **Can View**, **No Access**) * The Everyone team * [Direct item grants](/rbac#manage-access-for-specific-cost-reporting-items) (**Can Access** and **Cannot Access**) * Who can create, edit, or delete a report > [!TIP] > > A direct item grant and an Access Policy are easy to confuse, so it's worth being precise. A direct item grant hides an **entire item**, such as a whole Cost Report, from a team. An Access Policy lets the team open that same report but blanks out the **rows** they shouldn't see. Use grants to control access to reports; use Access Policies to control access to data. ## Create an Access Policy Only **Organization Owners** can create, edit, or delete Access Policies. A policy is a reusable object. You create it once, give it a name, and assign it to as many teams as you want. Two teams that need the same restriction can share a single policy. **1. Open the Policies list** Navigate to **Settings > Teams**, then select the **Policies** tab. Any policies you've already created appear here, along with the teams each one is assigned to. Click **Create Policy**. > **View screenshot** > > ![The Policies tab under Settings, listing existing Access Policies with their descriptions and assigned teams](https://assets.vantage.sh/docs/access-policies-list.png) > [!TIP] > > You can duplicate an existing policy from this screen or while editing the policy. Click the ellipses (**...**) and select **Duplicate**. If you are editing the policy, save or discard any unsaved changes first. **2. Name the policy and choose its teams** Under **Access Policy Details**, complete the following details: * **Access Policy Name:** Required. Use something that describes the boundary, such as *Data Platform accounts only*, so it's obvious later what the policy does. * **Access Policy Description (optional):** Record why the restriction exists. * **Teams:** Select every team this policy should apply to. You can leave this field empty for now and add teams later; a policy with no teams doesn't affect anyone. > **View screenshot** > > ![The New Access Policy form, with a name, description, assigned team, and a tag filter](https://assets.vantage.sh/docs/access-policies.png) **3. Add filter rules** Under **Access Policy Filters**, add the rules that define what these teams are allowed to see. At least one filter is required. **Save** stays disabled until the policy has one, and the form says "At least one filter is required." The filter builder is the same one you already use on Cost Reports. Each rule has an attribute, a comparison, and a value, for example, *Account is production*. See [What You Can Filter On](/access_policies#what-you-can-filter-on) below for the full list of attributes. Rules combine as follows: * **Rules within one Filter are combined with AND.** *Account is production* and *Region is us-east-1* in the same Filter scopes teams to data that is in *both* that account and that region. * **A single rule can list several values, which are combined with OR.** *Account is production, staging* matches either account. Use multiple values on one rule rather than adding a separate rule for the same attribute. * **Separate Filters (added with "Add a Filter") are combined with OR.** Use a second Filter when a team should see data matching one set of rules *or* another. > **View screenshot** > > ![The Access Policy Filters section with a rule limiting data to AWS for a given team](https://assets.vantage.sh/docs/access-policy-filters.png) **4. Check your work with Preview** Before you save, click **Preview** to see Vantage the way a member of those teams will see it. This step is worth doing every time, because as an Organization Owner you are exempt from Access Policies and won't otherwise notice whether your policy works. See [Preview a Policy](/access_policies#preview-a-policy) for details. **5. Save** Click **Save Changes**. The policy takes effect immediately for everyone on the selected teams. ### Assign a Policy from a Team Instead You can also work in the other direction and start from a team. Start from the policy when one restriction covers several teams, or start from the team when you're setting that team up. Navigate to **Settings > Teams**, select a team, then open the **Access** tab. In the **Policies** section: * Click **Add Policy > Add Existing Policy** to attach a policy you've already built. * Click **Add Policy > Create Policy** to build a new one. The new policy needs at least one filter before you can save it. > **View screenshot** > > ![The Policies section on a team's Access tab, showing the policies currently assigned to that team](https://assets.vantage.sh/docs/access-policies-team-tab.png) > [!NOTE] > > To detach a policy from this team without deleting it, click the ellipses (**...**) next to the policy, select **Remove from Team**, then click **Remove**. The policy remains available to every other team it is assigned to. To delete the policy itself, open **Settings > Teams > Policies** and use the policy's **Delete** action. ## What You Can Filter On Policy rules use the attributes in the table below. Every rule uses one of two comparisons, **is** or **is not**. There is no *contains*, *starts with*, or wildcard matching, so values must match exactly. To allow three accounts, add all three as separate values rather than matching a shared prefix. You write a policy once, and Vantage applies it to Cost Reports, Active Resources (Resource Reports), and Recommendations. Those areas don't all describe data the same way, so an attribute one area understands may not exist in another. When an area can't apply a rule, Vantage drops that rule. If other rules remain, those rules still apply. If every rule is dropped, that area shows no data. Service is one of those rules for Active Resources. *Account is production* and *Service is Amazon EC2* together limit Active Resources to that account, and the Service rule is ignored there. A policy built only from Service rules shows no Active Resources. The same Service rule does scope Cost Reports and Recommendations. The last three columns show which areas honor each attribute. | Attribute | What it matches | Cost Reports | Active Resources | Recommendations | | - | - | - | - | - | | Provider | The cloud or SaaS provider, such as AWS or Azure | | | | | Billing Account | The provider's billing or payer account | | | | | Account | An individual account within a provider | | | | | Region | The provider region | | | | | Service | A specific service, such as Amazon EC2 | | | | | Tag (key and value) | Resources with a specific tag key and value, such as `team` = `data-platform` | | | | | Tag key alone | Resources that carry a given tag key, any value | | | | | Untagged | Resources with no value for a given tag | | | | | Metadata | A provider-specific resource metadata key and value, such as instance type | | | | > [!TIP] > > For a boundary you can rely on, build your policy from Provider, Billing Account, Account, or Region. Those four attributes are honored in every area of Vantage. Pair a tag key with a value when Recommendations matter, such as *Tag key is `team`* and *Tag value is `data-platform`*. A tag key without a value, or Untagged, is dropped for Recommendations. A policy made only of rules an area drops shows no data there. > > When in doubt, [Preview](/access_policies#preview-a-policy) the policy and check each area yourself. ## How Multiple Policies Combine A person can end up with more than one policy, either because a single team has several policies assigned, or because they belong to several teams. The rules below explain what happens. | Situation | What the person sees | | - | - | | Several policies, or membership in several teams | Data matching **any** of those policies | | None of their teams has a policy | Everything | | They are an Organization Owner | Everything | | They apply their own filters to a report | The policy first, then their filters on top | | They use a Personal Access Token | The same data as in the console | | A team service token is used | The data allowed by that team's policies | The first row deserves particular attention: being on more teams gives a person more data, not less. Policies grant visibility rather than removing it, so each team a person belongs to adds to what they can see. To narrow what a person sees, remove them from a team or tighten the policy on a team they already belong to. Adding another, more restrictive policy will not reduce their access. > **Example: two teams, two policies, and more access than expected** > > Tara is on the Trading team, which has a policy of *Account is 4455*. She's then added to the Research team, which has a policy of *Account is 8899*. > > **Result**: Tara sees costs for account 4455 **and** account 8899. Her two policies are combined so she sees data matching either one. > > This is usually what you want: she works with both groups, so she needs both sets of data. But if the intent was to restrict Tara to only the overlap between the two teams, this won't do it. Create a single policy describing exactly what she should see and put her on one team with that policy. > **Example: a person's own filters narrow things further** > > Meagan is on the Data Platform team, which has a policy of *Provider is AWS*. She opens a Cost Report and adds her own filter for *Service is Amazon S3*. > > **Result**: Meagan sees AWS S3 costs only. Her filter narrows what the policy already allowed. She can't widen it. If she removes her S3 filter, she's back to all AWS costs, but never anything beyond AWS. > **Example: a team with no policy at all** > > Matt is on the Finance team, which has no Access Policy assigned. > > **Result**: Matt sees all cost data in any workspace his team can access, exactly as he did before Access Policies existed. Policies only restrict the teams they're assigned to, so leaving a team without one changes nothing for its members. > **Example: an Organization Owner never sees a restriction** > > An administrator with the **Organization Owner** role creates a policy of *Account is 4455*, assigns it to their own team, saves it, and opens a Cost Report expecting to see only that account. They see everything instead. > > **Result**: this is working as designed. Organization Owners always see all data, so a policy assigned to a team an Owner belongs to has no effect on that Owner. Use [Preview](/access_policies#preview-a-policy) to see what everyone else will see. > [!NOTE] > > Access Policies apply across your whole account rather than per workspace, so a policy follows a person into every workspace they visit. When you write a policy, make sure the accounts, providers, and regions it names make sense in every workspace the assigned teams can reach. A policy naming only production accounts will make reports come back empty in a workspace that has no production data. ## What Your Team Members Experience Restricted users may notice the following changes once you apply an Access Policy: * **Many filter menus are shorter:** Vantage limits provider, account, region, tag-value, and Metadata key/value menus to values the policy allows. For example, someone limited to two AWS accounts sees only those accounts in the account picker. * **Anomalies reflect only their data:** Vantage runs anomaly detection separately on the data each combination of policies allows, so the **Anomalies** tab on Cost Reports lists only anomalies in costs the person can see. Archiving or ignoring an anomaly changes it only for people with the same combination of policies. When a policy's rules or a person's team assignments change, the tab can be empty until Vantage next runs anomaly detection. * **Forecasts reflect only their data:** Vantage generates forecasts separately for the data each combination of policies allows, so the **Forecasts** tab and the forecast line on cost charts and Cost Report widgets show that scoped forecast. When a policy's rules or a person's team assignments change, the forecast can be empty until Vantage next generates it. Everything else behaves normally. A restricted person can still open, create, edit, delete, and share reports according to their role, set up notifications, and use the [FinOps Agent](/vantage_finops_agent). They just see less data inside all of it. If a Cost Report has an [anomaly notification](/cost_anomaly_alerts) enabled, Vantage sends it for anomalies detected under each Access Policy on the account. When that notification is an email to an address that belongs to a Vantage user, Vantage skips the email if the anomaly is not for an Access Policy that user has. For all other notifications, Vantage sends the anomaly notification. ## Build Hours There is no cost to create an Access Policy. For accounts using Access Policies, Vantage generates a separate set of Forecasts and Anomalies for each unique combination of policies, on every Cost Report that has Forecasts and Anomaly Detection turned on. This processing consumes [Build Hours](/build_hours) for each run beyond the standard Forecast and Anomalies, which are the runs for costs with no Access Policy applied. The amount for each Cost Report depends on your data retention, the number of services in the report, and the number of unique Access Policy combinations in the account. As an estimate, an average-size enterprise customer adds 1 Build Hour per enabled Cost Report per month for each combination of Access Policies assigned to teams. To manage consumption, set the [workspace defaults](/workspaces#set-workspace-defaults-for-forecasts-and-anomalies) for Forecasts and Anomaly Detection, or turn each on or off for an individual Cost Report in [Manage Forecasts & Anomalies](/cost_reports#forecasts-and-anomalies). Turning either off stops that processing for the report. Previewing a policy does not consume Build Hours. ## Preview a Policy The **Preview** feature temporarily applies the policy you're editing to your own session, so you can verify its boundary before you save. This preview applies only that policy; to test all policies assigned to one team, use the [team preview](#preview-a-teams-combined-policies) described below. **1. Open a policy and add at least one rule** Navigate to **Settings > Teams > Policies** and either create a new policy or open an existing one. Add at least one filter rule. You don't need to save first. Preview works on an unsaved draft. **2. Click Preview** Next to the **Access Policy Filters** heading, click **Preview**. Vantage takes you to your home page and an amber **Previewing** banner appears at the top of the console with the policy's name. > **View screenshot** > > ![The amber Previewing banner at the top of the Vantage console, showing the name of the policy being previewed](https://assets.vantage.sh/docs/access-policies-preview-banner.png) **3. Look around** Browse Vantage as you normally would. Open Cost Reports, Active Resources, Recommendations, and your dashboards. Everything is scoped to your draft rules, so this is your opportunity to confirm that each area restricts data the way you expected, especially Recommendations, which understands fewer attributes than Cost Reports. You'll also see everything else a scoped teammate sees, including the shorter filter menus and scoped Forecasts and Anomalies described in [What Your Team Members Experience](/access_policies#what-your-team-members-experience). **4. Exit and save** Click the **X** on the banner to leave the preview. Vantage returns you to the policy form with your name, description, teams, and filter rules exactly as you left them. Click **Save Changes** to put the policy into effect. ### Preview a Team's Combined Policies After policies are saved and assigned to a team, you can preview how all of that team's policies work together: **1. Open the team** Navigate to **Settings > Teams**, select the team, then open the **Access** tab. **2. Click Preview** In the **Policies** section, click **Preview**. The button is available when the team has at least one policy assigned. Vantage takes you to your home page and displays the amber **Previewing** banner with the team's name. Data allowed by any of the team's policies is included, just as it is for a member of that team. **3. Review and exit** Browse the areas you want to verify. Click the **X** on the banner when you're finished. Vantage returns you to the team's **Access** tab. Keep the following points about Preview in mind: * **Nothing is saved by previewing:** A draft policy doesn't affect anyone until you exit the preview and click **Save Changes**. A team preview doesn't change its assigned policies. Previewing does not consume [Build Hours](/build_hours). * **Nobody else is affected:** A preview applies only to your own browser session. Your teammates, Personal Access Tokens, and service tokens see no change. * **A preview covers either one policy or one team:** Previewing from the policy form applies only the policy you're editing. Previewing from a team's **Access** tab combines all policies assigned to that team. Neither option adds policies from a person's other teams, so someone who belongs to multiple restricted teams may see more data than one team's preview shows. * **A preview session lasts about four hours:** After that, your view returns to normal on its own. ## Frequently Asked Questions > **Which parts of Vantage do Access Policies cover?** > > Access Policies filter cost and resource data across Cost Reports, Active Resources and Resource Reports, Recommendations (active and archived), the dashboard widgets for those areas, the spend figures shown against budgets, CSV and PDF exports, many filter menus in the report builders, and API reads made with a Personal Access Token or team service token. > > They do **not** filter the following items, which stay visible to anyone who can open them: > > * [Financial Commitment Reports](/financial_commitment_reports) and the Commitments list > * [Kubernetes Efficiency Reports](/kubernetes) > * [Network Flow Reports](/network_flow_reports) > * Savings models and Savings Plans dashboard widgets > * [Virtual Tag](/tagging) configuration > * [Cost Alerts](/cost_alerts), [Budget Alerts](/budgets#budget-alerts), and [Report Notifications](/report_notifications). These are evaluated against the full data in the report or budget they monitor. Send them only to people and channels who should see that data. > > The Savings Plan Coverage widget on [Overview](/overview) is hidden for anyone with an Access Policy applied. > **Does a shared Canvas respect Access Policies?** > > No. A [Canvas](/canvas) shows the data from the last time its creator refreshed it, so it reflects the creator's access rather than each viewer's. If you share a Canvas across teams, everyone who can open it sees the creator's version of the data. Use [direct item grants](/rbac#manage-access-for-specific-cost-reporting-items) to control who can open a Canvas that contains sensitive data. > **Why don't Recommendations follow this policy?** > > Recommendations honor Provider, Billing Account, Account, Region, Service, and tag key-value pairs. A **tag key without a value** and **Untagged** are dropped. A policy built only from those rules shows no recommendations. When they are combined with a supported rule, the supported rule still applies and the dropped rules are ignored. > > Service is honored, but it's translated to the recommendation types associated with that service (for example, EC2 maps to EC2-related recommendations). A service with no related recommendation types shows no recommendations. > > Add a rule using a supported attribute, then use [Preview](/access_policies#preview-a-policy) to confirm the Recommendations page is scoped. See [What You Can Filter On](/access_policies#what-you-can-filter-on). > **Why did adding someone to a second team give them more access?** > > Because policies are combined so that a person sees data matching **any** of their teams' policies. Each team acts as another pass that adds to what they can see. > > To tighten what someone sees, remove them from a team or narrow the policy on the team they're on. Adding a more restrictive policy to a second team will not reduce their access. > **Why can't I see the effect of my own policy?** > > Because you're an Organization Owner, and Organization Owners always see all data. This is intentional, so an administrator can never lock themselves out of their own account. > > Use [Preview](/access_policies#preview-a-policy) to see what everyone else will see. > **Can someone tell that a policy is applied to them?** > > Not directly. The policy isn't displayed as a filter on their reports, and they can't see, edit, or remove it. Their totals reflect only their own data, and many filter menus show a shorter list of values. > > Forecasts and anomalies are limited to the costs they can see as well. See [What Your Team Members Experience](/access_policies#what-your-team-members-experience). > **Does an Access Policy stop people from editing or deleting reports?** > > No. Access Policies only control which data a person sees. What they're allowed to create, edit, delete, and share is still governed entirely by their roles, their team's workspace access, and direct item grants, exactly as described in [Role-Based Access Control](/rbac). > > This separation is the point: because the data boundary holds regardless of how a report is built, you can safely give restricted users the **Organization Editor** role and let them build their own reports. > **What happens if a policy matches no data at all?** > > Reports open normally but come back empty, showing \$0 and no rows. The person isn't shown an error or an access-denied message. > > This most often happens when a policy names accounts that don't exist in the workspace the person is looking at. Because policies apply across your whole account rather than per workspace, check that a policy makes sense in every workspace its teams can reach. > **Should I use Access Policies or separate workspaces?** > > They solve different problems and work well together. > > Use **[workspaces](/workspaces)** to organize your integrations into distinct sets of cost data and reporting items, and to give teams entirely separate places to work. > > Use **Access Policies** when several teams need to work in the same workspace and look at the same reports, but each should only see its own slice of the data. > > If you're separating a small number of large groups that never need to share reports, workspaces alone may be enough. If you have many teams sharing reporting items and dashboards, Access Policies avoid duplicating that setup in every workspace. > **Do API tokens respect Access Policies?** > > Yes. A [Personal Access Token](/api/authentication) returns the same data its owner sees in the console, including any policies from their teams. A [team service token](/api/authentication#create-a-vantage-api-service-token) returns the data allowed by the policies assigned to that team. > **Can I assign the same policy to more than one team?** > > Yes, and it's the recommended approach when several teams need the same boundary. A policy is a reusable object, so editing it once updates the restriction for every team it's assigned to. > > To detach the policy from one team, use **Remove from Team** from that team's **Policies** section, or edit the policy and unselect the team. Neither option affects the policy's other team assignments. > **Can I manage Access Policies at scale?** > > Yes. If you [map SSO groups to Vantage teams](/sso#set-up-sso-group-mapping-for-teams), team membership is refreshed each time a user signs in, so Access Policies follow people automatically as they move between groups. You assign the policy to the team once and never touch it per user. # Resource Reports Source: https://docs.vantage.sh/active_resources Monitor active cloud resources and their costs with Vantage Resource Reports across AWS, Azure, GCP, and other providers. For supported providers, Vantage looks for active resources within your account. An active resource is a resource, such as a virtual machine, that is currently generating costs within a cloud account. This is in contrast to resources that are included in billing but may no longer be live. Examples of active resources include items like Amazon S3 buckets, Azure Load Balancers, Snowflake queries, Confluent clusters, etc. You can create *resource reports* to see filtered views of your active resources. These reports provide visibility into all the currently operational resources within your account and the associated costs incurred by each resource. Reports include filterable dimensions, such as account, tag, region, service, and service-specific metadata. Use Resource Reports when you need a current inventory with resource metadata. To see how the number of resources or other cost-bearing groupings changes over time, use [Count reporting in Cost Reports](/cost_reports#count-reporting). > [!NOTE] > > For users on a team with an [Access Policy](/access_policies) assigned, Resource Reports and Active Resources show only the resources the policy allows. Provider, account, region, tag-value, and Metadata key/value menus are also limited to allowed values. CSV exports contain the same scoped data. Active Resources have no service attribute, so a policy built only from Service rules shows no resources. When Service is combined with another rule, the other rule still applies. > [!NOTE] > > Active resource views are currently supported for [AWS](/connecting_aws), [Azure](/connecting_azure), [GCP](/connecting_gcp), [Kubernetes](/connecting_kubernetes), [Snowflake](/connecting_snowflake), [MongoDB](/connecting_mongodb-atlas), [Confluent](/connecting_confluent), [PlanetScale](/connecting_planetscale), [Linode](/connecting_linode), [ClickHouse Cloud](/connecting_clickhouse), [Datadog](/connecting_datadog), [Anthropic](/connecting_anthropic), and [Modal](/connecting_modal). ## AWS Active Resources Vantage shows only active resources that have an associated IAM role. One common source of confusion is when an organization has only a root/management account with an IAM role. To view active resources from each member account, create an IAM role for each member account. As you create each additional IAM role, the member account's resources are automatically added to the active resource inventory. See the [AWS integration](/connecting_aws) documentation for details. Not every AWS service is supported for resource-level costs; however, most services that incur costs are supported. To see the full list of services for which there are resource-level costs, see the documentation on [supported AWS services](/aws_supported_services). ## Azure Active Resources To see the full list of supported Azure services, see the [Azure documentation](/azure_supported_services). > [!NOTE] > > Active Resources are not available for [Azure CSP integrations](/connecting_azure_csp). Azure does not expose any list or describe resource APIs through Partner Center to provide resource metadata. ## GCP Active Resources To see the full list of supported GCP services, see the [GCP documentation](/gcp_supported_services). ## Kubernetes Active Resources A Kubernetes *managed workload* is a higher-level abstraction than a pod that automatically manages pod objects on your behalf. Vantage currently supports Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, and ArgoCD Rollouts and syncs these managed workloads as active resources in your account. When available, pods are grouped by controller, and you can view and filter on the following metadata: * Controller name * Controller type * Cluster * Namespace * Controller labels ## Other Available Active Resources The following active resources are available for the additional providers listed below. | Provider | Available Active Resources | | - | - | | [Snowflake](/connecting_snowflake) | Snowflake queries | | [MongoDB Atlas](/connecting_mongodb-atlas) | MongoDB Atlas clusters | | [Confluent](/connecting_confluent) | Confluent Kafka clusters | | [PlanetScale](/connecting_planetscale) | PlanetScale databases | | [Linode](/connecting_linode) | Linode Instances, Kubernetes Clusters, Volumes, Object Storage, Images, and NodeBalancers | | [ClickHouse Cloud](/connecting_clickhouse) | ClickHouse Cloud services | | [Anthropic](/connecting_anthropic) | Anthropic API keys, Users, and Models | | [Datadog](/connecting_datadog) | Custom metrics | | [Modal](/connecting_modal) | Modal Apps | > [!NOTE] > > Anthropic Users and Models active resources are synced only from the [Claude API integration](/connecting_anthropic#connect-the-claude-api) (Admin API key). If you connect only Claude.ai (Claude Enterprise Analytics API), Claude.ai cost and usage data is still available, but no active resources are synced. See the [Anthropic Active Resources](/connecting_anthropic#active-resources) documentation for details. ## View Active Resources > [!NOTE] > > Active resources are synced for each [workspace](/workspaces) at least once every 24 hours. Vantage syncs all tags specific to a service. **Step 1** From the top navigation, click **Active Resources**. **Step 2** The **Services** screen is displayed, which contains each resource by name (e.g., CloudFront Distributions, Azure Databricks Workspaces, etc.), the total number of active resources, and accrued costs for each resource. The **Accrued Cost** column shows the past 30 days of costs. Select a resource from the parent list to see a list of all resources within that resource group. In the below example, the NAT Gateways resource is selected from the list. **Step 3** Select an individual resource from the filtered list. ![A sample resource report with a box around the NAT Gateways resource in the list](https://assets.vantage.sh/docs/resource-report-child.png) **Step 4** The resource is displayed along with a detailed view of its costs over time. In the below image, the selected AWS NAT Gateway resource is displayed along with associated metadata. ![Resource Report Drill Down](https://assets.vantage.sh/docs/resource-1.png) > [!NOTE] > > When available, a **View in Cost Report** button appears at the top of the active resource detail page, linking directly to the default Cost Report filtered by the resource's provider, service, and resource ID. An **Open in \[Provider]** button also appears, linking directly to the resource in the provider's console (e.g., AWS Console, Azure Portal, or GCP Console). The **Open in \[Provider]** button is available for most AWS, Azure, and GCP resources, as well as PlanetScale databases. Availability depends on the resource type and whether the necessary metadata (such as region or resource identifier) is present. **Step 5** Any tags assigned to the resource, both provider and Virtual Tags, are also displayed in the **Assigned Tags** section at the bottom. Note that Virtual Tags are currently supported for only AWS and Azure resources in this view. ![Assigned Tags on Resource Reports](https://assets.vantage.sh/docs/assigned-tags.png) ## Create a Resource Report Create a resource report to filter by specific resources or groups of resources. Create detailed reports, including reports that show: * Resources across AWS services that match a certain AWS tag * Resources within a specific AWS member account * All Amazon EC2 instances that are a certain type, like `m5.large` * All Snowflake queries belonging to a specific label To create a resource report: **Step 1** From the top navigation, click **Active Resources**. **Step 2** From the left navigation, click **Resource Reports**. You can create new reports and rename your existing reports from this page. The **All Active Resources Report** is provided by default. **Step 3** From the top right of the page, click **New Resource Report**. ![A full list of active resources for an account. The resource's label, type, costs, provider, region, and account are listed.](https://assets.vantage.sh/docs/resource-report-1.png) **Step 4** From the top left of the resource list, click **Filters**. The **Filters** panel is displayed. * Select a **Provider** (e.g., AWS). * Click **New Rule**, then select a filter category, like **Region**. (See the section below for details on available filter options.) * Depending on the filter criteria, select an operator (e.g., is, is not, contains). * Select a value (e.g., *Region* **is** *eu-west-1*). * Click **New Rule** to add additional criteria to the same filter. Results are displayed where both rule 1 *AND* rule 2 are true. * Click + Add Filter to add a new filter set. Results are displayed where *either* filter 1 *OR* filter 2 are true. * At the top of the **Filters** panel, click **Apply Changes**. ![A resource report filter with sample filter criteria for Snowflake and AWS](https://assets.vantage.sh/docs/resource-report-filter.png) **Step 5** At the top of the report, click **Save** or **Save as New**. The report name is displayed in the breadcrumbs above the report. To rename the report, click the pencil icon next to the default report name. Then, update the name and click **Save**. > [!TIP] > > If you have a Jira integration, you can create a corresponding issue for a Resource Report in your Jira instance. See the [Jira](/jira) documentation for details. ## Customize a Resource Report You can customize which columns are displayed in your Resource Reports, such as resource-specific metadata fields and tag values, as well as arrange the columns in any order. Both provider tag keys and [Virtual Tag](/tagging) keys can be added as their own columns so you can analyze tag values across resources at scale. > [!NOTE] > > Resource-specific metadata fields are available only when a Resource Report is filtered to a single service. Reports that span multiple services include only the default columns (i.e., **Label**, **Accrued Cost**, **Resource**, **Type**, **Region**, and **Account**) and any tag key columns you add. The **Accrued Cost** column shows the past 30 days of costs. ### Select Columns To select which columns are displayed on your Resource Report: **Step 1** From the top menu, select **Active Resources** > **Services**, then select a service. (Alternatively, filter a Resource Report to a single service, such as EC2.) **Step 2** From the top-right corner of the report table, click **Manage Columns**. **Step 3** Select or deselect any of the listed columns to adjust the display of your report. ![GIF of selecting custom columns](https://assets.vantage.sh/docs/select-columns.gif) ### Reorder Columns To reorder the columns of your Resource Report: **Step 1** Click and drag a column header to the position between two existing columns. Arrows are displayed to indicate where the column will be inserted. **Step 2** The column order is updated in both the Resource Report and the **Manage Columns** dropdown menu. ![GIF of sorting columns in a resource report](https://assets.vantage.sh/docs/reorder-columns.gif) ### Add Tag Columns You can add specific tag keys as their own columns in a Resource Report so each resource displays the tag value inline, rather than as part of a single grouped tags field. This makes it easier to analyze resources by tag at scale—for example, identifying owners of unattached EBS volumes from [Cost Recommendations](/cost_recommendations), auditing team attribution for the highest-cost RDS instances, or finding resources running in non-prod environments. Both provider tag keys and [Virtual Tag](/tagging) keys can be added as columns. To add tag columns: **Step 1** From the top-right corner of the Resource Report table, click **Manage Columns**. **Step 2** Open the **Tags** section to view available tag keys for the resources in your report. **Step 3** Select one or more tag keys. Each selection is added as its own column to the report. The column header uses the tag key, and each row displays the corresponding tag value for that resource. **Step 4** To save your selections so they persist across sessions, click **Save** or **Save as New** at the top of the report. > [!NOTE] > > * If a resource does not have a value for the selected tag key, the column displays an empty value for that row, making it easy to identify untagged or inconsistently tagged resources. > * There is no limit to the number of tag columns you can add to a Resource Report. > * Tag columns are included in [CSV exports](#export-resource-report) and in API responses for the report. ### Sort Columns To sort a column in a Resource Report, click the arrow next to a column name in the column header. The active sort column icon is highlighted in green, with an arrow indicating the sort direction. Sorting applies across the entire result set, not just the resources visible on the current page. > [!NOTE] > > Sorting on the **Accrued Cost** column requires the report to be saved first. ![GIF of selecting custom columns](https://assets.vantage.sh/docs/sort-columns.gif) The column order is saved per report. If you save a report after you customize the columns, the configuration—including visibility, order, and sort—will persist. ### Resource Report Filters The following filters are available for resource reports. | Filter | Provider | Examples | | - | - | - | | Account | AWS, GCP | AWS or GCP account name (e.g., production) | | Billing Account | AWS | AWS billing account name | | Label | All providers | The resource's label (i.e., name) | | Metadata | All providers | Specific to each resource type (e.g., AWS S3 buckets object count; Azure Load Balancers provisioning state; GCP Dataflow Jobs create time; Confluent Kafka cluster type; MongoDB Atlas cluster deployed region; PlanetScale database branches count; Snowflake query invocations; Kubernetes workload namespace) | | Not Tagged | All providers | Filter to see resources not tagged with a specific tag key or any tag key | | Region | AWS, Azure, GCP, Linode | us-east-1, ap-northeast-2, eastus, us-east4, us-lax | | Resource group | Azure | The Azure resource group name | | Resource type | All providers | EC2 instances, S3 buckets, Confluent Kafka clusters, Snowflake queries, etc. | | Subscription | Azure | The Azure subscription name | | Tag | All providers | Filter to see resource by a specific tag key or tag key/value; Virtual Tags for only AWS and Azure at this time | | UUID (ARN for AWS) | All providers | The unique provider ID (i.e., ARN for AWS) for the resource | ## Export Resource Report To export a resource report, click the export button (looks like an arrow pointing down) on the top right of a resource report (does not need to be saved). The resources in the report are exported in a ZIP file with a CSV file per active resource type. Each row includes an active resource along with its cost and metadata. Any [tag columns](#add-tag-columns) added to the report are also included as dedicated columns in the CSV export. Select one or more Vantage user emails to send the report. Then, click **Export**. It may take a few minutes for the email to be sent. ## Additional Active Resource Views The following tabs are available for specific resources on the **Active Resources** screen. These tabs provide additional resource-specific information. Some of these tabs may also display [Cost Recommendations](/cost_recommendations) relevant to the specific resource you are viewing. In these cases, a recommendation card is displayed at the top of the tab containing a description of the recommendation and remediation steps. The remediation workflow can include CLI commands, links to provider console actions, a list of manual steps, and references to Vantage blogs. When displayed within a specific resource tab, like Rightsizing or Extended Support, the CLI command will automatically include the exact resource ARN of the resource you are viewing. ### Billing Code Descriptions AWS practitioners who are having trouble understanding AWS billing codes can find descriptions of each billing code, other variations of that billing code, and other services that use the same billing code for specific services in Resource Reports. When you view a Resource Report for a specific service (e.g., EC2 instances), a link to [cur.vantage.sh](https://cur.vantage.sh/) is provided that takes you to a page with details for that billing line item. > [!NOTE] > > [cur.vantage.sh](https://cur.vantage.sh/) is a free utility that gives cloud practitioners simple definitions of billing codes for every AWS service. The site has a distinct page for each AWS service (e.g., S3 or EC2) that clusters together similar billing codes for that service, as there may be separate or distinct billing codes for each individual region. ![A Resource Report grouped to show a subcategory link with the corresponding cur.vantage.sh page](https://assets.vantage.sh/docs/cur-active-resource.png) ### Resource Relationships You can view relationships between specific resources on the **Relationships** tab. ![The Relationships tab with an example EBS volume displayed](https://assets.vantage.sh/docs/resource-report-relationships.png) Below are some examples of relationships you may see within your active resources. | Resource | Relationship | | - | - | | Amazon EBS Volumes | See associated EC2 instances, with accrued cost, account, instance ID, region, instance type, launch time, and lifecycle | | Amazon EC2 Instances | See associated EBS volumes and IP addresses, with accrued cost, account, volume type, size, IOPs, and state | | Amazon IP Addresses | See associated EC2 instances, with accrued cost, account, instance ID, region, instance type, launch time, and lifecycle | | Amazon RDS Snapshots | See associated RDS instances, with accrued cost, account, database identifier, engine, engine version, instance type, status, and allocated storage | | Azure Disks | See associated Azure Virtual Machines with accrued cost, account, resource ID, admin username, virtual machine size, boot diagnostics enabled, secure boot enabled, date/time created | | Azure Virtual Machines | See associated disk resources with accrued cost, account, resource ID, disk size, OS type, disk IOPs read/write, disk state, encryption type, network access policy, provisioning state, public network access, zones, and date/time created | | GCP Compute Disks | See associated Compute Instances, with accrued cost, account, instance name, machine type, creation timestamp, CPU platform, and resource URL | | GCP Compute Instances | See associated Compute Disks, with accrued cost, account, disk name, disk type, size, architecture, creation timestamp, and resource URL | > [!NOTE] > > The **Relationships** tab only appears when related resources are found. If a resource has no associated relationships, the tab will not be displayed. ### S3 Storage Summary For S3 buckets, a **Storage Summary** tab is available that provides a list of storage classes, their corresponding storage sizes, and approximate monthly costs for objects in the S3 bucket. ![An example of the S3 Storage Summary screen with Intelligent Tiering suggestions](https://assets.vantage.sh/docs/resource-report-s3-buckets.png) When available, this screen also includes **S3 Intelligent Tiering Considerations** with a table of possible maximum savings you can potentially yield as a result of implementing S3 Intelligent Tiering across all objects in the bucket with Standard Storage. ### S3 Request Metrics and Egress > [!NOTE] > > To view S3 request metrics and egress data, you must configure request metrics on the S3 bucket. It takes roughly 15 minutes for AWS to begin delivering these metrics after they are enabled. See the [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/metrics-configurations.html) for more information about ingress and egress request metrics. > > The required `s3:GetMetricsConfiguration` permission is included automatically via the `VantageS3RequestMetrics` policy in the default CloudFormation template and StackSet. AWS charges you on a per-request basis for S3 with potentially different rates for each request type. The **Request Metrics & Egress** tab provides a summary of request metrics for the bucket and each metric's cost for the trailing 30 days. ![An example of the S3 Storage Summary screen with Intelligent Tiering suggestions](https://assets.vantage.sh/docs/resource-report-egress.png) A graph of each request type (`GET`, `PUT`, `HEAD`, `POST`, `SELECT`, and `LIST`) is provided, which visualizes the total number of requests. The total cost for each request type is also provided. ### EC2 Rightsizing Recommendations For EC2 instances where Vantage identifies rightsizing opportunities, the **Rightsizing** tab is displayed with recommendations. See the [Cost Recommendations](/cost_recommendations) documentation for details. ### CloudWatch Metrics For certain resources, you can view high-fidelity charts for CloudWatch metrics. On resources that support CloudWatch metrics, the **CloudWatch Metrics** tab is displayed. These metrics are useful for rightsizing servers and databases based on utilization. ![Resource Report Drill Down](https://assets.vantage.sh/docs/cloudwatch-metrics.png) When you connect an AWS account to Vantage, CloudWatch metrics are configured automatically, per resource. The following table lists the supported services and the specific metrics displayed for each. | Service | Metrics | | - | - | | EC2 | CPU Utilization, Network In, Network Out, Memory Utilization\* | | EBS | Read Bytes, Write Bytes, Queue Length | | RDS | CPU Utilization, Database Connections, Free Storage Space, Write IOPS, Read IOPS | | S3 | Bucket Size Bytes, Number of Objects | | ECS/Fargate | CPU Utilization, Memory Utilization | *\*EC2 Memory Utilization requires the [CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) to be installed on the instance. If CloudWatch Agent data is not available, a prompt is displayed with a link to the AWS installation documentation.* ### VPC Flow Logs For active resources that generate network traffic costs, such as NAT Gateways and EC2 instances, the **VPC Flow Logs** tab is displayed. Select this tab to view peer resources and the associated traffic category (e.g., public). A Sankey diagram of each associated network flow is provided. See the [Network Flow Reports](/network_flow_reports) documentation for details on network flow reporting. ![Network Flow Report provider resource view](https://assets.vantage.sh/docs/nfr-resource.png) ### Extended Support Recommendations Vantage surfaces metadata and recommendations for AWS services that enter Extended Support to help teams understand upcoming end-of-support milestones and plan upgrades. This information is currently available for EKS, ElastiCache, OpenSearch/Elasticsearch, and RDS. When you view EKS, ElastiCache, OpenSearch, or RDS Resource Reports, additional metadata fields for Support Type (Standard or Extended), Standard Support End Date, and Extended Support End Date are available. From any Resource Report, add a new filter: * Standard Support End Date: `from AWS where Metadata Standard Support End Date is ` * Support Status: `from AWS where Metadata Support Status is ` ![Extended support report](https://assets.vantage.sh/docs/rds-filter.png) A report is displayed and shows resources that match the filter. #### EKS Extended Support > [!TIP] > > For more information on [Amazon EKS Extended Support](https://www.vantage.sh/blog/amazon-eks-extended-support-cost-kubernetes), see the Vantage blog. Select a cluster from the Resource Report list, then select the **Extended Support** tab. On this tab, Vantage provides a list of versions with their standard and extended support dates, displayed in descending order (newest first), as well as the current version of the cluster. Recommendations for the version to upgrade to are also provided. Vantage only recommends versions that have at least 90 days of standard support remaining, ensuring you won't be recommended a version that's about to enter extended support. ![EKS extended support report](https://assets.vantage.sh/blog/eks-extended-support/eks-extended-support-calendar.png) Click **Upgrade** to go to the AWS Management Console and perform the upgrade. #### ElastiCache Extended Support > [!TIP] > > For more information on [Amazon ElastiCache Extended Support](https://www.vantage.sh/blog/opensearch-elasticsearch-elasticache-extended-support), see the Vantage blog. Vantage automatically identifies Amazon ElastiCache for Redis clusters that are in, or approaching, Extended Support. This includes Redis OSS versions with published AWS Extended Support timelines, beginning with Redis OSS v4 and v5. For each ElastiCache for Redis cluster monitored in Vantage, the following process is used to estimate projected Extended Support costs: **Step 1** Look up the End of Standard Support date for the cluster's Redis engine version. **Step 2** Check if the cluster is within three months of this date. * If yes, proceed with cost estimation. **Step 3** Retrieve the relevant Extended Support premium for the supported Redis OSS version. **Step 4** Calculate the projected monthly cost using the Extended Support pricing model published by AWS. Select a cluster from the Resource Report list, then select the **Extended Support** tab. On this tab, Vantage provides upgrade recommendations, including the version required to exit Extended Support. The primary recommendation is to move to ElastiCache for Valkey or to a newer Redis OSS version supported by AWS. Vantage determines the next version number that does not have an Extended Support date within the next three months; however, it is recommended you upgrade to the highest allowable version based on your application's dependencies. Click **Upgrade** to go to the AWS Management Console and perform the upgrade. #### OpenSearch/Elasticsearch Extended Support > [!TIP] > > For more information on [Amazon OpenSearch Extended Support](https://www.vantage.sh/blog/opensearch-elasticsearch-elasticache-extended-support), see the Vantage blog. Vantage automatically identifies Amazon OpenSearch Service domains that are in, or approaching, Extended Support. This includes both legacy Elasticsearch versions and OpenSearch versions with published Standard Support and Extended Support timelines. For each OpenSearch Service domain monitored in Vantage, the following process is used to estimate projected Extended Support costs: **Step 1** Look up the End of Standard Support date for the domain's engine version. **Step 2** Check if the domain is within three months of this date. * If yes, proceed with cost estimation. **Step 3** Retrieve the regional Extended Support fee (per normalized instance hour) for the domain. **Step 4** Calculate projected monthly cost using: $$ \text{Monthly Cost} = \text{Normalized Instance Hours (data + master nodes)} \times \text{Hourly Rate} \times 730 $$ Where **730** represents the assumed average runtime hours in a month. Select a domain from the Resource Report list, then select the **Extended Support** tab. On this tab, Vantage provides upgrade recommendations, including the version required to exit Extended Support. Vantage determines the next version that does not have an Extended Support date within the next three months; however, it is recommended you upgrade to the highest allowable version based on your application's dependencies. Click **Upgrade** to go to the AWS Management Console and perform the upgrade. #### RDS Extended Support > [!TIP] > > For more information on [Amazon RDS Extended Support](https://www.vantage.sh/blog/amazon-rds-extended-support), see the Vantage blog. Vantage automatically identifies Amazon RDS instances that are in, or approaching, Extended Support for MySQL and PostgreSQL. For each Amazon RDS MySQL or PostgreSQL instance monitored in Vantage, the following process is used to estimate projected Extended Support costs: **Step 1** Look up the End of Standard Support date for the instance. **Step 2** Check if the instance is within three months of this date. * If yes, proceed with cost estimation. * If auto-upgrade is enabled for [MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html) or [PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html), the instance is excluded. **Step 3** Retrieve the number of vCPUs for the instance. **Step 4** Retrieve the AWS hourly Extended Support rate (per vCPU) for the region. **Step 5** Calculate the projected monthly cost using: $$ \text{Monthly Cost} = \text{vCPUs} \times \text{Hourly Rate (per vCPU)} \times 730 $$ Where **730** represents the assumed runtime hours in a 30-day month. Select an instance from the Resource Report list, then select the **Extended Support** tab. On this tab, Vantage provides upgrade recommendations, including the version required to exit Extended Support. Vantage determines the next minor version number that does not have an Extended Support date within the next three months; however, it is recommended you upgrade to the highest allowable version based on your application's dependencies. Click **Upgrade** to go to the AWS Management Console and perform the upgrade. ![RDS extended support report](https://assets.vantage.sh/blog/rds-extended-support/rds-extended-support-calendar.png) ### GCP Compute Rightsizing Recommendations For GCP Compute resources where Vantage identifies rightsizing opportunities, the **Rightsizing** tab is displayed with recommendations. See the [Cost Recommendations](/cost_recommendations) documentation for details. ### Kubernetes Rightsizing Recommendations For Kubernetes workloads where Vantage identifies rightsizing opportunities, the **Rightsizing** tab is displayed with recommendations. See the [Cost Recommendations](/cost_recommendations#kubernetes-rightsizing-recommendations) documentation for details on how to view and use this information. ### Datadog Host Costs For cloud resources that have the Datadog agent installed, Vantage can associate Datadog per-host fees along with the primary cloud resources from AWS, Azure, and Google Cloud that drive those costs. > [!NOTE] > > To view these costs and agent information, you need to have a [Datadog](/connecting_datadog) integration, along with either an [AWS](/connecting_aws), [Azure](/connecting_azure), or [GCP](/connecting_gcp) integration. On Active Resource views for resources like EC2 instances or Virtual Machines, the **Associated Datadog Costs** section is displayed and provides a service breakdown of costs. The following resources are supported: * Compute resources with the Datadog agent installed, such as virtual machines or container services * Databases that are monitored by Datadog’s DBM The following Datadog services are supported: * Infrastructure Monitoring * Database Monitoring * APM (Hosts) For eligible resources, the **Datadog Agent Installed** dimension indicates whether the agent is installed. The below image shows resource data for a particular EC2 instance. On the right information panel, the **Datadog Agent Installed** dimension displays **True**. Observe associated Datadog costs for **Infrastructure Monitoring** and **APM** in the table at the bottom. ![The Associated Datadog Costs section is displayed on an active resource](https://assets.vantage.sh/docs/datadog-host-screen.png) You can also create a Resource Report that filters for resources where the Datadog agent is installed. In the below image, the filter looks for EC2 instances where the agent is installed. > [!TIP] > > Vantage automatically generates this type of report when it finds the Datadog Agent installed on relevant resources. Navigate to the [Resource Reports](https://console.vantage.sh/resources) screen. Auto-generated reports will have a name similar to *AWS EC2 Instances with the Datadog Agent Installed*. **Step 1** Select the **Metadata** filter option. **Step 2** For **Resource Type**, select an eligible resource, like **EC2 Instances** or **RDS Instances**. **Step 3** For **Select a Key**, select **Datadog Agent Installed**. **Step 4** For **Value**, select **true**. ![Metadata filter for Datadog Agent costs](https://assets.vantage.sh/docs/datadog-filters.png) ### Datadog Custom Metrics For Datadog accounts with custom metrics, Vantage can surface unused custom metrics that are no longer providing value. Vantage identifies custom metrics that are unused by checking if: * The metric has not been queried in the past 30 days * The metric is not referenced by any dashboards, monitors, notebooks, or SLOs Each custom metric is displayed as an active resource with the following metadata: * **Metric Name**: The name of the custom metric * **Unit**: The unit of measurement for the metric * **Per Unit**: The per-unit cost for the metric * **Description**: Description of the metric * **Short Name**: Short name for the metric * **Statsd Interval**: The StatsD interval for the metric * **Integration**: The integration that created the metric * **Tags**: Tags associated with the metric * **Indexed Volume**: The indexed volume for the metric * **Has Related Assets**: Whether the metric is related to any dashboards, monitors, notebooks, or SLOs * **Has Been Queried**: Whether the metric has been queried in the last 30 days You can create Resource Reports to filter and analyze your Datadog custom metrics, helping you identify which metrics can be removed to reduce costs. In addition, the **Metric Cleanup** tab is displayed. See the [Datadog unused custom metrics](/cost_recommendations#unused-custom-metrics) cost recommendation documentation for details. # Annotations Source: https://docs.vantage.sh/annotations Add contextual notes to Cost Reports with Vantage Annotations. Annotations add context to events or data points within [Cost Reports](/cost_reports). An annotation includes a date and a comment, and is useful for explaining infrastructure changes, deployment events, billing updates, or other context that helps teammates understand a cost change. Annotations can be created manually from a report, or automatically when certain alert types fire: | Annotation Type | How It Is Created | Where It Appears | | - | - | - | | Manual annotation | A user adds it from a report chart or the **Annotations** sidebar. | On the selected Cost Report. | | Cost Alert annotation | A [Cost Alert](/cost_alerts) is triggered. | On the Cost Report associated with the alert event. | | Budget Alert annotation | A [Budget Alert](/budgets#budget-alerts) is triggered. | On the Cost Report associated with the budget alert. | ## Add an Annotation You can add annotations directly from the chart on a Cost Report, or from the **Annotations** sidebar. **From a Report Chart** **Step 1** From any report chart or graph, hover over the chart's bars or line and select the date point you want to annotate. **Step 2** The **Annotations** sidebar is displayed on the right side of the screen. Your username is displayed as well as the date that corresponds with the selected date point on the chart. Enter a comment for the annotation. **Step 3** To save the annotation, click the arrow icon on the bottom right of the comment box. ![Add Annotation From Graph](https://assets.vantage.sh/docs/annotation-add-graph.gif) **From the Annotation Sidebar** **Step 1** From the top right of any report, click the **Annotation** icon (looks like a word bubble). **Step 2** The **Annotations** sidebar is displayed. Click **New**. **Step 3** Select the appropriate date from the date picker, and enter a comment. **Step 4** To save the annotation, click the arrow icon on the bottom right of the comment box. > [!NOTE] > > When you manually create an annotation, [a corresponding issue](/annotations#view-corresponding-issues) is also created. ## View and Edit Annotations **Step 1** To view an annotation, from the top right of any Cost Report, click the **Annotation** icon (looks like a word bubble). **Step 2** The **Annotations** sidebar is displayed, with the most recently added annotation at the top of the list. A vertical line is also displayed on the report chart or graph for dates that have an existing annotation. **Step 3** To edit the annotation, click the ellipses (...) on the top right of the annotation, then select **Edit**. **Step 4** Select a new date from the date picker and/or edit the text in the comment field. **Step 5** To save the annotation, click the arrow icon on the bottom right of the comment box. > [!TIP] > > Clicking an annotation marker (the vertical line) on the report chart scopes the **Annotations** sidebar to that day, making it easier to find the annotations tied to a specific point in time. Clear the day filter to return to the full list. ## Hide Annotations **Step 1** From the top right of any Cost Report, click the **Annotation** icon (looks like a word bubble). **Step 2** From the top right of the Annotations pane, click the **Annotations Settings** icon (looks like a gear). **Step 3** You can toggle an annotation's visibility in the **Chart Display** section. ![Hiding Annotations](https://assets.vantage.sh/docs/hide-annotations.png) ## Delete an Annotation **Step 1** To delete an annotation, from the top right of any Cost Report, click the **Annotation** icon (looks like a word bubble). **Step 2** The **Annotations** sidebar is displayed. Click the ellipses (...) on the top right of the annotation, then select **Remove** > **OK**. > [!TIP] > > Instead of deleting an annotation, consider resolving the annotation, as described below. ## Resolve an Annotation **Step 1** To resolve an annotation, from the top right of any Cost Report, click the **Annotation** icon (looks like a word bubble). **Step 2** The **Annotations** sidebar is displayed. Click the ellipses (...) on the top right of the annotation, then select **Mark as Resolved**. > [!TIP] > > To unresolve an annotation, repeat the previous steps, but instead, select the **Unresolve** option. ### View Resolved Annotations By default, reports hide resolved annotations from the annotations list and chart or graph. **Step 1** To view resolved annotations, click the **Annotation** icon at the top right of the screen. **Step 2** From the **Annotations** sidebar, click the filter icon (next to the **New** button), then click **Show Resolved**. Resolved annotations are displayed in both views. ## Share an Annotation **Step 1** To share an annotation with a teammate, from the top right of any Cost Report, click the **Annotation** icon. **Step 2** The **Annotations** sidebar is displayed. Click the ellipses (...) on the top right of the annotation, then select **Copy Link**. A link is added to your clipboard, which you can use to share with a teammate. ## View Corresponding Issues When you manually create an annotation, a corresponding [issue](/issues) is also automatically created. Budget Alert annotations also have a corresponding issue. Cost Alert annotations are linked to the Cost Alert instead, so their menu shows **Go to Cost Alert** rather than **Go to Issue**. **Step 1** To open the corresponding issue, click the ellipses (...) on the top right of the annotation. **Step 2** Then, select **Go to Issue**. ![View of issue created by an annotation](https://assets.vantage.sh/docs/annotation-issues.png) For manual annotations, the issue is automatically created with the **Annotation** category label attached and a link to the annotated report. The issue's title defaults to the report name and annotation's date. You can use the comment function in the issue to also comment on the annotation. When an annotation is resolved, the corresponding issue will become a closed issue. Unresolving an annotation reopens the corresponding issue. ## Cost Alert Annotations When a [Cost Alert](/cost_alerts) is triggered, an annotation is added to the corresponding Cost Report. This happens even if you do not configure external notification delivery through email, Slack, Microsoft Teams, or Jira. Cost Alert annotations show details about the alert event, such as the alert title, the grouping that triggered the alert, the change amount, and the comparison interval. From the annotation menu, select **Go to Cost Alert** to view or edit the alert configuration. See [Cost Alerts](/cost_alerts) for details on how to set up Cost Alerts. > [!NOTE] > > If Jira delivery is configured for the Cost Alert, the annotation also includes a link to the Jira issue. If Jira delivery is not configured, no Jira issue is created, but the Cost Alert annotation still appears on the report. ## Budget Alert Annotations When a Budget Alert is triggered, an annotation is added to the corresponding Cost Report. See the [Budget Alerts](/budgets#budget-alerts) documentation for details on how to set up Budget Alerts. ## Troubleshooting > **Why do I see Go to Cost Alert instead of Go to Issue?** > > The annotation was created by a Cost Alert. Cost Alert annotations are connected to the alert event, so the menu links back to the Cost Alert configuration. If the alert was also delivered to Jira, the annotation includes a separate **Go to Jira Issue** option. > **Why do I see an annotation without an email, Slack, Teams, or Jira notification?** > > Cost Alerts can be configured without external delivery channels. When a Cost Alert triggers, Vantage still adds an annotation to the associated Cost Report so the event is visible during report review. > **Why did an annotation appear on an earlier date?** > > Alert-generated annotations use the date of the cost event that triggered the alert. Cloud providers can update billing data after the original usage date, so an alert may be detected later while the annotation appears on the date the cost change occurred. # Vantage API Source: https://docs.vantage.sh/api Access Vantage's REST API to programmatically manage cloud cost data. The Vantage API allows you to programmatically access your cost data and create cost resources, like Cost Reports, folders, and dashboards. > [!NOTE] > > Use the API when you need repeatable automation, custom integrations, or raw cost data for your own systems. If you want a point-in-time CSV (optionally FOCUS-formatted) or PDF that matches the current view of a Cost Report, use the [Cost Report export flow](/cost_reports#export-cost-reports) in the Vantage console instead. > **How to use this API reference** > > Browse all API endpoints alphabetically in the left navigation menu. Each endpoint page features a **"Try it"** button at the top that opens an interactive API playground. Enter your [Vantage API token](/api/authentication) to test API calls directly from your browser. > > **Keep in mind that the playground makes real API calls to your Vantage account using your live Vantage data. Exercise caution when testing endpoints that create, modify, or delete Vantage resources.** > > > **See how to use the API playground** > > > > The interactive API playground lets you test endpoints directly from your browser. In the video below, the user opens the API playground and enters their access token. As they fill in parameters on the left, the information populates in the request on the right. Click **Send** to complete the API call. > > > >