For TEB3033 (Distributed and Parallel Computing), my group of four got a classic brief. One company, two departments with opposite needs: HR wants a portal anyone on the internet can open, while Engineering wants a development server nobody outside can reach. And neither department's admins should be able to touch the other's setup. The budget was the $100 credit in an AWS Academy Learner Lab.
It's simple stuff, but it's the kind of simple that's easy to get subtly wrong, so here's how we approached it.
The whole design in one picture
Three locks, not one
Engineering's isolation doesn't rely on any single setting. Each layer would hold even if another one were misconfigured:
- The route table. The private subnet simply has no route to the internet gateway. Traffic from the internet isn't blocked so much as it has no road to travel on.
- The security group. Engineering only accepts connections from one address: the HR server's private IP. HR itself only opens port 80 to the world, and SSH only to the admin's IP.
- IAM. Every resource is tagged
Department: HRorDepartment: Engineeringwhen it's created, and each admin group can only manage resources carrying its own tag.
One rule per department
The IAM side is one small policy per group. VPC networking actions share the ec2: namespace, so a single statement covers servers, subnets, route tables and gateways. The Engineering policy is the same with a different tag value.
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": { "StringEquals": {
"aws:ResourceTag/Department": "HR" } }
}To prove the boundary, the plan creates a test user for each group, signs in as the HR admin, and tries to change Engineering's network. The expected answer is "Access Denied", while the same admin keeps full control of anything tagged HR.
Three journeys
| Who | What happens | Result |
|---|---|---|
| A visitor opens the HR portal | Through the gateway, past HR-SG on port 80, to Apache | Page loads ✓ |
| Someone aims at Engineering from outside | No public IP to find, and no route in even if they had one | Dead end ✗ |
| The HR server calls Engineering | 10.0.1.10 to 10.0.2.10 inside the VPC, allowed by Eng-SG | Works ✓ |
Half the budget
The network itself costs nothing: the VPC, subnets, route tables, security groups and IAM are all free. Only the two servers are billed, so each one gets the pricing that matches how it's used. HR runs around the clock, so it's on a one-year Partial Upfront plan; Engineering only works office hours, so it's On-Demand for about 8 hours a day.
| Item | Cost |
|---|---|
| Network, security groups, IAM | $0.00 |
| HR server (1-year Partial Upfront, always on) | $27 upfront + $4.93/month |
| Engineering server (On-Demand, 8 hours a day) | $3.32/month |
| Semester, about 3.5 months | ≈ $55.88, 56% of the $100 credit |
What we'd change for real
- One server per tier is a single point of failure. A load balancer and auto scaling would let a second HR server take over.
- The portal is plain HTTP. An ACM certificate on the load balancer would add HTTPS for free.
- Tagging depends on people remembering. AWS Config rules could flag anything created without a Department tag.
- Nobody's watching. CloudTrail and VPC Flow Logs would record every admin action and network connection.
Where my AWS started
This subject is where I earned my AWS Academy Graduate – Cloud Foundations badge, and where I first worked hands-on with AWS: VPCs and subnets, EC2, security groups, IAM policies and the Pricing Calculator. Small as this design is, the lesson stuck with me: put the rules in the structure, so the safe thing is the only thing that can happen.