rabbii96/devops-project-02

1. This repository is centered on an AWS “modular and scalable VPC” deployment. The README describes the target system as two VPCs connected for both administrative access and private application traffic: one VPC for a bastion host and one VPC for the application tier.

2. The VPC Architecture/ folder holds the AWS-side support artifacts for that environment. Based on the filenames, it contains JSON definitions for VPC Flow Logs, CloudWatch memory metrics, and an S3 bucket policy, plus a script.sh helper for setup or validation. These files are infrastructure inputs rather than application code.

3. The network boundary is split into two CIDR ranges:

- 192.168.0.0/16 for the bastion/admin VPC

- 172.32.0.0/16 for the application VPC

Each VPC has its own Internet Gateway, and the app VPC also uses a NAT Gateway so private instances can reach the internet for updates and bootstrap tasks without being publicly exposed.

4. The two VPCs are linked through a Transit Gateway, which is the private routing backbone of the design. That lets the bastion network reach private application instances while keeping the app subnet private and segregated from direct inbound internet access.

5. The operational access path is the bastion host in the public subnet. It is assigned an Elastic IP and protected by a security group that allows SSH from the public internet. From there, engineers can SSH into private instances in the app VPC. The README also calls out AWS Session Manager as an alternate shell access path, so the IAM role on instances is part of the management plane.

6. Observability is a first-class subsystem. Both VPCs send Flow Logs to CloudWatch Logs, using a dedicated log group with separate streams for each VPC. In addition, the pre-deployment steps require the CloudWatch Agent and custom memory metrics on the golden AMI, so instance-level telemetry is expected alongside network-level telemetry.

7. The application compute tier is designed as a highly available Auto Scaling Group spanning two private subnets across two availability zones. Instances are launched from a Golden AMI with a Launch Configuration, and the bootstrap flow pulls application code from Bitbucket and starts the web server. That makes the app tier ephemeral and rebuildable.

8. The ingress path for end users is: Route 53 CNAME → Network Load Balancer in public subnets → Target Group → Auto Scaling Group instances in private subnets. The NLB is the public entry point, while the application instances remain private behind it.

9. Configuration and secrets-like app inputs are separated from the AMI by using S3. The README explicitly says the instance role should have scoped access to a dedicated S3 bucket for application configuration, not broad S3 permissions. That keeps bootstrap configuration externalized and permission boundaries tight.

10. The html-web-app/ directory is the sample workload that gets deployed onto the EC2 web servers. It contains a simple HTML/CSS/JS site, images, error/ok pages, and web server descriptors (WEB-INF/web.xml). It also includes a Dockerfile and nginx.conf, which suggests the app can be packaged either as a traditional web artifact or containerized, even though the README’s main deployment path is EC2-based Apache.

11. podmanager/ is a separate Helm chart, with Kubernetes deployment and service templates plus default values. The repository README does not describe this path, so it appears to be an additional packaging/deployment option rather than part of the primary VPC architecture described in the document.

12. Jenkinsfile indicates there is CI/CD automation in the repo, likely for building or publishing the app and/or infrastructure artifacts. Even without the file contents, it is an important boundary because it suggests the environment is meant to be reproducible rather than assembled manually every time.

13. For an architecture diagram, the main flow to capture is: engineers access through bastion or Session Manager; app instances live in private subnets; outbound-only internet access goes through NAT; inbound user traffic goes through NLB and Route 53; network and instance telemetry go to CloudWatch; and the whole design is bridged by a Transit Gateway between the two VPCs.