Project 001: Building NatalieFosterJohnson.com on AWS - Part #2 — Before I Build, I Need an Architecture

Well, I did it.

Project 001 officially has a home.

I created the GitHub repository for NatalieFosterJohnson.com .

And because apparently I like making things interesting, I did it entirely from my phone. 😁💜🖤

There is no website yet.

There is no beautiful homepage.

Right now, I basically have an empty box with a label on it:

And that’s exactly where I wanted to start.

Because before I start clicking around AWS, deploying services, or adding technology simply because it’s available, I need to answer a much more important question:

Before this project, I understood what GitHub was conceptually. But The Resilient Builder isn’t about stopping at conceptual knowledge. I want to understand where these tools actually fit into something I’m building.

At a basic level, GitHub is an online platform where developers store, organize, and track code.

Think of it as a protected drive combined with version history, but for code.

For Project 001, GitHub will hold the code that eventually becomes NatalieFosterJohnson.com .

That distinction was important for me.

It’s where I’m keeping the building plans. Eventually, AWS will use those plans to build and deploy the website people actually visit.

So my simple mental model became:

GitHub = the building plans
AWS = the infrastructure
NatalieFosterJohnson.com  = the address

Suddenly, this started making a lot more sense.

My cybersecurity and governance brain kicked in here. It would be very easy to open the AWS console and start asking:

But that’s actually the wrong question. The better questions are:

And only after answering those questions should I start deciding which technology belongs in the architecture. That’s probably one of the biggest lessons I’ve already taken from this project:

So I started with the people.

Who Is Coming to NatalieFosterJohnson.com ?

I identified four primary journeys.

Someone may visit because they’re considering hiring me for cybersecurity advisory or consulting work. Someone else may have heard me speak and wants to learn more or invite me to an event.

Another person may be looking for my book, Pretty Secure, my writing, or other content.

And increasingly, someone may arrive because they’re following this AWS journey and want to see what I’m building and learning.

That gave the website four very simple jobs:

That’s much clearer than saying:

When people hear architecture in technology, it can sound much more intimidating than it needs to.

I think of it like building a house.

Before a contractor installs doors, wires lights, or puts up walls, someone creates a blueprint.

The blueprint answers questions like:

Where does everything go?

How does it connect?

What supports what?

What happens when someone enters the house?

Technology architecture does something similar.

For Project 001, my architecture needs to answer:

How does NatalieFosterJohnson.com  get visitors there?

Now we’re getting somewhere. 😁

After working through those questions, I created the first architecture for NatalieFosterJohnson.com .

And I’m intentionally keeping it simple.

The current plan is:

Visitor → NatalieFosterJohnson.com  → AWS Amplify → Next.js website

Behind that is another important flow:

NatalieFosterJohnson.com  ↔ Substack

Each piece has a job.

My domain is currently managed through Squarespace. I don’t need to move the registration simply because I’m building the website on AWS.

GitHub will store and track my website code.

Next.js will be used to build the website itself.

AWS Amplify will eventually connect to the GitHub repository, build the application, and deploy it.

Substack remains my publishing and newsletter platform while NatalieFosterJohnson.com  becomes my permanent professional home.

That’s Version 1.

No database. No EC2 instance. No collection of AWS services just so I can say I used them. If the project eventually creates a legitimate reason for another service, I’ll learn it and add it then.

AWS Amplify was one of the services I needed to understand before deciding whether it belonged in the architecture.

In very simple terms:

There’s obviously much more to learn about Amplify, and that’s part of the point of this project.

But right now, I can explain why it’s in my architecture.

Of course, I can’t look at an architecture diagram without immediately seeing security questions. 😂

Who has access to the AWS account?

What permissions do they have?

How is the GitHub repository protected?

Will all website traffic use HTTPS?

What gets logged?

How will I know if something stops working?

What happens when I eventually add a contact form? And because this is AWS:

What am I paying for? 😁

I’m not going to answer every one of those questions today. But I want them documented now.

I’m deliberately starting with a simple architecture:

My goal is to understand why each service exists, what problem it solves, how it connects to everything else, and what responsibility comes with using it.

This part of the project didn’t involve deploying anything. And that’s actually the lesson.

I created a GitHub repository.

I defined the purpose of the website.

I identified the people who will use it.

I decided what belongs in Version 1.

I created my first architecture.

And I started asking security questions before there was anything to secure.

For someone who is deliberately trying to become more hands-on with AWS, it might feel like I haven’t done much yet. But I’m starting to see it differently.

Good building starts with understanding what you’re trying to accomplish.

Now I have a blueprint.

Next, I need to understand the individual pieces well enough to start turning that blueprint into something real.

And then we can finally start touching AWS. 😁

In Part 3, I’m going deeper into the architecture itself. I’ll break down the services in my Version 1 design, explain what each one does, show how they connect, and decide what I need to configure first. Then we’ll start building.

Slowly.

Intentionally.

And with screenshots, mistakes, questions, and probably a few “what in the world does this setting mean?” moments along the way. 😂

That’s the whole point.

Stay resilient. 💜🖤