Author: secureaccend

https://t.me/pump_upp

Blogs

Exploring the Power of AWS Direct Connect: Bridging the Gap Between On-Premises and the Cloud.

Post author By secureaccend
Post date December 29, 2023
2 Comments on Exploring the Power of AWS Direct Connect: Bridging the Gap Between On-Premises and the Cloud.

How To Configure AWS Direct Connect.

AWS Direct Connect is a high-speed, low-latency connection that allows you to access public and private AWS Cloud services from your local (on-premises) infrastructure.

The connection is enabled via dedicated lines and bypasses the public Internet to help reduce network unpredictability and congestion. This can give us some significance and advantages in terms of bandwidth as well as latency. And it ensures that we have got a consistence network for use. It will cost more than if you establish an AWS-managed VPN across the Internet.

Let’s look at the configuration of Direct Connect.

According to our reference architecture above, we have an AWS region with A VPC, and we’ve got a corporate data Center that could be an office. What we want to do is to connect that corporate data center to AWS.

To do that, we have to connect that via what is called an AWS direct connect location and this can be found in many cities around the world.

In the direct connect location, there is something called an AWS cage, and that’s where AWS has its networking equipment.

And then there is a customer or a partner cage, customer means that you will also own a rack into that Data Center with your networking equipment.

A partner simply means an APN partner partnered with AWS, and they have their cage of networking equipment and you can get a connection into their cage, and they do the connectivity into the AWS.

So, the way it works is that there are routers into these cages, into the direct connect location. Then a DX port (Direct connect port) must be allocated, in the Direct connect location. So, this is the port into which you are going to plug into a cross-connect.

The cross-connect is a cable that goes between the customer or partner cage, into the DX port that has been allocated into the AWS cage.

We then have a customer router in the corporate Data Center and we need to connect that to the DX router in the Direct Connect location. So that’s where we form the entrance connection.

So, AWS has their connection from their cage into the direct connect in the region but you must connect from your corporate data Center to the customer partner cage.

This is where some expenses and some challenges may take place because you will find you need to connect from your Data Center to the customer cage location if you don’t have a pre-existing location and sometimes that connection takes a bit of money and might take quite a bit of time.

It’s something you cannot set up very quickly, with Direct Connect, it takes weeks to months. And that’s how long Direct Connect takes to provision.

The actual DX connection is a physical fiber connection to AWS and runs either 1Gps or 10Gps.

Key Benefits of Direct Connect.

Private connectivity between your AWS and data Center or office,

Consistency network experience means increased speed and lower latency/consistency.

It can lower the cost for organizations to transfer large volumes of Data.

Let’s look at a bit more details.

Once we have established a physical connection, we then have to establish something called a virtual interface. as shown above by our reference architecture.

There are public and private virtual interfaces.

A private virtual interface connects to a single VPC in the same AWS region using a virtual private gateway VGW.

A VIF is essentially a virtual interface that uses 802.1Q VLAN and BGP sessions.

NOTE: 802.1Q VLAN (Virtual Local Area Network) and BGP (Border Gateway Protocol) are two distinct networking concepts.

The next Virtual interface is public, and what this does is to connect you to the AWS public services in any region. So, private VIF goes into the same region as the actual physical connection, but the public VIF can connect to a public service in any region. It doesn’t connect you to the Internet, so you can’t use it for internet purposes.

What if you have multiple VPCs in the region,

In this case, you will have multiple VGWs and multiple private VIFs that we will use to connect to those VGWs. So, you are connecting to multiple VPCs each is connected over a separate private face.

This can also be shared with other AWS accounts, when you do that, is known as a hosted VIF.

You can get speeds of 50Mbps to 100Mbps if you use an APN partner. An APN partner will have a connection already to AWS, and essentially, they are giving you a subset of that connection.

This can be implemented, either via a hosted, VIF, or a hosted connection.

Hosted VIF, is a single VIF, that is shared with other customers. In that case, there is a shared bandwidth.

Or you use a hosted connection, that is a DX with a single VIF dedicated to you, so obviously there is a cost implication to this, but if you go with the cheaper option, the hosted VIF, you are going to ensure that you understand that there is shared bandwidth happening there.

NOTE: DX connections are not encrypted hence this could be a security risk.

So, the question is what can we do to make sure our data is encrypted?

We can have an IPsec S2S VPN (site-to-site VPN connection) running over a VIF to add encryption in transit, so essentially you are running Direct Connect then on top of Direct Connect so you encrypt the traffic that goes over that direct connect using an AWS managed VPN connection.

Link aggregation groups (LAGs) can be used to combine multiple physical connections into a single logical connection and use LACP (the link aggregation control protocol). This is just for improved speed; it’s not going to give you high availability.

DX design for high availability.

On the subject of high availability, let’s look at how you can design DX to make sure that you have high availability built into these connections. When we look at our first architectural diagram, we can identify very many points of failure. For high Resiliency for critical workloads using two single connections to more than one location. The below design helps to prevent connection against device, connectivity, and complete location failure.

This is going to be a considerably more expensive setup than if we have very low levels of redundancy. As you add redundancy you always add cost but you have to consider your business and the impact of an outage.

another implementation we could do to add redundancy is rather than adding a Direct Connect connection, we can add an IPsec VPN as shown below.

In this architecture we have the DX connection which is the primary path, we have a VGW which is connected back to the corporate data Center using a site-to-site VPN, which is the backup path, we give priority to our traffic to use the DX link, but if the DX link fails due to some reason, we have a backup path over the internet. but since the internet has some disadvantages, like lower bandwidth and considerably lower latency this might have an impact on your business. so, you get to consider an option that is best for your business but the last option could be significantly cheaper than having a fully redundant DX configuration.

a recommendation from AWS is that you should not use this architecture if your speeds are over 1Gbps. so, if you need more than 1Gbps of bandwidth don’t use this setup because of limitations in the AWS VPN.

This brings us to the end of this blog. Thanks for your attention.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at info@accendnetworks.com.

Thank you!.

Blogs

How to Configure A Dual-NAT Gateway

Post author By secureaccend
Post date December 20, 2023
1 Comment on How to Configure A Dual-NAT Gateway

HOW TO CONFIGURE A DUAL-NAT GATEWAY IN TWO DIFFERENT AVAILABILITY ZONES.

In this comprehensive guide, we will take you through configuring a dual-NAT gateway in two different availability zones, paired with route tables, enabling your private subnets to access the internet securely.

According to our reference architecture, we will create a Nat gateway in the public subnet az1, we will create a route table that we call private route table az1. We will then add a route to that route table to route traffic to the internet through the Nat gateway. We will then associate that route table with the private app subnet az1, and private data subnet az1.

Again, for the second availability zone:

We will create another Nat gateway in the public subnet az2. We will then create another route table called private route table az2, we will add traffic to this route table to route traffic to the internet through the Nat gateway in the public subnet az2. We will then associate this route table with the private app subnet az2 and private data subnet az2.

Let’s start.

Refer to our previous post on creating a Custom 3 tier-VPC. We will use that VPC project to accomplish this project.

To create the Nat gateway first make sure you are in the region where you created the VPC.

Then in the search box, type VPC and select VPC under services.

On the VPC dashboard on the left side of the navigation pane select Nat gateway, then click Create Nat gateway.

We will create the first Nat gateway in the public subnet az1.

In the create Nat gateway dashboard under name give your Nat gateway name, call it Nat gateway az1. Once you’ve given your Nat gateway a name, select the subnet where you want to put your Nat gateway. so under subnet, select the drop-down and look for public subnet az1 then select it. Then for connectivity type leave it on the default public, because we are creating a public Nat gateway.

Scroll down, under elastic allocation ID click allocate an elastic IP and that is going to allocate an elastic IP for you.

These are the only settings we need to create a Nat gateway, scroll down and click Create Nat gateway.

Success, we have created our first Nat gateway in the public subnet az1

Next, we will create a route table and call that route table, private route table az1. On the left side of your screen, select route tables then click create route table.

In the create route table dashboard under name, give your route table a name, and call it private route table az1. Once you’ve given the route table a name, select the VPC you want to create this route table in, so under VPC, select the drop-down and select your prod- VPC.

These are the only settings we need to create a route table now click create route table.

Success, we have successfully created our first private route table in private subnet az1.

Next, we will add a route to the private route table az1 to route traffic to the internet through the Nat gateway in the public subnet az1.

To add a route to this route table, navigate to the routes tab, select edit routes then click Add route

For the destination remember internet traffic is always 0.0.0.0/0 so under destination type in this value.

Then under target, the target is going to be our Nat gateway in the public subnet az1, so click in the search box, then select Nat gateway. Make sure you select Nat Gateway and not Internet Gateway. You should see the Nat gateway in the public subnet az1, it is the Nat gateway we call Nat gateway az1. Select it then click Save Changes.

Successfully, we have added a route to the route table to route traffic to the internet through the Nat gateway in the public subnet az1.

When you scroll down, you can see the routes here.

Next, we will associate this route table with private app subnet az1 and private data subnet az1.

To associate this route table with our subnets, click subnet associations, then click edit subnet associations.

In the edit subnet associations dashboard, under the available subnets, select private app subnet az1, and private data subnet az1. Once you’ve selected the two subnets, click Save Associations.

We have successfully associated our private app subnet az1 and private data subnet az1 to this route table.

And you can see that information, under explicit subnet associations, we have two subnets there.

If you click on the subnet’s association tab a gain, you will see that the private app subnet az1 and private data subnet az1 are associated with the route table.

Next, we will create the second Nat gateway in the public subnet az2. On the left side of the VPC dashboard select Nat gateway. then click Create Nat gateway.

Under Nat gateway settings give the Nat gateway a name, call it Nat gateway az2. Then select the subnet you want to put the NAT gateway in. Under subnets, select the drop-down and select public subnet az2. For connectivity type leave it on the default public because we are creating a public Nat gateway. Under elastic IP allocation ID, click the allocate elastic IP button, this will allocate an elastic IP for you.

Scroll down and click Create Nat gateway.

We have successfully created the Nat gateway.

The next thing we will do is to create another route table and call it private route table az2.

On the left side, select the route table. then click Create Route Table.

Under name give your route table a name, call it private route table az2. Once you’ve given your route table a name then, select the VPC you want to put your route table in, so under VPC, select the drop-down and select your prod VPC. These are the only settings we need to create this route table, click create route table.

We have successfully created a private route table az2.

Now that we have successfully created the private route table az2, we will add a route to this route table to route traffic to the internet through the Nat gateway in the public subnet az2. To add a route to this route table, select the routes tab then click edit routes.

In the edit routes dashboard click Add route

Under destination remember traffic going to the internet is always 0.0.0.0/0 so type it in there and select it.

Then under targets, we will select our Nat gateway, so select the search box, and select Nat gateway.

And this time make sure you select Nat gateway az2. Then click save changes.

We have successfully added a route to this route table to route traffic to the internet through the Nat gateway in the public subnet az2.

To see that route scroll down and you will see it there.

The last thing we will do is associate this route table with private app subnet az2, and private data subnet az2

To associate this route table with our subnets, go to the subnets associations tab, select it then click edit subnet associations.

Under available subnets, we will select the private app subnet az2 and private data subnet az2. Once you’ve selected the subnets, click Save Associations.

We have successfully associated our private app subnet az2, and private data subnet az2 with the private route table az2.

To see that, we can see that we have two subnets under explicit subnet associations.

and if you click on the subnet’s associations tab, you will see that our private app subnet az2, and private data subnet az2 are associated with this route table.

This is how we create Nat gateway to allow resources in our private subnet, to have access to the internet.

Delete The AWS NAT Gateway

After completion of your practice on the NAT Gateway you have to delete it to avoid incurring charges. Remember when you provision a NAT gateway, you are charged for each hour that your NAT gateway is available and each gigabyte of data that it processes.

Deleting a NAT gateway disassociates its Elastic IP address, but does not release the address from your account. So again, make sure you release the elastic IP address from your account.

Stay tuned for more.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at sales@accendnetworks.com

Thank you!

Tags AWS, AWS Cloud, AWS Cloud Computing, AWS Security

Blogs

Vpc Part Two: Building A Custom 3-tier Vpc From Scratch

Post author By secureaccend
Post date December 18, 2023
9 Comments on Vpc Part Two: Building A Custom 3-tier Vpc From Scratch

VPC PART TWO: BUILDING A CUSTOM 3-TIER VPC FROM SCRATCH

In our custom 3-tier VPC reference architecture, our infrastructure is divided into 3 tiers. The first tier which we can also call the user interface or presentation tier, has public subnets which can hold resources such as

NAT gateways
load balancers
bastion hosts

On the second tier which I also call the application tier, we have our private subnets, and this is the tier that can hold resources such as EC2 Instances (webservers).

On the third tier which I also call the database tier, we have another private subnet and this is the tier that holds databases.

The subnets are duplicated across multiple availability zones for high availability and fault tolerance.

Finally, we have an internet gateway and route table to allow the resources in the VPC to have access to the internet.

To create this VPC, let’s log into the management console.

The first thing you should do is select the region where you want to create the VPC. according to our reference architecture, this VPC should be in the US East (N. Virginia) region. (us-east-1)

To change your region, select the dropdown in the top right navigation pane in the management console, and make sure you select, Us-east (Northern Virginia).

Straight away type VPC in the search box, then select VPC under services.

In the VPC dashboard, select VPC’s then click create VPC.

Under VPC settings, select VPC only then give your VPC a name, and call it prod-VPC.

Leave it on the IPv4 CIDIR block.

Under IPv4 CIDIR, enter Your CIDIR block. According to our reference architecture, it is 10.0.0.0/16. Then leave it at no ipv6 CIDIR block, tenancy is going to be the default, and tags are optional. Scroll down and click Create VPC.

We have successfully created our VPC

NOTE: You can see all the VPC’s in your account by selecting the filter by VPC search box below.

Once you filter it by a particular VPC, it will only show you the information on that VPC.

Next, we will enable the DNS hostname for our VPC.

DNS options

If you need public IPv4 DNS hostnames for the EC2 instances launched into your subnets, you must enable both of the DNS options.

Enable DNS hostnames: EC2 instances launched in the VPC receive public DNS hostnames that correspond to their public IPv4 addresses.

To enable the DNS hostname in your VPC, make sure you’ve selected the VPC you’ve just created then select the actions drop-down button, then select edit VPC settings.

On the edit DNS hostnames dashboard, check the box on enable DNS hostname and then click save changes.

We have successfully modified VPC settings and enabled DNS hostname in our VPC.

Next is to create an internet gateway to allow resources in the VPC to communicate with the public. On the left side of the VPC dashboard, select Internet Gateway, and then click Create Internet Gateway.

In the create Internet gateway dashboard, under the name, give your Internet gateway a name, call it prod Internet Gateway and leave tags as optional then click Create Internet Gateway.

You have successfully created an internet gateway.

Next, we will attach the Internet Gateway to the VPC we just created.

To attach an internet gateway to a VPC, click the attach to a VPC

Under available VPC’s, click in the search box and select your prod-VPC. Remember only the VPC that does not have an Internet Gateway attached to it in your account will show up.

You can only attach one internet gateway, to a VPC. We just created this prod VPC and we haven’t attached any internet gateway to it; that’s why it’s the only VPC that is showing there. Select it and then click Attach Internet gateway.

We have successfully attached an internet gateway to our prod VPC.

If you look at the Internet gateway, the state is attached, and the VPC it is attached to is the prod VPC.

Next, we will create our public subnets in the first and the second availability zones, as shown according to our reference architecture. On the VPC dashboard on the left side of the navigation pane, select subnets.

I am still filtering my VPC, by the prod VPC, that’s why we are not seeing subnets in there because we have not created any subnet in that VPC.

We will create our first and second public subnets in this VPC. Click Create Subnet.

In the create subnet dashboard, select the VPC you want to create your subnet. Select the drop-down and select prod-VPC. Scroll down.

In the subnet settings sections, enter the details of your subnets, under name, call it public subnet az1, under Availability zone select the drop-down button and select us-east-1a, for IPv4 subnet CIDR block, enter 10.0.0.0/24. Then scroll down and click add new subnet, this will be the second public subnet.

Use the same procedure and enter the details of the second subnet as shown below. Remember the second subnet should be in us-east-1b AZ leave tags as optional and click create subnet.

Success, we have created our two public subnets.

Next, we will enable auto-assign IP settings. Select the first one and then select actions. Then click edit subnet settings.

Then in the edit subnet settings dashboard under the auto-assign IP settings section, check the box next to enable auto-assign public IPv4 address and then click save.

We have successfully changed the subnet settings.

Repeat the same procedure for the subnet in the second vailability zone. Click the action drop-down, and select Edit subnet settings.

Then in the edit subnet settings dashboard, under the auto-assign public IP settings section, check the box next to enable auto-assign IPv4 address then click save.

You have successfully changed the subnet settings.

Following our reference architecture, we will create a route table. On the left side of the navigation pane on the VPC dashboard, select the route table as shown.

It filters my VPC by the prod VPC, and in the prod VPC, there is only one route table and it is called the main Route table and it is private by default. This route table was created when you created the VPC.

To create the public route table, click Create route table.

In the Create Route Table dashboard, under name call your Route table public Route Table. Under VPC, select the drop-down button, and select your prod-VPC then click Create Route Table.

Route table successfully created. If you go to the routes tab, it shows local, which means it is only routing traffic locally within the VPC. This is because we have not associated this route table with any route.

Let’s add a public route to this route table. To add a route to the route table, make sure you are in the routes tab, and then click edit routes then click add route.

To add a route that routes traffic to the internet to this route table, under destination, click in the search box and type 0.0.0.0/0 then select it.

Then under target click in the search box a gain and here select your internet gateway.

Once you’ve selected the internet gateway, the internet gateway you have in your VPC will show up, and as you can see it’s the prod internet gateway. Select it and then click Save Changes.

The public route has been updated successfully. If you move to the routes tab, you will see the route.

Next, is to associate our two public subnets with the public route table. Move as follows, make sure you are still in the public route table, then move to the subnet associations tab. Once in the subnet association tab, click edit subnet associations.

You will be brought to the subnet association dashboard, here select the two subnets, public subnets az1 and az2 then click save associations.

Finish creating your VPC. Proceed to create the four remaining private subnets.

To create the private subnets, on the left side of the VPC dashboard, select subnets.

It filters by my VPC, and currently, I have two subnets.

We will strictly follow our reference architecture. Click Create Subnet.

In the create subnet dashboard, under VPC, select the drop-down button and select your prod-VPC. Scroll down.

Under the subnet name, enter private app subnet az1, under the availability zone, select the drop-down button and select us-east-1a, under IPv4 subnet CIDR block enter 10.0.2.0/24. Then scroll down at the bottom and click Add New Subnet.

This will be our second private subnet, enter the details as shown below, the details are a reflection of the reference architecture. Again move to the bottom and click add new subnet for the third private subnet.

Repeat the same procedure and enter the subnet details as shown below. Then scroll down and click Add new subnet for the fourth private subnet.

Enter the fourth subnet details as shown below, and make-sure the availability zones and CIDR block in the reference architecture are strictly followed. Click Create Subnets.

We have successfully created the four private subnets.

We created the four private subnets and did not explicitly associate them with any route table, hence they will be implicitly associated with the main route table.

This brings us to the end of this exercise. Pull down and stay tuned for more.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at sales@accendnetworks.com.

Thank you!

Blogs

Understanding AWS ACL (Access Control Lists): Controlling Subnet Traffic

Post author By secureaccend
Post date December 12, 2023
3 Comments on Understanding AWS ACL (Access Control Lists): Controlling Subnet Traffic

Understanding AWS ACL (Access Control Lists): Controlling Subnet Traffic

Network traffic flow in AWS

Before starting, let’s see how network traffics move among the resources. Traffics come from the internet to the internet gateway and then, according to the routes defined in the route tables, are directed to the virtual private cloud (VPC) subnets based on the rules defined through AWS ACL (Access Control Lists).

What is an AWS ACL?

In Amazon Web Services (AWS), NACL stands for Network Access Control List. An AWS ACL (Access Control Lists) is a stateless, rule-based system that acts as a virtual firewall for controlling inbound and outbound traffic at the subnet level in a Virtual Private Cloud (VPC). An AWS ACL (Access Control Lists) allow or deny specific inbound or outbound traffic at the subnet level while the security group controls the qualified traffic to reach and leave the resources.

The ACL resides in front of the VPC subnets, and the security Groups protect the AWS resources, such as EC2 instances. It is one of the most critical differences between Network ACL and Security Group.

Network Access Control lists (NACL’s) are used to manage traffic at the network layer. Hence the name Network access control list. Picture it as the first line of defence for your cloud infrastructure, filtering traffic based on rules you set. ACLs are stateless and filter traffic based on rules defined for inbound and outbound traffic at the subnet level.

When you create a Virtual Private Cloud (VPC), it automatically associates a default NACL that permits all inbound and outbound traffic.

NACL’s are a powerful tool that can be used to improve the security of your AWS VPC. However, it is important to note that NACL’s are just one component of a comprehensive security strategy. To protect your AWS resources, you should also use other security features, such as security groups, IAM roles, and WAF rules.

Components of Network Access Control List (NACL)

Rule Number: Each rule is assigned a unique number, and they are evaluated in ascending order. Once a rule matches incoming or outgoing traffic, it is immediately applied, even if higher-numbered rules contradict it.

Protocol: You have the flexibility to define any standard protocol, such as HTTP, HTTPS, ICMP, SSH, etc. when configuring rules for the ACL.

Inbound Rules: Inbound rules determine the source of incoming traffic and the destination port it is allowed to reach.

Outbound Rules: Outbound rules specify the destination for outgoing traffic and the destination port it can access.

Types of Network ACL

Default Network ACL

The default network ACL permits unrestricted traffic to enter or exit the associated subnet. Additionally, every network ACL includes a rule marked with an asterisk rule number, responsible for denying traffic that doesn’t match any numbered rules. This particular rule is immutable and cannot be altered or deleted.

In this example, the above table is a default Network ACL table, which is associated with a subnet.

Rule 200 allows incoming HTTP traffic (port 80) from the source IP range 10.0.0.0/24.

Rule 201 allows incoming HTTPS traffic (port 443) from the same source IP range 10.0.0.0/24.

Rule 202 permits SSH traffic (port 22) from the source IP range 192.168.1.0/24.

Rule 203 allows RDP traffic (port 3389) from the same source IP range 192.168.1.0/24.

The wildcard rule (*) at the bottom denies all other incoming and outgoing traffic, providing a default security posture that allows only specific types of traffic from specified source IP ranges while denying all other traffic.

Custom Network ACL

This user-defined access control list lets you customize your network security policies.

In this example:

Rule 100 allows incoming HTTP traffic (port 80) from the source IP range 10.0.0.0/24.

Rule 101 permits incoming HTTPS traffic (port 443) from the same source IP range 10.0.0.0/24.

Rule 102 allows SSH traffic (port 22) from the source IP range 192.168.1.0/24.

Rule 103 permits RDP traffic (port 3389) from the same source IP range 192.168.1.0/24.

The wildcard rule (*) at the end serves as a catch-all, denying all incoming and outgoing traffic, and providing a default security posture that allows only specific types of traffic from specified source IP ranges while blocking everything else. This custom Network ACL offers fine-grained control over traffic, allowing or denying access based on defined rules.

Hands-on demo Creating a Network ACL

In the VPC dashboard on the left side of the navigation pane under security, select “Network ACLs.” Then click “Create Network ACL.”

In the Create Network Access Control list dashboard, Provide the necessary information to create a Network ACL. Under the name, provide a name, for my case I will call it demo-ACL

Then under VPC, select the drop-down button and select your VPC, I created the prod-VPC so I will select it.

These are the only necessary settings to create NACL, leave tags as optional then scroll down and click create network ACL.

Success our NACL has been successfully created.

Note: By default, all inbound and outbound rules deny all traffic for newly created Network ACL as shown below.

Associate Subnet to Network ACL

Note: You can associate a network ACL with multiple subnets. but a subnet can be associated with only one network ACL at a time.

To associate subnets, move to the subnet association tab, then click Edit subnet associations.

In the edit subnet association dashboard, select your subnets by ticking the boxes, under the name, then click save changes.

We have successfully associated our subnets with the created NACL.

Configure Inbound and Outbound rules:

First, launch an instance in the subnets associated with the NACL, then try to access your Public/Application server. It should not be accessible, due to no inbound and outbound rules configured yet. Now, Edit and add a new inbound and outbound rule.

Select the NACL ID then click it, in the ACL dashboard, move to the Inbound rules tab then select Edit Inbound rules

In the edit inbound rule dashboard, click Add new rule.

Remember the rules are added in ascending numbers.

The first rule we will add is HTTP port 80, under rule number enter 100, then under custom TCP select the drop-down and select HTTP. Repeat the same process for HTTPS, and SSH then click save changes.

Then move to the outbound rules tab then, click edit outbound rules.

Add the first rule number. we will add rule 100, then under custom TCP select HTTP port 80, repeat the same, and add rule numbers 200, and 300 for HTTPS and SSH respectively then click save changes.

We have successfully added outbound rules.

Note: Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it gets executed regardless of any higher-numbered rule that might contradict it. For example, if rule 100 allows port 80, and rule 90 denies port 80, finally, port 80 will be denied as rule 90 is evaluated before 100.

Block IP address

Block IP address: Edit the inbound rule and try to block your own IP, after that, you should not be able to access your public/Application server.

This brings us to the end of this demo; always ensure you clean up resources.

Conclusion

NACL’s are important for AWS network security. They work with security groups, which handle different security aspects. NACL’s control traffic at the subnet level, using IP addresses and rules. Security groups manage access at the instance level, based on group memberships. These tools work together to defend against cyber threats.

Thanks for your attention and stay tuned for more.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at. sales@accendnetworks.com

Thank you!

Tags AWS, AWS Cloud, AWS Cloud Computing, AWS Security

Blogs

Vpc Part Two: Building A Custom 3-tier Vpc From Scratch.

Post author By secureaccend
Post date December 12, 2023
1 Comment on Vpc Part Two: Building A Custom 3-tier Vpc From Scratch.

VPC PART TWO: BUILDING A CUSTOM 3-TIER VPC FROM SCRATCH.

Nat gateways,
load balancers
and bastion hosts.

On the second tier which I also call the application tier, we have our private subnets, and this is the tier that can hold resources such as EC2 Instances (webservers).

On the third tier which I also call the database tier, we have another private subnet and this is the tier that holds databases.

The subnets are duplicated across multiple availability zones for high availability and fault tolerance.

finally, we have an internet gateway and route table to allow the resources in the VPC to have access to the internet.

To create this VPC, let’s log into the management console.

The first thing you should do is select the region where you want to create the VPC. according to our reference architecture, this VPC should be in the US East (N. Virginia) region. (us-east-1)

To change your region, select the dropdown in the top right navigation pane in the management console, and make sure you select, Us-east (Northern Virginia).

Straight away type VPC in the search box, then select VPC under services.

In the VPC dashboard, select VPC’s Then click create VPC

Under VPC settings, select VPC only then give your VPC a name, and call it prod-VPC.

Leave it on the IPv4 CIDIR block.

We have successfully created our VPC

NOTE: you can see all the VPC’s in your account by selecting the filter by VPC search box below.

Once you filter it by a particular VPC, it will only show you the information on that VPC.

Next, we will enable the DNS hostname, for our VPC.

DNS options

If you need public IPv4 DNS hostnames for the EC2 instances launched into your subnets, you must enable both of the DNS options.

Enable DNS hostnames: EC2 instances launched in the VPC receive public DNS hostnames that correspond to their public IPv4 addresses.

To enable the DNS hostname in your VPC, make sure you’ve selected the VPC you’ve just created then select the actions drop-down button, then select edit VPC settings.

on the edit DNS hostnames dashboard, check the box on enable DNS hostname then click save changes.

we have successfully modified VPC settings and enabled DNS hostname in our VPC.

Next is to create an internet gateway to allow resources in the VPC to communicate with the public. On the left side of the VPC dashboard, select Internet Gateway, then click Create Internet Gateway.

In the create Internet gateway dashboard, under the name, give your Internet gateway a name, call it prod Internet Gateway

leave tags as optional then click Create Internet Gateway.

You have successfully created an internet gateway.

Next, we will attach the Internet Gateway to the VPC we just created.

To attach an internet gateway to a VPC, click the attach to a VPC

Under available VPC’s, click in the search box and select your prod-VPC. Remember only the VPC that does not have an Internet Gateway attached to it in your account will show up.

You can only attach one internet gateway, to a VPC. We just created this prod VPC and we haven’t attached any internet gateway to it, that’s why it’s the only VPC that is showing there. Select it, then click Attach Internet gateway.

We have successfully attached an internet gateway to our prod VPC.

If you look at the Internet gateway, the state is attached, and the VPC it is attached to is the prod VPC.

I am still filtering my VPC, by the prod VPC, that’s why we are not seeing subnets in there because we have not created any subnet in that VPC.

We will create our first and second public subnets in this VPC. Click Create Subnet.

In the create subnet dashboard, select the VPC you want to create your subnet. Select the drop-down and select prod-VPC. Scroll down.

Use the same procedure and enter the details of the second subnet as shown below. Remember the second subnet should be in us-east-1b AZ leave tags as optional and click create subnet.

Success, we have created our two public subnets.

Next, we will enable auto-assign IP settings. Select the first one Then select actions. Then click edit subnet settings.

Then in the edit subnet settings dashboard under the auto-assign IP settings section, check the box next to enable auto-assign public IPv4 address then click save.

We have successfully changed the subnet settings.

Repeat the same procedure for the subnet in the second vailability zone. Click the action drop-down, and select Edit subnet settings.

Then in the edit subnet settings dashboard, under the auto-assign public IP settings section, check the box next to enable auto-assign IPv4 address then click save.

You have successfully changed the subnet settings.

Following our reference architecture, we will create a route table. On the left side of the navigation pane on the VPC dashboard, select the route table as shown.

It is filtering my VPC by the prod VPC, and in the prod VPC, there is only one route table and it is called the main Route table and it is private by default. This route table was created when you created the VPC.

To create the public route table, click Create route table.

In the Create Route Table dashboard, under name call your Route table public Route Table. Under VPC, select the drop-down button and select your prod-VPC then click Create Route Table.

Route table successfully created. If you go to the routes tab, it shows local.

which means it is only routing traffic locally within the VPC. This is because we have not associated this route table with any route.

Let’s add a public route to this route table. To add a route to the route table, make sure you are in the routes tab, then click edit routes then click add route.

To add a route that routes traffic to the internet to this route table, under destination, click in the search box and type 0.0.0.0/0 then select it.

Then under target click in the search box a gain and here select your internet gateway.

Once you’ve selected the internet gateway, the internet gateway you have in your VPC will show up, and as you can see it’s the prod internet gateway. Select it then click Save Changes.

The public route has been updated successfully. If you move to the routes tab, you will see the route.

You will be brought to the subnet association dashboard, here select the two subnets, public subnets az1 and az2 then click save associations.

finish creating your VPC. Proceed to create the four remaining private subnets.

to create the private subnets, on the left side of the VPC dashboard, select subnets.

It is still filtering by my VPC, and currently, I have two subnets.

We will strictly follow our reference architecture. Click Create Subnet.

In the create subnet dashboard, under VPC, select the drop-down button and select your prod-VPC. Scroll down.

Repeat the same procedure and enter the subnet details as shown below. Then scroll down and click Add new subnet for the fourth private subnet

Enter the fourth subnet details as shown below, and make-sure the availability zones and CIDR block in the reference architecture are strictly followed. Click Create Subnets.

We have successfully created the four private subnets.

We created the four private subnets and did not explicitly associate them with any route table, hence they will be implicitly associated with the main route table.

This brings us to the end of this exercise. Pull down and stay tuned for more.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at. sales@accendnetworks.com

Thank you!