In this article, I will walk through how I created an Azure Storage account, configured Blob Storage, uploaded a file, made it publicly accessible, and finally generated a Shared Access Signature (SAS) link for secure access.
This is part of my hands-on learning journey in Cloud Computing and DevOps using Microsoft Azure.
Creating the Azure Storage Account
The first step was to create a Storage Account in Microsoft Azure. This is the core service that provides a scalable location for storing files such as images, videos, documents, and backups.
Configuration used:
Resource Group: je-mega-soft
Storage Account Name: prodjemegastorage1
Region: Africa (South Africa North)
Primary Service: Azure Blob Storage
Performance: Standard
Redundancy: Locally Redundant Storage (LRS)
Access Tier: Hot
Allow Blob Public Access: Enabled (on container level)
Explanation of each choice:
Resource Group (je-mega-soft):
A resource group is simply a logical container in Azure that holds related resources. I used this to group everything related to my project for easy management and cleanup.
Storage Account Name (prodjemegastorage1):
This must be globally unique across Azure. I used a structured name to represent a production-style storage setup.
Region (Africa – South Africa North):
I selected this region because it is geographically closer to my location, which reduces latency and improves performance when accessing resources.
Primary Service (Blob Storage):
Blob Storage is designed for storing unstructured data like images, videos, logs, and backups. It is the best choice for this type of project.
Performance (Standard):
Standard performance was chosen because this is a learning/demo project. It is cost-effective and suitable for general-purpose storage. Premium would only be needed for high-speed enterprise workloads.
Redundancy (Locally Redundant Storage - LRS):
LRS stores data in a single data center but keeps multiple copies within that facility. I chose this because it is the cheapest option and perfect for testing and learning purposes.
Access Tier (Hot):
The Hot tier is used for data that is accessed frequently. Since I planned to upload and access the file during testing and sharing, this was the best fit.
Public Access Enabled:
I enabled public access at the container level because I wanted the uploaded file to be accessible via a URL without authentication.
After reviewing all settings, I clicked Create and waited for deployment to complete.
Creating a Blob Container
After the storage account was successfully created, I moved to the next step which is creating a container.
Path:
Storage Account → Data Storage → Containers → + Add Container
Container configuration:
Name: jemega-img-vid
Public Access Level: Container (anonymous read access for containers and blobs)
Why I used this container name:
I chose jemega-img-vid because:
“jemega” represents my personal/project brand name
“img-vid” clearly indicates the container is meant for images and videos
It is short, readable, and meaningful for future scaling
Public Access Level explanation:
Setting the access level to Container means:
Files inside the container can be publicly accessed
Anyone with the link can view blobs without authentication
This is useful for demos, static file hosting, and learning scenarios
About the $logs container:
During setup, Azure automatically created a container called $logs.
This container is used for system-generated logs such as:
Storage analytics logs
Request tracking logs
Diagnostic monitoring data
It is not meant for user files, so I did not modify or use it.
Uploading the File to Blob Storage
Next, I uploaded a file into the container.
File uploaded:
just me.png
Steps:
Opened the container (jemega-img-vid)
Clicked on Upload
Selected the file from my local system
Clicked Upload to store it in Azure Blob Storage
Once uploaded, Azure automatically generated a unique URL for the file.
Blob URL generated:
https://prodjemegastorage1.blob.core.windows.net/jemega-img-vid/just%20me.png
Explanation:
This URL directly points to the file inside the container. Because public access was enabled, the file can be accessed in a browser without authentication.
Generating a Shared Access Signature (SAS)
To improve security while still allowing temporary access, I generated a Shared Access Signature (SAS).
What is SAS?
A SAS token is a secure way to grant limited access to storage resources without exposing your account keys. It allows you to define:
What can be accessed
How long access is valid
What permissions are allowed
Why I used Key 1:
I used Key 1 from the storage account because it is one of the primary access keys used to generate SAS tokens. These keys should be protected because they grant full control over the storage account.
SAS configuration used:
Start Time: Today at 10:30 PM
Expiry Time: 31st of this month at 12:03 PM
Permissions: Read (sp=r)
Protocol: HTTPS only
Why SAS is important:
SAS provides:
Temporary access instead of permanent public exposure
Better security control over shared files
Ability to revoke access by changing keys or expiry
Fine-grained permissions (read, write, delete, etc.)
*Final SAS URL (Secure Access Link)
*
Here is the final link generated using SAS:
Conclusion
This walkthrough helped me understand the basics of Azure Blob Storage, from creating a storage account and container to uploading a file and generating a SAS link for controlled access. I also learned how key settings like redundancy, access tier, and public access affect cost, performance, and security. Overall, it made cloud storage concepts clearer and gave me a solid foundation for working with Azure storage services going forward.
