Hi everyone and welcome back. In this brief demonstration, I'm going to show you how to create a storage account using the Azure portal. Now, every storage account needs to belong to a resource group. Now a resource group, as you may know is a logical container that groups all of your Azure resources.

Now when we create our storage account here, we're going to have two options, we can create a storage account and then as part of that process, we can create the new resource group or we can select an existing resource group. What we're going to do here is add this new storage account to an existing resource group.

So on the screen here, I'm logged into my Azure portal and I'm at the home page. To create our general purpose V2 storage account, what we'll do here is go up to the hamburger here and select all services. And then from here, we can search for storage accounts. And we'll select it from the results page here. And we can see in my existing subscription here, I already have a storage account called VMLab diag 601.

What we're going to do here is create a new one by clicking Add. And then from here, we need to provide some basic information, we need to specify the subscription that's going to host the storage accounts. We need to select the resource group we want to deploy the storage account into or we can create a new one here. And then of course, we need to give our storage account a name, tell Azure which locations going into and then the performance of the storage account.

We can see that standard storage accounts are backed by magnetic drives and they are the cheapest cost per gigabyte. We can see in this popup, that standard storage accounts are good for applications that need bulk storage or where you're accessing the data within that storage account infrequently. The premium storage accounts are backed by solid state drives. You use these when you need a consistent low latency performance.

Now you will notice here that a premium performance storage account can only be used with Azure virtual machine disks and they are best for IO intensive applications like databases. Another important item to note here is that virtual machines that use premium storage for all of their discs, do qualify for a 99.9% SLA even if they're not running within an availability set so that's pretty important to remember.

For this exercise, we'll just use a standard storage account here and then the account kind here is where we can select what type of storage account to deploy. Here, we have three options storage V2, storage which is basically the legacy general purpose V1 and Blob storage.

Now in the replication dropdown, we can specify the redundancy that we need for our storage whether it be locally-redundant, zone-redundant, geo-redundant, read-access geo-redundant, geo zone-redundant or read access geo zone-redundant. Instead of going through each of these individually, you can visit the URL that you see on your screen for more information about each of these types of redundancy options. And lastly, we have the access tier here.

Now the hot access tier is really used for data that's accessed frequently. The cool access tier is typically used for infrequently access data. We can also see that there is a another option and it's the archive access tier but that can only be set at the Blob level and not on the actual storage account level.

So let's go ahead and see here. We'll deploy our storage accounts and we only have one subscription here, our labs subscription. So we'll leave that set and then we have a couple of different resource groups here. So I'll just deploy this into my VMLab resource group. And then we need to give our storage account a name and this name must be unique across all storage accounts in Azure, it needs to be unique across the landscape. The name can be as short as three characters but as long as 24 and it can only contain lowercase letters and numbers. So let's call this test9878storage.

We get the green checkbox which means we're good and we'll deploy into the Central US region, that's all we really need for this demonstration. And we're going to deploy a general purpose V2 and we'll accept the default read-access geo-redundant storage. We'll do the same thing for the access tier.

Now, when we click Next for Networking, we can specify our network connectivity requirements, including the connectivity method and any kind of network routing or routing preferences. Now we can see here we have three options, we have a public endpoint for all networks, public end point for selected and private end points.

Essentially, storage accounts have a public endpoint that's accessible through the internet. That's what this public endpoint would be. Now, if we select public endpoint, what we do is we're enabling that public endpoint to all networks, that's why we have all networks here. If we select the second option here, we can see we then allow a public endpoint but then we can select which networks can access this storage account. 

So that allows us to segment our traffic and block certain traffic. And then we have private endpoint. Now you would create a private end point to allow only private connections to this storage accounts. Now, what this would do is assign a private IP address from the virtual network that we select and it would take it and assign it to these storage accounts. And then as a result, all traffic between that virtual network and the storage account would be secured over a private link.

For this exercise here, we're just going to go public and the only option we have here for routing is Microsoft network routing defaults and that's because the combination of the storage account kind performance and replication along with location does not support internet routing which we probably wouldn't do anyway.

We'll go into data protection and then we can see, we have the Blob soft delete option, we have the file share soft delete option here and then we have versioning but versioning is not offered for this storage account due to the type of storage account combined with the subscription replication and location options.

So we'll leave these at their defaults. We'll click Next through to advanced. Now here's where we could configure some advanced features. We could configure the secure transfer which essentially enhances the security of the storage account by only allowing the requests to that storage account by secure connections.

When you enable the Blob public access, the storage accounts Blobs can be read publicly without needing to share an account key or even a shared access signature. So your Blobs are wide open. We have the TLS versioning. Now this large file shares option here, turning this on provides file share support for a maximum of a hundred terabytes.

Now you'll notice here that large file share storage accounts don't have the ability to convert to geo-redundant storage offerings. And down here, we have some Data Lake Storage Gen2 options. We'll leave these other defaults, we'll click next for tags, we're not going to do any tagging here. This just allows us to categorize our resources and then we'll go ahead and click Next to Review and Create. And at this point we can see our validation has passed, we can review our configuration and then we can go ahead and click Create. And what this will do is deploy our general V2 storage account. And we can go ahead and click, Go to Resource and we are now in our test9878 storage account.

So that is how you walk through the process of creating a storage account in the Microsoft Azure portal.