Azure Managed Disks - Simply Explained

1
00:00:00,000 --> 00:00:03,440
Most people think a virtual machine in Azure just needs a disk.

2
00:00:03,440 --> 00:00:05,600
You pick a size, you attach it, and you're done.

3
00:00:05,600 --> 00:00:08,960
But the wrong disk can cost you performance or money, sometimes both.

4
00:00:08,960 --> 00:00:12,400
And here's the thing, most beginners don't even know they have a choice.

5
00:00:12,400 --> 00:00:15,440
Before managed disks existed, the old way was a real hassle.

6
00:00:15,440 --> 00:00:18,840
You had to create a storage account yourself, then create a page blob inside it,

7
00:00:18,840 --> 00:00:20,760
then attach that blob to your VM.

8
00:00:20,760 --> 00:00:22,520
And you were responsible for everything.

9
00:00:22,520 --> 00:00:25,160
The storage account limits the performance, the replication,

10
00:00:25,160 --> 00:00:27,280
hit a limit, and your VM slowed down.

11
00:00:27,280 --> 00:00:28,920
If you didn't plan your storage accounts, right?

12
00:00:28,920 --> 00:00:30,520
You'd have to reshuffle everything.

13
00:00:30,520 --> 00:00:32,040
Managed disks fixed all of that.

14
00:00:32,040 --> 00:00:35,600
By the end of this episode, you'll understand what managed disks actually are,

15
00:00:35,600 --> 00:00:39,840
the five main types Azure offers, and how to choose the right one for your workload.

16
00:00:39,840 --> 00:00:41,640
So let's start with the simplest question.

17
00:00:41,640 --> 00:00:43,600
What exactly is a managed disk?

18
00:00:43,600 --> 00:00:44,800
What is a managed disk?

19
00:00:44,800 --> 00:00:46,160
The problem it solves.

20
00:00:46,160 --> 00:00:49,680
A managed disk is a block level storage volume that as your creates,

21
00:00:49,680 --> 00:00:51,480
manages, and replicates for you.

22
00:00:51,480 --> 00:00:52,680
That's the official definition.

23
00:00:52,680 --> 00:00:53,800
But what does it actually mean?

24
00:00:53,800 --> 00:00:57,680
Before managed disks, every time you wanted to attach storage to a virtual machine,

25
00:00:57,680 --> 00:01:00,360
you had to go through a whole process, you'd create a storage account,

26
00:01:00,360 --> 00:01:02,440
a separate Azure resource with its own limits,

27
00:01:02,440 --> 00:01:05,720
then you'd create a container inside it, then a page blob inside that container,

28
00:01:05,720 --> 00:01:07,920
then you'd attach that page blob to your VM,

29
00:01:07,920 --> 00:01:10,080
and you had to keep track of which storage account held,

30
00:01:10,080 --> 00:01:13,240
which disk because each account had caps on IOPS and throughput,

31
00:01:13,240 --> 00:01:16,000
go over those caps, and your application would throttle.

32
00:01:16,000 --> 00:01:18,400
So you'd end up spreading disks across multiple storage accounts

33
00:01:18,400 --> 00:01:19,840
just to avoid hitting limits.

34
00:01:19,840 --> 00:01:22,640
It was manual, error-prone, and it did not scale.

35
00:01:22,640 --> 00:01:25,000
Managed disks abstract all of that away.

36
00:01:25,000 --> 00:01:27,720
You don't create a storage account, a container, or a page blob.

37
00:01:27,720 --> 00:01:31,960
You just create a disk, pick a size, and a type, and Azure handles the rest.

38
00:01:31,960 --> 00:01:34,360
The storage account still exists behind the scenes,

39
00:01:34,360 --> 00:01:38,000
but you never see it, never manage it, and never worry about its limits.

40
00:01:38,000 --> 00:01:40,840
One of the biggest benefits is higher availability.

41
00:01:40,840 --> 00:01:42,280
When you create a managed disk,

42
00:01:42,280 --> 00:01:44,520
Azure places it on a storage scale unit.

43
00:01:44,520 --> 00:01:47,360
That's a cluster of storage service inside a data center.

44
00:01:47,360 --> 00:01:50,360
And it spreads your disks across different scale units automatically.

45
00:01:50,360 --> 00:01:53,880
So if one storage cluster has an issue, it doesn't take down all your disks.

46
00:01:53,880 --> 00:01:57,880
With unmanaged disks, if you put multiple VMs on the same storage account,

47
00:01:57,880 --> 00:01:59,680
a single failure could affect all of them.

48
00:01:59,680 --> 00:02:01,200
Managed disks prevent that.

49
00:02:01,200 --> 00:02:02,000
They also scale.

50
00:02:02,000 --> 00:02:05,400
You can have up to 50,000 managed disks per subscription per region.

51
00:02:05,400 --> 00:02:06,480
That's a lot of storage.

52
00:02:06,480 --> 00:02:11,040
Think of it like moving from managing your own file server to using a cloud file service.

53
00:02:11,040 --> 00:02:13,280
With the file server, you're responsible for the hardware,

54
00:02:13,280 --> 00:02:15,160
the drives, the backups, the network.

55
00:02:15,160 --> 00:02:18,160
With the cloud service, you just put your files there and it works.

56
00:02:18,160 --> 00:02:22,280
Managed disks are the same idea, less work, more reliability.

57
00:02:22,280 --> 00:02:23,520
Now that you know what they are,

58
00:02:23,520 --> 00:02:26,280
let's look at the different flavors Azure offers.

59
00:02:26,280 --> 00:02:30,640
The premium performance disks, ultra premium SSD V2 premium SSD.

60
00:02:30,640 --> 00:02:33,080
Azure gives you five disk types to choose from.

61
00:02:33,080 --> 00:02:36,880
Today, we're focusing on the fast ones, the premium performance disks.

62
00:02:36,880 --> 00:02:38,240
Let's start with ultra disk.

63
00:02:38,240 --> 00:02:40,280
It's the fastest disk Azure has.

64
00:02:40,280 --> 00:02:44,480
We're talking up to 400,000 IOPS and sub millisecond latency.

65
00:02:44,480 --> 00:02:46,560
That kind of speed is for extreme workloads,

66
00:02:46,560 --> 00:02:51,000
large databases, SAP HANA, anything that needs every bit of performance it can get.

67
00:02:51,000 --> 00:02:53,040
But here's the thing, there are trade-offs.

68
00:02:53,040 --> 00:02:56,560
Ultra disk only supports locally redundant storage or LRS.

69
00:02:56,560 --> 00:03:00,200
You can't get zone redundancy because the latency demands are so tight

70
00:03:00,200 --> 00:03:03,360
that replicating across zones would add too much delay.

71
00:03:03,360 --> 00:03:05,920
And you pay separately for capacity IOPS and throughput.

72
00:03:05,920 --> 00:03:08,680
That gives you fine-grained control, but you have to watch the cost.

73
00:03:08,680 --> 00:03:10,880
Next up is premium SSD V2,

74
00:03:10,880 --> 00:03:13,560
which is the sweet spot for most performance hungry applications.

75
00:03:13,560 --> 00:03:17,680
It goes up to 80,000 IOPS and 2,000 MB per second of throughput.

76
00:03:17,680 --> 00:03:19,840
But the real advantage is how performance works.

77
00:03:19,840 --> 00:03:21,640
It's decoupled from capacity.

78
00:03:21,640 --> 00:03:23,520
You can set each dial independently.

79
00:03:23,520 --> 00:03:26,200
One 10,000 IOPS on 100 gigabyte disk, no problem.

80
00:03:26,200 --> 00:03:29,640
One 50,000 IOPS on a 500 gigabyte disk, also fine.

81
00:03:29,640 --> 00:03:32,920
That means you don't have to over-provision storage just to get more IOPS.

82
00:03:32,920 --> 00:03:35,320
With older disk types, if you needed more performance,

83
00:03:35,320 --> 00:03:36,720
you had to buy a bigger disk.

84
00:03:36,720 --> 00:03:38,400
Even if you didn't need the extra space.

85
00:03:38,400 --> 00:03:40,240
Premium SSD V2 fixes that,

86
00:03:40,240 --> 00:03:44,120
and it's generally less expensive than the original premium SSD for the same performance.

87
00:03:44,120 --> 00:03:46,000
Then there's the original premium SSD.

88
00:03:46,000 --> 00:03:47,760
It's older but still widely used.

89
00:03:47,760 --> 00:03:49,800
Performance is tied to disk size.

90
00:03:49,800 --> 00:03:52,440
Bigger disk means more IOPS in throughput.

91
00:03:52,440 --> 00:03:54,480
So if you need 5,000 IOPS,

92
00:03:54,480 --> 00:03:57,080
you might have to buy a 500 gigabyte disk,

93
00:03:57,080 --> 00:03:59,400
even if you only need 100 gigabytes of space.

94
00:03:59,400 --> 00:04:00,680
That's the main downside.

95
00:04:00,680 --> 00:04:01,640
But here's a neat trick.

96
00:04:01,640 --> 00:04:04,920
You can change the performance tier without changing the disk size.

97
00:04:04,920 --> 00:04:07,000
So if you need a temporary boost for a batch job,

98
00:04:07,000 --> 00:04:09,440
you can bump up the tier and then drop it back down when you're done,

99
00:04:09,440 --> 00:04:10,400
with no downtime.

100
00:04:10,400 --> 00:04:12,960
That's useful for enterprise apps that need predictable IOPS,

101
00:04:12,960 --> 00:04:14,480
but have occasional spikes.

102
00:04:14,480 --> 00:04:17,000
The big difference between these three is control.

103
00:04:17,000 --> 00:04:21,400
Ultra-disk and premium SSD V2 let you dial in exactly the performance you need.

104
00:04:21,400 --> 00:04:22,920
Premium SSD is simpler.

105
00:04:22,920 --> 00:04:26,640
Pick a size, get the performance that comes with it, but less flexible.

106
00:04:26,640 --> 00:04:28,920
But not every workload needs lightning speed.

107
00:04:28,920 --> 00:04:34,080
For everyday tasks, the standard disks are perfectly fine and much cheaper.

108
00:04:34,080 --> 00:04:37,800
The cost-effective disks, standard SSD and standard HDD.

109
00:04:37,800 --> 00:04:40,200
So what about the rest of us who aren't running SAP HANA?

110
00:04:40,200 --> 00:04:42,520
Azure has you covered with two cost-effective options.

111
00:04:42,520 --> 00:04:44,800
Standard SSD is like the SSD in your laptop.

112
00:04:44,800 --> 00:04:45,800
It's solid state.

113
00:04:45,800 --> 00:04:51,760
So it's fast up to 6000 IOPS and 750 Mbps, but it's significantly cheaper than any premium

114
00:04:51,760 --> 00:04:52,760
option.

115
00:04:52,760 --> 00:04:56,680
Use this for web servers, dev and test environments, or line-of-business apps that don't

116
00:04:56,680 --> 00:04:59,000
need sub-milly second response times.

117
00:04:59,000 --> 00:05:03,320
You get SSD speeds without the premium price tag, then there's standard HDD, a traditional

118
00:05:03,320 --> 00:05:04,320
spinning hard drive.

119
00:05:04,320 --> 00:05:05,800
It's the slowest option.

120
00:05:05,800 --> 00:05:10,200
Up to 2,000 IOPS and 500 Mbps, but it's also the cheapest.

121
00:05:10,200 --> 00:05:14,000
Use it for backups, archive storage, or any workload that doesn't need high input and

122
00:05:14,000 --> 00:05:15,000
output.

123
00:05:15,000 --> 00:05:18,440
If you're offering logs you access once a month, perfect, putting a database on it, you'll

124
00:05:18,440 --> 00:05:20,720
regret it.

125
00:05:20,720 --> 00:05:22,520
Both use consumption-based pricing.

126
00:05:22,520 --> 00:05:24,240
You pay for provisioned capacity.

127
00:05:24,240 --> 00:05:25,960
Each has a service level agreement.

128
00:05:25,960 --> 00:05:28,440
Standard HDD offers 95% uptime.

129
00:05:28,440 --> 00:05:30,720
Standard SSD offers 99.5%.

130
00:05:30,720 --> 00:05:32,720
Premium disks go up to 99.9%.

131
00:05:32,720 --> 00:05:34,200
Here's a simple rule of thumb.

132
00:05:34,200 --> 00:05:39,080
If your workload is latency-sensitive, meaning even a few milliseconds matter, go premium.

133
00:05:39,080 --> 00:05:43,000
If you just need cheap storage for things you rarely access, go standard HDD.

134
00:05:43,000 --> 00:05:46,640
If you're in the middle, standard SSD is the best all-rounder for budget-conscious production

135
00:05:46,640 --> 00:05:47,640
workloads.

136
00:05:47,640 --> 00:05:49,960
How do you know how many IOPS and how much throughput you need?

137
00:05:49,960 --> 00:05:50,960
That's coming up next.

138
00:05:50,960 --> 00:05:53,280
We'll break down how disk performance actually works.

139
00:05:53,280 --> 00:05:54,760
How disk performance works?

140
00:05:54,760 --> 00:05:56,840
IOPS, throughput, and latency.

141
00:05:56,840 --> 00:05:58,480
Let's talk about disk performance.

142
00:05:58,480 --> 00:05:59,760
Three numbers matter.

143
00:05:59,760 --> 00:06:02,240
IOPS, throughput, and latency.

144
00:06:02,240 --> 00:06:06,080
IOPS stands for input/output operations per second.

145
00:06:06,080 --> 00:06:10,000
It tells you how many small, read or write operations the disk can handle each second.

146
00:06:10,000 --> 00:06:11,400
This is what databases care about.

147
00:06:11,400 --> 00:06:15,280
When a database runs a query, it's doing lots of tiny random reads and writes.

148
00:06:15,280 --> 00:06:17,520
You need high IOPS for that kind of work.

149
00:06:17,520 --> 00:06:18,520
Thruput is different.

150
00:06:18,520 --> 00:06:20,240
It's measured in megabytes per second.

151
00:06:20,240 --> 00:06:22,560
How much data the disk can move in a given time?

152
00:06:22,560 --> 00:06:26,640
If you're streaming video, transferring large files, or doing any workload that reads

153
00:06:26,640 --> 00:06:30,440
or writes big chunks of data sequentially, you need high throughput.

154
00:06:30,440 --> 00:06:31,440
Then there's latency.

155
00:06:31,440 --> 00:06:34,480
That's the delay between sending a request and getting a response.

156
00:06:34,480 --> 00:06:36,640
Ultra disks give you under half a millisecond.

157
00:06:36,640 --> 00:06:38,760
Standard HDD can hit tens of milliseconds.

158
00:06:38,760 --> 00:06:39,760
That's a huge difference.

159
00:06:39,760 --> 00:06:41,760
Here's a detail that trips people up.

160
00:06:41,760 --> 00:06:46,240
With premium SSD V2 and ultra disks, you set IOPS and throughput independently.

161
00:06:46,240 --> 00:06:48,760
You decide exactly what you need and pay only for that.

162
00:06:48,760 --> 00:06:53,600
But with older premium SSD and standard disks, IOPS and throughput scale with disk size,

163
00:06:53,600 --> 00:06:56,400
bigger disk means more performance built in.

164
00:06:56,400 --> 00:06:58,000
Now a lot of people miss this.

165
00:06:58,000 --> 00:06:59,080
Some disks can burst.

166
00:06:59,080 --> 00:07:03,200
If you normally run at a lower performance level but need a short spike, say during a monthly

167
00:07:03,200 --> 00:07:07,360
report, the disk can temporarily deliver higher IOPS or throughput.

168
00:07:07,360 --> 00:07:10,520
It's built into certain disk sizes, no configuration needed.

169
00:07:10,520 --> 00:07:11,520
It just happens.

170
00:07:11,520 --> 00:07:13,040
But here's the most important thing.

171
00:07:13,040 --> 00:07:15,640
The VM itself has IOPS and throughput limits too.

172
00:07:15,640 --> 00:07:19,680
You can attach 10 ultra disks to a small VM but the VM can only push so much data.

173
00:07:19,680 --> 00:07:20,840
The disks will be waiting.

174
00:07:20,840 --> 00:07:23,840
So always check your VM size limits before adding disks.

175
00:07:23,840 --> 00:07:26,200
Don't attach more than the VM can handle.

176
00:07:26,200 --> 00:07:28,720
Performance is one thing, but durability is another.

177
00:07:28,720 --> 00:07:31,160
Let's see how Azure protects your data.

178
00:07:31,160 --> 00:07:32,360
Redundancy options.

179
00:07:32,360 --> 00:07:35,800
LRS, ZRS and what they mean for your data.

180
00:07:35,800 --> 00:07:40,240
Every managed disk lives on an Azure storage cluster, a group of servers inside a data center

181
00:07:40,240 --> 00:07:42,480
that work together to store your data.

182
00:07:42,480 --> 00:07:45,920
Azure automatically keeps three copies of your data in that same data center.

183
00:07:45,920 --> 00:07:48,920
We call that locally redundant storage, or LRS.

184
00:07:48,920 --> 00:07:52,680
It protects you against a single disk failure or a single server failure.

185
00:07:52,680 --> 00:07:56,880
Microsoft guarantees 99.99999% durability.

186
00:07:56,880 --> 00:07:59,320
Practically speaking, your data is not going to disappear.

187
00:07:59,320 --> 00:08:01,400
But what if the entire data center goes down?

188
00:08:01,400 --> 00:08:04,240
That's where zone redundant storage or ZRS comes in.

189
00:08:04,240 --> 00:08:08,760
And ZRS, as your keeps three copies of your data spread across different availability zones

190
00:08:08,760 --> 00:08:12,960
in the same region, each zone is a physically separate data center with its own power cooling

191
00:08:12,960 --> 00:08:13,960
and network.

192
00:08:13,960 --> 00:08:16,440
So if one zone fails, your data is still safe in the other two.

193
00:08:16,440 --> 00:08:18,000
That gives you 12 nines of durability.

194
00:08:18,000 --> 00:08:19,000
There's a catch.

195
00:08:19,000 --> 00:08:22,280
Ultra disks and premium SSDV2 only support LRS.

196
00:08:22,280 --> 00:08:23,280
The reason is latency.

197
00:08:23,280 --> 00:08:26,880
To replicate data across availability zones, you need to send it over fiber between data

198
00:08:26,880 --> 00:08:27,880
centers.

199
00:08:27,880 --> 00:08:31,520
That adds a few milliseconds of delay for ultra disks, which promise sub millisecond

200
00:08:31,520 --> 00:08:33,360
latency, that's a deal breaker.

201
00:08:33,360 --> 00:08:36,920
So choosing between LRS and ZRS comes down to cost versus availability.

202
00:08:36,920 --> 00:08:40,440
ZRS costs more, but it keeps you running even if an entire zone goes down.

203
00:08:40,440 --> 00:08:42,360
For most workloads, LRS is fine.

204
00:08:42,360 --> 00:08:45,480
For mission critical systems, ZRS is worth the extra cost.

205
00:08:45,480 --> 00:08:46,480
One more thing.

206
00:08:46,480 --> 00:08:48,640
There's no georedundancy for managed disks.

207
00:08:48,640 --> 00:08:51,640
Azure doesn't automatically replicate your disk data to another region.

208
00:08:51,640 --> 00:08:56,400
If you need disaster recovery across regions, say your primary region goes down and you

209
00:08:56,400 --> 00:09:00,200
want to spin up VMs in a secondary region, you have to handle that yourself.

210
00:09:00,200 --> 00:09:04,580
You can replicate snapshots to another region or use Azure backup to store copies in a recovery

211
00:09:04,580 --> 00:09:05,820
services vault.

212
00:09:05,820 --> 00:09:06,920
But it's not automatic.

213
00:09:06,920 --> 00:09:10,160
Now let's look at the roles disks play inside a virtual machine.

214
00:09:10,160 --> 00:09:12,920
OS disk, data disk, and temporary disk.

215
00:09:12,920 --> 00:09:14,440
What's the difference?

216
00:09:14,440 --> 00:09:17,920
Every virtual machine in Azure comes with at least one disk, the OS disk.

217
00:09:17,920 --> 00:09:19,880
That's where Windows or Linux lives.

218
00:09:19,880 --> 00:09:21,200
On Windows, it's the C drive.

219
00:09:21,200 --> 00:09:22,880
On Linux, it's our dev SDA.

220
00:09:22,880 --> 00:09:26,080
You can't remove it while the VM is running because it's the disk the machine boots

221
00:09:26,080 --> 00:09:27,240
from.

222
00:09:27,240 --> 00:09:31,480
But you can add more storage with data disks, attach them for applications, databases,

223
00:09:31,480 --> 00:09:35,480
files, anything you want separate from the operating system.

224
00:09:35,480 --> 00:09:38,760
Depending on your VM size, you can attach up to 64 data disks.

225
00:09:38,760 --> 00:09:39,880
That's a lot of storage.

226
00:09:39,880 --> 00:09:43,040
Then there's the temporary disk and this one trips people up.

227
00:09:43,040 --> 00:09:44,840
On Windows, it's usually the D drive.

228
00:09:44,840 --> 00:09:47,000
On Linux, it's flash dev such as DB1.

229
00:09:47,000 --> 00:09:48,520
Think of it like a whiteboard.

230
00:09:48,520 --> 00:09:51,240
Fast to write on, but everything wipes clean when the VM stops.

231
00:09:51,240 --> 00:09:54,720
The temporary disk lives on the host server itself, the physical machine running your VM,

232
00:09:54,720 --> 00:09:56,800
so it's incredibly fast because it's local.

233
00:09:56,800 --> 00:09:57,800
But it's not persistent.

234
00:09:57,800 --> 00:10:01,680
When you stop or redeploy your VM, everything on that temporary disk disappears as your

235
00:10:01,680 --> 00:10:03,040
uses it for swap files.

236
00:10:03,040 --> 00:10:07,200
You can use it for page files or SQL server temp DB, but never store anything important

237
00:10:07,200 --> 00:10:08,200
there.

238
00:10:08,200 --> 00:10:10,080
If your VM moves to a different host, that data is gone.

239
00:10:10,080 --> 00:10:13,160
There's also a special option called a femoral OS disks.

240
00:10:13,160 --> 00:10:16,280
Normally, your OS disk is a managed disk that persists.

241
00:10:16,280 --> 00:10:20,520
But for workloads like Azure Kubernetes service nodes or virtual machine scale sets, you're

242
00:10:20,520 --> 00:10:22,640
constantly creating and destroying VMs.

243
00:10:22,640 --> 00:10:24,120
You don't care about the OS state.

244
00:10:24,120 --> 00:10:28,000
So you can use an a femoral OS disk that lives on temporary storage instead.

245
00:10:28,000 --> 00:10:31,240
Fast to deploy cheaper because there's no managed disk charge.

246
00:10:31,240 --> 00:10:35,240
And when the VM goes away, the OS disk goes with it perfect for stateless workloads.

247
00:10:35,240 --> 00:10:37,360
Now how does Azure protect your managed disks?

248
00:10:37,360 --> 00:10:39,840
Let's talk security, security and encryption.

249
00:10:39,840 --> 00:10:40,840
Here's the good news.

250
00:10:40,840 --> 00:10:43,520
All managed disks are encrypted, addressed by default.

251
00:10:43,520 --> 00:10:46,720
Azure uses server-side encryption with platform managed keys.

252
00:10:46,720 --> 00:10:49,160
You don't have to turn it on or configure anything.

253
00:10:49,160 --> 00:10:51,720
Every new disk you create is automatically encrypted.

254
00:10:51,720 --> 00:10:54,560
It covers the basic requirement for most organizations.

255
00:10:54,560 --> 00:10:55,920
But what if you need more control?

256
00:10:55,920 --> 00:10:59,120
Maybe your compliance team wants you to manage your own encryption keys.

257
00:10:59,120 --> 00:11:02,680
In that case, you can use customer managed keys with Azure Key Vault.

258
00:11:02,680 --> 00:11:06,400
Create a disk encryption set, point it to a key in your vault and assign that set to your

259
00:11:06,400 --> 00:11:07,400
disks.

260
00:11:07,400 --> 00:11:09,440
Azure uses your key to encrypt and decrypt.

261
00:11:09,440 --> 00:11:14,080
You control rotation, you control access, revoke the key and the data becomes inaccessible.

262
00:11:14,080 --> 00:11:15,760
That's a lot of power, so be careful.

263
00:11:15,760 --> 00:11:18,680
For even stricter requirements, enable encryption at host.

264
00:11:18,680 --> 00:11:19,760
This adds another layer.

265
00:11:19,760 --> 00:11:23,560
It encrypts data as it travels between the VM host and the storage cluster.

266
00:11:23,560 --> 00:11:26,480
It also encrypts the temporary disk and any cached data.

267
00:11:26,480 --> 00:11:30,880
If you're running workloads with strict compliance standards like healthcare or finance, this is

268
00:11:30,880 --> 00:11:31,880
worth looking into.

269
00:11:31,880 --> 00:11:33,680
Then there's Azure disk encryption.

270
00:11:33,680 --> 00:11:36,080
This is different from the default server-side encryption.

271
00:11:36,080 --> 00:11:41,680
It uses Bitlocker on Windows and DM-crypt on Linux to encrypt the OS and data disks from inside

272
00:11:41,680 --> 00:11:42,680
the VM.

273
00:11:42,680 --> 00:11:44,480
It's an extra layer of protection.

274
00:11:44,480 --> 00:11:48,120
If someone somehow gets access to the underlying storage, they still can't read the data without

275
00:11:48,120 --> 00:11:49,120
the keys.

276
00:11:49,120 --> 00:11:51,520
And finally, network security.

277
00:11:51,520 --> 00:11:55,760
Private endpoints let you access managed disks from within your virtual network without exposing

278
00:11:55,760 --> 00:11:57,560
them to the internet.

279
00:11:57,560 --> 00:11:59,600
Traffic never leaves the Microsoft backbone.

280
00:11:59,600 --> 00:12:02,840
If you're serious about security, use private endpoints for your storage.

281
00:12:02,840 --> 00:12:07,400
Now, how do you protect your data from accidental deletion or corruption?

282
00:12:07,400 --> 00:12:10,040
Backups and snapshots, protecting your data.

283
00:12:10,040 --> 00:12:11,800
Let's talk about protecting your data.

284
00:12:11,800 --> 00:12:13,600
You have two main options here.

285
00:12:13,600 --> 00:12:14,880
Snapshots and Azure backup.

286
00:12:14,880 --> 00:12:19,440
Think of a snapshot as a read-only copy of a disk captured at a specific moment.

287
00:12:19,440 --> 00:12:23,220
The first snapshot grabs the entire disk, but every snapshot after that only stores the

288
00:12:23,220 --> 00:12:24,960
changes since the last one.

289
00:12:24,960 --> 00:12:27,000
That's what makes them fast and cheap.

290
00:12:27,000 --> 00:12:31,480
You take a snapshot before making a risky change to a VM, like installing a patch or updating

291
00:12:31,480 --> 00:12:32,600
an application.

292
00:12:32,600 --> 00:12:36,640
If something goes wrong, you just create a new disk from the snapshot and attach it, and

293
00:12:36,640 --> 00:12:38,480
your back where you started.

294
00:12:38,480 --> 00:12:41,560
Snapshots are also great for cloning disks or moving them to another region.

295
00:12:41,560 --> 00:12:43,240
But they do have limits.

296
00:12:43,240 --> 00:12:44,720
Snapshots aren't a full backup solution.

297
00:12:44,720 --> 00:12:48,640
You have to manage them yourself, remember to take them and clean up the old ones.

298
00:12:48,640 --> 00:12:50,400
And by default, they're not georedundant.

299
00:12:50,400 --> 00:12:54,500
They live in the same storage as the original disk, so if you need protection across regions,

300
00:12:54,500 --> 00:12:56,200
you have to copy them manually.

301
00:12:56,200 --> 00:12:57,760
That's where Azure backup steps in.

302
00:12:57,760 --> 00:12:58,760
It's a managed service.

303
00:12:58,760 --> 00:13:00,240
You set up a backup policy.

304
00:13:00,240 --> 00:13:02,160
How often and how long to keep backups.

305
00:13:02,160 --> 00:13:03,560
And Azure handles the rest.

306
00:13:03,560 --> 00:13:07,520
It automates the snapshot process, handles retention and stores everything in a recovery

307
00:13:07,520 --> 00:13:08,600
services vault.

308
00:13:08,600 --> 00:13:11,320
You can configure that vault to replicate to a secondary region.

309
00:13:11,320 --> 00:13:15,640
It even supports file-level restore, so you can recover individual files without restoring

310
00:13:15,640 --> 00:13:16,640
the whole disk.

311
00:13:16,640 --> 00:13:18,000
So here's the simple rule.

312
00:13:18,000 --> 00:13:21,680
Use snapshots for quick rollbacks before deployment or patch.

313
00:13:21,680 --> 00:13:24,480
Use Azure backup for long term protection and compliance.

314
00:13:24,480 --> 00:13:28,400
If you need to show an auditor backups going back three years, Azure backup gives you

315
00:13:28,400 --> 00:13:29,400
that.

316
00:13:29,400 --> 00:13:31,520
Snapshots alone won't.

317
00:13:31,520 --> 00:13:33,160
Now let's talk about money.

318
00:13:33,160 --> 00:13:35,840
How do you avoid overpaying for disks?

319
00:13:35,840 --> 00:13:37,360
Cost optimization tips.

320
00:13:37,360 --> 00:13:39,000
Here's a number that might surprise you.

321
00:13:39,000 --> 00:13:43,000
Use your bills you for the provision size of a disk, not the space you're actually using.

322
00:13:43,000 --> 00:13:46,880
So if you have a one terabyte disk with only a hundred gigabytes of data, you're paying

323
00:13:46,880 --> 00:13:48,880
for that full terabyte every single month.

324
00:13:48,880 --> 00:13:51,080
That's the single biggest waste in most environments.

325
00:13:51,080 --> 00:13:52,840
So step one is right sizing.

326
00:13:52,840 --> 00:13:56,420
Use premium SSD V2 or ultra disk when you need performance.

327
00:13:56,420 --> 00:13:59,800
They let you dial up IOPS without buying extra capacity you don't need.

328
00:13:59,800 --> 00:14:03,880
With the older premium SSD, if you wanted more IOPS, you had to buy a bigger disk.

329
00:14:03,880 --> 00:14:07,680
With V2, you just adjust the IOPS setting that alone can save a lot.

330
00:14:07,680 --> 00:14:09,720
You can use it to delete unattached disks.

331
00:14:09,720 --> 00:14:13,520
If you delete a VM but leave the disks behind, you're still paying for them.

332
00:14:13,520 --> 00:14:16,720
They sit there unused, generating charges.

333
00:14:16,720 --> 00:14:18,600
Use automation to fine and clean them up.

334
00:14:18,600 --> 00:14:19,600
Azure has tools for that.

335
00:14:19,600 --> 00:14:22,200
Use standard HDD for things that don't need speed.

336
00:14:22,200 --> 00:14:25,120
Backups, archives, logs you access once a quarter.

337
00:14:25,120 --> 00:14:26,480
Don't put those on premium disks.

338
00:14:26,480 --> 00:14:27,760
You're just burning money.

339
00:14:27,760 --> 00:14:30,760
If you have predictable workloads, look into reserved capacity.

340
00:14:30,760 --> 00:14:34,880
For blob storage, reservations can save up to 38% on the hot tier.

341
00:14:34,880 --> 00:14:38,720
Same idea applies to manage disks, commit to a certain amount of storage for one or three

342
00:14:38,720 --> 00:14:40,680
years and you get a discount.

343
00:14:40,680 --> 00:14:41,840
Here's another easy one.

344
00:14:41,840 --> 00:14:44,240
Reduce redundancy for non-critical data.

345
00:14:44,240 --> 00:14:46,600
LRS costs about half of what's the RIS costs.

346
00:14:46,600 --> 00:14:51,560
If your dev environment doesn't need zone level protection, use LRS and save that ZRS budget

347
00:14:51,560 --> 00:14:52,560
for production.

348
00:14:52,560 --> 00:14:53,800
Monitor your costs.

349
00:14:53,800 --> 00:14:57,040
Azure cost management shows you exactly what you're spending on disks.

350
00:14:57,040 --> 00:14:58,480
Set budgets, set alerts.

351
00:14:58,480 --> 00:15:00,320
If costs, spike, you'll know why.

352
00:15:00,320 --> 00:15:05,440
So now you have the big picture of Azure manage disks and how to protect and optimize them.

353
00:15:05,440 --> 00:15:06,880
So here's the big picture.

354
00:15:06,880 --> 00:15:09,720
Manage disks are Azure's answer to the old storage headache.

355
00:15:09,720 --> 00:15:11,800
Before them, you had to juggle storage accounts yourself.

356
00:15:11,800 --> 00:15:16,560
Now you just pick a size and a type and Azure handles everything behind the scenes.

357
00:15:16,560 --> 00:15:18,600
Think of it like choosing the right tool for the job.

358
00:15:18,600 --> 00:15:20,400
There are five disk flavors to pick from.

359
00:15:20,400 --> 00:15:22,280
Ultra disk for lightning speed.

360
00:15:22,280 --> 00:15:25,200
Premium SSD V2 for flexible high performance workloads.

361
00:15:25,200 --> 00:15:27,520
Premium SSD for your predictable enterprise apps.

362
00:15:27,520 --> 00:15:30,200
Standard SSD gives you the best balance of cost and speed.

363
00:15:30,200 --> 00:15:33,920
And standard HDD is your cheap slow option for low stakes data.

364
00:15:33,920 --> 00:15:34,920
Each one has its place.

365
00:15:34,920 --> 00:15:36,200
Now here's your task.

366
00:15:36,200 --> 00:15:39,480
Open the Azure portal and look at the disks attached to your VMs.

367
00:15:39,480 --> 00:15:40,480
Ask yourself one question.

368
00:15:40,480 --> 00:15:42,280
Am I using the right type and size?

369
00:15:42,280 --> 00:15:45,280
Chances are, you'll find at least one disk you can optimize.

370
00:15:45,280 --> 00:15:46,280
That's a win.

371
00:15:46,280 --> 00:15:49,120
If you want to go deeper, check out Azure disk encryption next.

372
00:15:49,120 --> 00:15:51,720
It shows how to secure those disks even further.

373
00:15:51,720 --> 00:15:54,800
And if this helped, subscribe on your favorite podcast platform.

374
00:15:54,800 --> 00:15:57,840
Share this knowledge nugget with someone starting their Azure journey.