If you could run IPFS in a server-less environment you probably would not want to because ...
Expensive
Slow
Technical Limitations
Long Version:
The consistent and significant CPU, Memory and Network resources that running a IPFS gateway currently requires it would be impractical to run in most server-less environments as you are billed heavily for resources compared to more traditional reserved infrastructure for this type of workload.
In-order for an IPFS gateway to be able to resolve requests it must first discover and connect to other nodes, this leads to a warmup period in the 10s of seconds before and real “work” can be done so rapid start/stops is impractical in most cases.
The gateway must remain online in-order to serve any files you have added to it. If a file you add becomes popular enough then you can safely stop your node / remove the file as it is now replicated across the network and others can serve it, however if the file is not popular it is best to keep your own copy available to ensure it remains accessible.
Most server-less environments have a heavily NATed networking environment meaning inbound connections are generally not possible.
Solution/Workaround:
For nodes with a lifespan ranging from minutes to weeks a container based (Docker/Kubernetes) solution would probably be best, and for 24/7 nodes traditional VMs/reserved instances.