Hello and welcome to this lecture where I want to perform a demonstration on how to configure and create an environment configuration for your application within AWS Elastic Beanstalk. I'll show you some of the components that we've already discussed including the different deployments described in the previous lecture. I'll look at how to configure a number of different parameters to customize the deployment, meeting specific criteria that you might have such as a particular AMI to be used for the EC2 instances or if you want your instances to be associated to a specific VPC. Okay. So, let's get started. 

Okay. So, I'm logged in to my AWS Management Console. If we go to Elastic Beanstalk, now if you've not used Elastic Beanstalk before, then you'll be presented with this initial splash screen. To get started, all you need to do is click on the blue button that says get started. And here we can now start by creating our new web app with Elastic Beanstalk. Let's give this an application name. I'll just call this Demo. Then we can add some tags to our application if we wanted. So, for example, we can say this is our environment test. And we also have a base configuration here. This is where we choose our platform. There's a number of different platforms there depending on what you need. Let's just go generic docker platform for this demonstration. Now for application code, we can use a sample application. This allows us to get started right away. Or here we can upload our own code. So, if you had your own code you wanted to use with Elastic Beanstalk, which is very likely, then you select this option, and then simply upload and upload your source code. This could be a local file or held within S3. But for this demonstration, we're just going to use the sample application code. So, select the option. Now you can either create the application straight away from here using lots of defaults, but I want to show you how to configure different options for your Elastic Beanstalk application. So, if I click on configure more options, this brings us onto our environment configuration, which is what I primarily want to show you during this demonstration. Let's take a look. 

Now on the top here, we have different configuration presets. We have low cost, high availability, and a custom configuration. With the low cost option, it's going to deploy the application with the minimum amount of resources and the smallest instances whereas your high availability is going to deploy the application across multi-Availability Zones using load balancing and auto-scaling, et cetera. And then the custom configuration allows you to simply modify any element you want to. We could see as we click between these. So, for example, if we look at the capacity on low cost, the environment type is a single instance where if you change that to high availability, we can see that it's now load balanced with auto-scaling across any Availability Zones and one to four instances. So, you can see how the configuration presets differ. Again, if we look at the low cost again and then take a look at the load balancer, we can see that this configuration does not contain a load balancer, but again if we select high availability, we can see that we have an Application Load Balancer with a listener, a process, and a rule as well. So, let's stick with the high availability option just so we can have a look at a wider variety of configuration options. 

Now here at the very top, we can change our platform configuration. This simply allows you to choose a platform version. Click on this dropdown list. It will tell you which ones are available. So, we'll select the latest one here. Now we have a number of different boxes relating to our environment. As you can see, under each one, we have a modify option. So, we can change our instance type, the capacity, how the deployments are managed, security, et cetera. Let's just go through each of these just to have a quick look starting with the software. Click on modify. 

If we need a proxy server for our application, we can select one here, either Nginx or none. As you can see, this option allows you to control container behavior and lets you pass key-value pairs in an RS environment. Then we have S3 log storage. Now if you wanted our instances to upload rotated logs to Amazon S3, then we can. So, we can enable the logs to be rotated. And then we also have log streaming to CloudWatch Logs. Here we can configure our instance in our environment to stream logs to CloudWatch Logs. This will let us set the retention up to 10 years and configure Elastic Beanstalk to delete the logs when we terminate our environment. Again, we can enable log streaming, we can have the retention from a single day to up to 10 years, which I don't think we need to do for this example. Again, we have our lifecycle management where we can keep the logs after terminating our environment or delete the logs upon termination. For this demonstration, I'm just going to disable logging to CloudWatch Logs. And again, we can add some tags for our environment. 

Let's now look at the instances. This gives us an option to select an instance type. By default, it selected the t2.micro, which is fine, and using this AMI ID. We're able to change the configuration of our root volume. We can just have the default or select our own root volume as needed and then specify the size and what iOPS as well. Now here we have a number of security groups. So, if you want a specific security group assigned to your EC2 instances that are deployed, then you can select the relevant security groups as you need. Once you're happy with the information, just click on save. In each of these boxes as well, before going to modify, just provides a summary of the configuration options that you've selected. So, we could have just taken a look at this summary box here where it's got the AMI ID, the instance type that's selected, and the root volume configuration as well. So, in this capacity box, we can see that load balancing and auto-scaling is configured for any zones with one to four instances. So, in the environment type, we can have a single instance or load balanced. If we change this to a single instance, you'll see the available parameters change. So, let's swap that back to load balanced. For our auto-scaling, we can specify the minimum and maximum number of instances that we want. Depending on your application, you might want to alter that. We should put that back to the default. You may specify where you want your resources to be placed in specific Available Zones, so any one Availability Zone, any two, any three, et cetera, or just any of them. Here you can specify which Availability Zones you want to use. We'll use all of those. Here are some triggers based on your auto-scaling. You have a number of different options here, so for example CPUUtilization. Now I want this to scale based on average stats. Then we can change the unit to percentage. Then it's the period and breach duration for your auto-scaling before it kicks in. And then we can say the upper threshold is 75%, and the lower threshold is 30%. Basically what this is saying is when your CPU utilization goes above 75% on average for a period of five minutes, then perform the relevant auto-scaling. 

Now if we go down to the load balancer and click on modify, now here we can select our different load balancer, whether we want an Application Load Balancer, a Classic Load Balancer, or a Network Load Balancer. Now here you can make a number of configurational changes to your load balancer with regards to the listener, the processes, and the rules as well. Feel free to ensure you configure that as you need for your application. If you need more information on Elastic Load Balancers, then please take a look at the relevant content in the Cloud Academy library. Access log files, you can configure Elastic Load Balancing to capture logs with detailed information about requests sent to your load balancer. These logs are stored in S3. If you want to enable the storing of logs for your ELB, then you can enable it here and specify a bucket, and then your logs will be stored on S3. Now let's take a look at the rolling updates and deployments. Now I spoke earlier about the different deployment options. Here you can see all at once, rolling, rolling with additional batch, and immutable. For example, if we'd done rolling, then we can specify the percentage of the fleet at each time, so for example 25%, or you can base it upon the number of instances at a time. I'll leave that as percentage. So, for any configurational updates, we can specify the type of deployment as well. Just for clarity, this was for your main application deployment, this section. And here we can configuration updates, so any changes to your VM settings and VPC configuration trigger rolling updates to replace the instances in your environment without downtime. Here you can specify the type of rolling update that you'd like to perform those configuration updates on. Again, you have a number of parameters to help you control that deployment. Have deployment preferences here. You can customize the health check requirements and deployment timeouts. So, if you're happy for your deployment to continue even though there's been health check failures, then you can select this box. That will prevent your deployment from failing due to any health check issues. You can specify your healthy threshold. If you're okay with a warning considered as healthy as virtual deployment is concerned, then you can simply select warning. Okay. If we cancel out of that, we now have security. 

Here you can specify the service role for Elastic Beanstalk. You'll have a default service role of AWS role currently managed, which is this one here, and also the key pairs that you'd like to use for your resources for access. So, you can specify any of your key pairs that you might have here. So, if I just select Ca-demo for example, then I would have to use the resulting private key relating to this key pair to connect to any of the resources deployed. Monitoring. You could set a health check path here. This will help the load balancer perform health checks. And then your health reporting, either enhanced or basic. Now in the next lecture, I discuss both of these elements of reporting. We'll expand on the difference between them then. But I just wanted to show you now that this is where you change the monitoring. Now the bottom here, again we can enable log streaming to CloudWatch Logs and what we should do with our logs once the environment is terminated. Now if we look at our managed updates screen, here we can see that this enables managed platform updates to apply platform updates automatically during a weekly maintenance window that you choose. Your application stays available during the update process. So, you can enable managed updates, and you can specify timeframe of when you want these updates to be applied. 

The next section is notifications. Here we can simply enter an email address to notify us of any important events that happen within our environment. For that, I'll use SNS. It will drop me an email to notify me of any of these events. So, let's just save that in there. Network, we can see that this environment is not a part of VPC. We can modify this. We want this to run in my VPC, Cloud Academy VPC. Now if we have our application that's publicly visible, then we need to specify what sort of load balancer that we want, either a public or internal. So, I'll leave that as public. Specify the subnet based on our new VPC settings there. And here we can select our instance subnets as well, so where we want our instances to run. And click on save. 

Now we have a database option. We can add a database to our Elastic Beanstalk configuration here by either restoring from an existing snapshot or setting up a new database here. As you can see, we can add an Amazon RDS SQL database to our environment for dev and testing, and Elastic Beanstalk will provide connection information to our instances by setting environment properties for the database host name, username, and password, table name, and port. So, when we add the database to our environment, its lifecycle is also tied to our environment. All we need to do is add a username and password. And we can change the availability to either have multi-AZ database, so have it across multiple Availability Zones for high availability, or just a single AZ. I'm going to leave it as a single AZ for this demonstration. Click on save. 

Finally, we can add any tags that we want in our own environment. So, we can say Application, Test. Let's hit save. And then all we need to do is select create app. 

Elastic Beanstalk will then go ahead and create our environment as per our configuration. As you can see, it's creating different resources here for our environment. This will take a few minutes for it to all go through and be processed. Once it's all been created, you can then look up different elements of your application. You also have an information box at the top there. It states that an RDS database must have subnets selected in at least two Availability Zones. We can configure the database subnets in the network section. But for the sake of this demo, I'm just going to leave that as is. The configuration here, so this is essentially configuration that we made earlier. We can take a look at any log information if we had configured it to do so. We can look at the health, monitoring options, and the alarm, and managed updates, et cetera. So, it's quite a simple process, drawing lots of configurable component if you want to make specific changes. But once you have made all your configured options, it's then very simple just to deploy your application and have the environment created. That now brings me to the end of this demonstration. 

Coming up next, I shall be explaining how Elastic Beanstalk performs monitoring and health checks against your application and its associated environment.