How Grafana connects to CloudWatch with the core data source
Your AWS metrics and logs sit in Amazon CloudWatch, but your operations team wants one self-hosted Grafana view that also shows on-premises and other platform data. CloudWatch is a core Grafana data source in the metrics and time series category, so the connection is made with the built-in data source rather than a custom plugin. That matters for support and upgrades: a core data source ships with Grafana itself, and its configuration lives in the same provisioning and access model as your other data sources. This section explains how that connection is set up and what the rest of this page covers, including credentials, cross-account reads, API cost and combining CloudWatch with Prometheus.
Before you configure anything, confirm the current authentication options for the CloudWatch data source against the Grafana data sources documentation. Authentication methods, supported regions and the fields the data source exposes can change between Grafana releases, so check them against the version you plan to run, not against older guides. Also confirm which Grafana release you will standardize on, because the upgrade path for your instance affects how the data source is maintained over time.
The decisions that follow from this connection are practical. Choose how Grafana authenticates to AWS, decide which accounts and regions it may read, and decide whether dashboards built on CloudWatch will be shared outside your organization. A shared dashboard check is worth making early: CloudWatch is on the list of data sources the Grafana documentation confirms work with externally shared dashboards, but the sharing setup still needs to be reviewed against your data classification and your instance's exposure settings.
What you need before connecting CloudWatch to Grafana
Connecting the core CloudWatch data source to a self-hosted Grafana depends on decisions made before anyone opens the data source settings. The account and region scope, the Grafana version and database, the network path to AWS endpoints and the owner of IAM each shape the permissions and the operating model that follow.
AWS accounts and regions in scope
List every AWS account and region whose metrics and logs Grafana must read, and name the business owner for each. CloudWatch metrics and log groups are regional, so a dashboard that spans three regions needs a data source configured to query each one or a plan to route all of them through a single read path. Confirm with AWS documentation which namespaces and log groups each read role will need before writing any policy.
Self-hosted Grafana version and release channel
Record the Grafana version you will run and the patch cadence your team will follow. Grafana publishes major releases yearly, minor releases every other month and patch releases at least monthly, and each minor release has a fixed support window, so the version you pick sets how often you must upgrade. Confirm the current CloudWatch data source requirements against the release notes for that version before you install.
Production database for Grafana configuration
Grafana stores dashboards, data source settings and users in SQLite by default, but the installation docs state SQLite does not scale for production. Plan MySQL 8.0 or later, or PostgreSQL 12 or later, before you add AWS credentials, since those settings and any stored secrets live in this database. Ask your platform team who backs it up and how restores are tested.
Network paths to AWS endpoints
The Grafana server, not the browser, calls the CloudWatch API, so the host running Grafana needs outbound HTTPS to the regional CloudWatch and Logs endpoints for every region in scope. If you run Grafana in private subnets, confirm whether egress goes through a NAT gateway, a proxy or VPC endpoints, and whether your proxy or firewall policy allows those hostnames. Test from the Grafana host itself, since a laptop test proves nothing about the server path.
Ownership of IAM and credentials
Decide who creates the IAM roles or users Grafana uses, who approves read-only policies and who rotates any access keys. Identity teams usually own role trust policies, while the observability team defines which metrics and log groups are visible. Agree this split in writing, because a single shared access key used across environments is the hardest setup to audit or revoke later.
Combined data source and cost awareness
Before enabling dashboards, decide which AWS data will reach Grafana and how often panels and alert rules will query it. CloudWatch API requests are billed by AWS, so refresh intervals, the number of panels and alert evaluation frequency all affect spend. Ask AWS for current request pricing for your regions and agree a refresh policy with the teams who own the dashboards.
Configuring the CloudWatch data source step by step
This sequence takes a self-hosted Grafana from no AWS access to a verified CloudWatch data source, a first metric panel and a log query, with a check at each stage so problems surface before dashboards depend on them.
Create a scoped IAM identity and policy
The AWS account owner or cloud team creates an IAM identity for Grafana and attaches a policy limited to the CloudWatch read actions and the namespaces, regions and log groups the dashboards need. Prefer an IAM role that Grafana assumes through the instance, container or workload identity over long-lived access keys, and confirm which option your Grafana hosting model supports. Done means the policy document is reviewed against the namespaces you listed and the identity appears in IAM with no broader permissions than the scope agreed in writing.
Add the CloudWatch data source in Grafana
A Grafana administrator adds the CloudWatch data source from the connections menu or defines it in a provisioning file loaded at startup. Set the default region, select the authentication method that matches the identity from the previous step, and, if dashboards read from other accounts, record the cross-account role details the data source form asks for. Provisioning files suit teams that keep configuration in version control, while the UI suits a first setup. Done means the data source is saved and listed with the region and authentication method you chose.
Test the data source connection
Run the data source test in the Grafana UI before building anything on top of it. A failed test usually points to an authentication problem, a missing policy action or a wrong region, so check the IAM policy against the error message first. If you use an assumed role, confirm that the trust relationship allows the Grafana identity to assume it. Done means the test returns a success message from the data source settings page.
Build a first metric panel
Create a dashboard and add a time series panel that selects the CloudWatch metrics data source. Choose a namespace, a metric name, a statistic and the dimensions you need, such as instance identifier or load balancer name. Confirm the period and the time range, because CloudWatch returns different datapoints depending on both. Done means the panel draws a series whose dimension values match a resource you can see in the AWS console for the same time window.
Check dimension values and filters
Use the dimension dropdowns and the variable options to confirm that Grafana lists the resources your policy allows and nothing outside it. Create a dashboard variable for a dimension if teams need to switch between resources. Note the number of requests each panel and refresh cycle generates, since CloudWatch API calls are billed separately from the data source itself and can grow with panel count and refresh rate. Done means the variable returns the expected resources and the panel count is recorded for the cost review.
Add a CloudWatch Logs query
Add a second panel or an Explore query that uses the CloudWatch Logs query type against a log group your policy covers. Write a simple filter for a known log pattern and check that matching events return within the selected time range. If the log group is in another account or region, confirm that the cross-account or region settings apply to this query type as well. Done means a log query returns the events you expect and the IAM policy covers only the log groups named in the query.
Confirm access before sharing dashboards
Before a dashboard is shared beyond the team, confirm that the data source access settings and Grafana role permissions match the scope agreed for the IAM identity. Check that the data source is only visible to users who should query those AWS accounts. If you plan to share a dashboard outside the instance, review the shared dashboards documentation to confirm CloudWatch is supported for that sharing model. Done means a user without the right Grafana role cannot open or query the data source, and the sharing decision is recorded.
IAM roles versus access keys for Grafana
When Grafana runs on AWS compute such as an EC2 instance, a container service or a Kubernetes cluster on AWS, the preferred pattern is to attach an IAM role to the workload and let the CloudWatch data source obtain temporary credentials from the instance or task environment. No long-lived access key then needs to be stored in Grafana's configuration or on disk. The role's permissions should be limited to the namespaces, regions and read actions your dashboards and alert rules actually use.
- No stored secret: the workload receives short-lived credentials from the platform, so there is no key file to copy, leak or forget to rotate.
- Narrow policy: scope the role to read-only CloudWatch and CloudWatch Logs actions needed by your panels, and restrict regions where possible.
- Clear audit trail: calls appear under the role's session, which makes it straightforward to attribute queries to the Grafana host.
- Blast radius bound to the host: anyone who gains control of the Grafana host inherits the role's permissions, so the role should never carry write access.
- Shared hosts need care: if several services share the same instance profile, a Grafana request is indistinguishable from theirs in the logs.
Confirm in the current Grafana CloudWatch documentation which authentication method names are offered for the default credential chain, and whether the data source needs an explicit setting to use the instance or task role.
Grafana on-premises, in a data center or in another cloud has no AWS instance role to inherit, so it must authenticate with credentials it holds. The usual options are an IAM user with an access key, or federation that exchanges an identity from your own provider for temporary AWS credentials. Federation keeps secrets out of Grafana but adds an identity provider dependency and more moving parts to build and test.
- Access keys are static: a key stays valid until it is rotated or disabled, so rotation becomes an operational task that must be scheduled and tested.
- Federation shifts the risk: temporary credentials expire on their own, but the trust configuration between your identity provider and AWS becomes a control you must review.
- Secret storage matters: keys should be kept in a secrets manager or encrypted configuration rather than in dashboards, provisioning files committed to Git or plain environment files.
- Dedicated identity per Grafana: a separate IAM user or role per Grafana instance keeps audit records and revocation clean.
- Blast radius of a leaked key: a key outside AWS can be used from anywhere until disabled, so pair it with a read-only policy and monitoring for unusual API activity.
Confirm the credential options your Grafana version supports for the CloudWatch data source and how the secret is stored in the provisioning or configuration files, since both affect rotation.
Many organizations keep metrics and logs in several AWS accounts, such as one per workload or environment. Rather than creating a user in each account, a common design gives the Grafana workload one identity in a central account and lets it assume a read-only role in each target account. The CloudWatch data source can be configured to assume a role for each account, which keeps trust and permissions defined where each account owner can review them.
- One trust chain per account: each target account trusts only the specific Grafana identity and role, so revoking one account's access does not affect the others.
- External IDs for third-party style trust: where accounts are owned by different teams or vendors, confirm whether an external ID condition is required in the trust policy.
- Session duration: check the maximum session duration for each role, because long dashboard sessions depend on how the data source refreshes credentials.
- Audit by account: CloudTrail records in each target account show which role session read its metrics, which helps separate owners.
- Configuration sprawl: each account adds a data source configuration or setting, so keep them in provisioning files reviewed through version control.
Confirm in the current Grafana CloudWatch documentation how assume-role settings are named, whether the data source supports multiple accounts in one configuration, and any limits on role chaining.
Across all three models, the operational difference that matters most is how credentials change over time and how easily you can prove who used them. Rotation is almost free when the platform issues temporary credentials and becomes a recurring project when static keys are involved. Audit quality depends on whether each Grafana instance has its own identity, because shared identities blur accountability.
- Rotation ownership: name the team responsible for each key or trust policy and the trigger for rotating it, such as staff changes or suspected exposure.
- Rotation testing: rotate in a non-production Grafana first, then confirm that dashboards and alert rules still return data.
- Alert rules depend on credentials: a failed credential can silently stop alert evaluation, so monitor data source errors as well as dashboard health.
- Logging: enable CloudTrail in the accounts you query and review read activity from the Grafana identity periodically.
- Revocation path: document how to disable a key or remove a trust statement quickly, and test that step during planning.
Ask your AWS account team and security team to confirm your organization's CloudTrail coverage and key rotation policy before choosing a model.
Mapping AWS namespaces, dimensions and log groups to Grafana queries
This table pairs each CloudWatch concept with the Grafana query editor field or template variable that carries it, and notes what the Grafana side depends on. Read it while building a panel, so you can tell which settings are fixed in the query and which change with the region or account the dashboard is pointed at.
| CloudWatch concept | Grafana field or variable | What to set in Grafana | Dependency to check |
|---|---|---|---|
| Namespace | Namespace dropdown in the metric query | Choose the AWS service namespace, such as the EC2 or RDS namespace, or a custom namespace your applications publish to | Custom namespaces exist only in accounts that publish them, so a dashboard copied to another account may show none |
| Metric name | Metric name field in the metric query | Select the metric, for example a CPU utilization metric, from the list the data source loads for the chosen namespace | The list is filtered by namespace and region, so changing either can clear the selection |
| Dimensions | Dimensions rows in the metric query | Add key and value pairs such as an instance or load balancer identifier, or use a wildcard to match several resources | Dimension values are resource IDs that differ per account and region, so hard-coded values rarely carry over |
| Statistics | Statistic field (Average, Sum, Maximum, percentiles) | Choose the aggregation per period, and use the period setting to control the resolution of the series | Statistic and period choices affect alert behavior, so confirm them against the metric's own semantics |
| Region | Region field in the query, or a dashboard variable | Set a fixed region per query, or add a region variable and reference it in each query | Queries that reference a region variable return empty results if the variable is set to a region with no matching resources |
| Account (cross-account) | Default profile or assume-role setting on the data source | Create one data source per account or role, then select it in each panel or with a data source variable | The assumed role must allow the CloudWatch read actions in the target account, so confirm with the account owner |
| Log group | Log group selection in the CloudWatch Logs query | Pick one or more log groups from the list, or type the names directly for groups the role can read | Log group lists depend on the region and the role's permissions, so the list can be incomplete |
| Logs Insights query | Logs query editor in Explore or a panel | Write the Logs Insights query text and select the log groups it runs against | Insights queries are billed per data scanned, so narrow the time range and log groups before scheduling them |
| Dashboard variables | Template variables for region, account, namespace, or dimension | Use query-type variables so dropdowns repopulate from the chosen region or account | Variables that chain from region or account must refresh when those values change, or stale options remain |
Securing the CloudWatch connection and Grafana instance
A CloudWatch data source gives a Grafana instance read access to AWS account telemetry, and the same instance may be shared outside your organization. The cards below cover the controls that limit that access: the AWS permissions behind the connection, how credentials are stored, who may change the data source, Grafana hardening and what a shared dashboard reveals.
Least-privilege IAM policies by namespace
Write the IAM policy for the Grafana connection around the metric namespaces and log groups your dashboards and alerts actually query, rather than granting account-wide CloudWatch read access. List each namespace and log group in a review with the owning team, then confirm the policy with a test query for each. Read-only actions are enough for dashboards and alert rules, so avoid attaching write or administrative permissions to the same identity. Review the policy whenever a new dashboard needs a new namespace.
IAM roles over long-lived keys
Where the Grafana host runs on AWS, prefer an IAM role attached to the instance or workload over access keys stored in configuration. Roles issue short-lived credentials and avoid a static secret that can be copied off a server. Where Grafana runs outside AWS, confirm with your AWS team which federation or assume-role pattern your organization permits and how the data source is set to use it. Check the chosen method in the data source settings before you rely on it.
Cross-account trust to named roles only
If Grafana reads metrics from several AWS accounts, create one role per monitored account that trusts only the specific role that Grafana uses, and name that principal explicitly. Avoid trust policies that allow any principal in an account or an open external ID. Each account owner should approve the trust and the permissions it grants. Keep a register of which accounts trust the Grafana role so that removing a monitored account also removes its trust.
Secret storage for any keys
If access keys are unavoidable, keep them out of dashboards, provisioning files committed to Git and screenshots. Grafana encrypts data source secrets it stores, but the encryption key and the database still need protection, so restrict who can read the Grafana configuration and database backups. Rotate keys on a schedule your security team sets, and confirm that rotation does not break alerting, which keeps running on the stored credentials. Record who holds each key.
Who can edit the data source
Anyone who can edit a CloudWatch data source can change the credentials and region it uses and, in practice, reach any metric the role allows. Limit data source administration to a small platform group and give dashboard authors view or query access only. Confirm which roles your Grafana edition allows for data source changes in the access control documentation for your version, and audit changes to data sources as part of normal review.
Hardening the Grafana instance
Follow the security hardening guidance for the Grafana server: secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint and domain verification against DNS rebinding. These settings protect the instance that holds the CloudWatch connection, so they matter as much as the AWS permissions. Apply them in a staging copy first and confirm that plugins and dashboards still load.
What externally shared dashboards expose
CloudWatch is confirmed to work with externally shared dashboards, which means a public link can display live AWS metrics without a Grafana login. Before sharing, check which panels query the CloudWatch data source, what account, region and resource names they reveal in titles, labels and legends, and whether the role behind the panels can read more than the dashboard shows. Treat each external share as a disclosure decision that a named owner approves.
Controlling CloudWatch API request cost from dashboards
The AWS account that owns the metrics pays for every CloudWatch API call Grafana makes, so dashboard design is a cost decision, not only a visualization choice. Each panel that queries CloudWatch issues requests, and those requests repeat every time the dashboard refreshes, every time a user changes a variable, and every time an alert rule evaluates. Four drivers matter most: the refresh interval on each dashboard, the number of queries per panel, the fan-out created by template variables, and the evaluation frequency of CloudWatch-based alert rules. A dashboard with a short refresh, twenty panels with several queries each, and a variable that expands to dozens of instances can generate far more requests than the same information on a slower refresh with grouped queries.
Work through these drivers in order. First, confirm which dashboards refresh automatically and at what interval, and set longer defaults for overview dashboards that do not need near-real-time values. Second, count the queries behind each panel, since a panel with several hidden or duplicated queries multiplies its cost. Third, check whether template variables expand to wide dimension sets, such as every instance or every load balancer in an account, and narrow them to the scope a team actually watches. Fourth, review alert rules that query CloudWatch and set evaluation intervals that match how quickly the condition must be detected. Keep in mind that CloudWatch metric and API charges vary by usage type, so use the AWS billing data and cost allocation tags to find the usage types and accounts that grew, rather than estimating from dashboard counts.
Measure before and after any change. Ask your team to pull the CloudWatch-related usage lines from the AWS Cost and Usage Report or Cost Explorer for the accounts Grafana reads, filtered by the IAM role or account used by the data source, and compare them with the dashboards that were most viewed during the same period. Confirm current per-request and metric pricing directly in AWS pricing documentation for your Region, because those rates change and this page does not state them. A cost review should be part of the implementation scope: it covers the baseline measurement, the dashboard and alert changes, and a short report that tells the owners which panels and rules to revisit each quarter.
Combining CloudWatch and Prometheus panels on one dashboard
Put CloudWatch metrics on a shared dashboard only when the operator reading it needs AWS managed service signals next to on-premises or Kubernetes signals to answer the same question, such as whether a load balancer error spike lines up with an application saturation curve. The dashboard should answer one operational question rather than mirror every data source. Each panel keeps its own data source selection, so a single dashboard can hold a CloudWatch panel and a Prometheus panel side by side without merging the queries. Before building, confirm with your team which AWS services and which Prometheus jobs the dashboard must cover, and keep that list short enough that the dashboard stays readable during an incident.
Time and labels are where mixed dashboards most often mislead people. CloudWatch metrics arrive with their own period and statistic settings, and some AWS metrics are published at intervals longer than your Prometheus scrape interval, so the two series can look aligned while being sampled differently. Prometheus series are identified by labels you control, while CloudWatch series are identified by namespace, metric name and dimensions such as the resource identifier. Use panel titles, units and descriptions to state the source and period of each series, and check the Period and Statistic values in each CloudWatch query against the metric's documented resolution before comparing curves. Confirm these details in the AWS and Grafana documentation for the specific metrics you chose, since they vary by service.
Alert rules for each source should stay separate and named by source, so that a responder can tell which system raised a notification and which query to open. Keep CloudWatch-based and Prometheus-based rules in distinct folders or groups, label them with the data source and owner, and route them through the same notification policies only if your on-call process expects that. Treat any rule that combines both sources as a deliberate design choice that needs its own test, because the two sources can have different ingestion delays and outages. The Grafana Alerting and Prometheus integration pages in this group cover the rule and routing mechanics in detail, so use them to design the rule structure before you add cross-source panels.
Common CloudWatch data source failures and fixes
This table pairs the failures teams most often hit when a self-hosted Grafana reads CloudWatch with the likely cause, the check to run and the fix. Read it top to bottom during setup, and return to it when a panel goes blank, a test fails or the AWS bill moves unexpectedly. Most failures trace back to identity, region or namespace settings, so check those before changing anything else.
| Symptom | Likely cause | Check and fix |
|---|---|---|
| Data source test fails with access denied | The IAM role or user lacks the CloudWatch read actions the data source calls, such as listing metrics and fetching metric data | Confirm the identity Grafana uses, then compare its attached policy against the CloudWatch actions listed in the data source documentation. Add only the missing read actions and retest. |
| Data source test fails with credentials not found | Grafana cannot find keys, an instance role or a profile on the host or container running it | Check which auth provider the data source is set to and confirm the host, container or pod has credentials for it. For containers, confirm the task or pod role is actually attached. |
| Panels are empty but the test passes | Wrong region selected on the data source or on the query, so the metrics live in a different region | Open the query editor and set the region that holds the resource. Compare with the AWS console region selector, since a region set per panel can override the data source default. |
| Panels are empty or list no metrics for a namespace | Namespace or dimension names are misspelled, or the metric only publishes in certain conditions | Use the query editor's namespace and metric pickers rather than typing names. Confirm the resource is publishing in CloudWatch by checking the same metric in the AWS console. |
| Cross-account queries are denied | The assume-role trust policy does not allow the Grafana identity, the external ID does not match, or the target role lacks read permissions | Review the trust relationship in the target account and the permissions on the role it assumes. Confirm the external ID configured in Grafana matches the one in the trust policy, then retest from the data source page. |
| Cross-account data appears in some panels only | Some dashboards reference a profile or assumed role that the Grafana identity cannot use, or the target account is missing a required read permission | Check each panel's account setting and the permissions on the role for that account. Test each account separately so one failing profile does not hide the rest. |
| Unexpected rise in AWS API charges | Short dashboard refresh intervals, many panels each issuing metric queries, or dashboards left open on large variable sets | Review dashboard refresh and time range defaults, reduce panels that query the same metrics, and use dashboard variables sparingly. Ask your partner or internal team to review API usage for the CloudWatch read calls in your billing data before and after the change. |
| Alerts do not fire or fire late | CloudWatch metrics arrive with delay or at coarser periods than the alert evaluation interval, so the rule evaluates a window with no data | Match the alert query period and evaluation interval to the metric's publishing frequency. Test the rule with a known condition and set the no-data handling deliberately rather than leaving the default in place. |
| Alerts fire but the query value looks wrong | Metric statistic, period or dimension differs from what the dashboard shows, or the alert uses a different region or account | Compare the alert query with the panel query, including statistic, period, dimensions, region and account. Keep one shared query definition where possible. |
Questions buyers ask about the Grafana CloudWatch integration
Can our team set up the Grafana CloudWatch integration in-house?
Yes, most teams with a running Grafana and an AWS account can connect the core CloudWatch data source themselves, because the setup is a data source configuration plus AWS permissions. The harder part is the surrounding work: deciding which accounts and regions are in scope, designing least-privilege policies, keeping dashboards consistent across accounts, and setting alert rules that do not generate surprise API charges. Ask whether your team has someone who owns both the AWS IAM model and the Grafana provisioning files. If one of those owners is missing, a fixed-scope engagement can cover the design and handover, and your team keeps the running system.
What drives the effort and cost of a CloudWatch integration?
The main drivers are the number of AWS accounts, the number of regions, how many services and log groups are queried, and how much of the setup is done as code. Each of these multiplies the permission design, testing and documentation work. Cost has one-time parts, such as design, configuration and handover, and recurring parts, such as dashboard upkeep, permission reviews and upgrades of Grafana itself. DeployOpen does not publish prices. Ask for a written scope that lists accounts, regions, data sources, dashboards, alert rules and what provisioning or documentation you will receive, so the quote reflects those inputs.
What do we need from our AWS and Grafana owners before work starts?
The work needs decisions from two owners. On the AWS side, you need an account owner who can approve IAM roles or keys, confirm which accounts and regions are in scope, and agree on any cross-account trust. On the Grafana side, you need someone who controls the instance, its data source provisioning and its access model, and who can restart or redeploy it. Also confirm where Grafana runs and how it reaches AWS endpoints, because outbound network rules can block the queries. Request in the scope a list of named owners, change windows and the approval steps for IAM changes.
How long does the integration take when we have several AWS accounts?
The duration depends mainly on account count, because every account adds its own role or trust relationship, its permission review and its verification queries. A single account with a few dashboards is a short configuration task, while many accounts with separate environments add design and testing steps for each group. Timelines should come from the written scope, not from a general estimate. Ask the provider to break the schedule into account groups, state which steps depend on your approvals, and name the acceptance checks for each group.
Should Grafana use IAM roles or access keys for CloudWatch?
IAM roles are generally the better choice for a self-hosted Grafana, because they avoid long-lived access keys that must be stored, rotated and revoked. When Grafana runs on AWS compute, an attached role or an assumed role lets it query CloudWatch without a stored secret. Access keys remain an option when Grafana runs outside AWS, but they then need a secret store, a rotation schedule and a removal process when people leave. Whichever you pick, scope the policy to the namespaces, log groups and actions the dashboards need, and review it on a schedule. Confirm the exact credential settings for your Grafana version in the data source documentation before configuring them.
How do we control CloudWatch API request costs in Grafana?
Costs come from the number of API requests that dashboards and alert rules make, so control starts with query design. Limit panels that refresh frequently, avoid wide queries across many dimensions, and set alert evaluation intervals that match the decision the alert supports. Use dashboard variables carefully, because each variable change can trigger new requests. Ask for a review of query volume during handover and a short list of the most expensive panels. Check current CloudWatch pricing in AWS documentation with your account team, since your bill depends on your own request volume and region.
Where to confirm current CloudWatch behavior before you build
Before you commit to a design, check how the core CloudWatch data source behaves in the Grafana release you plan to run. Start with the Grafana data sources documentation, which lists AWS CloudWatch as a core data source in the metrics and time series category. Use it to confirm which Grafana major version you are targeting, which authentication options the data source supports for your deployment, and how the data source is configured in provisioning files, since those settings decide whether credentials can live in version control. Read the release notes for the exact version you will install, because data source settings and defaults can change between releases. Record the version and the date you checked, so the design review can be repeated if a later upgrade changes the answer.
Next, read the Grafana externally shared dashboards documentation and confirm whether CloudWatch appears on the list of data sources that work with externally shared dashboards. Do not assume a panel works in a public share because the data source works in the main instance. Then verify the AWS side with AWS documentation and your own accounts: the CloudWatch API operations and metric and log query limits in each region, the IAM actions your chosen identity needs, and the pricing for API requests and log queries in your billing currency. Run a test query from a non-production Grafana against a representative account and confirm the results, cost and permissions before you approve a production design.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports self-hosted Grafana inside your own AWS accounts and networks, with the CloudWatch data source wired to the identity model you choose. The work starts from a written scope so that access, dashboards, alert rules and ongoing responsibilities are agreed before any configuration changes are made.
How we scope
- Inventory the AWS accounts, Regions, namespaces and log groups the dashboards must read.
- Decide between an IAM role for the Grafana host and access keys, and record the reason in the scope.
- Map which teams see which accounts and whether Prometheus panels appear beside CloudWatch panels.
- Agree in writing which alert rules, notification paths and dashboards are in the first delivery.
How we build
- Configure the CloudWatch data source with least-privilege read policies scoped to the agreed accounts and resources.
- Set up cross-account assume-role chains where accounts are split, and test each trust path separately.
- Review expected CloudWatch API request volume against dashboard refresh rates and alert evaluation intervals.
- Define data sources, dashboards and alert resources as provisioning files so the setup can be reviewed and rebuilt.
How we hand over
- Test each panel and alert rule against known metric values and confirm the data matches the AWS console.
- Document the IAM roles, trust relationships, provisioning files and the list of dashboards in the deliverables.
- Walk your platform and security teams through access changes, key rotation steps and the request cost drivers.
- Record open items that depend on your AWS account structure, such as organization-level policies.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Review Grafana and plugin release notes before each planned upgrade, so data source changes are tested first.
- Re-check IAM policies and cross-account roles when accounts, Regions or teams change.
- Confirm with your team which support hours, response paths and ownership of dashboards apply before work starts.
