Theres nothing wrong with this per se. I would never have clients directly call AWS resources like specific lambdas etc in your account. I would always put them behind some form of ‘proxy’ for a bunch of reasons:
- Security - only have permission to call one specific thing ie APIGateway etc. Clients only know about a very generic endpoint, not how you architectured anything
- Availability - If you need to migrate that resource, or its overwhelmed its much harder if its directly exposed to your clients.
So having clients talk through a WebSocket like thing, is probably a good idea.
Obviously, a lot depends on how you architect your back-end gameservices platform. For websockets you probably need a way to ensure disconnect/reconnect happens for your clients in a way that matches your security/identity needs (ie maintain player id, don’t allow others to grab the connection and identity etc)
Obviously GameLift is restful like async call pattern so you’ll likely need a queuing/blocking/throttling scheme to ensure requests from your clients don’t overwhelm downstream services ie restrict number of calls in flight for a given client ie (1 matchmaking request at a time).
And you need a strategy, depending on how you implement your server socket layer, to migrate clients ‘seamlessly’ from ‘Compute A’ thats running the socket service, to ‘Compute B’ as all compute is fallible (plus all the normal stuff around scaling socket services etc). Some services, though have a routing layer on top, so your disconnect/connect logic can just be the migration path.
Hope some of that is helpful. Hopefully others may share their experiences.