I would recommend having the 'topology' image up while reading through this

badlol.png

OK lets pretend I didnt rust this in paint in the shortest time possible but lets say we have the following, look at image one, we will have a local address of 88.0/24 and a vpn address of 0.3 on router B and a local lan of 90.0/24 and a vpn address of 0.2 on router A as well as vpn address of 0.1 on the VPN sever. Just a note on that we can re use the same address on the VPN interfaces since they have no subnet and will be point to point addresses

Moving on in this situation lets say we have full internet connectivity set up on all the routers, the vpn cloud server is set up and the 2 clients have established a connection.
The behaviour we will see from here is that the VPN server will be able to ping 172.0.0.2 and 0.3, router A will be able to ping 172.0.0.1 but not 0.3 and router B will be able to ping 172.0.0.1 but not 0.2 and none of these routers will be able to ping any of the lan addresses that they are not directly connected two.

Why is this? well when you set up a VPN interface it will not create any routers for you, lets pick on router A, if you looked at its routing table it would have 4 entry's:
1 would be the directly attached route for the lan subnet so it can reach your LAN, 1 would be for the directly attached rout for your ISP connection so it knows how to get to the gateway, 1 would be for your 0.0.0.0/0 route so you can get out to any unknown addresses (the internet mainly) and the last one would be a route saying you can get to 172.0.0.1 through your VPN interface.

In the routes I mentioned there is nothing to do with the other lan addresses or even how to get to the 172.0.0.3 address, so once we try and either get to 192.168.88.0/24 or to 172.0.0.3 from router A it will look through those list of routers and try and find what matches it, since we dont have a specific route for it in there it will end up going out your ISP route to the internet rather than going through the tunnel.

To fix this on router A we need to make a route entry saying how to get to this address, we make a route for this saying the destination address is 192.168.88.0/24 and then have the gateway as the VPN interface going to the cloud server. NOTE only do this on point to point addresses never use the interface on anything with a subnet if it is not a directly attached route
Ok so now we have the extra route the traffic will now be put through the VPN tunnel up the the cloud server but once it reaches there the cloud server doesnt have a route on how to get to the 192.168.88.0/24 route either so instead of going through the other interface it will be sent out through the internet again and fail.
So you guessed it we will be adding a route on the VPN server on how to get to the 88.0/24 subnet.

Once this is done our packet will finally be able to get from the local lan on router A to the local lan on router B the next question is if the traffic is getting to router B from A why does my pings not work?
answer to that is while the traffic is able to now get to router B it has to return, router B will look at the source of this traffic and see it was from 192.168.89.0/24 subnet, since it will not have a route for this subnet it will throw this traffic out to the internet and it will never return.
I bet you can see a pattern here it is just the same as router A, so on router B we will need to apply a route with the destination of 89.0 going through its VPN interface so it can hit the cloud server then on the cloud server you need to set a route with the destination of 89.0/24 going through the router A's von interface

Questions are 100% welcome as my explanation is probably as sloppy as my picture

You need to disable source/destination check on the EC2 instance.
Either from Actions -> Networking -> Change Source/Derstination Check, or through the CLI:
aws ec2 modify-instance-attribute --instance-id=<instance-id> --no-source-dest-check