1.2 SaaS vs. Dynatrace Managed Architecture & Security

Understanding the architectural differences between Dynatrace SaaS and Dynatrace Managed is fundamental to deploying, securing, and maintaining an enterprise observability ecosystem. Both deployment models provide the complete Dynatrace feature set—including full-stack monitoring, Davis AI root cause analysis, PurePath distributed tracing, and Smartscape topology mapping—but they differ substantially in operational responsibility, infrastructure management, upgrade lifecycles, and network topologies.

Architectural Foundations: SaaS vs. Dynatrace Managed

Dynatrace offers two distinct hosting and operational models designed to accommodate diverse organizational requirements, security mandates, and regulatory compliance standards.

Dynatrace SaaS: Cloud-Native Managed Platform

In the Dynatrace SaaS model, the platform control plane, storage clusters, analytics engines, and user interfaces are hosted in public cloud hyperscalers (Amazon Web Services, Microsoft Azure, or Google Cloud Platform). Dynatrace operates as a fully managed service where Dynatrace Site Reliability Engineering (SRE) teams assume complete responsibility for:

• Infrastructure provisioning, compute scaling, and multi-tenant isolation.
• Automated platform updates delivered on a rapid bi-weekly sprint cadence.
• Continuous database optimization, storage rebalancing, and capacity scaling.
• High availability, multi-region disaster recovery, and 24/7 platform health monitoring.

Customers only deploy and manage the lightweight data collectors: Dynatrace OneAgent on their compute hosts and Dynatrace ActiveGate proxies across their network boundaries. SaaS is the default, recommended deployment model for modern cloud-native and hybrid environments because it eliminates operational overhead and guarantees instant access to platform capabilities.

Dynatrace Managed: Self-Hosted Enterprise Control

Dynatrace Managed is an on-premises or customer-managed cloud deployment model. While the customer supplies the underlying infrastructure (bare-metal physical servers, VMware vSphere virtual machines, or private IaaS instances in AWS, Azure, or GCP), the deployment functions as an autonomous, private cloud instance of Dynatrace.

Dynatrace Managed is specifically engineered for enterprises bound by strict regulatory, governmental, or corporate data sovereignty mandates—such as financial institutions, healthcare providers, defense contractors, and sovereign public-sector agencies—where monitored application data, database queries, and code-level transaction traces must physically remain within customer-controlled network perimeters.

In Dynatrace Managed, the platform is partitioned into two distinct administrative layers:

1. Cluster Management Console (CMC): The cluster-level administrative interface used by system administrators to manage cluster nodes, configure storage partitions, monitor hardware resource consumption, provision isolated tenant environments, and define user licensing.
2. Environment Console: The day-to-day observability workspace utilized by development, operations, and SRE teams. Each Managed cluster can host multiple, completely isolated tenant environments (e.g., Development, Staging, Production, or individual business units) with dedicated access controls, dashboards, and alerting rules.

---

The Shared Responsibility Model

The boundary of operational responsibility shifts significantly between SaaS and Managed deployments. Understanding this boundary is critical for capacity planning, system administration, and audit preparation.

---

Connectivity, Network Architecture, and Dynatrace Mission Control

A core security tenet of the Dynatrace architecture is the outbound-only communication paradigm. Regardless of whether SaaS or Managed is chosen, monitored application servers never accept inbound network connections from the Dynatrace platform.

The Outbound-Only Architecture

Traditional application monitoring solutions frequently required inbound firewall holes, allowing central monitoring servers to poll client daemons over proprietary listening ports. Dynatrace eliminates this security vulnerability entirely:

• All communication from OneAgent to ActiveGate occurs over port 9999 (configurable) using TLS-encrypted HTTPS.
• All communication from ActiveGate or direct OneAgent connections to the Dynatrace platform occurs outbound over standard HTTPS (port 443).
• No firewall ports are ever opened inward into customer data centers, production enclaves, or private virtual clouds.

Dynatrace Mission Control: The Autonomous Bridge

In Dynatrace Managed, the cluster operates on customer hardware, but it is not abandoned to manual administration. Instead, it maintains a continuous, outbound-only HTTPS connection to Dynatrace Mission Control (https://mkey.dynatrace.com).

Mission Control provides automated 24/7 operational support, acting as a remote management bridge that delivers:

• Automated Cluster Upgrades: New software versions and security patches are automatically downloaded and staged. Administrators can configure upgrades to install automatically or schedule them during specific maintenance windows.
• Cluster Health and Proactive Alerting: Mission Control continuously monitors cluster node hardware metrics (CPU saturation, memory exhaustion, disk queue depth, network latency) and Cassandra/Grail storage integrity. If a node fails or storage approaches capacity, Dynatrace support is automatically alerted before outages occur.
• Licensing and Consumption Synchronization: Mission Control synchronizes license entitlements, Host Unit consumption, and Davis Data Unit (DDU) tallies.

+-----------------------------------------------------------------------------------------+
|                              WHAT MISSION CONTROL EXCHANGES                              |
+-------------------------------------------------------------+---------------------------+
| TRANSMITTED TO MISSION CONTROL                              | NEVER TRANSMITTED         |
+-------------------------------------------------------------+---------------------------+
| • Cluster operational health (node CPU, RAM, disk usage)    | • Application source code |
| • Cassandra database ring state and sync metrics            | • PurePath trace payloads |
| • Crash dumps and system error logs of cluster services     | • Database query contents |
| • Installed cluster version and OneAgent version inventories | • Monitored host logs     |
| • Aggregated license consumption and billing metrics        | • User session PII data   |
+-------------------------------------------------------------+---------------------------+

Exam Key Point: Telemetry collected by OneAgent—including application traces, method arguments, database connection strings, log lines, and user metrics—never leaves the customer's Managed cluster nodes. Only high-level cluster management metadata and license statistics are transmitted outbound to Dynatrace Mission Control.

---

Managed Cluster Sizing, Hardware, and Storage Architecture

Deploying Dynatrace Managed requires meticulous planning of compute, memory, and filesystem partitions to guarantee cluster stability and support high-throughput data ingestion.

Node Sizing and High Availability (HA) Rules

For production environments, Dynatrace Managed mandates a minimum of 3 cluster nodes to establish a fault-tolerant quorum. The architecture relies on an Apache Cassandra distributed database ring to manage configuration, entity topology, and metadata:

• Minimum Production Cluster: 3 nodes distributed across separate physical server racks, power supplies, or cloud availability zones (AZs).
• High Availability Quorum: A 3-node cluster can withstand the complete loss of a single node (N+1 redundancy) without data corruption or service interruption.
• Non-Production Testing: A single-node cluster is supported strictly for non-production proofs-of-concept, but provides zero redundancy and cannot be scaled without migration.

Mandatory Disk Partitioning

Dynatrace Managed clusters process extreme volumes of write-intensive streaming telemetry. To prevent operating system lockups caused by disk exhaustion, administrators must partition the filesystem into separate logical volumes on dedicated physical or virtual SSD/NVMe drives:

1. Installation Directory (/opt/dynatrace-managed): Contains the core cluster binaries, configuration files, and software executables. Minimum recommendation: 50 GB to 100 GB.
2. Working / Data Directory (/var/opt/dynatrace-managed): Houses the write-intensive databases, Cassandra commit logs, Elasticsearch/Grail indices, and runtime system logs. Minimum recommendation: 500 GB to multiple terabytes, depending on monitored host count and trace retention policies.

Warning on Shared Storage: Storing Cassandra or transaction data partitions on Network Attached Storage (NFS) or high-latency network shares is strictly unsupported. High disk I/O latency on NFS leads to Cassandra read/write timeouts, split-brain scenarios, and cluster instability. Local high-speed NVMe or provisioned IOPS SSD volumes are mandatory.

---

Enterprise Security, Encryption, and Data Privacy

Both SaaS and Managed architectures are designed to satisfy stringent international enterprise security standards, including SOC 2 Type II, ISO 27001, FedRAMP, HIPAA, and GDPR.

Encryption Standards

• Data in Transit: All network channels—from OneAgent to ActiveGate, ActiveGate to cluster, and browser to user interface—enforce TLS 1.2 or TLS 1.3 encryption with modern forward-secrecy cipher suites.
• Data at Rest: All data stored within Dynatrace Managed databases and Dynatrace SaaS cloud storage volumes is encrypted using industry-standard AES-256 encryption.

Identity, Access Management, and Privacy Controls

• Single Sign-On (SSO): Integration with corporate identity providers (IdPs) via SAML 2.0 and OpenID Connect (OIDC).
• Automated User Provisioning: Integration with System for Cross-domain Identity Management (SCIM) to automate user onboarding, role assignments, and offboarding.
• Role-Based Access Control (RBAC): Permissions are bound to Management Zones, ensuring team members access only the servers, applications, and logs belonging to their department.
• Out-of-the-Box Data Masking: Dynatrace includes native masking rules to sanitize sensitive Personally Identifiable Information (PII), credit card numbers (PCI-DSS compliance), passwords, and session data from captured URLs, method arguments, and database bind values.