DEV Community

Cover image for AWS App Runner - initial thoughts
Ganesh Swaminathan for AWS Community Builders

Posted on

AWS App Runner - initial thoughts

AWS just introduced a new service called AWS App Runner.

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.

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 - 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 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

🆕 Just noticed that there is a App Runner workshop 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!

Top comments (3)

aditmodi profile image
Adit Modi

Hi ganesh,
tried my hand at aws app runner, the service is pretty easy to use but for routing it to particular domain , they have yet to provide alias for app runner in the aws route53 ( similar to what they have for albs , cloudfront & s3 ) .
For now - Domain mapping is an issue.

rolfstreefkerk profile image
Rolf Streefkerk

thanks for the quick overview, i was considering this for a new deployment. I'll stick with the individual services for now.

berviantoleo profile image
Bervianto Leo Pratama

I'm exploring AWS App Runner. Seems like I should try another service then. It's quite expensive for simple and under-development applications.