According to your description, the VPN is meant to bridge clients with other clients – so there is no need at all to additionally bridge it to the server's "eth0" interface. (That is, there's no need to set up a kernel 'bridge' device at all – the VPN server program will internally handle client-to-client bridging.)
Neither the games' operation nor the VPN's operation requires bridged access to the server's physical LAN – it is enough for the VPN to be an isolated Ethernet network.
And when the network is isolated from the server's physical Ethernet, then the VM provider becomes irrelevant – it will work on just about anything.
If i bridge the tap0 with eth0, will AWS's DHCP-server give IP addresses to clients?
I don't actually know the answer to that. (It might, since you always get a private DHCP service that isn't shared with other customers. Or it might not, since it's meant for VMs themselves only.)
If not, is there a way to still do this, like for example with virtual ethernet interfaces?
There is no need for any additional "virtual ethernet interface". If the VM is going to run its own gameserver, then
tap0 is the interface you need. And if the VM is only meant to relay data, then bridging between clients will happen internally within the VPN software.
Will I need to set up my own DHCP server then?
If you plan on using the VPN as a "site-to-site" bridge (i.e. connecting whole LANs together), then yes, you'll need a DHCP server somewhere.
But if the VPN is strictly client-to-client (i.e. each PC has its own VPN app and its own connection), then in many cases the VPN software itself will be able to assign IP addresses – without DHCP. For example, OpenVPN and ZeroTier both already assign addresses to clients by default.