Storage Account
A storage account is the resource that contains Azure's core storage services — Blob, Files, Queues, and Tables — under one namespace, one set of networking and security controls, and one bill. Its name forms the endpoint hostname and must be globally unique across all of Azure.
Understanding the account is what ties the rest of this chapter together: redundancy, networking, and the security model are account-level decisions that apply to everything inside. Two services live only here — Queue Storage for simple async messaging, and Table Storage (covered in Chapter 3) for cheap key-value data.
Account Kinds and SKUs
General-purpose v2 is the standard account kind and the right default — it supports all four services and every redundancy and tier option. Premium accounts use SSD-backed storage scoped to a specific service (block blobs, file shares, or page blobs) for low latency. The kind and the redundancy SKU are chosen at creation and shape what the account can do.
Services in the Account
Blob holds objects, Files holds SMB/NFS shares, Tables holds schemaless key-value rows, and Queues holds simple messages for decoupling components. Queue Storage is the lightweight async option — basic at-least-once delivery, no ordering or topics — and the line where you graduate to Service Bus is when you need ordering, sessions, or pub/sub.
Networking
By default the account answers on a public endpoint. A storage firewall restricts access to selected networks and IP ranges; service endpoints grant a subnet direct access; private endpoints give the account a private IP inside a VNet so traffic never touches the public internet. Locking down network access is the first hardening step on any account holding real data.
Security and Keys
Every account has two access keys that grant full control — powerful, hard to scope, and to be avoided in application code. Entra ID with RBAC is the preferred model; shared access signatures provide scoped, time-limited delegation when a key-free URL is needed. Keys should be rotated, and the rotation is two-key precisely so you can roll one while the other stays valid.
- Using account keys in application code instead of Entra ID with RBAC — a leaked key grants full control of every service in the account.
- Leaving the account on its public endpoint with no firewall, exposing data to the whole internet.
- Reaching for Queue Storage when the workload needs ordering, sessions, or pub/sub — that is Service Bus, not Queues.
- Picking a Premium account kind scoped to the wrong service, then finding it cannot hold the data you needed.
- Never rotating access keys, so a key leaked years ago still works.
- Treating the globally unique account name as throwaway, then being unable to reuse a meaningful name someone else has taken.
- Use general-purpose v2 unless a specific Premium, service-scoped account is required.
- Authenticate with Entra ID and RBAC; avoid account keys in code, and scope SAS tokens tightly when needed.
- Restrict network access with a storage firewall and private endpoints before the account holds real data.
- Use Queue Storage for simple decoupling; move to Service Bus when you need ordering, sessions, or topics.
- Rotate access keys on a schedule, using the two-key design to roll without downtime.
- Choose redundancy at the account level to match the value of the data it will hold.
Knowledge Check
Why are account access keys discouraged in application code?
- Each key grants full control of every service in the account, and a leak is catastrophic and hard to scope
- Keys silently expire on a fixed 24-hour clock and then abruptly break the running application until rotated
- Keys authorize Blob access only, never Files, Queues, or Tables
- Using a key turns off encryption at rest for the whole account
When should you move from Queue Storage to Service Bus?
- When you need ordering, sessions, or publish-subscribe topics that Queue Storage does not provide
- When you simply need the cheapest possible messaging at the lowest cost
- When individual messages grow larger than one kilobyte in size
- When the queue and its consumer must sit together in the very same Azure region for the lowest latency
What does a private endpoint do for a storage account?
- Gives the account a private IP inside a VNet so traffic avoids the public internet
- Lets the account name stop being globally unique across all of Azure
- Replaces the need for any access keys or Entra authentication
- Automatically replicates the account data to a geographically paired second region
You got correct