Application Security (DPS)

Application Security helps secure cloud-native and on-premise applications at runtime with intelligent automation. This includes visualizing, analyzing, and monitoring security vulnerabilities in your environment and blocking detected attacks on your applications.

Runtime Vulnerability Analytics (RVA)

Dynatrace Runtime Vulnerability Analytics enables you to detect, visualize, analyze, and monitor the remediation of third-party and code-level vulnerabilities in your environment.

Third-party vulnerabilities

Third-party vulnerabilities can arise when your application uses a specific library or language runtime containing vulnerabilities.

Code-level vulnerabilities

Code-level vulnerabilities can arise when Dynatrace Application Security detects a vulnerability in your code by evaluating the requests passing through your applications.

Billing and granularity

The unit of measure for Runtime Vulnerability Analytics is GiB hour (also referred to as "memory-gibibyte-hour" in your rate card). Dynatrace is built for dynamic cloud-native environments where hosts and services are rapidly spun up and destroyed. Therefore, billing granularity for GiB hour consumption is calculated in four 15-minute intervals per hour. When a host or container is monitored for fewer than 15 minutes in an interval, GiB-hour consumption is rounded up to 15 minutes before consumption is calculated.

GiB-hour calculation for physical hosts and virtual machines (VMs)

Each instance that Runtime Vulnerability Analytics runs on consumes GiB-hours based on the monitored host's physical or virtual RAM, calculated in 15-minute intervals (see the diagram example below).

The RAM of each VM or host is rounded to the next multiple of 0.25 GiB (which equates to 256 MiB) before monitoring consumption is calculated.** A 4 GiB minimum is applied to GiB-hour consumption for physical and virtual hosts.

For example, a host with 8.3 GiB memory is counted as an 8.5 GiB host, being the next multiple of 0.25 GiB, while a host with 2 GiB memory is counted as a 4 GiB host (no rounding needed, but application of the 4GiB minimum).

GiB-hour calculation for Containers and application-only monitoring

In cloud-native environments, services and hosts are often short-lived. Therefore calculating monitoring consumption in 15-minute time intervals, rather than full hours, better reflects your actual usage. Containers, which are an essential mechanism in cloud-native environments, are typically smaller in memory size than hosts. Therefore, the minimum memory threshold for containers is 256 MiB, rather than 4 GiB, the minimum memory threshold for hosts. The same rounding as for hosts, to the next multiple of 0.25 GiB, also applies for containers. For example, a container with 780 MiB memory is counted as a 1 GiB container (780 MiB, which equals 0.76 GiB, being rounded up to the next multiple of 0.25 GiB).

Runtime Vulnerability Analytics consumption calculation example

Figure 3. Example Runtime Vulnerability Analytics consumption calculation. Each interval is divided by 4 in order to reach the GiB-hour consumption unit of measure.

Host 1
Runs in the first interval with 2 GiB memory (counted as 4 GiB due to the Host Minimum) = 1.0 GiB/h

Container 1
Runs from in the first and second interval with 780 MiB memory (rounded to 1 GiB) = 0.5 GiB/h

Host 2
Runs from in the first, second, and third interval with 8.3 GiB memory (rounded to 8.5 GiB) = 6.375 GiB/h

Container 2
Runs in the third and fourth interval with 100 MiB memory (rounded to 0.25 GiB) = 0.125 GiB/h

Total 8.0 GiB/h

Runtime Application Protection (RAP)

Dynatrace Runtime Application Protection leverages code-level insights and transaction analysis to detect and block attacks on your applications automatically and in real time.

Billing and granularity for Runtime Application Protection (RAP)

The unit of measure for Runtime Application Protection is a GiB hour (also referred to as "memory-gibibyte-hour" in your rate card). Dynatrace is built for dynamic cloud-native environments where hosts and services are rapidly spun up and destroyed. Therefore, billing granularity for GiB-hour consumption is calculated in four 15-minute intervals per hour. When a host or container is monitored for fewer than 15 minutes in an interval, GiB-hour consumption is rounded up to 15 minutes before consumption is calculated.

GiB-hour calculation for physical hosts and virtual machines (VMs)

Each instance on which Runtime Application Protection is enabled consumes GiB-hours based on the monitored host's physical or virtual RAM, calculated in 15-minute intervals (see the diagram example below).

The RAM of each VM or host is rounded to the next multiple of 0.25 GiB (which equates to 256 MiB) before monitoring consumption is calculated. A 4 GiB minimum is applied to GiB-hour consumption for physical and virtual hosts.

For example, a host with 8.3 GiB memory is counted as an 8.5 GiB host, being the next multiple of 0.25 GiB, while a host with 2 GiB memory is counted as a 4 GiB host (no rounding needed, but application of the 4 GiB minimum).

GiB-hour calculation for Containers and application-only monitoring

In cloud-native environments, services and hosts are often short-lived. Therefore calculating monitoring consumption in 15-minute time intervals, rather than full hours, better reflects your actual usage. Containers, which are an essential mechanism in cloud-native environments, are typically smaller in memory size than hosts. Therefore, the minimum memory threshold for containers is 256 MiB, rather than 4 GiB, the minimum memory threshold for hosts. The same rounding as for hosts, to the next multiple of 0.25 GiB, also applies for containers. For example, a container with 780 MiB memory is counted as a 1 GiB container (780 MiB, which equals 0.76 GiB, being rounded up to the next multiple of 0.25 GiB).

Because Runtime Application Protection is based on code-level insights, Runtime Vulnerability Analytics must run concurrently in the background. Even if you configure a host to only run Runtime Application Protection, your environment will consume GiB-Hours for both Runtime Application Protection and Runtime Vulnerability Analytics.

See the Runtime Application Protection consumption calculation example below.

Figure 4. Runtime Application Protection consumption calculation. Each interval is divided by 4 in order to reach the memory-gibibyte-hour consumption unit of measure.

Host 1
Runs in the first interval; 2 GiB memory (Minimum of 4 GiB applies) = 1.0 GiB/h RVA; 1.0 GiB/h RAP

Container 1
Runs in the first and second interval; 780 MiB memory (round to 1 GiB) = 0.5 GiB/h RVA; 0.5 GiB/h RAP

Host 2
Runs in the first, second, and third interval; 8.3 GiB memory (round to 8.5 GiB) = 6.375 GiB/h RVA; 6.375 GiB/h RAP

Container 2
Runs in the third and fourth interval; 100 MiB memory (round to 0.25 GiB) = 0.125 GiB/h RVA & 0.125 GiB/h RAP

Total Runtime Vulnerability Analysis
0.5 GiB/h + 0.5 GiB/h + 6.375 GiB/h + 0.125 GiB/h = 8.0 GiB/h

Total Runtime Application Protection
0.5 GiB/h + 0.5 GiB/h + 6.375 GiB/h + 0.125 GiB/h = 8.0 GiB/h