AWS App Runner Reviews

I use AWS App Runner as a development platform. I create a service locally with Docker containers, and then I'm able to start it up to test. If I need to make a backup, I just put it on a different port to test different configurations. Once I have my services working, a team handles the DevOps for production deployment.

Using AWS App Runner, we reduced the need for a separate DevOps team, leading to significant cost savings. There was a three hundred percent return on investment by consolidating roles.

With AWS App Runner, performance monitoring and tracing are enhanced. I can restart services without using the command line, and it's a very user-friendly visual tool. It greatly impacts operations when running. Our company realized tremendous cost savings by eliminating the need for a separate DevOps team. AWS App Runner automates many processes, ultimately saving on labor costs and improving efficiency.

There are too many technical details for a single developer to know, making it overwhelming. It would benefit from a roadmap wizard or templates to guide developers. AWS App Runner should have a wizard and templates to simplify creating a REST service. Developers need clearer guidance to avoid spending excessive time understanding the system.

AWS App Runner is designed for large companies. It allows for easy scaling, just by investing more money, without needing to buy more machines. It can scale down when there's less demand, saving money.

I did not reach out to AWS for support. Instead, a person at my work who was certified in AWS App Runner showed me how to use it. Without this, the knowledge would have been overwhelming due to the vast technical requirements. I learned from observation and took notes.

Setting up AWS App Runner is not particularly hard, but knowing every detail involves a vast amount of knowledge that a developer may find overwhelming. It would benefit from a wizard and templates to help streamline the setup process.

The implementation involved someone who was certified showing me what to do. There was no formal training provided by AWS.

Our company experienced a three hundred percent return on investment by reducing the need for a separate DevOps team and consolidating responsibilities. However, the initial setup required significant resources and knowledge.

To get AWS App Runner up and running, significant resources and expertise are necessary. One individual must have sufficient knowledge, which can be costly for startups but feasible for larger companies.

I would rate AWS App Runner an eight. It offers excellent scalability for larger organizations, providing significant cost savings and efficiency improvements. However, it is not ideally suited for startups due to the high initial investment and vast knowledge required. It's essential for businesses to have either an in-house expert or a consultant for setup.

I think the solution is growing in size. It's like a multi-tier website that wants to provide some microblogging data being collected personally, but it does so in different tiers. The first one is closest to AWS. Another one is encrypting and decrypting data so that it is not very easy to eavesdrop. This user interface is in a web browser and shows textual information with a few analytics graphs.

It's still kind of an experimental thing. It's probably in this condition because I'm not selling or monetizing the product. It's a very good illustration of how you customize your expectations of the services you're developing and try them on the different implementations of the AWS compute services because they're changing. There is something new every two years or so, and it's evolving.

I like that the solution is easy to start with. You approach it via the AWS console. You try repeatedly, and it starts working perfectly at some point, which is great. As a second step, you try to re-implement the whole deployment process in code. Instead of using the web browser and filling in some fields, you go to your project and add a special file they want you to name App Runner.

In that file, you'll put your configuration like an infrastructure in code that basically tells all the service parameters so that it will deploy your service automatically. The next time you want to use the service, go to the codes you pointed to. It also discovers and recognizes the special file named App Runner. Then, it reads it and passes it.

It knows the parameters, such as where the variable would come from, what kind of compute instances should be used, how big they should be, and what memory should be attached. All those parameters don't need to be fed into the console manually in the web browser anymore because they are automatically passed.

While fighting some of the issues I was facing, I also found that others were complaining about the things I've been noticing. I'm sure addressing those things takes some time because AWS App Runner is more or less a new service. I'm unsure if it's some technical issue that developers are trying to overcome or if there is something architecturally underlying the whole service that is difficult to change.

When you try to deploy some code that you've written and tested on other platforms, you should also tell the system what your configuration would be. You usually supply a list of environmental variables that tell what other services your services could communicate with and what kind of parameters need to be tweaked.

This kind of information is typically separate from the codes of the original service you've written. This kind of separation has been addressed in the AWS App Runner service, but it is addressed at one of the later stages of deployment. It should be addressed everywhere.

There is a way to circumvent this. Most people say it will be changed and improved, but it's obviously taking some time. When you point the AWS App Runner service to where your code is, and the service starts to process it, it has to build it first.

In the build phase, they say you can supply a list of environment variables for your configuration. However, you can't supply a list of environmental variables that are secret in the Secrets Manager Service available that is very useful or important. You could supply the list of environment variables plus the list of secret variables that you have in the other service.

It is possible to use it at the later stage of deployment to run your application units using the same AWS App Runner service. It seems like it's the same thing. However, the developers have implemented it at a later stage, which is very useful for us AWS users and not in the intermediary step, which is also very important.

There are some ways to overcome this, but they're not natural, and that's what people say. I suspect that this will be on the service's roadmap, and probably next year, it will be totally solved.

I have been playing with AWS App Runner since 2020, but I found the time to go more in-depth into it since May. I'm more or less new to it.

I never saw a single crash when the solution was running. The solution works fine once you get it running, but it's difficult to get it running sometimes. It takes some experimenting and time because we have to try and fix something, and in three days, it's ready and working.

I rate the solution’s stability ten out of ten.

The main benefit of the solution's scalability options is that they are totally automatic. Instead of manually supplying the load balancer and virtual machines you want to run and telling how many instances those should scale to, AWS App Runner has everything pre-configured for you.

The upper limits of instances are fixed to 25 in the beginning. I am sure you could probably customize it. You just put another line in the special configuration file I mentioned. You can scale up to 50 instances or up to the quota limits on the underlying EC2 service you want to use. You could scale as much as you want. If you don't, you need to call the service guys at AWS and tell them you want to increase the limit, and they'll do it for you. I'm sure that should be possible.

When your service grows bigger and customers start using it a lot, it will automatically spin up new virtual machines or new instances, which will work synchronously under the best practice that AWS would recommend for load balancing. You only pay for all the instances spun based on special moments when there is a big supply. For example, a lot of customers would come on Black Friday.

You pay as much as you have been using up to the limits of 25 machines, in my case, at the same time. Since my project is small, it actually scales to one machine when it's working and back to zero, which is also a great feature. When you scale down following low demands, it would be great if your services scale down to zero and not just to one machine running all the time. I think this service is great because it does so.

I've read in a few social media posts that AWS App Runner is more or less like a basic automated compute service that can hit some boundaries. I've never actually managed to hit those boundaries. I am the only one using AWS App Runner in our organization because I'm mostly experimenting with this project. I'm not showing it elsewhere in production, and it's a small project.

I rate the solution’s scalability an eight to nine out of ten.

For cloud computing, we have been using AWS from the beginning. Earlier, I looked at Microsoft technologies when there was no cloud paradigm, but it didn't make me switch to the Microsoft implementation or Azure cloud. I have been happy with the AWS cloud implementation, which they originally started in 2006. I didn't have to resort to other clouds like Azure or Google.

I've been using Google Cloud for storage because it has a straightforward way to automatically synchronize your storage files or information between devices. Google Cloud is easy to use, unlike AWS. I'm also using a lot of Amazon S3 (Simple Storage Service) when I want to put my data closer to the AWS cloud.

You can run Google Drive on Windows, Linux, or Android, and it works. There is a document service that is trying to be equivalent to AWS, but they just announced last month that they're canceling it next year. You could share your documents with other end-user devices, whether Windows, virtual machines, or Desktop as a Service (DaaS) infrastructure, and I've been using it for two or three years.

However, they just announced that it will be decommissioned in 2025. There may be something else in store about end-user computing and document management that would probably arrive on Google Drive. For today, Google Drive is good enough for me for storage.

Operational costs are directly connected to the time the underlying infrastructure is running. Because I'm automatically scaling down to zero, it rightsizes the payments following best practices. What is promising is that rightsizing is the guiding principle that AWS recommended following. Here, it comes out of the box because it's a higher-level service.

It uses the underlying fundamental compute services, but it does so by following best practices. Since I've been trying it with more or less small projects, I haven't been testing this under loads. If you have a huge requirement in some banking system with machines running and responding at the millisecond level, AWS App Runner is not the right solution for them.

I think it's great for mid sized projects because it's easy and right-sized. However, it's probably not optimized for big projects needing lower latencies. Those load tests need to be done by some people planning to implement the solution for a bigger system.

Scaling into bigger solutions could be problematic because they're so automated that I'm not sure that they should be optimized for any case. This is just one way to approach compute services because there are probably five or ten ways to approach them in AWS.

An alternative would be to run your services on ECS (Elastic Container Service). When you run them on the Elastic Container Service, you can also choose one or two ways to run them. You could either provision automatically in a few instances and virtual machines working all day long, or you could provision them in a serverless manner via Lambda functions.

They scale up and down automatically and run only when needed, which is a different paradigm. You could try both and see which one is better for your case. You could experiment with this and probably go to more scalability when using the underlying compute infrastructure in a more managed way.

In my case, when using AWS App Runner, I skip this level and go directly to the value I want to obtain by trying to point AWS services to my code, and then they figure out the best way to run it. These are two different approaches. If I face some challenges, I will go to a lower-level possibility to utilize the services to manage and scale them appropriately if needed.

If ECS (Elastic Container Service) is not enough, the project might probably be more suitably implemented with the EKS (Elastic Kubernetes Service) for workloads optimized for Kubernetes. This is also another approach to compute. The great feature of AWS is that you have a few different approaches and a few different levels that you could try to scale with.

After you try them all and see which of those methods gives you the best metrics, you can invest more in that direction. If not, you go to the other one. If you try two or three options for tolerance and balancing between different options, you'll always have another one to switch to if something goes wrong with the first one. That's a great feature that allows you to skip to the other one that you've been testing if you don't like the service you're using.

You pay as much as your infrastructure and provision are running. If it's scaled down to zero, the infrastructure is not running, and you don't pay. This is a great feature. As long as some of your instances are unhealthy and fail health checks, the load balancer abandons them and spins new ones. Your prices are going up because you need more infrastructure to accommodate this disruption so that there are no more disruptions.

The scalability is automatic. This means that your expenses grow automatically as much as the scale spins new instances, which is up to 25 in my case. I'm not paying for more than 25 instances running at the same time. I have also configured everything in the beginning, including telling the system how big I want the instances to be, how many CPUs I want, and what kind of memory I want.

I know what to expect in terms of pricing if the scaling kicks up and goes to the upper limit, which is great. It is right-sized. Also, there is another dimension in which you should be paying. It is a very small one, but it's annoying to some of the people I've been seeing comment on the service. Each time it deploys a service that uses automatic load balancing, you pay something like a dollar or a euro on a service-by-service basis.

This is another secondary dimension of your expenses. The more granular your services are, the more load balancing it should provide for you. You need to pay an initial price every time, but it's so low that it's negligible compared to the cost of running the rest of the infrastructure. Since the second dimension is so small, people complain that it shouldn't be there at all because it's annoying.

In three weeks, I managed to deploy the services that I wanted. Out of the four services I deployed, three of them went just fine. The fourth one was more problematic because it was deployed successfully on the tenth attempt. It needs some customizations because it's more complex. Build processes rely on external factors that need to be adjusted so that they would run within the boundaries of AWS App Runner.

AWS App Runner provides an easy way to deploy higher-level compute services instead of individually managing compute instances of EC2 service. EC2 are virtual machine boxes that you can start and stop whenever you want to. If you also automate some kind of monitoring on those instances and put a load balancer above it, you are managing your automation manually.

However, if you need a simpler website or service deployment, you would typically want to try to utilize some kind of managed service that AWS manages for you, and you are paying by a different scheme. You are not paying upfront for the number of hours your machines are running, but you are charged for the value you get from the service.

That's where the managed service is sometimes preferable if you want to optimize the value you get from AWS services. That's why I decided to try those. They were really easy to start with, which is also interesting. When you have a vast sea of choices, it's a good idea that you could experiment and try your own things. Some things get started much faster than others. AWS App Runner was okay for my purposes.

They have some kind of phase when you're consuming the services. However, they also have a separate phase when you're building or working through the service. You typically write your source code somewhere. You also write a lot of procedures, like what to do with the source code, what your DevOps processes are, or what your data pipelines are that should convert the data in the format you need.

I'm running some of those in the cloud automatically or in some batch processes. I'm running the others on the workstations that I'm using. Those workstations can be physical or remote. The desktop service runs in the AWS cloud. There is a service called workspaces, and if you spin up a workspace in the AWS cloud, you can tell it to do different batch processes.

This is another way to run those remotely. Sometimes, preparations for those processes can be done at the front end, on the workstations, and not at the servers of the underlying cloud. That's why it's hybrid.

I would recommend the solution to other users because it's very well-targeted where we all need to be. You'd like everything to work out and spend less time with the inner workings, and it's doing this job just perfectly. Three of the four services work out of the box very easily. The fourth one has problems, which means that even AWS App Runner is not perfect.

I'm sure that the problems are not connected to the solution itself. The source code I've been trying to give it to deploy has some issues that must be addressed. It has been optimized for another platform and not for the AWS cloud. If you optimize it for the AWS App Runner service, it should work out of the box again, but it will take some time.

Overall, I rate the solution ten out of ten.