1 00:00:00,000 --> 00:00:03,480 Hello everyone and welcome to another episode of Knowledge Nuggets. 2 00:00:03,480 --> 00:00:05,400 I'm your host, Mirko Peters. 3 00:00:05,400 --> 00:00:07,800 Today's topic is one that almost everyone has heard of, 4 00:00:07,800 --> 00:00:09,240 but most people can't explain. 5 00:00:09,240 --> 00:00:13,320 Blob Storage, sounds like something from a 1950s sci-fi movie, right? 6 00:00:13,320 --> 00:00:15,680 Some alien creature that eats your data, the truth is, 7 00:00:15,680 --> 00:00:19,960 as you are Blob Storage, is probably the most common cloud storage service you'll ever use. 8 00:00:19,960 --> 00:00:24,800 Even if you never realize it, most people think cloud storage means dropbox or Google Drive. 9 00:00:24,800 --> 00:00:28,040 Drag a file into a folder and it magically appears on your other devices. 10 00:00:28,040 --> 00:00:29,520 As you are Blob Storage is different, 11 00:00:29,520 --> 00:00:31,520 it's built for a completely different job, 12 00:00:31,520 --> 00:00:34,800 storing massive amounts of unstructured data at cloud scale. 13 00:00:34,800 --> 00:00:37,760 We're talking trillions of files, petabytes of information, 14 00:00:37,760 --> 00:00:40,720 and enough throughput to keep AI training clusters busy. 15 00:00:40,720 --> 00:00:44,240 By the end of this episode, you'll understand exactly how Blob Storage works. 16 00:00:44,240 --> 00:00:47,440 The hierarchy, storage account, container, blob. 17 00:00:47,440 --> 00:00:49,640 The three blob types and when to use each one. 18 00:00:49,640 --> 00:00:53,320 The access tiers that let you match cost to how often you need your data. 19 00:00:53,320 --> 00:00:57,080 And the real world scenarios where Blob Storage is the right tool for the job. 20 00:00:57,080 --> 00:00:58,760 Here's the simplest definition. 21 00:00:58,760 --> 00:01:00,760 What is Blob Storage? 22 00:01:00,760 --> 00:01:02,760 So what is Blob Storage? 23 00:01:02,760 --> 00:01:05,760 In plain English, it's object storage for unstructured data. 24 00:01:05,760 --> 00:01:07,760 That sounds complex, but here's what it really means. 25 00:01:07,760 --> 00:01:11,760 Unstructured data is anything that doesn't fit neatly into rows and columns. 26 00:01:11,760 --> 00:01:16,760 A photo of your dog, a product demo video, a web server, log file, a database backup, a PDF contract. 27 00:01:16,760 --> 00:01:18,760 None of these have a fixed schema. 28 00:01:18,760 --> 00:01:21,760 No columns called name or date or price. 29 00:01:21,760 --> 00:01:24,760 It's just binary data with a little metadata attached. 30 00:01:24,760 --> 00:01:26,760 Blob stands for binary large object. 31 00:01:26,760 --> 00:01:30,760 And that's exactly what it is, a large chunk of binary data that adds your stores for you. 32 00:01:30,760 --> 00:01:33,760 Think of it like a massive warehouse where you can dump anything. 33 00:01:33,760 --> 00:01:37,760 And Azure will keep it safe, make copies, and serve it back whenever you need it. 34 00:01:37,760 --> 00:01:38,760 Here's a way to visualize it. 35 00:01:38,760 --> 00:01:40,760 Imagine a modern office building. 36 00:01:40,760 --> 00:01:42,760 The building itself is your storage account. 37 00:01:42,760 --> 00:01:44,760 It's the outermost container with an address and a name. 38 00:01:44,760 --> 00:01:47,760 Inside the building, you have different floors, which are your containers. 39 00:01:47,760 --> 00:01:50,760 And on each floor, there are individual rooms or filing cabinets. 40 00:01:50,760 --> 00:01:53,760 Those are your blobs, the actual files. 41 00:01:53,760 --> 00:01:55,760 Now, why does unstructured matter? 42 00:01:55,760 --> 00:01:57,760 Change is how you think about storage. 43 00:01:57,760 --> 00:02:02,760 Traditional file servers organize data in a folder hierarchy, a C drive, a folder called Documents, 44 00:02:02,760 --> 00:02:05,760 a subfolder called Projects, then a file. 45 00:02:05,760 --> 00:02:07,760 That hierarchy lives on a physical disk somewhere. 46 00:02:07,760 --> 00:02:10,760 And if that disk fails, you lose everything in that folder path. 47 00:02:10,760 --> 00:02:12,760 Blob storage doesn't work that way. 48 00:02:12,760 --> 00:02:14,760 Under the hood, everything is flat. 49 00:02:14,760 --> 00:02:16,760 No folder tree on a physical disk. 50 00:02:16,760 --> 00:02:19,760 You have a storage account, then a container, then blobs. 51 00:02:19,760 --> 00:02:21,760 The container is a flat name space. 52 00:02:21,760 --> 00:02:23,760 You can't nest containers inside containers. 53 00:02:23,760 --> 00:02:25,760 Lives at the same level inside its container. 54 00:02:25,760 --> 00:02:29,760 The folder like Structure you see in the portal is just metadata. 55 00:02:29,760 --> 00:02:31,760 A virtual path as your creates for your convenience. 56 00:02:31,760 --> 00:02:34,760 The actual storage is flat and the scale is enormous. 57 00:02:34,760 --> 00:02:41,760 A single block blob can hold up to about 4.75 terabytes, big enough to store an entire high definition movie library. 58 00:02:41,760 --> 00:02:46,760 On top of that, you can have trillions of blobs in one account with no practical limit to how much data you can store. 59 00:02:46,760 --> 00:02:49,760 That's the kind of power as your blob storage gives you. 60 00:02:49,760 --> 00:02:52,760 The hierarchy, storage account, container, blob. 61 00:02:52,760 --> 00:02:55,760 So how does blob storage actually organize your data? 62 00:02:55,760 --> 00:02:58,760 There are three levels in the hierarchy and each one has a specific job. 63 00:02:58,760 --> 00:03:00,760 At the top is the storage account. 64 00:03:00,760 --> 00:03:02,760 This is the name space for all your data. 65 00:03:02,760 --> 00:03:05,760 Every storage account needs a globally unique name. 66 00:03:05,760 --> 00:03:08,760 Between three and 24 characters, lowercase letters and numbers only. 67 00:03:08,760 --> 00:03:10,760 No hyphens, no underscores. 68 00:03:10,760 --> 00:03:13,760 That uniqueness is enforced across all Azure regions. 69 00:03:13,760 --> 00:03:17,760 So if you try my backups, someone in Japan, Brazil or Australia might have already taken it. 70 00:03:17,760 --> 00:03:21,760 The name you choose becomes part of the URL that applications use to access your data. 71 00:03:21,760 --> 00:03:24,760 The storage account also defines your performance tier. 72 00:03:24,760 --> 00:03:25,760 You have two options. 73 00:03:25,760 --> 00:03:30,760 Standard uses HDD storage, traditional spinning hard drives and works fine for most general workloads. 74 00:03:30,760 --> 00:03:34,760 Premium uses SSD storage for much lower latency and higher throughput. 75 00:03:34,760 --> 00:03:39,760 Premium costs more, but for AI inference or sub 10 millisecond response times, it's worth every penny. 76 00:03:39,760 --> 00:03:41,760 Below the storage account, you have containers. 77 00:03:41,760 --> 00:03:44,760 A container is the second level in the hierarchy. 78 00:03:44,760 --> 00:03:46,760 Think of it as a top level folder, but it's flat. 79 00:03:46,760 --> 00:03:48,760 You cannot nest containers inside each other. 80 00:03:48,760 --> 00:03:51,760 You can have as many as you need all at the same level. 81 00:03:51,760 --> 00:03:54,760 The container name becomes part of the URL for every blob inside it. 82 00:03:54,760 --> 00:03:56,760 And that brings us to the blob itself. 83 00:03:56,760 --> 00:03:58,760 Every blob has a unique URL like this. 84 00:03:58,760 --> 00:04:03,760 HTPS will splash your storage account, blob.core.windows.net. 85 00:04:03,760 --> 00:04:05,760 Now your container, your blob name. 86 00:04:05,760 --> 00:04:08,760 Applications access data through that simple web address. 87 00:04:08,760 --> 00:04:10,760 There are no file paths, no drive letters, no mounting. 88 00:04:10,760 --> 00:04:14,760 Just a clean direct URL that points to your data anywhere in the world. 89 00:04:14,760 --> 00:04:16,760 Blobs also carry metadata. 90 00:04:16,760 --> 00:04:21,760 When you upload a file, Azure automatically stores the content type, JPEG, PDF, video. 91 00:04:21,760 --> 00:04:25,760 You can also add custom tags like project name, department, or retention date. 92 00:04:25,760 --> 00:04:30,760 This metadata travels with the blob and can be used by applications and Azure services. 93 00:04:30,760 --> 00:04:34,760 Azure uses it for tearing decisions, lifecycle policies, and search filters. 94 00:04:34,760 --> 00:04:36,760 Here's a simple way to think about it. 95 00:04:36,760 --> 00:04:38,760 Your storage account is a filing cabinet. 96 00:04:38,760 --> 00:04:39,760 Each container is a draw. 97 00:04:39,760 --> 00:04:41,760 Each blob is a file inside that draw. 98 00:04:41,760 --> 00:04:42,760 That's the full hierarchy. 99 00:04:42,760 --> 00:04:43,760 Three levels. 100 00:04:43,760 --> 00:04:45,760 And nothing more complicated than that. 101 00:04:45,760 --> 00:04:46,760 The three blob types. 102 00:04:46,760 --> 00:04:48,760 Block, append, page. 103 00:04:48,760 --> 00:04:50,760 Not all blobs are created equal. 104 00:04:50,760 --> 00:04:51,760 There are three types. 105 00:04:51,760 --> 00:04:52,760 Each build for a specific job. 106 00:04:52,760 --> 00:04:54,760 The first type is the block blob. 107 00:04:54,760 --> 00:04:56,760 This is the workhorse of blob storage. 108 00:04:56,760 --> 00:05:01,760 When someone says upload a file to blob storage, they almost always mean a block blob. 109 00:05:01,760 --> 00:05:04,760 Images, videos, documents, backups, database dumps. 110 00:05:04,760 --> 00:05:07,760 Any file you can think of gets stored as a block blob. 111 00:05:07,760 --> 00:05:10,760 When you upload a file, Azure splits it into individual blocks. 112 00:05:10,760 --> 00:05:14,760 Each block uploads separately, often in parallel, making the process much faster. 113 00:05:14,760 --> 00:05:17,760 Once all blocks are uploaded, Azure commits them into a single blob. 114 00:05:17,760 --> 00:05:20,760 If a block fails during upload, only that block needs to be retried. 115 00:05:20,760 --> 00:05:21,760 Not the entire file. 116 00:05:21,760 --> 00:05:25,760 This design makes block blobs ideal for large files and streaming scenarios. 117 00:05:25,760 --> 00:05:27,760 The second type is the append blob. 118 00:05:27,760 --> 00:05:29,760 This one is optimized for append only operations. 119 00:05:29,760 --> 00:05:31,760 You can only add blocks to the end. 120 00:05:31,760 --> 00:05:33,760 You cannot modify or delete existing data. 121 00:05:33,760 --> 00:05:35,760 That makes append blobs perfect for logging. 122 00:05:35,760 --> 00:05:37,760 Imagine a web server generating log entries continuously. 123 00:05:37,760 --> 00:05:40,760 Each new log entry depends to the end of the blob. 124 00:05:40,760 --> 00:05:44,760 All the trails work the same way, IoT sensor data too. 125 00:05:44,760 --> 00:05:48,760 Any scenario where data flows in one direction and you never need to go back and change what's already there. 126 00:05:48,760 --> 00:05:50,760 The third type is the page blob. 127 00:05:50,760 --> 00:05:51,760 This one is completely different. 128 00:05:51,760 --> 00:05:56,760 Page blobs are made up of fixed size, 512 byte pages that support random read and write access. 129 00:05:56,760 --> 00:05:59,760 You can jump to any position in the blob and read or write data there. 130 00:05:59,760 --> 00:06:04,760 That matters because page blobs are used as virtual hard disks for Azure virtual machines. 131 00:06:04,760 --> 00:06:07,760 When you create a VM in Azure, the operating system disk is a page blob. 132 00:06:07,760 --> 00:06:09,760 The data disks are page blobs. 133 00:06:09,760 --> 00:06:13,760 It's designed for the kind of random access patterns that operating systems and databases need. 134 00:06:13,760 --> 00:06:15,760 Here is a simple rule to remember. 135 00:06:15,760 --> 00:06:18,760 If it's a file someone uploads or downloads, use a block blob. 136 00:06:18,760 --> 00:06:22,760 If it's a continuous stream of log entries or sensor readings, use an append blob. 137 00:06:22,760 --> 00:06:27,760 If it's a virtual machine disk, use a page blob, three types, three jobs, no confusion. 138 00:06:27,760 --> 00:06:30,760 Access tiers, hot cool cold archive. 139 00:06:30,760 --> 00:06:32,760 Welcome back to another knowledge nugget. 140 00:06:32,760 --> 00:06:35,760 Today we're talking about where your blobs live and how picking the right spot saves you money. 141 00:06:35,760 --> 00:06:38,760 Azure gives you four storage tiers and each one trades off between storage cost and access. 142 00:06:38,760 --> 00:06:40,760 The idea is simple. 143 00:06:40,760 --> 00:06:45,760 Data you touch all the time goes in a tier where reading is cheap even if storing costs a bit more. 144 00:06:45,760 --> 00:06:47,760 Data you almost never need goes somewhere. 145 00:06:47,760 --> 00:06:51,760 Storage is dirt cheap even if reading costs more when you finally pull it up. 146 00:06:51,760 --> 00:06:52,760 First up is hot. 147 00:06:52,760 --> 00:06:53,760 This is the default tier. 148 00:06:53,760 --> 00:06:56,760 Upload a blob without specifying where it goes and it lands here. 149 00:06:56,760 --> 00:07:01,760 Storage costs are highest in hot but transaction costs, the price of reading and writing are lowest. 150 00:07:01,760 --> 00:07:03,760 Hot is for data you grab regularly. 151 00:07:03,760 --> 00:07:07,760 Think customer facing images on a website, active project files or this month's logs. 152 00:07:07,760 --> 00:07:09,760 Anything that needs to pop up instantly. 153 00:07:09,760 --> 00:07:10,760 Next is cool. 154 00:07:10,760 --> 00:07:14,760 Storage costs drop by about 80% compared to hot but transaction costs go up. 155 00:07:14,760 --> 00:07:16,760 Cool is for data you access less than once a month. 156 00:07:16,760 --> 00:07:18,760 Short term backups from last quarter. 157 00:07:18,760 --> 00:07:20,760 Reports you might need to check occasionally. 158 00:07:20,760 --> 00:07:22,760 Files from finished projects that you aren't ready to toss yet. 159 00:07:22,760 --> 00:07:23,760 Then we have cold. 160 00:07:23,760 --> 00:07:27,760 Microsoft added this tier in 2023 and it sits right between cool and archive. 161 00:07:27,760 --> 00:07:30,760 Storage is even cheaper than cool but transactions cost more. 162 00:07:30,760 --> 00:07:33,760 Cold is for data you access every 90 days or so. 163 00:07:33,760 --> 00:07:35,760 Compliance data you keep for a few years. 164 00:07:35,760 --> 00:07:38,760 Historical backups you rarely restore but can't delete. 165 00:07:38,760 --> 00:07:39,760 Last is archive. 166 00:07:39,760 --> 00:07:41,760 This is the cheapest storage as your offers. 167 00:07:41,760 --> 00:07:42,760 Penny's per gigabyte per month. 168 00:07:42,760 --> 00:07:44,760 But here's the catch. 169 00:07:44,760 --> 00:07:45,760 Archive is offline storage. 170 00:07:45,760 --> 00:07:48,760 You can't read a blob while it's sitting in archive. 171 00:07:48,760 --> 00:07:52,760 You have to rehydrate it first which means moving it back to hot cool or cold. 172 00:07:52,760 --> 00:07:54,760 That process takes 2 to 15 hours. 173 00:07:54,760 --> 00:07:57,760 Archive is for data you're legally required to keep but will almost never touch. 174 00:07:57,760 --> 00:08:02,760 All tax records, 10 year old backup tapes, compliance archives that sit untouched until an auditor asks for them. 175 00:08:02,760 --> 00:08:04,760 Think of it like your closet. 176 00:08:04,760 --> 00:08:06,760 Hot is the shirt you wear every week. 177 00:08:06,760 --> 00:08:07,760 Right there, easy to grab. 178 00:08:07,760 --> 00:08:10,760 Cool is the jacket you pull out once a month when the weather turns. 179 00:08:10,760 --> 00:08:12,760 Cold is the formal wear you use a few times a year. 180 00:08:12,760 --> 00:08:14,760 Archive is the winter coat in the attic. 181 00:08:14,760 --> 00:08:15,760 You know it's there. 182 00:08:15,760 --> 00:08:17,760 But getting it out takes some work. 183 00:08:17,760 --> 00:08:19,760 Now here's the cost trap nobody warns you about. 184 00:08:19,760 --> 00:08:21,760 Moving data between tiers cost money. 185 00:08:21,760 --> 00:08:24,760 Every time you change a blob's tier, you pay a transaction fee. 186 00:08:24,760 --> 00:08:28,760 If you shuffle things around every few days, those fees eat up any savings you thought you were getting. 187 00:08:28,760 --> 00:08:31,760 The fixes lifecycle management, which we'll cover next. 188 00:08:31,760 --> 00:08:33,760 But the key takeaway is this. 189 00:08:33,760 --> 00:08:35,760 Pick the right tier for your access pattern and leave it there. 190 00:08:35,760 --> 00:08:38,760 Don't try to game the system by moving things constantly. 191 00:08:38,760 --> 00:08:41,760 Life cycle management automate the tiers. 192 00:08:41,760 --> 00:08:44,760 Manually moving blobs between tiers sounds exhausting doesn't it? 193 00:08:44,760 --> 00:08:46,760 You'd have to track every file. 194 00:08:46,760 --> 00:08:49,760 Remember when you uploaded it and decide when it's time for cheaper storage. 195 00:08:49,760 --> 00:08:50,760 Nobody has time for that. 196 00:08:50,760 --> 00:08:52,760 And honestly, you'd probably forget half the time anyway. 197 00:08:52,760 --> 00:08:56,760 That's exactly why Azure build lifecycle management right into blob storage. 198 00:08:56,760 --> 00:09:00,760 Life cycle management is a rule based engine that lives inside Azure blob storage. 199 00:09:00,760 --> 00:09:03,760 You define the rules and as your handles everything automatically. 200 00:09:03,760 --> 00:09:07,760 It moves blobs between tiers based on age, last modification or last access. 201 00:09:07,760 --> 00:09:10,760 It can even delete blobs when they have outlived their usefulness. 202 00:09:10,760 --> 00:09:11,760 Here's a typical setup. 203 00:09:11,760 --> 00:09:14,760 Say you have a backup system that creates a daily backup file. 204 00:09:14,760 --> 00:09:18,760 You want the last 30 days in hot tier so you can restore quickly if something breaks. 205 00:09:18,760 --> 00:09:21,760 After 30 days, you don't need instant access anymore. 206 00:09:21,760 --> 00:09:23,760 So Azure moves them to cool. 207 00:09:23,760 --> 00:09:27,760 After 90 days, they shift to archive. After 365 days, they get deleted entirely. 208 00:09:27,760 --> 00:09:29,760 That's three rules in a single policy. 209 00:09:29,760 --> 00:09:32,760 If a block blob hasn't been modified in 30 days, move it from hot to cool. 210 00:09:32,760 --> 00:09:36,760 After 90 days, move to archive, delete after 365 days. 211 00:09:36,760 --> 00:09:42,760 Azure runs these rules continuously, scanning your blobs and taking action whenever a blob meets the conditions. 212 00:09:42,760 --> 00:09:47,760 You can scope these rules to specific containers, specific blob types, or even use prefix filters. 213 00:09:47,760 --> 00:09:48,760 Picture this. 214 00:09:48,760 --> 00:09:52,760 You have one container for application logs and another for customer uploads. 215 00:09:52,760 --> 00:09:55,760 You can apply different lifecycle policies to each one. 216 00:09:55,760 --> 00:09:57,760 Logs get archived after 30 days. 217 00:09:57,760 --> 00:10:01,760 Customer uploads stay in hot for a year. There's one gotcha you need to know about. 218 00:10:01,760 --> 00:10:02,760 The billing cycle. 219 00:10:02,760 --> 00:10:07,760 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. 220 00:10:07,760 --> 00:10:10,760 You don't get the hot rate until the next cycle starts. 221 00:10:10,760 --> 00:10:14,760 This is Azure's way of stopping people from gaming the system by moving blobs around constantly. 222 00:10:14,760 --> 00:10:16,760 So don't micromanage. Set your rules and let them run. 223 00:10:16,760 --> 00:10:19,760 Best practice is to enable last access time tracking. 224 00:10:19,760 --> 00:10:23,760 By default, lifecycle rules can use creation time or last modified time. 225 00:10:23,760 --> 00:10:26,760 But last access time gives you much more accurate rules. 226 00:10:26,760 --> 00:10:30,760 If a blob hasn't been accessed in 30 days, it's probably safe to move to cool. 227 00:10:30,760 --> 00:10:33,760 If it hasn't been accessed in 180 days, archive it. 228 00:10:33,760 --> 00:10:38,760 This way, blobs that are rarely accessed but still important don't get moved to cold storage too early. 229 00:10:38,760 --> 00:10:41,760 For advanced setups, Azure also offers storage actions. 230 00:10:41,760 --> 00:10:46,760 This newer feature lets you orchestrate lifecycle management across multiple storage accounts and even across regions. 231 00:10:46,760 --> 00:10:48,760 It's security and access control. 232 00:10:48,760 --> 00:10:52,760 Now that you know how to store and manage blobs, let's talk about who gets to see them. 233 00:10:52,760 --> 00:10:56,760 Because storing data in the cloud means nothing if anyone can walk right in. 234 00:10:56,760 --> 00:10:58,760 You have two main ways to control access. 235 00:10:58,760 --> 00:11:00,760 First is shared key authorization. 236 00:11:00,760 --> 00:11:02,760 Your storage account comes with two access keys. 237 00:11:02,760 --> 00:11:05,760 If you have the key, you have full access to everything. 238 00:11:05,760 --> 00:11:07,760 Every container, every blob, every operation. 239 00:11:07,760 --> 00:11:10,760 Think of it like having a master key to the whole building. 240 00:11:10,760 --> 00:11:13,760 Powerful but dangerous if the wrong person gets their hands on it. 241 00:11:13,760 --> 00:11:17,760 The second approach is shared access signatures or SAS tokens. 242 00:11:17,760 --> 00:11:26,760 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. 243 00:11:26,760 --> 00:11:28,760 Read only, write only or both. 244 00:11:28,760 --> 00:11:34,760 The URL looks like a normal blob URL with a long string of characters at the end and that string is the token itself. 245 00:11:34,760 --> 00:11:38,760 SAS tokens are perfect for temporary access. Say you want to let a customer download a large file. 246 00:11:38,760 --> 00:11:44,760 You generate a SAS token that expires in 24 hours and only allows read access, then send them the URL. 247 00:11:44,760 --> 00:11:48,760 After 24 hours, the token expires and they can't access the file anymore. 248 00:11:48,760 --> 00:11:52,760 You don't have to change any passwords or revoke any permissions. It just stops working. 249 00:11:52,760 --> 00:11:56,760 But today, the recommendation is to move away from keys and SAS tokens entirely. 250 00:11:56,760 --> 00:12:00,760 Instead, use Microsoft EntryD with Azure R-Back, Roll-Based Access Control. 251 00:12:00,760 --> 00:12:04,760 You assign roles to users, groups or applications. 252 00:12:04,760 --> 00:12:08,760 For example, the storage blob data reader role lets someone read but not write or delete. 253 00:12:08,760 --> 00:12:11,760 The contributor role lets them read and write. 254 00:12:11,760 --> 00:12:14,760 And the owner role gives full control. Here's why this is better. 255 00:12:14,760 --> 00:12:17,760 EntryID integrates with everything else in Azure. 256 00:12:17,760 --> 00:12:21,760 You can use the same identity system for storage, databases, virtual machines and applications. 257 00:12:21,760 --> 00:12:26,760 You don't have to manage separate keys for every service and you can audit who accessed what and when. 258 00:12:26,760 --> 00:12:28,760 Network security gives you another layer. 259 00:12:28,760 --> 00:12:34,760 You can configure firewalls on your storage account to only allow traffic from specific IP addresses or virtual networks. 260 00:12:34,760 --> 00:12:37,760 You can use service endpoints to secure traffic from Azure services. 261 00:12:37,760 --> 00:12:43,760 And for the highest level of security, private endpoints give your storage account a private IP address inside your virtual network. 262 00:12:43,760 --> 00:12:46,760 Traffic never leaves the Azure backbone. 263 00:12:46,760 --> 00:12:49,760 It's like having a direct fiber connection from your application to your storage. 264 00:12:49,760 --> 00:12:51,760 Encryption is handled automatically. 265 00:12:51,760 --> 00:12:55,760 All data address is encrypted by default using Azure Managed Keys. 266 00:12:55,760 --> 00:12:58,760 If you need more control, you can bring your own keys using Azure Key Vault. 267 00:12:58,760 --> 00:13:01,760 You manage the keys and Azure uses them for encryption. 268 00:13:01,760 --> 00:13:05,760 This is often required for compliance with regulations like HIPAA or PCI DSS. 269 00:13:05,760 --> 00:13:07,760 SoftDelete is a safety net. 270 00:13:07,760 --> 00:13:09,760 If someone accidentally deletes a blob, it's not gone forever. 271 00:13:09,760 --> 00:13:15,760 By default, those blobs stick around for seven days and you can configure that up to 365 days. 272 00:13:15,760 --> 00:13:17,760 During that time, you can recover the blob with a single click. 273 00:13:17,760 --> 00:13:19,760 It's like a recycle bin for your cloud storage. 274 00:13:19,760 --> 00:13:22,760 For the most sensitive data, there's immutable storage, also called worm storage. 275 00:13:22,760 --> 00:13:24,760 Right once read many. 276 00:13:24,760 --> 00:13:31,760 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. 277 00:13:31,760 --> 00:13:36,760 This is critical for compliance scenarios where you need to prove that records haven't been tampered with. 278 00:13:36,760 --> 00:13:38,760 Redundancy and durability. 279 00:13:38,760 --> 00:13:41,760 If Azure loses a data center, redundancy is what protects you. 280 00:13:41,760 --> 00:13:44,760 Most people don't think about this until it's too late. 281 00:13:44,760 --> 00:13:48,760 Every blob you store is copied three times synchronously within at least one data center. 282 00:13:48,760 --> 00:13:49,760 That's the baseline. 283 00:13:49,760 --> 00:13:51,760 Three copies written at the same moment. 284 00:13:51,760 --> 00:13:53,760 If one copy fails, the other two are still there. 285 00:13:53,760 --> 00:13:57,760 But where those three copies live depends on the redundancy option you choose. 286 00:13:57,760 --> 00:14:00,760 The first option is LRS locally redundant storage. 287 00:14:00,760 --> 00:14:02,760 Three copies in a single data center. 288 00:14:02,760 --> 00:14:04,760 It's the cheapest option and the least durable. 289 00:14:04,760 --> 00:14:07,760 If that data center burns down or floods, you lose all three copies. 290 00:14:07,760 --> 00:14:15,760 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. 291 00:14:15,760 --> 00:14:18,760 The second option is ZRS zone redundant storage. 292 00:14:18,760 --> 00:14:22,760 Three copies spread across three different availability zones within the same region. 293 00:14:22,760 --> 00:14:26,760 Think of availability zones as separate data centers with their own power, cooling and networking. 294 00:14:26,760 --> 00:14:31,760 If one data center fails, the other two keep running, so ZRS protects against data center level failures. 295 00:14:31,760 --> 00:14:35,760 If you're running production workloads in a single region, ZRS is your baseline. 296 00:14:35,760 --> 00:14:40,760 The third option is GRS, geo-redundant storage and this one works differently. 297 00:14:40,760 --> 00:14:42,760 You get LRS in your primary region. 298 00:14:42,760 --> 00:14:44,760 Three copies in one data center. 299 00:14:44,760 --> 00:14:49,760 Then Azure asynchronously copies that data to a paired region where it stores three more copies using LRS. 300 00:14:49,760 --> 00:14:52,760 So you end up with six copies total spread across two regions. 301 00:14:52,760 --> 00:14:55,760 The catch is that the A sync replication can have up to 15 minutes of delay. 302 00:14:55,760 --> 00:14:59,760 If a disaster hits during that window, you might lose the most recent changes. 303 00:14:59,760 --> 00:15:02,760 The fourth option is GZRS, geo-zone redundant storage. 304 00:15:02,760 --> 00:15:06,760 This combines ZRS in the primary region with LRS in the secondary region. 305 00:15:06,760 --> 00:15:09,760 You get zone redundancy locally and geo-redundancy globally. 306 00:15:09,760 --> 00:15:12,760 It's the most durable option as your offers. 307 00:15:12,760 --> 00:15:17,760 And if you enable read access like RAGRS or RAGRS, you can read from the secondary region 308 00:15:17,760 --> 00:15:19,760 even during normal operations. 309 00:15:19,760 --> 00:15:21,760 That means zero downtime during a regional failure. 310 00:15:21,760 --> 00:15:23,760 So here's a simple rule of thumb. 311 00:15:23,760 --> 00:15:25,760 You get LRS for dev and test. 312 00:15:25,760 --> 00:15:27,760 ZRS for production in a single region. 313 00:15:27,760 --> 00:15:29,760 GZRS for mission critical applications. 314 00:15:29,760 --> 00:15:31,760 Where downtime is not an option. 315 00:15:31,760 --> 00:15:34,760 And remember redundancy protects your data, not your application. 316 00:15:34,760 --> 00:15:37,760 You still need to design your application to handle failures gracefully. 317 00:15:37,760 --> 00:15:39,760 Real-world use cases. 318 00:15:39,760 --> 00:15:42,760 All right, let's talk about where blob storage actually shows up in the real world. 319 00:15:42,760 --> 00:15:44,760 These aren't theory exercises. 320 00:15:44,760 --> 00:15:47,760 These are the jobs Azure customers give it every day. 321 00:15:47,760 --> 00:15:49,760 First up, backup and disaster recovery. 322 00:15:49,760 --> 00:15:52,760 This is probably the most common reason people start using blob storage. 323 00:15:52,760 --> 00:15:57,760 VM backups, database dumps, file shares, anything you need to bring back to life after a failure. 324 00:15:57,760 --> 00:16:02,760 Those lifecycle rules we talked about, they automatically move old backups to cool and then to archive. 325 00:16:02,760 --> 00:16:06,760 So your most recent backups are instantly accessible and your year old backups cost pennies to store. 326 00:16:06,760 --> 00:16:07,760 That's a win. 327 00:16:07,760 --> 00:16:09,760 Next, media and content distribution. 328 00:16:09,760 --> 00:16:14,760 If you host images, videos or documents, blob storage is the place to put them. 329 00:16:14,760 --> 00:16:19,760 Parade with Azure CDN or Azure Front Door and a user in Tokyo gets served from a server in Tokyo, 330 00:16:19,760 --> 00:16:24,760 not from your storage account in Virginia, fast delivery, low latency, minimal egress costs. 331 00:16:24,760 --> 00:16:25,760 Simple. 332 00:16:25,760 --> 00:16:27,760 Now let's talk data lakes and analytics. 333 00:16:27,760 --> 00:16:30,760 Azure Data Lake Storage, JN2 is built directly on top of blob storage. 334 00:16:30,760 --> 00:16:34,760 It adds a hierarchical namespace and Hadoop compatible file system semantics. 335 00:16:34,760 --> 00:16:37,760 That's what powers Azure Synapse, Databricks and Power BI at scale. 336 00:16:37,760 --> 00:16:42,760 We're talking petabytes of data, trillions of files and analytics queries that run in seconds. 337 00:16:42,760 --> 00:16:44,760 AI training data is another big one. 338 00:16:44,760 --> 00:16:47,760 If you're training machine learning models, you need massive amounts of data. 339 00:16:47,760 --> 00:16:52,760 Terabytes of images, text files, training checkpoints, blob storage handles this at exabyte scale. 340 00:16:52,760 --> 00:16:55,760 The premium tier gives you single digit millisecond latency. 341 00:16:55,760 --> 00:16:58,760 Blobfuse lets you mount containers as local file systems. 342 00:16:58,760 --> 00:17:00,760 And the throughput keeps GPU clusters fully utilized. 343 00:17:00,760 --> 00:17:02,760 It's built for the heavy lifting. 344 00:17:02,760 --> 00:17:04,760 Finally, log storage. 345 00:17:04,760 --> 00:17:09,760 Append blobs are perfect for streaming logs, application telemetry and IoT sensor data. 346 00:17:09,760 --> 00:17:11,760 Each new entry gets appended to the end. 347 00:17:11,760 --> 00:17:12,760 You never modify existing data. 348 00:17:12,760 --> 00:17:16,760 And lifecycle rules automatically archive or delete old logs based on your retention policy. 349 00:17:16,760 --> 00:17:18,760 Set it and forget it. 350 00:17:18,760 --> 00:17:21,760 So every use case maps to a different blob type and tier. 351 00:17:21,760 --> 00:17:23,760 Backups use block blobs and cooler archive. 352 00:17:23,760 --> 00:17:25,760 Media uses block blobs in hot with CDN. 353 00:17:25,760 --> 00:17:28,760 Data lakes use block blobs with hierarchical namespace. 354 00:17:28,760 --> 00:17:30,760 AI training uses block blobs and premium. 355 00:17:30,760 --> 00:17:32,760 Logs use append blobs in hot then cool. 356 00:17:32,760 --> 00:17:34,760 That flexibility is the killer feature. 357 00:17:34,760 --> 00:17:37,760 All right, here's what we covered today in plain English. 358 00:17:37,760 --> 00:17:40,760 Blob storage is flat, scalable object storage for unstructured data. 359 00:17:40,760 --> 00:17:43,760 You organize it in accounts, containers and blobs. 360 00:17:43,760 --> 00:17:45,760 Three blob types handle different jobs. 361 00:17:45,760 --> 00:17:49,760 Block for general files, append for logs, page for VM disks. 362 00:17:49,760 --> 00:17:52,760 Four access tiers let you match cost to how often you access data. 363 00:17:52,760 --> 00:17:54,760 Life cycle management automates the movement. 364 00:17:54,760 --> 00:17:59,760 And security and redundancy give you control over who sees your data and how safe it is. 365 00:17:59,760 --> 00:18:00,760 Here's your homework. 366 00:18:00,760 --> 00:18:03,760 Next time you need to store a file in the cloud, ask yourself one question. 367 00:18:03,760 --> 00:18:06,760 Is this data frequently accessed or rarely touched? 368 00:18:06,760 --> 00:18:10,760 That single question tells you which tier to use and saves you money from day one. 369 00:18:10,760 --> 00:18:11,760 Ready to go deeper. 370 00:18:11,760 --> 00:18:14,760 Next episode will compare Azure files and blob storage. 371 00:18:14,760 --> 00:18:17,760 Two services that look similar but solve completely different problems. 372 00:18:17,760 --> 00:18:19,760 Subscribe so you don't miss it. 373 00:18:19,760 --> 00:18:21,760 Your files don't need to be scary. 374 00:18:21,760 --> 00:18:23,760 Azure blob storage makes them simple.