I believe AWS App Runner can be improved with more VPC flexibility, which is not available yet, and better observability and debugging tools. AWS App Runner is lacking debugging tools. There is also limited customization compared to ECS and EKS, which is required, and pricing optimization for always-on services is something that is essential with AWS App Runner. While AWS App Runner is excellent for simplicity, it is not ideal for complex production workloads requiring deep control. If I had more control over networking, that would be very helpful.
Senior Java Consultant at a comms service provider with 1,001-5,000 employees
Real User
Top 5
Mar 21, 2025
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.
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.
AWS App Runner is primarily used for deploying and scaling web applications and APIs, known for its seamless integration with GitHub, automatic scaling, and serverless nature.
AWS App Runner allows efficient deployment and scaling of web applications and APIs by offering automatic scaling without complex configurations. It smoothly integrates with other AWS services and simplifies the transition from development to production. Users value its serverless nature, reducing operational...
I believe AWS App Runner can be improved with more VPC flexibility, which is not available yet, and better observability and debugging tools. AWS App Runner is lacking debugging tools. There is also limited customization compared to ECS and EKS, which is required, and pricing optimization for always-on services is something that is essential with AWS App Runner. While AWS App Runner is excellent for simplicity, it is not ideal for complex production workloads requiring deep control. If I had more control over networking, that would be very helpful.
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.
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.