Previous Lecture Complete and continue  

  VPC, Interfaces and Subnets

Welcome to Module 4: Networking. One of the problems with the EC2 instances could be that if you make them publicly available, then it's not very secure. And most of the times you don't even need to make the all the resources available publicly. Let's use VPC. What is VPC? VPC stands for Virtual Private Cloud. Basically, it's a virtual network. Your own private network. And it's logically isolated from other networks. It's dedicated to your AWS account.

The benefits of VPC are multiple. It's more secure. You can control traffic going to the VPC and going outside of the VPC. You get a better application performance and bandwidth efficiency because you're not making your requests in a public VPC, in a default VPC of that region, you're using your own network. Most importantly, your private IPs would not be changed. So, every time you start and stop an instance or you scale down and up, if you're not using a VPC you would get a new private IP. An IPv4 is a scarce resource, so I can understand why AWS is doing it but because in your private VPC, your new private network, you can use any private IPs, they would stay the same. So, if you really want to, you can use the IPs of different resources. You can just use them in your user data, in your code, because they're not going to change on restart.

Let's take a look at what VPC can do for you. Let's say you have a region with three Availability Zones. Each Availability Zone could have a subnet and your VPC will span across all three Availability Zones. So, different resources will be available within the same network even when they're in the different Availability Zones. And you can connect to a corporate network or home network within your VPC. You can create subnets. They would be limited by Availability Zones. So, subnets. Typically, when we're talking about subnets, we're talking about Availability Zones or Data Centers. It's important to understand how they work because by deploying resources into different Availability Zones/subnets, you will ensure the better resiliency. Let's say you have multiple instances in your VPC, and they are spread out in different Availability Zones. So, you can see 2A, it's in a different Availability Zone than 1A and 1B. Same thing with Availability Zone. And then you have subnet 1, which is an Availability Zone, on the top and it's a public subnet because there is a internet gateway. subnet 2 is a private subnet because it doesn't have access to internet by itself. It can only talk to other subnets. And then subnet 3, it can talk to your VPN or your corporate network. So, internet gateway enables communication with the outside world, with the internet, and VPN enables communication with your corporate network. It's worth mentioning the interface. Interface, or network interface to be more specific, allows you to attach instances in your VPC. And multiple instances could be associated with one interface.

Let's take a look at this diagram. The most important things that I want to point out, and it relates to the interface, are happening in the subnet A and the subnet B. The public traffic goes to the eth1. It's a special interface. And then that traffic goes to the subnet eth0. So, it goes to a different interface. And then you have multiple instances which are not exposed directly to the publicly facing internet gateway. They are exposed to a private IP and Elastic IP via that interface. And only after the subnet B, the traffic might go to the Virtual Private Gateway. Let's talk about Elastic Load Balancer. The benefits of Elastic Load Balancer is that it could monitor health of individual nodes, which are EC2 instances, in most cases. It could reroute to multiple Availability Zones so you can deploy and build more tolerance and resiliency and robustness in your infrastructure. You can make sticky sessions, support for sticky sessions. Or you can enable some CloudWatch metrics in addition to the standard health metrics. For more details, go ahead and click on that link to find out about the Load Balancer.

One key distinction between two types of Load Balancers are that for the Classic Load Balancer, you register instances directly with the Load Balancer. And for Application Load Balancer, you do it...you work with targets in target groups. So, targets would be your instances and then you would attach them to target group and only the target group would be attached to the Application Load Balancer. So, you have an extra layer of the obstruction when you're working with Application Load Balancer. But that's not all. There are Cross-Zone Balancing and it's always enabled in Application Load Balancer. In Classical Load Balancer, it's disabled by default but you can make it enabled. There's Host-based routing and Path-based routing, which is great for micro-services because now you can reroute different traffic to different micro-services based on the different Path in the URL. For example, "/accounts" or "/users", they would go to different micro-services. And then you have support for the multiple ports, which are typically used with containers. So, you can have multiple. Typically, we use Docker containers, the most popular technology. So, you'd create a cluster, which is just another name for an EC2 instance, and you would deploy two, three, maybe five containers and they could be working on different ports.

So, Application Load Balancer allows you to do that. With Classical LB, sorry, you're out of luck. And then, one of my favorite features is support for HTTP/2. HTTP/2 already here. If you don't use it, you're already behind. The practices for web development with HTTP/2, completely different. There is multiplexing, there is security, there is a whole bunch of additions and improvements and changes. So, make sure you take my course. HTTP/2 with Node.js, course on Node University to know about HTTP/2 if you are not familiar with all the features already. And then the Websocket support. It's tricky to make Websockets work through the Load Balancer but with Application Load Balancer it's a little bit easier. And finally, there is the deletion protection for the Application Load Balancer. There are more features so go to the AWS documentation for all the differences. I'm just highlighting six of the main, in my opinion. Here's the diagram that shows how an Application Load Balancer works. You have targets, which are EC2 instances and they're grouped in the target groups. So, you can have multiple target groups, which are monitored by using special health metrics. There are certain default health metrics but you can also set up your own based on the special endpoints, based on your business logic. And let's say one target group goes down. The traffic, the load, goes to a different target group. So, your Load Balancer should work seamlessly. The client shouldn't notice any problems. And the Listeners and the Rules, that's where you would define your HTTP protocol, the port number, the Path, the routing, and all that good information. So, your routing would go there. Load Balancer schemes could be either internal, meaning it's not going to the internet, the internet is not going there. Or internet-facing.

Why would you have an internal Load Balancer? Because you want to scale internally, as well. Maybe you have an internal service, which is not publicly facing, but you have a scalability issue. So, you would be adding more instances and hiding them behind the internal Load Balancer. But that's an internal resource. It's not supposed to be publicly facing for security reasons and just for maintenance issues. So, you can do that, as well. Load Balancer could be internal or internet-facing.

It's very important to understand how ELB works. There is two points of elasticity. First step, when the traffic hits your domain, which is azat.co, for example. That domain...I use name.com. You can use godaddy.com for your domain. So, you can use one of those name servers. So, in that name servers, you would have a CNAME record, which uses the DNS. So, that DNS would have amazonaws.com in it's name. So, that's how traffic knows to go to amazonaws.com. And that's your ELB IP. So basically, AWS, in response to the DNS, will give the ELB's IP. So, that's the first point of elasticity. Amazon would not give you the IP, so you would use the DNS because Amazon wants to have that first point of elasticity. They want to be able to change what exact IP address they're using. Maybe they would add more machines behind the scene. So, they want to have that flexibility. So, that's the first point. Then the client would get the Elastic Load Balancer IP address. And that would resolve to the actual traffic going to your instance and the instance would respond to that request. So, that's the second point of elasticity, which you implement. So, you would add certain rules using Auto Scaling groups or you would just create an infrastructure that will have multiple instances hiding behind the Elastic Load Balancer. And that will be the second point of elasticity.

I mentioned Elastic IP address before but let's dive a little bit deeper since it's a networking module. The benefits of using Elastic IP address. Static public IPv4. There is currently no IPv6. So that static IPv4 would be given to you and it would not be taken away for any reasons unless you release it. And you can use it to send emails because that's an anti-spam thing. You can not really use temporarily IPv4s. You have to have the static IPv4. So, let's say you're building the next email server, service, or server, you need to have that Elastic IP, which is kind of like a permanent IP address. You can associate with instance or network interface and you can remap to other instances in the case of instance failure. A little side note. Because IPv4 are scarce resources, there is a limit of five per account per region. But you can request more if there is a need, if you can make a case to AWS. And also, when you associate that Elastic IP address, you would lose the previous public IP, if your instance ever had one. Elastic IP address remains allocated and you would pay money until you release it. It's not going to go away. The differences between Elastic IP and ELB, for some of you it's not even going to be a question because those are completely different technologies for different purposes.

For some of you, it might be a little bit confusing why we can't just use Elastic IP or why should we use Elastic IP. We cannot use Elastic Load Balancer. So basically, Elastic Load Balancer provides you more scalability and reliability. It uses DNS, which you create a CNAME record for you domain and it's limited to 20 per region. It has two elasticity points. Elastic IP, on the other hand, is just a static IP address. It uses IP, which is an "A" record when you apply it. It's specific to region, so you cannot reuse the same Elastic IP in a different region. And there is a limit to five per region. And also, Elastic IP address works in one Availability Zone. One Elastic Load Balancer work across the Availability Zones. So, all in all, Elastic Load Balancer is more scalable and you build better resiliency for your applications using Elastic Load Balancer.

0 comments