We are incredibly excited today to introduce @awscloud#AppRunner: a fast, simple and cost-effective way to launch an auto-scaled, highly available and secure containerized web application from source code or container image to the cloud. A mini thread. aws.amazon.com/apprunner/ /1
Did you ever wish that launching a container in the cloud was as simple as launching one on your laptop? Do you spend more time managing orchestrators than your app? Would you rather have @awscloud deploy and auto-scale your app to meet demand? aws.amazon.com/blogs/aws/app-… /2
#AppRunner lets you create an auto-scaled HTTPS service with a single command or a few clicks in console. Point to your container image and ... that’s it! With smart defaults, your application is running on a secure public endpoint within a few minutes! aws.amazon.com/about-aws/what… /3
Integrated logging and metrics in @awscloud CloudWatch. TLS and custom domain names for your endpoint. Configurable health checks. High availability across AZs. Automated deployments. GitHub CI/CD integration. aws.amazon.com/blogs/aws/app-… /4
Configure how much CPU and memory your container instances need, how many concurrent requests each instance should process to meet your SLA. #AppRunner takes care of the rest. aws.amazon.com/apprunner/gett… /5
#AppRunner auto-scaling works by actively tracking incoming requests and responses, and automatically maintaining the right number of instances to meet the demand for your service. With dynamic instances, you only pay while your instances are processing requests. /6
You can also configure #AppRunner with provisioned instances which are always ready to serve requests. /7
#AppRunner works with partner solutions to provide a variety of capabilities, including monitoring, logging and devops. See our partners page for more details. aws.amazon.com/apprunner/part… /8
#AppRunner runs on @awscloud#Fargate. Each AppRunner instance is an isolated copy of your container running in #Firecracker with @containerd. Watch our "Fargate under the hood" session from re:Invent 2019 for a deep dive: /9
@awscloud Container Services teams are hiring! Come work with us on #AppRunner, #Fargate and more! We have opportunities ranging from low-level container runtime and Firecracker work to large-scale distributed systems. amazon.jobs/en/search?offs… /10
Finally, this team deserves special recognition for everything they have delivered this year under unfortunate and difficult worldwide circumstances. Our hearts go out to all who have been affected. /11
A significant portion of #AppRunner was built during the pandemic by people who haven't even seen each other in person. #AppRunner, #ECS and #Fargate teams supported each other and made this happen! This means more than any technical achievement. Go team! /12
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Today during the #reInvent keynote, we have announced Amazon #EKS on #Fargate. So proud of my team! AWS customers can now run both native #ECS tasks as well as #Kubernetes pods on Fargate. In this thread, I'll try to explain our reasoning behind some major design decisions. 1/n
For #EKS on #Fargate, we wanted to give customers a native k8s experience. You can use your existing tooling to run pods on Fargate. Fargate operates at the task (ECS) and pod (K8S) level, so any higher level abstraction (deployments, replicasets, etc.) built on top works. 2/n
When designing #EKS on #Fargate, instead of building a one-off integration with Kubernetes, we've asked ourselves "What additional capabilities does Fargate need in order to become a service on which other multi-tenant serverless containers offerings can be built?". 3/n