๐Ÿš€Day-6:Building a Secure and Scalable 2-Tier Network Architecture(Linux) on AWS ๐Ÿš€

Step-by-Steps

In today's cloud-driven world, building a secure and scalable network architecture is crucial for ensuring that cloud resources are protected and efficiently managed. In this blog, I'll walk you through how I designed and deployed a 2-Tier AWS Virtual Private Cloud (VPC) network architecture using Linux EC2 instances. This architecture focuses on isolating frontend and backend services, ensuring security, and enabling smooth communication between them.

๐Ÿ’ก What is a 2-Tier Architecture?

A 2-tier architecture is a network design that separates an applicationโ€™s frontend (user-facing) and backend (data processing) components into two distinct layers or tiers:

  1. Tier 1 (Frontend): Contains public-facing resources that interact with users directly, such as web servers.

  2. Tier 2 (Backend): Contains private resources, such as databases and APIs, that handle data processing but are not directly accessible from the internet.

In AWS, we can achieve this by using Virtual Private Cloud (VPC), which allows us to isolate resources in a secure and scalable environment.


๐Ÿ› ๏ธ Key Components of the AWS VPC 2-Tier Architecture

Hereโ€™s a breakdown of the essential AWS components used in this project:

1. Virtual Private Cloud (VPC)

The VPC is the foundation of our network architecture. It creates an isolated cloud environment where we can launch and manage resources.

  • CIDR Block: 10.0.0.0/16 โ€“ A block of private IP addresses used within the VPC.

2. Subnets

  • Public Subnet (Frontend): Hosts internet-facing resources. Instances in this subnet can communicate with the internet via an Internet Gateway.

  • Private Subnet (Backend): Hosts secure backend resources, which do not have direct internet access. Instead, they use a NAT Gateway for outbound connections.

3. Gateways

  • Internet Gateway (IGW): Provides public instances with direct internet access.

  • NAT Gateway: Allows private instances to access the internet securely for updates or outbound traffic without exposing them to inbound internet traffic.

4. Route Tables

  • Public Route Table: Routes traffic from the public subnet to the internet via the IGW.

  • Private Route Table: Routes outbound traffic from the private subnet through the NAT Gateway, keeping the backend isolated.

5. Security Groups

  • Public Security Group: Allows inbound traffic for SSH (22), HTTP (80), and HTTPS (443) to the frontend instances.

  • Private Security Group: Restricts access to internal traffic only, keeping backend instances secure.

6. EC2 Instances (Linux)

  • Instance 1 (Public Subnet): A Linux EC2 instance with a public IP, accessible from the internet for the frontend.

  • Instance 2 (Private Subnet): A Linux EC2 instance without a public IP, securely isolated for backend operations.


๐Ÿš€ Step-by-Step Process for Building the Architecture

1. Create a VPC

  • Start by creating a VPC with a 10.0.0.0/16 CIDR block, providing a large range of private IP addresses for internal use.

2. Set Up Subnets

  • Public Subnet: Place resources like frontend servers that need direct internet access.

  • Private Subnet: Place backend services like databases, which should remain isolated from public access.

3. Configure Gateways

  • Attach an Internet Gateway to the VPC to allow public instances to communicate with the internet.

  • Deploy a NAT Gateway in the public subnet, enabling secure outbound traffic from instances in the private subnet.

4. Set Up Route Tables

  • Link the public route table to the internet gateway to route internet-bound traffic.

  • Connect the private route table to the NAT Gateway for secure internet access from the private subnet.

5. Security Groups and Rules

  • Public Security Group: Allow inbound traffic on ports 22 (SSH), 80 (HTTP), and 443 (HTTPS) to the public instance.

  • Private Security Group: Allow only internal traffic to the backend instance, restricting all external traffic.

6. Launch EC2 Instances

  • Launch a Linux EC2 instance in the public subnet for the frontend, with a public IP for remote access.

  • Launch another Linux EC2 instance in the private subnet for the backend, without a public IP to maintain security.


๐Ÿ” Testing and Validating the Architecture

To verify that the architecture is working as expected, follow these simple steps:

1. Check Internet Connectivity (Public Instance)

Log into your public EC2 instance using SSH and run the following command to check internet access:

bashCopy codeping google.com

If you receive responses, the public instance is correctly configured.

2. Test NAT Gateway (Private Instance)

For the private instance, log in via the public instance using SSH tunneling or EC2 Instance Connect, and test the outbound internet access using:

bashCopy codeping google.com

A successful response confirms that the NAT Gateway is functioning correctly, allowing the private instance to access the internet securely.


๐Ÿ’ก Key Learnings and Best Practices

Through this project, Iโ€™ve gained valuable insights into cloud networking and security:

  • Resource Isolation: By separating frontend and backend resources, we ensure that only authorized traffic can reach sensitive backend services.

  • Secure Outbound Access: Using a NAT Gateway allows private instances to download updates and communicate with external services without being exposed to the internet.

  • Scalability: This 2-tier architecture lays the foundation for a scalable system, as more instances can be easily added to either the public or private subnet.


๐Ÿ› ๏ธ Tools and Technologies Used

  • AWS VPC for building a custom network environment.

  • Linux EC2 Instances for secure, scalable compute power.

  • Internet Gateway & NAT Gateway for managing network traffic.

  • Security Groups to control inbound and outbound traffic.


๐ŸŽฏ Future Enhancements

This architecture can be extended by adding:

  • Auto Scaling to dynamically adjust resources based on demand.

  • Elastic Load Balancing (ELB) to distribute incoming traffic across multiple frontend instances.

  • Amazon RDS for reliable and scalable database services in the private subnet.


๐ŸŒŸ Conclusion

This project serves as a foundational example of building secure and scalable architectures on AWS using best practices. It demonstrates key AWS services like VPC, Subnets, Internet Gateway, NAT Gateway, and Security Groups to build a well-architected 2-tier network that can be expanded for enterprise-level applications.

If you found this helpful or have any questions, feel free to leave a comment or connect with me on LinkedIn!


๐Ÿ“ข Tags to Improve Visibility

hashtag#AWS hashtag#VPC hashtag#Linux hashtag#CloudComputing hashtag#DevOps hashtag#InfrastructureAsCode hashtag#CloudSecurity hashtag#AWSArchitect hashtag#CloudNetworking hashtag#Automation hashtag#CloudInfrastructure hashtag#TechBlog hashtag#Networking hashtag#CloudEngineering hashtag#Security

0
Subscribe to my newsletter

Read articles from Santhosh Haridass directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Santhosh Haridass
Santhosh Haridass

๐Ÿš€ ๐€๐›๐จ๐ฎ๐ญ ๐Œ๐ž "Hi, I'm Santhosh Haridass, a DevOps student passionate about cloud computing and automation. I'm currently learning AWS, Linux, Docker, and CI/CD pipelines, with a focus on automating workflows and building scalable solutions. My goal is to become a skilled DevOps/Cloud engineer, and I'm excited to share my learning journey and projects with the community."