Share via

How can deny storage account creation if a Private Endpoint is not created at the same time

Srinath Sarman 0 Reputation points
2026-05-29T01:51:14.0733333+00:00

Hello,

Looking for a solution to create Azure policy to deny storage account creation if a Private Endpoint is not created at the same time.

Thanks,

Srinath.

Azure Policy
Azure Policy

An Azure service that is used to implement corporate governance and standards at scale for Azure resources.

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Bharath Y P 9,215 Reputation points Microsoft External Staff Moderator
    2026-05-29T16:05:08.35+00:00

    Hello Srinath, you can absolutely lock down storage account creation so that it’s denied unless a Private Endpoint is also deployed. The easiest way is to leverage Azure Policy. Below is a sample “deny” policy definition that checks for the existence of at least one private endpoint connection on a storage account and blocks the creation if none is found.

    — Sample Azure Policy Definition —

    
{

  "properties": {

    "displayName": "Deny storage account without Private Endpoint",

    "policyType": "Custom",

    "mode": "Indexed",

    "description": "This policy denies creation of Storage Accounts unless they have an associated Private Endpoint connection.",

    "parameters": {},

    "policyRule": {

      "if": {

        "allOf": [

          {

            "field": "type",

            "equals": "Microsoft.Storage/storageAccounts"

          },

          {

            "count": {

              "field": "Microsoft.Storage/storageAccounts/privateEndpointConnections[*]",

              "where": {

                "field": "Microsoft.Storage/storageAccounts/privateEndpointConnections[*].privateEndpoint.id",

                "notEquals": ""

              }

            },

            "equals": 0

          }

        ]

      },

      "then": {

        "effect": "deny"

      }

    }

  }

}

    Steps to use it:

    1. Go to Azure Portal → Policy → “Definitions” → “+ Policy definition”.
    2. Paste the JSON above.
    3. Save, then Assign it to the desired scope (subscription or resource group) so that any new storage account creation will be blocked unless a Private Endpoint is declared in that same template or request.

    If you’d rather have Azure automatically inject or deploy the Private Endpoint when someone creates the storage account, you can swap out "effect": "deny" for a "deployIfNotExists" effect—using an ARM template in the policy’s deployment block to spin up the Private Endpoint in a specified VNet/Subnet.

    Reference list these docs dive into private endpoint setup, troubleshooting, and Azure Policy:

    1. Create Storage Private Endpoints https://docs.microsoft.com/azure/private-link/create-private-endpoint-storage-portal
    2. Azure Policy overview https://learn.microsoft.com/azure/governance/policy/overview
    3. Troubleshoot Private Endpoint creation issues https://docs.microsoft.com/azure/private-link/private-endpoint-overview
    4. DNS changes for Private Endpoints https://docs.microsoft.com/azure/storage/common/storage-private-endpoints#dns-changes-for-private-endpoints

    Hope this helps. If the information was useful, please consider accepting the answer and upvoting. Feel free to reach out if you need any further assistance. Thank you.

    Was this answer helpful?

  2. Jose Benjamin Solis Nolasco 8,076 Reputation points Volunteer Moderator
    2026-05-29T03:44:10.6833333+00:00

    Welcome to Microsoft Q&A

    Hello Srinath Sarman,

    Azure Policy checks resources one by one as they are being built. To build a Private Endpoint, you have to tell it which Storage Account to attach to. That means the Storage Account must be built first. Azure Policy can't block the Storage Account for missing a Private Endpoint that hasn't been allowed to be built yet

    Instead of trying to force them to be built at the same time, you should use these two standard workarounds:

    Block the Internet: Create a policy that Denies the creation of a Storage Account unless "Public Network Access" is disabled. If the creator can't use the public internet to reach their new storage, they will be forced to build a Private Endpoint anyway!

    Audit Missing Endpoints: Use an AuditIfNotExists Azure Policy. This lets the Storage Account be built, but if the user doesn't attach a Private Endpoint within a few minutes, Azure flags the storage account in red as "Non-Compliant" so your security team can see it.

    😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-05-29T01:51:24.78+00:00

    This scenario can’t be enforced in a single atomic Azure Policy evaluation because:

    • Azure Policy evaluates one resource at a time (the storage account or the private endpoint), based on that resource’s properties.
    • A private endpoint is a separate resource (Microsoft.Network/privateEndpoints) created after or alongside the storage account, often in a different template or deployment.
    • Policy for Microsoft.Storage/storageAccounts has no built‑in way to require “there must also be a private endpoint resource created in the same deployment.”

    What can be done instead is to enforce the desired end state with policies that:

    1. Deny storage accounts that allow public or anonymous access, forcing use of private endpoints or other restricted network paths.
    2. Deny storage accounts that don’t meet specific security/networking requirements.

    Examples from the context:

    • A deny policy on allowBlobPublicAccess prevents creation or modification of storage accounts that allow anonymous blob access: 
        {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "not": {
            "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
            "equals": "false"
          }
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
      This pattern can be reused for other storage properties (for example, default network access rules) to effectively require private‑only access.
    • The CIS “Storage account public access should be disallowed” built‑in policy similarly enforces that storage accounts cannot be publicly accessible.

    To approximate “deny storage account creation if a private endpoint is not created at the same time,” combine:

    1. A custom or built‑in policy that:
      • Denies public network access or anonymous access for storage accounts.
      • Optionally enforces default network rule = deny.
    2. A deployment pattern (ARM/Bicep/Terraform) that always creates:
      • The storage account.
      • One or more Microsoft.Network/privateEndpoints pointing to that account.

    With this combination:

    • Any attempt to create a storage account that is usable without a private endpoint (for example, with public access) is denied by policy.
    • The only viable way to use the storage account is via private endpoints, which are created by the deployment template.

    However, Azure Policy alone cannot express a hard dependency like “deny the storage account unless a private endpoint resource exists in the same deployment.” That dependency must be enforced by deployment tooling and design, while policy enforces the secure configuration of the storage account itself.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.