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.
SQL MI public endpoint, Azure SQL MI public data endpoint, managed instance public data endpoint
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-25
Microsoft Learn
Microsoft Learn explains that Azure SQL Managed Instance can provide user connectivity through a public endpoint, but the configuration must be secured with network controls, port 3342 access rules, strong authentication, and careful operational review before production use. Always. Carefully. under explicit governance.
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.
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.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
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.
Signal 02
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.
Signal 03
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.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
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.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Acquisition migration uses a time-boxed endpoint
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A software company acquired a smaller SaaS vendor whose integration server could not reach Azure private networks before the migration deadline. The team needed short-term SQL Managed Instance access without normalizing a public path.
🎯Business/Technical Objectives
Enable temporary connectivity for the acquired integration server.
Restrict access to approved source addresses and named database identities.
Capture evidence proving the endpoint was disabled after migration.
Avoid changing the long-term private network design.
✅Solution Using SQL Managed Instance public endpoint
Architects enabled the SQL Managed Instance public endpoint only after the security team approved the source egress addresses, NSG rule, and expiry date. Azure CLI toggled publicDataEndpointEnabled and exported the before-and-after state to the migration record. Database administrators created limited SQL users for the integration workload and monitored failed logins throughout the cutover. The public path was used for three data synchronization runs while a private endpoint design was completed. After validation, engineers disabled the public endpoint with CLI, removed the NSG rule, and confirmed the application used the new private path.
📈Results & Business Impact
The acquired system completed migration four weeks before the network consolidation project finished.
No broad source ranges were allowed; access stayed limited to two approved egress addresses.
The public endpoint was disabled 48 hours after final validation, meeting the audit deadline.
Migration support tickets stayed under the expected threshold despite the temporary exception.
💡Key Takeaway for Glossary Readers
A public endpoint can be a safe temporary bridge only when ownership, source restriction, monitoring, and retirement are designed up front.
Case study 02
Energy trader eliminates unmanaged exposure
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An energy trading desk discovered that a managed instance public endpoint had remained enabled after a vendor support engagement. No one could prove whether it was still needed.
🎯Business/Technical Objectives
Find all managed instances with public endpoint exposure.
Identify real owners and application dependencies before disabling access.
Remove unnecessary public paths without disrupting settlement systems.
Create a repeatable monthly governance check.
✅Solution Using SQL Managed Instance public endpoint
Cloud security engineers ran Azure CLI inventory across subscriptions and filtered instances where publicDataEndpointEnabled was true. For each match, they pulled tags, activity logs, failed login telemetry, and NSG rules. The trading instance had no successful vendor connections for ninety days, but one old service account still had database access. The team disabled the public endpoint in a controlled window, removed the associated NSG rule, disabled the stale account, and watched settlement jobs for two cycles. The same CLI query became a monthly governance control with exceptions reviewed by data platform leadership.
📈Results & Business Impact
Seven public endpoint exceptions were reduced to two approved time-boxed cases.
The trading instance exposure window closed without any missed settlement batch.
Failed public login noise dropped by 92 percent after stale paths were removed.
Monthly review time fell from manual portal checks to a 15-minute scripted report.
💡Key Takeaway for Glossary Readers
Public endpoint inventory is one of the fastest ways to find SQL Managed Instance exposure that no longer has a business owner.
Case study 03
Field service vendor gets controlled emergency access
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A field service platform lost private routing during a network redesign, blocking a vendor from applying an urgent billing fix. The business needed access restored for one evening only.
🎯Business/Technical Objectives
Restore vendor connectivity without delaying the billing fix.
Limit exposure to the vendor jump network and audited database account.
Disable the endpoint immediately after validation.
Preserve evidence for the post-incident review.
✅Solution Using SQL Managed Instance public endpoint
The incident commander approved a temporary SQL Managed Instance public endpoint under an emergency change. Network engineers added a narrow NSG rule for the vendor jump network, and database administrators confirmed the vendor account had only the required stored procedure permissions. Azure CLI enabled the endpoint, captured the managed instance state, and recorded the activity log correlation. The vendor performed the fix, application owners validated invoice generation, and the endpoint was disabled before the incident bridge closed. A follow-up action repaired the private route and added a policy alert for future public endpoint enablement.
📈Results & Business Impact
Billing correction finished the same night instead of slipping to the next weekly run.
Public access was enabled for 94 minutes and limited to one approved source range.
No unexpected login attempts succeeded during the emergency window.
The post-incident review had exact command output, timestamps, and rollback evidence.
💡Key Takeaway for Glossary Readers
Emergency public endpoint use is defensible only when it is narrow, observable, and removed before the exception becomes normal.
Why use Azure CLI for this?
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.
CLI use cases
Show one managed instance and return only the public endpoint enabled flag for a security review.
List all managed instances in a resource group and identify which ones still expose a public endpoint.
Enable the public endpoint for an approved temporary integration after NSG and authentication controls are ready.
Disable the public endpoint during cleanup or incident response and capture command output for the security record.
List or update NSG rules that allow public endpoint traffic so access is limited to approved source ranges.
Before you run CLI
Confirm the tenant, subscription, resource group, instance name, business owner, and approved reason for enabling public connectivity.
Verify Microsoft.Sql update permission and network permission to review or change NSG rules associated with the managed instance subnet.
Check source IP ranges, authentication method, monitoring, expiry date, and whether private connectivity is a better long-term solution.
Use read-only inventory first; avoid enabling public access during broad automation unless every target has an approved change record.
Before disabling, inspect logs, application owners, connection strings, and support tickets so hidden dependencies do not fail unexpectedly.
What output tells you
The publicDataEndpointEnabled value tells whether the managed instance currently accepts user connectivity through its public endpoint path.
Resource ID, tags, region, and state identify the exposed instance and help route review to the correct workload owner.
NSG rule output shows whether source ranges and destination ports are narrowly scoped or dangerously broad.
Activity log entries show who changed the endpoint state and whether the change was tied to an approved maintenance window.
Failed login and connection telemetry show whether the endpoint is attracting unexpected traffic after it is enabled.
Mapped Azure CLI commands
SQL Managed Instance public endpoint CLI operations
direct
az sql mi show --resource-group <resource-group> --name <managed-instance> --query "{name:name,publicEndpoint:publicDataEndpointEnabled,state:state}"
az sql midiscoverDatabases
az sql mi list --resource-group <resource-group> --query "[].{name:name,publicEndpoint:publicDataEndpointEnabled,region:location}" --output table
az sql midiscoverDatabases
az sql mi update --resource-group <resource-group> --name <managed-instance> --public-data-endpoint-enabled true
az sql misecureDatabases
az sql mi update --resource-group <resource-group> --name <managed-instance> --public-data-endpoint-enabled false
az sql miconfigureDatabases
az network nsg rule list --resource-group <resource-group> --nsg-name <nsg-name> --output table
az network nsg rulediscoverNetworking
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.