Apparently, you don't actually get to choose which VPC Lightsail will try to peer with -- it wants to peer with your Default VPC.
Once VPC peering is enabled, you can address other AWS resources in your default AWS VPC by using their private IPs.
https://amazonlightsail.com/docs/#faq
I don't know if I overlooked this originally, or if it was subsequently added to the documentation. It's the last sentence of a paragraph and I may have simply overlooked it. In regions where I do have a default VPC, I don't use it, preferring to "roll my own" from scratch.
Default VPC is not simply a VPC you've selected as "the default," but rather refers to a specific VPC in each region that is initially created by the VPC infrastructure, pre-provisioned.
The problem is, you may not have one of these in every region... and you'll encounter exactly the problem described here, if you don't have a Default VPC in the Lightsail region in question (when this was originally written, LightSail was only available in us-east-1; it has subsequently been launched in many of the other AWS regions). If that describes your situation, you may be able to remedy it yourself, or you may need to contact support. Either way, the Default VPC appears to be the only VPC that Lightsail will peer with.
Not having a Default VPC shouldn't be an issue with a relatively new AWS account:
If you created your AWS account after 2013-12-04, it supports only EC2-VPC. In this case, you'll have a default VPC in each AWS region.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html
Both of the accounts I initially tested with a quite a bit older than that.
I created a new AWS account today, and, not surprisingly, Lightsail VPC peering worked on the first attempt.
After selecting the appropriate region, if your "EC2 Dashboard" page in the AWS console, at the top right of the screen, says...
Supported Platforms
EC2
VPC
...and there's no mention of a Default VPC there, then that's what you're missing. You might (as of 2017-07-27) be able to create a Default VPC yourself. Failing that, you may need to contact AWS support to request that they reconfigure your account so that you have a Default VPC, which was the standard process that was required before the ability to create your own was made available. Once you have a Default VPC in the region, all should be well.
But there's a bit of a catch, so you'll need to take additional steps to prepare your account, before trying to create a Default VPC or contacting support.
Q. I really want a default VPC for my existing EC2 account. Is that possible?
Yes, however, we can only enable an existing account for a default VPC if you have no EC2-Classic resources for that account in that region. Additionally, you must terminate all non-VPC provisioned Elastic Load Balancers, Amazon RDS, Amazon ElastiCache, and Amazon Redshift resources in that region. After your account has been configured for a default VPC, all future resource launches, including instances launched via Auto Scaling, will be placed in your default VPC. To request your existing account be setup with a default VPC, contact AWS Support. We will review your request and your existing AWS services and EC2-Classic presence to determine if you are eligible for a default VPC.
https://aws.amazon.com/vpc/faqs/#Default_VPCs
That's the catch -- you permanently lose access to EC2-Classic -- but if you ask me, that isn't really much of a sacrifice.
So if your account still has "EC2 Classic" access and the default VPC is conspicuously absent, then the solution is to migrate away from, and terminate, any old EC2 Classic (non-VPC) instances, along with any services that are running on top of EC2 Classic (such as RDS running outside of VPC), and it would probably not be a bad idea to remove supporting entities like non-VPC Elastic IPs, Security Groups, etc. Then you can contact AWS and have your account reconfigured to "EC2-VPC"-only in the region, and your peering connection from Lightsail should succeed.
I say "should succeed" because I am still waiting for AWS Support to "approve" my requested account change. That last note on the ticket says my request is "still open" and this process is...
usually pretty quick but on some occasions it can take 24 - 48 hours for our Service Team to review and approve this type of request
Success. After a couple of days, AWS support reconfigured my account. I now have a default VPC in the us-east-1 region, and clicking the box next to "Enable VPC Peering" now works as expected. In the VPC console, I can now see that my default VPC is peered with the "stealth" VPC allocated for Lightsail.
Note that you don't need a paid support plan in order to request that AWS update your account as I've described above. You aren't actually asking for technical support. You can submit this as an account support request.
If you want to access resources in other VPCs in the region other than the Default VPC, that's not natively supported, at least at the moment. This would be more complicated for AWS to offer as a managed service, since they control the basic provisioning of your Default VPC and Lightsail VPC, but not any others.
VPC Peering connections do not support transit traffic, so it's not just a matter of peering the other VPCs to your Default VPC and connecting that way. For now, you'd need to deploy TCP or HTTP proxy servers (e.g. HAProxy, similar to this configuration, but pointing to services or a similar proxy in the target VPC as backends) or instances providing private-to-private source and destination network address translation (NAT) in the Default VPC in order to bridge the gap and cross over into any other VPC through an additonal peering connection. Performance should be excellent, but be sure to familiarize yourself with the pricing for peered VPC traffic. The Lightsail docs and EC2 docs seem inconsistent with each other, with regard to bandwidth costs for peering traffic.
Regarding question 1.
Assuming you are referring to the ability to connect via an IPSec based VPN to securely connect to resources that are located outside AWS. The answer is yes. However, the native AWS implementation of this does have some restrictions. The first is that it is not possible to specify any aspects of the phase 1 or phase 2 configuration settings. Instead AWS provide you with the ability to download pre-configured settings for a range of manufacturers, but also provide some good generic examples too.
Some good resources are:
AWS Managed VPN Connections - provides details on the AWS VPN Gateway service
Your Customer Gateway - provides information on the settings required on the device outside of AWS
Regarding question 2.
This is true, if the tunnel drops for some reason, the AWS side cannot initiate it (this is a VERY annoying limitation if you ask me). However there are ways around it. Some devices support sending keep alive packets to keep the tunnel up. For example Cisco ASA's can make use of IP SLA feature to send SLA messages accorss the tunnel to keep it up. Extract from the sample ASA configuration:
In order to keep the tunnel in an active or always up state, the ASA needs to send traffic to the subnet defined in acl-amzn. SLA monitoring can be configured to send pings to a destination in the subnet and will keep the tunnel active. This traffic needs to be sent to a target that will return a response. This can be manually tested by sending a ping to the target from the ASA sourced from the outside interface. A possible destination for the ping is an instance within the VPC. For redundancy multiple SLA monitors can be configured to several instances to protect against a single point of failure.
Or you can simply arrange for a system on one side to periodically send a ping - via a cron job or scheduled task.
Another option however is to deploy your own IPSec gateway into AWS - either running on the instance itself, or on another instance, you then can update the route table on your subnet to route to the off AWS subnets via this instance. This allows you more control on the IPSec settings and behaviour - but is arguably more complex to manage compared to the native AWS service.
Best Answer
This traffic is still subject to VPC network ACLs and Security Groups. Configure those properly and the other party will not have unfettered access to your entire VPC.