SQL Managed Instance public endpoint

Understand the concept

In plain English

A SQL Managed Instance public endpoint lets clients connect to the managed instance over a public connectivity path instead of only through private virtual network routes. It can be useful when private networking is not ready, when a trusted external system must connect temporarily, or when migration teams need a controlled bridge. It is also risky if treated casually. Enabling it is only part of the job; operators must manage network security rules, authentication, monitoring, and a plan to disable the endpoint when the need disappears.

Why it matters

The public endpoint matters because it can solve urgent connectivity problems and create serious exposure at the same time. During migrations, acquisitions, partner integrations, or temporary support scenarios, it may be the fastest way to reach SQL Managed Instance when private connectivity is not yet complete. But the database remains a high-value target, and a public path demands stricter controls than a private-only design. The operational impact is also broad. If the endpoint is enabled without clear ownership, security teams may find unexpected exposure months later. If it is disabled without dependency checks, legacy applications may fail immediately. Ownership matters. That boundary must stay visible to owners.

Technical context

The public endpoint is an instance-level connectivity setting on Azure SQL Managed Instance. When enabled, clients use the managed instance public endpoint name and the documented public endpoint port, while network security groups and allowed paths must permit the traffic. It sits beside private endpoint, VNet-local connectivity, proxy behavior, firewall-style controls, and SQL authentication or Microsoft Entra access decisions. It is not a database-level setting. One change can affect every database hosted on the managed instance and every application that discovers the endpoint.

Exam context

Compare with

Where it is used

Where you see it

1. In the Azure portal, the managed instance Networking settings show whether the public data endpoint is enabled and where related network guidance appears. for review. too and exception status.
2. In Azure CLI output, az sql mi show can return publicDataEndpointEnabled so security teams can inventory exposed managed instances quickly. across subscriptions during audits. repeatedly. before operators change NSG rules. clearly.
3. In network security group rules, allowed inbound traffic for the public endpoint path appears as explicit port and source restrictions tied to access approvals. clearly. during reviews.

Common situations

• Provide temporary connectivity for a migration tool or legacy system while the permanent private networking path is still being built.
• Support a tightly controlled partner integration where private connectivity is not feasible but source ranges, identities, and logging are approved.
• Run emergency diagnostics from a trusted administrative network when private routes are impaired and the endpoint can be disabled afterward.
• Inventory and eliminate public exposure by finding every managed instance with the public endpoint enabled across subscriptions.
• Replace broad public endpoint dependency with private endpoints or peering by first identifying real traffic and affected application owners.

Illustrative Azure scenarios

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

Azure CLI

With ten years of Azure engineering behind me, I prefer Azure CLI for public endpoint work because the setting must be proved, not guessed. CLI shows whether publicDataEndpointEnabled is true, lets me disable it quickly, and supports scripts that compare endpoint posture across every managed instance. I also use CLI to inspect the network security group rule that allows port 3342. For audits, command output is stronger than screenshots because it can be timestamped, filtered, exported, and tied to a remediation pipeline or change ticket. That repeatability prevents forgotten exposure after migration windows or vendor tests end, especially when exception owners change.

az sql mi show --resource-group <resource-group> --name <managed-instance> --query "{name:name,publicEndpoint:publicDataEndpointEnabled,state:state}"

az sql mi list --resource-group <resource-group> --query "[].{name:name,publicEndpoint:publicDataEndpointEnabled,region:location}" --output table

az sql mi update --resource-group <resource-group> --name <managed-instance> --public-data-endpoint-enabled true

az sql mi update --resource-group <resource-group> --name <managed-instance> --public-data-endpoint-enabled false

az network nsg rule list --resource-group <resource-group> --nsg-name <nsg-name> --output table

Architecture context

Architecturally, I view the public endpoint as an exception path, not the default SQL Managed Instance connectivity model. The preferred pattern is usually private connectivity through the managed instance VNet, private endpoints, peering, or controlled hub routing. A public endpoint may still be justified for temporary migration traffic, tightly governed partner access, or environments where private routing is blocked by organizational boundaries. The architecture must define who can enable it, what NSG rules allow it, which identities can authenticate, how traffic is monitored, and when the endpoint must be disabled or replaced by a private design. Exceptions need expiry dates. Expiry dates and owner tags should be mandatory.

Security

Security impact is direct and significant because the public endpoint creates an internet-reachable path to SQL Managed Instance. Enabling it should require change approval, least-privilege database access, strong authentication, encryption, auditing, Defender or threat detection review, and restrictive NSG rules. Broad source ranges, permanent exceptions, shared SQL logins, or unmonitored access attempts create real attack surface. The endpoint itself does not grant database permissions, but it gives attackers a reachable doorway to test credentials and vulnerabilities. Security teams should verify that only approved source addresses can reach the port and that the endpoint is disabled when the exception ends. Always. Review every exception.

Cost

The public endpoint does not normally create a separate database SKU charge. Its cost impact comes from risk, support, and network operations. Temporary public access can avoid expensive emergency network projects during a migration, but keeping it enabled indefinitely may increase audit findings, monitoring effort, and security response cost. Broad rules or unmanaged dependencies also raise incident cost because teams must investigate whether suspicious login activity is noise or a real threat. FinOps and governance owners should track public endpoint exceptions just like other exposed resources, with an expected retirement date and owner accountability. Those reviews turn exposure into accountable spend. Exception governance has a real support cost.

Reliability

Reliability depends on using the public endpoint deliberately. It can provide a practical connection path when private networking is unavailable, but it also adds dependency on public endpoint DNS, NSG rules, client egress, and proxy behavior. If a team enables it as a temporary migration bridge, they should test retry logic, connection strings, and monitoring before production use. If a team disables it later, they must confirm no application still depends on that path. Reliability failures often come from untracked dependencies, not from the endpoint itself: one undocumented integration can turn a cleanup task into an outage. Track dependencies carefully. Test from the approved source network.

Performance

Performance depends on the client path. Public endpoint traffic may be affected by internet routing, partner egress, packet inspection, source-region distance, and retries. It does not improve query execution inside SQL Managed Instance, and it should not hide CPU, log IO, or blocking problems. For temporary migration or reporting, operators should measure connection latency, failed logins, throughput, and query duration from the actual source network. If results are inconsistent, a private path may be more predictable. The public endpoint is a connectivity option, not a database tuning feature. Measure connection setup, packet path, and query runtime separately before blaming SQL. Testing from approved external sources keeps network delay separate from database pressure. Test from real client networks before approving long-lived exceptions or migration cutovers.

Operations

Operationally, the public endpoint is inspected during security reviews, access troubleshooting, migrations, and emergency support scenarios. Operators check publicDataEndpointEnabled, confirm the relevant network security group rule, validate source IP restrictions, and review Activity Log entries for who enabled or disabled it. Changes should be made from a runbook because the instance setting and network rule must agree. Good practice includes tagging the exception owner, setting an expiry review, testing from an approved client, and closing the rule when the endpoint is disabled. Monthly control reviews should reconcile endpoint state, source ranges, owner tags, and rollback steps before exceptions linger unnecessarily.

Common mistakes

• Enabling the public endpoint for migration and forgetting to disable it after private connectivity is delivered.
• Allowing broad source ranges in NSG rules because the team cannot identify the real client egress addresses.
• Assuming SQL permissions alone are enough and ignoring failed login monitoring, weak accounts, or stale SQL users.
• Disabling the endpoint during cleanup without checking whether a partner, job, or legacy application still uses it.
• Confusing public endpoint access with Azure SQL Database firewall rules and missing the managed instance NSG requirements.