I’m currently working through CCNA Course 3 (ENSA), and a lot of it - subnetting, default routes, NAT - reads fine on paper but doesn’t fully click until you’ve watched it actually move traffic. With $100 in AWS credits sitting unused, I decided to rebuild the classic “public subnet / private subnet” enterprise pattern from scratch in the AWS Console, rather than using a one-click VPC wizard, specifically so I’d have to reason through every routing decision myself.
The result: a small, fully functional two-tier network that mirrors what you’d find behind most production web applications - a public-facing server, a private backend server with zero direct internet exposure, and a bastion-host pattern for reaching it.
Internet
|
[Internet Gateway]
|
┌───────────┴───────────┐
│ lab-vpc (10.0.0.0/16)
│
│ public-subnet (10.0.1.0/24)
│ ├── public-server (EC2, public IP)
│ └── NAT Gateway (Elastic IP)
│
│ private-subnet (10.0.2.0/24)
│ └── private-server (EC2, no public IP)
│
└───────────────────────┘
0.0.0.0/0 → Internet Gateway0.0.0.0/0 → NAT Gateway (which itself lives in the public subnet)That distinction - NAT Gateway physically sitting in the public subnet while serving the private one - was the first thing that didn’t fully make sense until I’d actually wired it up.
1. VPC and subnetting
Created a /16 VPC and carved out two /24 subnets in the same AZ - one public, one private. Straightforward CIDR math, but a useful reminder that “public” and “private” in AWS aren’t inherent properties of a subnet - they’re just a consequence of which route table gets attached to them.
2. Internet Gateway + route table
Attached an IGW to the VPC, then created a route table with a default route (0.0.0.0/0 → IGW) and associated it with the public subnet only. This is the AWS equivalent of a default route pointing at your ISP’s next hop - the private subnet, using a different route table with no such route, is effectively unreachable from and to the internet by default.
3. Public EC2 instance
Launched an Amazon Linux instance into the public subnet. The security group here is doing the actual firewall work: it allows inbound SSH (port 22) with the source locked to my own IP address rather than 0.0.0.0/0 - no reason to expose SSH to the entire internet for a lab box, and connected via PuTTY.
4. NAT Gateway + private route table
This is the core of the lab. Created a NAT Gateway (with its own Elastic IP) inside the public subnet, then built a second route table for the private subnet pointing 0.0.0.0/0 at the NAT Gateway instead of the IGW.
5. Private EC2 instance + bastion access
Launched a second instance into the private subnet with no public IP assigned at all. Its security group only allows inbound SSH from the public subnet’s CIDR range (10.0.1.0/24) - not from my laptop’s IP, and not from the internet at large. That single rule is what actually enforces the “unreachable except through the bastion” behavior; without it, having no public IP alone wouldn’t be enough of a guarantee inside a more complex network.
Since there’s no public IP, PuTTY on my laptop can’t reach it directly - I had to hop through the public server first, the classic bastion/jump-host pattern:
lab-key.ppk into Pageant (PuTTY’s SSH agent) on my laptopssh ec2-user@<10.0.2.1> - and because Pageant was forwarding my key through the connection, it authenticated without the private key ever having to exist as a file on the public serverThat last point matters: the private key never touches the bastion’s disk. If the public server were ever compromised, there’s no key sitting on it for an attacker to steal and reuse.
Running curl ifconfig.me from each box told the whole story:
The private instance has full outbound internet access - it could update packages, hit an external API, whatever - but nothing on the internet could have opened a connection to it. That’s the exact pattern behind why databases and internal services sit in private subnets in real deployments: outbound access without inbound exposure.
NAT Gateway is the one resource in this build that actually costs money - roughly $0.045/hour plus data processing, whether or not traffic is flowing - so I tore it down and released its Elastic IP immediately after testing, keeping the whole exercise under $1.
Subnetting and default routing are core CCNA Course material - just expressed here in AWS instead of Packet Tracer. NAT itself is actually Course 3 (ENSA) territory, so this lab ended up previewing a concept slightly ahead of where my coursework currently sits, which was a useful head start. It’s also a reminder that the instincts you build doing audit and controls work - tracing exactly what can access what, and why - mapped directly onto network security design. A security group is, in the end, just an access control matrix.
Next step: automating this build with the AWS CLI or Terraform, so the same topology can be spun up and torn down in seconds instead of clicking through the console.
]]>Hello! If you’ve been following my journey, you know I’m transitioning from a background in economics and finance into the world of software development. To bridge these two worlds, I decided to build something that speaks to both: a Depreciation Calculator. This project wasn’t just about writing code; it was about making the accounting concepts I’m studying for my CPA exam tangible and interactive.
As a CPA candidate, depreciation methods (Straight-Line, Declining Balance, etc.) are fundamental. As an aspiring developer, I wanted to build a clean, useful web app. This calculator was the perfect fusion as it reinforced my finance knowledge while forcing me to apply new HTML, CSS, and JavaScript skills to solve a real problem.
I didn’t build this alone. As a novice, I collaborated extensively with AI assistants, Claude and DeepSeek, to guide the process. They acted as my technical mentors, helping me:
Structure the project from scratch.
Debug JavaScript logic for accurate financial formulas.
Understand Git and GitHub, which was a major initial hurdle.
Speaking of hurdles, my biggest challenge wasn’t the code—it was version control. As a GitHub novice, I found the process of commits, pushes, and branches confusing. At one point, I even encountered a cryptic error about “Git LFS” that stopped me in my tracks! With patient guidance, I learned to navigate these waters. Figuring out how to successfully deploy the project to GitHub Pages and see it live on the web for the first time was an incredibly satisfying “aha!” moment. It transformed the project from files on my computer into a real, shareable application.
The calculator allows you to input an asset’s cost, salvage value, and useful life. With a click, it generates a year-by-year depreciation schedule using the Straight-Line method (with more methods coming soon!). It presents the data in a clear table and will soon feature charts for visualization. It’s clean, responsive, and, most importantly, accurate to accounting standards.
This is just Phase 1. I’m currently working on Phase 2, which will add the Declining Balance and Sum-of-the-Years-Digits methods. Future plans include interactive charts and export functionality.
This project taught me that the best way to learn is to build. It connected abstract coding syntax to a concrete outcome I care about. It also showed me the value of asking for help, whether from AI or the broader developer community. Try the calculator for yourself and see the code: Live Depreciation Calculator View the Code on GitHub — I’d love to hear your thoughts or feedback. What concepts from your field would you like to see turned into an app?
]]>I graduated from the Technical University of Kenya with a degree in Economics. On paper, I was headed for a career in finance - and for a while, that’s exactly where I went. I worked on internal audits at the Kenya Revenue Authority, dove into CPA certifications, and even spent time in sales at JTL KE.
But there was always something else pulling at me: technology.
My path hasn’t been a linear switch from one field to another. Instead, it’s been a parallel build: deepening my expertise in accounting and financial systems through my CPA studies, while simultaneously expanding my technical toolkit with certifications in AWS Cloud, CCNA networking, and Ethical Hacking. This blog is where these tracks converge. It’s a space for exploring how core principles from one discipline can inform and elevate practical builds in the other.
You can expect content focused on applied knowledge—turning theory into tools. This means translating financial concepts into clean, functional software, breaking down the architecture of fintech solutions, and sharing the hands-on journey of building with purpose.
A perfect example of this intersection in action is a project I’ve just deployed: a professional Depreciation Calculator.
The future of finance is unequivocally tech-enabled. Whether in fintech, automated accounting, or advanced data analysis, the professionals who will lead are those fluent in both the language of business logic and the language of technical implementation. I’m committed to building projects that bridge this gap—creating tools that solve real financial and operational challenges with modern, accessible technology.
My plan is simple: build things, break things, learn from both. I’m documenting my journey here - the wins, the struggles, the “why won’t this code work” moments at 2 AM. I’m particularly interested in exploring:
This blog will document that journey—the process, the hurdles, and the insights.
If you’re a finance professional curious about technology, a developer interested in the “why” behind fintech, or on a similar path of synthesis, I invite you to follow along. Let’s connect and build something insightful.
- Alex