1 00:00:00,000 --> 00:00:02,360 Azure already gives you plenty of storage options, 2 00:00:02,360 --> 00:00:04,080 blob, files, disk. 3 00:00:04,080 --> 00:00:06,240 So why does Azure NetApp files even exist? 4 00:00:06,240 --> 00:00:08,720 That's the first question people ask when they hear about it. 5 00:00:08,720 --> 00:00:09,560 And it's a fair one. 6 00:00:09,560 --> 00:00:11,400 Microsoft keeps adding storage services 7 00:00:11,400 --> 00:00:13,800 and it can feel like a new option appears every quarter. 8 00:00:13,800 --> 00:00:14,760 So why another one? 9 00:00:14,760 --> 00:00:15,600 Here's the thing. 10 00:00:15,600 --> 00:00:18,320 Most Azure storage handles general use just fine. 11 00:00:18,320 --> 00:00:20,640 Web apps, file shares, backups, 12 00:00:20,640 --> 00:00:22,760 the everyday things that keep a business running, 13 00:00:22,760 --> 00:00:24,560 but some workloads don't fit that mold. 14 00:00:24,560 --> 00:00:25,800 They need ridiculous speed. 15 00:00:25,800 --> 00:00:28,080 They need consistent performance under pressure, 16 00:00:28,080 --> 00:00:30,600 and they can't afford extra milliseconds of delay. 17 00:00:30,600 --> 00:00:32,760 Azure NetApp files is built specifically 18 00:00:32,760 --> 00:00:34,040 for those workloads. 19 00:00:34,040 --> 00:00:35,320 By the end of this episode, 20 00:00:35,320 --> 00:00:37,200 you'll know exactly what A and F is, 21 00:00:37,200 --> 00:00:40,000 when to use it, and when to stick with something simpler. 22 00:00:40,000 --> 00:00:41,160 We'll cover what it actually is, 23 00:00:41,160 --> 00:00:43,120 the three main use cases where it shines 24 00:00:43,120 --> 00:00:44,920 and how it compares to Azure files. 25 00:00:44,920 --> 00:00:46,920 Let's start with a simple definition. 26 00:00:46,920 --> 00:00:49,320 What Azure NetApp files actually is. 27 00:00:49,320 --> 00:00:51,000 Azure NetApp files is a managed, 28 00:00:51,000 --> 00:00:53,400 high performance enterprise file storage service 29 00:00:53,400 --> 00:00:55,000 that lives right inside Azure. 30 00:00:55,000 --> 00:00:56,640 This is not some third party add-on 31 00:00:56,640 --> 00:00:58,200 or something you bolt on later. 32 00:00:58,200 --> 00:00:59,960 It's the first party Microsoft service 33 00:00:59,960 --> 00:01:01,600 fully built into the Azure portal, 34 00:01:01,600 --> 00:01:02,840 but what sets it apart? 35 00:01:02,840 --> 00:01:05,440 Under the hood, it runs on NetApp technology. 36 00:01:05,440 --> 00:01:07,160 The same storage system that's been powering 37 00:01:07,160 --> 00:01:09,240 on premises data centers for decades, 38 00:01:09,240 --> 00:01:11,120 NetApp has been doing enterprise file storage 39 00:01:11,120 --> 00:01:12,680 since the 1990s. 40 00:01:12,680 --> 00:01:14,840 They understand fast and reliable data. 41 00:01:14,840 --> 00:01:17,560 Microsoft partnered with them to bring that expertise 42 00:01:17,560 --> 00:01:19,480 into Azure as a managed service. 43 00:01:19,480 --> 00:01:20,720 So what does that mean for you? 44 00:01:20,720 --> 00:01:23,240 A and F supports both SMB and NFS protocols 45 00:01:23,240 --> 00:01:24,320 right out of the box. 46 00:01:24,320 --> 00:01:26,560 Windows workloads, Linux workloads, 47 00:01:26,560 --> 00:01:27,680 it handles both. 48 00:01:27,680 --> 00:01:29,280 You don't have to choose one or the other. 49 00:01:29,280 --> 00:01:31,320 The same volume can serve both types of clients 50 00:01:31,320 --> 00:01:32,240 if you need it. 51 00:01:32,240 --> 00:01:34,080 Performance is where it really stands out. 52 00:01:34,080 --> 00:01:35,680 We're talking sub millisecond latency 53 00:01:35,680 --> 00:01:38,160 and massive throughput, not fast enough. 54 00:01:38,160 --> 00:01:40,200 It's genuinely blazing fast. 55 00:01:40,200 --> 00:01:41,160 Here's an analogy. 56 00:01:41,160 --> 00:01:43,320 If Azure files is the reliable family sedan 57 00:01:43,320 --> 00:01:44,920 that gets you where you need to go, 58 00:01:44,920 --> 00:01:46,720 Azure NetApp files is the sports car, 59 00:01:46,720 --> 00:01:48,640 built for speed and it handles unlike anything else 60 00:01:48,640 --> 00:01:49,480 in the garage. 61 00:01:49,480 --> 00:01:50,920 And the best part, it's fully managed. 62 00:01:50,920 --> 00:01:52,760 No patching service, no replacing hardware. 63 00:01:52,760 --> 00:01:54,200 You just create a volume, 64 00:01:54,200 --> 00:01:56,640 choose your performance tier and start using it. 65 00:01:56,640 --> 00:01:58,520 Azure and NetApp take care of the rest, 66 00:01:58,520 --> 00:02:00,320 but why would you need a sports car for storage? 67 00:02:00,320 --> 00:02:03,200 Let's look at the problems regular storage can't solve. 68 00:02:03,200 --> 00:02:06,760 The problems, regular storage can't solve. 69 00:02:06,760 --> 00:02:09,560 Most cloud storage handles everyday IT, just fine. 70 00:02:09,560 --> 00:02:11,600 Web apps, file shares, backups. 71 00:02:11,600 --> 00:02:12,760 For most people that's enough, 72 00:02:12,760 --> 00:02:14,120 you don't need a Formula One engine 73 00:02:14,120 --> 00:02:15,720 to drive to the grocery store. 74 00:02:15,720 --> 00:02:17,280 But some workloads are different. 75 00:02:17,280 --> 00:02:18,880 Think of them like demanding athletes 76 00:02:18,880 --> 00:02:21,120 who need every millisecond and can't afford to wait. 77 00:02:21,120 --> 00:02:21,960 Here's the problem. 78 00:02:21,960 --> 00:02:24,160 High latency kills database performance. 79 00:02:24,160 --> 00:02:25,920 A few extra milliseconds on a log ride 80 00:02:25,920 --> 00:02:28,360 can slow down an entire transaction system. 81 00:02:28,360 --> 00:02:30,040 Low throughput chokes simulations, 82 00:02:30,040 --> 00:02:32,320 turning jobs that should take hours into days. 83 00:02:32,320 --> 00:02:34,040 Inconsistent IOPS is another issue. 84 00:02:34,040 --> 00:02:36,040 It frustrates VDI users the most. 85 00:02:36,040 --> 00:02:37,440 One minute everything's fine. 86 00:02:37,440 --> 00:02:39,960 The next, the desktop lags because storage can't keep up. 87 00:02:39,960 --> 00:02:41,760 Let me give you a concrete example. 88 00:02:41,760 --> 00:02:44,680 A 2.3 terabyte, SAP HANA database backup 89 00:02:44,680 --> 00:02:46,600 on regular storage might take an hour. 90 00:02:46,600 --> 00:02:48,600 That's an hour of waiting and potential issues. 91 00:02:48,600 --> 00:02:49,840 On Azure NetApp files, 92 00:02:49,840 --> 00:02:52,000 the same backup completes in two minutes. 93 00:02:52,000 --> 00:02:53,680 Not a typo, two minutes. 94 00:02:53,680 --> 00:02:55,760 The issue isn't that Azure files is bad. 95 00:02:55,760 --> 00:02:58,080 It's a great service for what it's designed to do. 96 00:02:58,080 --> 00:02:59,640 But it's optimized for cost. 97 00:02:59,640 --> 00:03:00,560 Not peak performance. 98 00:03:00,560 --> 00:03:02,480 It gives you good enough speed at a reasonable price 99 00:03:02,480 --> 00:03:03,640 and that's fine for most workloads, 100 00:03:03,640 --> 00:03:06,080 but not all Azure NetApp files fills that gap. 101 00:03:06,080 --> 00:03:07,960 It's built for workloads that can't compromise 102 00:03:07,960 --> 00:03:09,520 on speed or consistency. 103 00:03:09,520 --> 00:03:11,920 When every millisecond counts, ANF is the answer. 104 00:03:11,920 --> 00:03:14,040 So who actually needs this kind of performance? 105 00:03:14,040 --> 00:03:16,080 Let's start with one of the biggest users. 106 00:03:16,080 --> 00:03:16,920 SAP HANA. 107 00:03:16,920 --> 00:03:18,760 Use case number one, SAP HANA. 108 00:03:18,760 --> 00:03:20,240 Let's talk about SAP HANA. 109 00:03:20,240 --> 00:03:22,200 If you're not in the enterprise database world, 110 00:03:22,200 --> 00:03:23,320 you might not have heard of it. 111 00:03:23,320 --> 00:03:25,040 But it's one of the most demanding workloads 112 00:03:25,040 --> 00:03:26,360 you can run in the cloud. 113 00:03:26,360 --> 00:03:28,400 SAP HANA is an in-memory database, 114 00:03:28,400 --> 00:03:30,800 meaning it keeps all its data in RAM for speed. 115 00:03:30,800 --> 00:03:32,320 But even though data lives in memory, 116 00:03:32,320 --> 00:03:34,120 HANA still needs ultra-fast storage 117 00:03:34,120 --> 00:03:35,720 for logs, backups, and snapshots. 118 00:03:35,720 --> 00:03:37,960 Those rights have to happen quickly and reliably. 119 00:03:37,960 --> 00:03:40,320 If storage can't keep up, the whole database slows down. 120 00:03:40,320 --> 00:03:43,360 That's why Azure NetApp files is SAP certified. 121 00:03:43,360 --> 00:03:47,160 It's listed in the official SAP HANA hardware directory, 122 00:03:47,160 --> 00:03:50,160 meaning it's been tested and approved by SAP themselves. 123 00:03:50,160 --> 00:03:51,120 That's not a small thing. 124 00:03:51,120 --> 00:03:54,080 SAP doesn't certify just any storage solution. 125 00:03:54,080 --> 00:03:57,280 They test it thoroughly and only the ones that pass make the list. 126 00:03:57,280 --> 00:03:59,120 What kind of performance are we talking about? 127 00:03:59,120 --> 00:04:01,240 Submily second latency consistently, 128 00:04:01,240 --> 00:04:04,520 and up to four times 500 might be per second of throughput per volume. 129 00:04:04,520 --> 00:04:05,640 To put that in perspective, 130 00:04:05,640 --> 00:04:08,280 SAP's minimum requirement for HANA log rights 131 00:04:08,280 --> 00:04:10,160 is under one millisecond of latency 132 00:04:10,160 --> 00:04:12,680 and ANF lives comfortably below that threshold. 133 00:04:12,680 --> 00:04:15,040 That matters because latency above one millisecond 134 00:04:15,040 --> 00:04:17,240 can slow down database transactions. 135 00:04:17,240 --> 00:04:19,160 When you're processing thousands of transactions 136 00:04:19,160 --> 00:04:21,280 per second, every extra millisecond adds up. 137 00:04:21,280 --> 00:04:23,280 Microsoft even built a special deployment tool 138 00:04:23,280 --> 00:04:25,640 called Application Volume Group for HANA. 139 00:04:25,640 --> 00:04:27,760 It optimizes volume layout by spreading them 140 00:04:27,760 --> 00:04:29,520 across multiple storage endpoints, 141 00:04:29,520 --> 00:04:31,920 so no single endpoint becomes a bottleneck. 142 00:04:31,920 --> 00:04:34,160 Think of it like having multiple lanes on a highway 143 00:04:34,160 --> 00:04:35,600 instead of one narrow road. 144 00:04:35,600 --> 00:04:37,680 And the backup numbers are worth talking about. 145 00:04:37,680 --> 00:04:40,240 A 2.3 terabyte HANA backup completes in about two minutes 146 00:04:40,240 --> 00:04:41,200 on ANF. 147 00:04:41,200 --> 00:04:44,920 On conventional storage, that same backup could take 30 to 60 minutes. 148 00:04:44,920 --> 00:04:46,040 That's not just a convenience. 149 00:04:46,040 --> 00:04:48,360 It changes what's possible with your backup windows. 150 00:04:48,360 --> 00:04:49,880 The cost side is interesting too. 151 00:04:49,880 --> 00:04:51,120 With flexible service levels, 152 00:04:51,120 --> 00:04:52,720 you can match performance exactly 153 00:04:52,720 --> 00:04:55,080 to what HANA needs without over-provisioning. 154 00:04:55,080 --> 00:04:56,640 You're not paying for extra capacity 155 00:04:56,640 --> 00:04:58,440 just to get the throughput you need. 156 00:04:58,440 --> 00:05:01,520 SAP is one big use case, but ANF also powers 157 00:05:01,520 --> 00:05:04,800 a very different kind of workload, high performance computing. 158 00:05:04,800 --> 00:05:07,200 High performance computing, HPC. 159 00:05:07,200 --> 00:05:09,720 High performance computing covers a lot of ground. 160 00:05:09,720 --> 00:05:13,200 Simulations, rendering, financial modeling, scientific research, 161 00:05:13,200 --> 00:05:15,640 anything where you're running massive parallel jobs 162 00:05:15,640 --> 00:05:18,200 across hundreds or even thousands of compute nodes. 163 00:05:18,200 --> 00:05:20,160 These workloads have a very specific need. 164 00:05:20,160 --> 00:05:23,520 They need shared file access with high throughput and low latency. 165 00:05:23,520 --> 00:05:25,640 Multiple nodes must read and write the same data sets 166 00:05:25,640 --> 00:05:26,680 at the same time. 167 00:05:26,680 --> 00:05:28,920 If your storage can't keep up, your compute nodes 168 00:05:28,920 --> 00:05:30,600 sit idle waiting for data. 169 00:05:30,600 --> 00:05:33,200 And idle compute time is wasted money. 170 00:05:33,200 --> 00:05:36,640 Azure NetApp files delivers up to 652,000 IOPS 171 00:05:36,640 --> 00:05:39,600 with under 2 milliseconds of latency in benchmark tests. 172 00:05:39,600 --> 00:05:41,800 That's a lot of input output operations. 173 00:05:41,800 --> 00:05:44,040 And it's fast enough that storage rarely 174 00:05:44,040 --> 00:05:45,440 becomes the bottleneck anymore. 175 00:05:45,440 --> 00:05:46,920 For really large data sets, there's 176 00:05:46,920 --> 00:05:48,480 the large volumes feature. 177 00:05:48,480 --> 00:05:51,280 It supports capacities up to two petabytes per volume. 178 00:05:51,280 --> 00:05:53,680 That's 2,000 terabytes in a single volume. 179 00:05:53,680 --> 00:05:55,560 Think about what that means for a research team 180 00:05:55,560 --> 00:05:57,520 working with massive simulation outputs, 181 00:05:57,520 --> 00:05:59,680 or a media studio rendering a feature film. 182 00:05:59,680 --> 00:06:01,800 Then this breakthrough mode, it pushes throughput up 183 00:06:01,800 --> 00:06:04,560 to 50 gigabits per second from a single large volume. 184 00:06:04,560 --> 00:06:07,120 That's enough bandwidth to move enormous data sets quickly. 185 00:06:07,120 --> 00:06:10,640 Here's a real world example, electronic design automation, 186 00:06:10,640 --> 00:06:13,520 or EDA in the chip design industry. 187 00:06:13,520 --> 00:06:16,680 Companies like Nvidia and AMD run thousands of simulations 188 00:06:16,680 --> 00:06:19,360 at once to verify chip designs before manufacturing. 189 00:06:19,360 --> 00:06:21,800 Each simulation reads and writes shared data. 190 00:06:21,800 --> 00:06:23,880 The storage system has to handle that concurrent load 191 00:06:23,880 --> 00:06:25,080 without slowing down. 192 00:06:25,080 --> 00:06:27,120 ANF is built for exactly that pattern. 193 00:06:27,120 --> 00:06:29,120 So why not just use Azure files for this? 194 00:06:29,120 --> 00:06:31,520 Because Azure files has file level throughput caps, 195 00:06:31,520 --> 00:06:33,800 300 megabytes per second, egress per file. 196 00:06:33,800 --> 00:06:36,520 That means even if your storage back end has more capacity, 197 00:06:36,520 --> 00:06:38,800 a single large file can't push past that limit. 198 00:06:38,800 --> 00:06:40,360 ANF has no file level caps. 199 00:06:40,360 --> 00:06:42,640 Each file can saturate the network connection. 200 00:06:42,640 --> 00:06:44,720 For workloads dealing with large simulation files, 201 00:06:44,720 --> 00:06:46,040 that difference matters. 202 00:06:46,040 --> 00:06:49,640 Microsoft's own guidance recommends ANF for HBC workloads 203 00:06:49,640 --> 00:06:53,320 up to about 4,000 cores and 6.5 gigabytes per second 204 00:06:53,320 --> 00:06:54,080 of throughput. 205 00:06:54,080 --> 00:06:56,280 Beyond that, you might need a different architecture, 206 00:06:56,280 --> 00:06:59,160 but for the vast majority of HBC scenarios, 207 00:06:59,160 --> 00:07:00,880 ANF fits the bill. 208 00:07:00,880 --> 00:07:03,720 Third major use case, virtual desktop infrastructure, 209 00:07:03,720 --> 00:07:05,760 where user experience is everything. 210 00:07:05,760 --> 00:07:07,960 Virtual desktop infrastructure, VDI. 211 00:07:07,960 --> 00:07:10,680 Now let's talk about something almost everyone deals with. 212 00:07:10,680 --> 00:07:11,960 The desktop experience. 213 00:07:11,960 --> 00:07:13,960 Virtual desktop infrastructure or VDI 214 00:07:13,960 --> 00:07:16,240 means hosting Windows desktops in the cloud, 215 00:07:16,240 --> 00:07:18,680 think as you are virtual desktop or Citrix. 216 00:07:18,680 --> 00:07:20,640 Instead of running a full PC on your desk, 217 00:07:20,640 --> 00:07:22,560 the desktop lives on a server somewhere 218 00:07:22,560 --> 00:07:24,160 and you connect to it remotely. 219 00:07:24,160 --> 00:07:25,040 Here's the challenge. 220 00:07:25,040 --> 00:07:27,720 User profiles and app data must be stored centrally 221 00:07:27,720 --> 00:07:29,040 and accessed quickly. 222 00:07:29,040 --> 00:07:31,640 Every time someone logs in, their profile has to load, 223 00:07:31,640 --> 00:07:33,960 settings, files, application data. 224 00:07:33,960 --> 00:07:36,160 If that storage is slow, the login is slow, 225 00:07:36,160 --> 00:07:38,400 and slow logins make people unhappy very fast. 226 00:07:38,400 --> 00:07:40,520 This is where ANF makes a real difference. 227 00:07:40,520 --> 00:07:43,160 Slow profile load times have been the number one complaint 228 00:07:43,160 --> 00:07:44,920 in VDI deployments for years. 229 00:07:44,920 --> 00:07:47,520 Users compare it to their old on-premises desktop. 230 00:07:47,520 --> 00:07:50,760 And if the cloud version feels slower, they notice immediately. 231 00:07:50,760 --> 00:07:54,280 Azure NetApp files solves this with high IOPS and low latency. 232 00:07:54,280 --> 00:07:56,400 And I'm not talking about theoretical improvements. 233 00:07:56,400 --> 00:07:58,480 Real-world results show logon times dropping 234 00:07:58,480 --> 00:08:01,080 from 20 to 30 seconds down to under five seconds 235 00:08:01,080 --> 00:08:02,960 when organizations switch from Azure files 236 00:08:02,960 --> 00:08:05,360 to ANF for their profile storage. 237 00:08:05,360 --> 00:08:07,440 That's the kind of improvement users actually feel. 238 00:08:07,440 --> 00:08:08,280 Why does it work so well? 239 00:08:08,280 --> 00:08:12,800 Because ANF supports up to 450,000 IOPS per volume, 240 00:08:12,800 --> 00:08:14,240 that matters when hundreds of users 241 00:08:14,240 --> 00:08:16,560 all log on at the same time in the morning. 242 00:08:16,560 --> 00:08:17,800 That's the logon storm. 243 00:08:17,800 --> 00:08:19,120 Everyone arrives at nine, 244 00:08:19,120 --> 00:08:21,880 and suddenly every profile needs to load simultaneously. 245 00:08:21,880 --> 00:08:24,400 A storage system that can't handle that concurrency 246 00:08:24,400 --> 00:08:25,720 will slow everyone down. 247 00:08:25,720 --> 00:08:27,240 ANF handles it. 248 00:08:27,240 --> 00:08:29,960 There's another feature that's incredibly useful for VDI. 249 00:08:29,960 --> 00:08:32,880 ANF supports up to 255 snapshots per volume. 250 00:08:32,880 --> 00:08:34,760 That means you can instantly revert 251 00:08:34,760 --> 00:08:36,680 a user's profile to yesterday's state. 252 00:08:36,680 --> 00:08:38,160 If someone's profile gets corrupted 253 00:08:38,160 --> 00:08:39,920 or a bad update breaks something, 254 00:08:39,920 --> 00:08:41,520 you don't have to restore from backup. 255 00:08:41,520 --> 00:08:43,960 You just point to yesterday's snapshot and it's done. 256 00:08:43,960 --> 00:08:45,680 That saves hours of support time 257 00:08:45,680 --> 00:08:47,880 and the reliability piece matters too. 258 00:08:47,880 --> 00:08:51,000 ANF comes with a 99.99% availability SLA. 259 00:08:51,000 --> 00:08:52,600 For mission-critical VDI deployments 260 00:08:52,600 --> 00:08:54,560 where downtime means lost productivity, 261 00:08:54,560 --> 00:08:56,320 that level of reliability is essential. 262 00:08:56,320 --> 00:08:58,120 Here's a cost angle you might not expect 263 00:08:58,120 --> 00:09:00,520 because ANF is so fast you can actually use smaller, 264 00:09:00,520 --> 00:09:03,080 cheaper virtual machines and still get good performance. 265 00:09:03,080 --> 00:09:04,400 The storage handles the heavy lifting 266 00:09:04,400 --> 00:09:05,800 so your compute doesn't have to. 267 00:09:05,800 --> 00:09:08,680 That can offset some of the premium storage cost. 268 00:09:08,680 --> 00:09:11,840 And you now see the three pillars SAP HPC VDI. 269 00:09:11,840 --> 00:09:15,240 But how does ANF actually compare to its cousin Azure files? 270 00:09:15,240 --> 00:09:17,960 How Azure NetApp files compares to Azure files? 271 00:09:17,960 --> 00:09:20,000 So both Azure NetApp files and Azure files 272 00:09:20,000 --> 00:09:21,760 are managed file shares in Azure. 273 00:09:21,760 --> 00:09:24,440 That means you don't patch servers or replace hardware. 274 00:09:24,440 --> 00:09:27,080 The real difference comes down to performance and price. 275 00:09:27,080 --> 00:09:28,560 Let's compare the raw numbers. 276 00:09:28,560 --> 00:09:31,600 Azure files premium caps at 100,000 IOPS per share, 277 00:09:31,600 --> 00:09:33,520 which is plenty for many workloads. 278 00:09:33,520 --> 00:09:36,720 But ANF hits up to 450,000 IOPS per volume, 279 00:09:36,720 --> 00:09:38,600 more than four times that ceiling. 280 00:09:38,600 --> 00:09:41,280 When you're running workloads that need serious concurrent access, 281 00:09:41,280 --> 00:09:42,840 that gap really matters. 282 00:09:42,840 --> 00:09:44,720 Latency tells a similar story. 283 00:09:44,720 --> 00:09:47,120 Azure files standard runs around 10 milliseconds 284 00:09:47,120 --> 00:09:49,640 and premium brings that down to two to three milliseconds. 285 00:09:49,640 --> 00:09:50,600 That's respectable. 286 00:09:50,600 --> 00:09:52,680 But ANF delivers sub millisecond latency 287 00:09:52,680 --> 00:09:55,520 around 0.5 milliseconds on the ultra tier. 288 00:09:55,520 --> 00:09:58,040 That's the difference between storage being a minor factor 289 00:09:58,040 --> 00:09:59,880 and storage being essentially invisible. 290 00:09:59,880 --> 00:10:02,600 Throughput is where the gap gets even wider. 291 00:10:02,600 --> 00:10:04,560 Azure files has file level caps. 292 00:10:04,560 --> 00:10:06,400 300 megabytes per second egress 293 00:10:06,400 --> 00:10:08,840 and 200 megabytes per second egress per file. 294 00:10:08,840 --> 00:10:11,000 So even if your backend has more capacity, 295 00:10:11,000 --> 00:10:13,720 a single large file can't push past that limit. 296 00:10:13,720 --> 00:10:15,520 ANF has no file level caps. 297 00:10:15,520 --> 00:10:18,760 Each file can use as much throughput as the network allows. 298 00:10:18,760 --> 00:10:20,000 And maximum share size, 299 00:10:20,000 --> 00:10:22,560 Azure files tops out at 100 terabytes per share. 300 00:10:22,560 --> 00:10:25,080 ANF goes up to two petabytes with large volumes. 301 00:10:25,080 --> 00:10:27,000 That's 20 times the capacity. 302 00:10:27,000 --> 00:10:28,200 So when do you use each one? 303 00:10:28,200 --> 00:10:30,880 Azure files is the right choice for general file sharing, 304 00:10:30,880 --> 00:10:32,520 department shares, backup targets, 305 00:10:32,520 --> 00:10:34,160 and cost sensitive workloads. 306 00:10:34,160 --> 00:10:35,480 Think of it as the sedan. 307 00:10:35,480 --> 00:10:37,760 Reliable affordable gets the job done. 308 00:10:37,760 --> 00:10:40,880 ANF is for workloads where latency and throughput are critical. 309 00:10:40,880 --> 00:10:44,280 SAPI Hana, Oracle, SQL Server, HPC, VDI. 310 00:10:44,280 --> 00:10:46,160 Any scenario where sub millisecond latency 311 00:10:46,160 --> 00:10:47,560 and high IOPS make a real difference 312 00:10:47,560 --> 00:10:48,920 to application performance. 313 00:10:48,920 --> 00:10:50,280 Now here's the thing about cost. 314 00:10:50,280 --> 00:10:53,200 Azure files is cheaper for most use cases and that's by design. 315 00:10:53,200 --> 00:10:56,080 But ANF can actually save money in specific scenarios. 316 00:10:56,080 --> 00:10:59,600 If it lets you use smaller VMs because the storage is faster, 317 00:10:59,600 --> 00:11:01,360 you save on compute costs. 318 00:11:01,360 --> 00:11:03,480 If it prevents over provisioning capacity, 319 00:11:03,480 --> 00:11:05,920 just to get enough throughput, you save on storage costs. 320 00:11:05,920 --> 00:11:08,240 So the total cost picture isn't always straightforward. 321 00:11:08,240 --> 00:11:11,080 There's one feature that changes the cost equation entirely, 322 00:11:11,080 --> 00:11:13,440 the flexible service level. 323 00:11:13,440 --> 00:11:16,200 The flexible service level, right sizing performance. 324 00:11:16,200 --> 00:11:17,960 Here's a feature that changes the cost equation. 325 00:11:17,960 --> 00:11:21,320 Traditionally, ANF capacity pools had a fixed ratio. 326 00:11:21,320 --> 00:11:23,760 The bigger your pool, the more throughput you got, 327 00:11:23,760 --> 00:11:26,360 and the smaller your pool, the less throughput you got. 328 00:11:26,360 --> 00:11:27,880 That sounds reasonable on the surface, 329 00:11:27,880 --> 00:11:29,440 but it created a real problem. 330 00:11:29,440 --> 00:11:32,200 Imagine you have a small database, say one terabyte, 331 00:11:32,200 --> 00:11:34,000 but it needs high throughput to run properly. 332 00:11:34,000 --> 00:11:36,640 Under the old model, you'd have to over provision capacity 333 00:11:36,640 --> 00:11:38,080 just to get enough performance. 334 00:11:38,080 --> 00:11:41,200 You might need to buy 64 terabytes of storage on the standard tier 335 00:11:41,200 --> 00:11:43,600 just to get the throughput that one terabyte actually needs 336 00:11:43,600 --> 00:11:45,800 with the other 63 terabytes sitting empty. 337 00:11:45,800 --> 00:11:47,440 You're paying for space you don't use. 338 00:11:47,440 --> 00:11:49,120 That's not efficient and it's not cheap. 339 00:11:49,120 --> 00:11:51,440 Flexible service level changes that completely. 340 00:11:51,440 --> 00:11:53,520 It decouples capacity from throughput, 341 00:11:53,520 --> 00:11:55,520 two independent knobs instead of one. 342 00:11:55,520 --> 00:11:57,040 You decide how much storage you need 343 00:11:57,040 --> 00:11:59,120 and separately how much performance you need. 344 00:11:59,120 --> 00:12:00,160 They don't have to match. 345 00:12:00,160 --> 00:12:01,920 So now you can have a one terabyte pool 346 00:12:01,920 --> 00:12:04,480 with one gigabyte per second of throughput. 347 00:12:04,480 --> 00:12:05,400 Under the old model, 348 00:12:05,400 --> 00:12:07,160 that same performance on the standard tier 349 00:12:07,160 --> 00:12:09,720 would have required 64 terabytes of capacity. 350 00:12:09,720 --> 00:12:11,520 That's a 64 to one difference. 351 00:12:11,520 --> 00:12:12,760 With flexible service level, 352 00:12:12,760 --> 00:12:14,320 you pay for exactly what you need. 353 00:12:14,320 --> 00:12:15,680 The cost savings are real. 354 00:12:15,680 --> 00:12:18,360 In many scenarios, you're looking at 30% or more 355 00:12:18,360 --> 00:12:20,920 compared to using the ultra tier for the same performance. 356 00:12:20,920 --> 00:12:23,880 And that's before you factor in reserve capacity discounts. 357 00:12:23,880 --> 00:12:26,200 The disaster recovery scenario makes this even clearer. 358 00:12:26,200 --> 00:12:29,320 Say you need 100 terabytes of capacity for a DR side, 359 00:12:29,320 --> 00:12:30,880 but you don't need much throughput 360 00:12:30,880 --> 00:12:32,520 until an actual failover happens. 361 00:12:32,520 --> 00:12:33,440 Under the old model, 362 00:12:33,440 --> 00:12:35,040 you'd have to provision for the performance 363 00:12:35,040 --> 00:12:36,360 you might need someday. 364 00:12:36,360 --> 00:12:37,760 With flexible service level, 365 00:12:37,760 --> 00:12:39,360 you pay for capacity only. 366 00:12:39,360 --> 00:12:43,120 128 megabytes per second baseline throughput and nothing more. 367 00:12:43,120 --> 00:12:44,360 When failover happens, 368 00:12:44,360 --> 00:12:46,560 you scale throughput up on demand. 369 00:12:46,560 --> 00:12:48,480 When it's over, you scale it back down 370 00:12:48,480 --> 00:12:50,600 after a 24 hour cool down period. 371 00:12:50,600 --> 00:12:51,520 Speaking of scaling, 372 00:12:51,520 --> 00:12:53,360 you can increase throughput whenever you need it 373 00:12:53,360 --> 00:12:55,000 within limits and after 24 hours, 374 00:12:55,000 --> 00:12:56,200 you can scale back down. 375 00:12:56,200 --> 00:12:58,120 That's perfect for handling peak loads. 376 00:12:58,120 --> 00:13:00,840 Month and processing migration windows, seasonal spikes, 377 00:13:00,840 --> 00:13:03,360 without permanently paying for that extra capacity. 378 00:13:03,360 --> 00:13:05,120 This feature is currently available in preview 379 00:13:05,120 --> 00:13:06,760 across all A and F regions. 380 00:13:06,760 --> 00:13:09,080 It's one of the most requested additions to the service 381 00:13:09,080 --> 00:13:10,960 and it's already changing how customers think 382 00:13:10,960 --> 00:13:12,160 about storage cost. 383 00:13:12,160 --> 00:13:14,320 That's the flexible service level in a nutshell, 384 00:13:14,320 --> 00:13:16,640 a simple change that solves a big problem. 385 00:13:16,640 --> 00:13:18,320 Connection section, putting it all together. 386 00:13:18,320 --> 00:13:20,200 So here's the aha moment. 387 00:13:20,200 --> 00:13:22,880 Azure NetApp files doesn't compete with Azure files. 388 00:13:22,880 --> 00:13:24,840 It fills a specific performance gap, 389 00:13:24,840 --> 00:13:26,960 a gap that matters for the right workloads. 390 00:13:26,960 --> 00:13:28,840 Now those three use cases we covered, 391 00:13:28,840 --> 00:13:32,080 SAP HANA, HPC, VDI, they all share one thing. 392 00:13:32,080 --> 00:13:33,720 They need consistent low latency, 393 00:13:33,720 --> 00:13:35,120 high throughput, file access. 394 00:13:35,120 --> 00:13:36,680 That's the common thread through all of them. 395 00:13:36,680 --> 00:13:38,840 Whether it's a database transaction, 396 00:13:38,840 --> 00:13:42,280 a simulation job, or a user logging into their desktop, 397 00:13:42,280 --> 00:13:45,080 the storage has to deliver without hesitation. 398 00:13:45,080 --> 00:13:46,160 No waiting around. 399 00:13:46,160 --> 00:13:48,880 Flexible service level makes that performance affordable. 400 00:13:48,880 --> 00:13:51,360 Instead of over provisioning capacity you don't need, 401 00:13:51,360 --> 00:13:53,040 you pay only for what you use. 402 00:13:53,040 --> 00:13:55,880 That changes the whole economics of high performance storage. 403 00:13:55,880 --> 00:13:57,120 It makes speed accessible. 404 00:13:57,120 --> 00:14:00,520 On top of that, ANF integrates with the rest of the Azure ecosystem. 405 00:14:00,520 --> 00:14:02,680 It uses EntraID for access control, 406 00:14:02,680 --> 00:14:04,080 snapshots handle backups, 407 00:14:04,080 --> 00:14:06,120 and replication covers disaster recovery. 408 00:14:06,120 --> 00:14:08,760 It's not an isolated tool, it's part of the broader platform. 409 00:14:08,760 --> 00:14:10,560 The real power lies in the combination, 410 00:14:10,560 --> 00:14:12,160 not in any single feature. 411 00:14:12,160 --> 00:14:15,280 Performance, flexibility, and managed simplicity altogether, 412 00:14:15,280 --> 00:14:16,640 you get enterprise grade storage 413 00:14:16,640 --> 00:14:18,320 without the enterprise grade overhead. 414 00:14:18,320 --> 00:14:21,080 Think of ANF as the specialized tool in your storage toolbox. 415 00:14:21,080 --> 00:14:23,400 You don't use it for everything, but when you need it, 416 00:14:23,400 --> 00:14:25,040 nothing else works as well. 417 00:14:25,040 --> 00:14:26,040 That's its job. 418 00:14:26,040 --> 00:14:27,240 Two things you can do right now. 419 00:14:27,240 --> 00:14:30,400 First, if you have a workload that complains about storage speed, 420 00:14:30,400 --> 00:14:33,320 like slow backups, laggy VDI, or long simulation times, 421 00:14:33,320 --> 00:14:34,400 take a closer look. 422 00:14:34,400 --> 00:14:36,920 Evaluate whether ANF could solve that bottleneck. 423 00:14:36,920 --> 00:14:39,000 It might be the fix you've been searching for. 424 00:14:39,000 --> 00:14:40,720 Second, head to the Azure website 425 00:14:40,720 --> 00:14:43,320 and use the Azure NetApp files cost calculator. 426 00:14:43,320 --> 00:14:46,440 Model your workload, especially with the flexible service level option. 427 00:14:46,440 --> 00:14:49,680 You might find that the performance you need costs less than you think. 428 00:14:49,680 --> 00:14:50,840 That's often the surprise. 429 00:14:50,840 --> 00:14:54,840 One caution though, don't migrate everything to ANF just because it's fast. 430 00:14:54,840 --> 00:14:56,320 Use it where it matters most. 431 00:14:56,320 --> 00:14:58,720 For general file shares and everyday workloads, 432 00:14:58,720 --> 00:15:00,920 Azure files is still the right choice. 433 00:15:00,920 --> 00:15:02,480 Save the sports car for the racetrack. 434 00:15:02,480 --> 00:15:03,480 That analogy works here. 435 00:15:03,480 --> 00:15:04,560 So what's the bottom line? 436 00:15:04,560 --> 00:15:07,360 Azure NetApp files is Azure's high performance file storage 437 00:15:07,360 --> 00:15:09,520 for workloads that can't compromise on speed. 438 00:15:09,520 --> 00:15:12,320 It's the specialized tool for the jobs that need it most. 439 00:15:12,320 --> 00:15:14,480 If this episode made ANF click for you, 440 00:15:14,480 --> 00:15:16,160 subscribe to Microsoft Knowledge Nuggets 441 00:15:16,160 --> 00:15:18,080 for more plain English explanations. 442 00:15:18,080 --> 00:15:20,480 Share it with someone starting their Azure journey. 443 00:15:20,480 --> 00:15:21,960 And drop a comment if something clicked. 444 00:15:21,960 --> 00:15:22,880 We always read them. 445 00:15:22,880 --> 00:15:23,800 I'm Mirko Peters.