Repair AWS Network with CloudFormation

Deploy, diagnose, and repair an AWS web network with CloudFormation.

Introduction

30 Second Summary

A project can look finished on paper while the page people need still refuses to load. A strong portfolio story proves your ability to trace that gap through to a working fix.

In this project, you will deploy a deliberately broken web stack with AWS CloudFormation. Your final public GitHub repository will prove the repair by tracing the blocked HTTP path with Amazon VPC Reachability Analyzer back to the CloudFormation template.

What You'll Build

You will demonstrate a restored AWS web page from a public repository that traces its failure to a missing network rule.

By the end of this project, you'll have:

  • A reproducible browser-accessible web stack that turns infrastructure.yaml into a working AWS project page after the repair.
  • Before-and-after troubleshooting evidence showing Not reachable, Reachable, plus the restored web page.
  • A public portfolio repository where a rendered Mermaid architecture diagram anchors your engineering write-up.
  • Secret Mission: Open a pull request from the lessons-learned branch to add LESSONS.md.

Are there any prerequisites?

You need AWS and GitHub accounts with permission to create the project resources on a 64-bit Windows 10 or 11 device.

No AWS CLI or prior Git experience is required.

Before We Start

Before you touch any tools or cloud resources, lock in the portfolio story you are about to create. Your goal is to connect a deliberate HTTP failure to a clear diagnosis, a controlled repair, and published evidence.

Set Up Your Windows Portfolio Workspace

Your network repair evidence needs a dependable home before you create any billable AWS resources. A local workspace keeps every project artifact in one place.

You'll use Visual Studio Code to edit the portfolio files. GitHub Desktop manages a local Git repository that tracks each change.

In this step, get ready to:
  • Confirm that your Windows device meets the compatibility requirements.
  • Prepare Visual Studio Code as your project editor.
  • Create a tracked local repository for the lab.
Confirm Windows compatibility and install Visual Studio Code

Visual Studio Code requires 64-bit Windows 10 or Windows 11. GitHub Desktop also requires a 64-bit operating system.

  • Press the Windows key to open search.
  • Type Settings into search.
  • Press Enter.
  • Select System from the left sidebar.
  • Select About.
  • Under Windows specifications, confirm that the edition is Windows 10 or Windows 11.
  • Under Device specifications, confirm that System type lists a 64-bit operating system.

A supported edition clears the Windows version check. A 64-bit system type clears the architecture check.

  • Press the Windows key to search for your editor.
  • Type Visual Studio Code into search.

✔️ Visual Studio Code opens

  • Select Visual Studio Code from the search results.

Your editor is ready for the portfolio files you'll create in this project.

ⓧ Visual Studio Code isn't installed

The recommended Windows User setup does not require administrator permissions. Windows may still ask you to approve the installation.

  • Open the official Visual Studio Code Windows setup guide.
  • Choose the User setup download.
  • Select the downloaded installer from your browser's downloads list.
  • Approve the Windows installation request if it appears.
  • Complete the installer using its default options.
  • Press the Windows key to open search.
  • Type Visual Studio Code into search.
  • Press Enter.

Visual Studio Code opens to an empty editor window. Your project editor is now ready.

Visual Studio Code won't open?

  • Confirm that the installer finished before searching again.
  • Restart Windows if the completed installation does not appear in search.

Ask for help with installing Visual Studio Code on Windows.

Install and configure GitHub Desktop

GitHub Desktop gives you a visual view of repository changes. This keeps the source-control workflow visible without requiring terminal commands.

  • Press the Windows key to search for GitHub Desktop.
  • Type GitHub Desktop into search.

✔️ GitHub Desktop opens

  • Select GitHub Desktop from the search results.

GitHub Desktop is ready to connect your local work to your GitHub account.

ⓧ GitHub Desktop isn't installed

The Windows installer handles the Git components that GitHub Desktop needs. The setup may show standard Windows approval prompts.

  • Open the official GitHub Desktop download page.
  • Click Download for Windows (64bit).
  • Select the downloaded installer from your browser's downloads list.
  • Complete the installer prompts.
  • Press the Windows key to open search.
  • Type GitHub Desktop into search.
  • Press Enter.

GitHub Desktop opens to its welcome or sign-in screen. The source-control tool is now installed.

GitHub Desktop won't install?

  • Confirm that the download is the 64-bit Windows installer.
  • Close any existing GitHub Desktop window before running the installer again.

Ask for help with installing GitHub Desktop on Windows.

The browser handles your GitHub credentials during authentication. Your repository does not receive your account password.

  • In GitHub Desktop, click File.
  • Select Options.
  • Select Accounts.
  • Select the appropriate Sign Into button for your GitHub account.
  • Complete the GitHub authentication in your browser.
  • Return to GitHub Desktop.

GitHub Desktop now shows your connected account. Your local repositories can use that authenticated GitHub identity.

  • Click File in GitHub Desktop.
  • Select Options.
  • Select Integrations.
  • Under External Editor, select Visual Studio Code.
  • Click Save.

Your GitHub account connection is live. Visual Studio Code is now the editor GitHub Desktop opens for this project.

Can't connect your account or editor?

  • Complete any unfinished browser authorization before returning to GitHub Desktop.
  • Confirm that Visual Studio Code opens normally before selecting it as the external editor.

Ask for help with configuring GitHub Desktop.

Create and verify your local repository

A local repository gives the project a named home on your computer. Initializing it with a README creates a file you can edit immediately to test the tracking workflow.

  • Click File in GitHub Desktop.
  • Select Create a New Repository on your Hard Drive....

The new repository form opens. The values you enter here define the local project that GitHub Desktop tracks.

  • Enter aws-network-repair-lab as the repository name.
  • Select Initialize this repository with a README.
  • Click Create repository.

GitHub Desktop switches to the new repository. The current repository name shows aws-network-repair-lab.

  • Click Repository in the top menu.
  • Select Open in default editor.
  • Select README.md from the Visual Studio Code Explorer sidebar.
  • Select the existing contents of README.md.
  • Replace the selected contents by pasting the code below:
# AWS Network Repair Lab

What does this file do?

  • The # turns the line into the main Markdown heading.
  • The heading gives the repository a clear project title before you add the full engineering write-up.
  • Save README.md in Visual Studio Code.

Before you switch back, what change do you expect GitHub Desktop to detect?

  • Return to GitHub Desktop.
  • Select the Changes view.

You'll see README.md listed as a changed file. The diff shows the new project title.

That's your first visible source-control signal. GitHub Desktop can detect edits saved from Visual Studio Code.

README.md isn't listed in Changes?

  • Confirm that GitHub Desktop currently shows the aws-network-repair-lab repository.
  • Save README.md again before returning to the Changes view.
  • Confirm that the heading uses the capitalization shown in the code block.

Ask for help when GitHub Desktop cannot detect the README change.

✔️ Awesome, I've got everything!

Your README matches the target state for this step.

ⓧ I'd like to double check the full code

# AWS Network Repair Lab

What should match?

This is the entire README.md file at this point. The heading text plus capitalization should match exactly.

  • Capture the GitHub Desktop Changes view by pressing Windows logo key + Shift + S.
  • Save the snip outside the aws-network-repair-lab folder by pressing Ctrl + S.

Your local source-control loop now catches every saved edit. Next, you'll use this workspace to deploy the deliberately broken AWS web stack.

Deploy a Broken Web Stack

Your local portfolio workspace is ready. You can now turn that repository into a reproducible cloud project.

A stack can finish successfully while its application remains unreachable. In this step, AWS CloudFormation deploys the resources before you test HTTP reachability as a separate signal.

In this step, get ready to:
  • Create the deliberately incomplete CloudFormation template.
  • Deploy the template as a stack in US East (N. Virginia).
  • Capture evidence of the failed browser request.
Create the broken template

A CloudFormation template describes cloud resources as infrastructure as code. This version defines a web stack with one network control left incomplete for the troubleshooting exercise.

  • In the Visual Studio Code Explorer sidebar from earlier, use New Folder to create an evidence folder inside aws-network-repair-lab.
  • Use New File to create infrastructure.yaml inside aws-network-repair-lab.

You should see evidence and infrastructure.yaml beside README.md in the Explorer sidebar.

  • Add the template metadata plus the first VPC resource to infrastructure.yaml by pasting this code:
AWSTemplateFormatVersion: '2010-09-09'
Description: Deploys a small public web server for an AWS network troubleshooting portfolio lab.

Parameters:
  LatestAmiId:
    Description: Public Systems Manager parameter for the latest Amazon Linux 2023 x86_64 AMI.
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Resources:
  LabVpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: aws-network-repair-vpc

What Does This Section Do?

  • The template metadata describes the stack's purpose.
  • LatestAmiId resolves the current Amazon Linux 2023 machine image from a public Systems Manager parameter.
  • LabVpc creates the isolated network with DNS support.
  • Save infrastructure.yaml.
  • Confirm the editor shows Parameters followed by LabVpc.

Seeing YAML Warnings at the Top?

Check that Parameters: and Resources: start at the far left. Keep each nested level aligned with spaces.

Help me fix the YAML indentation in the metadata and LabVpc sections.

  • Add the internet gateway plus the public subnet below Value: aws-network-repair-vpc by pasting this code:

  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: aws-network-repair-igw

  GatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref LabVpc
      InternetGatewayId: !Ref InternetGateway

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref LabVpc
      CidrBlock: 10.0.1.0/24
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: aws-network-repair-public-subnet

How Does Traffic Enter the Network?

  • InternetGateway provides a target for the public internet route.
  • GatewayAttachment connects that gateway to LabVpc.
  • PublicSubnet assigns public IPv4 addresses to instances launched inside it.
  • Save infrastructure.yaml.
  • Confirm InternetGateway plus GatewayAttachment plus PublicSubnet appear below LabVpc.

Network Resources Out of Alignment?

Make sure each logical resource begins with two spaces under Resources:. Keep every Properties: line nested beneath its resource.

Help me align the internet gateway and public subnet resources.

  • Add the public routing resources below Value: aws-network-repair-public-subnet by pasting this code:

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref LabVpc
      Tags:
        - Key: Name
          Value: aws-network-repair-public-rt

  DefaultRoute:
    Type: AWS::EC2::Route
    DependsOn: GatewayAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable

How Does the Public Route Work?

  • PublicRouteTable stores the routes used by the public subnet.
  • DefaultRoute sends IPv4 traffic for 0.0.0.0/0 to the internet gateway.
  • PublicSubnetRouteTableAssociation applies that route table to PublicSubnet.
  • Save infrastructure.yaml.
  • Confirm DefaultRoute contains DependsOn: GatewayAttachment.

Route Resources Nested Incorrectly?

Check that DefaultRoute aligns with PublicRouteTable. Keep DependsOn: GatewayAttachment directly beneath the route type.

Help me repair the route-resource structure.

  • Add the security group plus the web server bootstrap below RouteTableId: !Ref PublicRouteTable by pasting this code:

  WebServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allows public HTTP access to the portfolio web server.
      VpcId: !Ref LabVpc
      Tags:
        - Key: Name
          Value: aws-network-repair-web-sg

  WebServer:
    Type: AWS::EC2::Instance
    DependsOn: DefaultRoute
    Properties:
      ImageId: !Ref LatestAmiId
      InstanceType: t3.micro
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !Ref WebServerSecurityGroup
      UserData:
        Fn::Base64: |
          #!/bin/bash -xe
          sudo dnf install -y httpd wget php-fpm php-mysqli php-json php php-devel
          sudo systemctl enable httpd
          sudo systemctl start httpd
          cat > /var/www/html/index.html <<'EOF'

What Starts the Web Server?

  • WebServerSecurityGroup declares the network control attached to the instance.
  • WebServer launches a t3.micro instance on Amazon EC2.
  • UserData installs the Apache packages during the first boot.
  • The service commands enable Apache for later boots.
  • The final command begins writing the project page to the Apache document directory.
  • Save infrastructure.yaml.
  • Confirm the WebServer resource references WebServerSecurityGroup.

Web Server Block Highlighted?

Keep UserData: inside the WebServer properties. Preserve the spacing before every shell command.

Help me fix the WebServer YAML structure.

  • Complete the web page plus the instance tags below cat > /var/www/html/index.html <<'EOF' by pasting this code:
          <!doctype html>
          <html lang="en">
          <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, initial-scale=1">
            <title>AWS Network Repair Lab</title>
            <style>
              body { margin: 0; min-height: 100vh; display: grid; place-items: center; font-family: Arial, sans-serif; background: #0f172a; color: #e2e8f0; }
              main { width: min(680px, 86vw); padding: 2.5rem; border: 1px solid #334155; border-radius: 16px; background: #1e293b; box-shadow: 0 20px 45px rgba(0, 0, 0, 0.35); }
              h1 { color: #38bdf8; }
              code { color: #fbbf24; }
            </style>
          </head>
          <body>
            <main>
              <p>Connectivity restored</p>
              <h1>AWS Network Repair Lab</h1>
              <p>This Amazon Linux 2023 web server was deployed with AWS CloudFormation.</p>
              <p>HTTP traffic now reaches the instance through a security group rule for <code>TCP/80</code>.</p>
            </main>
          </body>
          </html>
          EOF
      Tags:
        - Key: Name
          Value: aws-network-repair-web-server

What Does the Page Show?

  • The HTML creates the project page served by Apache.
  • The CSS centers a dark content card in the browser.
  • The EOF marker closes the page content written by the startup script.
  • The Name tag makes the instance easier to identify in AWS.
  • Save infrastructure.yaml.
  • Confirm the HTML lines remain indented beneath Fn::Base64: |.

HTML Shifted Out of User Data?

Keep each HTML line aligned with the shell commands above it. Keep Tags: aligned with the WebServer properties.

Help me restore the HTML indentation inside UserData.

  • Add the stack outputs below Value: aws-network-repair-web-server by pasting this code:

Outputs:
  WebsiteURL:
    Description: Public URL for the portfolio web page.
    Value: !Sub 'http://${WebServer.PublicDnsName}'
  WebServerInstanceId:
    Description: EC2 instance ID used as the Reachability Analyzer destination.
    Value: !Ref WebServer
  InternetGatewayId:
    Description: Internet gateway ID used as the Reachability Analyzer source.
    Value: !Ref InternetGateway
  SecurityGroupId:
    Description: Security group ID expected to block and then allow HTTP.
    Value: !Ref WebServerSecurityGroup
  VpcId:
    Description: VPC created for the lab.
    Value: !Ref LabVpc

Why Add Stack Outputs?

  • WebsiteURL exposes the public DNS address for the browser test.
  • WebServerInstanceId identifies the analysis destination used in the next step.
  • InternetGatewayId identifies the analysis source used in the next step.
  • SecurityGroupId identifies the network control attached to the web server.
  • VpcId records the network created by the stack.
  • Save infrastructure.yaml.
  • Confirm WebsiteURL appears first under Outputs:.

Outputs Highlighted as Invalid?

Keep Outputs: at the far left. Align each output name two spaces beneath it.

Help me fix the Outputs section.

Use this comparison to catch a missing line before the template leaves your computer.

✔️ Awesome, I've got everything!

Your deliberately broken template is saved. Continue to the deployment substep.

ⓧ I'd like to double check the full code

AWSTemplateFormatVersion: '2010-09-09'
Description: Deploys a small public web server for an AWS network troubleshooting portfolio lab.

Parameters:
  LatestAmiId:
    Description: Public Systems Manager parameter for the latest Amazon Linux 2023 x86_64 AMI.
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Resources:
  LabVpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: aws-network-repair-vpc

  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: aws-network-repair-igw

  GatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref LabVpc
      InternetGatewayId: !Ref InternetGateway

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref LabVpc
      CidrBlock: 10.0.1.0/24
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: aws-network-repair-public-subnet

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref LabVpc
      Tags:
        - Key: Name
          Value: aws-network-repair-public-rt

  DefaultRoute:
    Type: AWS::EC2::Route
    DependsOn: GatewayAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable

  WebServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allows public HTTP access to the portfolio web server.
      VpcId: !Ref LabVpc
      Tags:
        - Key: Name
          Value: aws-network-repair-web-sg

  WebServer:
    Type: AWS::EC2::Instance
    DependsOn: DefaultRoute
    Properties:
      ImageId: !Ref LatestAmiId
      InstanceType: t3.micro
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !Ref WebServerSecurityGroup
      UserData:
        Fn::Base64: |
          #!/bin/bash -xe
          sudo dnf install -y httpd wget php-fpm php-mysqli php-json php php-devel
          sudo systemctl enable httpd
          sudo systemctl start httpd
          cat > /var/www/html/index.html <<'EOF'
          <!doctype html>
          <html lang="en">
          <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, initial-scale=1">
            <title>AWS Network Repair Lab</title>
            <style>
              body { margin: 0; min-height: 100vh; display: grid; place-items: center; font-family: Arial, sans-serif; background: #0f172a; color: #e2e8f0; }
              main { width: min(680px, 86vw); padding: 2.5rem; border: 1px solid #334155; border-radius: 16px; background: #1e293b; box-shadow: 0 20px 45px rgba(0, 0, 0, 0.35); }
              h1 { color: #38bdf8; }
              code { color: #fbbf24; }
            </style>
          </head>
          <body>
            <main>
              <p>Connectivity restored</p>
              <h1>AWS Network Repair Lab</h1>
              <p>This Amazon Linux 2023 web server was deployed with AWS CloudFormation.</p>
              <p>HTTP traffic now reaches the instance through a security group rule for <code>TCP/80</code>.</p>
            </main>
          </body>
          </html>
          EOF
      Tags:
        - Key: Name
          Value: aws-network-repair-web-server

Outputs:
  WebsiteURL:
    Description: Public URL for the portfolio web page.
    Value: !Sub 'http://${WebServer.PublicDnsName}'
  WebServerInstanceId:
    Description: EC2 instance ID used as the Reachability Analyzer destination.
    Value: !Ref WebServer
  InternetGatewayId:
    Description: Internet gateway ID used as the Reachability Analyzer source.
    Value: !Ref InternetGateway
  SecurityGroupId:
    Description: Security group ID expected to block and then allow HTTP.
    Value: !Ref WebServerSecurityGroup
  VpcId:
    Description: VPC created for the lab.
    Value: !Ref LabVpc

What Should Match?

Compare this reference with your saved file from top to bottom. The security group should contain its description plus VPC reference plus tags.

Deploy the CloudFormation stack

CloudFormation reads the template as one dependency graph. It creates each declared resource in the required order.

Why CloudFormation for This Lab?

Manual console changes would leave no reusable definition behind. CloudFormation keeps the network plus the web server reviewable inside infrastructure.yaml.

  • In your browser, sign in to the AWS Management Console.
  • Use the Region selector to choose US East (N. Virginia).
  • Use the console search to open CloudFormation.
  • Choose Create stack.
  • Choose With new resources (standard).
  • Choose Choose an existing template.
  • Choose Upload a template file.
  • Choose Choose File.
  • Select infrastructure.yaml from your local aws-network-repair-lab repository.
  • Choose Next.

Where Does the Uploaded Template Go?

CloudFormation uploads the local template to an Amazon S3 bucket in the selected Region. AWS can create a CloudFormation-managed bucket when one is unavailable.

  • Enter aws-network-repair-lab as the stack name.
  • Keep the default value for LatestAmiId.
  • Choose Next.
  • Keep the defaults on the options page.
  • Choose Next.

Charges Start at Submission

Submitting this stack starts resources that can generate charges for EC2 compute plus storage plus a public IPv4 address plus data transfer. The cleanup section later shows how to remove the stack.

  • Review the selected template plus the stack name.
  • Choose Submit.

The deployment takes several minutes while AWS creates the network plus the instance. A quiet stack page during this wait is expected.

  • Wait until the stack status changes to CREATE_COMPLETE.

Good progress. CloudFormation has accepted your template plus created the declared AWS resources.

Stack Creation Did Not Complete?

Open the stack events to find the first failed resource. A template parsing failure usually points to misplaced YAML indentation.

Help me diagnose my failed CloudFormation stack creation.

Test the WebsiteURL and capture the failure

Stack creation plus application reachability are separate checks. The output URL now tests whether browser traffic can reach the web server.

  • Select the Outputs tab on the stack page.
  • Locate the WebsiteURL output.
  • Copy the WebsiteURL value.
  • Record the copied value here: your WebsiteURL output.

Before you open the URL, do you think CREATE_COMPLETE guarantees that the browser request succeeds?

  • Paste your WebsiteURL output into a new browser tab.
  • Press Enter.

The browser cannot load the page even though the stack reports CREATE_COMPLETE. This visible shortfall is the planned troubleshooting problem.

What Did the Test Prove?

The resources deployed successfully. The security group has no inbound HTTP rule for TCP port 80.

The browser failure proves that deployment status alone cannot confirm application connectivity.

  • Open the Snipping Tool capture overlay with Windows logo key + Shift + S.
  • Drag the capture area around the failed browser result.
  • Select the captured snip to open it in Snipping Tool.
  • Press Ctrl + S to open the save dialog.
  • Navigate to the evidence folder inside aws-network-repair-lab.
  • Enter 01-browser-timeout.png as the file name.
  • Choose Save.

That is the failure captured. Your repository now contains evidence that the deployed application could not accept the browser request.

Screenshot Missing from the Evidence Folder?

Return to the Visual Studio Code Explorer sidebar. Confirm the file is named exactly 01-browser-timeout.png inside evidence.

Help me save my browser-failure screenshot in the correct project folder.

Your stack deployed successfully while its web page stayed unreachable. Next, you'll trace the block with Reachability Analyzer.

Find the Network Block

Your AWS CloudFormation stack reached CREATE_COMPLETE in the last step. The browser still cannot load the web page.

Guessing between routes and firewalls wastes time. In this step, you'll use Amazon VPC Reachability Analyzer to identify the component blocking TCP port 80.

In this step, get ready to:
  • Record the stack's network resource IDs.
  • Analyze the modeled HTTP path to the web server.
  • Capture evidence of the blocking component.
Record the stack outputs

The stack's outputs expose the exact IDs created during deployment. These IDs keep your analysis tied to the broken environment from the previous step.

  • Return to the aws-network-repair-lab stack in AWS CloudFormation from earlier.
  • Select the Outputs tab.
  • Record the InternetGatewayId value here: your internet gateway ID.
  • Record the WebServerInstanceId value here: your web server instance ID.
  • Record the SecurityGroupId value here: your web server security group ID.

You now have the two path endpoints plus the security group ID that you can test against the diagnosis.

Create the analysis path

Reachability Analyzer checks modeled connectivity between supported AWS resources. Your path begins at the internet gateway before ending at the Amazon EC2 instance.

Why use Reachability Analyzer?

Trial-and-error edits can change the environment before you understand the failure. Reachability Analyzer preserves the broken state while it evaluates the configured path.

When the destination is unreachable, the analysis identifies a blocking component. That turns a browser timeout into evidence you can act on.

Reachability Analyzer is available through Network Manager in the AWS Management Console.

  • Enter Network Manager in the AWS Management Console search bar.
  • Select Network Manager from the search results.
  • Choose Reachability Analyzer in the left navigation.
  • Choose Create and analyze path.
  • Select an internet gateway in Source type.
  • Select your internet gateway ID in Source.

The path now starts at the internet gateway created by your stack.

  • Select an EC2 instance in Destination type.
  • Select your web server instance ID in Destination.

The source and destination now represent the same inbound path that failed in your browser.

  • Select TCP in Protocol.
  • Enter 80 in Destination port.

Before You Run the Analysis

Running this analysis costs $0.10. This project plans two analyses for $0.20 total.

This first run stays inside that planned amount. The second run verifies the repair later.

Before you run the analysis, ask yourself whether the modeled path will be reachable.

  • Choose Create and analyze path.
  • Wait for the analysis to complete.

You'll see Reachability status report Not reachable. This is the intended shortfall from the broken stack.

You have now turned the browser timeout into a reproducible network finding.

Analysis Not Completing?

Confirm that both resource IDs came from the aws-network-repair-lab stack in US East (N. Virginia). Resources from another Region cannot form this path.

Check that the internet gateway is the source. Confirm that the EC2 instance is the destination.

Ask for help with troubleshooting the Reachability Analyzer path.

Identify and capture the blocker

The overall result proves the path fails. The explanation details connect that failure to a specific AWS component.

Before you expand the result, ask yourself whether the blocking component will match one of the stack outputs.

  • Expand Explanations in the completed analysis.
  • Expand Details.
  • Locate the blocking component ID.
  • Compare the blocking component ID with your web server security group ID.

The IDs match. Reachability Analyzer identifies WebServerSecurityGroup as the component blocking the path.

Your diagnosis now has a precise root cause. Capture the completed result with Snipping Tool so the repository can preserve the evidence.

  • Press Windows logo key + Shift + S to open the capture overlay.
  • Drag over the completed analysis result.
  • Frame the capture to include Not reachable plus the blocking security group ID.
  • Select the capture preview.
  • Press Ctrl + S to open the save dialog.
  • Select the evidence folder inside aws-network-repair-lab.
  • Save the capture as 02-not-reachable.png.

Strong work. Your evidence now ties the browser failure to the exact network control blocking TCP port 80.

Your diagnosis is backed by AWS evidence. Next, you'll repair the declared network control through infrastructure as code.

Repair the Stack Through Code

Your completed Amazon VPC Reachability Analyzer path has isolated the broken security group. The stack exists, but TCP port 80 has no inbound permission.

The repair belongs in infrastructure.yaml, which is your AWS CloudFormation source of truth. Updating the live rule directly would leave future deployments broken.

In this step, get ready to:
  • Declare public HTTP ingress in the CloudFormation template.
  • Update the existing CloudFormation stack.
  • Prove the repaired path works in Reachability Analyzer and your browser.
Add the HTTP ingress rule

A security group ingress rule defines which traffic can enter a resource. This rule permits public HTTP requests over TCP/80.

  • In the Explorer sidebar in Visual Studio Code, select infrastructure.yaml.
  • Locate the WebServerSecurityGroup resource.
  • Find the VpcId: !Ref LabVpc line inside its Properties section.
  • Paste this block directly below that line:
SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 80
    ToPort: 80
    CidrIp: 0.0.0.0/0

What Does This Rule Do?

  • The SecurityGroupIngress property declares the security group's inbound rules.
  • The IpProtocol value selects TCP traffic.
  • The FromPort and ToPort values limit the rule to HTTP port 80.
  • The CidrIp value allows requests from public IPv4 addresses.
  • Save infrastructure.yaml in Visual Studio Code.

You should now see SecurityGroupIngress nested under WebServerSecurityGroup.Properties at the same indentation level as VpcId.

Seeing a YAML Problem?

YAML uses indentation to define structure. Align SecurityGroupIngress with GroupDescription and VpcId.

Check that each property beneath the hyphen has four additional spaces. Help me check the security group rule indentation.

✔️ Awesome, I've got everything!

Your template now declares the HTTP rule that repairs the diagnosed network block.

ⓧ I'd like to double check the full code

AWSTemplateFormatVersion: '2010-09-09'
Description: Deploys a small public web server for an AWS network troubleshooting portfolio lab.

Parameters:
  LatestAmiId:
    Description: Public Systems Manager parameter for the latest Amazon Linux 2023 x86_64 AMI.
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Resources:
  LabVpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: aws-network-repair-vpc

  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: aws-network-repair-igw

  GatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref LabVpc
      InternetGatewayId: !Ref InternetGateway

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref LabVpc
      CidrBlock: 10.0.1.0/24
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: aws-network-repair-public-subnet

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref LabVpc
      Tags:
        - Key: Name
          Value: aws-network-repair-public-rt

  DefaultRoute:
    Type: AWS::EC2::Route
    DependsOn: GatewayAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable

  WebServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allows public HTTP access to the portfolio web server.
      VpcId: !Ref LabVpc
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: aws-network-repair-web-sg

  WebServer:
    Type: AWS::EC2::Instance
    DependsOn: DefaultRoute
    Properties:
      ImageId: !Ref LatestAmiId
      InstanceType: t3.micro
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !Ref WebServerSecurityGroup
      UserData:
        Fn::Base64: |
          #!/bin/bash -xe
          sudo dnf install -y httpd wget php-fpm php-mysqli php-json php php-devel
          sudo systemctl enable httpd
          sudo systemctl start httpd
          cat > /var/www/html/index.html <<'EOF'
          <!doctype html>
          <html lang="en">
          <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, initial-scale=1">
            <title>AWS Network Repair Lab</title>
            <style>
              body {
                margin: 0;
                min-height: 100vh;
                display: grid;
                place-items: center;
                font-family: Arial, sans-serif;
                background: #0f172a;
                color: #e2e8f0;
              }
              main {
                width: min(680px, 86vw);
                padding: 2.5rem;
                border: 1px solid #334155;
                border-radius: 16px;
                background: #1e293b;
                box-shadow: 0 20px 45px rgba(0, 0, 0, 0.35);
              }
              h1 { color: #38bdf8; }
              code { color: #fbbf24; }
            </style>
          </head>
          <body>
            <main>
              <p>Connectivity restored</p>
              <h1>AWS Network Repair Lab</h1>
              <p>This Amazon Linux 2023 web server was deployed with AWS CloudFormation.</p>
              <p>HTTP traffic now reaches the instance through a security group rule for <code>TCP/80</code>.</p>
            </main>
          </body>
          </html>
          EOF
      Tags:
        - Key: Name
          Value: aws-network-repair-web-server

Outputs:
  WebsiteURL:
    Description: Public URL for the portfolio web page.
    Value: !Sub 'http://${WebServer.PublicDnsName}'
  WebServerInstanceId:
    Description: EC2 instance ID used as the Reachability Analyzer destination.
    Value: !Ref WebServer
  InternetGatewayId:
    Description: Internet gateway ID used as the Reachability Analyzer source.
    Value: !Ref InternetGateway
  SecurityGroupId:
    Description: Security group ID expected to block and then allow HTTP.
    Value: !Ref WebServerSecurityGroup
  VpcId:
    Description: VPC created for the lab.
    Value: !Ref LabVpc
Update the existing stack

A CloudFormation update compares the saved template with the current stack. It applies the declared ingress rule to the existing security group.

Why CloudFormation Instead of a Console Edit?

A direct security group edit would repair only the current environment. Future deployments from the broken template would lose the rule.

Updating the template preserves the fix as infrastructure as code. The repository remains the repeatable definition of your network.

  • Return to the AWS Management Console from earlier.
  • Return to the CloudFormation console.
  • Select the aws-network-repair-lab stack.
  • Choose Update.
  • Select Replace existing template.
  • Select Upload a template file.
  • Choose Choose file.
  • Select the saved infrastructure.yaml file inside your aws-network-repair-lab folder.

Where Does the Uploaded Template Go?

CloudFormation uploads the local template to an Amazon S3 bucket in US East (N. Virginia). It can reuse a CloudFormation-managed bucket that already exists in this Region.

  • Review the change-set preview.
  • Confirm the preview targets WebServerSecurityGroup.
  • Choose Update stack.

CloudFormation applies the change in the background, so a short wait here is normal.

  • Wait for the stack status to reach UPDATE_COMPLETE.

The source of truth is back in control. CloudFormation has applied the declared network repair.

Stack Update Did Not Complete?

Confirm that you uploaded the saved copy of infrastructure.yaml from the aws-network-repair-lab folder.

Review the latest stack event for the resource that failed. Help me diagnose my CloudFormation update.

Prove the repair end to end

The existing path keeps every test input fixed. Only the declared ingress rule has changed.

  • Return to the existing Reachability Analyzer path in Network Manager.

Before you reanalyze the path, do you expect the same source and destination to remain blocked after the template update?

  • Choose Analyze path.
  • Wait for the analysis to complete.

You should see Reachability status set to Reachable.

That is the diagnosis loop closed. The same TCP/80 path now passes with the declared rule in place.

  • Keep the completed result visible with Reachable and the path details in view.
  • Press Windows logo key + Shift + S to open the capture overlay.
  • Drag over the completed Reachability Analyzer result.
  • Press Ctrl + S to save the snip.
  • Save the image as evidence/03-reachable.png.

Still Seeing Not Reachable?

Confirm the stack status is UPDATE_COMPLETE. Check that the path still uses the recorded InternetGatewayId as its source.

Confirm that the destination is the recorded WebServerInstanceId. Help me investigate the unchanged path result.

  • Return to the aws-network-repair-lab stack in CloudFormation.
  • Select the Outputs tab.
  • Copy the WebsiteURL value.

Before you open the URL, do you expect the browser to time out again or reach the web server?

  • Paste the WebsiteURL into your browser address bar.
  • Press Enter.

You should see Connectivity restored above the AWS Network Repair Lab heading.

You repaired the stack without creating configuration drift. The browser now proves that HTTP reaches the Amazon Linux 2023 web server.

  • Keep the working AWS Network Repair Lab page visible.
  • Press Windows logo key + Shift + S to open the capture overlay.
  • Drag over the working browser page.
  • Press Ctrl + S to save the snip.
  • Save the image as evidence/04-working-site.png.

Browser Still Cannot Load the Page?

Confirm that you copied WebsiteURL from the updated stack's Outputs tab. Reload the exact URL after confirming Reachability Analyzer reports Reachable.

Check that the stack still contains the original WebServer resource. Help me troubleshoot the web page.

Your stack is repaired, your network test passes, and your evidence captures the full troubleshooting story. Next up, you'll turn these artifacts into a public GitHub portfolio repository.

Publish Your Portfolio Repository

Your AWS CloudFormation stack now serves the project page. Amazon VPC Reachability Analyzer also proves that the repaired path is reachable.

The next goal is a public GitHub repository that presents this work as an engineering story. GitHub Desktop will carry your local changes into that public repository.

Working infrastructure remains invisible unless the repository explains the architecture and failure. The write-up will preserve your diagnosis through the cleanup plan.

In this step, get ready to:
  • Complete the portfolio README.
  • Create a credential-free project commit.
  • Publish the repository publicly on GitHub.
Write the portfolio README

A README uses Markdown to turn project files into a structured explanation. The preview in Visual Studio Code gives you a quick feedback loop while you build that explanation.

  • In the Visual Studio Code window from earlier, select README.md from the Explorer sidebar.
  • Replace the current title in README.md with the first part of the portfolio write-up by pasting this content:
# AWS Network Repair Lab

This project deploys a small AWS web environment with CloudFormation, introduces a deliberate HTTP connectivity failure, diagnoses the blocking component with Amazon VPC Reachability Analyzer, and repairs the infrastructure through code.

## What this demonstrates

- AWS CloudFormation infrastructure as code
- VPC, subnet, internet gateway, route table, and security group relationships
- Amazon EC2 user-data bootstrapping
- Structured network troubleshooting
- Git commits, public repository publishing, and technical documentation

## Architecture

```mermaid
flowchart LR
    Browser[Web browser] -->|HTTP TCP 80| IGW[Internet gateway]
    IGW --> Subnet[Public subnet 10.0.1.0/24]
    Subnet --> EC2[Amazon Linux 2023 EC2]
    RouteTable[Public route table] -. 0.0.0.0/0 .-> IGW
    SecurityGroup[Web security group] -. controls TCP 80 .-> EC2
    CloudFormation[AWS CloudFormation] -. provisions .-> IGW
    CloudFormation -. provisions .-> Subnet
    CloudFormation -. provisions .-> RouteTable
    CloudFormation -. provisions .-> SecurityGroup
    CloudFormation -. provisions .-> EC2
```

What does this section add?

  • The opening paragraph gives readers the project story before they inspect any files.
  • The demonstration list turns the project into concrete engineering capabilities.
  • The Mermaid source describes how traffic moves from the browser to the EC2 instance.
  • Save README.md.
  • Press Cmd+K, release the keys, then press V on macOS. Use Ctrl+K, release the keys, then press V on Windows.
  • Confirm the preview shows the project title beside a formatted capability list.

Preview missing the headings?

  • Confirm the file name is README.md.
  • Check that each heading begins with the same number of hash symbols shown above.

Help me fix my Markdown preview.

  • Add the failure and diagnosis sections immediately below the closing fence of the Mermaid diagram by pasting this content:
## Failure scenario

The initial CloudFormation template deliberately omitted `SecurityGroupIngress`. The stack reached `CREATE_COMPLETE`, but the browser could not reach the web server. This showed that successful resource creation does not guarantee application connectivity.

![Browser timeout before the repair](evidence/01-browser-timeout.png)

## Diagnosis

I created a Reachability Analyzer path with the internet gateway as the source, the EC2 instance as the destination, TCP as the protocol, and destination port `80`. The result was `Not reachable`, and the blocking component matched the web server security group.

![Reachability Analyzer before the repair](evidence/02-not-reachable.png)

What does this section add?

  • The failure section separates successful resource creation from application connectivity.
  • The diagnosis section records the path configuration that isolated the security group.
  • The relative image paths connect each claim to evidence stored inside the repository.
  • Save README.md.
  • Confirm the preview shows the failure screenshot below the failure explanation.
  • Confirm the preview shows the first Reachability Analyzer screenshot below the diagnosis.

Evidence images missing?

  • Confirm the screenshots remain inside the evidence folder.
  • Compare each image file name with its path in README.md.
  • Match the capitalization of every folder name and file name.

Help me repair the README image paths.

  • Add the repair section immediately below the first Reachability Analyzer image by pasting this content:
## Repair

I added the missing HTTP rule to the CloudFormation template instead of editing the live security group manually.

```yaml
SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 80
    ToPort: 80
    CidrIp: 0.0.0.0/0
```

After updating the existing stack, the same analysis reported `Reachable`.

![Reachability Analyzer after the repair](evidence/03-reachable.png)

The browser then displayed the web page created by the EC2 user-data script.

![Working AWS web page](evidence/04-working-site.png)

What does this section add?

  • The rule excerpt identifies the exact infrastructure change that restored HTTP access.
  • The second analysis proves that the same modeled path became reachable.
  • The working-page screenshot proves that the application responded after the repair.
  • Save README.md.
  • Confirm the preview formats the ingress rule as a YAML code block.
  • Confirm the repaired-path screenshot appears above the working-page screenshot.

Repair rule displaying as plain text?

  • Confirm the opening code fence includes yaml.
  • Confirm the closing code fence sits directly below the ingress rule.

Help me fix the YAML block in my README.

  • Add the deployment, cost, and security sections immediately below the working-page image by pasting this content:
## Deployment

1. In AWS CloudFormation, choose Create stack and With new resources (standard).
2. Choose Choose an existing template, Upload a template file, and upload `infrastructure.yaml`.
3. Name the stack `aws-network-repair-lab` and submit it in US East (N. Virginia).
4. When the stack reaches `CREATE_COMPLETE`, open `WebsiteURL` from Outputs.

## Cost awareness

- Reachability Analyzer costs $0.10 per analysis. This project plans two analyses, totaling $0.20.
- A Linux `t3.micro` in US East (N. Virginia) is listed at $0.0104 per hour.
- The public IPv4 address costs $0.005 per hour.
- CloudFormation adds no charge for the AWS-native `AWS::*` resources in this template. The resources themselves, EBS storage, and applicable data transfer are still billed.

## Security

This repository contains no AWS passwords, access keys, tokens, private keys, or other credentials. The template uses a public Systems Manager parameter to resolve the Amazon Linux 2023 AMI.

What does this section add?

  • The deployment section makes the infrastructure reproducible from the repository.
  • The cost section records the charges associated with the lab.
  • The security section tells readers that the public repository contains no credentials.
  • Save README.md.
  • Confirm the preview shows a numbered deployment list.
  • Confirm the preview shows separate cost and security sections.

Deployment steps running together?

  • Keep each numbered deployment instruction on its own line.
  • Leave one blank line before the cost heading.

Help me fix the README list formatting.

  • Finish README.md by adding the cleanup, repository contents, and outcome sections below the security statement:
## Cleanup

1. In Reachability Analyzer, select the path and choose Actions, Delete path.
2. In CloudFormation, select `aws-network-repair-lab`, choose Delete, and confirm Delete.
3. Use Filter status, Deleted to verify the stack reached `DELETE_COMPLETE`.

## Repository contents

- `infrastructure.yaml`: Final repaired CloudFormation template
- `README.md`: Architecture, diagnosis, repair, costs, and cleanup
- `evidence/`: Before-and-after screenshots

## Outcome

The final repository proves that I can declare AWS infrastructure, diagnose a network failure with a purpose-built AWS tool, repair the source of truth, verify the result, and communicate the work clearly.

What does this section add?

  • The cleanup section shows how to stop the cloud resources from generating further charges.
  • The repository contents section gives readers a map of the project files.
  • The outcome closes with the professional capability demonstrated by the project.
  • Save README.md.
  • Confirm the preview ends with the cleanup steps.
  • Confirm the repository contents appear as three bullet points.
  • Confirm the final outcome appears below the file list.

Final sections out of order?

  • Place the cleanup section directly below the security statement.
  • Place the repository contents section directly below the cleanup steps.
  • Keep the outcome section at the end of the file.

Help me compare my README structure.

✔️ Awesome, I've got everything!

Your README.md now matches the complete portfolio write-up.

ⓧ I'd like to double check the full code

# AWS Network Repair Lab

This project deploys a small AWS web environment with CloudFormation, introduces a deliberate HTTP connectivity failure, diagnoses the blocking component with Amazon VPC Reachability Analyzer, and repairs the infrastructure through code.

## What this demonstrates

- AWS CloudFormation infrastructure as code
- VPC, subnet, internet gateway, route table, and security group relationships
- Amazon EC2 user-data bootstrapping
- Structured network troubleshooting
- Git commits, public repository publishing, and technical documentation

## Architecture

```mermaid
flowchart LR
    Browser[Web browser] -->|HTTP TCP 80| IGW[Internet gateway]
    IGW --> Subnet[Public subnet 10.0.1.0/24]
    Subnet --> EC2[Amazon Linux 2023 EC2]
    RouteTable[Public route table] -. 0.0.0.0/0 .-> IGW
    SecurityGroup[Web security group] -. controls TCP 80 .-> EC2
    CloudFormation[AWS CloudFormation] -. provisions .-> IGW
    CloudFormation -. provisions .-> Subnet
    CloudFormation -. provisions .-> RouteTable
    CloudFormation -. provisions .-> SecurityGroup
    CloudFormation -. provisions .-> EC2
```

## Failure scenario

The initial CloudFormation template deliberately omitted `SecurityGroupIngress`. The stack reached `CREATE_COMPLETE`, but the browser could not reach the web server. This showed that successful resource creation does not guarantee application connectivity.

![Browser timeout before the repair](evidence/01-browser-timeout.png)

## Diagnosis

I created a Reachability Analyzer path with the internet gateway as the source, the EC2 instance as the destination, TCP as the protocol, and destination port `80`. The result was `Not reachable`, and the blocking component matched the web server security group.

![Reachability Analyzer before the repair](evidence/02-not-reachable.png)

## Repair

I added the missing HTTP rule to the CloudFormation template instead of editing the live security group manually.

```yaml
SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 80
    ToPort: 80
    CidrIp: 0.0.0.0/0
```

After updating the existing stack, the same analysis reported `Reachable`.

![Reachability Analyzer after the repair](evidence/03-reachable.png)

The browser then displayed the web page created by the EC2 user-data script.

![Working AWS web page](evidence/04-working-site.png)

## Deployment

1. In AWS CloudFormation, choose Create stack and With new resources (standard).
2. Choose Choose an existing template, Upload a template file, and upload `infrastructure.yaml`.
3. Name the stack `aws-network-repair-lab` and submit it in US East (N. Virginia).
4. When the stack reaches `CREATE_COMPLETE`, open `WebsiteURL` from Outputs.

## Cost awareness

- Reachability Analyzer costs $0.10 per analysis. This project plans two analyses, totaling $0.20.
- A Linux `t3.micro` in US East (N. Virginia) is listed at $0.0104 per hour.
- The public IPv4 address costs $0.005 per hour.
- CloudFormation adds no charge for the AWS-native `AWS::*` resources in this template. The resources themselves, EBS storage, and applicable data transfer are still billed.

## Security

This repository contains no AWS passwords, access keys, tokens, private keys, or other credentials. The template uses a public Systems Manager parameter to resolve the Amazon Linux 2023 AMI.

## Cleanup

1. In Reachability Analyzer, select the path and choose Actions, Delete path.
2. In CloudFormation, select `aws-network-repair-lab`, choose Delete, and confirm Delete.
3. Use Filter status, Deleted to verify the stack reached `DELETE_COMPLETE`.

## Repository contents

- `infrastructure.yaml`: Final repaired CloudFormation template
- `README.md`: Architecture, diagnosis, repair, costs, and cleanup
- `evidence/`: Before-and-after screenshots

## Outcome

The final repository proves that I can declare AWS infrastructure, diagnose a network failure with a purpose-built AWS tool, repair the source of truth, verify the result, and communicate the work clearly.
Review and commit the project

A Git commit creates a permanent snapshot of the files you plan to publish. This snapshot should contain the repaired template, complete write-up, and four evidence images.

Publishing exposes every committed file. Your focused credential review confirms that the repository is ready for public visibility.

Passwords, access keys, tokens, and private keys must stay outside a public repository. The template uses a public AMI parameter, so infrastructure.yaml should contain no credentials.

  • Return to GitHub Desktop.
  • Select README.md in the Changes view.
  • Review the README diff for all four evidence paths.
  • Select infrastructure.yaml in the Changes view.
  • Review the template for passwords, access keys, tokens, private keys, or other credentials.
  • Review the four files under evidence for the expected file names.
  • Enter Document AWS network repair in the commit summary field.
  • Select the commit button below the summary field.

The Changes view should now be clear. Your local repository contains one commit for the repaired template, complete README, and evidence.

That is the trust-critical part complete. Your commit preserves the project without exposing credentials.

Files still listed after the commit?

  • Confirm the commit summary field contains Document AWS network repair.
  • Check that every project file has a selected checkbox in the Changes view.
  • Select the commit button again after choosing the missing files.

Help me complete the GitHub Desktop commit.

Publish and inspect the repository

A remote repository gives your local commit a shareable home. Public visibility lets readers inspect the documentation without access to your AWS account.

Publishing is the point where every committed file becomes visible to other GitHub users. Your credential review means this repository is ready for that exposure.

  • In GitHub Desktop, choose Publish repository.
  • Confirm the repository name is aws-network-repair-lab.
  • Leave Keep this code private unselected.
  • Choose Publish Repository.

Before you open the published repository, consider whether GitHub will turn the Mermaid source and image paths into visuals.

  • Select Repository from the GitHub Desktop menu.
  • Choose View on GitHub.

You should see the architecture as a rendered diagram. The four relative image paths should display their corresponding screenshots.

  • Confirm the repository header indicates public visibility.
  • Scroll to the Architecture section.
  • Confirm the Mermaid architecture appears as a rendered diagram.
  • Confirm the README renders all four evidence images.
  • Select infrastructure.yaml from the repository file list.
  • Confirm the template contains the repaired ingress rule without credentials.

Published README missing visuals?

  • Compare each image path in README.md with the corresponding file under evidence.
  • Confirm the Mermaid diagram begins with a Mermaid code fence.
  • Commit any corrections in GitHub Desktop before pushing the new commit.

Help me fix the published README visuals.

Your portfolio is now public. It shows the failed connection, the diagnosis, the infrastructure repair, and the working result in one repository.

Secret mission

Open Your First Pull Request

Add a focused lessons-learned document on a new branch. Publish it through a GitHub pull request whose diff leaves infrastructure.yaml untouched.

Clean Up Your Resources

Clean Up Your Resources

Your AWS resources remain live. Choose whether to keep the demo available, remove the cloud resources for later redeployment, or remove the local copy too.

Cost warning

Your two completed Amazon VPC Reachability Analyzer analyses cost $0.20. Each future analysis costs $0.10.

The Linux t3.micro instance costs $0.0104 per hour in US East (N. Virginia). Its public IPv4 address costs another $0.005 per hour.

EBS storage and applicable data transfer can add charges while the Amazon EC2 instance remains available. Choose Pause or Delete if you have finished demonstrating the live site.

Resources you used:

  • One AWS CloudFormation stack named aws-network-repair-lab containing the VPC, subnet, internet gateway, route table, security group, and web server.
  • One Reachability Analyzer path covering traffic from the internet gateway to the EC2 instance over TCP/80.
  • Template-upload storage that CloudFormation may have created or reused in Amazon S3.
  • One local Git repository named aws-network-repair-lab containing the template, documentation, and evidence files.

Your public GitHub repository remains your portfolio evidence. Every option below preserves the repository and its open pull request.

Keep everything running

No action is needed. Choose this option if you are still demonstrating the live web page.

  • Keep the aws-network-repair-lab stack in UPDATE_COMPLETE.
  • Keep the existing Reachability Analyzer path as live troubleshooting evidence.
  • Run another analysis only when you need fresh evidence because each run costs $0.10.
  • Keep the local aws-network-repair-lab repository available for future edits.
  • Keep the public repository available with its Mermaid diagram, four evidence images, and open pull request.

Pause - I'll come back to this later

Shut down the live cloud resources to stop their recurring charges. Keep the local repository so the repaired template is ready for another deployment.

Your Portfolio Evidence Stays Safe

Deleting the analysis path and stack removes the live lab. Your local files, public repository, four screenshots, and open pull request remain available.

Delete the Reachability Analyzer path
  • Return to the AWS Management Console.
  • Open Reachability Analyzer in Network Manager.
  • Select the path whose source is the stack internet gateway.
  • Confirm that the destination is the EC2 instance.
  • Confirm that the protocol is TCP with destination port 80.
  • Choose Actions.
  • Choose Delete path.
  • Confirm with Delete path.

The path disappears from Reachability Analyzer. Its stored analyses are deleted with it.

Delete the CloudFormation stack

Deleting the stack looks like a large change because it removes every AWS resource declared by infrastructure.yaml. The same file can redeploy the lab when you return.

  • Return to CloudFormation.
  • Select the aws-network-repair-lab stack.
  • Choose Delete.
  • Confirm with Delete.
  • Set Filter status to Deleted.
  • Confirm that aws-network-repair-lab shows DELETE_COMPLETE.

That clears the VPC, subnet, internet gateway, route table, security group, and web server created by the stack.

Review the template-upload storage

Shared Storage Needs Care

CloudFormation can reuse one template-upload bucket for multiple stacks in the same Region. Keep the bucket while you plan to redeploy this lab.

  • Open Amazon S3 in the AWS Management Console.
  • Locate the CloudFormation template-upload bucket associated with US East (N. Virginia).
  • Review its objects to confirm whether it contains the uploaded infrastructure.yaml template.
  • Keep the upload storage available for the next deployment.

Your live AWS resources are now paused through deletion. The local repository remains ready to recreate them.

Delete - I don't want to use this again

Remove the live AWS resources and the local repository. Keep the public GitHub repository as the permanent record of your work.

Check Each Resource First

Cloud cleanup is permanent. The public repository still contains the repaired template if you decide to rebuild the lab.

Delete the Reachability Analyzer path
  • Return to the AWS Management Console.
  • Open Reachability Analyzer in Network Manager.
  • Select the path whose source is the stack internet gateway.
  • Confirm that the destination is the EC2 instance.
  • Confirm that the protocol is TCP with destination port 80.
  • Choose Actions.
  • Choose Delete path.
  • Confirm with Delete path.

The Reachability Analyzer path and its stored analyses are now removed.

Delete the CloudFormation stack
  • Return to CloudFormation.
  • Select the aws-network-repair-lab stack.
  • Choose Delete.
  • Confirm with Delete.
  • Set Filter status to Deleted.
  • Confirm that aws-network-repair-lab shows DELETE_COMPLETE.

The main sources of ongoing lab charges are now removed.

Review the template-upload storage

Protect Shared Templates

The template-upload bucket may contain objects used by other CloudFormation stacks. Verify ownership before deleting any object or bucket.

  • Open Amazon S3 in the AWS Management Console.
  • Locate the CloudFormation template-upload bucket associated with US East (N. Virginia).
  • Identify the uploaded template object that belongs to infrastructure.yaml.
  • Confirm that no active deployment needs that object.
  • Delete the lab's template object.
  • Confirm that the bucket is dedicated to this lab before removing the bucket itself.
  • Delete the bucket only when it contains no shared objects.
Delete the local repository

Your public repository already preserves the final template and evidence. Removing the local folder frees the copy stored on your Windows device.

  • Close Visual Studio Code.
  • Close GitHub Desktop.
  • Press the Windows logo key to open Windows search.
  • Type File Explorer.
  • Press Enter.
  • Search for the aws-network-repair-lab folder.
  • Select the local repository folder.
  • Delete the selected folder.
  • Confirm that File Explorer no longer lists the folder in its original location.

Cleanup is complete. Your public repository still holds the repaired infrastructure, documentation, four evidence images, and pull request.

Nice Work!

Nice Work!

Mission accomplished! Your public portfolio now shows a deliberately broken AWS web stack progressing from failed HTTP access to a code-based repair with before-and-after evidence.

What you learned:

  • Built a browser-accessible web environment with AWS CloudFormation as infrastructure as code. Your repaired infrastructure.yaml can reproduce the complete network.
  • Used Amazon VPC Reachability Analyzer to trace the failed TCP port 80 path to the security group. Your paired results prove that the declared fix restored reachability.
  • Published a public GitHub repository with a rendered Mermaid architecture diagram. Its four evidence images tell the complete troubleshooting story.
  • Secret Mission: Created a feature branch for LESSONS.md. Opened a pull request without altering infrastructure.yaml.

Ready to quiz yourself?