What you need is source policy routing to route responses to incoming connections out the EC2 gateway instead of the VPN. Assuming that your instance's internal IP is 1.0.0.20 with default gateway at 1.0.0.1, and VPN IP is 10.8.0.20:
Create named routing tables (only needs to be done once)
echo 10 ec2 >> /etc/iproute2/rt_tables
echo 11 vpn >> /etc/iproute2/rt_tables
Configure the new routing tables with a default route over their respective gateways
ip route add 1.0.0.0/24 dev eth0 table ec2
ip route add default via 1.0.0.1 table ec2
ip route add 10.8.0.0/24 dev tun0 table vpn
ip route add default via 1.0.0.1 table vpn
Add routing rules to select the correct routing table based on the source address
ip rule add from 1.0.0.20 lookup ec2
ip rule add from 10.8.0.20 lookup vpn
This should allow you to set the default gateway to be the VPN and still have incoming connections work.
What you could do instead however, is configure your application to explicitly bind to the VPN IP (10.8.0.20) when creating outgoing connections, which will cause all connections from that application to go over the VPN, but all other outgoing connections go out directly. If you can't configure your application to bind to the VPN IP, you could add an HTTP proxy server to do this part.
I figured this out on my own.
In order to route based on the FQDN, one may need to run a DNS server on the client capable of detecting when a VPN is active on that FQDN's WAN address. When it detects an active VPN connection, it could resolve the FQDN to the VPN tunnel address instead, so that applications (web browsers, etc.) would receive the VPN tunnel address instead of the WAN address of the server. Since that would pose issues for SSL certificates that show which IP addresses are valid, one would really need a VPN-aware network driver capable of automatically and transparently tunneling data from applications over the VPN tunnel. It could be done, but I don't know if such intelligent network drivers exist. According to this response to a bad answer, you CAN ROUTE BASED ON FQDN with the appropriate configuration as I suspected:
As for the issue of duplicate Server IPv4 addresses being assigned to different VPN servers in a Windows 7 client, this appears to be by design. In Windows Server 2008/2012 Routing and Remote Access Services (RRAS), the server utilizes an IPv4 router which can be configured to use a static address pool like so. This static pool will determine the Server IPv4 address on the client. Here I've set my second server to use 192.168.2.0/24 as its subnet, so it will receive a server IP of 192.168.2.1 on the Windows 7 client.
My user account on each VPN server is assigned a static IP address in the Dial-In tab of the user properties under computer management. This will become the client's IPv4 address on the VPN.
Finally, to ensure that file sharing traffic must originate from the server's VPN subnet only, the appropriate protocols/ports in the firewall can have their remote IP restricted to to the assigned subnet:
Now, on the client, I can connect to file shares over the internet through this VPN which requires no 3rd party software at all. I simply map a network drive to each of the server's VPN addresses (e.g. \\192.168.1.1\sharedfolder and \\192.168.2.1\sharedfolder\).
Unfortunately, we cannot use the FQDN such as \\my.server.com\sharedfolder\ because Windows is not smart enough to realize that having a VPN connected to that IP address implies all traffic on all ports to that address except the encrypted VPN packets themselves should be be routed through the VPN IP. A side of effect of not being able to use the FQDN for the file sharing path is that windows may not keep the connection alive and will assume that it can be reestablished quickly as a local address, when in reality it will idle out after a minute and then take 30 seconds to reestablish a connection to the shared folder. This can be resolved by setting a higher idle timeout in the registry. The default idle timeout for a network share defaults to 600 seconds (10 minutes). To keep the connection alive longer, add a DWORD registry value named "KeepConn" to the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters", and give it a higher value (in seconds) such as 3600, which would be an hour. According to the link:
Increase the value of this entry if your application closes and opens
Universal Naming Convention (UNC) files on a server less frequently
than every 10 minutes. This decreases the number of reconnections to a
server.
UPDATE: I forgot to mention that although file sharing over VPN using purely built-in Windows 7 and Windows Server 2012 features, there is an extra step necessary for Windows Server 2008 because of some bug/feature where traffic on the SMB ports appear to be blocked on the default network adapter independently of the firewall. You must install the microsoft loopback adapter, which will then function identically to the default interface aside from allowing SMB traffic, so once you get it installed it should look like this. Then instead of connecting to the share on 192.168.1.1 (the Server's VPN address), you connect to 192.168.1.2, which is the loopback adapters address:
Instructions on how to install the loopback adapter can be found here: http://blogs.msdn.com/b/virtual_pc_guy/archive/2005/10/04/477195.aspx
Best Answer
Traffic routes are determined by routing tables. The best way to preserve your SSH connection is to configure a static route that defines the non-VPN gateway as the way to reach wherever it is you're coming from. This prevents the server from trying to route your SSH traffic over the VPN, which you don't want.