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:
- Initiating: Identifying the need to reduce complexity and costs
- Planning: Documenting current infrastructure and designing consolidation strategy
- Executing: Implementing service migrations in phases
- Monitoring: Tracking progress and performance
- Closing: Validating successful migration and documenting lessons learned
This structured approach ensures:
- Lower costs in AWS through optimized architecture
- Reduced migration complexity through service consolidation
- Minimized risk through phased implementation
- Clear resource requirements based on simplified infrastructure
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.