In this module, we will apply the skills we have learned thus far to select and combine AWS services together to create a highly available web site. First, we will create a strawman design based on the requirements we are given. Then we will implement the solution design in the AWS console setting up the services we have selected. Then we will review our solution architecture looking for possible improvements and optimizations, aiming to create the most operationally excellent architecture possible.
- [Instructor] Okay, welcome back. Let's get into our implementation. I've created a user called s3_user with full access to S3 and some access keys so I can access S3 from my local computer. I also created an IAM role with full conditions for S3 and CloudWatch. So, let's start by creating the database. I will create a MySQL database instance with Multi-AZ to store our data. Now we need to configure the information about our database. Let's provision a simple T micro instance with five gigabytes of storage. We'll identify this DB and create the credentials for it. We can then select the default subnet group and assign a security group for this database instance. We'll come back to security groups when we need to harden our environment. For now we're going to start with a wide open policy. The database name will be WordPress. We will stick with the default settings for the rest of the fields. Now, we are ready to upload our files. I will use the sync command to synchronize the files from this folder to the S3 bucket that we created. Sync checks each file and copies the most recent versions from either side of the connection. It's a quick way to update files between S3 and any local storage. So, the files have been copied okay to the S3 bucket. Now we can configure our security groups to manage access between our resources. First, we need a security group to be associated with the web service. Then a security group to be associated with the elastic load balancer with a rule for the elastic load balancer to accept HTTP requests from anywhere. HTTP requests will be on port 80. So, let's create one rule allowing access from the elastic load balancer to the web service. And another rule allowing access from the web service to the database instances. Now let's create some instances. We'll use the Amazon Linux and T2 micro instances. This is where we can specify the subnet into which we want to launch the instances and the role we will use to limit what the instance can do in our VPC. We can also bootstrap the machine by adding some user data. Now, user data is a script that runs once during the installation launch. It's really useful for bootstrapping instances and we can add the script to our auto scale launch config so every new machine is provisioned with the resources that we want. So, let's just pause and walk through what we're doing here. This script will download the WordPress app bundle from S3 and deploy it onto our new instance. The script will also configure the instance to monitor through CloudWatch and to enable us to report on some custom EC2 metrics. Okay, so let's launch our instance. So, let's name this instance wp-web-1 and select the security group that we previously created. AWS will present an error as it should as we have not allowed SSH access to the instance. Let's launch this instance and two more like it. Now we can create our elastic load balancer. We'll name it wp-elb and configure it to run on the three subnets available through our default VPC. Let's select the security group that we created especially for our load balancer. And configure health checks to check the installation path of WordPress. Let's select the three web instances. Their status will chance to in service when that's complete. Okay. We are close to having our proposed design ready to test. Let's see what it looks like when we test out the load balancer URL. Great, it works. So, at this point, we have our WordPress application running on three instances in three separate availability zones behind our elastic load balancer. The elastic load balancer will health check each instance on the port we specified and then it will round robin requests of traffic to those instances returning an OK status in the health check. Our MySQL database is running with its master in one availability zone and two failover databases in alternate availability zones. We now want to configure CloudFront as another additional layer of durability and security. Let's start by creating a new web distribution. This time we'll use the load balancer as our origin. I will make a very generic configuration allowing all HTTP methods and using all edge locations as our price class which suits as our customer has a global audience. It will take some time to deploy which can happen in the background. We need to add two elements controlling the log in and the admin pages. Both of them will use the same settings. We only need to specify the right path pattern. Static and dynamic content will now be delivered by our CloudFront distribution meaning we have another layer of durability and security in our application design. CloudFront is forwarding presently most of the content from the load balancer. So, we can change that by changing our site URL. That will be all we need to do on the WordPress site. So, at this point we have a CloudFront distribution handling our traffic requests from global locations. We've got our WordPress service sitting behind an elastic load balancer. Now let's go into some optimization and see what we can add to improve the durability of this solution in the next video.
Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built 70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+ years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.