To communicate outside of the VPC, each non-default subnet needs a routing table and an internet gateway associated to it (the default subnets get an external gateway and a routing table by default).
Depending on the way you have created public subnet in the VPC, you might need to explicitly add them additionally. Your VPC setup sounds like it matches Scenario 1 - a private cloud (VPC) with a single public subnet, and an Internet gateway to enable communication over the Internet from the AWS VPC documentation.
You will need to add an internet gateway to your VPC and inside the Public subnet's routing table assign 0.0.0.0/0 (default route) to go to the assigned internet gateway. There is a nice illustration of the exact network topology inside the documentation.
Also, for more information, you can check the VPC Internet Gateway AWS documentation. Unfortunately it's a little messy and a non-obvious gotcha.
For more details about connection issues, see also: Troubleshooting Connecting to Your Instance.
You can set up a bastion host to connect to any instance within your VPC:
http://blogs.aws.amazon.com/security/post/Tx3N8GFK85UN1G6/Securely-connect-to-Linux-instances-running-in-a-private-Amazon-VPC
You can choose to launch a new instance that will function as a bastion host, or use your existing NAT instance as a bastion.
If you create a new instance, as an overview, you will:
1) create a security group for your bastion host that will allow SSH access from your laptop (note this security group for step 4)
2) launch a separate instance (bastion) in a public subnet in your VPC
3) give that bastion host a public IP either at launch or by assigning an Elastic IP
4) update the security groups of each of your instances that don't have a public IP to allow SSH access from the bastion host. This can be done using the bastion host's security group ID (sg-#####).
5) use SSH agent forwarding (ssh -A user@publicIPofBastion) to connect first to the bastion, and then once in the bastion,SSH into any internal instance (ssh user@private-IP-of-Internal-Instance). Agent forwarding takes care of forwarding your private key so it doesn't have to be stored on the bastion instance (never store private keys on any instance!!)
The AWS blog post above should be able to provide some nitty gritty regarding the process. I've also included the below in case you wanted extra details about bastion hosts:
Concept of Bastion Hosts:
http://en.m.wikipedia.org/wiki/Bastion_host
If you need clarification, feel free to comment.
Best Answer
No, there is not. Internet traffic to/from EC2 instances always traverse the Elastic IP 1:1 NAT infrastructure.
I have all manner of IPsec operating in VPC (including IPSec tunnels that cross NAT boundaries) without issue. Why do you think you need to have the public address directly assigned to the host? That is not a requirement from IPsec's perspective.