AWS App Runner Gets a Killer Feature!

Back in May 2021, we published a blog on the benefits and drawbacks on AWS new container managed service, App Runner. Since then there have been incremental features to improve the service, but on 9th Feb 2022 – AWS released a feature that the community had been crying out for…

Support for Amazon VPC

Now this doesn’t sound very exciting, Amazon VPC is just networking? True, but up until now AWS App Runner has only been able to communicate with services over the internet. If you wanted to deploy an App Runner web service and have it connect to AWS RDS (Database Service) for example, you would have to make the database public and all outbound communication from App Runner would traverse the internet to your public facing database.

Now this kind of design goes against best practices and the AWS Well-Architected Framework – publicly exposing your database is definitely not a good idea and if your app is heavy on moving data it could increase data transfer costs.

AWS are well aware of this and have been working on a solution to allow applications running on App Runner to communicate with AWS services privately. Their solution introduces VPC Networking Mode.

This new feature utilises an underlying service, VPCConnector – which acts as your gateway for external communications from App Runner to AWS hosted services. In order to utilise VPC Networking you must create your own VPCConnector which can be done through the wizard by clicking ‘add new’…

When creating your VPCConnector there are a couple of decisions that need to be made

  • VPC – The VPC in which you want your App Runner service to connect to,
  • Subnets – The subnets to deploy the VPCConnector (These don’t have to be in the same subnet as your resource, e.g. RDS, but must have routable access to it),
  • Security Groups – Since VPCConnectors only deal with outbound traffic from App Runner, only the outbound rules need to be configured to allow access to your AWS hosted resource. (Your RDS for example will need to allow inbound access from this new security group).

Once setup – your App Service should be able to securely communicate with your AWS hosted services securely over private communications!

There is a small point to be made here – inbound communications to your App Runner service must still come over the internet using the public URL it is hosted on. This means that if you want your AWS hosted services to initiate the communication to App Runner – this can’t be done privately at the moment.

So how does App Runner stack up against other AWS container services now?

AWS App Runner is a service which is designed to be lightweight and easy to use. It is intended to abstract most of the required knowledge for securely hosting containerised applications on AWS away from developers, allowing them to deploy applications knowing their service is using scaling, resiliency and security best practices.

For these reasons, AWS App Runner can never compete with the likes of ECS/EKS for enterprise level container orchestration – to add more features to AWS App Runner would undo the very use case it has been designed for. It’s the features like these that make App Runner so attractive to customers new to AWS or containers

  • Automated Deployment Pipelines – No need to establish CI/CD environments, AWS can do the heavy lifting,
  • Automatic Scaling – App Runner scales to meet demand automatically,
  • Secure by Design – Fully managed TLS setup,
  • Logs & Metrics – automatically ship logs to AWS CloudWatch.

There are allegedly 17 different ways you can run a container service on AWS – but let’s compare the most popular services…

We hope that gives you some idea on the options you might take to deploy containers on AWS, as always please get in touch for any advice or help. For more information on App Runner’s new feature behind the scenes, please see this AWS blogpost.

Enterprise and public sector trust Mobilise to securely transform their tech, teams and how they do business.

Say hello to your independence with our project enablement approach.