A virtual private cloud, or VPC, enables us to build a logical network unit where the vendor or service provider is in charge of managing the hardware and resources. We are in charge of configuring and organizing the network logically as users.
Only one region may be used to construct a VPC, and each VPC may contain several subnets. Within the VPC, granularity is provided via subnets. For this blog, I have three subnets. Each subnet’s IP address range needs to fit inside the boundaries of the VPC IPs, and no subnets’ IP ranges should cross. To build up such IP ranges, we employ the CIDR block.
There are two types of subnets: public subnets and private subnets. In contrast to private subnets, public subnets have direct access to the internet. Private subnets do not.
A VPC must be set up before we can enable traffic to and from the internet through an internet gateway. Not every subnet is made accessible to the internet by having an internet gateway; instead, the routeing table can decide which subnets are.
The traffic entering a VPC from the gateway is routed through a routing table and divided across subnets. A default route table for each VPC is linked to each subnet. To specify the traffic flow inside VPC, however, we may design our own route table. As a result, I established a unique route table and hooked it to the internet gateway with IP 0.0.0.0/0. I then connected two subnets to this route table that I had created on my own. By doing this, I have given public access to two of my subnets (out of three), while the third subnet is only connected to the default route table (still private).
The fact that each VPC can only have one internet gateway is crucial to know. Despite my attempts, the system did not let me attach a different gateway.
The VPC also needs a security group to specify inbound and outbound traffic, much like other AWS services. I have thus offered both total outgoing traffic and HTTP incoming traffic. This implies that every HTTP request coming in from the internet gateway and SSH will be permitted to get within the network. However, all output traffic to the internet will be permitted.
For security reasons, keeping track of any modifications after a network is set up is essential. As a result, we must build a log flow that will monitor every activity inside our VPC and deliver the information to the required location. We have two options: we can send it to the cloud watch or send it to s3 and use the data there for analysis. I’ve configured my flow log to send data to CloudWatch with the proper IAM role.
Developed VPC Look for VPC in the console. Select the appropriate template after clicking “start VPC wizard.” Enter the relevant information and click “create.”
2. Construct three subnets in various availability zones. Click Create a Subnet on the left panel’s subnet. Give the subnet’s name and attach it to the relevant VPC. As seen in the pictures below, repeat the process three times to create three subnets, each with a separate availability zone.
3. Built a web gateway and connected it to a VPC. On the left side, select Internet Gateway. Enter a name and then click Create. Lab Internet Gateway is what I gave it. Once it has been built, pick the gateway and choose an action from the drop-down menu. It will be possible to connect it to a particular VPC. Return to your VPC menu when you have connected.
4. Attempting to connect a second internet gateway to the same VPC. Repeat the previous steps to confirm that we can only link one gateway to one VPC.
5. After building a public access route table, out of three subnets, two are made public access, and one is left private access. Make a routing table first, then attach the relevant VPC. Click the router tab to change the routeing table after the VPC has been joined and established. Click add a route in the routeing table and input the public access IP address 0.0.0.0/0. Connect that IP to the VPC gateway we established in the stages above. Now, navigate to the subnet associated tab, choose two subnets, and click the Save button to make two of our subnets publicly accessible. In this manner, a routing table that is attached to the VPC gateway has been built, and two subnets have been added to it that may be accessed by the public via the associated gateway.
6. I’m attaching the security group now that the routing table has been added to the gateway and the subnet has been connected to the VPC. The security groups would permit traffic into and out of our VPC. I’m permitting HTTP and SSH for incoming traffic and full access for outgoing traffic. This indicates that only HTTP and SSH components may access the VPC but that nothing inside the VPC is restricted from being communicated outside. First, select “create security groups” under the security groups heading on the left panel. Next, give the security group a new name, provide a description, and attach the relevant VPC. Provide the incoming and outgoing traffic regulations, as seen in the picture. Once finished, choose to Create Security Groups, and the VPC will be connected.
7. Now that the entire environment has been configured, it is crucial to monitor all network activities. We would need to make a VPC flow log for that. Select the filter to instruct the flow log to track a certain kind of activity by first selecting the VPC we just created, then the flow log tab, and finally, the “create flow log” button, which is blue in color. If we want to monitor just approved requests in our network, only refused requests in our network, or both, for instance. I have chosen Every. Create a destination log group now. This log group will include all of the network log information. Logs can also be sent to an S3 bucket. Additionally, the IAM policy must be attached for the flow log to have access to cloud watch log groups to access the log group. We finally clicked “Save.”