The auditor asks it at the end of the meeting: « Who actually holds the key that encrypts your observability data? » With BYOK AWS Dynatrace, the answer can be you. Your SaaS environment then encrypts its data with an AWS KMS key that stays inside your own AWS account. That answer has a cost, and you pay it the day someone touches the key.
So I start from the failure, not the procedure. Once you know what breaks, the setup steps read differently. One caveat: span.observer could not test this on a live environment. The facts below come from the Dynatrace documentation page (dated 14 June 2026) and from the AWS KMS documentation. Anything missing from both is marked « unverified ».
BYOK AWS Dynatrace: what you take back
Without BYOK, each environment has its own storage space, encrypted with a key that Dynatrace administers. With BYOK, you swap that key for yours, created and governed in AWS. It protects Grail data and also platform documents: Notebooks, Dashboards and Workflows.
The scope is narrow. You need a Dynatrace SaaS environment hosted on AWS and an active DPS subscription; trial accounts are out. Azure and Google Cloud are announced without a date. None of this applies to Dynatrace Managed.
Before going further, ask yourself honestly whether the requirement is real (a contract, a regulator, an internal policy) or just a reflex. If the Dynatrace-managed key satisfies your compliance framework, BYOK mostly adds one more dependency to run.
What breaks when the key goes away
Dynatrace must be able to reach every key you hand over at all times, retired ones included. If access to the active key is cut, the documentation lists three effects:
- nothing more is written to permanent storage;
- Dashboards, Notebooks and Workflows can be neither opened nor saved;
- every Grail query fails.
A cache holds incoming data for a few hours before the final write, so a short blip may pass without loss. Beyond that window the page is silent about pending data: unverified, assume it is lost.
Worse, a deleted or revoked key makes everything it encrypted unrecoverable. In AWS, deletion goes through a waiting period of 7 to 30 days (30 by default). During it the key shows « Pending deletion » and cannot be used, but you can still cancel. That window is your safety net. When in doubt, AWS suggests disabling rather than deleting.
The takeaway: Dynatrace’s access to the key is a production dependency, like the API token an integration relies on. It deserves an owner, an alert and a line in the runbook.
Setup, in the order that saves round trips
You need one right on the Dynatrace side: the account administrator permission « View and manage account and billing information » (see users, groups and permissions). On the AWS side you must be able to create a KMS key; the exact IAM rights are not spelled out, unverified. Also make sure the security contact and at least one emergency contact are filled in on the account, since they are the ones warned when access degrades.
Fetch the key policy
In Account Management: Settings, Environments, your environment’s row, the Encryption keys tab, then Add encryption key. Note the Region, because the AWS key has to live there. Under Copy Snippet, copy the proposed policy.
It holds two statements. One lets a Dynatrace AWS account manage grants (kms:CreateGrant, kms:ListGrants, kms:RevokeGrant), provided kms:GrantIsForAWSResource is true. The other opens the everyday cryptographic operations: kms:Encrypt, kms:Decrypt, kms:ReEncrypt*, kms:GenerateDataKey* and kms:DescribeKey. The account ID is a placeholder, <dynatrace_account_id>, in the documentation.
This screenshot shows the public example. Your wizard generates the real values, so use its block instead.
Create the key in KMS
In the AWS KMS console the settings are not negotiable: same region as the environment, symmetric key, usage « Encrypt and decrypt », KMS as key material origin, single-Region key.
Paste the policy under Edit key policy, with a comma between your existing statements and Dynatrace’s. According to AWS, a principal like arn:aws:iam::ID:root delegates access to the account’s IAM policies, so have your cloud team review the whole thing. Finally copy the ARN, which begins with arn:aws:kms:.
Register, then activate
Back in the wizard, choose Next, name the key, paste the ARN and choose Save. Dynatrace tests the key with a temporary write and read. If that fails, check the region, the policy and the ARN format (arn:aws:kms…).
Saving is not enough. In the row’s menu choose Activate and confirm. From then on, new data is encrypted with your key. The page mentions no re-encryption of what already exists.
How to check that it works
- The key is listed under Encryption keys after validation.
- Open an existing Dashboard and run a Grail query: those are the actions that fail when access drops.
- Ask the security contact to confirm that Dynatrace’s emails arrive.
No key-access status indicator is described beyond those notifications: unverified, so do not build an SLI on it.
Rotation, and backing out
The recommended route is AWS KMS automatic rotation, which needs no action in Dynatrace. For a symmetric key with KMS-generated material the default period is 365 days; KMS decrypts with whichever material version did the encrypting, and nothing is re-encrypted.
Manual rotation means creating a new key and replaying the steps. Older data stays tied to the old key, which must therefore remain available.
To give up BYOK, activate the DYNATRACE DEFAULT KEY. New data goes back under Dynatrace’s key, but older data still depends on yours: do not delete it.
The minimum runbook
- A named owner for the key and its policy, with few people allowed to edit it.
- A written rule: disable, never delete, a key that has encrypted data.
- A security contact and two emergency contacts reachable outside office hours.
- KMS automatic rotation switched on.
- An incident procedure for « key access lost », with cancelling a scheduled deletion as the first move.
Frequently asked questions
Does BYOK work on a trial account?
No. It needs an active DPS subscription and a SaaS environment on AWS.
What do we lose if the key is revoked in AWS?
Permanent writes, document access and Grail queries all stop. If the key is deleted or revoked for good, the data it encrypted is gone.
Must Dynatrace be reconfigured at every rotation?
Not with KMS automatic rotation. A new key does require registering and activating it again.
Conclusion
BYOK AWS Dynatrace answers a need for control, and it hands your team the availability of the key. Setup takes four steps; the discipline afterwards matters more. Before you start, reread the official page: Manage AWS encryption keys.
span.observer is an independent blog, not affiliated with Dynatrace LLC or AWS. Trademarks belong to their owners. Features change: check every setting in the official documentation before applying it in production.
Originally published on span.observer. French version: https://span.observer/fr/byok-aws-dynatrace-cle-chiffrement-client/.
Top comments (0)