Amazon VPC's network infrastructure assumes that all of the address space in the supernet associated with the VPC will be inside the VPC, associated with instance interfaces. Your VPN, being on the "other side" of one instance, isn't "inside" the VPC.
As such, you can't provision your VPN to use any subnet within the VPC's address block, if you want your VPN to work, because the VPC route tables will not accept the static route that you'd need, in order for traffic bound for the VPN to be routable from any instance other than the one that hosts the VPN. The routes for all subnets within the VPC's supernet are only ever implicit; explicit routes aren't accepted if they conflict, and a route to a subnet in the VPC's address space always conflicts.
10.8.0.0/16 includes 10.8.0.0/24 so that will not work. If your VPC is 10.8.0.0/16, your VPN would need to be something else, non-overlapping, like 10.10.10.0/24. Then you'd add a static route in the VPC route table, routing that subnet to the instance ID of the instance that functions as the VPN server.
So an inadvertent conflict is pretty much impossible, by the nature of the design of the VPC network infrastructure.