Building Production-Ready Multi-AZ EC2 Server Architecture: Part 2 - Deployment, Testing & Cleanup

Overview

In this second part of our comprehensive guide, we’ll complete the production-ready AWS architecture by setting up the Application Load Balancer, Auto Scaling Groups, comprehensive testing, and proper cleanup procedures. This builds upon the infrastructure foundation from Part 1.

Architecture Completion

Our complete production architecture will include:

• Application Load Balancer for traffic distribution
• Auto Scaling Groups for automatic instance management
• Comprehensive Testing and verification procedures
• Proper Cleanup to avoid unexpected charges
• Production Monitoring and optimization strategies

Step 5: Application Load Balancer - Traffic Distribution

Overview

Create an Application Load Balancer (ALB) that will be the internet-facing entry point for your web application. The ALB will distribute traffic across your EC2 instances and provide high availability.

What You’ll Create

• Application Load Balancer in public subnets
• Internet-facing load balancer
• HTTP listener on port 80
• Integration with target group

Step-by-Step Instructions

1. Navigate to Load Balancers

1. Go to EC2 service in AWS Console
2. Click Load Balancers in the left sidebar
3. Click Create Load Balancer

2. Choose Load Balancer Type

• Select Application Load Balancer
• Click Create

3. Basic Configuration

Fill in the following details:

Load Balancer Details:

• Load balancer name: my-app-alb
• Scheme: Internet-facing
• IP address type: IPv4

4. Network Mapping

Configure network settings:

VPC and Subnets:

• VPC: Select my-app-vpc from dropdown
• Mappings: Check both Availability Zones
• Subnet selection: For each AZ, select the public subnet (not private)
  • Look for subnets with names like my-app-vpc-public-subnet-1 and my-app-vpc-public-subnet-2
  • Important: Do NOT select private subnets for the load balancer

5. Security Groups

Configure security settings:

Security Group Selection:

• Security groups: Remove the default security group
• Add security group: Select my-app-alb-sg
• Remove: Click the X next to the default security group

6. Listeners and Routing

Configure the listener:

Listener Configuration:

• Protocol: HTTP
• Port: 80
• Default action: Forward to target group
• Target group: Select my-app-tg from dropdown

7. Create Load Balancer

1. Review all settings
2. Click Create load balancer
3. Wait for the load balancer to become active (2-3 minutes)

Load Balancer Configuration Summary

Load Balancer Name: my-app-alb
Scheme: Internet-facing
IP Address Type: IPv4
VPC: my-app-vpc
Subnets: 2 public subnets (one per AZ)
Security Groups: my-app-alb-sg
Listener: HTTP on port 80
Default Action: Forward to my-app-tg

Why These Settings?

Internet-facing vs Internal

• Internet-facing: Load balancer gets a public IP and can receive traffic from the internet
• Internal: Load balancer only receives traffic from within the VPC
• Our choice: Internet-facing because we want public access

Public Subnets Only

• Load balancers must be in public subnets to receive internet traffic
• Private subnets are for backend instances only
• Public subnets have direct internet access via Internet Gateway

Security Group

• ALB security group allows HTTP traffic from the internet
• EC2 security group only allows traffic from the ALB
• This creates a secure architecture

Load Balancer States

Provisioning States

• Provisioning: Load balancer is being created
• Active: Load balancer is ready to receive traffic
• Failed: Load balancer creation failed

What Happens During Provisioning?

1. AWS allocates public IP addresses
2. Security groups are applied
3. DNS name is generated
4. Health checks begin (once targets are registered)

DNS Name and Access

Load Balancer DNS Name

After creation, you’ll get a DNS name like:

my-app-alb-1234567890.us-east-1.elb.amazonaws.com

How to Access Your Application

1. Copy the DNS name from the load balancer details
2. Paste it into a web browser
3. You should see your web application (once instances are healthy)

Troubleshooting

Issue: Can’t find VPC in dropdown

Solutions:

• Ensure you’re in the correct AWS region
• Wait a few minutes after VPC creation
• Refresh the page

Issue: Can’t select public subnets

Solutions:

• Look for subnets with “public” in the name
• Ensure subnets are in the correct VPC
• Check that subnets have internet gateway routes

Issue: Target group not available

Solutions:

• Ensure target group was created in Step 4
• Check that target group is in the same VPC
• Verify target group name is exactly my-app-tg

Issue: Load balancer stuck in “Provisioning” state

Solutions:

• Wait 5-10 minutes (creation can take time)
• Check for any error messages in the console
• Verify all required resources exist

Issue: Can’t access load balancer DNS

Solutions:

• Wait for load balancer to be “Active”
• Check security group allows HTTP from 0.0.0.0/0
• Verify internet gateway is attached to VPC
• Ensure instances are healthy in target group

Cost Considerations

ALB Pricing

• Base cost: $0.0225/hour ($16/month)
• Data processing: ~$0.008 per GB processed
• LCU (Load Balancer Capacity Unit): Based on traffic patterns

Cost Optimization Tips

• Use for production workloads (not just testing)
• Monitor usage with CloudWatch
• Consider Network Load Balancer for high-performance needs
• Delete when not in use to avoid charges

Advanced Configuration Options

HTTPS Listener (Production)

• Add HTTPS listener on port 443
• Use AWS Certificate Manager for SSL certificates
• Redirect HTTP to HTTPS for security

Multiple Target Groups

• Path-based routing: Route different paths to different target groups
• Host-based routing: Route based on domain name
• Query string routing: Route based on query parameters

Access Logs

• Enable access logs for monitoring and debugging
• Store logs in S3 for analysis
• Use for security auditing

Verification Checklist

• Load balancer created with name my-app-alb
• Scheme set to Internet-facing
• VPC set to my-app-vpc
• Both public subnets selected (one per AZ)
• Security group set to my-app-alb-sg
• HTTP listener on port 80 configured
• Default action forwards to my-app-tg
• Load balancer state is “Active”
• DNS name is available

Important Notes

• Load balancers are highly available by default
• DNS name is automatically generated and stable
• Load balancer can handle traffic even if some instances are unhealthy
• Changes to load balancer configuration take effect immediately
• Load balancer automatically distributes traffic across healthy instances

Security Best Practices

• Use HTTPS in production (add HTTPS listener)
• Implement WAF for additional protection
• Monitor access logs for suspicious activity
• Regular security group reviews
• Use least privilege principle for security group rules

Step 6: Auto Scaling Group - Automatic Instance Management

Overview

Create an Auto Scaling Group (ASG) that will automatically launch and manage EC2 instances in your private subnets. The ASG will ensure high availability by maintaining a desired number of healthy instances and automatically replacing failed ones.

What You’ll Create

• Auto Scaling Group with launch template
• EC2 instances in private subnets
• Integration with load balancer target group
• Automatic instance management

Step-by-Step Instructions

1. Navigate to Auto Scaling Groups

1. Go to EC2 service in AWS Console
2. Click Auto Scaling Groups in the left sidebar
3. Click Create Auto Scaling group

2. Step 1: Choose Launch Template

Configure the launch template:

Auto Scaling Group Details:

• Auto Scaling group name: my-app-asg
• Launch template: Select my-app-template from dropdown
• Version: Latest (default)
• Click Next

3. Step 2: Choose Instance Launch Options

Configure network settings:

Network Configuration:

• VPC: Select my-app-vpc from dropdown
• Availability Zones and subnets:
  • Important: Select both private subnets (not public)
  • Look for subnets with names like my-app-vpc-private-subnet-1 and my-app-vpc-private-subnet-2
  • Why private subnets? Instances should not be directly accessible from the internet
• Click Next

4. Step 3: Configure Advanced Options

Configure load balancing and health checks:

Load Balancing:

• Load balancing: Choose “Attach to an existing load balancer”
• Attach to an existing load balancer: Choose from your load balancer target groups
• Target group: Select my-app-tg from dropdown

Health Checks:

• Health check type: Check both “EC2” and “ELB”
  • EC2: Checks if instance is running
  • ELB: Checks if instance is healthy in the target group
• Health check grace period: 300 seconds (5 minutes)
  • This gives instances time to start up and become healthy

Additional Options:

• Health check grace period: 300 seconds
• Default instance warmup: 300 seconds
• Click Next

5. Step 4: Configure Group Size and Scaling

Set capacity and scaling policies:

Group Size:

• Desired capacity: 2
• Minimum capacity: 2
• Maximum capacity: 4

Scaling Policies:

• Scaling policies: None (for simplicity)
• Instance scale-in protection: Disabled
• Click Next

6. Step 5: Add Notifications (Optional)

Skip notifications for now:

• Click Next without adding any notifications

7. Step 6: Add Tags (Optional)

Add tags for better organization:

Tags:

• Key: Name
• Value: my-app-instance
• Key: Environment
• Value: Production
• Click Next

8. Step 7: Review and Create

1. Review all settings carefully
2. Ensure private subnets are selected
3. Verify target group is attached
4. Click Create Auto Scaling group

Auto Scaling Group Configuration Summary

Auto Scaling Group Name: my-app-asg
Launch Template: my-app-template
VPC: my-app-vpc
Subnets: 2 private subnets (one per AZ)
Load Balancer: Attached to my-app-tg
Health Checks: EC2 + ELB
Desired Capacity: 2
Minimum Capacity: 2
Maximum Capacity: 4
Health Check Grace Period: 300 seconds

What Happens After Creation

Instance Launch Process

1. ASG launches 2 instances in private subnets
2. Instances run user data script to install Nginx
3. Instances register with target group automatically
4. Health checks begin after grace period
5. Instances become healthy and receive traffic

Timeline

• 0-2 minutes: Instances launching
• 2-5 minutes: User data script running
• 5-8 minutes: Health checks starting
• 8-10 minutes: Instances healthy and serving traffic

Auto Scaling Group Features

Automatic Instance Management

• Replaces failed instances automatically
• Maintains desired capacity at all times
• Distributes instances across availability zones
• Handles instance termination gracefully

Health Check Integration

• EC2 health checks: Monitor instance status
• ELB health checks: Monitor application health
• Automatic replacement of unhealthy instances
• Grace period for instance startup

Load Balancer Integration

• Automatic registration with target group
• Automatic deregistration when terminating
• Health check coordination between ASG and ELB
• Traffic distribution across healthy instances

Troubleshooting

Issue: Can’t find launch template

Solutions:

• Ensure launch template was created in Step 3
• Check you’re in the correct region
• Verify template name is exactly my-app-template

Issue: Can’t find private subnets

Solutions:

• Look for subnets with “private” in the name
• Ensure subnets are in the correct VPC
• Check that subnets have NAT gateway routes

Issue: Target group not available

Solutions:

• Ensure target group was created in Step 4
• Check that target group is in the same VPC
• Verify target group name is exactly my-app-tg

Issue: Instances not launching

Solutions:

• Check Auto Scaling Group activity history
• Verify launch template is valid
• Check IAM permissions
• Review security group settings

Issue: Instances not becoming healthy

Solutions:

• Check security group allows HTTP from ALB
• Verify user data script is working
• Check target group health check settings
• Review instance system logs

Monitoring and Management

Auto Scaling Group Activity

1. Go to Auto Scaling Groups
2. Select my-app-asg
3. Click Activity tab
4. Monitor instance launch and health check activities

Instance Status

1. Go to EC2 → Instances
2. Look for instances with names like my-app-instance
3. Check instance state and status checks

Target Group Health

1. Go to EC2 → Target Groups
2. Select my-app-tg
3. Click Targets tab
4. Monitor instance health status

Cost Considerations

Instance Costs

• t2.micro instances: Free Tier eligible (750 hours/month for first 12 months)
• 2 instances: ~$0.0116/hour each = ~$0.0232/hour total
• Monthly cost: ~$17/month for 2 instances

Auto Scaling Benefits

• Automatic scaling based on demand
• Cost optimization by scaling down during low usage
• High availability with multiple instances
• Automatic replacement of failed instances

Advanced Configuration Options

Scaling Policies (Future Enhancement)

• Target tracking: Scale based on CPU utilization
• Step scaling: Scale based on CloudWatch alarms
• Scheduled scaling: Scale based on time schedules
• Predictive scaling: Use machine learning for scaling

Instance Refresh

• Rolling updates: Update instances without downtime
• Health check integration: Ensure new instances are healthy
• Gradual replacement: Replace instances one at a time

Lifecycle Hooks

• Instance launch: Custom actions before instance becomes active
• Instance terminate: Custom actions before instance terminates
• Grace period: Time to complete custom actions

Verification Checklist

• Auto Scaling Group created with name my-app-asg
• Launch template my-app-template selected
• VPC set to my-app-vpc
• Both private subnets selected (one per AZ)
• Target group my-app-tg attached
• Health checks configured for EC2 + ELB
• Desired capacity set to 2
• Minimum capacity set to 2
• Maximum capacity set to 4
• Health check grace period set to 300 seconds

Important Notes

• Private subnets are crucial for security
• Health check grace period gives instances time to start
• Both EC2 and ELB health checks provide comprehensive monitoring
• Automatic instance management ensures high availability
• Load balancer integration provides seamless traffic distribution

Security Benefits

• Instances in private subnets are not directly accessible from internet
• Only load balancer can send traffic to instances
• Automatic instance replacement maintains security posture
• Health checks ensure only healthy instances receive traffic

Step 7: Verification and Testing - Comprehensive Validation

Overview

Verify that your Multi-AZ EC2 architecture is working correctly by checking instance health, target group status, and testing the web application through the load balancer.

What You’ll Verify

• EC2 instances are running and healthy
• Target group shows healthy instances
• Load balancer is distributing traffic
• Web application is accessible and working

Step-by-Step Verification

1. Check Auto Scaling Group Status

Navigate to Auto Scaling Groups

1. Go to EC2 service in AWS Console
2. Click Auto Scaling Groups in the left sidebar
3. Select my-app-asg

Verify ASG Status

• Desired capacity: 2
• Current capacity: 2
• Healthy capacity: 2
• Status: Should show “Active”

Check Activity History

1. Click Activity tab
2. Look for successful instance launches
3. Verify no failed activities

2. Check EC2 Instance Status

Navigate to Instances

1. Go to EC2 → Instances
2. Look for instances with names like my-app-instance

Verify Instance Status

For each instance, check:

• Instance state: Running
• Status check: 2/2 checks passed
• Subnet: Should be in private subnets
• Security group: Should show my-app-ec2-sg

Instance Details

• Instance type: t2.micro
• AMI: Amazon Linux 2023
• Key pair: Your selected key pair
• VPC: my-app-vpc

3. Check Target Group Health

Navigate to Target Groups

1. Go to EC2 → Target Groups
2. Select my-app-tg
3. Click Targets tab

Verify Target Health

• Targets: Should show 2 instances
• Status: Both should show “Healthy”
• Health check: Should show “Healthy”
• Port: 80
• Protocol: HTTP

Health Check Details

• Health check path: /
• Health check protocol: HTTP
• Healthy threshold: 5
• Unhealthy threshold: 2

4. Check Load Balancer Status

Navigate to Load Balancers

1. Go to EC2 → Load Balancers
2. Select my-app-alb

Verify Load Balancer Status

• State: Active
• Scheme: Internet-facing
• VPC: my-app-vpc
• Subnets: 2 public subnets

Check Listeners

• Protocol: HTTP
• Port: 80
• Default action: Forward to my-app-tg

5. Test the Web Application

Get Load Balancer DNS Name

1. In the load balancer details, copy the DNS name
2. It should look like: my-app-alb-1234567890.us-east-1.elb.amazonaws.com

Test in Web Browser

1. Open a web browser
2. Paste the DNS name in the address bar
3. Press Enter

Expected Results

• Page loads successfully
• Shows message: “Hello from Web Server with IP: [Private IP]”
• IP address: Should be a private IP (e.g., 10.0.x.x)

Test Load Balancing

1. Refresh the page multiple times
2. Notice the IP address may change
3. This shows load balancer is distributing traffic

6. Advanced Testing

Test High Availability

1. Terminate one instance in the EC2 console
2. Wait 2-3 minutes
3. Check Auto Scaling Group activity
4. Verify new instance is launched
5. Test web application still works

Test Health Checks

1. Stop Nginx on one instance (via SSH)
2. Wait for health checks to fail
3. Verify instance becomes unhealthy
4. Check load balancer stops sending traffic to it

Troubleshooting Common Issues

Issue: Instances Not Launching

Symptoms

• Auto Scaling Group shows 0 current capacity
• Activity history shows failed launches

Solutions

1. Check launch template:

   • Verify template is valid
   • Check AMI availability
   • Verify key pair exists

2. Check IAM permissions:

   • Ensure Auto Scaling service has necessary permissions
   • Check EC2 instance profile

3. Check subnet availability:

   • Verify private subnets exist
   • Check subnet has available IP addresses

Issue: Instances Not Becoming Healthy

Symptoms

• Instances are running but target group shows unhealthy
• Health checks are failing

Solutions

1. Check security groups:

   • Verify my-app-ec2-sg allows HTTP from my-app-alb-sg
   • Check outbound rules allow responses

2. Check user data script:

   • Verify Nginx is installed and running
   • Check if custom HTML page was created
   • Review instance system logs

3. Check target group settings:

   • Verify health check path is correct (/)
   • Check health check protocol (HTTP)
   • Verify port 80 is correct

Issue: Cannot Access Load Balancer

Symptoms

• Browser shows connection error
• DNS name doesn’t resolve

Solutions

1. Check load balancer state:

   • Verify it’s “Active”
   • Wait for provisioning to complete

2. Check security groups:

   • Verify my-app-alb-sg allows HTTP from 0.0.0.0/0
   • Check outbound rules

3. Check VPC configuration:

   • Verify internet gateway is attached
   • Check route tables for public subnets

Issue: Load Balancer Not Distributing Traffic

Symptoms

• Always shows same IP address
• Only one instance receives traffic

Solutions

1. Check target group:

   • Verify multiple instances are healthy
   • Check load balancing algorithm

2. Check instance health:

   • Ensure all instances are healthy
   • Verify all instances are in target group

Performance Testing

Basic Load Test

1. Open multiple browser tabs
2. Refresh pages simultaneously
3. Monitor target group health
4. Check instance CPU usage

Stress Test (Optional)

1. Use tools like Apache Bench or curl
2. Send multiple concurrent requests
3. Monitor Auto Scaling Group activity
4. Check if instances scale up

Monitoring and Alerts

CloudWatch Metrics

1. Go to CloudWatch in AWS Console

2. Check EC2 metrics:

   • CPU utilization
   • Network in/out
   • Status check failed

3. Check ELB metrics:

   • Request count
   • Target response time
   • Healthy host count

Set Up Alarms (Optional)

1. Create CloudWatch alarms for:

   • High CPU utilization
   • Unhealthy instances
   • High response time

2. Configure SNS notifications for alerts

Verification Checklist

Infrastructure

• Auto Scaling Group shows 2 current capacity
• 2 EC2 instances are running
• Instances are in private subnets
• Instances have correct security group
• Target group shows 2 healthy targets
• Load balancer is in “Active” state
• Load balancer is in public subnets

Application

• Web application loads successfully
• Shows custom message with instance IP
• Load balancer distributes traffic (IP changes)
• Application responds quickly
• No error messages in browser

High Availability

• Multiple instances are healthy
• Traffic is distributed across instances
• Auto Scaling Group maintains desired capacity
• Health checks are working properly

Production Enhancements

1. Add HTTPS support with SSL certificates
2. Implement auto scaling policies based on CPU/memory
3. Set up monitoring and alerting
4. Add custom domain with Route 53
5. Implement backup and disaster recovery

Cost Optimization

1. Monitor usage patterns
2. Implement scheduled scaling
3. Use Spot instances for non-critical workloads
4. Set up cost alerts

Step 8: Cleanup - Resource Management and Cost Control

Overview

This guide provides step-by-step instructions for cleaning up all AWS resources created during the Multi-AZ EC2 deployment to avoid ongoing charges.

Important Notes

• Cleanup is crucial to avoid unexpected charges
• NAT Gateways cost ~$65/month for 2 gateways
• Load Balancer costs ~$16/month
• EC2 instances cost ~$17/month for 2 instances
• Total potential savings: ~$98/month

Cleanup Order

Resources must be deleted in a specific order due to dependencies:

1. Auto Scaling Group (terminates instances)
2. Load Balancer (removes traffic routing)
3. Target Group (removes health checks)
4. Launch Template (removes instance blueprint)
5. Security Groups (removes firewall rules)
6. VPC (removes all network resources)

Step-by-Step Cleanup

1. Terminate Auto Scaling Group

Navigate to Auto Scaling Groups

1. Go to EC2 service in AWS Console
2. Click Auto Scaling Groups in the left sidebar
3. Select my-app-asg

Set Capacity to Zero

1. Click Edit button
2. Desired capacity: Change to 0
3. Minimum capacity: Change to 0
4. Maximum capacity: Change to 0
5. Click Update

Wait for Instances to Terminate

1. Go to Activity tab
2. Wait for instances to terminate (2-3 minutes)
3. Verify Current capacity shows 0

Delete Auto Scaling Group

1. Select my-app-asg
2. Click Delete button
3. Type delete to confirm
4. Click Delete

2. Delete Load Balancer

Navigate to Load Balancers

1. Go to EC2 → Load Balancers
2. Select my-app-alb

Delete Load Balancer

1. Click Delete button
2. Type the load balancer name to confirm
3. Click Delete
4. Wait for deletion to complete (2-3 minutes)

3. Delete Target Group

Navigate to Target Groups

1. Go to EC2 → Target Groups
2. Select my-app-tg

Delete Target Group

1. Click Delete button
2. Type the target group name to confirm
3. Click Delete

4. Delete Launch Template

Navigate to Launch Templates

1. Go to EC2 → Launch Templates
2. Select my-app-template

Delete Launch Template

1. Click Delete button
2. Type the template name to confirm
3. Click Delete

5. Delete Security Groups

Navigate to Security Groups

1. Go to EC2 → Security Groups
2. Select my-app-ec2-sg

Delete EC2 Security Group

1. Click Delete button
2. Type the security group name to confirm
3. Click Delete

Delete ALB Security Group

1. Select my-app-alb-sg
2. Click Delete button
3. Type the security group name to confirm
4. Click Delete

6. Delete VPC

Navigate to VPCs

1. Go to VPC service in AWS Console
2. Select my-app-vpc

Delete NAT Gateways and Elastic IPs

1. Go to VPC service in AWS Console

2. Click NAT Gateways in the left sidebar

3. Select my-app-nat-gateway-1 and my-app-nat-gateway-2

4. Click Delete button

5. Type the NAT gateway name to confirm

6. Click Delete

7. Go to EC2 service in AWS Console

8. Click Elastic IPs in the left sidebar

9. Select my-app-nat-gateway-1-eip and my-app-nat-gateway-2-eip

10. Click Release button

Delete VPC

1. Click Delete VPC button
2. Type the VPC name to confirm
3. Click Delete

Note: This will automatically delete:

• All subnets (public and private)
• NAT gateways
• Internet gateway
• Route tables
• Network ACLs

Verification of Cleanup

Check All Resources Are Deleted

1. EC2 Instances: Should show 0 instances
2. Auto Scaling Groups: Should show 0 groups
3. Load Balancers: Should show 0 load balancers
4. Target Groups: Should show 0 target groups
5. Launch Templates: Should show 0 templates
6. Security Groups: Should only show default groups
7. VPCs: Should only show default VPC

Check Billing

1. Go to AWS Billing console
2. Check Current month charges
3. Verify no unexpected charges

Troubleshooting Cleanup Issues

Issue: Cannot Delete Auto Scaling Group

Solutions:

• Ensure desired capacity is set to 0
• Wait for all instances to terminate
• Check for any scaling policies that need to be deleted

Issue: Cannot Delete Load Balancer

Solutions:

• Ensure target group is deleted first
• Check for any listeners that need to be removed
• Wait for load balancer to be in “Active” state

Issue: Cannot Delete Security Group

Solutions:

• Ensure no resources are using the security group
• Check for any network interfaces attached
• Verify all instances are terminated

Issue: Cannot Delete VPC

Solutions:

• Ensure all subnets are empty
• Check for any network interfaces
• Verify all gateways are detached
• Check for any VPC endpoints

Cost Monitoring

Set Up Billing Alerts

1. Go to AWS Billing console
2. Click Billing preferences
3. Enable Receive Billing Alerts
4. Set up CloudWatch billing alarms

Monitor Usage

1. Check AWS Cost Explorer
2. Review Monthly charges
3. Set up Budget alerts

Alternative: Stop Instead of Delete

For Temporary Shutdown

If you want to keep the architecture but stop charges:

1. Set Auto Scaling Group capacity to 0
2. Keep other resources (VPC, security groups, etc.)
3. Restart later by setting capacity back to 2

Cost Comparison

• Full cleanup: $0/month
• Temporary shutdown: ~$16/month (NAT gateways + load balancer)
• Running: ~$98/month (all resources)

Best Practices

Regular Cleanup

• Clean up test environments immediately
• Set up automated cleanup for temporary resources
• Use AWS Config to track resource changes
• Implement tagging for better resource management

Cost Optimization

• Use AWS Cost Explorer to analyze spending
• Set up budgets and alerts
• Review unused resources regularly
• Use AWS Trusted Advisor for recommendations

Verification Checklist

• Auto Scaling Group deleted
• Load Balancer deleted
• Target Group deleted
• Launch Template deleted
• Security Groups deleted
• VPC deleted
• No unexpected charges in billing
• All resources removed from console

Production Best Practices

Security Considerations

1. Network Segmentation: Use private subnets for application instances
2. Least Privilege: Security groups with minimal required access
3. Encryption: Enable encryption for sensitive data
4. Monitoring: Implement CloudWatch monitoring and alerting
5. WAF Integration: Add AWS WAF for additional protection
6. Regular Security Reviews: Audit security groups and access patterns

Cost Optimization

1. Free Tier Usage: Leverage t2.micro instances and Free Tier limits
2. NAT Gateway Optimization: Consider single NAT gateway for testing
3. Resource Tagging: Implement consistent tagging strategy
4. Monitoring: Set up billing alerts and cost monitoring
5. Auto Scaling Policies: Implement CPU and memory-based scaling
6. Spot Instances: Use Spot instances for non-critical workloads

High Availability

1. Multi-AZ Deployment: Distribute resources across availability zones
2. Health Checks: Implement comprehensive health monitoring
3. Auto Scaling: Prepare for automatic scaling capabilities
4. Backup Strategy: Plan for data backup and recovery
5. Disaster Recovery: Implement cross-region backup strategies
6. Monitoring: Set up comprehensive monitoring and alerting

Performance Optimization

1. Load Testing: Regular performance testing and optimization
2. Caching: Implement CloudFront for static content
3. Database Optimization: Use RDS for database workloads
4. CDN Integration: Leverage AWS CloudFront for global distribution
5. Monitoring: Implement detailed performance monitoring

Conclusion

You’ve successfully completed a production-ready, highly available web server architecture with:

✅ Application Load Balancer for traffic distribution and high availability ✅ Auto Scaling Groups for automatic instance management ✅ Comprehensive Testing and verification procedures ✅ Proper Cleanup to avoid unexpected charges ✅ Production Best Practices for security, cost, and performance

Architecture Summary

This complete architecture provides:

• High Availability: 2 instances across 2 availability zones
• Auto Scaling: Automatic instance management and replacement
• Load Balancing: Even traffic distribution across instances
• Security: Private subnets with controlled access
• Monitoring: Health checks and status monitoring
• Cost Effective: Free Tier eligible components with proper cleanup

Next Steps

1. Production Deployment: Implement HTTPS, custom domains, and monitoring
2. Advanced Features: Add auto scaling policies, CloudWatch alarms, and WAF
3. Infrastructure as Code: Use CloudFormation or Terraform for repeatable deployments
4. Monitoring and Alerting: Set up comprehensive monitoring and alerting
5. Security Hardening: Implement additional security measures and compliance

This architecture provides a solid foundation for deploying real-world web applications on AWS, following AWS Well-Architected Framework principles and industry best practices.

Remember to always clean up resources when you’re done testing to avoid unexpected charges!