Recently, I worked on a project where the goal was to prototype different storage scenarios and train new personnel in Azure. The data wasn’t critical, so there was no need for backups or complex recovery options if it got overwritten or removed. My task was to set up a simple and flexible storage configuration that could be easily adjusted. Here's a quick rundown of what I did and the steps I followed.
Step 1: Creating a Resource Group
To start, I needed a resource group to keep everything organized:
- I went to the Azure portal and searched for Resource groups.
- Then, I clicked on + Create to start the process.
- I gave my resource group a name, something simple like theprotonguy, to easily identify it.
- After selecting a region (which I planned to use consistently throughout the project), I hit Review and create.
- Finally, I clicked Create to deploy the resource group. This step ensures all my project resources stay neatly contained.
Step 2: Creating a Storage Account
With the resource group ready, the next thing on my list was setting up a storage account:
- In the Azure portal, I searched for Storage accounts and selected + Create.
- I made sure to choose the resource group I just created.
- For the storage account name, I needed something unique across Azure, so I went with a distinctive name like teststorageaccount.
- I set the performance tier to Standard since high performance wasn’t a priority for this prototype.
- After reviewing everything, I clicked Create and waited for the deployment to finish. Once done, I clicked Go to resource to jump straight into the configuration.
Step 3: Configuring Basic Settings in the Storage Account
Now came the fun part—tweaking some basic settings to match the project's needs.
Configuring Redundancy
Since this was all about keeping costs low and we didn’t need high availability, I chose the simplest redundancy option:
- I navigated to the Redundancy section under Data management in the storage account.
- Here, I selected Locally-redundant storage (LRS), which stores data within a single location, minimizing costs.
- I hit Save to lock in the changes and confirmed everything looked good by refreshing the page.
Enforcing Secure Transfer
Security is always a priority, even for training scenarios:
- Under Configuration in the Settings section, I made sure that Secure transfer required was set to Enabled.
- This ensures that all data transferred to and from the storage account uses secure connections, which adds a layer of protection.
Setting the Minimum TLS Version
To keep up with best practices, I adjusted the TLS settings:
- Still in the Configuration section, I set the Minimal TLS version to 1.2. This step ensures that all connections meet modern security standards.
- As usual, I saved these settings before moving on.
Disabling Shared Key Access
To prevent unauthorized access while the storage was idle, I disabled shared key access:
- In the same Configuration area, I found Allow storage account key access and set it to Disabled.
- After saving, this ensured that no one could access the account using shared keys, keeping it secure until needed.
Allowing Public Access from All Networks
Lastly, I adjusted the networking settings to ensure the storage account was easily accessible for testing:
- Under the Networking blade in Security + networking, I set Public network access to Enabled from all networks.
- After saving these changes, the storage account was ready for any network to connect, making it perfect for training and prototyping.
Overall, this was a straightforward setup designed for ease of use and low cost, ideal for scenarios where the data’s not critical. It was a great hands-on way to get familiar with Azure's storage configurations while keeping things simple and flexible. If you're looking to set up something similar or have questions, feel free to ask in the comments!
Top comments (0)