My home LoRaWAN sensors (water meter, pressure sensor, energy meter) push their measurements through AWS IoT Core into an Amazon Aurora DSQL database. To visualize this data I use Grafana Cloud on the free tier, which connects to DSQL through the standard PostgreSQL datasource.

This sounds straightforward, until you hit one detail: Aurora DSQL does not have database passwords. Authentication is done with IAM tokens that expire after a few hours at most. Grafana, on the other hand, stores a static password in its datasource configuration and has no idea the password it holds is a token with an expiry date.

This article covers:

  • why the DSQL “password” is a token and why it must be refreshed often,
  • a Lambda function that refreshes the token and pushes it to Grafana through the Grafana HTTP API,
  • an EventBridge rule that invokes this Lambda every hour, with a retry because the Grafana free tier cluster can be asleep,
  • why least privilege access matters a lot with DSQL, and how I created a read-only user for Grafana.

All the infrastructure is defined with AWS CDK in Python.

The architecture

Architecture: EventBridge triggers a Lambda that generates a DSQL token and updates the Grafana PostgreSQL datasource

Sensor data flows from AWS IoT Core into DSQL through an ingestion Lambda. On the visualization side, Grafana Cloud queries DSQL with the PostgreSQL datasource, using a dedicated read-only user. In the middle, a small Lambda keeps the datasource credentials fresh: every hour, EventBridge invokes it, the Lambda generates a new DSQL authentication token and pushes it to Grafana as the new datasource password.

Aurora DSQL authentication: the password is a token

Aurora DSQL is a serverless, PostgreSQL-compatible database. It is designed to scale, in the words of AWS, virtually without limits. There are no instances to size, no storage to provision, and no CREATE USER alice WITH PASSWORD '...' either. Every connection is authenticated with IAM: you generate a signed token with the AWS SDK or CLI and pass it as the PostgreSQL password.

A token is valid for a limited duration that you choose at generation time. In my case I generate tokens valid for 2 hours:

1
2
3
4
5
6
7
8
9

import boto3

client_dsql = boto3.client(service_name="dsql", region_name=DSQL_REGION)

dsql_password_token = client_dsql.generate_db_connect_auth_token(
    Hostname=CLUSTER_ENDPOINT,
    Region=DSQL_REGION,
    ExpiresIn=2 * 60 * 60,  # seconds
)

This model is great for security: credentials are short-lived, tied to an IAM identity, and never stored anywhere. But it clashes with tools like Grafana that were built around long-lived passwords. If you paste a token into the Grafana datasource configuration by hand, your dashboards will stop working a couple of hours later with an authentication error.

The fix is simple: automate the paste.

The DSQL cluster in CDK

For completeness, this is all it takes to create the cluster. Note the deletion protection, this database holds years of sensor history and I do not want a cdk destroy to take it away:

1
2
3
4
5
6
7
8

from aws_cdk import CfnTag, aws_dsql

dsql_iot_database = aws_dsql.CfnCluster(
    scope=self,
    id="dsql_iot_database",
    deletion_protection_enabled=True,
    tags=[CfnTag(key="Name", value="dsql_iot_database")],
)

Least privilege: a read-only user for Grafana

This part is important. DSQL is built to scale very, very hard, “to infinity” as the marketing goes. That is exactly what you want for ingestion, and exactly what you do not want from a dashboard tool with a badly written query, or worse, a leaked credential. A runaway workload does not hit a connection limit or a saturated instance, it just scales, and so does the bill.

To be fair, my current usage is free: DSQL has a monthly free tier (100,000 DPUs and 1 GB of storage) and my handful of sensors stays well below it. I would like to keep it that way, so Grafana gets its own PostgreSQL role with the strict minimum:

1
2

CREATE ROLE grafana_ro WITH LOGIN;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO grafana_ro;

The grafana_ro role can read the sensor tables and nothing else: no INSERT, no UPDATE, no DDL. On the IAM side, the same principle applies. The token-refresh Lambda is only allowed to generate regular (non-admin) connection tokens for this specific cluster:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

grafana_dsql_token_role.add_to_policy(
    statement=aws_iam.PolicyStatement(
        effect=aws_iam.Effect.ALLOW,
        actions=[
            "dsql:DbConnect",   # generate non-admin tokens
            "dsql:GetCluster",
        ],
        resources=[
            f"arn:aws:dsql:{props.dsql_region}:{self.account}"
            f":cluster/{props.dsql_cluster_name}",
        ],
    )
)

dsql:DbConnectAdmin is deliberately absent. Even if the Grafana API key and the datasource were both compromised, the attacker would end up connected as a role that can only run SELECT.

There is one DSQL-specific detail: to log in as grafana_ro, the IAM identity must also be associated with the PostgreSQL role inside the database (AWS IAM GRANT), which is a one-time setup step done with an admin token. See the DSQL documentation on database roles for the details.

The token-refresh Lambda

The Lambda does two things: generate a fresh token, then update the Grafana datasource with it. The Grafana API key is stored as a SecureString in SSM Parameter Store and read at cold start:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

import logging
import os

import boto3
from api_access import update_datasource_password
from aws_lambda_powertools.utilities.parameters import get_parameter
from aws_lambda_powertools.utilities.typing import LambdaContext

logger = logging.getLogger()
logger.setLevel(os.environ.get("LOGGING_LEVEL", "INFO"))

DSQL_REGION = os.environ["DSQL_REGION"]
CLUSTER_ENDPOINT = os.environ["DSQL_CLUSTER_ENDPOINT"]
GRAFANA_URL = os.environ["GRAFANA_URL"]
GRAFANA_API_KEY_SSM_NAME = os.environ["GRAFANA_API_KEY_SSM_NAME"]
GRAFANA_DATASOURCE_UID = os.environ["GRAFANA_DATASOURCE_UID"]

grafana_api_key = get_parameter(
    name=GRAFANA_API_KEY_SSM_NAME,
    decrypt=True,
)
client_dsql = boto3.client(service_name="dsql", region_name=DSQL_REGION)


def handler(event, context: LambdaContext):
    logger.info("Generate Aurora DSQL token")
    dsql_password_token = client_dsql.generate_db_connect_auth_token(
        Hostname=CLUSTER_ENDPOINT,
        Region=DSQL_REGION,
        ExpiresIn=2 * 60 * 60,  # seconds
    )

    logger.info("Update Grafana datasource.")
    update_datasource_password(
        grafana_url=GRAFANA_URL,
        grafana_api_key=grafana_api_key,
        datasource_uid=GRAFANA_DATASOURCE_UID,
        new_password=dsql_password_token,
    )

The Grafana side uses the datasource HTTP API. There is no PATCH endpoint for a single field, so the function first fetches the current datasource definition, then sends it back with the new password in secureJsonData:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

import requests


def update_datasource_password(
    grafana_url: str, grafana_api_key: str, datasource_uid: str, new_password: str
):
    headers = {
        "Authorization": f"Bearer {grafana_api_key}",
        "Content-Type": "application/json",
    }
    datasource_api_url = f"{grafana_url}/api/datasources/uid/{datasource_uid}"

    response = requests.get(url=datasource_api_url, headers=headers)
    if response.status_code != 200:
        raise ValueError(f"Failed to fetch data source: {response.text}")

    datasource = response.json()

    updated_payload = {
        "name": datasource["name"],
        "type": datasource["type"],
        "typeLogoUrl": datasource.get("typeLogoUrl"),
        "access": datasource["access"],
        "url": datasource["url"],
        "jsonData": datasource.get("jsonData", {}),
        "user": datasource["user"],
        "secureJsonData": {
            "password": new_password,
        },
        "basicAuth": datasource.get("basicAuth", False),
        "isDefault": datasource.get("isDefault", False),
        "database": datasource.get("database", ""),
        "readOnly": datasource.get("readOnly", False),
    }

    update_response = requests.put(
        url=datasource_api_url, json=updated_payload, headers=headers
    )
    if update_response.status_code != 200:
        raise ValueError(f"Failed to update data source: {update_response.text}")

Fields like jsonData (which holds the SSL mode, PostgreSQL version, and so on) must be sent back as-is, otherwise the PUT would reset them.

Scheduling with EventBridge, and why the retry matters

An EventBridge rule invokes the Lambda every hour. Since the token is valid for 2 hours, there is always a full hour of overlap: even if one refresh fails completely, the dashboards keep working until the next one.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

from aws_cdk import Duration, aws_events, aws_events_targets

aws_events.Rule(
    scope=self,
    id="HourlyTrigger",
    description="Trigger the update of DSQL token every hour",
    schedule=aws_events.Schedule.rate(duration=Duration.hours(1)),
    targets=[
        aws_events_targets.LambdaFunction(
            handler=lambda_update_dsql_token,
            retry_attempts=1,
        )
    ],
)

The retry_attempts=1 is not decorative. On the Grafana Cloud free tier, an instance that receives no traffic for a while is put to sleep. When the Lambda then calls the Grafana API, the first request can fail (or time out) while the cluster wakes up. The EventBridge retry, which happens a bit later thanks to exponential backoff, lands on a Grafana instance that is awake again and succeeds. In practice this is enough, I have not needed a more elaborate retry strategy inside the Lambda itself.

The Grafana API key lives in SSM Parameter Store as a SecureString, and the Lambda is only granted read access to that one parameter:

1
2
3
4
5
6
7
8

grafana_api_key_secure_string = (
    aws_ssm.StringParameter.from_secure_string_parameter_attributes(
        scope=self,
        id="GrafanaApiKeySecureString",
        parameter_name=props.grafana_api_key_ssm_name,
    )
)
grafana_api_key_secure_string.grant_read(lambda_update_dsql_token)

Setting up the Grafana side

Two manual steps are needed in Grafana Cloud, both well covered by the official documentation:

  1. Create a service account with a token. The service account only needs the “Data sources / Writer” permission, again least privilege. Follow the service accounts documentation, then store the generated token in SSM:
1
2
3
4

aws ssm put-parameter \
    --name "/iot/grafana/datasource/api_key" \
    --type SecureString \
    --value "glsa_xxxxxxxxxxxx"

  1. Create a PostgreSQL datasource pointing to the DSQL cluster endpoint, following the PostgreSQL datasource documentation. The settings that matter for DSQL:

    • Host: your-cluster-id.dsql.eu-west-1.on.aws:5432
    • Database: postgres
    • User: grafana_ro
    • TLS/SSL mode: require
    • Password: anything, the Lambda will overwrite it within the hour

Once the datasource is saved, note its UID (visible in the URL of the datasource page) and pass it to the Lambda through the GRAFANA_DATASOURCE_UID environment variable.

Conclusion

Aurora DSQL and Grafana Cloud free tier make a nice combination for a home IoT project: the database costs nothing under the free tier (100,000 DPUs and 1 GB of storage per month), scales if the project grows, and Grafana provides the dashboards without hosting anything myself.

The one impedance mismatch is authentication: DSQL only speaks short-lived IAM tokens, Grafana only stores static passwords. A 40-line Lambda invoked hourly by EventBridge bridges the two, with a retry to absorb the free tier cluster waking up from sleep. And because a database that can scale “to infinity” can also bill accordingly, everything runs under least privilege: a SELECT-only PostgreSQL role for Grafana, an IAM role that can only generate non-admin tokens for one cluster, and a service account token scoped to datasource updates.