- [Morgan] Welcome back. One of the benefits of using ECS with the EC2 launch type is the amazing control you get of the underlying cluster. In previous videos, I showed you how to launch a simple container instance, running on EC2, using ECS. From a high level, we have ECS, which is the orchestration tool, and EC2, which is the compute backing for your containers. ECS is communicating with the underlying EC2 instances in order to manage the cluster and the container instances. To enable this communication between ECS and the cluster, there is an ECS agent running on each EC2 instance. Let's pull up the command we use to launch the EC2 instance. You can see here, we define the use of an AMI. We were using the built-in ECS optimized AMIs for Linux, and the ECS agent is pre-installed on the EC2 instance. Without this agent, the EC2 would not be able to communicate with ECS. There was also a user data script that was included in this command whenever we launched the EC2 instance. This user data script, we can open it up, this user data script was configuring the ECS agent on the instance to be aware of what ECS cluster the agent would be communicating with, which is for us, this ECS demo cluster. The pre-built AMIs for ECS are a great starting point. But what if you wanted to install third-party monitoring software in the host or use a custom AMI that was pre-approved by, say, your cyber security team in order to meet compliance or governments' requirements? If you want to choose a custom AMI, that is also possible with ECS. This will allow you to completely customize the cluster that hosts your tasks. In order to use a custom AMI with ECS, you would create an empty cluster and then launch your EC2 instances separately and configure them to be a part of the cluster after bootup, using user data and configuration files, just like we did in our demo earlier. The only real difference is, you would also need to ensure that any custom instance you are adding to your cluster has the ECS agent downloaded, installed, and configured. Another great aspect of ECS with EC2 hosting is that it uses EC2 auto-scaling for cluster scaling, so there's no need to learn a secondary scaling mechanism, as it is the same as regular EC2 scaling. ECS uses VPC constructs for networking, just like any other EC2-based service. Your EC2 instances are located in a Virtual Private Cloud or VPC, with an IP range that you specify. You decide which instances are exposed to the Internet and which remain private by placing them in either a public or private subnet, and you can also use security groups and network ACLs, which will allow you to control inbound and outbound network access to and from your instances. Once your cluster is up and running inside of your VPC, you might want to perform basic administrative tasks on your instance, such as installing or updating software or potentially accessing diagnostic logs. In order to do this, you would need to create a connection with the underlying instance. If you're using Linux, a common way to do this would be to use SSH. Since ECS doesn't entirely abstract the underlying infrastructure, you have the ability to make those connections needed to administer the instances. When we created our cluster, we associated the key pair, ecs-containers-kp with the instances, and we also used a security group, which opened up Port 22 for SSH access. Let's go ahead and establish a connection with the instance. All right, I'm now connected to my instance, and to prove it, let's cURL the instance Metadata Service for this host and pull down the private IP address. To do that, I'm going to cURL 169.254.169.254 slash latest slash meta-data slash local-ipv4. And you can see, over here on the left, 10.1.1.53 is the private IP address of the instance that this particular container is hosted on. Now I can exit from the instance, and I am back to the regular Cloud9 terminal. As you can see, ECS gives you control over the underlying infrastructure, and ECS also allows you to take advantage of different EC2 pricing options. With the EC2 launch type, billing is based on the cost of the underlying EC2 instances. If your workload has a consistent demand for many CPU cores and a high amount of memory, you might consider running your cluster on the EC2 launch type in order to optimize for cost. You can run your ECS cluster on On-demand instances, Reserved instances, or Spot instances. This sort of control can help you find places to minimize cost. For real cost savings, you could also consider running ECS on Spot instances. The way Spot works at a high level is you get to use EC2 instances with the instance price of 50 to 90% off of the On-demand price. The price is driven by supply and demand, and AWS reserves the right to reclaim that instance at any time, giving you a two-minute warning that the instance will no longer be available for your use. ECS allows you to use Spot instances in your cluster, and the ECS agent running on the instance provides automatic support for connection draining. So that way, when the EC2 instance gets the notification that the instance will be reclaimed in two minutes, the ECS agent automatically recognizes that and will begin to drain the connections from that instance, allowing ECS to place those containers on other hosts. For more information on how to save money to the tool called Spot Fleet and ECS, go ahead and check out the class notes. So as you can see, spinning up containers on Amazon Elastic Container Service takes away a lot of the headache when it comes to managing container-based workloads. You can choose to manage your cluster with the highest amount of control using the EC2 launch type, or you can choose to stay a little bit more high-level and go with the Fargate launch type. Each launch type best suits different needs, so keep in mind your specific use case when you are deciding what launch type to pick with ECS. Thanks, and I'll see you next time.
