Skip to content

Scalable AWS VPC Architecture

Level:Intermediate
Time:30-60 min
Cost:medium
Works locally:No
Cloud creds:Yes
Cleanup:No
Reviewed:2026-05-30
Validation:test -f README.md

Architecture lab with sample policies and scripts.

Outcome Architecture notes plus validation output
Tools used HTML, Linux Scripts, VPC design, AWS
Best fit Intermediate - 30-60 min
Student workstation Repository files Lab steps AWS account Validation proof
  • Install or review: HTML, Linux Scripts, VPC design, AWS.
  • Use your own cloud account credentials and keep them out of commits.
  • This project expects cloud resources, so verify budget alerts and cleanup first.
  • Open the safety guide before running commands that create infrastructure.
Cost and credential stance

Cost risk is medium. Cloud target: AWS. Cloud credentials needed: Yes. Always use your own account, never commit secrets, and confirm cleanup before creating paid infrastructure.

Use this flow before you run commands:

  1. Read the cost and credential warning above.
  2. Review the validation, troubleshooting, cleanup, and portfolio proof sections below.
  3. Follow the original project guide preserved near the bottom of this page.
  4. Return to the validation and cleanup checks before you capture portfolio evidence.

Run the project validation command before and after meaningful changes:

Terminal window
test -f README.md
  • Run test -f README.md first so local tooling issues are visible early.
  • If a command fails, check tool versions, working directory, and required environment variables.
  • For cloud failures, confirm account identity, region, quotas, and least-privilege IAM.

No dedicated cleanup command was detected in the project README. Treat this as a warning: before provisioning anything, write down the exact delete, destroy, or rollback steps for your environment.

  • Validation command output: test -f README.md
  • Screenshot or terminal proof: Architecture notes plus validation output
  • Notes explaining what changed, what failed, and how you fixed it
  • Cleanup evidence, especially for cloud or Kubernetes resources

The original README content is preserved here for lab-specific commands and context. Headings are intentionally demoted so the page outline stays focused on the standard lab flow.

  1. Goal
  2. Pre-Requisites
  3. Pre-Deployment
  4. VPC Deployment
  5. Validation

Deploy a Modular and Scalable Virtual Network Architecture with Amazon VPC.

🛡️ 2026 DevSecOps Enhancements (What You Will Learn)
Section titled “🛡️ 2026 DevSecOps Enhancements (What You Will Learn)”

This project architecture has been updated to model 2026 best practices for Cloud engineers. Pay special attention to:

  1. Network Segmentation via Transit Gateway: Learning to isolate internet-facing Bastion VPCs from completely private application VPCs.
  2. S3 Block Public Access: How we configured the S3 configurations to actively deny public ACLs and force-encrypt application configuration objects.
  3. Session Manager (SSM) over SSH: Why we utilize AWS Systems Manager (AmazonSSMManagedInstanceCore in the IAM role) to completely eliminate public port 22 exposure on modern private nodes.
  1. You must be having an AWS account to create infrastructure resources on AWS cloud.
  2. Source Code

Customize the application dependencies mentioned below on AWS EC2 instance and create the Golden AMI.

  1. AWS CLI
  2. Install Apache Web Server
  3. Install Git
  4. Cloudwatch Agent
  5. Push custom memory metrics to Cloudwatch.
  6. AWS SSM Agent
  1. Build VPC network ( 192.168.0.0/16 ) for Bastion Host deployment as per the architecture shown above.
  2. Build VPC network ( 172.32.0.0/16 ) for deploying Highly Available and Auto Scalable application servers as per the architecture shown above.
  3. Create NAT Gateway in Public Subnet and update Private Subnet associated Route Table accordingly to route the default traffic to NAT for outbound internet connection.
  4. Create Transit Gateway and associate both VPCs to the Transit Gateway for private communication.
  5. Create internet gateway for each VPC and Public Subnet associated Route Table accordingly to route the default traffic to IGW for inbound/outbound internet connection.
  6. Create Cloudwatch Log Group with two Log Streams to store the VPC Flow Logs of both VPCs.
  7. Enable Flow Logs for both VPCs and push the Flow Logs to Cloudwatch Log Groups and store the logs in the respective Log Stream for each VPC.
  8. Create Security Group for bastion host allowing port 22 from public.
  9. Deploy Bastion Host EC2 instance in the Public Subnet with EIP associated.
  10. Create S3 Bucket to store application specific configuration.
  11. Create Launch Configuration with below configuration.
    1. Golden AMI
    2. Instance Type – t2.micro
    3. Userdata to pull the code from Bitbucket Repository to document root folder of webserver and start the httpd service.
    4. IAM Role granting access to Session Manager and to S3 bucket created in the previous step to pull the configuration. (Do not grant S3 Full Access)
    5. Security Group allowing port 22 from Bastion Host and Port 80 from Public.
    6. Key Pair
  12. Create Auto Scaling Group with Min: 2 Max: 4 with two Private Subnets associated to 1a and 1b zones.
  13. Create Target Group and associate it with ASG.
  14. Create Network Load balancer in Public Subnet and add Target Group as target.
  15. Update route53 hosted zone with CNAME record routing the traffic to NLB.
  1. As DevOps Engineer login to Private Instances via Bastion Host.
  2. Login to AWS Session Manager and access the EC2 shell from console.
  3. Browse web application from public internet browser using domain name and verify that page loaded.

If you are planning to use this repository for learning, please hit the star. Thanks!

DevCloud Ninjas

Use the guide first.

The full learning flow stays on this page. Open GitHub only when a step asks you to inspect code, fork the lab, or download source assets.