Amazon Container Services

Editor's Notes

• #3: We are super excited about the ecosystem of services that we now have enabling AWS to be the best place to run containers securely, at scale, and for production workloads.
• #4: We’ve learned that customers love containers. Why? Packaging – simple to think about, easy to model out applications at the component-level, eases the journey to running microservices or 12-factor apps Distribution – generally the container image, which encapsulates everything you need to run your application, is stored in a small, light-weight image that can be run on nearly any machine in a repeatable way Immutable Infrastructure – with the packaging and distribution come a simple way to run immutable infrastructure where you can scale up or down based on requirements
• #5: Let’s take a few minutes and talk through our journey with containers on AWS.
• #6: It was just a little over 3 years ago, November 2014, that we were here announcing the release of Amazon Elastic Container service We launched ECS because our customers needed a way to manage and scale the deployment of Docker containers on AWS. Our customers wanted a managed service where they didn’t have to operate their own cluster management software, a solution that was scalable and secure that they could trust to run their production workloads, and they wanted tight integration and support for EC2 features that they liked.
• #7: Then in 2015, we focused on building a highly reliable, and performant docker image registry and announced this GA release near the end of 2015. Our goal with ECR was to enable developers to use the same familiar docker push/pull APIs to store their container images and we see this product highly adopted by customers both running containers on AWS and really across any environment. What we see is that ECR powers an incredible number of container workloads – across cloud and on-prem. But we’ve continued on this mission over the past 12 months as well.
• #8: To ensure we can support every workload, we’ve provided containers running on Amazon ECS deep integration with the breadth of AWS platform features and capabilities to make it easier to run container-based applications in production. These integrations include support for AWS VPC task networking, IAM roles and Security Groups for tasks, Load Balancer support (ELB, ALB, NLB), Task Auto Scaling for clusters and Tasks, and CloudWatch Metrics and Logs. We also provide a rich set of developer tools to make it easier to build complex applications on AWS, including integration with AWS CodePipeline and the ECS CLI which offers a simplified, yet powerful, user experience for getting started with ECS. With ECS and Auto Scaling, customers can run applications that can grow to support cloud-scale applications.
• #9: In the last couple of years we have seen great adoption of production use cases on Amazon ECS. Our active users are up by more than 450% since 2016 and we are managing containers across millions of instances each month. In fact, we are witnessing an incredible transition to containers and customers scaling on Amazon ECS, whether its Expedia running its travel platform or Mapbox powering mapping data for some of the most popular websites, Amazon ECS enables these customers to be able to run containers at scale. And indeed, we see hundreds of millions of containers launched every week.
• #10: Comprised of many companies from startups to fortune 500 companies running tens of millions of applications worldwide on AWS using Amazon ECS and launching hundreds of millions of containers each week.
• #11: We want to make AWS the best place for our customers to run their applications. We believe earning our customer’s trust in this way starts with things like security, availably, and performance.
• #12: As of 12/1 we have amended the existing Amazon EC2 and EBS compute SLA to now also include container services, including Amazon ECS - with a commitment to 4 9’s of availability.
• #13: But the area we’ve spent a ton of time on based on what we’ve heard from our customers is to make containers a fundamental compute primitive. We’ve done things like IAM roles for Tasks, Auto Scaling for Tasks, Load balancer Support for Tasks (ELB, ALB, NLB)….
• #14: And most recently announced our new Task Networking capability for tasks that brings AWS VPC like features to the ECS task. When selecting AWSVPC mode within your task definition, you can now have the option to assign ENIs, public IPs, and security groups at task-level granularity. So, ECS takes on the burden of creating, attaching ENIs on demand (for task launches), tearing down when tasks stop. The ECS Agent ensures that containers in a task are configured to use the ENI by utilizing linux network namespaces, and this is all done through an open sourced set of CNI plug-ins that we we’ve built for Amazon ECS. If interested, you can take a look at these on our GitHub repo.
• #15: As customers begin to move to microservices, a shift in how they manage these has also occurred. You now have 100s to 1000s of smaller components or micro-applications running across your infrastructure. Keeping track of where these are running, the application health, and how to reach these is challenging. It’s a problem that needs to be automated. At re:Invent we announced that Amazon ECS will soon have native service discovery support, coming early in 2018. With Service Discovery for Amazon ECS, you will be able to run services and have these registered in an Route53-backed service registrar when the tasks for that service are started. Amazon ECS will manage the lifecycle of updating the service registrar as new tasks come online or go offline. We are also introducing support for Docker container-level health checks and will update the status of an application in the registrar based off the container-level health. With this new Service Discovery feature, there is no infrastructure to manage, tasks and services are dynamically updated, and available as native capability of Amazon ECS. The benefits of this approach are that you get tie in to the broader AWS ecosystem and can use the same service directory for container tasks on Amazon ECS, applications on EC2, running across clusters, and availability zones. And, benefit from the the near 100% availability SLA for Amazon R53.
• #16: Just as critical to managing containers as scale is to automate the deployment process. Customers tell us that deploying new code involves jumping through many hoops. We want to make it faster and easier to build and deploy code changes as containers. ECS & AWS CodePipeline jointly launching full support for continuous delivery and deployment to Amazon ECS. Now, each time your developers push a new code change into a source control repository – be it on GitHub or AWS CodeCommit or any versioned object store like Amazon S3, AWS CodePipeline can automatically build, test and deploy the updated container into ECS.
• #17: Customers are interested in running workloads across multiple operating systems. We announced early beta support with the initial beta release of a windows version of Docker about 1 year ago. After working to provide customers with a seamless experience between platforms, now happy to announce that Windows containers on Amazon ECS fall into our Generally Available category. We have a new ECS optimized AMI for Windows, based on Windows Server 2016 core build running Docker 17.06. The ECS Agent runs as a service within the build to ensure proper lifecycle management. Can take advantage of many of the platform features that you have been accustomed to on Linux using the ECS optimized AMI for Linux; including – IAM roles for tasks, native scheduling and placement, application load balancers, logging and metrics. Continuing to work hard to ensure that Windows containers are a tier-1 supported platform; for example, can see the work starting to bring the AWSVPC task networking primitives to Windows by following along on GitHub.
• #18: Customers, each of you, are the critical key to our innovation. We love to listen to customers (you), understand your use cases, learn, use those ideas to fuel our experimentation and find ways to then build innovative new features to solve the problems and challenges we are hearing about. We get those features into your hands, and then the fly wheel spins again – with new feedback, ideas, use cases, etc. This process has helped us to deliver over 50 new features since 2015. One of the most prominent things we’ve heard from our ECS customers is that you would love to only have to think about the container – or application – and not have to manage any of the underlying EC2 infrastructure. Listening to you allows us to make AWS the BEST place to run containers and allows you to focus on the application.
• #19: AWS Fargate is a new technology to run containers without the need to manage underlying infrastructure. Fargate allows you to work entirely with an ECS Task Native API. With Fargate you specify the container image, CPU, and memory required to run that container - in an ECS Task Definition. And with a single command you can run that container in production. With one command you can scale that to 10s, 100s, or thousands based on your requirements.
• #20: With Fargate: You have no instances to manage: no more patching OS or runtimes With the new Task Native API, you don’t need to worry about clusters (they are their as an organizational and security boundary), but you don’t need tow think about cluster utilization or Auto Scaling of compute resources within the cluster. With the resource based pricing model you only pay for the resources you provision for each task. We think Fargate fundamentally changes how you think about consumption; how you will run and deploy your applications with containers.
• #21: Anthony discussed earlier about our thinking behind building Fargate and how it eliminates undifferentiated heavy lifting of infrastructure management when it comes to running containerized workloads. We now want to discuss how Fargate can be used in action. As mentioned earlier, today we have launched Fargate with support for ECS with plans to have EKS take advantage of the Fargate technology as well. We will dive deeper into the experience we launched today with ECS and see it in action!
• #22: Or if you want to run containers in the cloud, you spin up some EC2 instances, launch containers on them and get going in minutes. This would work even if you are using dozens of containers. But as you think about scaling this, managing hundreds of such instances, monitoring their health, scaling them and launching your containers on them and the whole lifecycle around them…how do you scale for that?
• #23: If you double click on the instances it reveals that there is additional supporting software that you need to run, maintain and patch on ALL your virtual machines to support your containers like the Docker daemon and ECS Agent.
• #24: So the real picture looked something like this. There are these additional layers of management you need to be aware of when all you wanted to do was run containers! [CLICK] Fargate support for ECS enables you to do just that – fully managed orchestration as well as data plane experience bringing your focus to only containers.
• #25: Let’s take a look how we can run containers on ECS using Fargate
• #26: Let’s look at how the pricing and configuration works for Fargate.
• #27: Here are the various configurations supported today with Fargate. As you can see, you can have from 2GB per vCPU to generally up to 8GB per vCPU for various configurations. Match your workload requirements closely whether they are general purpose, compute or memory optimized. You can look at the Fargate website for exact pricing levels Per second billing at the container level with the minimum of 1 min
• #28: Fargate works for ECS today – you now have to launch types when you chose to run a task on Amazon ECS.
• #32: We listened, and that’s why we’ve built Elastic Container Service for Kubernetes- or EKS. We know how important a Kubernetes service is to our customers. So we didn't build Amazon EKS haphazardly. An excellent way to communicate how we took your feedback and synthesized it into a service is by taking a look at the core tenets for EKS. These tenets anchored our decision-making for how Amazon EKS should work. 
• #33: Our customers believe that there are tremendous advantages to running Kubernetes on AWS. According to a CNCF survey this year, 57% of Kubernetes workloads run on AWS today. This is entirely organic growth fueled by strong community of developers, customers, and partners. Let’s take a quick look at what your typical Kubernetes on AWS deployment looks like.
• #34: Now, with EKS, the complexity of standing up your own Kubernetes control plane is simplified. Instead of running the Kubernetes control plane in your account, you connect to a managed Kubernetes endpoint in the AWS cloud. This endpoint abstracts the complexity of the Kubernetes control plane- your worker nodes can check into a cluster, and you can interact with your Kubernetes cluster through the tooling you already know and love.
• #35: As of this morning, EKS is now Kubernetes certified. This is a big deal to us, and it helps us demonstrate our commitment to running open source/upstream kubernetes. Up stream open source experiance