Thank you for your question! I really appreciate that you enjoyed the book!
I haven’t used FLAME on AWS, and I don’t think there’s a straightforward way to implement it using native AWS resources unless you’re running a kites cluster and leveraging the FLAME kites backend.
From my perspective, Fly.io is a much better fit as a backend for FLAME because it spins up VMs extremely quickly and securely. I believe they achieve this using Firecracker under the hood, which is also what AWS uses to run Lambda functions. This backend effectively handles ephemeral VMs and provides a scalable networking layer, making it a solid choice for FLAME.
The FLAME kites backend, on the other hand, only allows you to assign resources if they are available in the node pool and can create pods, but it doesn’t offer the same level of dynamic VM provisioning.
AWS Lambda does support running Docker images, but these run in complete isolation, meaning you wouldn’t be able to connect them as distributed Erlang nodes as far as I know. Because of that, Lambda isn’t a viable option for FLAME in a distributed Elixir setup.