Cloud Engineer Academy — Week 5 & 6 Part 1: Bastion Host on AWS
I have completed the first section of Module 5 & 6 — AWS Fundamentals in the Cloud Engineer Academy. This is just the first part of a larger framework I’m engaged in. The overall goal is to familiarize myself with the AWS console before diving into Infrastructure as Code (IaC), and I’m all in for it.
Now, observe this architecture. You might think, “Wow, the person who created this is going to build a large, scalable, three-tier infrastructure.” Or, “Wow, this individual must be thorough, given their use of NACLs.” However, the reality is that we’re operating under the AWS Free Tier. Despite our eagerness to complete projects, we are limited by the available services. But I, or rather, the person in question, is grateful nonetheless. It’s not only a privilege to have hands-on experience with such technology for free, albeit with limited capacity, but also to understand the architecture, at least in theory. Anyway, I digress. With these constraints in mind, let’s dive into how we’ve structured our network and configured our services within these limitations.
In simple terms, a subnet is a range of IP addresses. What determines whether a subnet is public or private depends on the accessibility of its IP addresses. Public subnets have IP ranges that are accessible from the internet, while private subnets have IP ranges that are only accessible from within a specific network.
Normally, we would give servers in a private subnet access to the internet via a NAT Gateway. However, a NAT Gateway incurs costs, so in this case, we’re using a bastion host instead to achieve a similar effect.
After creating our VPC,
we have three EC2 instances: one in one of our public subnets and one in each of our private subnets in the tier. The EC2 instance in our public subnet serves as our Bastion Host.
We ssh into our bastion host through the internet gateway; once there, we can then ssh into EC2App2a, from which we can then ping EC2App2b.
Each subnet has manually configured security groups to allow this to occur.
Takeaways from this Project
Bastion Host
I essentially think of a bastion host as a fortified fortress of your infrastructure. They are heavily fortified, monitored, and secured because they are exposed to potential attacks by being accessible from the public internet. They are equipped with minimal software and services to reduce their attack surface and are regularly updated and patched to protect against vulnerabilities. Access to and from a bastion host is typically controlled through strict authentication, authorization, and auditing measures.
192.168.0.0/20 CIDR Block
This particular CIDR Block, 192.168.0.0/20, provides us with IP ranges from 192.168.0.0 to 192.168.15.255. This range is more than adequate for a medium-sized network, ideally fitting the requirements of this project.
The importance of understanding Ports and the OSI model
For this project to succeed, we need to enable communication for both SSH (Secure Shell) and ICMP (Internet Control Message Protocol). SSH operates on the Transport Layer of the OSI model, so our security groups must allow inbound communication on TCP port 22. This setup facilitates secure communication between devices. On the other hand, ICMP does not operate on a transport layer port like TCP or UDP; it functions at the Network Layer and does not use a port number. Typically, ICMP is used for sending error messages and operational information, which helps in network troubleshooting and management. Unlike typical protocols that use ports, ICMP messages are processed based on their types and codes, which define different operations and functions. In our setup, we configure the security group to allow specific types of ICMP traffic using custom IPv4 settings.
To conclude, I really appreciate starting with the AWS console to become familiar with its environment before deploying services via Infrastructure as Code (IaC). This approach definitely smooths the learning curve. More importantly, I’ve begun to see more connections as I progress further into the Academy. This particular project especially underscored the importance of understanding the fundamentals, such as networking. Stay tuned! This is just a small part of what promises to be an extensive journey into cloud computing.
Happy Learning,
David Reyes Jr
