1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)

Effectively managing a modern enterprise observability platform requires a comprehensive understanding of commercial licensing, capacity metering, and consumption governance. Dynatrace has evolved its commercial framework from rigid, component-based licensing into a flexible, consumption-driven model known as the Dynatrace Platform Subscription (DPS). Understanding how Host Units (HUs) and Davis Data Units (DDUs) are metered ensures organizations maximize observability coverage while optimizing budget efficiency.

---

The Evolution of Licensing: Classic vs. Dynatrace Platform Subscription (DPS)

Historically, software monitoring vendors required customers to purchase isolated, product-specific licenses. Dynatrace originally offered a Classic Licensing model that segmented platform capabilities into distinct licensing buckets. While still encountered in legacy contracts, modern deployments overwhelmingly leverage DPS.

Classic Licensing: Siloed Entitlements

In the Classic model, an enterprise purchased fixed quantities of individual license components:

• Host Unit Licenses: Reserved strictly for full-stack or infrastructure server monitoring.
• Digital Experience Monitoring (DEM) Units: Reserved for Synthetic tests and Real User Monitoring (RUM) sessions.
• Log Management Licenses: Purchased based on gigabytes of log data ingested per day.
• Davis Data Unit (DDU) Pools: Purchased specifically for custom metrics and cloud API polling.

The Limitation: Classic licensing frequently led to stranded capacity. If an organization modernized applications by migrating from large monolithic virtual machines to serverless functions, their unused Host Unit licenses could not be converted to cover synthetic testing or cloud metric spikes without commercial contract renegotiation.

Dynatrace Platform Subscription (DPS): The Unified Commitment Pool

The Dynatrace Platform Subscription (DPS) replaces fragmented licenses with a single, unified annual or multi-year financial commitment. Under DPS:

• The customer commits to an annual platform spend balance.
• Every capability—OneAgent full-stack monitoring, Grail log ingestion, DQL query compute, Synthetic monitors, Davis AI causation, and automated Workflows—draws down against the identical commitment balance based on transparent hourly or volume-based consumption rates.
• Organizations enjoy complete architectural flexibility: as workloads shift from virtual machines to Kubernetes or serverless containers, consumption dynamically adapts without contractual friction.

---

Host Unit (HU) Sizing Mechanics and Calculation Rules

For server and virtual machine monitoring, Dynatrace meters capacity using Host Units (HUs). Sizing is determined purely by the physical RAM of bare-metal servers or the allocated vRAM of virtual machines, completely independent of CPU core counts.

Full-Stack Monitoring Calculation

Full-Stack monitoring delivers deep code-level tracing (PurePath), process discovery, service flow mapping, network analysis, and infrastructure metrics. The baseline consumption ratio is: $\text{1.0 Host Unit} = \text{16 GB of Host RAM}$

For systems with less than 16 GiB of RAM, Dynatrace applies fractional tiers taken from the official host unit weighting table:

• $\le$ 1.6 GiB RAM: Consumes 0.10 HU.
• $\le$ 4 GiB RAM: Consumes 0.25 HU (1/4 of a Host Unit).
• $\le$ 8 GiB RAM: Consumes 0.50 HU (1/2 of a Host Unit).
• $\le$ 16 GiB RAM: Consumes 1.0 HU.

When a host's RAM falls between two rows, Dynatrace rounds up to the next tier. A host with 12 GiB of RAM therefore consumes a full 1.0 host unit, because 12 GiB sits between the 8 GiB and 16 GiB rows. This rounding rule is a favourite exam trap: candidates who compute $12 \div 16 = 0.75$ get the question wrong.

For systems exceeding 16 GB of RAM, consumption scales linearly in 16 GB increments:

• 32 GB RAM: Consumes 2.0 HUs.
• 48 GB RAM: Consumes 3.0 HUs.
• 64 GB RAM: Consumes 4.0 HUs.
• 128 GB RAM: Consumes 8.0 HUs.

Infrastructure-Only Monitoring Calculation

Many organizations operate supporting server fleets—such as database replica nodes, intermediate proxies, batch file servers, or storage appliances—where code-level application execution is absent, but operating system health, disk saturation, and network metrics remain critical.

For these workloads, administrators configure OneAgent in Infrastructure-Only Monitoring mode:

• Infrastructure-Only mode consumes 0.3 Host Units per 16 GiB of RAM (a 70% reduction compared to Full-Stack mode).
• A 16 GiB server consumes 0.3 HU; a 32 GiB server consumes 0.6 HU; a 48 GiB server consumes 0.9 HU.
• Critical cap: Infrastructure-mode consumption is capped at 1.0 host unit per host. A 64 GiB server therefore consumes 1.0 HU, not $4 \times 0.3 = 1.2$ HUs, and a 512 GiB server also consumes just 1.0 HU. The cap is what makes Infrastructure mode dramatically cheaper on large database and storage nodes — the bigger the box, the larger the saving.

+-----------------------------------------------------------------------------------------+
|                           HOST UNIT (HU) SIZING REFERENCE TABLE                         |
+-----------------------+-----------------------------+-----------------------------------+
| HOST MEMORY (RAM)     | FULL-STACK MONITORING (HU)  | INFRASTRUCTURE-ONLY MODE (HU)     |
+-----------------------+-----------------------------+-----------------------------------+
| Up to 1.6 GiB         | 0.10 HU                     | 0.03 HU                           |
| Up to 4 GiB           | 0.25 HU                     | 0.075 HU                          |
| Up to 8 GiB           | 0.50 HU                     | 0.15 HU                           |
| Up to 16 GiB          | 1.0 HU                      | 0.3 HU                            |
| 32 GiB                | 2.0 HUs                     | 0.6 HU                            |
| 64 GiB                | 4.0 HUs                     | 1.0 HU (capped)                           |
| 128 GB                | 8.0 HUs                     | 2.4 HUs                           |
+-----------------------+-----------------------------+-----------------------------------+

Kubernetes & Container Sizing Note: In Kubernetes and OpenShift clusters, OneAgent is licensed at the underlying worker node level based on each node's physical or virtual RAM. Once a worker node is licensed, all containers, pods, microservices, and namespaces running on that node are monitored with zero additional per-container licensing fees.

---

Davis Data Units (DDUs): Structure and Consumption Mechanics

While Host Units cover standard server and process infrastructure, modern environments ingest vast streams of telemetry from external systems. Davis Data Units (DDUs) serve as the universal consumption currency for custom data and third-party integrations.

Telemetry Types Powered by DDUs

DDUs meter three primary telemetry streams:

1. Custom Metrics: Application or business metrics ingested via the Dynatrace REST API, OpenTelemetry metric exporters, StatsD, or Micrometer.
2. Cloud Provider Integrations: External hypervisor and PaaS metrics polled via ActiveGate integrations from Amazon Web Services (AWS CloudWatch), Microsoft Azure Monitor, and Google Cloud Monitoring.
3. Dynatrace Extensions 2.0: Performance metrics gathered from network appliances (SNMP), mainframe systems, Windows infrastructure (WMI), Java management beans (JMX), and Prometheus endpoints.

Metric Consumption Weighting

Metric consumption in Dynatrace is calculated based on the number of data points reported over time:

• One continuously reported metric tuple (1 metric data point reported once every 60 seconds) produces 525,600 data points per year.
• Each ingested metric data point deducts 0.001 DDU from the quota, so one continuously reported metric tuple consumes $525{,}600 \times 0.001 = \mathbf{525.6\text{ DDUs}}$ per year.
• High-cardinality metadata multiplies metric streams: if a custom metric orders.processed is split across 5 distinct regional dimensions, it forms 5 unique metric time series, consuming roughly $5 \times 525.6 = \mathbf{2{,}628\text{ DDUs}}$ annually. Dimension explosion — not raw metric count — is what destroys DDU budgets.

---

Cost Governance, Quota Allocation, and Spend Optimization

Without proactive governance, modern microservice architectures can generate explosive telemetry volumes that rapidly deplete organization budgets. Dynatrace provides robust administrative controls to meter and restrict consumption.

DDU Pool Management and Hard Caps

Within Dynatrace Account Management, administrators configure distinct DDU Pools mapped to specific environments or business units:

• Custom Metrics Pool: Establishes monthly or annual quotas for custom metric ingestion.
• Cloud Integration Pool: Controls metric volume ingested from AWS CloudWatch or Azure Monitor.
• Log Ingestion Pool: Restricts log ingestion volumes.

Administrators can configure pools with soft notifications (alerting administrators when 80% of budget is reached) or hard caps (automatically dropping incoming telemetry once the quota is exhausted to prevent unplanned overage charges).

Telemetry Optimization Strategies

1. Metric Ingestion Filtering: Configure rules at the ActiveGate or platform level to discard noisy, low-value metric dimensions before they are metered.
2. CloudWatch Namespace Selection: Rather than polling all AWS metrics, restrict ActiveGate polling configurations to essential namespaces (e.g., AWS/EC2, AWS/RDS), omitting high-volume, low-utility metrics such as basic EBS volume statistics.
3. Automated Host Group Rules: Utilize Host Groups and automated deployment rules to assign development and staging clusters to Infrastructure-Only monitoring mode by default, reserving Full-Stack monitoring for critical staging and production environments.