apprunner-roadmap
apprunner-roadmap copied to clipboard
aws
Support web sockets
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do * not help prioritize the request If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request Ability for the automatic load balancer to support web sockets
Describe alternatives you've considered Using Beanstalk and enabling web sockets support in application load balancer
Just curious if there's an update. It's been over 16 months. Close to 200 people votes on this.
Similarly, very keen to see even a brief word about where this is being prioritised from AWS team (@amitgupta85 please forgive the tag). Just to note (very selfishly), this is the one outstanding piece of functionality that prevents my team from migrating from Heroku, since our application uses websockets for GraphQL.
The top seven upvoted issues in this repo are all extremely desirable in my view, but this is the only one that outright blocks us from even experimenting with App Runner for our main app.
Top 7
Is there any update to this? My team wants to use App Runner for our streamlit applications, and this is a huge blocker for us
I opened a support case, got the "No plans to support this". Isn't the idea to prioritize based on likes? You would think so but the team seems to be operating using their own prioritization and not Community.
Yea this seems like something a lot of people would need. Unfortunate they're not people their customers needs first.
@gsogol @bnicholl @nebbles We don't have native support for web sockets at this point. However, it is possible to place CloudFront and API Gateway in front of an App Runner service which has support for Web sockets.
For CloudFront, you can put a CloudFront distribution in front of a public App Runner service. For API Gateway, you have couple options
-
API Gateway in front of public App Runner service - You can use API Gateway HTTP proxy integration feature and put App Runner service behind an API Gateway. The traffic will flow from API Gateway -> public App Runner service. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy-for-http.html
-
API Gateway in front of private App Runner service - Make the App Runner service private (accessible within a VPC) and use API Gateway VPCLink with HTTP proxy integration feature to put private App Runner service behind an API gateway. For VPCLink, you will have to set a NLB with targets as IP address of PrivateLink VPC endpoint. The traffic will flow from API Gateway -> NLB -> VPC endpoint -> private App Runner service. You can share the same API Gateway, NLB and VPC endpoint to access multiple private App Runner services so the cost of non App Runner infrastructure components (API Gateway, NLB and VPC endpoint) is shared as well as it is their one time setup and does not need to be repeated with every App Runner service - https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-private-integration.html
For CloudFront, you can put a CloudFront distribution in front of a public App Runner service.
IIRC I did this very thing for Server-Sent Events, but to no avail. While yes, CloudFront does support WebSockets, the fact that the Envoy proxy used by AppRunner limits requests to 30 seconds means that this point is moot.
+1 to the AWS team prioritizing this.
I guess the App Runner team is very short-handed, making me worried in thinking to host my application with it.
Updates here would be much appreciated AWS team. I've just finished moving all my apps to app runner, spun up a test environment and only now realise there's no web socket support. I moved from a more complex (to manage) ALB/EC2 setup that supported it, so I expected it to be supported here.
Basically, I now have to move off App Runner to something else after spending hours/days moving my apps here - it's super infuriating.
@amitgupta85 All my hopes are on your post to save lots of wasted work. I've put a Cloudfront distribution in front of my public app runner service URL - but my app still seems to be getting a 403 when trying to open a wss:// connection - have I missed something?
We are taking a look at the CloudFront issue and will post updates soon. In the meantime, you can also try out the API Gateway option by following putting API Gateway in front of App Runner (as discussed above) and enabling web sockets on API Gateway - https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-integration-requests.html
@amitgupta85 or you can prioritize web sockets in AppRunner and call it a day. Community over internal priorities should always take precedence 🤔
It's not actually just websockets that's failing on a cloudfront distribution in front of my public apprunner endpoint, it's any request. Are there any special settings required above a normal origin-using-the-public-url? Does it have to be a custom domain? (I'm using my awsapprunner.com subdomain currently)
I guessed my way through a Websockets API API Gateway setup, because your instructions are pretty vague. I used a $request.body.action route selection expression, and in the $default route I connected an HTTP PROXY integration to my awsapprunner.com URL. I deployed to a stage called 'Prod' which gave me a url like this:
https://a1ykizot66.execute-api.ap-southeast-1.amazonaws.com/Prod/@connections
I think that means I should expect https://a1ykizot66.execute-api.ap-southeast-1.amazonaws.com/Prod/ping to return "Hello World"
to behave the same as https://gx6d3sumsa.ap-southeast-1.awsapprunner.com/ping which returns "Hello World"
.. which it does not. Although I've almost surely missed something because API Gateway is so complicated, any idea what?
For readers. I couldn't get this working with Cloudfront. Using the app runner domain it returned 404s/403s, after configuring a custom domain it only returned 502s.
Instructions are insufficient for API Gateway and I couldn't figure it out.
I've had to bail to Lightsail Containers (LC) until this gets sorted out but with barely any signs of life from the AppRunner team it seems unlikely.
Trade offs:
- No github integration
- LC lets you deploy images from your ECR but unfortunately doesn't have auto-hooks to deploy images on push, it requires a manual jiggle in the AWS UI.
- Also its logs don't integrate with Cloudwatch logs and are fairly cumbersome to use.
@henricook thanks for sharing your solution here, I appreciate the details. 👏 FWIW, I also had to find another solution for my own WS/SSE-powered containerized app and ended up having to create an entire ALB + Fargate Service just to run it.
IMO it is very disappointing that this issue has remained open for so long, with so many upvotes, with so little communication/guidance from the AWS team. Although I was able to navigate around this issue for a personal project, the lack of WS support in AppRunner has caused our team at work to re-evaluate deploying our service on AWS entirely, as we are currently leveraging multiple cloud providers at the moment. I would think it would be in the AWS team's best interest to prioritize this request, as without it, GCP's Cloud Run will continue to siphon current and potential customers away from AWS. 😞
We don't have native support for web sockets at this point. However, it is possible to place CloudFront and API Gateway in front of an App Runner service which has support for Web sockets.
For CloudFront, you can put a CloudFront distribution in front of a public App Runner service.
@amitgupta85 I'm not sure I understand how CloudFront would solve this problem. If the App Runner load balancer doesn't support WebSockets, how would adding an additional layer in front of App Runner enable it? Could you clarify? Thanks!
This is something that you already have on ELB , api gateway etc why not just activate it on app runner ? Currently app runner is extremely easy to use but a modern need of apps as real-time is put under appreaciated
Is there any update on this any way around to use websockets with app runner without adding load balancer
Thank you for having patience on this issue. We would like to get some feedback on maximum request timeout that you would like us to have for Web sockets support in App Runner.
All websocket libraries have their own timeout and reconnect functionality already and timeouts shouldn't really be something that happens when you app runs normally.
There’s also the need that some endpoints have different timeouts than others . It will be nice to keep it as normal as possible.
On Fri, 28 Apr 2023 at 7:05 PM amitgupta85 @.***> wrote:
Thank you for having patience on this issue. We would like to get some feedback on maximum request timeout that you would like us to have for Web sockets support in App Runner.
— Reply to this email directly, view it on GitHub https://github.com/aws/apprunner-roadmap/issues/13#issuecomment-1528264239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJOJFKZBMXTNJ7YTDBQNFLXDRLLFANCNFSM45D3LC7A . You are receiving this because you were mentioned.Message ID: @.***>
-- Daniel Vengoechea Head of Growth e-me.co
-- Pd: Conoce nuestra nueva página web www.e-me.co http://e-me.co/?utm_source=email-signature-pd&utm_medium=email&utm_campaign=email-signature-pd
@amitgupta85 Socket.io and many libraries default to 30 min. Your question, however is a maximum timeout. So not sure there. Many of us will be super happy just having websocket support regardless of the maximum value. Many libraries provide events for us to handle timeouts and ability to reconnect. So I will default to saying 30 min - 60 min.
But even if you're thinking in seconds, I'll take that and just handle timeouts myself (easy enough) as long as the wss actually goes through.
Any approximate timelines?
App Runner currently supports 2 mins of maximum request timeout. We are looking to understand what would be a reasonable maximum request timeout for web sockets support and if App Runner needs to support higher maximum request timeout as a prerequisite. If that is the case, what would be its value. Thank you.
it is difficult to provide a general recommendation, as it will depend on the specific use case and the resources available. However, a reasonable starting point for WebSocket connections might be in the range of 5 to 10 minutes, with the ability to configure this value as needed based on the application's requirements.
On Fri, 28 Apr 2023 at 9:53 PM amitgupta85 @.***> wrote:
App Runner currently supports 2 mins of maximum request timeout. We are looking to understand what would be a reasonable maximum timeout for web sockets support and if App Runner needs to support higher maximum request timeout as a prerequisite. If that is the case, what would be its value. Thank you.
— Reply to this email directly, view it on GitHub https://github.com/aws/apprunner-roadmap/issues/13#issuecomment-1528546562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJOJFPPDYWS745NLVZ2ELDXDR7D5ANCNFSM45D3LC7A . You are receiving this because you were mentioned.Message ID: @.***>
-- Daniel Vengoechea Head of Growth e-me.co
-- Pd: Conoce nuestra nueva página web www.e-me.co http://e-me.co/?utm_source=email-signature-pd&utm_medium=email&utm_campaign=email-signature-pd
App Runner currently supports 2 mins of maximum request timeout. We are looking to understand what would be a reasonable maximum request timeout for web sockets support and if App Runner needs to support higher maximum request timeout as a prerequisite. If that is the case, what would be its value. Thank you.
Makes sense. Standard http requests should be quick. Those who are running jobs obviously will take longer. Those who run a websocket connection will be the longest. The key is to not scale down while the websocket connection is live and active.
Maybe start with 10 min?
App Runner currently supports 2 mins of maximum request timeout
Is this the case even with data actively being transmitted? Heroku's approach^1 is:
"An application has an initial 30 second window to respond with a single byte back to the client. However, each byte transmitted thereafter (either received from the client or sent by your application) resets a rolling 55 second window. If no data is sent during the 55 second window, the connection will be terminated."
This is great since provided everything is healthy, the client and server can confirm with keepalive pings, keeping the connection open.