Hello and welcome to the let's Talk. Azure podcast with your host Sam Foote and Anand Armstrong.
If you're new here, we're a pair of Azure and Microsoft 365 focus it security professionals. It's episode 14 of season five. Alan and I recently had a discussion around Microsoft's Azure backup. It's a cloud based service provided by Microsoft Azure that allows users to backup and protect data stored in Azure and on premise environments. We talked about what is as your backup, what can you backup with it, how do you secure your backups and how much does it cost? We've noticed a large number of you aren't subscribed yet. If you do enjoy our podcast, please do consider subscribing. It would mean a lot to us for you to show your support to the show. It's a really great episode. So without further delay, let's jump in. Hey Alan, how are you doing this week?
Hey Sam, not doing too bad. How about you? Been a busy week, hasn't it? Yeah, busy week work wise. I think the co pilot for security buzz is dying down. Maybe lots of ninja trainings I've seen this week for it, that's for sure. That seems to be my LinkedIn sort of meme at the moment. Yeah, definitely is definitely a lot of the community jumping through that training. Yeah. Like you said this week and last week as well, I think, when it might have been announced. So. Yeah.
I have also noticed that there's a lot of stuff in all of the weekly summary emails that I get for the private preview communities. Those lists seem to just be getting longer and longer in some respects from. The CCP, the new stuff. There is a lot, there's a lot of surveys at the moment. Yeah, lots of surveys. That's just my quick check of that list. See. Right. How much is going on and it's, yeah, it's, it's growing, that's for sure. So some really good updates coming out of there.
Yeah. Okay. Okay. So what we talked about this week. Then, Sam, we are talking about the glamorous world of backups, specifically using azure backup. Cool, cool. I think they're important, aren't they? So you find out about that sort of stuff. So I guess to kind of start off with what are backups? You know, why are they needed?
Yeah. So it's a really core part of any infrastructure, service or solution that you may have as organizations manage and host applications, services and sort of the data that backs up those services, making sure, especially if you're hosting those platforms and those solutions yourself, making sure that you've got a backup that you can actually restore from in the event of, let's say, a disaster, some sort of outage, maybe. You're unfortunately going through some sort of ransomware type of incident. Making sure that you've got your, or even potentially your customers data backed up, ready to restore is critically important. We do have, well, we have technology driven incidents, hardware failure, data corruption. There's a lot of software that is in place to protect against that nowadays, but also there's sort of physical disaster. Data centers and buildings do touch wood, occasionally catch fire, they flood. You know, there's many different potential avenues there. And when we talk about things like ransomware, we're talking about a threat actor group, usually typically human operated, that is looking to encrypt, destroy, disrupt your data. So making sure that you have a, a robust backup strategy is really important. And I think this is, this is one of the sort of challenges of sort of traditionally hosting your applications, maybe on your own premises or sort of your co located machines, potentially. You know, if you, if you do manage your own infrastructure and your own data, you know, it is, it is your responsibility to back up that data. So it might be that you have a completely separate appliance that might be physically located in a different location. You need to replicate that data to that location. So you need potentially hardware and software to do that, keeping it quite high level, because there are lots of different types of systems and sort of silos of data that do require backup. But generally you want three copies of your data in two different locations, one being off site as an example. So having the logistics of having a second physical location in the on premise world can be quite challenging. Does your business have a second site that you can put some sort of backup solution into and say, replicate across two sites? Do you physically have the bandwidth in order to move your workloads data? Traditionally, teams may have backed up to different mediums. They might have backed up to tape physical media, which is all possible. And those systems are there. It's just the, the cost in terms of hardware, software and people to manage those backups can be expensive. And also the criticality of the backups themselves is really important to the organization. It's effectively your insurance policy. If you do have an outage, maybe you just accidentally delete some data in your system. Maybe it's not nefarious at all. Maybe it's just a user mistake. As a very simple example, making sure that your backups are there, they're verified, you test that backup process regularly, is really important to organizations. It is their insurance policy. Alan, in your past life, have you had to handle large scale data backup like on Prem previously?
Yes, in a couple of ways. So weirdly. Not weirdly, but as, as an apprentice. I'm not apprentice. When I was at college, I went to work experience. When they get you to, you know, do a week in a business in it or something like that, I managed to work for a log large organization. And one of my jobs, in fact, I think this wasn't when I was at college. I think this is when I was at school when they did, you know, do it when you're like, I know 13 1415. I can't remember when it is actually you do that. But anyway, so it was part of that. I knew somebody that was in a large organization. Their it, and one of my jobs was to go through to the two data centers in the same building and go and pull out the backup discs and go and take them to the vault and then switch them out with the ones that are in there and then go and put them back in in the right, you know, base sort of thing. So, and then, as you said, you know, that's one sort of copy. And then another time was to get them out. And then I went with somebody and we drove, I know, half an hour, 40 minutes down the road to another site where there was another safe. And then we switched the disk, the other backup tapes there and then went back to the data center. And that was in effect, I think I did. I think that was, I think they were doing it daily at that point. It wasn't like the weekend. No, it's two days, two days a week. I think they were doing it. And that was somebody's job in effect, to go and move that, make sure they get switched out and make sure that, you know, they're not, you know, the tapes are not moaning or anything like that from a media perspective. Yeah. So that was probably the first time I sort of hit that sort of having to do backups.
And. Sorry. Do you think you physically having to move those discs was because of technology and sort of bandwidth constraints at those times?
I think they were. At the time they really didn't have probably another, I don't know actually, because it was probably about 1015 so years ago. So it probably was a bandwidth perspective. Probably not, you know, there wasn't enough there to do it from a disk to disk kind of thing or from hard drive or sans and things like that. Yeah, but it was probably also to do with probably costs because of the, you know, the data being sat on a, on a disk in a safe, a fireproof safe as well, you know, in that, in the main headquarters plus, you know, down, you know, I say down the road half an hour away sort of thing. Yeah, so, so yeah it probably, it's probably more. I think it might have been, you're right, might be of, might have been a sort of technology perspective at that point because it would have been 1520 years ago sort of thing. So you know, your gig, Internet pipes were probably thousands upon thousands at that point, if that was even capable at that point, I guess, but no, and then. Yeah, and then closer to more the recent time then. Yeah. Not necessarily being involved with it but understanding that what we were doing, in effect, you know, of having backups off site to another location that was in another county with another organization I was working for at that point. So that was just, you know, a wan network that was going up to it and then overnight, you know, backups were taken and then stored on locally, you know, on the local site, but also up at the, in effect the disaster recovery site as well. So that's probably my sort of experience with backups one in person and then one, I guess, like you said, over a wan or a network to another site.
Yeah, I've been. I suppose I was quite lucky from a management of backups perspective because as I was sort of getting started as a developer, all the application hosting and management was somebody else's problem, if that makes sense. We wrote the software and then handed it over to other teams to host and manage. It wasn't until sort of later that when I was working with startups, those types of teams just didn't have the, the budget for any sort of physical backup or even really anybody to manage it, you could say. The stakes? Well, no, the stakes overall in terms of the total amount of data were lower, but the criticality to the business itself, because I was working for B two B SaaS companies, being able to roll back data for certain customers was really important and also being able to do that relatively quickly was also important. So the applications themselves handled some element of soft delete, you know, archiving, etcetera at the application level. But I was actually quite lucky that when it sort of became part of my focus, I was sort of cloudified by that point. So I did have access to some nicer tooling.
Cool. Yeah, it's, it's a key, key part really, isn't it, to everything you don't. Sometimes it's missed, isn't it? I think it's like it affects what you were saying there in some like light form, you know, you can't afford it or it's just forgotten about till something happens.
Yeah. And I think, you know, um, it's usually a human process to make sure that those backups are consistent and valid and that backup process and disaster recovery process is, you know, fully functional at all times. Because, you know, I've, I've had it where I've, I've seen it where a lot of the web systems will do like incremental backups on the local machine. So it might keep like, you know, three days or seven days worth of backups on the machine and then it might start syncing to a remote location, you know, and keeping an archive backup there. And I've seen it where all of those remote backups don't work. Somebody's encrypted the backup and they don't know the key or the, it's just been writing blank, you know, zip files as an example to those locations. It's not until you actually need it and then you get saved at the last minute with local backups that aren't truly backups because they're local and not, you know, remote. So I've seen all sorts of bodging and. Yeah, and it's an unglamorous task that goes overlooked, but when there is a disaster and everybody's, you know, pointing it, let's call it the it guy, to get the system back up and running, they're pretty critical at that moment.
Yeah, I guess from a, from a personal perspective, you know, some, where you're not using things like onedrive and things like that, where there's some form of, sort of protection. Backup protection in some form, yeah. Maybe not new actual sort of backups kind of thing, but version history, things like that. But plugging in your usb hard drive into your laptop to take a copy of any personal data, photos, videos, et cetera, where you're not using cloud storage, of course. Sort of thing. Yeah, exactly. Okay, so let's get back to the topic, or the product at least. What is Azure backup?
Yes, I think we've quite well defined that backups are important. There definitely should be a focus on them. So the Azure backup service is a Microsoft Azure, Microsoft managed service that you can use to backup data and items in Azure. But also, you can see, you can back up your cloud resources, but you can also back up your on premise resources as well. So what I like about this is, is that you have one remote, potentially remote to you if you've say, got on premise resources or your hybrid. However your setup is, you do have the potential for a remote backup destination in the cloud. So even if you haven't migrated your platforms and solutions to the cloud, you still do have options here. So why would you use a system like this? If you have got on premise data and items that you want to back up, this is a remote source for you to back up to. You can do short term, long term backups as well. That's all handled in your sort of lifecycle policies with inside of Azure backup. If you are in Azure, there are really well integrated, I'll call it first party solutions for backing up infrastructure in Azure. So a big part of that is infrastructure as a service, VMS, you can effectively store backups and snapshots of your machines directly from Azure because it is managed by Microsoft. On top of Azure, you get a huge amount of scale there. As Alan mentioned in his example of physically moving discs or tape. You have to have the capacity, you have to have the infrastructure there to support that. Can we call it unlimited? It's not unlimited. I don't know what word to use. That is just one down from unlimited. But you have the scale of Azure there to support you in those backup efforts. You know, from a infrastructure and sort of storage perspective, you could effectively call that unlimited. From our perspective, data transfer with Azure backup is quite friendly. Data transfer, there's no ingestion or egress costs directly. With Azure backup, there are some workloads that you will get some level of egress cost, but we don't really need to dive into that on this podcast. But essentially if you're sending, putting your backups into Azure, you are effectively paying for the storage you're using. We'll talk about pricing at the end.
Of the. Sorry, you're gonna say something on. Well, I was gonna say, you know, it seems quite, and from your initial thing, you know, it's a remote site, you know, and it kind of made, it kind of made sense. It was like Azure based on the name, you know. But yeah, from the sound of it sounds very good that it's actually, you know, on premise as well. I'm guessing that's using potentially Azure arc to maybe view that. I don't know if you need that, actually.
No, you don't. As a separate agent, we will talk about that shortly. Alan? Yeah, there's a separate agent that you can use for any sort of, any machine basically or file set that you want to use. Okay, and as well you've got the sort of we'll talk more about security, but when we're talking about Azure, there's sort of an encryption first element always to Azure. So data in transit and data at rest can be protected using encryption, which is usually a big checkbox that you need to check for regulatory compliance and any other standards that you're sort of following. It's all azure based, so all of the management and monitoring is done in the Azure portal. So you get to see monitoring and alerting capabilities inside of there. And it also integrates with Azure Monitor as well to get more stats and insight and maybe feed that into other systems that you're using as well. One big part that I do want to talk about is what they call app consistent backups, and this is a really big point with any backup solution is how you backup and snapshot and make recovery points. With any sort of backup system you, it depends how you approach it and the size of your data. If you've got a very small amount of data, you might just back up the whole lot, maybe on a nightly schedule. As an example. A lot of the times you'll do an initial backup and then you'll snapshot your changes going forward. There's lots of different ways. I'm not sort of championing a specific way of approaching that, but that recovery point and those, those snapshotting points is actually built into the tool itself. So even if you do just have a set of files, it's going to give you that level of capability on top to give you that sort of versioning and restore point access. The other last point I just want to talk about quickly is resilience. So even though this is a singular off site point, you've got multiple storage options. If you use Azure storage you'll know some of these already, but you've got locally redundant storage which replicates your data three times inside of a single data center. So there's three copies of your data just on the, the lowest tier of locally redundant storage you've got geo redundant storage which replicates, automatically replicates your data to a secondary region, usually hundreds of miles away from the primary source of data. It obviously costs more, but you do get more durability if there is a regional outage. And then you've also got on top of that you've then got zone redundant storage. So this is where your data is replicated into completely separate availability zone and giving you the lowest possible risk of downtime because you'd effectively have to have multiple zones going offline at one point. So it really well protects sort of cross region, cross border, that type of thing. So lots of features that are sort of baked in out of the box that I would say if you're rolling a solution by yourself can be complicated to implement.
Yeah, I guess that kind of ties on to sort of what I was going to kind of ask was, you know, because there are a lot of backup solutions out there, you know, because they would have been, you know, from the, not from the past, but you know, everyone do backups on tapes, things like that. Just that the, you know, the volumes changed, you know, as through the, through the, through the years. You know what, why would you, I guess you're kind of answering some of this just by talking about it. But, you know, why, why would you use as your backups over, you know, even managing your own?
Well, I mean I think the scale of the effort that is required to manage some of these technical requirements. Right. You know, to have, you know, geographically redundant storage with high availability, good consistency of backups, you know, having them off site. These in my opinion are more advanced or enterprise grade features if you want to call it that. Some organizations just wouldn't simply have the business model or budgets to even support that type of solution. And we see now with, if you take sort of the world that I used to be part of, you've got some really small challenger companies that integrate with other really large scale organizations. They may be beholden to a company's disaster recovery requirements. If you're transacting with a, if you're a supplier for a larger organization, they might ask to see your disaster recovery policy. They may review that as part of their procurement. You as an organization need to show that you have got a modern approach to your disaster recovery strategy. And I don't believe companies of certain sizes would be able to get to that. If you're an organization of a few thousand people and you've got at least a handful of people in it, then maybe you would have the resources, infrastructure, knowledge and software to be able to actually run it yourself or like many do with the cloud anyway, make that Microsoft's problem, especially for a, should we call it non live like solution or system if that makes sense. This is backups of your data. This is not your application, your platform for running your application. So even if you still wanted to run your systems on prem, then this would be a good remote target. I suppose the only thing that people might be concerned of is sending their data into the cloud and, you know, residency questions or, you know, you know, they're sending up potentially sensitive information. So that would be my only thought of concern. And I also don't really know because I haven't run those systems where the cost benefit or ROI calculator sits on any of this. At what scale do you have to be to go on Prem? If you're storing a terabyte, is it worth you building a second Nas and having that off site or buying a tape drive and backing up? But if you're storing a petabyte, then is the cloud going to be cheaper for you or is it all of that on premise cost? I can't answer that question because I haven't actually had to go through that. But I assume even on Prem, it costs a lot of money to back up at that scale.
Yeah. I mean, not necessarily. I don't know the budgetary side of things, but I think I've kind of been in sort of the discussions maybe not as a sort of decision maker of it, but maybe as a someone in the rooms kind of thing. But the problem, the problem is that when you want to build something like that, you've got to work out your capacity at the start because generally you get, you know, you normally get a budget for buying new hardware and you got to go, okay, well, we need, you know, it's going to last us, what, three if we can, if we can manage it, five years kind of thing, you know, before it starts, you're going out of support and things like that, you know, then you got to go, okay, so in five years time, how much data am I going to have? You know, if we're growing at, you know, 10%, you know, our customers, let's not hope we have a boom of like 50 next, you know, next year because then we're going to run out of capacity kind of thing. So I think that's a key part as well, why you would maybe move to not, let's say, running your own in your data center, because you can't just sometimes just can't understand how much data because it might go the other way. You know, that you think, oh, we're going to, you know, we're going to use two petabytes of data and you only use one and you've got this hardware sat there and you've not been able to know, get the value out of it as well.
Yeah, exactly. And the same conversation is around infrastructure, isn't it? And just, you know, cloud journey. It's just, I think it's just great that we've got these types of options that are so flexible to us now. It's really powerful. Yeah, yeah, exactly. So we can back up into Azure. What can we back up in effect, you know, what can we, yeah.
Holy moly. What can we not back up? Right. I'm not going to dive into these in too much depth because we're already at half an hour so far. It's just talking about bad old days of backups. But on premise backups can be done using what's called the Mars agent. I believe it's only windows, but that allows you to backup files, folders and system state using that agent. As far as I know that is just standalone with network config back to back to Azure. There are also, there's another backup agent called Mabs which allows you to to protect on premise Hyper V and VMware and other specific on premise workloads as well. Azure backups in Azure you can backup Windows and Linux vms that is really well integrated into the actual portal itself utilizing backup extensions. But you can also use the marge agent as well. Directly in Azure if you've got specific files that you want to update. Azure managed disks usually attached to virtual machines is extra capacity and storage can be backed up to Azure backup and snapshotted and recovered from there. Backing up Azure file shares Azure file shares correct me if I'm wrong, Alan is a direct cloud SMB share that you can put files in a lot of organizations lifting content into there because it's relatively simple migration path to Azure files. You can effectively use it to back up those file shares. SQL server running inside of Azure vms as well backing up singular SQL server databases from virtual machines in Azure. There's SAP database backups as well that is supported. There is also post postgres. Postgres servers can be backed up as well using Azure backup. Azure blob storage can be backed up and also Azure Kubernetes service can be backed up. So the list of supported workloads and how you integrate them in the learn documentation, there is a lot of pages on different scenarios for different workloads in different places, if that makes sense because how you approach some of this is different dependent on, you know, is it Iaas, is it on premise? Is it, you know, a PAAS solution that you're backing up? And it's probably worth calling out that if there's a workload that's in Azure that hasn't been, that I haven't listed, it might be that they have their own backup solution sort of built in. So some of the PaaS solutions themselves just have backup in snapshotting built in. So yeah, there's a lot of, I've mainly personally used it for backing up virtual machines inside of Azure. That's generally what I've tended to look at. But even your sort of managed storage solutions in Azure still do need point in time recovery and backups. So you know, even Azure files so that you can get sort of snapshots and recovery points for that. And yeah, so that they, as I went through the list, I talked about SQL server on Iaas in Azure. If you're using something like SQL Azure, that solution has backup built into it. So SQL Azure has its own snapshotting and backup solution there. So I think that's why they've primarily focused on Iaas and on premise workloads because they are usually the gap points for where you might have to bring in specialist hardware or software to do that.
Yeah. Okay. Yeah, I was just thinking about sure, files because it is really in the simplest of terms it is like an SMB server isn't in effect. Yeah, that's, yeah. Without doing a whole episode on it. That's, yeah, that's the TLDR. Yeah.
So yeah, you know, that virtual machine, you probably have your backup solution on it to pull the data. So that might be something that someone, you know, organization might not be moving to because you know that the, you know, fed, it's, you've got no way of potentially backing up or easy to, but actually there is. So that's cool. Okay, so we've got these backups. So how, how do we secure them?
Yeah, so starting off there's a, there's a backup center that can be used and that's sort of got the entry point for a lot of the vaults that you create for your storage. And a vault is, there's two different types of vaults, recovery services vaults and also backup vaults. Recovery services vaults might be something that people have heard before. They've been around forever I'm going to say. Ever since I've been using Azure there's been recovery services vaults. But backup vault is a new newer type of vault where that's used to actually back up newer Azure services. So some of those workloads are backed up in sort of two different areas. But management of your backups is handled in the backup center and it's honed set of RBAC basically inside of there to sort of manage access to the backups themselves. One sort of, so as I mentioned at the start, encryption in transit is you know, just, it's there with pretty much. Is there anything that doesn't use encryption in transit in Azure? I don't think there is. There's nothing that I know of. Let's just say that's everywhere. The backups are encrypted by default with a Microsoft managed key. You can bring your own key to encrypt your backups as you're going into there. But what can be put into your vaults is soft deletion protection and immutability as well. Soft deletion can trigger or completely block anybody from deleting any content from recovery services vault and that can be configured. Immutability allows. If you set it, you can say it can never be overridden and it effectively keep copies of everything forever or not allow you to change copies or delete restoration recovery points. This is really important when you've got a ransomware or a threat actor in your environment because one of the tactics that they will potentially use is to attack your backup mechanism and remove your recovery points. Because the general approach of recovering from ransomware without paying your bitcoins is to actually move to one of your previous backups, restore, secure, restore, and then move forward. So RBAC and access, and also what people can do with those backups is really important. If you, if you have a threat actor that has, you know, global administrative privileges in your environment, you would be worried that they would be able to go in and actually override any sort of deletion and actually start removing things. So yeah, you have the ability to effectively lock that down. There's a few different strategies there. The other one that you've got the monitoring perspective as well. So you've got full access monitoring logs and potential for alerting there for what's going on. There is also a, what's called a resource guard as well, which enables a multi user authorization on a recovery services vault and also backup vaults. So it basically means that a security administrator has to give specific access to a vault for a backup administrator to get access to it. So it's effectively like a front door or a guardian sort of solution on top of it. I haven't seen that in use before. As I was researching for this episode, I saw that. So that would be something interesting that I'd like to go and actually have a look at because, you know, it should only really be in those critical moments or in disaster recovery sort of playback in testing that you actually want to access any of your backups. So actually having this monitoring, logging and protection systems in place, I think just adds another layer of defense for those backups themselves. And if you do have highly confidential data you can sort of double, double encrypt that yourself with your own customer managed key as well. Yeah.
Okay. There's definitely a lot of options then. That's interesting about that guard part as well. Yes. Yeah, I want to give that a try and see how that works in.
Yeah, because, yeah, I was gonna, I was just gonna quickly talk, not necessity talk about, but just sort of discuss that, you know, I suppose you could have multiple vaults or recovery vaults depending on the service and have our back separately in each of those depending on parts of the business it versus your application sort of stuff. So there's no crossover or even like one for the actual customer data kind of thing as well. So yeah, you've got that, but like you said, you've got that next layer of, well, okay, if you do need to access it.
Yeah. And you're completely right and it's probably worth calling that out that you can have as many volts, well there must be a limit, but you can have as many volts as you want and you can segregate your data in whatever way you want to, you know, so you have got these levels of protection, but then you've also got segregation of the data as well, which is again something that, what would you have to have like multiple machines, devices, tapes, physical to sort of do that? Yeah.
And yeah, it's probably worth also just talking about how data transits because that's a big talking point for security of a lot of organizations. For Azure vms, your data transit remains easier inside the Azure backbone network. And for on premise you can use express route virtual private network to connect to azure to sort of protect that traffic in transit if that's what you've got in place and that's what you want to use so you don't have to sort of transit over the Internet, Internet, so to speak, if you, if you don't want to. Yeah.
Because in effect you said it's going to be SSL anyway, which is whether you want to control the SSL, that it goes inside the SSL. Yes. Yeah, yeah, exactly. No, that's cool. Okay. Well it sounds, obviously, it sounds, there's a lot there. I guess the, the big question is how many, how many dollars, how much it costs to use and to store data as well.
Okay. So I'm just going to talk about a couple of, it's priced per sort of different workload basically. So the different types of items that you're putting there. Let's talk about azure virtual machines to start off with and sort of the pricing there. So you pay an initial price per month based on the size of the instance that you're backing up. So if your instance is under 50 gig you pay $5 a month base. If it's between 55 hundred you pay $10 and if it's over 500gb you pay $10 base price per 500 gig increment. Basically at that point that's the size of your virtual machine disk. Then you pay for storage consumed on top of that. So you do pay per instance and then an actual storage cost on top. I'm not going to go through the price it's charged per gigabyte. Basically, you know, LRs, ZRs, GRs, it all ramps up in terms of pricing there as well. If you are storing a lot of data, you can also do reserved pricing. But just to put that into perspective, the 100 terabytes a month standard tier at one year reserved is $30,000 a month. So when you're starting to get into reserve capacity, you're at those much higher tiers of deletion, sorry of sorry of backup. It's interesting, it says per month as well, because obviously you might have a lifecycle policy in place where your backups are actually being removed. So it's like a per gigabyte per month storage model, like I previously said. There is also, there are two tiers of storage. Actually it's probably worth talking about. There's a standard tier of storage which is sort of hot, immediately accessible, and there's an archive tier as well. The archive tier is substantially cheaper, but there is a sort of a rehydration fee when you want to restore data from your archive tier to your sort of standard tier as you go through that process. So there are ways to reduce cost further. If you are archiving because some backups are archived just for compliance reasons, let's say you have to keep your data for ten years or 7810 years. Whatever your company retention policies are with your different systems, you might just mainly be using it for backup, not necessarily operational readiness. You might keep the last three months, three months, six months. Everybody approaches it in a different way of sort of backups live so that you can restore in the event of a disaster. But then you might be archiving long term archiving data for sort of data retention purposes. Let's talk about Azure files. If your Azure files instance size is greater than 250gb, you pay $6.25, $6.25 per month and then if your instance size is over 250gb, then you pay 60% of the cost of the instance price per month to back it up. So there's just a flat sort of backup cost basically there. I won't go through any of the other workloads. We could talk about on premise servers. On premise servers are basically the same pricing as Azure VMS. The only difference is that there is no archive tier for on premise machines. So the standard tier pricing is exactly the same price per gigabyte. It's like two cent per month for LRS, three and a half cents per month for ZRS per gigabyte. And GRS is five cents per gigabyte per month on the standard tier. So yeah, some good flexible options there. It's all sort of pay for what you use with some base pricing. So you can get a lot. Let's say you had, let's say you had your, let's say you had a SaaS application that was hosted on an Iaas server in azure. Unless it was all just on one box. It probably shouldn't be, but let's say it is for this example, keeps it simple. You could quite quickly have azure backup on that machine for $510 a month plus price per gigabyte for what you want to store and how long you want to store it for. So again, like we say with a lot of the other solutions, if you're a small company, you can get a lot of benefit from these tools with a very little starting cost. Like I was saying, once you get into the hundreds, tens or hundreds of terabytes or petabytes, where does the, you know, Roi sort of break even or change? I can't answer that question to be totally.
Yeah, okay. That's really good. Yeah. Like you said, it's quite an easy, uh, less least friction to, to um, entry kind of thing. Um, so yeah, cool. Okay. Is there anything else than Sam you think about?
Nothing else for me. I won't talk any more about backups. They, they aren't that sexy, but they are important. So I thought it was worth doing an episode on it because for me the backup service is something you might enable and sort of forget about or use it, but it can back up a lot more than what we've really ever used it for. Yeah. Okay, cool. So Alan, what's the next episode?
So the next episode is going to be a bit of a recap on an episode we did a while ago, and it's going to be around entra global secure access. So we did. I think we did it. We did an episode when it sort of was announced that it was either last Microsoft secure or ignite. I can't which one it was. Yes. So a lot has changed. A lot of it's now more publicly accessible for going through it. So I think it's worth running through again, what it is, what it can do, what's the sort of two or three parts to it and in effect, you know, what's the benefits there? What can it potentially help with or what can it potentially, you know, what products can it potentially replace? So I think it's probably a good one to start. Coming up. It's in public preview at the moment. We're waiting for it to go ga. Generally available.
Yeah. It's worth bringing back up to the. To the top again, I think. Yeah. Nice. Yeah. Lots of excitement around that product. So, yeah, it'd be good to get an updated, you know, overview of it. So. Great. Yeah. And it might get out of my system because I know I keep going on about it.
Yeah. I know I sort of joke with you, but everybody that I have heard, you've explained it to people and everybody's been like, oh, I know somebody that could really use that. Or if you've talked to an organization, they're like, that seems really, really handy. So I've not really seen any pushback on it. So it seems like a very exciting product that's coming. Yeah. Yeah, exactly. So, yeah. Talk about it next week. So. Okay.
So did you enjoy this episode? If so, please do consider leaving us a review on Apple or Spotify. This really helps us reach out to more people like yourselves. If you do have any feedback or suggestions on episodes, there's a link in our show notes to get in contact. Yeah. And if you've made it this far, thanks ever so much for listening, and we'll catch you on the next one. Yeah, thanks. All.