High Availability Architecture

  • Classic Load Balancer
    • Launch two EC2 instances in different availability zones
      • Use bootstrap scripts
    • View web pages from the public internet
    • Create Classic Load Balancer
      • Advanced Details
        • Response Timeout: 2 seconds
        • Interval: 5 seconds
        • Unhealthy Threshold: 2
        • Healthy Threshold: 3
    • View the DNS name
    • Verify EC2 instances are InService
    • Browse load balancer DNS name from web browser
      • Refresh multiple times
    • Power off web server 01
    • Verify web server 01 is OutOfService
    • Verify load balancer only distributing traffic to web server 02
    • Power on web server 01
    • Delete classic load balancer
  • Target Group
    • Create Target Group
      • Health Check Path: /index.html
      • Healthy Threshold: 2
      • Unhealthy Threshold: 3
      • Timeout: 5
      • Interval: 2
    • Add targets
  • Application Load Balancer
    • Create applicaiton load balancer
      • Select all availability zones
    • Verify targets are in healthy state
    • Review load balancer listeners
    • “Edit” load balancer listeners
    • Test the application load balancer
      • Refresh multiple times
  • Launch Configuration
    • Create a launch configuration
      • Associate with IAM role
      • Use bootstrap script
  • Auto Scaling Group
    • Create Auto Scaling group
      • Group Size: 3
      • Subnet: select all available
      • Use scaling policies to adjust the capacity of this group
        • Scale between 3 and 6 instances
        • Metric type: CPU Utilization
        • Target value: 80
        • Instances need: 60
      • View activity history
      • View instances
      • Terminate two EC2 instances
      • Verify two EC2 instances are launched
      • View activity history
      • Delete the auto scaling group
  • High Availability Website
    • Create two S3 buckets
    • Create CloudFront Distribution (media)
    • Create security group for RDS
    • Provision RDS instance
      • Engine Options: MySQL
      • Templates: Dev/Test
      • DB Instance Size: db.t2.micro
      • Availability & Durability: Multi-AZ Deployment
      • Monitoring: Disable Enhanced Monitoring
    • Verify role for EC2 instance S3 access
    • Provision EC2 Instance
      • Assign role
      • Use bootstrap script
    • Verify .htaccess file is created
    • Install WordPress
      • Publish post with image
      • View image on EC2 instance
    • Verify EC2 Instance can view buckets
    • Copy image to S3 bucket (aws s3 cp –recursive /var/www/html/wp-content/uploads s3://bucket)
    • Copy website to bucket (aws s3 cp –recursive /var/www/html s3://bucket)
    • View WordPress code in S3 bucket from CLI
    • Update .htaccess with CloudFront URL
    • Sync /var/www/html to S3 bucket (aws s3 sync /var/www/html s3://bucket)
    • Configure Apache URL rewrites (/etc/httpd/conf/httpd.conf)
    • Configure Bucket Policy for media bucket
    • View WordPress site from internet
    • Verify URL rewrite of image
    • Create application load balancer
      • Create new target group
        • Register EC2 instance to target group
    • Verify application load balancer is in active state
    • Register EC2 instance in target group
    • Configure Route 53 Alias record
    • View website using domain name
    • Configure cronjob for syncing readers (*/1 * * * * root aws s3 sync –delete s3://bucket /var/www/html)
    • Restart cron service
    • Test the cronjob
    • Create AMI for read node
    • Configure write node (*/1 * * * * root aws s3 sync –delete /var/www/html s3://bucket & */1 * * * * root aws s3 sync –delete /var/www/html/wp-content/uploads s3://bucket)
    • Test the write node
    • Create auto scaling group
      • Create new launch configuration
        • Select WordPress read AMI
        • Apply IAM S3 role
        • Apply bootstrap script
      • Create auto scaling group
        • Start with two instances
        • Select all availability zones
        • Receive traffic from one or more load balancers
          • Target group
        • ELB health check
        • Health Check Grace Period: 60
    • Remove write node from target group
    • Verify two instances are launching
    • Verify target group targets are healthy
    • View domain
    • Login to WordPress dashboard
    • Add new post
    • Test loss of AZ
    • Reboot RDS instance with failover
    • Verify website is still accessible
    • Delete all AWS resources