AWS Compute encompasses the services that are at the heart of Amazon Web Services Cloud Computing Platform. Compute Services let you run your code in the Cloud, in virtual servers and containers, or with serverless scripts. Think of Compute Services as the servers in your on-premise setup. This is where the code is stored and executed. There is one major difference though. Cloud servers are built to be ephemeral, so storage of permanent data has to happen somewhere else, which we'll cover in the lecture after this one.

In this lecture, we'll cover four of the most commonly used Compute services: those known as EC2, Elastic Load Balancer, EC2 Container Services, and Elastic Beanstalk. There's a fifth Compute service called AWS Lambda, that is important, but doesn't follow the same general paradigm as the rest of Compute, so we'll cover it in another lecture.

EC2 stands for Elastic Compute Cloud, and is the service that lets you quickly spin up and shut down the Cloud servers that are most like your on-premise servers. Each EC2 virtual server, called an EC2 instance, is a computer running in the Cloud that you have full access to, and control over. They're called virtual, because the EC2 instances aren't actually pieces of hardware. Instead, many EC2 instances can be virtualized on any one of Amazon's physical servers. Generally, this means that you can easily spin up or shut down a server, because you don't have to worry about what happens to the physical hardware. Amazon simply reallocates it to other uses. While they're virtual, in the sense of not being physical, EC2 instances can do anything a physical server could. When you spin up an instance, you can select what kind of instance you want, its speed, its storage and memory size, the OS it's running, the software that comes bundled with it, and more. These options are guaranteed. Once your instance is up and running, Amazon ensures that you have the physical hardware you need to back up the options you've selected. Once you've spun up one or more of EC2 instances, you own them completely. You can log into them remotely. You can install any software you want on them. They really are your own servers in the Cloud. You can also network them together, or with other non-Cloud machines, using AWS's Networking Services, which we'll cover in another lesson. They can be made to be accessible from the Internet, or they can be placed behind a firewall on a private network. They can run front-end code to be served to users, back-end code to simply do calculations, or both. Many Web apps built for the Cloud will have a separate front end and back end capabilities, so that you can spin up and manage different servers for each function, and then network them so that they can communicate when needed.

EC2 charges you based on the number and type of EC2 instances that you have up and running. Each EC2 instance type has an hourly cost, ranging from fractions of a cent to dollars per an hour, and as long as it's running will charge your account that cost per an hour, regardless of how much computation it's doing. In addition, there's a cost for data transfers. So while additional Internet traffic won't increase your Compute costs, it will increase your bandwidth costs.

So, that's the Computing Cloud parts of Elastic Compute Cloud, but what's the Elastic mean? In short, it means that you can easily spin up or down instances, without having to worry about your data, your networks, or anything else. Well, one caveat about your data, you should never save data to your EC2 instances, if you care about it. EC2 instances come with some amount of storage and memory built in, but because instances can be spun up or down at any time, and will take their local data with them, you should never treat data on the EC2 instance as persistent. If you need to save data, or to serve data to your users, you should do it with one of AWS's storage or database services. We'll cover these in depth in the next lesson. If you design your application correctly, then spinning down an EC2 instance won't affect any of your important data, because that will have been saved to persistent volume somewhere else. So, EC2 instances are designed to be ephemeral. You can spin up and shut down EC2 instances from the Web portal, through the AWS API, or you can set up a Load Balancer to do it automatically.

So, let's talk about Elastic Load Balancer. Elastic Load Balancer, or ELB, is an easy way to manage your EC2 instances. In its simplest form, you set up a virtual network for all of your EC2 instances, and route all of the traffic going into the network through the Load Balancer. The Load Balancer will route that traffic to the various EC2 instances, so that each of them has a more or less equal load. You can set rules, so that if the average load across all of the instances gets too small, it removes instances and re-balances the traffic to control costs. Or, if the average load across the instances gets too high, you can add more EC2 instances, so that large amounts of traffic won't bring down your app. Each Load Balancer has a cost per an hour, but this is usually much smaller than the savings you get from not having to run too many EC2 instances.

EC2 Container Services, also sometimes called ECS, is a Container Orchestration Service. It is built on top of EC2 instances, but abstracts away the virtual servers, and treats all of them as a single cluster, which you can run your Containerized applications on. I don't want to get too much into detail about how containers work, but a common use case for this would be if you have a Web application that's made of a bunch of small, separate apps, called microservices. If you use this kind of architecture, you can define the different parts of your app with ECS, and ECS will automatically know when to scale up or down specific microservices. This way you don't have to scale up or down the entire app, when only one specific part is seeing a lot of use. There are plenty of other use cases for Containers and Orchestration Services, so if you'd like to learn more about that, make sure to take one of Cloud Academy's Container courses. And if you are using Containers, then know that running EC2 Container Services makes managing your EC2 instances much easier than if you were going to manage them manually.

Finally comes Elastic Beanstalk. Elastic Beanstalk is a way to run your code using EC2, Elastic Load Balancer, and other AWS services, but without having to provision those services yourself. Instead, you upload your code to Elastic Beanstalk, and Beanstalk takes care of deploying the code to EC2 instances, running a Load Balancer, spinning up and attaching storage volumes, and much more. Elastic Beanstalk makes deploying code very easy for a developer who might not want to pay attention to the messy details of how it's deployed. However, it only works for applications written in specific languages, such as Ruby on Rails, or Node.js, and it doesn't offer quite as much fine tuned flexibility as setting the application up yourself, using the underlying AWS services.

Well, that's your introduction to AWS Compute. There are a few other services that fall under the Compute heading, and as I mentioned, we'll cover Lambda later in the course. But you now have a good enough idea of what types of services are in Compute, those which actually run the code that makes up your application.