Today’s Day Two Cloud kicks off an occasional series on cloud essentials. For the first episode we discuss the Virtual Private Cloud, or VPC. A VPC is an fundamental construct of a public cloud. It’s essentially your slice of the shared cloud infrastructure, and you can launch and run other elements within a VPC to support your workload.
In this episode, Ned Bellavance walks through key components of the VPC including regions and availability zones, networking and IP addressing, paid add-ons, data egress and associated charges, monitoring and troubleshooting a VPC, and basic security controls.
Note that this conversation is AWS-centric. Azure, Google, and other public clouds also have VPC-like constructs, but with their own terminology and subtle differences. Rather than spend all of our time on comparisons, we use AWS as a baseline and will leave it to you to figure out the variations.
Sponsor: DoiT
An award-winning strategic partner of Google Cloud and AWS, DoiT works alongside more than 3,000 customers to save them time and money. Combining intelligent software with expert consultancy and unlimited support, DoiT delivers the true promise of the cloud at peak efficiency with ease, not cost. Their technology is backed by deep multicloud expertise in the analytics, optimization and governance of cloud architecture, as well as specializations in Kubernetes, AI, and more. Learn more at doit.com.
Show Links:
Amazon Virtual Private Cloud – AWS
Amazon VPC User Guide – AWS
Overview of Data Transfer Costs for Common Architectures – AWS
Transcript
Transcripts are auto-generated and best effort.
Ethan Banks (00:00:00) – Today’s podcast is sponsored by Do It Reduce Your Cloud spend by improving your cloud efficiency with Do It and award winning strat…
Full Transcription
Edit Speaker’s Names
Ethan Banks (00:00:00) – Today’s podcast is sponsored by Do It Reduce Your Cloud spend by improving your cloud efficiency with Do It and award winning strategic partner of Google Cloud and AWS. Find out more at Doit. That’s it. Dot com. Welcome to day two, Cloud. And today, Ned and I are going to begin a series of cloud essentials. What is Cloud Essentials, you might ask? Well, some of the fundamentals that you might want to know about if you are working in the cloud in today’s topic are vpcs. Because net, I don’t think it gets more essential than Vpcs.
Ned Bellavance (00:00:36) – They are a pretty foundational building block of pretty pretty much anything else you’re going to do when it comes to cloud computing, at least from an infrastructure perspective. So it’s probably a good place to start.
Ethan Banks (00:00:47) – Now, Vpcs. We’re going to be talking about them from an AWS centric perspective. If you look at Azure, if you look at GCP and a lot of the other public cloud providers that are out there, they may have slightly different terminology.
Ethan Banks (00:01:01) – But the conversation today that Ned and I are going to have is focused on the way AWS looks at Vpcs and the terminology that they use. That means if you go to Azure GCP, you’re going to find very similar concepts and maybe even the same terms, but also probably some different terms that mean the same thing is what AWS called it. By and large, as I was doing my reading, that’s what I came across with. Would you agree with that, Ned?
Ned Bellavance (00:01:26) – Yeah, I would agree with that at a very high level. Of course, once you get down into the intricacies of how each cloud provider has implemented the networking, there are some differences and some of them are more important than others. For instance, the concept of availability zones, which we’ll get into in AWS, has much broader implications for AWS than the way that availability zones are implemented and say something like Microsoft Azure. So I can speak to that as we get to that portion of looking at Vpcs.
Ethan Banks (00:01:58) – Let’s start at the beginning then.
Ethan Banks (00:02:00) – What is a VPC? VPC is an acronym that stands for Virtual Private Cloud. This is your slice of the cloud providers infrastructure. And something to keep in mind here is that you are on shared infrastructure with other people. That is the point of the cloud. Now security from those other people is guaranteed by the provider, but you’re still going to have the noisy neighbor problem. If you were a VMware administrator, you’re you’re familiar with this problem. There could be a virtual machine on a host that’s just chewing up memory and CPU and impacting other virtual machines that are also running on that hypervisor. You can have that problem in the cloud. It is again shared infrastructure, now a VPC, virtual private cloud. It is your own little world. And inside that world and you you launch stuff.
Ned Bellavance (00:02:50) – That’s true. Well, first you have to structure the VPC in some way. You can think of the VPC itself as like an empty shell and now we’re going to populate that shell with things. It’s like a home and you got to decorate your home.
Ned Bellavance (00:03:03) – And what do you do first with a home? Well, you have to divide it into sections, right? And just like you’d have rooms in a house, you would create subnets inside of a VPC to contain the network interfaces that will attach to that VPC. I kind of like that analogy. We could probably run with it.
Ethan Banks (00:03:20) – Well, as a network guy, I liked this as I was doing my my reading and pondering about this topic. Yeah, Vpcs are very network centric. You have again subnets that you’re assigning to things and you’re putting those subnets into different places and then as you put it in there, that’s your, it’s your home. You can have multiple vpcs that interconnect with one another if you need to expand or you’re trying to design for a certain application availability and things like that in the Amazon world, in the world, they give you regions which are globally distributed, different parts of the globe in upon which are inside of which you can launch your vpcs inside of a region you have availability zones.
Ethan Banks (00:04:06) – So Amazon for would give you a best practice of. If you need a highly available application, you would have vpcs in different availability zones and you would have an application running in different availability zones so that in case the data center running availability zone a falls over has a catastrophic problem, your app is still running because you’ve got a different copy of it in availability zone B that of course would not be impacted because how does Amazon describe these availability zones inside of a region? Again, multiple Azs, they are physically separated and isolated from one another. They are interconnected using low latency, high throughput and highly redundant networking. So these Azs are connected very quickly one to another so you can share data between them. When everything’s working well, they are considered more highly available, fault, tolerant and scalable than a traditional single or multiple data center infrastructure. So they’re saying our Azs are better than your DCS feeble humans that build your on prem. Just give it up and move it all to the cloud in our Azs because there’s so much better.
Ethan Banks (00:05:10) – And then of course, from a design perspective, you would spread those critical workloads across Vpcs and then launch them in separate availability zones. Now that I do have a question here, since you worked with a lot of customers that have maybe had to face this. As I thought about different applications I’ve supported over the years, a lot of them wouldn’t support this architecture because they’re not designed in a way that you could just spread them out across availability zones very easily.
Ned Bellavance (00:05:37) – Well, so let’s back up a little bit and refine the terminology because a VPC exists within a region, but not a specific availability zone. Yes. So when you create your VPC, you do have to select a region where that VPC exists. But the thing that actually resides in a particular availability zone is a subnet. So each subnet is assigned to one and only one availability zone. So if you have an application that has fault tolerance within the application, which is usually accomplished by having multiple nodes of a cluster behind a load balancer or something along those lines, then best practice would be to create at least two subnets in two different availability zones and place some of your nodes in the first subnet and some of your nodes in the second subnet and then balance your traffic across those two Azs or do like an active passive kind of setup.
Ned Bellavance (00:06:35) – There’s some cost implications which we can get into later, but that would be from a fault tolerance perspective, what would be considered best practices inside a single VPC.
Ethan Banks (00:06:45) – So here’s a question that I have about that. In that scenario where I’ve spread pool members, if you will, into multiple subnets distributed in different availability zones, as Amazon describes. Connected using those low latency, high throughput, highly redundant networking connections so that they can all see each other and so on. Where’s my load balancer in this scenario? And is it also benefiting from high availability of some kind?
Ned Bellavance (00:07:12) – Yes. So Amazon offers two different types of load balancers. They’re both under the moniker of Elastic Load Balancer, and this is a managed service that AWS handles. And so you don’t have to you don’t have to worry about what’s happening under the covers, really. They’re handling it for you. And essentially there’s two types. One is a network load balancer that runs at layer four, so that can do basic network load balancing, but it won’t inspect the contents of the traffic at a layer seven level with Https looking at requests, doing modification of requests and whatnot.
Ned Bellavance (00:07:49) – The other load balancer type is the application load balancer, and so that has a little more intelligence built into it. It can parse a query and determine which host to send that query to either of those is capable of handling multiple availability zones. And like I said, since it’s a managed service from AWS, you just point it at the subnets it should connect to and it handles the rest.
Ethan Banks (00:08:14) – I like the way you said I don’t have to worry about it because Amazon takes care of it. I like that. I still going to worry about it though. That’s just that’s just who I am. Yeah, you.
Ned Bellavance (00:08:22) – Can. And honestly, you can bring your own load balancer if that’s the kind of thing you want to do, but that can be more challenging. You’d probably end up going with a network virtualized appliance that is from one of the major load balancer companies out there. Or you can set up your own load balancer using something like Nginx can do load balancing Haproxy or proxy can do load balancing.
Ned Bellavance (00:08:49) – So you can also set that up yourself, but that’s going to require additional work on your part.
Ethan Banks (00:08:55) – There’s one reason that I can think that I would want to do what you just described, and that is I’m so embedded in my legacy infrastructure from on prem because I was an F5 user. Let’s say that I want to keep my operational my operations exactly the same as they’ve been for forever. And so then I would take that load balancer and put it into the cloud. Other than that, I would rather use what Amazon gives me in the assumption that it’s going to make my life easier in the long run. If I just bite the bullet, figure out how this this load balancer I haven’t used before perhaps works and, and then leave my F5 810 whatever behind. I’m assuming cost wise it’s at least a wash. I’m assuming going to an Amazon load balancer wouldn’t be vastly more expensive. I mean, five, eight, ten, etcetera. They’ve never been they’ve always been reassuringly expensive. So I don’t think there’d be a big cost change.
Ned Bellavance (00:09:51) – You would still need to deploy an EC2 instance which is their elastic compute service. You would still need to deploy an EC2 instance and have that running and have it be beefy enough to support the A ten or the five load balancer. Right. And then you’d still be paying the licensing cost of that load balancer to 5 or 810. So chances are the application load balancer or if you can use the NLB, the network load balancer, either of those options is going to be cheaper than running your own EC2 instances and managing the load, balancing yourself.
Ethan Banks (00:10:28) – And as you just said, and then I don’t have to quote unquote worry about it because Amazon’s going to keep it up and running for me and I can rely on them and their infrastructure to keep that virtual appliance functioning for me. So net okay, we just went down a rabbit trail with, with some application architecture stuff, but it was one of those common things that I think a lot of people face as they begin to move to cloud. Well, how am I going to take this thing? I’ve been delivering on prem across my active, active or active standby data center architecture and and mirror that in the cloud.
Ethan Banks (00:10:59) – And the answer is, well, maybe you don’t want to mirror it or maybe you want to take the principles that took you to build the current architecture you have, rethink how you would fulfill those goals, but do it in a in a cloud way. How would you do it so that it makes good sense? You’re still accomplishing everything that you want to, but you’re doing it not replicating what you did on premise on premises, but then do it in the cloud, taking advantage of all the tooling that Amazon is giving you. So to back up for a second, we started talking about vpcs a virtual private cloud, your slice of the cloud providers infrastructure. Amazon has vpcs you can launch in different regions all over the world. Inside of those regions there are multiple availability zones, and as you begin to carve out your subnets, your networking layer of where you’re going to stand up these vpcs, you can put those subnets in different places. They don’t have to be in different places, but you can and you would put them ideally in different availability zones so that if Amazon has an outage, that never happens.
Ethan Banks (00:12:04) – Nat I mean, we know that never happens, then of course you can survive that outage. So now let’s talk about connectivity more and subnets and and all of that, because in my thinking, again, a VPC is a network centric construct. And inside of those inside of that, you stand up these subnets because you got to have an IP network that resources you deploy in the VPC can use. It’s really the one of those fundamental building blocks. Amazon does support IPV four and IPV six. You can bring your own IP. They do support that, which is for some of this is a somewhat of a recent thing, particularly with IPV six. I know it was in the last year and a half or so. I think they began to add the IPV six bring your own IP functionality, but that means you can if you have your own IPV four IPV six block that’s been assigned to you by a provider or from the Regional Internet registry, you can announce those from Amazon that will allow that public IP address space to be announced from your from your VPC.
Ethan Banks (00:13:12) – So so now that’s that’s the building block there with with subnets. Do you have more guidance or thoughts about public versus private IPS or any best practices that you recommend when beginning to stand up your subnets?
Ned Bellavance (00:13:26) – Yeah. So, I mean, when you’re carving out your network address space, you want to be fairly deliberate about it and also understand that a certain portion of the network address space is reserved by Amazon for each subnet and each VPC. So they reserve, I believe it’s the first four addresses in any network range for their own personal use. One is to serve up well, one is to act as the gateway to get out of that subnet, right? One is to act as a DNS server and then on the other two are reserved for future use, whatever that future use might be. So you have to take that into account when you’re trying to if you’re trying to be real conservative about your IPv4 address space usage, you still have to account for the fact that you’re not getting access to the entire range of addresses, especially if you’re trying to go real small.
Ned Bellavance (00:14:21) – So just bear that in mind as you’re planning out your your address layout. If you’re going with IPV six, man, you got all the space in the world.
Ethan Banks (00:14:30) – And do what you want.
Ethan Banks (00:14:32) – Network administrators listening to this would go, Oh, that sounds familiar because as a network admin, if you’re laying out an IPV four block, particularly you, you would have done this. You’d you’d have this habit. You know, there’s going to be an IP address that’s reserved for the gateway to get out of the subnet. And you know that there’s a couple that you might need for something like a hot standby routing protocol or something where you’re going to reserve a few extra addresses for that and then you might want to reserve 1 or 2 because like I think I’m going to need to drop a new route in here. At some point. I’m going to have to transition over. I’m going to want to reserve a couple of addresses for myself there if I ever get that project done and so on. So that way of thinking should be very familiar to folks.
Ethan Banks (00:15:12) – Well, let’s talk about other connectivity than from within that subnet, because you build the you build the subnet, but then you got to get from that subnet to other things like the Internet to other vpcs you might want to connect to your on premises network or to VPN like a B2B VPN tunnel kind of thing. You might have direct connect circuits. If you’re a very large shop and you’re spending all that money for a direct connect and so on. So. So let’s walk through these need to connect to the Internet. You need an Internet gateway. Pretty, pretty simple construct there. Is there any magic to it?
Ned Bellavance (00:15:47) – Not magic per se. It really is what it says on the tin. It’s a gateway to the Internet. And traditionally what you would do is for your public subnets, you would set the default route for those public subnets to send their traffic to the Internet gateway. And out it goes, Yay! The Internet gateway does not do any sort of Nat, there’s no network address translation happening with the Internet gateway.
Ned Bellavance (00:16:14) – So any instances that want to use that Internet gateway already need to have a public IP address associated with them and that could either be an IPV four elastic IP or an IPV six address. If they don’t have that, then they could send traffic out to the internet gateway, but they’ll never be able to get the response back.
Ethan Banks (00:16:34) – Right. Okay. So well, and I would guess Amazon’s actually going to drop it if they see private address space heading out through the Internet gateway because they know it’s not routable. If they’re doing best practice kind of stuff, they’re just going to throw it away because that’s that’s what it typically what a public service provider would do. It would be considered a bogan. That is address is showing up on the wire that are not supposed to be here. And there’s a bunch of those that that there’s there’s lists for. So I would expect yeah they’ll you might think it’s clearing your Internet gateway but it’s really not going to go anywhere. Yeah. Yeah.
Ned Bellavance (00:17:06) – So that would be for public instances one that you want to associate with the public IP address and go out the Internet gateway.
Ned Bellavance (00:17:13) – The other class of instances you would have would be on what are called private subnets. And so these are subnets that are going to go through some sort of nat gateway to reach the public Internet. And there’s essentially two types of nat gateway that Amazon offers up. You can have their managed Nat gateway service, which you spin up usually one per availability zone, or you can go with your own manage your own Nat instances that you’re sort of running yourself that are providing that network address translation And you would probably do the same about one per availability zone to send your traffic through. And then those Nat instances or the Nat gateway would have a public IP address that they can then use to go through the Internet gateway and do their thing.
Ethan Banks (00:18:02) – Now Amazon does also have firewalls and in for many network admins that have been running their own networks for a long time, The firewall is also the Nat Gateway. So are these kind of the same thing or as a Nat Gateway? It’s a Nat gateway. It does network address translation, and that’s what it does.
Ethan Banks (00:18:20) – It’s not really a firewall and we shouldn’t think of it as such.
Ned Bellavance (00:18:23) – It is definitely not a firewall. I would not. Think of it as such. There are other ways to control the ingress and egress of traffic from your VPC. There’s some very easy there’s there’s some very basic ACLs you can apply, but you can also deploy other firewall solutions or you can deploy Amazon’s firewall solution. So that’s going to depend on your unique requirements when it comes from security perspective. But in terms of just doing that, that is all the Nat Gateway Service is intended to do. If you’re bringing your own Nat instances, you could add some firewall functionality into those, but that’s not something that’s part of the native Nat Gateway features.
Ethan Banks (00:19:05) – So we’re talking about subnets. Our subnets exist inside of our vpcs and we’re talking about how to connect that subnet to other resources on the Internet. We’ve talked about an Internet gateway, we’ve talked about a Nat gateway. Now let’s talk about transit gateways. A transit gateway is a complex piece.
Ethan Banks (00:19:25) – There’s a lot of things that it can do. You can use it to connect to other vpcs to your on premises networks. You can use it to connect to VPNs like a VPN tunnel, to some other site you can which could be for on premises. You can use it to connect, to direct connect circuits. And the way Amazon lays it out, they say, think of it. Think of a transit gateway as a hub with the items connected to it, as spokes would call it. Transit Gateway is another way to think about it is a cloud router. So again, draw out your different resources that you want to interconnect with the transit gateway in the middle that cloud router. And that’s architecturally where Amazon Amazon is positioning this transit gateway. And this is sort of a new construct net. I mean not new new, but I mean within the last, what, two years, three years since they announced the transit gateway, something like that.
Ned Bellavance (00:20:21) – About three years, I think would be right. So in order to understand the necessity of the transit gateway, it’s important to understand how things were done previously and how messy it could really get.
Ned Bellavance (00:20:32) – So one of the most important concepts to understand is you can peer vpcs together. So I can create a connection between VPC, A and VPC. B, and it’s a bidirectional peering connection. So instances in VPC A can talk to instances and VPC B and likewise.
Ethan Banks (00:20:51) – Which is separate from the transit gateway. This is just an option you have. Yeah, it’s very simplistic kind of connection. Yeah.
Ned Bellavance (00:20:58) – Yes. And this existed long before the idea of a transit gateway. The thing is, if I have appearing relationship between VPC A and B PCB and then one between VPC, A and VPC, C, I cannot send traffic from C to be. It will not do transitive routing across the two peering links. And that’s true of basically any peering link. None of them will do transitive routing. It’ll stop at a and just die. So if I want B and C to talk to each other, I have to create a third peering connection between those two vpcs. Now imagine what happens if I have 20 vpcs that I want all connected? That’s a lot of things.
Ethan Banks (00:21:43) – You end up having to build out a. Wow. I was going to say a full mesh, but it’s actually yeah, it’s more complicated than that. Everybody’s going to have a direct connection to everybody else, right? That’s that’s a lot to manage. Yeah.
Ned Bellavance (00:21:56) – That is a lot to manage. And then think about connections to your on premises environment. Well, that’s also not transitive, so I’m going to have to set VPN connections from each of my vpcs and you can see how this can quickly get extraordinarily complicated. So the transit gateway, prior to that there was the idea of a transit VPC where you would run basically two Cisco routers inside of it. It was very expensive and it would do essentially what the transit gateway does today. The transit gateway was the solution to create more of a hub and spoke architecture and have the transit gateway do the transitive routing. That was not possible with the peering connections that you had before.
Ethan Banks (00:22:40) – See the Cisco product you were talking about would have been the CSR, the cloud services router, CSR 1000 V, I think was the I don’t know if that’s still the model that they use or not, but it’s been a fun tool in a lab for sure because you could spin it up in a lab, you know.
Ethan Banks (00:22:53) – But then, yeah, of course, also get licensed and run it in a VPC to do all of that magic that you were talking about and running it with BGP so that you could interconnect whatever. All the things were that you wanted to interconnect was was a big thing. I think you license it for throughput. How much data did you need to shove through the thing? Something like that. So it could get spendy awfully quickly. So transit Gateway not as bendy, you would say.
Ned Bellavance (00:23:19) – Not as many, but it still has a cost associated with having it running. And it also charges you not only for running it, but also for the data throughput that goes goes through the transit gateway. So calculating how much the transit gateway is going to cost you is going to come down to your traffic patterns as much as the number of connections that you need.
Ethan Banks (00:23:41) – Today’s sponsor, DeWit can help you with your cloud challenges. Maybe you want to maximize your cloud use while controlling your costs. Perhaps the issue is balancing resource utilization while delivering agile IT.
Ethan Banks (00:23:53) – Maybe it just can’t get good support from your cloud partners do It can help an award winning strategic partner of Google Cloud and do it works with over 3000 customers to save them time and money do it combines intelligence software with expert consultancy and unlimited support to deliver cloud at peak efficiency with ease. The Do It team knows multicloud, Cloud analytics, Optimization, governance, Kubernetes, AI and more work with do it to optimize your cloud investment so you can stay focused on business growth. Learn more at DeWitt. That’s it. Dot com. So we’ve mentioned now a few different key ways to get our subnet connected to Internet Gateway VPC, peering directly one to another. Something that is good for a very simple environment does not scale well, and therefore you’d move up to a transit gateway. Are there other subnet connectivity options? We need to mention that.
Ned Bellavance (00:24:53) – There are, So you can also create a VPN gateway and that would be another way to connect to an on premises environment or doesn’t even have to be on premises. Just something else that can talk to a VPN gateway.
Ned Bellavance (00:25:06) – My understanding is that the VPN gateway you establish an AWS will not initiate the connection, so you need something on the other side that will initiate the connection. And then they go through the whole IPsec handshake and set up the tunnel and everything. But I don’t believe that the AWS one will initiate that and I’ve run into that. When you wanted to connect a vnet running in Azure with the VPN Gateway and a VPC running in AWS with their VPN gateway, neither one will start the process. So you actually have to deploy something different in one of them, like an open VPN server. So something will actually initiate the connection.
Ethan Banks (00:25:45) – Historically, that’s an IPsec option, that’s you can actually set the tunnel up to behave in a particular way anyway. I guess they’re just they’re insisting that they want to be passive. Okay, if I’m using transit Gateway, do I have to have a VPN gateway? If I’m looking for VPN connectivity.
Ned Bellavance (00:25:59) – You would establish the VPN Gateway in the transit gateway to talk down to whatever your appliance is in your on prem environment.
Ned Bellavance (00:26:08) – So that could be another spoke in your hub is a connection down to on prem using either a VPN gateway or if you want to pony up for a direct connect, you can also have direct connect connections.
Ethan Banks (00:26:21) – Direct connects are startlingly expensive. Yes. What else? Net. Are there any other major connectivity points we should mention?
Ned Bellavance (00:26:29) – The other one is the idea of Vpcs interface endpoints. So these are a little funky, but to understand the idea behind them, when you think about how an EC2 instance in a VPC talks to any of AWS public services, it has to send that traffic out in internet gateway to do so. So if I have an instance in a VPC and I want it to talk to S3, it’s going to go out the Internet gateway and then to the S3 service. Now it’s going to hit it immediately because it’s not like it actually has to go out to the open Internet and route back into Amazon, but it needs that connectivity there. So one of the things they did really early on was create I think it’s called a gateway interface, and that’s something you could put inside your VPC.
Ned Bellavance (00:27:19) – That would be a connection to S3 directly without having to go out the Internet gateway, which means your private EC2 instances wouldn’t have to go through a Nat gateway. They could just connect directly to S3. That was like pretty useful, right? Yeah.
Ethan Banks (00:27:35) – You know, on a much smaller scale is a similar construct in Vulture. If I stand up a virtual private server, not a VPC but a vpcs and I want a multiple vpcs I have within my account to connect to each other. I can build a private networks that they can communicate. It sounds similar in that nature rather than having to go out the public interface to talk to one another.
Ned Bellavance (00:27:55) – So creating that for all the different Amazon services was going to become really onerous. There were a few obvious ones that they set up initially with this gateway endpoint, but as they expanded the number of services, they also had third party providers saying, Hey, I’d like to offer this service to other customers. Is there a way I can do that and sort of place an endpoint inside of their vpcs so they can talk to my service, whatever it is? And so the other solution that came about was a VPC endpoint interface, which is an elastic network interface that gets created inside your VPC, and then it’s connected off either to an AWS service directly or it’s connected to a third party offering.
Ned Bellavance (00:28:41) – So it’s a little bit different than the gateway because the gateway is kind of just like a dumb thing that connects to S3 and I think it’s still uses the public networking to do it. The VPC endpoint interface is a private link from your VPC to either the AWS service or to someone else’s VPC to a network interface that they’re offering a service on.
Ethan Banks (00:29:06) – Lots of options. So yeah, one more question, Ned, is you’ve spent a lot of time as a cloud architect. With all of these options that are there are some of these historical more or less and have aged out and you really don’t use them anymore or is there depending on the use case specific needs for all of these options that Amazon is giving us?
Ned Bellavance (00:29:26) – I think a lot of it comes down to cost security and requirements. Cost is probably going to be one of the biggest factors because running a VPC endpoint interface has a cost associated with it. You’re going to be paying for the interface itself and the traffic that goes through it. So maybe if you don’t need that interface or that gateway to be deployed in your VPC, you’re okay.
Ned Bellavance (00:29:52) – Going out through the Internet gateway, it might end up being cheaper for you to do so. Peering between Vpcs. If you’re not running a particularly complex infrastructure, you don’t have a ton of vpcs that need to be peered together. Transit Gateway might be overkill and cost way too much, and it might be just as easy to set up peering relationships between 5 or 6 different vpcs and call it a day. So I think a lot of the architecture, even the older architecture models, are still valid for particular use cases. And a lot of these bigger solutions that we’re talking about are for mature enterprises that have grown into a larger infrastructure need.
Ethan Banks (00:30:35) – Would you look at a transit gateway and say that’s a bigger solution or is that pretty commonly used by everybody?
Ned Bellavance (00:30:41) – I think it’s a bigger solution. It’s for an enterprise size deployment. If you’re just even if you’re a shop running 20 vpcs, chances are those 20 Vpcs don’t all need to be interconnected. You might have like two shared services Vpcs that need connection to some of your other Vpcs.
Ned Bellavance (00:31:01) – So if that’s the case, there’s no need for you to stand up a transit gateway and the cost associated with it. It’s only when you start really expanding your cloud real estate and you need that full mesh of networking that the transit gateway starts making sense. Also, if you’re deploying across multiple regions, it might start making sense to have a transit gateway in each region and then connect those transit gateways so you can have cross regional traffic being routed through the transit gateways.
Ethan Banks (00:31:33) – It becomes clear how quickly cloud costs can add up, which is one of our recurring themes on the show, is just the expensive cloud. And it kind of sucks that you have to pay close attention to this, but I guess that’s no different from enterprise. It all along with our cloud budget was always a constraint. How much is this going to cost me to acquire CapEx and how much is it going to cost me to run OpEx? And you always got to take those things into consideration. And I’ve been in plenty of meetings where that discussion and the cost associated with a particular solution drove the decision and a lot of times it was a trade off or a compromise decision.
Ethan Banks (00:32:08) – We can’t go with the Cadillac with the very best because frankly, we can’t afford it. Would it be nice? Would we benefit from it as a business? Sure. We don’t have the money to get that done. For me, looking at it as an ideally like for network architecture, it’s like how small we are. I’m starting with a transit gateway because I can scale that thing forever. It doesn’t matter how big we get, whatever craziness we need to do, I know I’m going to be able to plug anything in. I need to that transit gateway and it’s going to do what I want. But if it’s too spendy, then there’s my constraint. There’s my trade off where I’m going to make a decision to use something else that accomplishes the goal but saves me some money.
Ned Bellavance (00:32:48) – The important thing to bear in mind is that you can always grow into it. It’s not like I made this peering decision and I can never go over to this transit gateway. There’s a migration process. It’s not going to be completely seamless, but it’s going to be fairly seamless.
Ned Bellavance (00:33:05) – And it’s something that you can spin up on demand and do a gradual migration over and you can control it all through code. That’s very different than when you had to make architectural decisions before. And the cost of putting in the next bigger size router was tens of thousands of dollars. Now it’s okay, we’ve grown into it. We can just start paying for it. And if it turns out we don’t need it, we can migrate back. And I don’t have the sunk cost of the big cap expenditure that I would have with traditional routing.
Ethan Banks (00:33:38) – It’s the migration thing though, because there’s always the unforeseen in those migration processes. And I one of my things over the years was to if I know we’re going to grow into this thing, I’m going to put the foundation in place to just have that and not have to change it. No, we can scale without having to fundamentally have that. Six months to a year long project of architect in the new thing and then migrating everybody over to it and all that.
Ethan Banks (00:34:04) – And maybe with cloud it’s easier on premises was always painful with that kind of stuff because it involved things like unplugging and plugging in wires and disruptive service changes and and the such like. And I know with cloud you can just change, change it with some automation or with a few clicks in the UI and you’re doing things differently now. But still, there’s always risk there when when that’s introduced. Well, Ned, we’ve brought up the topic of cost. We brought up the topic of money. So let’s talk about what you pay for with VPC, The VPC itself. As far as I can tell from AWS, it’s free. You don’t pay to create vpcs that let you create as many as you like, but then everything else costs money pretty much is from what I can, pretty much. So.
Ethan Banks (00:34:50) – Yeah.
Ethan Banks (00:34:51) – Let’s talk about my favorite addresses to start. IPv4 addresses if you’re using the private address space that RFC 1918 address space that’s free, they’re not charging you for that. If you’re using a public IPv4 address, you are charged for that.
Ethan Banks (00:35:08) – And there’s a lot of different contexts in ways in which that you are charged for it. However, if you bring your own public IP, you are not charged for it from from what they’re saying. So that’s that’s a place to start. They’re there. Any other comments or gotchas on IPv4 addresses and cost net?
Ned Bellavance (00:35:25) – There’s a big shift that’s going to occur in, I believe, March of next year. So previously if you had an elastic IP, which is a public IP address that was not associated with an instance, you just had it reserved just in case you would get charged an hourly rate to have that elastic IP. Once it was attached to a running instance, you were no longer charged directly for that public IP address. Starting in March of next year, they’re going to charge for all public IP addresses that you’re using regardless of whether they’re attached or not. And that sort of goes to the fact that IPv4 address space is public address. Space is scarce and becoming more scarce. And so AWS has to be able to afford to keep buying more address space and also justify the address space that they’re currently using.
Ned Bellavance (00:36:18) – So they’re pushing a little bit of that pain back on the consumer and saying, well, you can always go IPv6 and then it’s free again. It’s not that easy.
Ethan Banks (00:36:27) – If you’re whining about IPv4 scarcity, is they just making that up? No, that’s that’s real. There literally isn’t any left. And the way companies are getting more is they’re taking their unused IPv4 address space and it’s being resold on the it’s going to say the black market, but it’s more like a gray market. And there there’s half a commodity value. IPv4 addresses have a value per address. Now where it used to be something you just pay a fee for to the your regional Internet registrar to have use of a block. Now, you can’t do that anymore because there aren’t any. So the the real impetus here is for folks to start going towards IPv6 and IPv6 address support is becoming better and better and better as as it goes. And I, I don’t know where we’re at with AWS and IPv6. I don’t know that it’s ubiquitous, universal for every service.
Ethan Banks (00:37:22) – It definitely supports IPv6, but I think we’re getting closer to that net.
Ned Bellavance (00:37:25) – We’re getting closer, but as of today, there are still services in AWS that do not speak IPv6. So if you wanted to go full IPv6 for everything, you would either have to not use those services or you’d have to run dual stack for the time being. I suspect that between now and March of next year, there’s going to be a mad dash to update all of those services to fully support IPv6.
Ethan Banks (00:37:51) – Lots of other things that you pay for within a VPC. Addresses are just one thing. There’s lots enough of other things. For example, we mentioned a Nat gateway that’s got an hourly charge and a per gigabyte charge. AWS iPam offers an iPam service where you’re charged per IP address that’s managed by their iPam VPC interface endpoints, which Ned mentioned earlier. You pay for those. There’s an hourly charge for traffic mirroring of elastic network interface. So if you’re using an and, and you’re doing traffic mirroring because you want to do some troubleshooting or something and see a copy of the traffic that’s flowing through there, you’re going to pay an hourly charge for that.
Ethan Banks (00:38:28) – You’re charged per use of a couple of analyzer tools. There’s a reachability analyzer, and I’m trying to figure out if a can talk to point B across my cloud infrastructure. The reachAbility analyzer is charged per use. Then there’s a network access analyzer. Can someone get access to this thing? That’s another troubleshooting tool. You pay for that. There’s data egress charges, there’s processing charges and it can get really confusing. In fact, there are companies that specialize in helping you figure all of this stuff out and looking at your cloud architecture and your vpcs and all the rest of the services you’re consuming to figure out why, why is your bill so big and where is where is your spending going into what service, and how can you change things in your cloud design to improve your costs so that you’re not spending so much Amazon’s got? I don’t think that Amazon is trying to be perfectly obscure about how you’re charged. Every single service that I click through explained it cost you this much per hour. It’s, you know, $0.0045 per hour or it’s whatever it is per gigabyte.
Ethan Banks (00:39:37) – And they were very clear on it. It’s just that to keep all of it in your head when there’s all these little services that you’re using and you’re using an IP address and using this particular gateway and you’re using this and you’re using that, and now there’s a data egress charge because you’re moving from outside of your region. So now you’re paying a charge where if you kept it in the region, maybe you wouldn’t be paying a data egress charge and so on. So since we’re not used to being billed that way historically as IT professionals, if you’re moving into cloud for the first time, I think trying to get your head around this and trying to explain to your boss or the accounting department, what’s my cloud bill going to be? It’s like.
Ethan Banks (00:40:15) – I don’t know.
Ethan Banks (00:40:16) – It’s not that it’s unfavorable, it’s just that it’s such a complicated thing to get your head around that it’s hard to know exactly until you get that bill.
Ned Bellavance (00:40:25) – Yes. And for someone who’s relatively new to the cloud and cloud networking, it’s enough of a struggle just to figure out how things should work.
Ned Bellavance (00:40:35) – From a technical perspective, I’m trying to move my application to a VPC and I’m trying to wrap my brain around all these different concepts when it comes to public versus private subnets. Internet Gateways Nat Gateway Security Group rules, which we didn’t even get into security groups or. Or network ACLs just getting it all right technically and getting the thing actually working. You’re like, Hallelujah, it’s done. I don’t care how much this cost, I finally made it all work. But the thing is, when you have to go back and think about the cost portion of it. Now that actually is a huge factor. And if you poorly design the architecture, you could end up paying way more because of the way that you built it. One one thing that a lot of folks don’t realize is that traffic between two different availability zones in the same region, in the same VPC, has an egress charge associated with it.
Ethan Banks (00:41:32) – Does it because the way I read some of the documentation, that wasn’t the case. So wow, I didn’t realize that.
Ned Bellavance (00:41:39) – Well, here’s the thing. That’s not always true. It depends.
Ethan Banks (00:41:44) – Oh.
Ned Bellavance (00:41:45) – So let’s say you’re running Amazon’s RDS service. That’s their relational database as a service, and you have a primary copy in one availability zone and a standby copy and another availability zone because it’s a managed service from AWS. There is no data transfer charge to send data between the two availability zones. However, if I have an EC2 instance in AZ one that’s talking to the instance in AZ two, there is a data transfer charge for pulling that information across the visibility zones. So when you’re architecting your solution, you might want to put all of your active EC2 instances in the same availability zone as the primary copy of your database to minimize data egress charges. I know it sounds ridiculous.
Ethan Banks (00:42:38) – But like.
Ned Bellavance (00:42:39) – Those are the some of the architectural decisions that you have to make. Do I feel okay having all of my active requests going to a single availability zone and then failing over in the case of an issue? Or am I okay with paying the egress charges for information flowing between the two Azs or can I set up a read replica in one of the visibility zones to lower data egress charges? It sounds esoteric, but it’s the sort of thing that could save you hundreds or potentially thousands of dollars, depending on your application.
Ethan Banks (00:43:08) – Wow. So and the.
Ethan Banks (00:43:12) – Thing is, if you’re the IT engineer, you’re probably going to be the one that’s expected to understand that better than anyone else, which is which is frightening. But Amazon does provide guides and so on. Again, I don’t think they’re trying to be purposefully obscure about this. They’re very clear about what the charges are. But it takes some effort on your part to figure that all out. Well, Ned, we’re coming up on kind of the end of the show here. But a couple other points just to make quickly. We’re not going to spend much time here, but if you are coming from a networking background, there are troubleshooting tools for your VPC as well as monitoring and troubleshooting tools. They give you flow logs. You get iPam, which we mentioned. There’s traffic mirroring, there’s the reachability analyzer, there’s a network access analyzer, and there are cloudtrail logs. If you’re interested in monitoring API calls that are made to the VPC. Those are all there available to you to help you understand not just connectivity but also access to the VPC and understanding what’s going on there.
Ethan Banks (00:44:09) – So you can figure out what just happened or why isn’t the thing happening that’s supposed to happen. Lots of options there do I think you’d be familiar with? And then securing your VPC, which I guess is a whole other show net honestly to spend proper time on that. But I will. I think we should at least mention the shared responsibility model which has come up on the show before the security of the cloud. That’s the stuff that Amazon owns, the hardware and the software that makes up the cloud. They would say that’s their problem. And then there’s the security in the cloud, the stuff that you deploy in the Amazon cloud, that’s your problem. And so between you and Amazon, you’ve got the shared responsibility for security. That’s how Amazon wants you to think about it. That’s how they want you to understand it. Don’t make the mistake of assuming I put it in the cloud. It’s secure. No, no, you still got to secure stuff. And there’s a lot of ways to secure things for sure.
Ethan Banks (00:44:59) – I am being the big one. The what does Iam stand for? And my net my brain just blanked.
Ethan Banks (00:45:05) – Out.
Ned Bellavance (00:45:06) – Identity and access management.
Ethan Banks (00:45:08) – Yes.
Ethan Banks (00:45:09) – It’s kind of like Rbac if you’re used to that from a networking perspective. Role based access control who can do what inside of your VPC. That’s not this isn’t traffic management as such. This is again, Bob is logged in and what can Bob do inside the VPC? That’s what I am is all about at a high level. You can control traffic flows through the network as well. There’s different kinds of ACLs. You can control things with routing tables, which is maybe doesn’t feel secure, but I mean, if a routing device doesn’t know how to get to some destination, it’s a form of security. And there are firewalls where you can do traditional stateful, and there’s also some stateless firewall options within as well. And then there’s security groups, which you mentioned, Ned, which are not the same as plain old network ACLs, but kind of similar.
Ethan Banks (00:45:57) – There’s a whole chart there explaining the two and how they work and what the differences are between them when you use one versus the other. And again, there’s a whole show we should probably be devoting. To securing your VPC and getting into that.
Ned Bellavance (00:46:10) – Yes. There’s a lot more there around security and also IP address management and DNS and Dhcp options. A lot of stuff we could dig into, but I think we really we put a nice basics and essentials even around the VPC.
Ethan Banks (00:46:29) – So these yes, these.
Ned Bellavance (00:46:30) – Are the essential things that you might want to know about the VPC as you’re going through the process of setting it up. We’ll also include a link to the Amazon VPC User Guide as well as an interesting post from from their blog that talks about the different data transfer costs for common architectures. Because as I mentioned, that’s something that’s pretty confusing. So that blog post gives concrete examples and what the data charge would actually look like for each one.
Ethan Banks (00:46:57) – Lots and lots of information there. And if you’re new to all of this, you begin to understand why there are so many different certifications within the realm and different specialties that you can have, because there’s that much to know.
Ethan Banks (00:47:09) – There really is one of those. The deeper you go, the deeper it gets. Well, that is all for today. Virtual high fives to you for making it all the way to the end net. And I are going to do more of these Cloud Essentials episodes over time. So if there’s a topic that you want us to cover, let us know. Just fill out the request form on day two. Cloudera Look up in the title bar there and you’re going to see it. You click through, you fill out the form and boom, we will have your request. Data Cloud is part of the Packet Pushers network. We have more podcasts, articles, videos and newsletters for your professional career development, all at packet Pushers dot net. You can connect with all of our podcast host. They’re read blogs by industry experts. Join our Slack group and more. It’s all free for you and privacy respecting. You don’t have to log in or share your personal information to get to the thing that you want because vendor sponsors pay the bills and we don’t have to sell them your information to do that outside of packet pushes net you can find us on LinkedIn since since ECS isn’t isn’t really the place for us like it used to be back in the day when it was Twitter and there was a burden.
Ethan Banks (00:48:09) – We all hugged and stuff. Yeah. Anyway, until then, just remember cloud is what happens while it is making other plans.
Podcast: Play in new window | Download
