AWS Migration: Chapter 1 – Project Planning

As a long-time homelab enthusiast who recently joined AWS, I'm about to embark on an interesting journey – becoming a customer of the company I now work for. While I should mention I'm an AWS employee, these are my personal experiences and thoughts.

My Current Setup: The Beast

Picture this: In the corner of my tiny apartment sits a server that could probably launch a small space program. It's powered by a Ryzen 3950x3D with a whopping 196GB of RAM. It's been my faithful companion in running everything from Mastodon to GitLab, never once complaining about resources. It's also been faithfully contributing to my power bill and doing its best impression of a space heater during summer.

If it ain't broke, why are we fixing it?

Well, besides the obvious power bill and heat issues, having just joined AWS, I've been immersing myself in Amazon's Leadership Principles.

“Customer Obsession” particularly caught my attention – what better way to understand our customers than to become one myself? Sure, I know the technical side of servers, but understanding the cost model from a customer's perspective? That's different territory.

Frugality

Looking at my homelab through the lens of Amazon's “Frugality” principle, I really had to take a moment of introspection. I'm currently running:

Service Database Cache Additional Services Web Server
Mastodon PostgreSQL Redis Elasticsearch, Sidekiq, Streaming Service nginx
WriteFreely SQLite - - Built-in
GitLab PostgreSQL Redis Multiple Sidekiq workers, CI/CD runners nginx
Bookstacks MySQL - PHP-FPM nginx
Pixelfed PostgreSQL Redis FFmpeg, Image Processing Libraries nginx
WordPress MySQL Redis PHP-FPM nginx

So we have: – 3 different database engines – 4 Redis instances – Multiple web servers – Various specialized services

It's like bringing a cruise ship to a kayaking trip.

Planned Consolidation

Before I joined AWS, I would've called this the KISS principle. Now I'm learning to speak Amazon (Invent and Simplify), but the concept remains the same We have too much overlap and this setup is way too complicated. Here's my battle plan:

Current Service Migration Strategy Key Changes
WriteFreely Convert to GitLab Pages Static site generation from existing content
Bookstacks Convert to GitLab Pages Export documentation to markdown
WordPress Convert to GitLab Pages Use Simply Static plugin for content export
Pixelfed Option 1: Merge to Mastodon Consolidate with existing social presence
Option 2: Static photoblog Convert to lightweight photo gallery
Mastodon Optimise existing setup – Implement aggressive media caching
– Configure S3 lifecycle rules
– Set media preview limits
GitLab Maintain as core service No changes required

Why All This Prep Work?

Preparation is fundamental to project success. Following the Project Management Institute's framework, this migration represents a clear project lifecycle:

This structured approach ensures:

This isn't just about moving to the cloud – it's about moving smarter. Stay tuned for the next chapter in this journey, where I'll share the execution phase and lessons learned.

This post contributes to Professional Development Units (PDUs) under the Project Management Institute's Technical Project Management category.

The author was employed at Amazon Web Services at the time of writing. The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy or position of Amazon Web Services.

#pmp #aws #homelab