Skip to article
Databases Azure Database for MySQL

MySQL private access

MySQL private access means a MySQL Flexible Server networking model that keeps database connectivity inside a virtual network instead of exposing a public endpoint. You see it when teams host sensitive workloads, enforce network isolation, connect applications through private subnets, or meet compliance expectations. Think of it as private network reachability for the database, not permission to read the data. It matters because the setting changes how teams design, secure, operate, and troubleshoot the workload. Before changing it in production, know the owner, dependency, evidence, expected result, and rollback path.

Source: Microsoft Learn - Private network access using virtual network integration for Azure Database for MySQL - Flexible Server Reviewed 2026-05-16

Exam trap
Treating MySQL private access as a generic label instead of checking the live Azure resource state.
Production check
Confirm the resource scope, region, owner tag, and current provisioning state.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-16
Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

MySQL private access matters because it reduces public exposure and gives teams a clearer network boundary for sensitive MySQL workloads. If teams treat it as a loose label, they can break connectivity through DNS or subnet mistakes, or assume private networking replaces credential controls. The practical value is a more defensible access path with evidence for auditors and operators. A strong implementation shows the owner, scope, dependent workloads, current settings, monitoring signals, and rollback steps. That evidence makes design reviews clearer, incidents shorter, audit responses stronger, releases safer, and future operators less dependent on tribal knowledge. Before approving a change, confirm the business reason and the Microsoft Learn source behind the decision.

Official wording and source

Microsoft Learn describes private access for Azure Database for MySQL as keeping server connectivity inside a virtual network. It relies on private networking and DNS design, while authentication, TLS, database permissions, and monitoring remain separate security responsibilities. This supports safe production planning, operations, and review.

Open Microsoft Learn

Technical context

Technically, MySQL private access sits in the Azure Database for MySQL private networking layer. Azure represents it through virtual network integration, private DNS, subnet delegation, server networking mode, connection strings, and firewall behavior. It commonly depends on VNet design, subnet capacity, DNS configuration, application placement, route tables, identity, TLS, and operations access paths. The important boundary is that private access controls network path, while database users, TLS, and application authorization still control data access. Compare portal, CLI, template, metric, log, and ticket evidence before troubleshooting or changing production settings.

Exam context

Compare with

MySQL public access Private Link Private endpoint for Storage

Where it is used

Where you see it

  1. In the Azure portal, you see MySQL private access on resource, configuration, networking, monitoring, or security pages where teams review current state before approving production changes.
  2. In CLI, ARM, Bicep, Terraform, SDK, or API output, it appears as names, properties, associations, modes, values, IDs, or operation results that can be captured as evidence.
  3. In architecture and incident reviews, it appears when teams explain ownership, dependency impact, safe rollback, monitoring signals, cost tradeoffs, and the boundary between configuration and runtime behavior.

Common situations

  • Design or review MySQL private access for a production Azure workload.
  • Troubleshoot access, reliability, performance, or configuration problems with repeatable evidence.
  • Prepare a safe change by confirming scope, owner, dependencies, rollback path, and monitoring signals.
  • Explain the operational impact to developers, operators, architects, auditors, and FinOps reviewers.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Private commerce database Scenario, objectives, solution, measured impact, and takeaway.
Scenario

UrbanTrail Retail wanted its checkout database unreachable from the public internet after a security review.

Goals
  • Remove public database exposure.
  • Keep application connectivity stable.
  • Use private DNS for predictable resolution.
  • Document network evidence for auditors.
Approach using MySQL private access

The architecture team used MySQL private access as the named control. They deployed the MySQL server with private access in a delegated subnet and linked the private DNS zone to the application VNet. Network engineers validated peering, NSG rules, and application connection strings before switching production traffic. Operators captured CLI and portal evidence, compared metrics, logs, activity records, and user-facing behavior afterward, and saved approval, rollback, owner, and validation notes. The runbook listed known limits, exception rules, and rollback signals so support could verify the decision during incidents. They also rehearsed the operator workflow with a second reviewer, recorded validation timing, expected user impact, support coverage, test queries, and the business signal that would prove success. The final handoff compared baseline metrics with post-change evidence, named the follow-up owner, and added cleanup criteria so configuration drift would not quietly return.

Potential outcomes
  • Public exposure findings were closed.
  • Checkout connectivity succeeded from approved subnets only.
  • DNS troubleshooting time dropped 45%.
  • Audit evidence included subnet, DNS, and CLI output.
What to learn

Private access reduces database exposure when DNS, subnet delegation, and application placement are designed together.

Scenario 02 Hybrid reporting path Scenario, objectives, solution, measured impact, and takeaway.
Scenario

CedarWorks Manufacturing needed on-premises reporting tools to reach Azure MySQL without opening public firewall ranges.

Goals
  • Connect through ExpressRoute.
  • Keep server access private.
  • Resolve MySQL FQDN from on-premises.
  • Avoid changing application database credentials.
Approach using MySQL private access

The architecture team used MySQL private access as the named control. They used MySQL private access with VNet integration, Private DNS forwarding, and ExpressRoute routing. Operators tested DNS from on-premises clients, confirmed port 3306 reachability, and documented the network path before reporting jobs moved to Azure. Operators captured CLI and portal evidence, compared metrics, logs, activity records, and user-facing behavior afterward, and saved approval, rollback, owner, and validation notes. The runbook listed known limits, exception rules, and rollback signals so support could verify the decision during incidents. They also rehearsed the operator workflow with a second reviewer, recorded validation timing, expected user impact, support coverage, test queries, and the business signal that would prove success. The final handoff compared baseline metrics with post-change evidence, named the follow-up owner, and added cleanup criteria so configuration drift would not quietly return.

Potential outcomes
  • Public firewall rules were not required.
  • Reporting latency improved 22%.
  • No credential rotation was needed for cutover.
  • Network evidence was reusable for later database migrations.
What to learn

Private access is especially useful for hybrid workloads when name resolution and routing are treated as first-class dependencies.

Scenario 03 Regulated data isolation Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Medora Research hosted clinical study metadata and needed tighter Azure network boundaries for MySQL.

Goals
  • Restrict database traffic to approved VNets.
  • Separate research and admin access paths.
  • Capture evidence for compliance.
  • Preserve operator troubleshooting access.
Approach using MySQL private access

The architecture team used MySQL private access as the named control. They placed the MySQL server in a delegated subnet with private access and linked only approved VNets to the private DNS zone. Bastion and jump-host procedures gave operators a controlled troubleshooting path without public access. Operators captured CLI and portal evidence, compared metrics, logs, activity records, and user-facing behavior afterward, and saved approval, rollback, owner, and validation notes. The runbook listed known limits, exception rules, and rollback signals so support could verify the decision during incidents. They also rehearsed the operator workflow with a second reviewer, recorded validation timing, expected user impact, support coverage, test queries, and the business signal that would prove success. The final handoff compared baseline metrics with post-change evidence, named the follow-up owner, and added cleanup criteria so configuration drift would not quietly return.

Potential outcomes
  • Compliance reviewers accepted the network isolation control.
  • Unapproved VNet tests failed as expected.
  • Operators retained a documented access path.
  • Security exceptions decreased by 58%.
What to learn

Private access helps regulated workloads prove who can reach the database before identity checks even begin.

Azure CLI

Azure CLI is useful for MySQL private access because CLI commands can show server network settings and support private connectivity checks before changes are approved. It also captures exact resource IDs, timestamps, settings, and queryable output for tickets, audits, and automation, which is safer than relying on portal screenshots alone.

Useful for

  • Inventory the affected resource and export current configuration for a change record.
  • Compare live settings with approved architecture, policy, or source-controlled deployment files.
  • Collect evidence during incidents, audits, migrations, scale reviews, or cleanup work.

Before you run a command

  • Confirm the tenant, subscription, resource group, resource name, and whether the command is read-only or mutating.
  • Check that your identity has the least-privilege role needed to inspect or change the setting.
  • Know the production impact, maintenance window, rollback path, and preferred output format before making changes.

What the output tells you

  • Resource IDs and names prove the exact scope, which prevents confusing similarly named resources.
  • Configuration values show whether live state matches the approved design or expected baseline.
  • Provisioning state, timestamps, metrics, and related IDs help separate configuration problems from runtime symptoms.

Mapped commands

MySQL private access operations

direct 
az mysql flexible-server show --name <server-name> --resource-group <resource-group>
az mysql flexible-serverdiscoverDatabases
read-only Microsoft Learn 
az mysql flexible-server create --name <server-name> --resource-group <resource-group> --vnet <vnet-name> --subnet <subnet-name> --private-dns-zone <zone-resource-id>
az mysql flexible-serverprovisionDatabases
cost-impacting Microsoft Learn 
az network private-dns zone show --name <zone-name> --resource-group <resource-group>
az network private-dns zonediscoverDatabases
read-only Microsoft Learn 
az network vnet peering list --resource-group <resource-group> --vnet-name <vnet-name>
az network vnet peeringdiscoverDatabases
read-only Microsoft Learn

Architecture context

MySQL private access places Azure Database for MySQL Flexible Server behind a private network path so applications connect through a virtual network rather than exposing a public endpoint. In architecture terms, it is part of the network and identity boundary for database workloads. The design must cover subnet placement, private DNS, peering, firewall posture, jump-host or Bastion access, CI/CD connectivity, and monitoring reachability. Private access improves exposure control, but it can break deployments if pipelines, admin workstations, or dependent services cannot resolve or route to the server. Architects should plan it with application hosting, data migration, backup validation, and incident response in mind. The goal is a database reachable by approved workloads, not a server that is private but operationally unreachable.

Security
From a security angle, MySQL private access should be reviewed for VNet scope, private DNS records, subnet permissions, administrator access, diagnostic logs, TLS, and whether public access remains disabled. The main risk is that misconfigured DNS or broad network permissions can undermine the private-access design. Least privilege still applies because Azure separates who can read settings, who can change resources, who can connect at runtime, and who can view diagnostic data. Operators should verify RBAC scope, network controls, TLS or encryption, secret handling, logging, and policy coverage. Good evidence includes role assignments, approved access paths, activity logs, diagnostic settings, change approval, and an agreed rollback plan.
Cost
Cost impact for MySQL private access comes from network design effort, private connectivity support, troubleshooting time, duplicate test environments, and costs avoided by reducing exposure incidents. Some costs are direct resource charges; others appear as support time, failed changes, over-retention, under-sizing incidents, or duplicate environments. FinOps review should identify the owner, environment, tags, usage metric, and business workload that consumes the setting. Do not reduce cost by weakening security or recovery without documenting the tradeoff. The best choice is the smallest safe configuration that meets reliability, compliance, and performance needs. For shared services, keep chargeback notes so usage changes can be explained without guessing.
Reliability
Reliability for MySQL private access depends on DNS health, subnet availability, application routing, private connectivity tests, backup and maintenance behavior, and documented break-glass access. A weak design can block applications or administrators during an incident because the private path was not tested. Teams should document blast radius, dependency health, backup or failover behavior, and the signals that prove the system is healthy. For production, evidence should include current configuration, metrics, logs, alert rules, tested recovery steps, and an owner who can approve changes. Managed services reduce toil, but they do not remove the need to rehearse failure paths and verify customer impact. Test the path before a real incident.
Performance
Performance for MySQL private access is shaped by network latency, DNS resolution, route path, application placement, connection pooling, and whether private routing adds acceptable overhead. The effect may be direct, such as latency, throughput, connection handling, or query duration, or indirect, such as slower troubleshooting or blocked traffic. Operators should measure before changing settings and separate capacity, network, identity, storage, and application causes. Useful signals include metrics, logs, dependency health, error rates, retry volume, and baseline comparisons. Tune one variable at a time and record whether the measurable workload signal improved. Keep the baseline and result together so decisions stay tied to evidence.
Operations
Operationally, MySQL private access needs a repeatable inspection path covering private DNS review, subnet checks, connection tests, route validation, application configuration, monitoring, and evidence that public access is not required. Runbooks should say who owns it, which command or portal blade proves current state, which changes are read-only or mutating, and what evidence belongs in a change record. Avoid undocumented portal-only edits for production. Use CLI output, metrics, logs, tags, templates, and ticket notes so support teams can compare intended and actual state during incidents. During incidents, the runbook should also state safe read-only checks, escalation owner, and closure criteria.

Common mistakes

  • Treating MySQL private access as a generic label instead of checking the live Azure resource state.
  • Changing production settings without owner approval, rollback notes, or monitoring evidence.
  • Assuming portal wording, inherited policy, or old screenshots prove the current configuration.