13.1 AWS, Azure & Google Cloud Integrations
Key Takeaways
- Cloud Integrations is a separately scored Associate exam topic covering agentless ingestion of provider metrics that OneAgent cannot see.
- AWS monitoring supports role-based and key-based authentication; key-based authentication is restricted to the AWS GovCloud and China partitions, so role-based is the standard choice.
- Classic AWS CloudWatch polling requires at least one ActiveGate that can reach CloudWatch, whereas CloudWatch Metric Streams pushes metrics through Kinesis Data Firehose to the Dynatrace API and needs no ActiveGate.
- Cloud integrations complement rather than replace OneAgent: they cover managed services such as RDS, Lambda, and load balancers where no agent can be installed.
- Cloud service entities join the same Smartscape topology as agent-monitored hosts, which is what lets Davis include a managed database or queue in a root-cause chain.
OneAgent instruments what you can install software on. A modern cloud estate is full of things you cannot: an Amazon RDS instance, an Application Load Balancer, an SQS queue, an Azure Service Bus namespace, a Google Cloud Pub/Sub topic. Cloud Integrations is the exam topic that covers how Dynatrace fills that gap, and it appears as its own line on the certification score report.
The mental model to carry into the exam: cloud integrations are agentless, API-based ingestion of provider-side metrics, and they complement OneAgent rather than replacing it.
Why Agentless Ingestion Is Necessary
| Scenario | Who reports it |
|---|---|
| EC2 instance running your application | OneAgent — full-stack, code-level |
| Amazon RDS engine internals | Cloud integration — no agent possible |
| Lambda function invocation counts, throttles, errors | Cloud integration (plus OneAgent Lambda instrumentation for traces) |
| Application Load Balancer request counts and 5xx rates | Cloud integration |
| Kubernetes node in EKS | OneAgent via the Operator |
| EKS control plane | Cloud integration — AWS manages the control plane |
A question that offers "install OneAgent on the managed database instance" is testing whether you know the boundary.
AWS: Authentication and Two Collection Paths
Authentication
Dynatrace supports role-based and key-based authentication for AWS monitoring.
- Role-based is the standard, recommended method: you create an IAM role in the monitored AWS account with a trust relationship to Dynatrace and a read-only monitoring policy. There are no long-lived credentials to rotate or leak.
- Key-based authentication uses an access key ID and secret. It is allowed only for the AWS GovCloud and China partitions, where the cross-account role mechanism Dynatrace uses is not available.
That restriction is a favourite exam detail. If a scenario describes a commercial AWS region and an answer proposes key-based authentication for convenience, it is wrong.
Collection path 1 — CloudWatch polling (classic)
Dynatrace integrates with Amazon CloudWatch to pull metrics remotely. In this model at least one ActiveGate must be able to connect to Amazon CloudWatch to perform the monitoring tasks. Dynatrace automatically identifies and collects metrics from the AWS services CloudWatch supports — currently around 95 services.
Because this is polling, the trade-offs are the ones you would expect: metric latency is bounded by the polling interval, and very large accounts generate substantial CloudWatch API request volume, which AWS bills separately.
Collection path 2 — CloudWatch Metric Streams
CloudWatch Metric Streams inverts the flow. All metrics issued in a given AWS region are streamed through Amazon Kinesis Data Firehose to the Dynatrace API. Two consequences matter for the exam:
- No ActiveGate is required for the metric path, because AWS pushes to Dynatrace rather than Dynatrace pulling from AWS.
- Metrics arrive with lower latency and without per-request CloudWatch polling costs.
When a scenario emphasizes "we cannot deploy an ActiveGate with outbound access to CloudWatch" or "our CloudWatch API charges are unacceptable," Metric Streams is the intended answer.
Azure and Google Cloud
The pattern repeats with provider-specific mechanics.
- Azure monitoring is configured against an Azure Active Directory (Entra ID) application registration granted the Monitoring Reader role on the subscriptions to be observed. Dynatrace then reads Azure Monitor metrics for services such as App Service, SQL Database, Functions, Cosmos DB, and Service Bus. Azure App Service additionally supports OneAgent instrumentation via a site extension, giving you full-stack tracing on top of the platform metrics.
- Google Cloud monitoring uses a service account with monitoring read permissions, ingesting Cloud Monitoring metrics for services such as Cloud SQL, Pub/Sub, GKE, and Cloud Run.
Across all three providers, credentials are always read-only monitoring scopes. Any answer that requires write or administrative permissions to a cloud account for observability is wrong.
Cloud Entities in Smartscape
The real payoff is not the metrics — it is the topology. Ingested cloud services become entities in Smartscape, sitting alongside agent-monitored hosts, processes, and services. Because Davis reasons over that shared dependency graph (Chapter 7), it can produce a root cause such as:
Checkout service response time degraded → calls to
orders-dbslowed →orders-dbis an Amazon RDS instance whose CloudWatchWriteLatencyandDatabaseConnectionsmetrics both spiked.
Without the cloud integration, the chain would dead-end at "the database is slow" with no evidence about why. This is the argument the exam wants you to be able to make: agentless cloud data is valuable because it joins the same topology, not because it is an extra dashboard.
Cost and Scoping
Cloud integrations are metered — the polled or streamed metric data points consume platform capacity. The governance controls are therefore important operationally and appear in exam scenarios:
- Scope by service: enable only the AWS/Azure/GCP services you actually need rather than every supported service.
- Scope by resource: use tag-based filters so that only production resources are monitored.
- Prefer recommended metric sets over "all metrics" for high-cardinality services.
The wrong answer in a cost scenario is always "disable the integration"; the right answer is to narrow its scope.
An enterprise is configuring AWS monitoring for workloads in the eu-west-1 commercial region. A contractor proposes generating an IAM access key ID and secret because it is faster than configuring cross-account trust. What is the correct assessment?
A security policy forbids deploying any ActiveGate with outbound connectivity to Amazon CloudWatch, yet the team must ingest CloudWatch metrics for managed services. Which approach satisfies both requirements?
After enabling AWS cloud integration, an architect wants to explain the concrete analytical benefit over simply viewing the same metrics in the AWS console. What is the strongest justification?