Architecture Series 1
In this series of posts on AWS architecture, I embark on a detailed journey from Point-A — the initial planing and setup of a VPC — to Point-B, where we will have constructed a complete and robust infrastructure based on AWS’s Well-Architecture Framework. My goal is not only to share my knowledge and experience but also to guide you through each stage of designing and implementing cloud architectures that are secure, efficient and scalable.
Architectural design is vast, and while I’m proficient with my AWS services, I often find my self questioning whether my implementations are the best fit for the objectives at hand. I know you will find thousand of ways, perhaps even better than those presented here, but that’s the idea: to show maybe one of the way to do the things and learn in the process. After all, the solution that fits one person may not suit everyone.
Join me as we build from the ground up, starting with a VPC, and feel free to contribute suggestions or ask questions along the way.
The first idea when I hear some say I want to deploy my application in Cloud is: “I need to create a VPC, with instances for the application in Availability Zones to delivery High Availability”.
But what is that called “Availability Zones”, in few works AWS have setup data centers (because against any forecast the Cloud is the computer of some else, in this case AWS) across separate geographic areas called Region that consist in multiple physically data centers, in this case on or more data center makes a Availability Zone and one or more Availability Zones makes a Region.
And this is how I am going to start to create my application, with this idea in mind from small idea to bigger until we create a fully and work architecture.
First Take: Basic Architecture for my web application
Considerations
- Security
- High Availability
- Monitoring
I am just a guy that is starting to deploy his basic application in AWS, I am very comfortable deploying my application in 2 EC2 behind an Application Load balancer, because I know for I need secure my application and avoid a malicious access to my servers that will host my application.
So I decide used the below architecture.
I will use
- 1 VPC
- 2 Public Subnets for public layer
- 2 Private Subnets for my private resources.
I decided use the CIDR 10.0.16.0/20, why?: the use of 10.0.16.0/20 CIDR block provides a balance between current needs and future grow potential. This CIDR gives me a total of 4096 IP addresses, which offers plenty of room for expansion as my project grows. I ensure that I won’t run out of IP addresses as I scale, whether that means adding more subnets, deploying new resources, or integrating additional services in the future. The block /20 provides the flexibility that I need to support my project while avoiding the limitations of smaller subnet.
The subnets will be distributed in the next way:
- 10.0.16.0/24 Public subnet
- 10.0.17.0/24 Private subnet
- 10.0.18.0/24 Public subnet
- 10.0.19.0/24 Private subnet
Why?: A/24 network provides a 254 usable IP addresses (considering the reserved addresses for Gateway, DNS, future projects and broadcast), which is more than sufficient for my current setup. This choice allows me to keep my architecture simple, minimizing potential complexities in managing a large subnet while also ensuring efficient use of IP space. Should my requirements grow in the future, scaling the network by adding additional subnets or resizing the CIDR block is always an option, but for now, a /24 provides a perfect balance between capacity and simplicity.
Why I am using 2 Public and private subnets?:
- Public subnets can host my application load balancer and other resources that will need internet access.
- Private subnets are perfect to host the application server from internet access reducing the surface of attack.
Why I am defining 2 availability zones?
- Allocating the resources between multiple availability zones I am ensuring the availability of the application, in case one zone fails the other can continue working as usual without affecting our customers.
Security
As this is a simple architecture for an application I am configuring specific security groups for every resource:
- A security group for ALB just with one inbound rule that allow the connections for HTTPS from any source.
- A security group for both instances with a inbound rule to allow connectivity from the SG of the ALB. Ensuring not include a rule from any where.
Why?, As we start to design we need to attach to something know it as “least-privilege principle”, its the best practice to grant only the access that the resources require to perform specific actions on specific conditions. In this case as my application its only be access through the Application load balancer, I only add the necessary permissions to complete this task.
This could be read as very simple and basic, but we are just starting and in every post I will add a layer of complexity to enhanced the architecture.
By carefully selecting each component and configuring them to work seamlessly together, I establish a solid foundation for my web application. This setup is designed to meet current needs while remaining flexible enough for future growth and scalability. I invite you to join me on this journey as we refine and expand our architecture. Your feedback and insights are invaluable; together, we can evolve our setups into more complex and robust systems. Stay tuned for future posts where we’ll delve deeper into advanced AWS features and best practices.