Azure Blob Storage - Simply Explained

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.