AWS App Runner - initial thoughts
Tags: aws, containers, beginners, cloudskills
Published: 2021-05-19 11:02:54

AWS just introduced a new service called [AWS App Runner](https://aws.amazon.com/apprunner/). 

There is a simple "Whats New" service announcement [here]().
Ignore that as there is a lot more details here in the AWS Containers blog from Martin Beeby [here](https://aws.amazon.com/blogs/aws/app-runner-from-code-to-scalable-secure-web-apps/).

These are my first few thoughts after reading the announcement (and not yet having tried the service) - some of these may need refining over time as I could be wrong!

# The Good 

* This looks very close to Google's [Cloud Run ](https://cloud.google.com/run)  - Something I personally have commented at several forums as something AWS needed to replicate

* This service abstracts away creating an ECS Cluster, Fargate Services, ELB's, TLS Certificates and setting some basic monitoring and auto scaling rules - so really trying it to make it as simple as a docker run (but with added advantage that it runs directly on AWS and provides a nice endpoint)

* Unlike Lambda, a container / service handles services (upto 80 concurrent connections) and THEN it scales into multiple services - it looks to be purely connection rather than vCPU or Memory driven . Developers may need to make sure their containers can handle 80 connections within the base vCPU /Memory allocated or else higher load may crash the container before autoscaling kicks in? _(something to test out)_

* Re-using the same running container reduces cold starts for new connections coming in 

* No Cold Starts on scale out! Wow - this is a huge advantage over Fargate in my opinion. I am going to wait for one of the AWS heroes to scale test this and report the latency seen etc (they always beat me to these things!)

* Being able to set a ceiling for the maximum limit of connections can avoid runaway load and keep a check on the costs

* Support for Customer Managed CMK (not sure this extends to the instance running the actual container or the ephemeral storage used)

# The bad 
* Private container registries are not yet supported (may have to raise a request on the container roadmap) - this has been a challenge with Lambda support for containers as well. There are some reasons to not using ECR for some teams. 



* ~~Pricing looks about 50% higher than Fargate on its own. It is definitely not a fair comparison as this includes a few other services but an ELB is like $0.0225 per hour on its own. I will try to add up the services it abstracts to see if the pricing is justified on its own OR if there is a small premium for such a fully managed service / ease of use~~

* Actually scratch that above statement! Pricing is convoluted / misleading.  I was mistaken when reading the post that there is a $0.064 per hour compute charge (Fargate pricing is about $0.04048 per hour in comparison and that was behind my 50% more expensive comment). 

There is a "provisioned" capacity fee (just memory at $0.007 per hour/GB which in Fargate is $0.004445 per hour/GB - approx 60% cheaper in Fargate ) and then a higher active utilization fee!  

You need to really dig into the [pricing examples](https://aws.amazon.com/apprunner/pricing/) for details. A __test instance will cost $5 a month but that is if you PAUSE the service for 22 hours a day!!__. The $25 a month example is for a single 1 vcpu / 2GB container busy for upto 8 hours a day. 

Combined with the fact you can set a ceiling of tasks, I would think most developers can be managed around $10/month which is a bit more expensive than say running a Lightsail instance but the added ease of use could be worth it. 


# The (not so) Ugly?

* This looks to be for services that are open on the public internet only? A "private" service for those who can run within VPC / restrict the endpoint to use (say within your organization / Enterprise) would be awesome. I wonder if you can customize the endpoint with some kind of an IP / ACL / WAF rule...

* The BIGGEST issue I see of concern is there was no call out / mention of Scale to Zero. After reading through the pricing example and realizing there is just a small memory charge for idle instances, its not that "Ugly" but Google's Cloud Run billing is _"Only pay when your code is running, billed to the nearest 100 milliseconds."_. 

A true _zero cost when idle_ can be really advantageous. I guess that's the premium you pay for having zero latency for the very first request (There are cold starts for Google Cloud Run when the service has scaled to zero). 

#Looking forward

:new: Just noticed that there is a [App Runner workshop](https://www.apprunnerworkshop.com/) available!

This could be an awesome new service and a great starting point for all new AWS developers wanting to deploy containers and even some smaller projects in Enterprises. I am hoping to learn more and experiment with this (and will update this post if any of my initial learnings are incorrect).

Stealing a comment from a colleague - this could become the "App Ruiner" for every other complex service in AWS!