Hi there. In this video, we're going to take our discussions of service endpoints a step further by talking about service endpoint policies, but first, we need to understand what are they?

And how can they be leveraged within the scope of your virtual network? The first thing to understand is that a service endpoint policy is a way for you to filter the egress traffic that leaves your virtual network and travels to a Azure storage account that's been configured via a service endpoint. Now, this means that you're going to be providing allow and deny traffic rules to specific storage accounts, and there are different mechanisms for defining what those storage accounts are, you don't have to necessarily just pick and choose individual ones. Network security groups can limit traffic but only to specific regions. Whereas in a service endpoint, you're going to be able to filter your traffic to anywhere that's in a resource group, that's in the subscription, and in some cases even across multiple tenants. It replaces the need for network virtual appliances to filter your traffic, but only filtering the traffic on a specific allow or deny definition.

If you need more tight filtering or packet management or things along those lines, then the NVAs may still be required. One thing to be aware of here, there is no centralized logging currently for the use of endpoint policies, meaning that you're not going to be able to go back and validate that traffic did not flow to storage account A but did flow to storage account B. Now, here is what a JSON example would look like for a service endpoint policy definition. You're going to give it a name, you're going to specify a resource group where the policy is going to be deployed, and then of course you're going to specify the service. Right now, Microsoft. Storage is the only service that is available for endpoint policies. And then you're going to define a specific service that is allowed. In this case, we have chosen a specific storage account called mystgacc. And I limited the string here by putting in three dots so that you don't necessarily need to see the full subscription id, the resource group name, things along those lines, that is what gets filled into that little three-dot section. And then, of course, we need to define the resource provider that this JSON is being created for.

Now, this is just a JSON example. In the next video, we will be doing a demonstration of how to create an endpoint policy inside of the Azure portal so that you can see that as well. But this is what you would be using if you were using the Azure CLI or Azure Power Shell. Now, some configuration considerations to keep in mind. The endpoint policies are applied on the subnet where the service endpoint is configured and you should have seen that in the previous video when we did the demonstration of how to configure service endpoints, but we'll do it again in the next video. You are allowed to add specific storage accounts to an allow list. Now as I mentioned, there are a number of different ways that those can be defined. They can be all storage accounts in the specific subscription, all storage accounts in a specific resource group, or you can pick and choose individual storage accounts, and again I'll show this to you in the next video. By default, no policies are configured on a subnet, which means that all storage accounts are available by default.

It isn't until you apply a policy that you start to limit everything that has not been specified in that policy. Multiple policies can be applied to each subnet, you are not limited to just one. If a storage account is allowed within a policy, then one thing to be aware of is if that storage account has been configured to be read-only geographic redundancy, then the secondary account will also be allowed for access. So, as an example, read access geographic redundant. If your storage account is RA-GRS and you have applied it in East US, then of course the read accessible secondary is going to be in West US. Standard regional pairings that Azure's had in place for a decade now. If you allow that storage account to be accessible via the policy, then the west region secondary will be accessible as well.

And then lastly, storage accounts specified within the policy can be in different subscriptions or different tenants as long as you the user have access to those storage accounts to be able to see them from a configuration perspective. If you can't see them, then you can't define them, at least from an  Azure portal perspective. Now, obviously, if you can write a JSON that defines those storage accounts that are in a different subscription or a different tenant, then that will work as well. In the next video, we'll take a look at how to demo or demonstrate the configuration of both the endpoint policy creation as well as applying it to a individual subnet.