Although you may or may not be doing all of the things illustrated, your setup is essentially the same as VPC Scenario 3.
In a nutshell...
Create a new VPC route table.
Set its default route (0.0.0.0/0) to point to your Sonicwall, which will have been assigned a virtual private gateway identifier inside VPC -- it looks like
Associate the subnet(s) where your instances without public IP addresses are located, with this new route table.
You don't need to configure any routing on the AWS side to allow the traffic from the tunnel to reach the instances. This is always possible in VPC -- the VPN is trusted as far as routing is concerned, so routing inbound traffic to the subnets where the instancea are located is implicit.
This will send Internet-bound traffic from the VPC instances out the VPN connection, with their private IP addresses intact. The Sonicwall will need to be configured to do the necessary network address translation on the traffic to allow it to access the Internet using the Sonicwall's public IP address -- which, in the grand scheme, is hopefully the most straightforward part of this setup.
Note that if you -- now, or in the future -- want EC2 instances inside VPC to have AWS-assigned public IP addresses, you will need to place those on different subnets inside VPC. These subnets, known as public subnets, use the VPC's Internet Gateway object (
igw-xxxxxxxx) for in and out Internet access.
Note also that if you are using AWS services like DynamoDB, SNS, SQS, etc., you will probably want a NAT instance or NAT gateway in your VPC to allow some level of outbound Internet traffic to short-circuit the path away via your VPN because almost all AWS services, even within the region, require that your instances be able to access "the Internet" in order to get to them. (S3 is one exception, it allows creation of a VPC "endpoint" that obviates the need for Internet access). If you access these services by backhauling over your VPN connection, you will have increased costs and higher latency because you will be paying unnecessarily for the traffic in both directions by routing it outside the AWS region and back again.
Final note, when troubleshooting, you will find that DNS resolution in VPC, by default, always works... even if the rest of your routing is completely and hopelessly wrong... because DNS resolution is handled by some hidden network magic inside VPC. Don't let the fact that DNS is working confuse you. (example: "host x resolves, but I can't actually ping it" -- yes, it almost certainly will always resolve, and that fact doesn't necessarily say anything about your network configuration.)