Hey everyone, glad that you are here. Today we are gonna hang around some Networking stuffs. Whenever networking comes, there always was this concept of a VPC lying around. We saw it from time to time.
VPC, what is that? Alright that's what we gonna get fond off in this, I'll try to explain VPC in simple words, explain what it is, how it works, and why we might want to use it. So let's dive into that.
So what is a VPC? We often find this term a lot. For example, while creating an EC2 instance we have to select image, its instance type plus other configuration settings. Mainly we need to select a network i,.e VPC. As we can see in the below image, i have a default VPC here which is provided at the time when you create a AWS account.
Okay now the main question again..
What actually is the purpose behind having this VPC?
VPC stands for Virtual Private Cloud. Its like having your own network in the world of Cloud. We have regions in the AWS, in which Availability zones are present. You can think availability zones as typically data centers in a big cluster or building of data centers, you could say. All of the services which will be launched by us will reside in this availability zones like EC2 or RDS(Relational Database Service managed by AWS). In production enviornment we often split out instances up across multiple availability zones, so if one goes down due to failure we still be having other instances running over another zone.
Now the real hero arrive's, VPC. While the shared AWS infrastructure might seem secluded, VPCs take isolation to a whole new level. Think of them as secure, walled gardens within your cloud empire, each dedicated to your specific needs.
Why would you consider using a VPC in AWS? What role does it play in your network setup?
Well, a VPC, or Virtual Private Cloud, is essentially your isolated network within a specific region, extending across all availability zones in that region. But wait,
Why isolate your network when it's already separate from others in AWS? Isn't it inherently isolated from other customers?
A Isolation in this context refers to managing multiple networks within your own AWS account that are segregated from each other.
But why might you need this isolation?
Could it be driven by compliance requirements, or perhaps you're still maintaining your on-premise data center and need to connect it with your cloud data center? In such cases, having a VPC allows you to manage and connect both your local and cloud networks seamlessly.
Now, even if you don't anticipate needing multiple networks, you still require at least one VPC. Why?
Because every new instance you launch in AWS needs to be attached to a network, and that network is essentially your VPC. It's like your network hub in the cloud. So, whether you're a large corporation with diverse networking needs or a smaller entity, having a VPC is fundamental. It's not just about isolation; it's about creating and managing your network space efficiently in the AWS cloud.
What about subnets in AWS? How do they fit into this network setup?
Well, think of subnets as the subnetworks within your VPC. Interestingly, each subnet corresponds to just one availability zone. It's like having a network within a network. Now, while the VPC spans multiple availability zones, each subnet is confined to a single availability zone.
Let's talk about setting up your own IP range within the VPC. Wait, are we talking about external IPs that are accessible from the Internet? No, we're focused on internal IPs here. You get to define your own range of internal IPs for your VPC. Now, sure, you can assign public IPs to your instances for external accessibility, like Elastic IPs in your region and availability zones. But within your VPC, each instance gets both internal and public IPs.
What's the idea behind this? Well, your instances communicate internally using the internal IPs you define. It's like a private network within your VPC. These internal IPs are totally under your control – you set up a range as you see fit. So, subnets allow you to organize your instances, placing them in different subnetworks, and this internal IP setup ensures seamless communication within your network. It's about structuring your cloud network effectively with the flexibility to define your IP ranges.
How does the IP allocation work within these subnets in AWS? Imagine your VPC has an overall IP range, let's say from 1.1.1.1 to 100.100.100.100 (keeping it simple). Now, each subnet within this VPC takes a subset of this IP range. For instance, the first subnet might use 1.1.1.1 to 10.10.10.10, and the second one could be allocated 20.20.20.20 to 30.30.30.30, just as an example.
Now, these IPs aren't just for internal communication. You can also access this network from the outside. How? Well, that's where the Internet gateway comes into play. This gateway is crucial for any traffic leaving your VPC, managing the connection from your private cloud to the outside world. Interestingly, your default VPC automatically comes with such a gateway.
Security groups
How do we manage access to our resources within the VPC and subnets in AWS? Let's talk about security groups first. They operate at a per-instance level, so technically, you wouldn't need a VPC just for them. However, in the AWS setup, you assign security groups to VPCs. Then, every instance within that VPC can be attached to the security groups assigned to the VPC. It's a way of controlling which access is allowed to instances and determining the traffic leaving them – essentially acting like a firewall.
Now, on a broader scale, we have Network Access Control Lists (NACLs). These operate at the subnet level. While they might sound more robust, typically, you'd work with security groups because they offer a more granular per-instance level of control. But, here's the interesting part – you can use both. Yes, you don't have to choose one over the other. You can combine security groups and NACLs to configure access settings both at the instance and subnet levels. So, this is how you exercise control over access within your VPC.
route table
So you can set up security groups at the VPC level and then assign them to instances, providing control over access. If that's not enough, you can add Network Access Control Lists (NACLs) operating at the subnet level for an extra layer of control. But here's where it gets even more interesting – you have control over routing. Instead of just relying on firewalls, you can get down to the nitty-gritty of technical routing, ensuring traffic is directed differently even if a firewall is somehow compromised. How? Through route tables.
By default, when you create a new VPC, you get a default route table that controls how network traffic is routed when leaving your VPC. You have the flexibility to set up routing based on your specific needs. Is traffic allowed to reach other instances within the VPC? Can it leave the VPC? Routing is configured at the VPC level but specifically on the subnets.
Public and Private subnets
What's the value of an instance without a public IP? Well, it might lack an external address, but it can still have an internal one. The key here is that you can still reach it from within your VPC. Imagine having one subnet with public IPs accessible from outside and another subnet reachable only from within the VPC – perhaps for your database servers. Suddenly, the VPC concept starts to make more sense.
By default, a subnet is just a subnet – not public or private. But you can tweak a subnet's characteristics to make it public or private. How? It begins with routing. You can block outgoing traffic to deny Internet access for a subnet or allow it. You can also control whether a subnet assigns or receives public IPs for its instances.
This brings us to the idea of public and private subnets. Let's say you configure the routing and IP assignments such that one subnet is public, hosting web servers accessible from the Internet, while the other is private, housing database servers not accessible from the Internet but reachable from your web servers.
However, there's a twist. Sometimes, you want your private subnet instances to access the Internet for updates, for instance. You can achieve this by redirecting outgoing Internet access to a NAT (Network Address Translation) gateway, which translates internal IPs into public ones. This allows your private instances to indirectly access the Internet while still not having public IPs.
It may sound complex, but the core idea is to protect some resources from outside access while maintaining a network structure in the cloud. This setup provides security and control, ensuring collaboration within your network while safeguarding against external threats.
I feel that's too much networking for today, i don't wanna flood your brains too much. Hope you had a great read, see you in the cloud until next time :)