Azure Blob Storage - Simply Explained

Hello everyone and welcome to another episode of Knowledge Nuggets. I'm your host, Mirko Peters. Today's topic is one that almost everyone has heard of, but most people can't explain. Blob Storage, sounds like something from a 1950s sci-fi movie, right? Some alien creature that eats your data, the truth is, as you are Blob Storage, is probably the most common cloud storage service you'll ever use. Even if you never realize it, most people think cloud storage means dropbox or Google Drive. Drag a file into a folder and it magically appears on your other devices. As you are Blob Storage is different, it's built for a completely different job, storing massive amounts of unstructured data at cloud scale. We're talking trillions of files, petabytes of information, and enough throughput to keep AI training clusters busy. By the end of this episode, you'll understand exactly how Blob Storage works. The hierarchy, storage account, container, blob. The three blob types and when to use each one. The access tiers that let you match cost to how often you need your data. And the real world scenarios where Blob Storage is the right tool for the job. Here's the simplest definition. What is Blob Storage? So what is Blob Storage? In plain English, it's object storage for unstructured data. That sounds complex, but here's what it really means. Unstructured data is anything that doesn't fit neatly into rows and columns. A photo of your dog, a product demo video, a web server, log file, a database backup, a PDF contract. None of these have a fixed schema. No columns called name or date or price. It's just binary data with a little metadata attached. Blob stands for binary large object. And that's exactly what it is, a large chunk of binary data that adds your stores for you. Think of it like a massive warehouse where you can dump anything. And Azure will keep it safe, make copies, and serve it back whenever you need it. Here's a way to visualize it. Imagine a modern office building. The building itself is your storage account. It's the outermost container with an address and a name. Inside the building, you have different floors, which are your containers. And on each floor, there are individual rooms or filing cabinets. Those are your blobs, the actual files. Now, why does unstructured matter? Change is how you think about storage. Traditional file servers organize data in a folder hierarchy, a C drive, a folder called Documents, a subfolder called Projects, then a file. That hierarchy lives on a physical disk somewhere. And if that disk fails, you lose everything in that folder path. Blob storage doesn't work that way. Under the hood, everything is flat. No folder tree on a physical disk. You have a storage account, then a container, then blobs. The container is a flat name space. You can't nest containers inside containers. Lives at the same level inside its container. The folder like Structure you see in the portal is just metadata. A virtual path as your creates for your convenience. The actual storage is flat and the scale is enormous. A single block blob can hold up to about 4.75 terabytes, big enough to store an entire high definition movie library. On top of that, you can have trillions of blobs in one account with no practical limit to how much data you can store. That's the kind of power as your blob storage gives you. The hierarchy, storage account, container, blob. So how does blob storage actually organize your data? There are three levels in the hierarchy and each one has a specific job. At the top is the storage account. This is the name space for all your data. Every storage account needs a globally unique name. Between three and 24 characters, lowercase letters and numbers only. No hyphens, no underscores. That uniqueness is enforced across all Azure regions. So if you try my backups, someone in Japan, Brazil or Australia might have already taken it. The name you choose becomes part of the URL that applications use to access your data. The storage account also defines your performance tier. You have two options. Standard uses HDD storage, traditional spinning hard drives and works fine for most general workloads. Premium uses SSD storage for much lower latency and higher throughput. Premium costs more, but for AI inference or sub 10 millisecond response times, it's worth every penny. Below the storage account, you have containers. A container is the second level in the hierarchy. Think of it as a top level folder, but it's flat. You cannot nest containers inside each other. You can have as many as you need all at the same level. The container name becomes part of the URL for every blob inside it. And that brings us to the blob itself. Every blob has a unique URL like this. HTPS will splash your storage account, blob.core.windows.net. Now your container, your blob name. Applications access data through that simple web address. There are no file paths, no drive letters, no mounting. Just a clean direct URL that points to your data anywhere in the world. Blobs also carry metadata. When you upload a file, Azure automatically stores the content type, JPEG, PDF, video. You can also add custom tags like project name, department, or retention date. This metadata travels with the blob and can be used by applications and Azure services. Azure uses it for tearing decisions, lifecycle policies, and search filters. Here's a simple way to think about it. Your storage account is a filing cabinet. Each container is a draw. Each blob is a file inside that draw. That's the full hierarchy. Three levels. And nothing more complicated than that. The three blob types. Block, append, page. Not all blobs are created equal. There are three types. Each build for a specific job. The first type is the block blob. This is the workhorse of blob storage. When someone says upload a file to blob storage, they almost always mean a block blob. Images, videos, documents, backups, database dumps. Any file you can think of gets stored as a block blob. When you upload a file, Azure splits it into individual blocks. Each block uploads separately, often in parallel, making the process much faster. Once all blocks are uploaded, Azure commits them into a single blob. If a block fails during upload, only that block needs to be retried. Not the entire file. This design makes block blobs ideal for large files and streaming scenarios. The second type is the append blob. This one is optimized for append only operations. You can only add blocks to the end. You cannot modify or delete existing data. That makes append blobs perfect for logging. Imagine a web server generating log entries continuously. Each new log entry depends to the end of the blob. All the trails work the same way, IoT sensor data too. Any scenario where data flows in one direction and you never need to go back and change what's already there. The third type is the page blob. This one is completely different. Page blobs are made up of fixed size, 512 byte pages that support random read and write access. You can jump to any position in the blob and read or write data there. That matters because page blobs are used as virtual hard disks for Azure virtual machines. When you create a VM in Azure, the operating system disk is a page blob. The data disks are page blobs. It's designed for the kind of random access patterns that operating systems and databases need. Here is a simple rule to remember. If it's a file someone uploads or downloads, use a block blob. If it's a continuous stream of log entries or sensor readings, use an append blob. If it's a virtual machine disk, use a page blob, three types, three jobs, no confusion. Access tiers, hot cool cold archive. Welcome back to another knowledge nugget. Today we're talking about where your blobs live and how picking the right spot saves you money. Azure gives you four storage tiers and each one trades off between storage cost and access. The idea is simple. Data you touch all the time goes in a tier where reading is cheap even if storing costs a bit more. Data you almost never need goes somewhere. Storage is dirt cheap even if reading costs more when you finally pull it up. First up is hot. This is the default tier. Upload a blob without specifying where it goes and it lands here. Storage costs are highest in hot but transaction costs, the price of reading and writing are lowest. Hot is for data you grab regularly. Think customer facing images on a website, active project files or this month's logs. Anything that needs to pop up instantly. Next is cool. Storage costs drop by about 80% compared to hot but transaction costs go up. Cool is for data you access less than once a month. Short term backups from last quarter. Reports you might need to check occasionally. Files from finished projects that you aren't ready to toss yet. Then we have cold. Microsoft added this tier in 2023 and it sits right between cool and archive. Storage is even cheaper than cool but transactions cost more. Cold is for data you access every 90 days or so. Compliance data you keep for a few years. Historical backups you rarely restore but can't delete. Last is archive. This is the cheapest storage as your offers. Penny's per gigabyte per month. But here's the catch. Archive is offline storage. You can't read a blob while it's sitting in archive. You have to rehydrate it first which means moving it back to hot cool or cold. That process takes 2 to 15 hours. Archive is for data you're legally required to keep but will almost never touch. All tax records, 10 year old backup tapes, compliance archives that sit untouched until an auditor asks for them. Think of it like your closet. Hot is the shirt you wear every week. Right there, easy to grab. Cool is the jacket you pull out once a month when the weather turns. Cold is the formal wear you use a few times a year. Archive is the winter coat in the attic. You know it's there. But getting it out takes some work. Now here's the cost trap nobody warns you about. Moving data between tiers cost money. Every time you change a blob's tier, you pay a transaction fee. If you shuffle things around every few days, those fees eat up any savings you thought you were getting. The fixes lifecycle management, which we'll cover next. But the key takeaway is this. Pick the right tier for your access pattern and leave it there. Don't try to game the system by moving things constantly. Life cycle management automate the tiers. Manually moving blobs between tiers sounds exhausting doesn't it? You'd have to track every file. Remember when you uploaded it and decide when it's time for cheaper storage. Nobody has time for that. And honestly, you'd probably forget half the time anyway. That's exactly why Azure build lifecycle management right into blob storage. Life cycle management is a rule based engine that lives inside Azure blob storage. You define the rules and as your handles everything automatically. It moves blobs between tiers based on age, last modification or last access. It can even delete blobs when they have outlived their usefulness. Here's a typical setup. Say you have a backup system that creates a daily backup file. You want the last 30 days in hot tier so you can restore quickly if something breaks. After 30 days, you don't need instant access anymore. So Azure moves them to cool. After 90 days, they shift to archive. After 365 days, they get deleted entirely. That's three rules in a single policy. If a block blob hasn't been modified in 30 days, move it from hot to cool. After 90 days, move to archive, delete after 365 days. Azure runs these rules continuously, scanning your blobs and taking action whenever a blob meets the conditions. You can scope these rules to specific containers, specific blob types, or even use prefix filters. Picture this. You have one container for application logs and another for customer uploads. You can apply different lifecycle policies to each one. Logs get archived after 30 days. Customer uploads stay in hot for a year. There's one gotcha you need to know about. The billing cycle. If you move a blob from cool to hot in the middle of the month, you pay the cool rate for the entire billing cycle. You don't get the hot rate until the next cycle starts. This is Azure's way of stopping people from gaming the system by moving blobs around constantly. So don't micromanage. Set your rules and let them run. Best practice is to enable last access time tracking. By default, lifecycle rules can use creation time or last modified time. But last access time gives you much more accurate rules. If a blob hasn't been accessed in 30 days, it's probably safe to move to cool. If it hasn't been accessed in 180 days, archive it. This way, blobs that are rarely accessed but still important don't get moved to cold storage too early. For advanced setups, Azure also offers storage actions. This newer feature lets you orchestrate lifecycle management across multiple storage accounts and even across regions. It's security and access control. Now that you know how to store and manage blobs, let's talk about who gets to see them. Because storing data in the cloud means nothing if anyone can walk right in. You have two main ways to control access. First is shared key authorization. Your storage account comes with two access keys. If you have the key, you have full access to everything. Every container, every blob, every operation. Think of it like having a master key to the whole building. Powerful but dangerous if the wrong person gets their hands on it. The second approach is shared access signatures or SAS tokens. Assess token is a URL with a time limit and specific permissions. You generate it for a particular blob or container, set an expiration time and define exactly what operations are allowed. Read only, write only or both. The URL looks like a normal blob URL with a long string of characters at the end and that string is the token itself. SAS tokens are perfect for temporary access. Say you want to let a customer download a large file. You generate a SAS token that expires in 24 hours and only allows read access, then send them the URL. After 24 hours, the token expires and they can't access the file anymore. You don't have to change any passwords or revoke any permissions. It just stops working. But today, the recommendation is to move away from keys and SAS tokens entirely. Instead, use Microsoft EntryD with Azure R-Back, Roll-Based Access Control. You assign roles to users, groups or applications. For example, the storage blob data reader role lets someone read but not write or delete. The contributor role lets them read and write. And the owner role gives full control. Here's why this is better. EntryID integrates with everything else in Azure. You can use the same identity system for storage, databases, virtual machines and applications. You don't have to manage separate keys for every service and you can audit who accessed what and when. Network security gives you another layer. You can configure firewalls on your storage account to only allow traffic from specific IP addresses or virtual networks. You can use service endpoints to secure traffic from Azure services. And for the highest level of security, private endpoints give your storage account a private IP address inside your virtual network. Traffic never leaves the Azure backbone. It's like having a direct fiber connection from your application to your storage. Encryption is handled automatically. All data address is encrypted by default using Azure Managed Keys. If you need more control, you can bring your own keys using Azure Key Vault. You manage the keys and Azure uses them for encryption. This is often required for compliance with regulations like HIPAA or PCI DSS. SoftDelete is a safety net. If someone accidentally deletes a blob, it's not gone forever. By default, those blobs stick around for seven days and you can configure that up to 365 days. During that time, you can recover the blob with a single click. It's like a recycle bin for your cloud storage. For the most sensitive data, there's immutable storage, also called worm storage. Right once read many. Once you store a blob with an immutability policy, it cannot be modified or deleted for a specified period, not by anyone, not even by the storage account owner. This is critical for compliance scenarios where you need to prove that records haven't been tampered with. Redundancy and durability. If Azure loses a data center, redundancy is what protects you. Most people don't think about this until it's too late. Every blob you store is copied three times synchronously within at least one data center. That's the baseline. Three copies written at the same moment. If one copy fails, the other two are still there. But where those three copies live depends on the redundancy option you choose. The first option is LRS locally redundant storage. Three copies in a single data center. It's the cheapest option and the least durable. If that data center burns down or floods, you lose all three copies. LRS is fine for dev and test environments and for data you can easily recreate, but it is not fine for anything you'd cry about losing. The second option is ZRS zone redundant storage. Three copies spread across three different availability zones within the same region. Think of availability zones as separate data centers with their own power, cooling and networking. If one data center fails, the other two keep running, so ZRS protects against data center level failures. If you're running production workloads in a single region, ZRS is your baseline. The third option is GRS, geo-redundant storage and this one works differently. You get LRS in your primary region. Three copies in one data center. Then Azure asynchronously copies that data to a paired region where it stores three more copies using LRS. So you end up with six copies total spread across two regions. The catch is that the A sync replication can have up to 15 minutes of delay. If a disaster hits during that window, you might lose the most recent changes. The fourth option is GZRS, geo-zone redundant storage. This combines ZRS in the primary region with LRS in the secondary region. You get zone redundancy locally and geo-redundancy globally. It's the most durable option as your offers. And if you enable read access like RAGRS or RAGRS, you can read from the secondary region even during normal operations. That means zero downtime during a regional failure. So here's a simple rule of thumb. You get LRS for dev and test. ZRS for production in a single region. GZRS for mission critical applications. Where downtime is not an option. And remember redundancy protects your data, not your application. You still need to design your application to handle failures gracefully. Real-world use cases. All right, let's talk about where blob storage actually shows up in the real world. These aren't theory exercises. These are the jobs Azure customers give it every day. First up, backup and disaster recovery. This is probably the most common reason people start using blob storage. VM backups, database dumps, file shares, anything you need to bring back to life after a failure. Those lifecycle rules we talked about, they automatically move old backups to cool and then to archive. So your most recent backups are instantly accessible and your year old backups cost pennies to store. That's a win. Next, media and content distribution. If you host images, videos or documents, blob storage is the place to put them. Parade with Azure CDN or Azure Front Door and a user in Tokyo gets served from a server in Tokyo, not from your storage account in Virginia, fast delivery, low latency, minimal egress costs. Simple. Now let's talk data lakes and analytics. Azure Data Lake Storage, JN2 is built directly on top of blob storage. It adds a hierarchical namespace and Hadoop compatible file system semantics. That's what powers Azure Synapse, Databricks and Power BI at scale. We're talking petabytes of data, trillions of files and analytics queries that run in seconds. AI training data is another big one. If you're training machine learning models, you need massive amounts of data. Terabytes of images, text files, training checkpoints, blob storage handles this at exabyte scale. The premium tier gives you single digit millisecond latency. Blobfuse lets you mount containers as local file systems. And the throughput keeps GPU clusters fully utilized. It's built for the heavy lifting. Finally, log storage. Append blobs are perfect for streaming logs, application telemetry and IoT sensor data. Each new entry gets appended to the end. You never modify existing data. And lifecycle rules automatically archive or delete old logs based on your retention policy. Set it and forget it. So every use case maps to a different blob type and tier. Backups use block blobs and cooler archive. Media uses block blobs in hot with CDN. Data lakes use block blobs with hierarchical namespace. AI training uses block blobs and premium. Logs use append blobs in hot then cool. That flexibility is the killer feature. All right, here's what we covered today in plain English. Blob storage is flat, scalable object storage for unstructured data. You organize it in accounts, containers and blobs. Three blob types handle different jobs. Block for general files, append for logs, page for VM disks. Four access tiers let you match cost to how often you access data. Life cycle management automates the movement. And security and redundancy give you control over who sees your data and how safe it is. Here's your homework. Next time you need to store a file in the cloud, ask yourself one question. Is this data frequently accessed or rarely touched? That single question tells you which tier to use and saves you money from day one. Ready to go deeper. Next episode will compare Azure files and blob storage. Two services that look similar but solve completely different problems. Subscribe so you don't miss it. Your files don't need to be scary. Azure blob storage makes them simple.