1 00:00:14,320 --> 00:00:18,240 Welcome back to Backspace academy. In this lecture we'll have a look at the 2 00:00:18,240 --> 00:00:23,199 compute and networking services of AWS. We'll then have a look at some examples 3 00:00:23,199 --> 00:00:26,960 and finally we'll finish up with a hands-on lab where we're going 4 00:00:26,960 --> 00:00:31,359 to deploy a wordpress web server using the Amazon 5 00:00:31,359 --> 00:00:36,719 EC2 service. Amazon elastic compute cloud or EC2 for 6 00:00:36,719 --> 00:00:40,079 short, provides virtual servers in the AWS 7 00:00:40,079 --> 00:00:43,200 cloud. You can launch one or thousands of 8 00:00:43,200 --> 00:00:48,960 instances simultaneously and only pay for what you use. There's a broad 9 00:00:48,960 --> 00:00:53,199 range of instant types with varying compute and memory capabilities 10 00:00:53,199 --> 00:00:58,000 and those will be optimized for different use cases. 11 00:00:58,000 --> 00:01:01,920 Amazon EC2 auto scaling allows you to dynamically 12 00:01:01,920 --> 00:01:08,000 scale your Amazon EC2 capacity up or down automatically according to 13 00:01:08,000 --> 00:01:12,960 conditions that you define. It can scale up or down by launching or 14 00:01:12,960 --> 00:01:17,360 terminating instances based on demand. It can also perform 15 00:01:17,360 --> 00:01:20,640 health checks on those instances and replace them when 16 00:01:20,640 --> 00:01:25,439 they become unhealthy. Amazon Lightsail, it's the easiest way 17 00:01:25,439 --> 00:01:29,119 to launch virtual servers running applications in 18 00:01:29,119 --> 00:01:33,280 the AWS cloud. AWS will provision everything you need 19 00:01:33,280 --> 00:01:38,079 including DNS management and storage to get you up and running as 20 00:01:38,079 --> 00:01:44,880 quickly as possible. Amazon elastic container service or ECS for short is a 21 00:01:44,880 --> 00:01:48,880 highly scalable high performance container management 22 00:01:48,880 --> 00:01:52,720 service for Docker containers. The containers, 23 00:01:52,720 --> 00:01:58,240 they will run on a managed cluster of EC2 instances. AWS 24 00:01:58,240 --> 00:02:01,280 lambda is a serverless service and lets you run 25 00:02:01,280 --> 00:02:06,159 code in the AWS cloud without having to worry about provisioning or 26 00:02:06,159 --> 00:02:10,080 managing that server. You just upload your code and AWS 27 00:02:10,080 --> 00:02:15,120 takes care of everything for you. So let's have a look at how we could use 28 00:02:15,120 --> 00:02:20,400 these services to deploy a web server in the AWS cloud. 29 00:02:20,400 --> 00:02:25,599 Here we have the AWS cloud and our virtual private cloud or VPC 30 00:02:25,599 --> 00:02:29,040 located inside that and remember a VPC is 31 00:02:29,040 --> 00:02:32,640 our own private space within the AWS cloud 32 00:02:32,640 --> 00:02:36,959 and no one can enter that unless we allow them to enter it. 33 00:02:36,959 --> 00:02:42,319 We can launch an EC2 instance and that can be running our web 34 00:02:42,319 --> 00:02:48,480 application for example wordpress. So what happens if this single EC2 35 00:02:48,480 --> 00:02:52,239 instance becomes overwhelmed by demand? For 36 00:02:52,239 --> 00:02:55,599 example we might have released a new product and our wordpress 37 00:02:55,599 --> 00:03:00,640 application cannot deliver the web pages quickly enough to satisfy 38 00:03:00,640 --> 00:03:04,879 that. What we could do is that we could tear 39 00:03:04,879 --> 00:03:09,040 down that instance and put in a bigger instance that could 40 00:03:09,040 --> 00:03:13,200 handle that demand and that is called vertical scaling and 41 00:03:13,200 --> 00:03:18,560 that used to be all the rage 10 or 20 years ago but the problem is 42 00:03:18,560 --> 00:03:22,480 that it takes time to do that and while we're doing that 43 00:03:22,480 --> 00:03:28,560 our application is not running and also, what happens when the demand goes back 44 00:03:28,560 --> 00:03:33,760 down again? Do we have to tear that down and then put in a smaller instance and 45 00:03:33,760 --> 00:03:37,680 what happens if that happens every day? What happens if that happens 46 00:03:37,680 --> 00:03:41,599 every hour? It's just not going to be economical for 47 00:03:41,599 --> 00:03:46,000 us to do that. What we can do is that we can 48 00:03:46,000 --> 00:03:51,360 horizontally scale and we do that by adding more instances 49 00:03:51,360 --> 00:03:54,959 and as demand goes up we add more instances 50 00:03:54,959 --> 00:03:59,040 and as demand goes down we terminate those instances 51 00:03:59,040 --> 00:04:04,959 and that way we still have continuity of our application. Our 52 00:04:04,959 --> 00:04:08,799 application will always be running because there's always going to be at 53 00:04:08,799 --> 00:04:14,879 least one EC2 instance to look after the demand. 54 00:04:14,879 --> 00:04:18,079 One problem with this architecture is that it has 55 00:04:18,079 --> 00:04:23,360 multiple endpoints for our web server and that's not practical because 56 00:04:23,360 --> 00:04:26,560 customers are not going to go to one endpoint until that stops working and 57 00:04:26,560 --> 00:04:28,800 then go to another one and then another one. 58 00:04:28,800 --> 00:04:32,400 It's just not going to work like that and obviously their bookmarks in their 59 00:04:32,400 --> 00:04:35,759 browser are not going to be valid so we need a 60 00:04:35,759 --> 00:04:40,240 way of having one single endpoint for that web application 61 00:04:40,240 --> 00:04:43,360 that our customer can go to and then having a way 62 00:04:43,360 --> 00:04:50,560 of distributing those requests to an EC2 instance that is available. 63 00:04:50,560 --> 00:04:54,400 That is where elastic load balancing comes in. 64 00:04:54,400 --> 00:05:00,080 So it can receive traffic from our end users and it will distribute that 65 00:05:00,080 --> 00:05:04,080 traffic to an EC2 instance that is available. 66 00:05:04,080 --> 00:05:07,120 So a request will come in. It will distribute it 67 00:05:07,120 --> 00:05:12,320 to an available EC2 instance. Another request will come in and it will 68 00:05:12,320 --> 00:05:16,639 distribute it to a different EC2 instance that is available and it 69 00:05:16,639 --> 00:05:21,680 will balance the load across those EC2 instances 70 00:05:21,680 --> 00:05:28,639 and if one of those EC2 instances becomes unhealthy, it will fail a health check 71 00:05:28,639 --> 00:05:32,400 with the elastic load balancer and then the elastic load balancer 72 00:05:32,400 --> 00:05:38,960 will no longer send traffic to that unhealthy EC2 instance. 73 00:05:38,960 --> 00:05:44,160 But what happens if that demand is only for a short period of time for 74 00:05:44,160 --> 00:05:48,160 example half an hour? What do we do then? It's not going to be 75 00:05:48,160 --> 00:05:52,720 practical for us to terminate instances when demand goes 76 00:05:52,720 --> 00:05:55,759 down and then launch instances manually when 77 00:05:55,759 --> 00:06:00,240 that occurs. We can't do that every hour it's not going to be practical 78 00:06:00,240 --> 00:06:03,680 and that's where the auto scaling service 79 00:06:03,680 --> 00:06:10,160 comes in. It can launch EC2 instances automatically when the demand on those 80 00:06:10,160 --> 00:06:13,520 instances increases and it can terminate 81 00:06:13,520 --> 00:06:17,360 automatically EC2 instances when the demand on those 82 00:06:17,360 --> 00:06:22,000 instances goes down. It can also perform 83 00:06:22,000 --> 00:06:25,039 health checks on those instances and if one of those 84 00:06:25,039 --> 00:06:28,880 instances becomes unhealthy for whatever reason, 85 00:06:28,880 --> 00:06:32,720 it can replace that instance with a healthy instance 86 00:06:32,720 --> 00:06:36,080 and it will do that automatically without you having to do 87 00:06:36,080 --> 00:06:39,280 anything at all. 88 00:06:42,400 --> 00:06:45,600 So now we'll have a look at the networking and content 89 00:06:45,600 --> 00:06:52,400 delivery services. Amazon CloudFront is a global content delivery network or cdn 90 00:06:52,400 --> 00:06:55,520 for short that securely delivers your frequently 91 00:06:55,520 --> 00:07:00,400 requested content to over 100 edge locations across the 92 00:07:00,400 --> 00:07:03,520 globe and by doing this it achieves low 93 00:07:03,520 --> 00:07:07,039 latency and high transfer speeds for your end 94 00:07:07,039 --> 00:07:11,599 users. It also provides protection against 95 00:07:11,599 --> 00:07:17,360 DDOS attacks. Amazon virtual private cloud or VPC for short 96 00:07:17,360 --> 00:07:21,280 lets you provision a logically isolated section 97 00:07:21,280 --> 00:07:28,560 of the AWS cloud and you can launch AWS resources in that virtual network 98 00:07:28,560 --> 00:07:35,280 that you yourself define and this is your own personal private space 99 00:07:35,280 --> 00:07:39,440 within the AWS cloud and no one can enter it 100 00:07:39,440 --> 00:07:46,720 unless you allow them to enter it. AWS direct connect is a high-speed 101 00:07:46,720 --> 00:07:52,639 dedicated network connection to AWS. Enterprises can use it to establish a 102 00:07:52,639 --> 00:07:57,680 private connection to the AWS cloud in situations where a 103 00:07:57,680 --> 00:08:03,599 standard internet connection won't be adequate. AWS elastic 104 00:08:03,599 --> 00:08:07,599 load balancing or ELB for short automatically distributes 105 00:08:07,599 --> 00:08:11,199 incoming traffic for your application across 106 00:08:11,199 --> 00:08:16,800 multiple EC2 instances and also in multiple availability zones. So if one 107 00:08:16,800 --> 00:08:21,360 availability zone goes down, the traffic will still go to the 108 00:08:21,360 --> 00:08:24,000 other availability zone and your application 109 00:08:24,000 --> 00:08:28,319 will continue to deliver responses to requests. 110 00:08:28,319 --> 00:08:32,959 It also allows you to achieve high availability and fault tolerance 111 00:08:32,959 --> 00:08:36,719 by distributing traffic evenly amongst those instances 112 00:08:36,719 --> 00:08:42,320 and it can also bypass unhealthy instances. 113 00:08:42,320 --> 00:08:48,640 Amazon Route 53 is a highly available and scalable domain name system or DNS 114 00:08:48,640 --> 00:08:52,000 for short and it can handle direct traffic for 115 00:08:52,000 --> 00:08:56,560 your domain name and direct that traffic to your back-end 116 00:08:56,560 --> 00:09:02,880 web server. Amazon API gateway is a fully managed service that makes it 117 00:09:02,880 --> 00:09:07,600 easy for developers to create and deploy secure 118 00:09:07,600 --> 00:09:11,120 application programming interfaces or API 119 00:09:11,120 --> 00:09:17,440 at any scale. It handles all of the tasks involved in accepting and processing up 120 00:09:17,440 --> 00:09:21,200 to hundreds of thousands of concurrent API 121 00:09:21,200 --> 00:09:24,959 calls. It's a serverless service and as such 122 00:09:24,959 --> 00:09:28,399 you don't need to worry about the underlying 123 00:09:28,399 --> 00:09:34,000 infrastructure AWS looks after everything for you. 124 00:09:34,000 --> 00:09:38,000 So let's have a look at an example of how we can use these networking services 125 00:09:38,000 --> 00:09:41,360 of AWS. So here we've got the architecture that 126 00:09:41,360 --> 00:09:43,760 we looked at before in the compute section 127 00:09:43,760 --> 00:09:47,680 but one thing we didn't mention was availability zones. 128 00:09:47,680 --> 00:09:51,600 So let's just say that we've launched that architecture in a single 129 00:09:51,600 --> 00:09:56,000 availability zone. What happens if that availability zone 130 00:09:56,000 --> 00:10:00,000 goes down? What happens to our traffic? Our traffic 131 00:10:00,000 --> 00:10:04,160 has nowhere to go and our application stops delivering 132 00:10:04,160 --> 00:10:10,160 responses to requests. That is why it's always desirable to 133 00:10:10,160 --> 00:10:15,040 have our architecture distributed across multiple availability 134 00:10:15,040 --> 00:10:18,000 zones. That way if one availability zone goes 135 00:10:18,000 --> 00:10:22,240 down the other one will continue to operate and the infrastructure 136 00:10:22,240 --> 00:10:25,440 within that other availability zone will continue 137 00:10:25,440 --> 00:10:31,680 to respond to requests. We can launch EC2 instances in multiple 138 00:10:31,680 --> 00:10:36,560 availability zones and our elastic low balancing service 139 00:10:36,560 --> 00:10:39,760 can distribute that traffic across multiple 140 00:10:39,760 --> 00:10:45,839 availability zones as well. So if one availability zone goes down the elastic 141 00:10:45,839 --> 00:10:49,440 load balancer will continue to distribute traffic to 142 00:10:49,440 --> 00:10:53,040 the availability zone that is still healthy 143 00:10:53,040 --> 00:10:56,160 and to those instances in that availability zone 144 00:10:56,160 --> 00:11:01,839 that are still healthy as well. So let's just say our application 145 00:11:01,839 --> 00:11:06,640 running on these EC2 instances is a wordpress web server and that 146 00:11:06,640 --> 00:11:10,480 contains lots of images and lots of video that is 147 00:11:10,480 --> 00:11:14,320 static content, it's not really changing that much and it's not 148 00:11:14,320 --> 00:11:17,360 efficient for us to continue to keep delivering that 149 00:11:17,360 --> 00:11:21,839 from our EC2 instances. We would like somewhere to put that 150 00:11:21,839 --> 00:11:25,600 where it can be delivered with high speed and low latency 151 00:11:25,600 --> 00:11:30,480 and to take the load off our EC2 instances. 152 00:11:30,480 --> 00:11:34,079 That is where the CloudFront content delivery 153 00:11:34,079 --> 00:11:41,360 network or CDN comes in. So we can get these large images and large videos 154 00:11:41,360 --> 00:11:45,040 that are not really changing that often and we can put that 155 00:11:45,040 --> 00:11:48,800 in a CloudFront distribution and CloudFront 156 00:11:48,800 --> 00:11:52,000 will cache that and distribute that across 157 00:11:52,000 --> 00:11:55,360 hundreds of edge locations across the globe. 158 00:11:55,360 --> 00:11:59,920 So when your end user requests that video or those images, 159 00:11:59,920 --> 00:12:03,680 it will be delivered to them with really high speed 160 00:12:03,680 --> 00:12:10,079 and low latency and at the same time it's going to take the load off your EC2 161 00:12:10,079 --> 00:12:13,760 instances and is going to significantly reduce 162 00:12:13,760 --> 00:12:19,120 your costs at the same time. Dynamic content that is changing 163 00:12:19,120 --> 00:12:22,560 regularly, CloudFront can forward those requests 164 00:12:22,560 --> 00:12:26,079 over to the elastic load balancer which will then forward them 165 00:12:26,079 --> 00:12:31,600 to an EC2 instance. So that way you have the best of both worlds. You 166 00:12:31,600 --> 00:12:35,279 have dynamic content delivered as a dynamic 167 00:12:35,279 --> 00:12:38,320 content and at the same time you have these 168 00:12:38,320 --> 00:12:41,360 large videos and images that aren't really 169 00:12:41,360 --> 00:12:46,480 changing that often delivered very rapidly. 170 00:12:46,480 --> 00:12:50,639 Now that CloudFront service or that CloudFront distribution 171 00:12:50,639 --> 00:12:55,360 will have its own DNS name that we can put into a browser 172 00:12:55,360 --> 00:12:58,720 and we can directly access that. The problem with that 173 00:12:58,720 --> 00:13:02,959 is that that DNS name for that CloudFront distribution 174 00:13:02,959 --> 00:13:08,000 will be something very complicated and just won't mean anything to our end user 175 00:13:08,000 --> 00:13:11,920 at all. So we would prefer to have our end user type in 176 00:13:11,920 --> 00:13:15,519 a domain name and have the request for that domain name 177 00:13:15,519 --> 00:13:20,040 forwarded to that CloudFront service. As you can see here we've got 178 00:13:20,040 --> 00:13:26,240 example.com and that is where route 53 domain name service 179 00:13:26,240 --> 00:13:32,839 can come in. So route 53 will grab those requests for your domain 180 00:13:32,839 --> 00:13:36,399 example.com and it will forward those requests 181 00:13:36,399 --> 00:13:40,480 over to the CloudFront service and the CloudFront service 182 00:13:40,480 --> 00:13:44,959 will handle it from then on. So let's just say we work for 183 00:13:44,959 --> 00:13:49,279 a large enterprise that has its own corporate data center 184 00:13:49,279 --> 00:13:52,399 and the reason it's got its own corporate data center is because that is 185 00:13:52,399 --> 00:13:56,720 located where the employees work and we don't 186 00:13:56,720 --> 00:14:00,480 want our employees to be slowed down by a 187 00:14:00,480 --> 00:14:05,680 network. We want them to be able to work efficiently but at the same time 188 00:14:05,680 --> 00:14:13,360 we have resources on the AWS cloud that those employees also need to access. 189 00:14:13,360 --> 00:14:17,040 So we need some way of having a high speed connection 190 00:14:17,040 --> 00:14:21,360 between our corporate data center and the AWS cloud 191 00:14:21,360 --> 00:14:25,839 and that is where the AWS direct connect service comes in 192 00:14:25,839 --> 00:14:32,320 and that can provide a very high speed fibre optic network between our 193 00:14:32,320 --> 00:14:37,600 corporate data center and the AWS cloud and that is completely 194 00:14:37,600 --> 00:14:44,480 private. Okay, so that's a very complicated architecture and don't 195 00:14:44,480 --> 00:14:48,880 be too concerned if that's very overwhelming because if you're going on 196 00:14:48,880 --> 00:14:53,360 to become a cloud practitioner you're not going to need to really be 197 00:14:53,360 --> 00:14:58,720 able to produce this yourself. As an associate level certification that 198 00:14:58,720 --> 00:15:02,560 is a different story you'd be expected to create this yourself 199 00:15:02,560 --> 00:15:06,720 but cloud practitioner you'll need to know what these services do. 200 00:15:06,720 --> 00:15:10,240 You'll need to know that route 53 will forward request 201 00:15:10,240 --> 00:15:14,000 for your domain name to a backend endpoint. 202 00:15:14,000 --> 00:15:19,920 CloudFront will distribute your content to hundreds of edge locations across the 203 00:15:19,920 --> 00:15:22,800 globe. Elastic load balancer will receive 204 00:15:22,800 --> 00:15:25,760 requests and distribute those requests to 205 00:15:25,760 --> 00:15:30,240 multiple instances across multiple availability zones. 206 00:15:30,240 --> 00:15:35,600 A virtual private cloud is your private space within the AWS 207 00:15:35,600 --> 00:15:38,720 cloud. The AWS Direct Connect is a high 208 00:15:38,720 --> 00:15:43,040 high-speed fibre-optic network connection between 209 00:15:43,040 --> 00:15:47,759 an on-premises corporate data center and the AWS cloud. 210 00:15:47,759 --> 00:15:51,199 If you understand that then you're well on your way 211 00:15:51,199 --> 00:15:55,839 to passing the cloud practitioner exam. 212 00:15:55,920 --> 00:15:59,839 Okay, so coming up next we're going to have a lab. So make sure that you 213 00:15:59,839 --> 00:16:03,199 download the introduction to AWS lab notes that come 214 00:16:03,199 --> 00:16:06,160 with this course. So what we're going to do is we're going 215 00:16:06,160 --> 00:16:10,320 to launch an EC2 instance and we're going to select an Amazon 216 00:16:10,320 --> 00:16:14,320 machine image (AMI) of a wordpress web server and that will 217 00:16:14,320 --> 00:16:19,600 allow us to deploy a wordpress server on the AWS cloud 218 00:16:19,600 --> 00:16:22,639 and then we're going to be able to go to our browser 219 00:16:22,639 --> 00:16:29,600 and view our website that was created by that EC2 instance and we're going to do 220 00:16:29,600 --> 00:16:32,800 that all through the AWS management console 221 00:16:32,800 --> 00:16:39,440 on our desktop computer. Okay before we start the lab need to 222 00:16:39,440 --> 00:16:42,079 make sure you get your hands on these lab notes. 223 00:16:42,079 --> 00:16:46,000 The section we're going through here is the creating a web server with 224 00:16:46,000 --> 00:16:50,880 EC2. If you run into trouble when you're following the lab notes there is a 225 00:16:50,880 --> 00:16:54,800 troubleshooting section here, troubleshooting viewing your wordpress 226 00:16:54,800 --> 00:16:58,399 application and also there is a troubleshooting 227 00:16:58,399 --> 00:17:01,839 logging into your wordpress application. So make sure that 228 00:17:01,839 --> 00:17:04,160 you follow these lab notes and if you get into 229 00:17:04,160 --> 00:17:09,679 trouble follow the troubleshooting steps. So starting off in the management 230 00:17:09,679 --> 00:17:12,799 console we're going to go to services and then 231 00:17:12,799 --> 00:17:19,839 EC2 so i've got this in the a to z and just scroll down to EC2 232 00:17:24,880 --> 00:17:27,919 and what we're going to do is go into instances here on 233 00:17:27,919 --> 00:17:32,559 the left and we're going to be creating an instance or launching an 234 00:17:32,559 --> 00:17:36,880 instance. Now you won't have any instances here. I've got an old one here 235 00:17:36,880 --> 00:17:43,440 but yours will most probably be empty. We'll click on launch instances 236 00:17:44,000 --> 00:17:49,200 and what we're going to do is, go into the AWS marketplace here on the left 237 00:17:49,200 --> 00:17:52,960 and we're going to search for wordpress, 238 00:17:54,080 --> 00:17:58,799 and we're going to get the wordpress certified by Bitnami and Automatic. 239 00:17:58,799 --> 00:18:01,840 So we'll select that one 240 00:18:05,120 --> 00:18:09,520 and it's going to show the hourly fees. So for software there's nothing 241 00:18:09,520 --> 00:18:12,559 this is open source software so there's no cost there 242 00:18:12,559 --> 00:18:16,799 but if we select a t2 micro the costs there are 12 243 00:18:16,799 --> 00:18:22,080 or 1.2 cents per hour, but because we're going to be operating 244 00:18:22,080 --> 00:18:25,679 under the free tier with a new account which is less than 12 months old, 245 00:18:25,679 --> 00:18:29,679 then you will not be paying for that, but my account here is 246 00:18:29,679 --> 00:18:33,520 many years old so I have to pay for it but you will be operating under the 247 00:18:33,520 --> 00:18:39,360 free tier if you have a new account. We'll just click on continue 248 00:18:41,039 --> 00:18:44,480 and we'll select that t2 micro which is again 249 00:18:44,480 --> 00:18:50,080 free tier eligible. So there we can see micro instances are eligible 250 00:18:50,080 --> 00:18:53,679 for the AWS free tier for the first 12 months 251 00:18:53,679 --> 00:18:58,320 following your AWS sign up date. 252 00:18:58,720 --> 00:19:01,840 So next we go to configure instance details. 253 00:19:01,840 --> 00:19:04,960 Now the main thing that we're looking at here is to make sure that we have a 254 00:19:04,960 --> 00:19:08,880 public ip enabled. So we click on enable here 255 00:19:08,880 --> 00:19:12,640 and that assigns a public ip. So that means that we can actually 256 00:19:12,640 --> 00:19:17,200 find this this web server over the internet 257 00:19:17,200 --> 00:19:23,200 using our browser, and we're going to launch that into our default VPC. 258 00:19:23,200 --> 00:19:29,200 We'll click on next add storage. We'll leave the storage as it is. 259 00:19:29,200 --> 00:19:33,120 Now we can add a tag. So we're going to add a name tag. So we can see here, 260 00:19:33,120 --> 00:19:37,919 choose your add tag button or you can click to add a name tag. So i'm just 261 00:19:37,919 --> 00:19:42,080 going to click to add a name tag and so you can see here it's put the key 262 00:19:42,080 --> 00:19:45,600 in already which is name and name always has to have a capital N 263 00:19:45,600 --> 00:19:53,840 for that tag and i'm just going to call this backspace lab. 264 00:19:57,919 --> 00:20:01,440 Okay and we'll click on configure security group. 265 00:20:01,440 --> 00:20:06,000 Now this is already going to create a security group for us now. 266 00:20:06,000 --> 00:20:10,720 A security group is is like a firewall so 267 00:20:10,720 --> 00:20:14,640 same as we would have a windows firewall or a linux firewall, 268 00:20:14,640 --> 00:20:18,720 we have a security group which we can associate 269 00:20:18,720 --> 00:20:23,520 with this server and that will block access to that server and we need to 270 00:20:23,520 --> 00:20:28,320 allow access by using rules. So here we can see we've 271 00:20:28,320 --> 00:20:32,320 got http access is allowed and it's allowed from 272 00:20:32,320 --> 00:20:34,880 anywhere here. So we click on this and we'll have 273 00:20:34,880 --> 00:20:39,520 anywhere there and so that's fine. So that will allow us to connect into or 274 00:20:39,520 --> 00:20:46,320 to access this this server on using http in our browser. 275 00:20:46,320 --> 00:20:50,080 Next we'll click on review and launch 276 00:20:50,320 --> 00:20:54,480 that looks all fine there and we'll just click on launch. 277 00:20:54,480 --> 00:20:59,520 Now we don't need to choose a key pair. So we just proceed without a key pair 278 00:20:59,520 --> 00:21:02,640 What a key pair allows us to do is to connect 279 00:21:02,640 --> 00:21:06,799 in remotely to the linux operating system of this server. 280 00:21:06,799 --> 00:21:10,000 We don't need to do that. All that we need to do is to be 281 00:21:10,000 --> 00:21:14,400 able to access the wordpress application that's running on this server and we'll 282 00:21:14,400 --> 00:21:18,559 do that using a username and password. So we don't need to worry about that key 283 00:21:18,559 --> 00:21:23,360 pair and we'll click on launch instances. 284 00:21:29,840 --> 00:21:33,360 Okay so that launch process has started. If we scroll down here there'll be a 285 00:21:33,360 --> 00:21:38,559 button on the right hand side for viewing the instances, 286 00:21:38,720 --> 00:21:42,880 and there we go so there we can see our backspace wordpress lab we gave it that 287 00:21:42,880 --> 00:21:45,440 name tag and that name tag has come up there and 288 00:21:45,440 --> 00:21:49,679 so that's how we can find that, and that is currently pending and now 289 00:21:49,679 --> 00:21:52,480 it's gone to running and it will be doing some status checks 290 00:21:52,480 --> 00:21:56,159 now. So we need to make sure that those status checks have been finished 291 00:21:56,159 --> 00:22:00,159 and from that point onwards we will be able to 292 00:22:00,159 --> 00:22:03,840 actually access this server. So if we just click on this button up here, this 293 00:22:03,840 --> 00:22:06,400 refresh button, we'll be able to see what's going on 294 00:22:06,400 --> 00:22:09,679 there and so there we can see the status is 295 00:22:09,679 --> 00:22:12,960 initializing so it's still got a little bit of a way to go. So we'll give that a 296 00:22:12,960 --> 00:22:15,440 bit of time. 297 00:22:16,080 --> 00:22:21,360 Okay so after about five minutes or so our status checks have changed to two 298 00:22:21,360 --> 00:22:25,600 out of check two checks have passed and again just click on the 299 00:22:25,600 --> 00:22:27,039 refresh button there and you'll be able to see 300 00:22:27,039 --> 00:22:30,559 it if it's not there. So what we can do now is click on this 301 00:22:30,559 --> 00:22:33,679 instance id to open it up and have a look at it. 302 00:22:33,679 --> 00:22:39,120 So there we have our instance id it's running it's a t2 micro instance 303 00:22:39,120 --> 00:22:43,360 and it has this public ip address. It also has a public 304 00:22:43,360 --> 00:22:47,360 DNS there's a public address name there that we're not going to use as 305 00:22:47,360 --> 00:22:51,600 such but we could also put that into our browser and open that as well, 306 00:22:51,600 --> 00:22:58,240 and it has a VPC id. So we launched this into the default VPC which has been 307 00:22:58,240 --> 00:23:02,960 automatically created by AWS when we create our AWS account, 308 00:23:02,960 --> 00:23:06,559 but we can also if we wanted to create multiple 309 00:23:06,559 --> 00:23:12,000 VPC and put and use those to launch our instances into but for this 310 00:23:12,000 --> 00:23:16,080 one i'm just using the default VPC that has been created for us 311 00:23:16,080 --> 00:23:21,039 by AWS. We also have a private ip address and so that is for 312 00:23:21,039 --> 00:23:27,440 internal traffic within our VPC there and we have a subnet id which is a 313 00:23:27,440 --> 00:23:33,360 subnet within our VPC where this is located. We scroll down 314 00:23:33,360 --> 00:23:37,120 here. We can see we've got security 315 00:23:37,120 --> 00:23:40,960 and we can see here that we've got our our our rule 316 00:23:40,960 --> 00:23:45,760 that allows traffic from anywhere on port 80 which is our http 317 00:23:45,760 --> 00:23:51,600 access and that is the rules within our security group and again remember 318 00:23:51,600 --> 00:23:55,679 this security group is a firewall that we associate with 319 00:23:55,679 --> 00:23:59,360 an instance and that will prevent access to that instance 320 00:23:59,360 --> 00:24:02,720 unless we have rules which we have defined here 321 00:24:02,720 --> 00:24:06,799 that allow that access to come through. 322 00:24:07,120 --> 00:24:10,960 Okay so what we'll do now is it will try and access our web server. So we can use 323 00:24:10,960 --> 00:24:14,080 one of these. We can use this one here if we wanted to but i'm 324 00:24:14,080 --> 00:24:17,200 just going to use this one here and i'm just going to open that in a new 325 00:24:17,200 --> 00:24:19,840 tab, 326 00:24:23,679 --> 00:24:27,440 and there we go so there is our out of the box 327 00:24:27,440 --> 00:24:32,720 Wordpress website all up and running. So what would what we'd like to do now 328 00:24:32,720 --> 00:24:38,159 is that we'd like to log into our our website as an administrator of our 329 00:24:38,159 --> 00:24:42,559 of our website and be able to change it, to be able to 330 00:24:42,559 --> 00:24:45,520 put pictures in it and do whatever we want to it. So what we would do is we 331 00:24:45,520 --> 00:24:52,320 will go to forward slash and then admin 332 00:24:52,480 --> 00:24:56,320 and that will take us to our login. So what is this login? We need to have a 333 00:24:56,320 --> 00:25:01,679 login to log into our into our website. So we go back to our 334 00:25:01,679 --> 00:25:07,120 instance details. We'll click on instances here. 335 00:25:07,120 --> 00:25:12,880 We'll select that backspace wordpress lab again, and we're going to go to 336 00:25:12,880 --> 00:25:16,480 actions, and we're going to go to instant 337 00:25:16,480 --> 00:25:20,720 settings, and then we're going to get the system 338 00:25:20,720 --> 00:25:23,039 log. 339 00:25:24,159 --> 00:25:28,640 Now what this system log is basically what is consoled out. 340 00:25:28,640 --> 00:25:33,360 What would be outputted from a console screen that is recorded 341 00:25:33,360 --> 00:25:39,039 in a log by the instance. So if we scroll up here, there will be 342 00:25:39,039 --> 00:25:44,880 a console output that will say what our username and password that 343 00:25:44,880 --> 00:25:48,240 has been generated for this site is. So we scroll up a little bit more and there 344 00:25:48,240 --> 00:25:52,159 we can see setting bitnami application password to 345 00:25:52,159 --> 00:25:55,520 that and the default application username is 346 00:25:55,520 --> 00:26:02,880 user. So if i copy that that password and if i log in with user, 347 00:26:04,240 --> 00:26:11,360 i'll paste in that password and log in, 348 00:26:11,360 --> 00:26:14,400 and there we can see we've logged in as an administrator 349 00:26:14,400 --> 00:26:17,760 to our wordpress site. 350 00:26:18,080 --> 00:26:22,320 Now one thing i've experienced with this lab with a lot of students is that 351 00:26:22,320 --> 00:26:27,039 instead of going through this process of clicking on admin or doing forward 352 00:26:27,039 --> 00:26:29,840 slash admin and then putting the username and 353 00:26:29,840 --> 00:26:33,840 password, they're going to the instance and 354 00:26:33,840 --> 00:26:37,120 they're actually selecting actions and then connect because they're not reading 355 00:26:37,120 --> 00:26:40,159 the lab notes. You won't be able to connect. That is to 356 00:26:40,159 --> 00:26:45,919 connect in to the linux operating system using SSH with a remote computer and we 357 00:26:45,919 --> 00:26:50,000 won't be allowed to do that because when we launched this server we 358 00:26:50,000 --> 00:26:53,200 were asked whether we wanted to associate 359 00:26:53,200 --> 00:26:59,120 an encryption key pair to this server and we said no because 360 00:26:59,120 --> 00:27:02,480 we're not going to be connecting into the linux operating system 361 00:27:02,480 --> 00:27:05,520 all we're doing is we're going to be accessing our 362 00:27:05,520 --> 00:27:08,960 wordpress application and that's all that we need to do. 363 00:27:08,960 --> 00:27:12,000 So if you find that it's a problem that is what's 364 00:27:12,000 --> 00:27:16,559 most probably if you cannot get this connected in. 365 00:27:16,559 --> 00:27:20,399 The other thing there is that there is also a troubleshooting of 366 00:27:20,399 --> 00:27:24,720 launching as well. So troubleshooting viewing your wordpress application 367 00:27:24,720 --> 00:27:29,440 most probably is that something has gone wrong with the firewall setting 368 00:27:29,440 --> 00:27:33,679 that it doesn't have that port 80 access in there as well 369 00:27:33,679 --> 00:27:36,799 but if you follow the lab notes you won't go 370 00:27:36,799 --> 00:27:40,159 into or you won't get into trouble. So what we'll do now is we'll clean all 371 00:27:40,159 --> 00:27:43,440 this up because we don't want to get we won't want to get billed for it, 372 00:27:43,440 --> 00:27:46,159 although you won't get billed for it if you're on the free tier, 373 00:27:46,159 --> 00:27:50,240 if you leave it here and then you launch another instance and you've got two of 374 00:27:50,240 --> 00:27:54,080 them, you will be billed for one of those. So let's make sure that we clean this up. 375 00:27:54,080 --> 00:27:59,039 So we go to actions and we go to instance state 376 00:27:59,039 --> 00:28:06,000 and we go to terminate instance and will terminate 377 00:28:06,159 --> 00:28:10,640 successfully terminated. So that process will be chugging away and again we can 378 00:28:10,640 --> 00:28:14,080 click on this refresh button and see when it has actually changed from 379 00:28:14,080 --> 00:28:18,880 shutting down to terminated. So that brings us to the end 380 00:28:18,880 --> 00:28:23,120 of a very quick lab so you've now launched a web server and you've 381 00:28:23,120 --> 00:28:25,840 accessed that and i hope you got a lot out of it and i 382 00:28:25,840 --> 00:28:30,320 look forward to seeing you in the next one.