Azure Storage: a hands‑on guide to containers, access tiers, file shares, SAS tokens, and key rotation
Azure Storage walkthrough: create containers, change access tiers, set up file shares, generate SAS tokens, and rotate access keys to revoke access efficiently.
How storage management fit into the guided project
The guided lab focused on Azure Storage and practical storage management tasks that matter for day‑to‑day cloud operations: storing data efficiently, optimizing storage cost, and controlling and revoking access securely. Working inside an existing storage account named guided-project-rg, the exercise moved from creating a container and uploading a blob through changing access tiers and setting up a file share, to issuing a Shared Access Signature (SAS) for limited access and finally revoking that access by rotating an account key. Taken together, these steps demonstrate how lifecycle, cost, and access controls combine when administrating Azure Storage.
Creating a storage container and uploading a blob
The first tangible step in the lab was to create an object container and place a test file into it. Within the storage account the workflow was to navigate to Data storage → Containers, create a new container named storage-container, and upload a test image file into that container. When the file uploaded it was automatically assigned the Hot access tier.
That automatic assignment illustrates a common default: newly uploaded blobs in this scenario were placed in Hot tier, which is intended for frequently accessed data. Because the uploaded file in the lab was only a test artifact, keeping it in Hot was not cost‑efficient; that set up the next task, adjusting the access tier.
Changing access tiers to optimize cost
After the blob appeared in storage, the lab author selected the blob, chose Change tier, switched it from Hot to Cold, and saved the configuration. This explicit action—moving the blob from Hot to Cold—was used to emphasize a fundamental storage concept that the project highlighted: storage tiers materially affect cost and not all objects require premium, frequent access.
The step shows an operational pattern you can apply inside Azure Storage: evaluate expected access patterns, and move objects to a lower access tier when they are infrequently read. In the lab this was a deliberate cost optimization applied to a test file; the exercise framed tier changes as part of responsible lifecycle management rather than a one‑off setting.
Deploying an Azure File Share for shared access scenarios
The guided project did not stop at blobs. It also exercised Azure Files, the SMB‑style shared storage capability that coexists with object blob storage in the same account. Inside the same storage account the author navigated to File shares, created a new share called file-share, enabled backup for the lab, and uploaded a file into the share.
This sequence established two complementary storage constructs in the environment: blob storage, described in the lab as object‑based, and file shares, described as SMB‑style shared storage. The lab explicitly noted that these are different storage solutions intended for different use cases, with the file share configured to allow shared, backup‑enabled storage within the same account context as the blobs.
Generating a Shared Access Signature (SAS) token for limited access
Controlling access without exposing full account credentials was the next focus. Instead of sharing account keys, the exercise generated a Shared Access Signature for the uploaded blob. The lab’s SAS configuration details are explicit:
- Signing method: Account key
- Signing key: Key 1
- Permissions: Read only
- Protocol: HTTPS only
- Custom expiration time
After generating the SAS, the author copied the Blob SAS URL into a new browser tab and confirmed that the image displayed successfully. The lab highlighted three practical advantages of SAS tokens shown by this step: there is no need to share account keys, access provided is time‑bound, and permissions can be granular (in this case read‑only). That combination demonstrates a lightweight, temporary access pattern for distributing single‑object access while preserving broader account security.
Rotating access keys to revoke access
Granting temporary access is only one half of secure access governance; the other half is revocation. Because the SAS token in the lab was signed with Key 1, the author invalidated that token by rotating Key 1. In the portal the workflow was to go to Security + networking → Access keys, select Rotate key for Key 1, and confirm the regeneration. After rotation, the author refreshed the browser tab with the SAS URL and observed authentication failures.
The lab recorded that authentication failed and access was successfully revoked, using key rotation to demonstrate an important Azure security behavior: rotating a storage account key immediately invalidates all SAS tokens that were signed with that key. The practical outcome in the exercise validated key rotation as an effective method to cut off previously issued SAS access without changing individual tokens.
What the lab delivered: tangible outcomes
By the end of the exercise the author had completed a compact but comprehensive set of storage administration tasks inside a single storage account:
- Created and configured blob storage and a container (storage-container).
- Uploaded a blob and adjusted its access tier from Hot to Cold to optimize cost.
- Created an Azure File share (file-share), enabled backup for the lab, and uploaded a file into the share.
- Generated a read‑only, HTTPS‑only SAS token using Account Key 1 with a custom expiration, and validated access via the SAS URL.
- Revoked that access by rotating Key 1 and confirmed that the SAS URL authentication failed.
Those steps together reinforced three core areas the project emphasized: storage architecture, access governance, and cost management.
Why these operations matter in practical administration
Each step in this lab addresses a routine operational need:
- Container creation and blob uploads are the building blocks for object storage and content delivery tasks.
- Access tiers map directly to storage cost and should be matched to actual access patterns; moving a rarely accessed object to Cold tier reduces expense compared with leaving it in Hot.
- File shares provide a different access model suited for shared file systems and backup scenarios, and having both object and file options available in one account lets administrators choose the right tool for each workload.
- SAS tokens offer targeted, time‑limited access without exposing account credentials.
- Key rotation provides a blunt but effective mechanism to revoke any token signed with a rotated key.
The lab framed these mechanisms not as isolated features, but as interlocking pieces of responsible cloud storage management: lifecycle control, cost awareness, and access governance.
Security mechanics demonstrated by the SAS + key rotation pattern
The sequence—issue a SAS token signed with an account key, then rotate that key when access must end—illustrates a security pattern that can be applied when administrators need fast, account‑level revocation. In the lab the SAS was explicitly read‑only and HTTPS‑only, demonstrating use of the permissions and protocol controls available at token generation time. Rotating the signing key produced immediate authentication failures on the SAS URL, underscoring the coupling between a SAS’s validity and the key that signed it.
Because the experiment used a custom expiration in addition to key signing, it also showed layered controls: tokens can be issued with a built‑in expiration while key rotation provides an administrative kill switch before that time elapses.
Developer and operations implications
For developers and operators working with Azure Storage in similar lab or production contexts, the exercise suggests a few operational patterns supported by the project’s steps:
- Keep default tier assignments in mind and apply tier changes where appropriate to align cost with access frequency.
- Use file shares when SMB‑style, shared storage semantics are required, and use blob containers for object storage scenarios.
- Prefer SAS tokens over sharing account keys for object‑level, temporary access. Configure SAS tokens with minimal permissions and HTTPS‑only protocols where possible.
- Maintain a key rotation policy so that any issued tokens can be revoked quickly if needed; rotating keys is an effective way to immediately invalidate SAS tokens that depend on them.
The lab itself executed these patterns inside an existing storage account named guided-project-rg and enabled backup on the file share for the purposes of the exercise, reinforcing that these are practical administrative actions rather than abstract concepts.
How this fits into broader storage and cloud workflows
Although this exercise focused on portal operations—creating containers and shares, uploading files, changing tiers, generating a SAS, and rotating a key—the procedures shown are representative of how storage lifecycle and access control are managed in cloud environments. Within a broader workflow, the same operations appear alongside policy definition, backup and restore plans, and access governance in organizational settings. The lab’s inclusion of both blob and file share configuration demonstrates that a single storage account can host multiple storage models to meet different application and backup requirements.
Operational caveats observed in the lab
The guided steps also surface a couple of operational cautions:
- Default tiering behavior can lead to unnecessary cost if objects are uploaded and left in a high‑access tier when they are seldom used. The lab mitigated that by moving the test blob to Cold.
- SAS tokens are convenient but tied to the signing key; if that key is compromised, all SAS tokens signed with it may be at risk until rotation occurs. The exercise showed how rotation provides immediate revocation, but it also implicitly underscores the importance of protecting account keys and planning for key lifecycle management.
These caveats align directly with the lab outcomes and were demonstrated through the concrete actions taken during the guided exercise.
Practical follow‑ups and what lab participants can do next
Following the lab’s pattern, administrators or learners working inside a similar storage account can reproduce each step to build familiarity: create a container, upload a blob, inspect the default tier, change the tier to Cold for low‑use objects, create a file share and enable backup for it, issue a SAS with limited permissions and test it, then rotate the signing key and verify the SAS is invalidated. Those repeatable operations provide hands‑on reinforcement of the concepts the lab set out to teach: lifecycle management, cost control, and access governance.
Broader implications for teams and organizations
On an organizational level, the lab highlights how a few straightforward administrative controls combine to support security and cost objectives. Teams that codify access policies (for example, having templates for SAS generation with strict defaults) and that integrate key rotation into operational runbooks can reduce the risk of lingering access and can align storage costs to actual usage. Likewise, treating file shares and blob containers as distinct options and documenting when each should be used helps avoid architectural drift where the wrong storage type is used for a workload.
These points emphasize that cloud storage management is not only about uploading files but about managing lifecycle, security, and access as operational responsibilities.
The exercise described in the guided project demonstrates how relatively simple portal operations—container creation, tier changes, file share setup, SAS issuance, and key rotation—can be combined to implement practical, testable storage governance controls that are relevant to administrators, developers, and operations teams alike.
Looking ahead, teams using these patterns can refine them into automated policies and operational playbooks, for example coupling tier transitions to lifecycle rules or integrating key rotation into scheduled maintenance, to make storage governance more predictable and to ensure that access can be granted and revoked cleanly as use cases evolve.
