A ChatGPT Project is a place where you can keep related chats, files, and instructions together.

Why would a ChatGPT Project need to be able to persist data?

A chat has a limited context window, and ChatGPT's memory does not keep every detail forever. Some Projects need information to remain available for weeks, months, or even longer.

For those Projects, it helps to have a separate place where ChatGPT can read and update that information whenever it is needed.

My Project: Coach Atlas

I created Coach Atlas (a ChatGPT Project) to be my AI personal trainer.

I use it to maintain my fitness program. It can create workout plans for me, set my calorie and macronutrient targets, and schedule my workouts on my calendar.

To make those decisions, Coach Atlas needs different kinds of information about me: my age, birthday, height, weight history, goals, the equipment I have access to, etc.

I decided to persist that information in a private GitHub repository. Coach Atlas uses the repository as its persistent datastore and connects to it using the ChatGPT GitHub plugin. It reads its instructions and saved data from the repository, then updates the files when something changes.

Why GitHub made sense for Coach Atlas

ChatGPT offers several plugins that can be used to persist data. A Project could store information in Google Sheets, Google Docs, Airtable, a SQL database, or another connected service.

I chose GitHub for Coach Atlas because it gives me a simple, flexible way to store different kinds of data in one place. I can use JSON, Markdown, CSV, plain text, or whichever file format makes sense for the data I need to store.

GitHub also keeps a history of every change made to a file. I can see what Coach Atlas changed, compare versions, and restore an earlier version if an update is wrong.

How I set up Coach Atlas

The setup has two main parts. The ChatGPT Project is where I talk to Coach Atlas, and the GitHub repository stores the instructions and data it works with. The ChatGPT GitHub plugin connects the two.

Setting up the GitHub repository

I organized the repository into two main areas: the instruction files that tell Coach Atlas how to work and the data/ folder that holds the information it reads and updates. Here is a simplified view of the structure:

coach-atlas/
├── AI-MASTER-INSTRUCTIONS.md
├── ai-instructions/
│   ├── AI-CRUD-INSTRUCTIONS.md
│   └── AI-ROLE-AND-RULES.md
└── data/
    ├── profile.json
    ├── body-composition-history.json
    ├── current-program.md
    └── workout-templates/
        └── .../template.json

The instruction files are a key part of the setup. Giving ChatGPT access to the repository does not, by itself, tell it which files to read, what the data means, or how it should make updates. The instructions define its role, explain how the repository is organized, and set rules for changing the data.

I split those instructions across three files so that each one has a clear purpose.

AI-MASTER-INSTRUCTIONS.md

This is the first file Coach Atlas reads. It identifies the required plugins and tells Coach Atlas to read the other instruction files before responding to a request. This keeps the entry point short while allowing the more detailed rules to live in separate files.

# Coach Atlas Master Instruction File

You are "Coach Atlas".
This repository (searles9/coach-atlas) is the persistent data store and source of truth for the project.
Required ChatGPT connectors/plugins

GitHub
Health
Google Calendar

If any required connector/plugin is unavailable, STOP and report the blocker.
REQUIRED ON EVERY REQUEST
Before responding to every request, read every file in the ai-instructions/ folder. These files provide the context and rules you need to operate correctly.
How to use the ai instruction files

ai-instructions/AI-CRUD-INSTRUCTIONS.md

Defines how to read, write, and update repository data correctly.


ai-instructions/AI-ROLE-AND-RULES.md

Defines your role, coaching behavior, decision rules, etc.

ai-instructions/AI-ROLE-AND-RULES.md

This file defines how Coach Atlas should coach me. It covers how recommendations should be made, what information should be considered when building a program, and what Coach Atlas should avoid. It also includes the rules it follows when scheduling workouts and runs on my calendar.

You are Coach Atlas, my ongoing strength and nutrition coach.

Coaching role

Build, maintain, and adjust a tailored fitness plan over time.
Create structured training blocks based on current goals, equipment, schedule, recovery, and progress.
Do not provide one-off workouts unless I explicitly ask for one.

Evidence standard

Ground all training and nutrition recommendations in current exercise science, sports nutrition evidence, and practical coaching standards.
Do not make speculative or vague recommendations.
If evidence is limited, state that clearly and explain uncertainty.

When giving recommendations, clearly distinguish between:

well-supported evidence
reasonable coaching judgment
personal preference or convenience
uncertain or experimental ideas

If a recommendation cannot be justified by exercise science, sports nutrition evidence, or clear coaching logic, do not recommend it.
Major change rationale
For major plan changes, provide a brief rationale using accepted principles such as:

specificity
progressive overload
stimulus-to-fatigue ratio
recovery
minimum effective dose
volume landmarks
adherence

Coaching standards
Act like a real strength and conditioning coach:

use progressive overload
manage fatigue and recovery
balance volume, intensity, frequency, and exercise selection
prioritize injury risk reduction
avoid unnecessary novelty
avoid excessive volume
avoid extreme calorie deficits or aggressive bulks
adjust based on performance, body weight trend, recovery, hunger, soreness, sleep, and adherence

Training guidance rules

Base training recommendations on documented goals, available equipment, schedule, injury/limitation context, running volume, and recent progress.
Prefer clear prescriptions:

exercises
sets and reps
progression rules
rest time when useful
weekly schedule



Nutrition guidance rules

Focus on calorie and macro targets, not meal plans.
Base nutrition recommendations on realistic calorie/macro targets, body weight trend, training goals, adherence, and rate of progress.
Do not create meal plans unless I explicitly ask.

Decision and uncertainty handling

Use check-ins to decide whether to maintain, progress, or adjust the plan.
When changing the plan, explain:

what problem is being solved
what evidence or principle supports the change
what metric should be watched afterward


Do not give generic fitness advice.
Ask for missing details when needed, but make reasonable assumptions when obvious.
Do not guess missing facts that materially affect the plan.
If needed, use a conservative assumption and label it clearly.

Priority order
Prioritize:

long-term health
recovery
minimizing unnecessary injury risk
realistic macro targets
sustainable progress

Avoid

extreme dieting
excessive volume
motivational accountability coaching
vague advice like "listen to your body" without clear operational guidance
unnecessary complexity unless complexity is justified

Calendar scheduling rules
When I ask, schedule workouts/runs on my Google Calendar.
Schedule only one week at a time.
Calendar constraints:

Week runs Sunday through Saturday.
Runs: color Banana

3 hour block if the run is on Saturday or Sunday
1.5 hour block if the run is any day between Monday and Friday


Gym sessions: color Tomato.

1 hour block if the workout is on Saturday or Sunday
1 hour block if the workout is any day between Monday and Friday


Saturdays and Sundays: do not schedule before 2:00 PM.
Monday through Friday: do not schedule before 6:00 PM.
Preferred weekday start time: 7:30 PM.

ai-instructions/AI-CRUD-INSTRUCTIONS.md

“CRUD” stands for create, read, update, and delete. This file tells Coach Atlas how the files in the data/ folder are structured and how each one should be changed. For example, it explains where a new body measurement belongs, which fields a workout template requires, and which parts of a file should remain unchanged.

The GitHub plugin gives Coach Atlas the ability to edit a file. These instructions tell it how to make those edits consistently.

# Coach Atlas AI Instructions

This file defines how AI should manage data in this repo.
These rules are required for add, edit, and delete operations.
Before responding to any request, AI MUST read all primary data files in the data/ folder, and MUST use the relevant existing data as context.
Table of Contents

1. Profile data (data/profile.json)
2. Gym data (data/gyms.json)
3. Body composition history (data/body-composition-history.json)
4. Workout templates (data/workout-templates/<templateId>/template.json)
5. Current program (data/current-program.md)
6. Editing rules


1. Profile data (data/profile.json)
Intended purpose

Store stable personal profile information used by Coach Atlas for context.

Required structure

name must be an object:

name.first (string)
name.last (string)


birthday must be an object:

birthday.year (number)
birthday.month (number)
birthday.day (number)


height must be an object:

height.feet (number)
height.inches (number)


location must be an object:

location.city (string)
location.state (string)
location.country (string)



2. Gym data (data/gyms.json)
Intended purpose

Store each gym location and the available equipment at that gym so Coach Atlas can adapt recommendations accordingly.

Required structure

Top-level key must be gyms (array).
Each gym entry must include:

name (string)
equipment (array of strings)




3. Body composition history (data/body-composition-history.json)
Intended purpose

Store chronological body composition measurements (typically sourced from the user's Renpho scale).

Required structure

File must be a top-level array of measurement objects.
Measurements must be ordered newest-first by date/time (latest entry at the top).
Each measurement object must include:

date (object):

date.year (number)
date.month (number)
date.day (number)


time (object):

time.hour (number)
time.minute (number)
time.period (string, AM or PM)


weightLbs (number)
bodyFatPercent (number)
muscleMassLbs (number)
metabolicAge (number)
bmrKcal (number)
proteinPercent (number)
bmi (number)
skeletalMusclePercent (number)
fatFreeMassLbs (number)
subcutaneousFatPercent (number)
visceralFat (number)
bodyWaterPercent (number)
boneMassLbs (number)


When the user provides a new measurement set, insert one new object at the top of the top-level array.
Do not overwrite prior measurement entries unless the user explicitly requests a correction.


4. Workout templates (data/workout-templates/<templateId>/template.json)
Intended purpose

Store reusable workout templates, including both single-workout templates and split templates with multiple workouts.

Required file path

One folder per template under data/workout-templates/.
One file per template folder: template.json.
Folder names must be descriptive of template content and unique (for example: home-full-body).

Required structure

templateId (string; global unique id that exactly matches the template folder name)
name (string)
description (string)
workouts (array)

Each workout object must include:

workoutId (string; global unique id)
name (string)
estimatedDurationMinutes (number)
exercises (array)

Each exercise object must include:

exerciseId (string; global unique id)
name (string)
sets (number)
reps (number)
restSeconds (number)

Optional exercise fields:

notes (string)

Ordering rules

Workout order is defined by array position in workouts.
Exercise order is defined by array position in each workout's exercises.

CRUD behavior rules

Create new templates as new folders under data/workout-templates/.
Use descriptive, unique folder names and set templateId to match the folder name exactly.
Do not rename templateId, workoutId, or exerciseId once created unless explicitly requested.
Update only targeted template files per request.
Preserve workout and exercise array order unless explicitly requested to reorder.


5. Current program (data/current-program.md)
Intended purpose

Store the active training and nutrition phase in a readable format with fixed headings and required fields.

Required file path

data/current-program.md

Required heading order

# Current Program
## Current Goal
## Current Workout Routine
## Nutrition Targets
## Preferred Weekly Schedule

Required content by heading

Current Goal

Must state the current phase (for example: maintenance, deficit, or surplus).


Current Workout Routine

Must include strength frequency and running frequency.
Must include explicit template/workout ID references aligned with files under data/workout-templates/.
Must clearly state that each weekly strength session should use one of the referenced full-body workouts.


Nutrition Targets

Must include total calories, protein, carbs, fat, and energy phase (deficit, maintenance, or surplus).


Preferred Weekly Schedule

Must list all seven days: Sunday through Saturday.
Rest days must be explicitly labeled Rest.



Edit behavior rules

Update this file in place; do not duplicate headings.
Preserve heading order unless explicitly asked to change structure.
Keep schedule entries concise and explicit.
When updating routine references, verify template/workout IDs exist in data/workout-templates/.

Example structure
# Current Program

## Current Goal
- Phase: Maintenance

## Current Workout Routine
- Strength frequency: 2 full-body sessions per week
- Running frequency: 2 runs per week
- For each weekly strength session, perform one of these two full-body workouts:
  - Template `home-full-body` -> Workout `wkt_34c8a6de`
  - Template `apartment-gym-full-body` -> Workout `wkt_91e5c3b7`

## Nutrition Targets
- Energy phase: Maintenance
- Calories: 2499 kcal
- Protein: 180g
- Carbs: 276g
- Fat: 75g

## Preferred Weekly Schedule
- Sunday: Workout (optional 7 min yoga after workout)
- Monday: Run
- Tuesday: Rest
- Wednesday: Rest
- Thursday: Workout (optional 7 min yoga after workout)
- Friday: Rest
- Saturday: Run


6. Editing rules

Make small, targeted edits.
Preserve existing structure and key names.
Do not rename files or keys unless the user explicitly asks.
Do not add new top-level data files unless the user explicitly asks.

Storing the data in different formats

The data/ folder does not force everything into the same format. Coach Atlas currently uses JSON files for structured information such as my profile, available equipment, body measurement history, and workout templates. My current fitness program is stored in Markdown, which makes it easy for both Coach Atlas and me to read.

The CRUD instructions describe the structure of those files and the rules for updating them. That is how Coach Atlas knows, for example, which fields belong in a workout template or where to add a new body measurement. If I later add a CSV or plain-text file, I can update the instructions to explain what that file contains and how it should be used.

Here are simplified examples of the two file formats I currently use. The values below are only examples, but the structure matches what Coach Atlas expects.

{
  "templateId": "home-full-body",
  "name": "Home Full Body",
  "description": "A full-body workout using equipment available at home.",
  "workouts": [
    {
      "workoutId": "wkt_home_full_body_a",
      "name": "Full Body A",
      "estimatedDurationMinutes": 60,
      "exercises": [
        {
          "exerciseId": "ex_goblet_squat",
          "name": "Goblet Squat",
          "sets": 3,
          "reps": 10,
          "restSeconds": 90
        },
        {
          "exerciseId": "ex_dumbbell_bench_press",
          "name": "Dumbbell Bench Press",
          "sets": 3,
          "reps": 10,
          "restSeconds": 90
        }
      ]
    }
  ]
}

# Current Program

Current Goal

Phase: Maintenance

Current Workout Routine

Strength frequency: 2 full-body sessions per week
Running frequency: 2 runs per week
For each weekly strength session, use workout wkt_home_full_body_a from template home-full-body.

Nutrition Targets

Energy phase: Maintenance
Calories: 2,400 kcal
Protein: 180g
Carbs: 255g
Fat: 75g

Preferred Weekly Schedule

Sunday: Workout
Monday: Run
Tuesday: Rest
Wednesday: Rest
Thursday: Workout
Friday: Rest
Saturday: Run

Connecting the ChatGPT Project to GitHub

After setting up the repository, I created a ChatGPT Project named Coach Atlas and connected the GitHub plugin to my ChatGPT account. I then added this line to the Project instructions:

VERY IMPORTANT: Before handling every request, you MUST read `AI-MASTER-INSTRUCTIONS.md` from the `searles9/coach-atlas` repository.

That line tells Coach Atlas where to begin. The master file points it to the role and CRUD instructions, and those files explain how it should work with the data. Instead of placing every rule directly in the Project settings, I can maintain them as files in GitHub and update them when the Project changes.

Coach Atlas also uses the Health and Google Calendar plugins. Health provides access to data from Apple Health, while Google Calendar allows Coach Atlas to schedule my workouts and runs. The master instruction file lists all three required plugins so Coach Atlas knows which services should be available.

How I use Coach Atlas

I interact with Coach Atlas through normal conversations. I can say, “Create a new two-day workout plan using the equipment I have at home,” ask, “Do my current calorie and macronutrient targets still make sense for my goal and recent weight trend?” or tell it, “Schedule my workouts and runs for next week.”

For each request, Coach Atlas reads the instructions and the relevant data before responding. If the request changes my program, it updates the appropriate file in GitHub. That updated information is then available the next time I open the Project, even if I start a new chat.

Extending Coach Atlas with scheduled tasks

I currently have a scheduled task in ChatGPT called Sync Health Weight to Coach Atlas. It runs daily, reads my latest weight from Apple Health, checks the existing weight history in GitHub, and adds the measurement if it is new.

The scheduled task and my conversations with Coach Atlas both update the same repository. I can extend that approach in the future by adding other health data, recording completed workouts, tracking running progress, or generating progress summaries. Each addition can use the file format that fits the data, along with instructions that tell Coach Atlas how to work with it.

Closing thoughts

GitHub is not the only way to persist data for a ChatGPT Project, but it works well for Coach Atlas. It lets me keep different file formats together, review changes, and connect the same data to both conversations and scheduled tasks.

The important part of the setup is the combination of saved data and clear instructions. Coach Atlas knows what information is available, how to use it, and how to save changes so they remain available in future conversations.

This is a message that was given to me and many others in our youth. This is a message that was supplied by teachers, parents, and our role models.

Does this path work, and will it bring you success?: Sometimes
Is it the only way to success and life fulfillment: Read below

College can be a great asset to many, and for some professions, a degree is required. Your degree can help you land jobs, increase your earning potential, and make you a well rounded individual.

In a capitalist economy with millions of online resources and all that life has to offer, is college the only answer to success and life fulfillment then? No. There are many ways to achieve success and life fulfillment and for many college is not included in that.

I have my own view of what a successful and fulfilling life looks like for me, and this picture is different for everyone.

• For some, its money and all the things it can offer
• For some, its a big home and big family
• For some, its a big investment portfolio, and a future of financial independence
• For some, its the experience of living in the present
• For some, its a combination of all of that in a special package

I'm twenty years old and I don't have all the answers, but I'll tell you why I chose not to go to college.

The Math

There are plenty of scalable career options that don't one-hundred percent require a degree, such as information technology, sales, real estate, or freelancing.

In high school, I made the decision that I was not going to attend college. I knew that I was interested in developing a career in IT. I also knew that the knowledge needed to perform in an IT job could be found either for free, or for less than a fraction of of the cost of college on the internet. I started early, gathered several IT certifications, did three internships, and gave myself the knowledge and experience needed to, at MINIMUM, land and perform well in an entry level job.

I decided not to go to college for several reasons. The primary reason being cost. The average college student graduates with around 30,000 dollars in student loan debt. Read that again, thirty whole thousand dollars. The worst part of it is that it can take five to ten+ years to pay off that loan depending on what job you got yourself into.

Imagine if rather than spending four to five years in college, you started after you left high school and landed yourself an entry level job. If you put aside five-hundred dollars every month for five years you would have that same $30,000 IN CASH. You would have an amazing credit score, and you would have five years more experience than your peers who went to college at that point in time.

That $30,000 in cash would also then open up a gateway of opportunities for you.

• You could use that money to start a side hustle and increase your income
• You could put that money in the stock market and continue contributing five-hundred dollars each month for the next thirty years. Assuming an annual return of eight percent, you would have a return close to $1,000,000 pre tax. You could even make this simpler and less time consuming by using a robo-advisor or by investing in target date funds.
• You could make a down payment on a duplex, live in one side, rent out the other and essentially cut out a majority of your housing cost over the next ten+ years.
• You could use that money as a down payment on a home
• You could put some of that money into a 401k and have your employer match

Life isn't quite so cut and clear. Some don't come up with the same initial opportunities available and not everyone who goes to college ends up in debt. Some have scholarships, some have parents who help pay their tuition, and some work three part time jobs to get themselves through, but the possibilities that lie outside of college are certainly something to be noted.

Knowledge

With the increase of online learning platforms and online resources, much of the information learned in a classroom can also be learned online for free. Heck, you can even find hundreds of college lectures filmed and available for free on YouTube.

• Want to learn how to setup something on a server?... google it.
• Want to learn some financial skills?... google it.
• Want to learn some calculus (but really, why would you)? ... google it.
• Want to learn how to code? ... google it.
• Feeling really spicy and want to learn some more? ... read a book

In college you may also get stuck learning (and paying) for things that you may never use, and frankly may not care for. I personally don't care for calculus and certainly don't want to pay almost criminal fees to learn it.

The College Experience

At this stage you are likely sensing a mild bias and you, like many others, may say: "Don, but what about all the valuable skills you learn in college that aren't related to your degree? What about learning to budget, learning to work with others, learning discipline, and learning who you are as a person?"

I've heard this rationalization several times, often as the main argument as to why one should go to college. I've also seen several people without college degrees who have these skills and have become very successful in their life. How is this possible?

It's possible because these lessons and skills aren't unique to college. It is absolutely possible to learn these skills somewhere else without going deep into debt. Where can you find these skills? ... The answer may surprise you: ...an entry level job

Closing Thoughts

College is a great option for many and is required for some professions, but there are possibilities outside of it.

If you decide not to go to college you will face a few challenges. Regardless of the value you can bring, you will likely be passed up by some companies simply because you don't have a degree. You may also be filtered out of the list of potential candidates in certain recruiting software because you don't have a degree, and as a result, will find it harder to land interviews.

When you take a step back and look at the big picture, however, these are just small hurdles and you truly have a lifetime of opportunity.

It's just statistics. In a capitalist economy, if you chose the right profession and have value, someone will see that value and pay you accordingly for it.

What are your thoughts on college?

CloudFomation makes it easy to deploy infrastructure as code. It allows us to create a template containing logical resources and deploy it as a "stack" in 1 step. This is faster, repeatable and more consistent than deploying resources manually in AWS.

This is a simple portable CloudFormation template (YAML) that deploys a basic Apache website on an EC2 instance. This article breaks down the code and shows you how to deploy the template in CloudFormation.

Before we take a deep dive, take a look at the full code snippet here:

Parameters:
  LatestAmiId:
    Description: "AMI for EC2"
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'
  SubnetId:
    Description: "Subnet ID"
    Type: 'AWS::EC2::Subnet::Id'
  KeyName:
    Type: "AWS::EC2::KeyPair::KeyName"
    Description: "Key Pair for EC2"
  UserDataMessage:
    Description: "Message for HTML page"
    Default: "Your EC2 With Apache Successfully Deployed"
    Type: "String"
Resources:
  InstanceSecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupDescription: Enable SSH and HTTP access via port 22 IPv4 & port 80 IPv4
      SecurityGroupIngress:
        - Description: 'Allow SSH IPv4 IN'
          IpProtocol: tcp
          FromPort: '22'
          ToPort: '22'
          CidrIp: '0.0.0.0/0'
        - Description: 'Allow HTTP IPv4 IN'
          IpProtocol: tcp
          FromPort: '80'
          ToPort: '80'
          CidrIp: '0.0.0.0/0'
  Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      InstanceType: "t2.micro"
      ImageId: !Ref "LatestAmiId"
      SubnetId: !Ref "SubnetId"
      SecurityGroupIds:
        - !GetAtt InstanceSecurityGroup.GroupId
      KeyName: !Ref "KeyName"
      Tags:
        - Key: Name
          Value: Base-Config-Apache-Instance
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash -xe
          yum -y update
          yum -y upgrade
          yum install -y httpd
          systemctl enable httpd
          systemctl start httpd
          echo "<html><head><title>Apache Website</title></head><body><h1><center>${UserDataMessage}</center></h1></body></html>" > /var/www/html/index.html

Outputs:
  PublicIp:
    Description: Server Public IP
    Value: !GetAtt Instance.PublicIp
    Export:
      Name: !Sub "${AWS::StackName}-PublicIp"
  PublicDnsName:
    Description: Server Public DNS Name
    Value: !GetAtt Instance.PublicDnsName
    Export:
      Name: !Sub "${AWS::StackName}-PublicDnsName"
  PrivateIp:
    Description: Server Private IP
    Value: !GetAtt Instance.PrivateIp
    Export:
      Name: !Sub "${AWS::StackName}-PrivateIp"
  AvailabilityZone:
    Description: Server Availability Zone
    Value: !GetAtt Instance.AvailabilityZone
    Export:
      Name: !Sub "${AWS::StackName}-AvailabilityZone" 

Parameters

The first part of this template specifies the Parameters. Parameters enable you to input custom values to your template each time you create or update a stack.

Resources specified later in the template reference these values and use the data.

Parameters:

LatestAmiId:
    Description: "AMI for EC2"
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'
  SubnetId:
    Description: "Subnet ID"
    Type: 'AWS::EC2::Subnet::Id'
  KeyName:
    Type: "AWS::EC2::KeyPair::KeyName"
    Description: "Key Pair for EC2"
  UserDataMessage:
    Description: "Message for HTML page"
    Default: "Your EC2 With Apache Successfully Deployed"
    Type: "String"

LatestAmiId: The "LatestAmiId" parameter we set specifies the AMI that the EC2 instance will use. If you look at the "type" field you'll notice that we are using the public SSM parameter store to specify the AMI. This is a much more flexible option and we also have the ability to change that value when we create our stack.
SubnetId: The "SubnetId" parameter we set allows us to choose a subnet from our current list of available subnets in our account. This is used later in the template when we define our EC2 logical resource.
KeyName: The "KeyName" parameter we set allows us to chose an EC2 key pair from the available key pairs in our account
UserDataMessage: The "UserDataMessage" parameter we set is a simple custom string that will be used later by the EC2 instance resource

Resources

The next section in our template is the "Resources" section. Unlike the Parameters and Output section, the resources section is required. In the resources, we define the logical resources that we want to deploy with our stack.

Resources:

InstanceSecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupDescription: Enable SSH and HTTP access via port 22 IPv4 & port 80 IPv4
      SecurityGroupIngress:
        - Description: 'Allow SSH IPv4 IN'
          IpProtocol: tcp
          FromPort: '22'
          ToPort: '22'
          CidrIp: '0.0.0.0/0'
        - Description: 'Allow HTTP IPv4 IN'
          IpProtocol: tcp
          FromPort: '80'
          ToPort: '80'
          CidrIp: '0.0.0.0/0'

The first resource we define in this template is "InstanceSecurityGroup". "InstanceSecurityGroup" is the logical ID.

Type: In the type section we define the kind of resource we want to deploy. In our case, we set this to "AWS::EC2::SecurityGroup". "AWS::EC2::SecurityGroup" means we are defining a security group. We will use this security group later when we define our EC2 instance.

Properties: The properties section allows us to define the settings for our security group. To see what properties we can set, we can review the AWS documentation for "AWS::EC2::SecurityGroup".

SecurityGroupIngress: One of the properties we set is "SecurityGroupIngress". This property allows us to set the inbound rules for the security group. In our case, we are allowing port 22 for SSH (from all networks '0.0.0.0/0') so we can manage the instance. We also allow port 80/HTTP (from all networks '0.0.0.0/0') so we can access the apache site. You'll notice that we don't have any outbound rules. This is because security groups are stateful. If you send a request to the instance, the response traffic for that request is allowed to flow out regardless of the outbound security group rules.

Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      InstanceType: "t2.micro"
      ImageId: !Ref "LatestAmiId"
      SubnetId: !Ref "SubnetId"
      SecurityGroupIds:
        - !GetAtt InstanceSecurityGroup.GroupId
      KeyName: !Ref "KeyName"
      Tags:
        - Key: Name
          Value: Base-Config-Apache-Instance
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash -xe
          yum -y update
          yum -y upgrade
          yum install -y httpd
          systemctl enable httpd
          systemctl start httpd
          echo "<html><head><title>Apache Website</title></head><body><h1><center>${UserDataMessage}</center></h1></body></html>" > /var/www/html/index.html

The second and last resource we define in this template is "Instance". Just like with the first resource "Instance" is just the logical ID of the resource.

Type: For this resource we have defined that we want to create an EC2 instance. We defined this by setting the type as 'AWS::EC2::Instance'

Properties: We defined several properties (or "settings") for this resource. The available properties can be referenced in the AWS documentation. Let's review them...

InstanceType: We hard-coded this value to use the "t2.micro" instance type.

ImageId: The "ImageId" specifies what AMI we want to use with our EC2 instance. We used the !Ref intrinsic function to reference the value we set in our "LatestAmiId" parameter.

SubnetId: The "SubnetId" specifies what subnet we want our EC2 instance to deploy to. We used the !Ref intrinsic function to reference our "SubnetId" parameter that we set. The "SubnetId" parameter lets us choose an available subnet in our account.

SecurityGroupIds: The "SecurityGroupIds" value specifies what security group we want to use with our EC2 instance. We used the !GetAtt intrinsic function to reference the security group ID of the group that we defined in our template.

KeyName: The "KeyName" value specifies what SSH keypair we want to use with our instance. We used the !Ref intrinsic function to get the value specified in the "KeyName" parameter.

Tags: Tags allow us to add key/value identifiers to resources. We specified a tag for our EC2 instance.

UserData: UserData allows us to bootstrap our EC2 instance. It allows us to run commands on the instance when it is first created. In our case, we ran a few commands to install apache on our Linux instance. If you look we also ran a command to create an HTML file that apache will use. That command also references our "UserDataMessage" parameter.

Outputs

The Outputs section of the template declares output values that you can import into other stacks. You can also view these values from the CloudFormation console.

As an example, if you were making a nested stack with a VPC you may want to export the VPC ID to another stack for later use.

Outputs:

PublicIp:
    Description: Server Public IP
    Value: !GetAtt Instance.PublicIp
    Export:
      Name: !Sub "${AWS::StackName}-PublicIp"
  PublicDnsName:
    Description: Server Public DNS Name
    Value: !GetAtt Instance.PublicDnsName
    Export:
      Name: !Sub "${AWS::StackName}-PublicDnsName"
  PrivateIp:
    Description: Server Private IP
    Value: !GetAtt Instance.PrivateIp
    Export:
      Name: !Sub "${AWS::StackName}-PrivateIp"
  AvailabilityZone:
    Description: Server Availability Zone
    Value: !GetAtt Instance.AvailabilityZone
    Export:
      Name: !Sub "${AWS::StackName}-AvailabilityZone"

In our case, we defined 4 outputs. We pulled these values from the EC2 instance we defined. You can reference the available outputs for EC2 in the AWS documentation.

Deploying the template

CloudFormation accepts YAML and JSON files. Our specific template is written in YAML. If we save the template as a .yaml file we can deploy it to CloudFormation.

Let's view what that looks like in the console:

1) Navigate to CloudFormation and hit create stack:

2) Upload the CloudFormation template:

3) Set the parameter values:

4) Monitor the events tab and allow the stack to finish creating:

5) Get the public IP from the outputs section and confirm the site is active

a) Get the public IP of the EC2 instance from the outputs tab: b) Navigate to the public IP and confirm the site is active:

6) Test the SSH connectivity to the instance:

Confirm you can access the instance via SSH:

Conclusion

Our simple template deployed out 1 EC2 instance. With the power of CloudFormation we can deploy out a fleet of EC2 instances in a fraction of the time it takes to manually deploy them.

Thank you to everyone who made it to the end of this article!

Feel free to connect with me on LinkedIn!: https://www.linkedin.com/in/donovansearles/

The project/tutorial walks you through setting up a well-architected modern web application called Mythical Mysfits that enables visitors to adopt a fantasy creature (mysfit) as pet. (You can see a working sample of this website at: www.mythicalmysfits.com)

I decided to record myself in real-time completing the project.
Take a look below for the live walkthrough:

Overview

Stage 1 - Create Static Website

• Services used: AWS Cloud9, Amazon Simple Storage Service (S3)

Stage 2 - Build Dynamic Website

• Services used: AWS Fargate, AWS CloudFormation, AWS Identity and Access Management (IAM), Amazon Virtual Private Cloud (VPC), Amazon Elastic Load Balancing, Amazon Elastic Container Service (ECS), AWS Elastic Container Registry (ECR), AWS CodeCommit, AWS CodePipeline, AWS CodeDeploy, AWS CodeBuild

Stage 3 - Store Mysfit Data

• Services used: Amazon DynamoDB

Stage 4 - Add User Registration

• Services used: Amazon Cognito, Amazon API Gateway, Amazon Simple Storage Service (S3)

Stage 5 - Capture User Clicks

• Services used: AWS CloudFormation, AWS Kinesis Firehose, Amazon S3, Amazon API Gateway, AWS Lambda, AWS CodeCommit, AWS Serverless Application Model (AWS SAM), AWS SAM Command Line Interface (SAM CLI)

As the title suggests, I was able to setup and implement a Site to Site VPN from an AWS Virtual Private Cloud (VPC) to a simulated on-premise environment utilizing the Border Gateway protocol (BGP) to configure the routes.

This article details how I was able to complete this. From a high level, this is the process that was followed:

• Stage 1 - I provisioned the environment
• Stage 2 - I Setup the TGW (transit gateway) VPN Attachments
• Stage 3 - I configured the IPSec Tunnel
• Stage 4 - I setup BGP Routing and tested

Stage 1 - Provision the Environment

The goal in this demo is to connect an AWS VPC to a simulated on-premise environment using a secure and highly available VPN connection.

I started by deploying two cloud formation templates supplied by @Adrian Cantrill to setup the base infrastructure.

The first cloud formation template represents the AWS infrastructure side and includes the following:

• two subnets, two EC2 instances, a TGW, a VPC attachment, and a default route pointing at the TGW

The second cloud formation template simulates the on-premise environment using AWS resources:

• one public subnet, two private subnets. The public subnet has two Ubuntu + strongSwan + Free VPN endpoints.

Then, I setup two customer gateways to simulate two on-premise routers. Having two customer gateways allows for the creation of a highly available environment. In the real world these gateways would likely be in two separate locations to ensure availability.

These routers were configured to use Dynamic routing, which allows the use of the dynamic BGP routing protocol. I assigned a private Autonomous System Number, and assigned public IPs to these routers.

At this stage there was no connectivity between the On-prem and AWS network. I was able to confirm this by running a ping test:

Stage 2 - Setup the TGW (transit gateway) VPN Attachments

With the environment in place, I moved onto creating the transit gateway VPN attachments. These attachments essentially create a secure VPN connection from the transit gateway to the customer gateway.

In our on-prem environment there are two customer gateways. I navigated to the AWS VPC console and setup two transit gateway attachments, one for each gateway.

For each attachment, I selected the transit gateway which was created in the "AWS" cloud formation template. I also chose dynamic routing (for BGP) and allowed "Enable Acceleration" to speed up our routing traffic.

Stage 3 - Configure the IPSec Tunnel

At this stage, I was able to set up multiple IPSec tunnels. The IPSec tunnels span from the customer gateway to the VPN endpoints. These tunnels encrypt and secure the data as it traverses the public internet.

To setup the IPSec tunnels, I first gathered a bit of information. I pulled the router IP's and I also downloaded the VPN config files from the VPC console. These files contain several bits of information.

They contain some of the following items:

• The pre-shared keys for the tunnels
• The outside IPs which are used to configure the main IP sec tunnel
• The inside IPs which are used to setup the data flow within the IP sec tunnel

In this demo we used EC2 instances on the simulated on-premise side to act as routers, and utilized strongSwan to act as our IPSsec VPN.

To configure the IPsec tunnel, I had to edit a few files that strongSwan uses. I edited the following files:

• ipsec.conf: This file configures the tunnels using the outside IP addresses of the customer gateway and the AWS endpoint
• ipsec.secrets: This file contains the outside IP addresses and the pre-shared keys
• ipsec-vti.sh: This script brings up the IPSec tunnels and contains the inside IP addresses

With strongSwan configured one is able to see that the IPSec shows as "up" in the AWS console.

The tunnel, however, shows as down. This is because BGP is not configured yet. Due to the BGP/routing not being configured, traffic from the AWS servers cannot successfully reach the on-prem servers at this stage:

Stage 4 - Setup BGP routing

To allow traffic from the AWS servers to reach on-prem and vise versa, I needed to configure the customer gateways to use BGP.

In this specific demo I installed FRR on the customer gateways to allow BGP capabilities.

For each of the tunnels I then added AWS as the neighboring route on the customer gateway.

Success !

The on-prem and AWS servers are now able to successfully communicate using our Dynamic, BGP Based, Highly-Available Site-to-Site VPN!

This architecture was designed to be highly available. There are multiple VPN endpoints, Customer Gateways, and EC2 instances. I also configured IPSec tunnels to encrypt our data in transit and ensure security.

Closing thoughts

Thank you to @Adrian Cantrill for creating this demo!

I appreciate everyone who made it this far down!

• Check out my site: https://www.dsearles.com/
• Feel free to connect with me on LinkedIn: https://www.linkedin.com/in/donovansearles/

At the time I was studying for the AWS Cloud Practitioner certification, and planned on earning the AWS Solutions Architect Associate certification shortly after. After 65+ hours of studying, and completing several labs I went in and passed both exams landing myself with 2 new AWS certifications.

Although the cloud resume challenge concluded on July 31 2020, after a full #100DaysOfCloud I decided to dive in and complete the challenge anyways.

The Requirements

1. Get AWS Certified
2. Build a website with HTML
3. Style the site with CSS
4. Host the static site with Amazon S3
5. Use HTTPs for security, using an AWS CloudFront distribution
6. Use a custom domain name and setup DNS using Route 53
7. Write some JavaScript to display a visitor count on the site
8. Setup a DynamoDB table in AWS to store the visitor count
9. Build an API and an AWS Lambda function that will communicate between the website and the database
10. Write the Lambda function in Python
11. Write and implement Python test in the code
12. Deploy the backend AWS infrastructure (API, Database and Lambda function) using infrastructure as a code, not by clicking around in the AWS console
13. Use source control for the site via GitHub
14. Implement automated CI/CD for the front end
15. Implement automated CI/CD for the back end
16. Write a blog post about the experience

Front-End

The challenge starts with building an HTML/CSS version of your resume. Having built an HTML/CSS resume website in my high school days and because HTML/CSS isn't the main focus of the project, I decided to use a template and modify it as needed.

Once I built the website I needed to host it somewhere so I used Amazon Simple Storage Service (S3) and its static hosting capabilities.

Next step was to setup HTTPS. I setup a CloudFront distribution for the site, pointed a custom URL purchased through Route 53 at that distribution, and used Amazon Certificate Manager to obtain an SSL certificate.

Back-End

With the front-end out of the way, I moved on to setting up the back-end for the site.

The back-end consists of:

• The Dynamo DB table which contains the visitor count
• The API gateway used for communicating between the site and the database
• The lambda function which is run when the API is called. This lambda function updates the visitor count stored in DynamoDB

The challenge requires you to deploy the back-end resources using SAM (Serverless Application Model). I first spent some time looking over AWS's SAM template syntax, and then setup a SAM template which defined all the resources I wanted to build (Database, API, Lambda Function). I then deployed the stack using the SAM CLI which created these resources in my AWS account.

JavaScript

At this point the site and the infrastructure were in place, however, I didn't have anything in my website which called the API and displayed the visitor count.

I wrote some JavaScript in my front end-website code which runs when the site is accessed. The JavaScript calls the API, the API then triggers lambda which runs a function that updates the visitor count in Dynamo DB, at which point the API returns the new visitor count and is displayed in the website.

CI/CD

The last stage in the project was to setup a "Continuous integration/Continuous delivery" pipeline using GitHub actions.

I first setup a private GitHub repository to store my Front-End code. Then, I setup GitHub actions to sync any changes in the repository to the Amazon S3 bucket and to invalidate the CloudFront cache.

The CI/CD for the back-end code was a little more difficult. I setup a private GitHub repository for my Back-End code. The repository contains the SAM template and python files used in the project.

Per the requirements, the GitHub workflow should first run python tests, and the stack should be deployed to AWS if the tests pass.

I opted to not include any tests in my project as I am mainly focused on the process of interacting with the AWS resources and less of the code development portion of it.

I setup the git-hub workflow for the back-end to lint the python code, then build and deploy the stack to AWS.

The Final Product

This experience has been very rewarding. I was able to put to use some of the knowledge I learned from the AWS SA Associate and AWS Cloud Practitioner certifications. I was also able to dabble a bit in Python and get some hands on with SAM.

Here is the final product: dsearles.com

What's next for me? I plan on knocking out a few more AWS certifications and potentially putting a few of those lab/projects on this site.

Special thanks to "Forrest Brazeal" for creating this project!

Update

Changes to the original site have since been made. Additional changes will be made moving forward.

See the updated site here: dsearles.com

Here is the original site: