This week we took a break from best practices and procedures and talked about some hot news - AWS starting to charge for public IPv4 addresses - what should you do? How to mitigate, when does it start etc.
The other topic was Israel's shiny new region, pricing, reasons to use and some AC considerations if you ever decide to build your own data center!
Links
Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops
This week we took a break from best practices and procedures and talked about some hot news - AWS starting to charge for public IPv4 addresses - what should you do? How to mitigate, when does it start etc.
The other topic was Israel's shiny new region, pricing, reasons to use and some AC considerations if you ever decide to build your own data center!
Links
Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops
Yeah. Oh, I'm ready and actually, hey, hey, hey, hello. So I am a other one and welcome. Hello. It's like an episode on steroids. Hey, welcome to DevOps topics. Yeah, okay, bye bye. Thank you. See you next week. Okay, thank you. Bye bye. A episode number 29. Today, we're going to talk about AWS region in Israel and we're also going to talk about on the stakeholders about this week about the addresses in AWS, which will start costing you money soon enough. So we are very AWS oriented. Have you noticed that? We only call about AWS. It's like nobody else exists on AWS. I mean, they are kind of like 60, 70% of the market, right? And that's only because Microsoft are considering every office 365 as an Azure user, which is not really fair. I think most of the users are in our AWS, most of the internet. Well, I'm going a bit far with that, but a lot of the internet sits on AWS. So what are you going to do? Okay, so let's continue with AWS. So today's topic, we're going to start with AWS region in Israel and its implications in Israel or any other region that AWS decides to deploy its data centers in and the implications. Okay, and how fun it is. And we're also going to talk about it on a scale that's already about IPv4 and the newly costs of IPv4. So we'll start with the set path IPv4 and that we need to pay for that. And then we'll move to the AWS region in Israel because it's way more happier than IP addresses. So when I say IPv4 costs money, what's the first thing that comes up to your mind? Okay, so newsflash, AWS will start charging that. If I'm not mistaken, that's going to start on February 24. All right, so we have like what six months to prepare ourselves? Okay, so I think in February 2024, they're going to start charging for every IPv4. That is AWS generated. That means regardless if you're holding an elastic IP or just a random public IP, which we'll say what these are in a sec, there's also the option in AWS to bring your own range of IP addresses. If you own some in your data centers, you can bring your own, obviously, for these, you won't pay because they are yours. Now, when AWS, you have two, I think two types, correct me if I'm wrong, two main types of public IP addresses. There's ones that call elastic IPs that are they're kind of bound to your account. There's a kind of static, I'm not sure why they are elastic, but they're kind of static IPs, right? Yeah, I think it's elastic. I think I just have the conversation with our marketing on why AWS call everything elastic. Some of it is elastic. Some of it is and I think it's elastic in the sense that it's the cloud, right? You can create some and then delete them. So it's kind of elastic. But it's like an address. That's the idea. Elastic IP, when I think about it, I'm like, okay, I need a static IP address. Right, right, right. I get an elastic IP address. That's weird. I'm saying the resource is elastic in the sense that it can be provisioned. You pay on demand by the hour and then you can delete it. So you will not convince me. Yeah, whatever. I'm not able to do this. Okay, okay. Okay, cool. So you pay for elastic IP addresses. So elastic IP addresses, I mean, till this day, if I'm not mistaken, they would only charge you if that's not attached to something, right? If you take an elastic IP and you detach it to an instance, attachment, right? That's what it's called an attachment. That's considered. Okay, maybe it actually works. And association, correct? You're right. So if it's associated, there's nothing to pay for because it's in use. They just don't want to create waste of IPv4 addresses, which are kind of scarce today. And the other type is the random, random, what were we going to call them? The non-EIPs. No, random, I like it. The random is like, it's good. Random, random public IP address. Exactly. So if you have, I think it's a subnet configuration that you take provision public IP addresses for every resource or instance, then everything that comes up in your subnet, everything that's being provisioned, everything. I mean, most, I mean, 9 out of 10 times, that would be an easy to instance. They would be provisioned with a public IP address. Even if they need it, even if they don't need it by that, I mean, if it's connected to an subnet is routed through an internet gateway, it makes sense in some way. I don't not always, but it makes sense because you can access it from the outside world. If you're running in a private subnet that's attached to a net or not attached to a net at all, it's just a black subnet, then there's no point in attaching a public IP address, right? You don't need them. And from this day on, you're going to start paying for them. So I'm guessing that's AWS way of like not forcing you, but encouraging you to not provision of course the private ones and keep in mind what you use for in production for the public ones. Now, I think it's important to say again, what would you say? I think I could compute not provision for the private ones. We don't care. I mean, nobody cares about the switch day of why won't I provision public addresses for everything that sits in my subnet, other than the security measurements, right? I don't care. That's going to start costing you money. And pretty much, I think it was, it can get to thousands of dollars a month for a very small workload. Okay. Like dozens of dollars per instance per month, if I'm not mistaken, it's going to start costing you something substantial that you start considering it. So I think that's your way of encouraging you to kind of. I like it that, you know, security is not encouraging enough, but money is money is more encouraging than security. Yeah, because it's not, it's not the type of security vulnerability that everything is exposed. It's only if someone managed to hack through the way into the internal system or someone misconfigured something, then it would become an issue. But yeah, you're right. So that's it. That's about the addresses and what they're going to charge for. Now, oh, I wanted to say something, it's important to say AWS takes pride in not raising prices, almost ever. I think the last time they did something like that was substantial was 2016. Check me on that, I'm not sure. But they're known for saying we don't take, we don't raise prices. They have a lot of other ways, obviously, to make the revenue go up. But this is the first time that they're actually saying, this is what it is to cost. It's going to cost higher from now on. And it doesn't seem like for the, it's not the obvious reasons of other things we're used to. It's, I think it's an encouragement to keep IPv4 addresses alive. And that's what I think. Other than that, they want to push us to use IPv6. So that's an option, but it doesn't seem like the world is going there. IPv6, everyone was, we're very encouraged to go for IPv6s in the past. Let's just tell them to be basic lines. We have a baseline, IPv4 is what we all know, like four octets, we can say that we have just numbers, like, you know, 22.22.22 or any other subset in four. Yeah, that's the same on the base. That's in my base. And then you have the hexa, you know, IPv6, which is hexa-based, will you have four six days? Like four, like instead of having like a octet, a bit, you have like four hexa bits for each representation. So it's 16 bits of hexa. Yeah, and it's longer. So more options. Okay, bottom line, we have way, way like like exponential more options, right? Yeah. So it's way, way more options will probably never end the IPv6. Right. Hopefully, maybe when we get to everything is like internet of things and stuff, that mean maybe we will reach half the options of IPv6, but that's way, way more options. Yeah. So if we push over there, like, if we, let's say I have an EKS cluster, let's discuss it, discuss this. It's also discussed, disgusting, but let's discuss this, because let's say I have an EKS cluster and everything is working and I have, maybe I'm a very, very, very large company and I have tons of public addresses, because some of my services are public, no idea why. So we do you think it's feasible to just say, okay, guys, let's move to IPv6, that you think like it's a long migration, short migration, takes time to resell. What do you think about that? I have, I have to tell you something. First of all, I'm not 100% sure. Sure. I think it's feasible and technically possible. It will probably take some work, but I went and read AWS, obviously, when they publish, they went public with this announcement, they released another segment that said, okay, here's what you can do. Here's what we're going to charge for here is when it starts and here are your options. And they did not, if I'm not mistaken, I think read it yesterday, if they did not mention IPv6 at all. So they did, yeah, Jeff Barr posted some blog post about saying, listen, I know it's going to cost money, but we encourage you to shift to IPv6. So it's perfect that you're saying that. I think I read something else, not by Jeff, but I'm just like a traditional, not traditional. There's the shared blog post they do with other companies, and it was like a company public releasing something within the. I'll share the link to Jeff Barr. Perfect link so you can attach to the video, right? So I'm repeating what I said. It's a great idea. I was, again, I was, I started by saying, I'm not sure why didn't they say that, but if Jeff Barr is saying that, then yes, perfect. I do think it's feasible, but I want to ask you first, putting IPv6 aside, which is a great option. What else do you think of doing right away? If I'm telling you, it's not February, it's going to be October this year. What are your first steps? I'd ask, Chad GPT please write a script, the scans, all my subnets in every active region that I use for the checkbox assigned public IP. So just to just to realize which subnets when they provision your resources are going to use public IP addresses other than that, I would tell Chad GPT to please list like a script to get all the list of IP addresses and if they are associated or not. So just to get a bit of information about how am I using public IP addresses, you know, this is what I would do to see what's going on in my account. Okay, let me go a little bit further and be annoying. Do you need public addresses within your public subnets? Do you need them? No, usually like if I go out to the internet from any subnet, usually it's from not gateway, I mean, I barely use public sub, the only public IP addresses that I use probably is for the network called Baransale or, you know, if it's AWS, application on Baransale, it's a scene name, it doesn't even have a static IP address. So only the not gateway has an elastic IP address and that's it. I mean, but these are the public, the private ones. And the public ones? Not that I can think of. Maybe so, so Lambda in VPC, maybe if you wanted to run in a VPC, but not in a private subnet, but in a public subnet, and not go through the not gateway, no idea why. So maybe, but what Lambda's? Yeah, maybe Lambda in VPC would try to- The reason is latency, obviously, because running inside of VPC requires you to attach and network interface to Lambda. But you can decide on which subnet. So if you deploy it, if the Lambda in VPC runs in a private subnet, it doesn't need a public IP address, right? Because it goes out to the internet from the not gateway. Right. Right. So I'm saying, like, if it's a Lambda in VPC, which is deployed in a public subnet, then it would cost a lot of money, probably, I'm not sure. Yeah. See, it's like everything that I say is like off topic, it's like not off topic, but edge cases, right? I'm not sure if you need a public IP in, I don't know. Okay. Let's go through the first thing that I had in my most of my developers. They need to provision, I mean, again, we're a company kind of a DevOps company. Every test that most of our test is running against AWS or other cloud providers, APIs. So we need to provision a lot of resources just for tests, like huge fleets of instances and block storage, etc. And they put everything up with public IPs. For the sole reason that they say, we need to connect to those instances, we need to see what's going on. We need to, whatever, what's your answer to that? Yes, it's then perfect. And that's by the way mentioned by AWS, stop using SSH. It's just a, it's not a bad method, but it's, it becomes a bad method. But that's between us. We just talked about, okay, let's talk about it. We understood each other now. Let's say perfect. Perfect. The easiest way for you to get a shell on an instance. I don't know. Let's touch on why would you need a shell? But if you need a shell on an instance, the easiest way for you is to use a SSL SSH, which is a secure shell tunnel. And what you do is there's, there's a pair of certificates, you have the public one and the instance holds a private one. And then you use the two keys to communicate with each other, authenticate yourself against the instance. And then if you're authenticated, you get a secure shell on the instance. That's SSH. Now, this creates a few problems. First of all, you need access to the instance, like network access. So if that's a private instance, for example, even if there's a nut, there's no way for you to access it directly. So you need some kind of VPN or a jump box. And that's a beginning of our problems, right? These are just the two of things I mentioned are a security kind of attack vector. If you don't protect them well, so it's a problem. The other thing is a lot of companies and a lot of users, they share keys because it's hard. If you didn't provision the instance, then you didn't get to say what key it uses for connection. So you need someone else to put the key there. The easiest thing to do is to just share the key, right? We have a key, it's called staging something something company.com. And we share it with other developers. And then it's easy. You just pick it from the list when you provision resources. You let others use it, right? What if the key gets leaked, everyone can access it now, especially if it sits in a public subnet? That's a problem. There's a service that you mentioned. Can you give like before we move to the service? So there is, I don't know if you have it in mind, but there is an alternative to what you said. So instead of sharing the key that the client key, the one that is shared with between the users, every user can have its own key and then access the machine somehow. So yeah, the old way was to let AWS use AWS has its own it used to be for Git purposes. AWS have their Git service cloud commit, something commit. And so on the other way, I really meant like the bell metal way. No, no, yeah. Oh, mate. Okay. So you'll say yours at the old way. And I used to use it that there's Git commit. It's a Git server by AWS. You could have the fact that it's Git means that it had to hold a set of SSH keys for cloning and stuff. So you could use that to update instances with your own automated tool to kind of sync users keys to the instance. So when a user joins, you create the key for them for a Git commit and then it syncs to the instance. It's a lot of work, but that's a safe way of managing stuff. And then when someone lives, you delete the key from the instance, a lot of work. The new way, I think AWS today, they can connect you with the instance and immediately when you have users within IM or SSO, they sync it into the instance, and you have a secure tunnel. But again, that doesn't save you from having to access it through the network. And now I want to talk about the service. But before you don't, yeah, I have like the hybrid bed, but okay, but quick and healthy way. So instead of sharing, let's say me and you, okay, you have your own key. I have my own key. I'm the one who created an easy to instance. Right? Yeah. So now only I have access to the easy to instance, what I can do, I can SSH to this is to instance, then in the home deal in the dot SSH, there is this authorized keys, remember this file? So the authorized keys, I can tell you all mail, what's your public, what's your public key? Public, public key, please give it to me. I want to add it to the authorized keys of this instance. And then even though, even though in AWS, we configured that my key is the one that is configured as the key pair of the instance, you will also have access to the instance with SSH. Right. It's not as safe as you mentioned, because it means you need to manage it on your own, it means someone needs to have access to the instance, but it's better than sharing my key with you for sure. Yes. That's, by the way, that's that's a way to go. That's what C said means used to do. And I guess are still doing when they want someone new to access, like static servers on prem. That's what you do. You add to the key, authorized release, okay, authorized keys. If you want to add more people to access the same instance without sharing keys with each other. Ideally, ideally, that thing is, is being synced from somewhere. Even do you remember using a bin stock, did you ever use bin stock? Mm hmm. Cool. So bin stock has this, there was a dot e b something, there's e b configurations or something, there were configuration files for a bin stock. And when you'd use bin stock, you can put public keys and just commit them, and it's public, no problem with that. And it would sync to every new instance. It would sync the keys in there. So that would kind of help you. Service. So there's a system, we talked about it like a thousand times. There is AWS has a service that's called the systems manager, systems manager has a lot of features within it. It's just a way to control a bunch of instances, a bunch, I mean, by tag, by name, specific instance, and just communicate with it to do something. It can be running a command, configuring something, SSH into a server, like, not SSH, but more of getting a shell. And the way it does that is with an agent, this agent is pre-installed on every instance you put up as long as the AMI is coming from Amazon. And it's just in hibernate mode, unless you give it permissions to operate and you switch it on, right? So with SSM, you can run and get a shell the easiest way is to just right click on an instance, then go to AWS Connect. And then you have a few ways. One of them is the session manager. You just click within your browser connect and you get a shell. This is kind of with windows, by the way, you also get remote desktops, so you can actually get the RDP. I don't know if you know that, but with windows, you can get RDP, not just shell if you listen. Really? I thought you'd always have to go with windows. There was another kind of process you had to go by obtaining administrator keys. You'd have to create another, there was another request. Like, I want to generate administrator keys with the instance, no? It's like that. Okay, so the keys, okay. So for a shell for shell, you know, skill shell, it's the same for windows and Linux. So both in windows, you get into parallel shell, in Linux, you get into batch or shell or whatever. And in windows, you also get the remote desktop where you can download the RDP file. And then you need to decrypt the administrator password by providing the five LLA of the instance. That's the thing. Okay. Let's go up, let's close all the sub threads we opened and go back to the, where were we? Okay, SSH with the service. So SSM, you can get a shell. And again, we both talked about it like a hundred times within the podcast. If you don't like the browser shell, which I don't, you can download the plugin from AWS, we can put it again in the links. There's a plugin that kind of integrates itself into your AWS CLI. And then you can run the command that says AWS, SSM start session, provide an instance ID. And this SSH into an instance, without you having to use a key, you don't need to have network access to it at all. It can be a completely private instance within a black cabinet that doesn't even have an app and you're connected. And that's it. That's the simplest way ever. No need to authenticate, no need to share keys, no need to nothing. And it doesn't cost money. It's just there. All you have to do is pre-provision your system to work that way. If you're a developer and you have a DevOps team or an ops team, just ask them to do that by default. That's it. I want to say one more statement. By the way, and I want you to attack it. But do what you talked about, SSM and SSH and whatever. So the reason we're talking about all that is, as you mentioned, people are people, DevOps engineers, developers are provisioning publicly sources just to SSH to an instance, even though there is an easy and more secure solution for that. So if you're provisioning instances, lambda functions, containers, or anything that uses public IP addresses, and you want to access those with a in a safe way, you can SSH with AWS SSM systems manager that I don't know mentioned. And then it's safe, you don't pay money for public IP addresses. And that's it. So what else you want to say? One more sentence to say. Just a correct one thing. You cannot do that with Lambdas. You cannot access Lambdas unless there is a very specific way of kind, not really SSH, and we're getting it. Yeah, obviously. So correct. It's for reduction of cost as of February 2024. I wanted to say a statement, and I wanted you to attack it. I want to say this, and I know it's extreme. But I think developers do not have any reason at all to SSH into instances on AWS. What do you think? No, I'm thinking. I don't know where my gun is. Yeah. I'm analyzing the question. Okay. What's the, what's the top present to SSH into an instance for the developer? If something goes wrong, something goes wrong. And then what? Well, yes, I'll tell you what. Okay. Something is a DevOps engineer. Sometimes, let's say you're running. You're so posted. Yeah, I should be runners, right? Yeah. And one of them maybe is stuck. By the way, in when you do a lot of research, like machine learning and stuff like that, so you might get a lot of zombie easy to instances, some some services that are like forgetting about an easy to instance, and you're not sure what's going on with it. Okay. It's weird. I know, but people on the line, our crowd right now are like, yeah, man, he talks exactly what I'm experiencing. Okay. So it can happen if you can have a zombie instances. I admit that you need to fix the root cause of that, but for time to time, it can happen that you need access to an easy to instance to see what's going on. I'm with you. I'm with you 100% things go wrong. There's nothing to do about it. I want to say what's when things don't go wrong. When things go wrong, sure, go ahead as the same SSH, whatever you probably do need to keep an a key somewhere to back up yourself, when things don't go wrong, when that's the procedure. I think, okay, I'll say what my experiences, developers are just SSH into instances to read logs, the application logs. Why? Because it's test and they did not export it anywhere. It's just a random easy to they put up and they install something on it, and now they want to read their logs. And I'm saying, there's no reason to, if you'd connect it to CloudWatch or export it to a shared collector or something, it would work better. Now, like small print developers are not DevOps or Ops engineers. I don't think that's a good thing. I do think they should have the capabilities, but most of them aren't. That's just how things are. And there's no reason to be mad at them. I think we should help them. We should provide some kind of a template. It can be CloudFormation or Terraform or whatever to help them do exactly that. When you provision an instance, just provision it with the best practices, like shipping logs, metrics, and everything to help them stay away, by the way, enabling us to send. And everything they can do to help them stay away of travel. Travel is having to SSH. Travel is not having us the same. Travel is not having logs. Travel is all the AMIs, et cetera, et cetera. It's just provide the template. Another dimension. I think I'm quite happy because I think I'm the only one in the organization that SSH to an instance. And that's only because some of the CICD channels that we have are like windows channels. And it takes a very long time to live provision a Windows machine, because it's very, very heavy. So from time to time, you know, you want to maybe clean it up from Docker images. And even though you can do those things automatically, sometimes there's two important information on the instance. So you don't really want to do an automatic cleanup. You want to make sure you're not doing images that are important and stuff. So from time to time, you know, talking about in every few months, if something is like, hmm, let's see what's going on. I connect to an easy to instance with SSM, by the way, but that's it. Like I don't really connect to any instance or yeah, because there's no reason for that. No. Perfect. So that can think of another hard statement I'm going to say, and it is a little extreme. If you find yourself often having to SSH into an instance, you are doing something wrong. Your automation is not as bulletproof or as good as you think it is. So you have a lot of work to improve it to a point that you don't have to. Sure, things happen from time to time, you have to. There's nothing to do about it. Nobody's perfect, but not as a, not as a normal procedure. One last thing for me, that AWS said about the costs of addresses is that they're going to integrate it into your billing as a new entry into your COR, the cost and usage reports. So that's a very complicated report that you can read from your AWS billing, analyze down to a very fine-grained level of what's going on. What did you pay for? They're going to add a lot of data there to help you analyze how much you're paying for addresses, where can you save, etc, etc. They're going to help you, I think with a tool inside the billing to show you how much you're utilizing elastic IPs and how much you're utilizing public IPs. So maybe that can be helpful. I'll leave a link to the blog post below and to yours, the one that you mentioned from Jeff Parto, to help you. There's also the one from Jeff Parto that he wrote where there's a new feature in VPC for, as he said, for the cost. I'm not sure I haven't read about IP addresses in the cost usage, but I saw that in the VPC, like in the actual VPC, new region, you can see a feature that reads like how many IP addresses do I have, how many of us associated, how many of us, how much IPs are done and stuff like that. Okay, that's a good segue to move on to the IPv4 done. Moving on to the news flash about AWS in Israel. But first before we begin, I must say that we already have AWS in Israel, maybe not data center in the region, but we already have a cloud font edge location. So that's not the first, let's say data center. That's easy. But still, but still, it's not the first thing ever. We have offices of Amazon in Israel. We have an edge location of Amazon in Israel, and now we have data centers in Israel, which is like every other region that we see Ireland, London, US, East one, you know, North Virginia, or whatever. And let's start to talk about that. And I'd like to start by saying, do you know the pricing, and if you don't, can you guess the pricing in Israel? I read the number, but it was the number that they announced when they started the project. No, I mean, let's say S3 storage. Okay, so as we, I hope as we all know, right? Oh, oh, let's see if we know the numbers. The cheapest region in AWS is from all of us. This is one version, US East one, Virginia, right? And also all the new features of AWS, better features, whatever going to, North Virginia, and those. The one with the most availability zones, one with most chances of you getting your instance, etc. Okay, so US is one, it's like you'll go to if you want new features and the lowest one, but again, it's in your United States, so topic latency, whatever. Regulation was popular one. So yes, it's the largest one, but it's the most popular. After that, okay, after that region, we have Ireland, Oregon, Oregon, in the United States. I mean, like, let's say to another region. Okay, so Europe, yeah, to Europe. So let's say the most, the cheapest one, and that also gets the newest features and whatever in Europe is Ireland. Yeah. Okay, and it's again, the most popular in Europe, cheapest, whatever. So if you want to compare region to region or stuff like that. So in United States, I like to compel everything to US East one. And in Europe, I like to compel everything to Ireland. According, this is like my zero, you know, and according to that, I compel prices. Okay, one of the most expensive religions in Europe, can you guess? Maybe you know them? Frankfurt, actually, you lived there. Oh, London, yeah. Okay, yeah, it's very niche. It's very niche. I'm not considering that origin. London is also very, very expensive. And did you know that still, a village and is more expensive in London? Well, as it is, check the S3 prices. It's like a few, a few more sense, but still, it's more expensive than London. I just have an idea. Do you think they align it with the cost of restaurants? Not as just restaurants, just dining, fine dining. Yeah, I mean, so the pricing right now is crazy. Okay, as as far as I say, I'd say, because it's, if you're using AWS, taking a, if you're a big customer, and you decide to move to AWS in its little compelling to an Ireland, probably your thoughts would be because Omele, but I'm all, why would you move? Either latency or legal reasons? Exactly. This is exactly what I would say. Latency or regulation, right? Let's talk about legal reasons for a second. Shoot. If you're a big company, you probably have users within Europe. If you're running with customers within Europe and you hold what they call PII, private, identifiable in personal identifiable in, anyway, private information of the customer. P, P, something like that. Yeah, whatever. I don't know, fees for personal health, health information. That's for HIPAA and stuff. That's for HIPAA. Yes. Okay. So this is just standard, sox stuff, the basic stuff. You need to comply with GDPR. GDPR since 2018, I think it started. You have to hold the information within, I hope I'm not messing it up, but you have to hold the information within the area that you're compliant to, right? If it's European customers and they, uh, is it an application? I'm not sure. We have to read it. I have to come back with that. I know that you also need to delete a data, like if they, if you get a request, you need to delete it after 24 hours or something like that. And you need to provide the right to the right to be forgotten or something like that, which basically means if a customer wants to be deleted, you need to guarantee that everything is gone from all of the servers. And I think in some areas, for example, German customers, you have to have, uh, services deployed within Frankfurt within the, the realms of the country for legal reasons, but you can correct me that. Anyway, yes, legal or latency. Um, Israel in that sense, I don't think helps you a lot other than latency because it's not EU. It's not part of the European, um, union. So it's mainly for latency and mainly if you want to have that. Can you see if it's in the middle? You know that the US government uses AWS. So now the Israeli government is going to use AWS is why they approved it in Israel because they want to use it. So finally, the you the Israeli government is going to use AWS with a small caveat. I think they have an agreement with both AWS and GCP. If I remember correctly, they have an agreement with both. Is it GCP or Azure? I can remember now one of them. It was AWS and another cloud and they signed an agreement with both. And that's what led them to open the, or to announce the project. Um, do you know how much the project, how much they say it would cost to put up the status center? I read the numbers. I'm not 27 million. Maybe they said seven. I read 7.2 billion dollars to put it up. Um, I may be a more I'm talking about is like how much money they're going to spend until 20 37 or something like that. But they said they're going to invest money in Israel until 20 37 and each year we're going to have 7,700 new jobs every year for people in the country. It makes total census. It makes total census. And the last thing about it that they call, I mean, if you're not Israeli, let me tell you something. Israel is such a small country. It takes you like what five hours, six hours to go from the longest path you can go from one and to another. In the shortest path, it takes like 30 minutes or something. Um, Israel has it named like other regions. So this one is called IL central one, which is funny enough. If you try to put something as far away as you can from this point, it's like an availability zone. It's not even another region. What bike was called it? IL central one. As if there's going to be IL south one, two, three, you know, but I guess that's just a convention, but it's so funny. I guess. I guess. Yeah. So it's probably because of the convention. It's funny that we have, we might even have another region, you know, soon, even though it's not possible because it's going to be an availability zone. Yeah. Yeah. Yeah. Also, you know what I thought about about, it's funny, just because it's Israel and I don't know if people are listening. No, Israel or not, but it's very hot in Israel. So can you think about the AC, the AC and the effort that they put first, maybe to put it underground to maybe make it even cooler, you know, no, that's, that's why maybe that's why it costs so much seriously. I mean, seriously, think about the electricity that they're going to pay, how many solar panels maybe they have above. So what I would do, I would dig into the ground, build everything underground, put a solar panels above all this area, but then the cost around it with, you know, with a fence, so nobody would get near. And that's it. I have a farm of data center and whatever, you know, I know AWS went far and beyond with, with the original AWS on the story on the United States grounds to put it in the coldest place that they found, the snowiest places, mountain valleys and peaks, and they had all this geographical computation in Israel. It's just, it's all desert. So you need to invest so much in cooling and making sure it's maintained well. I'm guessing that's part of the complexity and the place. Think about GPU, like GPU are usually getting way more hotter. So you, you'll need way more AC, way more, wow. I wonder how it's going to work with electricity. Seriously, I mean, it's going to be a thing because if you have suddenly, you know, a peak of tons of silvers, you know, sometimes in Israel, we have those days where the electricity company, where the electric company says, listen, this is the hottest day. We're going to have sometimes a stop, like they're going to stop the electricity in, in area, because they consume too much electricity. No, I have an idea. Maybe this would be a winter region. And during summer, it will just be re-routed by our universe. Okay, so because it's, it's hot, it's going to be funny. So this is why I won't talk about the implications of other regions. So I guess every region has its own complications. Also, I'm not going to delve into it. I'm not going to dive into it, but it was funny to me that now in this whole political and we're not going to get into a word of that, but there is like a political situation in Israel right now. There's no war, but there was a political situation. Okay, it's not like we're cool. Okay, it's a bit hot in here politically. We got a lot of protests, not cool, right? Even though, even though we have this political situation, AWS decided Amazon decided to invest in region in Israel, which really surprised they announced it like three or four years ago. It doesn't matter. When you see this political situation and you realize you will not invest, it's better to lose upfront five billion dollars than to invest more 20 billion dollars, like and then lose it all. You know, I agree, but it should be like an assumption when you build something as an Israel, I'm saying that when you build something in Israel, you need to expect everything. Not war. They know they know they don't know. It's the Middle East. It's the Middle East. Look, you can be the best of the most. Yeah, you can be the most modern democracy in the world, or at least think of yourself as such. If you're in the Middle East, and if you're in Israel, it's hot. People are angry. And yeah, Israel is not a simple country. And you need to expect everything. This is one of the things you need to expect. Yeah, so I was happy that during this whole political situation, Amazon did continue with this move. I know they decided like, yeah, but we said it two years ago. And when they decided they're really going to do it, and it's going to be generally available. By the way, this is the first time AWS announces religion with the least services available ever. Did you know that? Yeah. Yeah, by the way, I wanted to, I would like had to have my own VPN, because I need to consume, I want to consume, you know, just content from Israel, which is blocked for me as a citizen in the UK. So I was so happy about it. Finally, I can have a VPN that I can deploy on my own. And I went ahead and used that same tool that I always use, Algo VPN. I could put a link. It's a grace open source one. And they said, no, there are no two instances in Israel, because it's such a news reason they just don't have old families. So I needed to update the code. It wasn't just that big of a problem. It was so funny to see a region with no T2 instances. Wow. So somebody got T3 instances. Not big. They got T3. I think you have T4 now, right? Okay. I think, yeah, probably for the graviton, right? Right. Right. Because Amazon usually add all those graviton and stuff. Anyway, so it's funny. I saw that S3 is available. So if you want to store some storage in AWS, so feel free to store your stuff in Israel. And I think that's it for Israel. What do you think? Hopefully, it won't get stolen like your bike in Tel Aviv. If you store things in S3 in Tel Aviv, just keep it, keep it chained, right? Keep a lock on it. Exactly. Okay. Should we move to the corner? Yes, let's do that. Okay. Effect. Cool. Of the week. Okay. Almost. So we are going to talk about an experience. Maybe a solution we wanted to share. Anything knowledgeable that you want to share with you, that we experienced this week, last week, next week, or any other week of the week. So only you can start. Okay. In the spirit of AWS and Jeff Baron blog post, recently it was Prime Day, you know, Prime Day. So there's Amazon Prime Day where you get a lot of good deals on Amazon. And if you're obviously, if you're a prime customer, but even if not, it's a great two days of deals every year on Amazon. And obviously, that's powered by AWS. So Jeff Barr, the head evangelist, I think, is releasing a blog post with statistics and numbers every year. So first of all, that's just a recommendation. I'll put the link, read it. It's short. And it's very, very nice and interesting to see. The one bit that stood out for me was the the increase of EBS usage. So it was like hundreds of petabytes, but the increase in percentage was 40% over the last year. And it's not that last year was the first year of Amazon Prime. It's just to tell you how much resources we provision and use just for retail and how much people buy every year. So you can talk about the economic downturn and everything you want, people shop and they shop a lot. And yeah. Wow. Amazing. Yeah. And move to me. Yeah. Move to you. Call of the me. Okay. So over to you. Over to you. Okay. Over to me. Over. So this week, I wrote after maybe I think ahead. I was dried up for like eight months. And finally, I was able to write my own a blog post about writing a bash scripts like a pro. When I wrote about the topic, like part two, and I wrote about L handling. So finally, I got into it and I wrote down a nice blog post, a very short one. I'd say like maybe a six minutes blog post where you can just read and learn how to handle errors in bash, which is our favorite. Well, my favorite scripting language, not all metals. And we're also put a link to that in the description. Actually, my favorite scripting language. And I also had had a nice migration by the way. Okay. Just want to add another thing that I did this week, which was very, very nice. I realized how good it was that all my CICD processes are written in a make file. Because I migrated from drone and beat buckets from GitHub to GitHub actions. Right. So let's focus on the drone IO to GitHub actions. Okay, from one CICD service to another. So the only thing I need to do was to add the secrets other than that, all of the comments are wrapped in make. Yeah, just because a lot, you know, so if I have a make build in the CICD and also the developers use it, I just had to add it in the CICD in GitHub actually. And that's it. I mean, it was no hassle to just migrate from a CICD service to another. So if you want to be agnostic as possible, and I just love it, where you can use make file, even though it's not even meant for that, because it's used to build C. It was built for that. It wasn't built for the, it was made. What, 20 years ago? No, yeah, but it was made, it was made for automation of builds, right? Before every, anyone had ever coined the term CI and stuff like that, it's automating tasks of your project, building stuff, but mainly, but how I use it, you know, that that's wrong, because when you do make build, what make does, it searches for a file, which is named build, and because it doesn't exist, it invokes the command, but if the file exists, it, you know, it says, okay, it is cached, I'm not going to run it, but I didn't know that. It's an abuse, you know, so this how make works, it has this cache where you can, if you have a file and the code wasn't changing and all, so it just stays the same, because everything was already done, so why would you ask? So you, they made me add two things to the, to the corner. One, I mentioned both, one is called just, which is make in rust, and it's a modern project, but kind of does it without the abuse. It's, it's really, really new. Yeah, so I want to use that make for sure. So just, it's not. Trust is not another abuse, that's how you use it, like the, the process that you mentioned would make, and the other one you talked about my grating CI, also a tool that we mentioned, it's called dagger. It's actually a company, it's from the creators of Docker, and they kind of built the system for you to, if I'm not mistaken, it's a way for you to write code that describes your CI process, and then you can easily migrate it between everywhere. It doesn't matter if you run on GitHub, GitLab, et cetera, et cetera. It's just interesting. I'm still not there, because I didn't really understand the big plus over doing something like make, just like you do. I mean, it's a nice way to kind of describe stuff, but then again, you can use make. So I don't know. And okay. So I think we are done for this week. We had a very interesting episode. I think it's the first time we're talking about the news. Yes. Why, while avoiding politics, we'll do that more often if there are any news, but yeah, this week was a hot news. Okay. What news week? So thank you everyone, and we'll see you next week, and we'll see you. Bye-bye. Bye.