Tools
Tools: Deploying a Highly Available AWS Application with Bastion Access, Transit Gateway, and Auto Scaling.
2026-01-19
0 views
admin
Introduction ## Architecture Overview ## What We Are Deploying ## Prerequisites ## Step 1: Create the VPCs ## Bastion VPC ## Application VPC ## Step 2: Create Subnets ## Bastion VPC ## Application VPC ## Step 3: Internet Gateways ## Step 4: NAT Gateway ## Step 5: Transit Gateway ## Step 6: Security Groups ## Bastion Security Group ## Application Security Group ## Step 7: Bastion Host ## Step 8: Create a Golden AMI ## Instance Setup ## Step 9: CloudWatch Logs and VPC Flow Logs ## Step 10: IAM Role for EC2 ## Step 11: S3 Bucket for App Configuration ## Step 12: Launch Configuration ## User Data ## Step 13: Auto Scaling Group ## Step 14: Target Group ## Step 15: Network Load Balancer ## Step 16: Route53 DNS ## Step 17: Validation ## Expected Results ## Final Thoughts In this project, I built a secure, highly available AWS architecture that mirrors real-world production environments.
The goal was to practice network segmentation, private connectivity, high availability, and observability using native AWS services. By the end of this guide, you will understand how to deploy: Before starting, ensure you have the following in place: We start by isolating responsibilities using two VPCs. This separation ensures administrative access is decoupled from the application environment. Private subnets across multiple AZs provide high availability. Each VPC requires an Internet Gateway for public connectivity. Update public route tables: Private instances still need outbound internet access. Update private route tables: To enable private VPC-to-VPC communication, we introduce a Transit Gateway. Update route tables in both VPCs: This eliminates the need for VPC peering and scales better. This enforces least-privilege network access. Instance type: t3.micro This host becomes the only SSH entry point into the environment. We build a reusable image for consistency and scaling. Installed components: Stop the instance and create an AMI named golden-ami. Observability is critical in production systems. Create an IAM role with: This enables secure instance management without SSH keys. Use the Golden AMI and configure: This ensures fault tolerance and scalability. Confirm everything works as expected: This project helped me deeply understand: Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse COMMAND_BLOCK:
sudo apt update -y
sudo apt install apache2 git awscli amazon-cloudwatch-agent -y
sudo systemctl start apache2
sudo systemctl enable apache2 Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK:
sudo apt update -y
sudo apt install apache2 git awscli amazon-cloudwatch-agent -y
sudo systemctl start apache2
sudo systemctl enable apache2 COMMAND_BLOCK:
sudo apt update -y
sudo apt install apache2 git awscli amazon-cloudwatch-agent -y
sudo systemctl start apache2
sudo systemctl enable apache2 COMMAND_BLOCK:
#!/bin/bash
sudo apt install git -y
git clone <repo-url> /var/www/html
systemctl restart apache2 Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK:
#!/bin/bash
sudo apt install git -y
git clone <repo-url> /var/www/html
systemctl restart apache2 COMMAND_BLOCK:
#!/bin/bash
sudo apt install git -y
git clone <repo-url> /var/www/html
systemctl restart apache2 - A bastion-managed environment
- A private, auto-scaled application layer
- Secure VPC-to-VPC communication using a Transit Gateway
- End-to-end logging and DNS routing - Two VPCs with isolated responsibilities
- Transit Gateway for private communication
- Public and private subnets across multiple AZs
- Bastion host for secure access
- Auto Scaling Group behind a Network Load Balancer
- Centralized logging and DNS routing - VPC-A (Bastion / Management): Secure administrative access
- VPC-B (Application): Highly available, private application layer - AWS account
- IAM user with administrator access
- AWS CLI installed and configured
- EC2 key pair created
- A registered domain managed in Route53 - CIDR: 192.168.0.0/16
- Name: bastion-vpc - CIDR: 172.32.0.0/16
- Name: app-vpc - Create an IGW for both VPCs
- Attach each IGW to its respective VPC
- Update public route tables: 0.0.0.0/0 → Internet Gateway
- 0.0.0.0/0 → Internet Gateway - 0.0.0.0/0 → Internet Gateway - Allocate an Elastic IP
- Create a NAT Gateway in the public subnet of the Application VPC
- Update private route tables: 0.0.0.0/0 → NAT Gateway
- 0.0.0.0/0 → NAT Gateway - 0.0.0.0/0 → NAT Gateway - Create a Transit Gateway
- Attach: Bastion VPC
Application VPC
- Bastion VPC
- Application VPC
- Update route tables in both VPCs: Destination: Other VPC CIDR
Target: Transit Gateway
- Destination: Other VPC CIDR
- Target: Transit Gateway - Bastion VPC
- Application VPC - Destination: Other VPC CIDR
- Target: Transit Gateway - Allow SSH (22) from your IP
- Outbound: All traffic - Allow SSH (22) from Bastion SG
- Allow HTTP (80) from Load Balancer
- Outbound: All traffic - Launch EC2 in the Bastion VPC public subnet
- Attach: Bastion security group
Elastic IP
- Bastion security group
- Instance type: t3.micro - Bastion security group - CloudWatch Agent - Create CloudWatch Log Group:
/vpc/flowlogs
- Enable VPC Flow Logs for both VPCs
- Destination: CloudWatch
- Separate log streams per VPC - Trusted entity: EC2
- Policies: AmazonSSMManagedInstanceCore
Custom S3 read-only policy (restricted bucket access)
- AmazonSSMManagedInstanceCore
- Custom S3 read-only policy (restricted bucket access) - AmazonSSMManagedInstanceCore
- Custom S3 read-only policy (restricted bucket access) - Create an S3 bucket
- Enable encryption
- Block public access
- Store application configuration files - Instance type: t3.micro
- Security group: Application SG
- IAM role attached - Subnets: Private subnet (us-east-1a)
Private subnet (us-east-1b)
- Private subnet (us-east-1a)
- Private subnet (us-east-1b) - Private subnet (us-east-1a)
- Private subnet (us-east-1b) - Target type: Instance
- Protocol: TCP
- Health checks enabled - Internet-facing
- Subnets: Public subnets
- Listener: TCP :80
- Forward traffic to ASG target group - Type: CNAME
- Name: app.example.com
- Value: NLB DNS name - SSH into Bastion Host
- SSH into private EC2 via Bastion
- Access EC2 via Session Manager
- Open browser:
http://app.example.com - Application loads successfully
- Auto Scaling responds to traffic
- Logs visible in CloudWatch - Secure AWS network design
- Transit Gateway vs VPC peering
- Bastion-based access patterns
- Auto scaling in private subnets
- Observability and production readiness
how-totutorialguidedev.toaimlbashnetworkdnsroutingsubnetapachegit