Comment 7 for bug 1321442

We still do not support the case where there's no default VPC on the account. We *do* support the case when there's no VPC support at all though (e.g. when using a classic EC2 pre-VPC account, but that's becoming less of an issue as it's not possible to create a legacy EC2-Classic account anymore).

I propose to have the following changes implemented:
1. Add a "vpc-id" optional environments.yaml config setting, which is not set by default (the current behavior is preserved - i.e. assume the existence of a default VPC and discover its id during bootstrap).
2. When set though, Juju will validate the given id (e.g. vpc-a1b2c3d4) and ensure it passes some sanity checks, bailing out with an error early on failure. Checks should include, at minimum:
2.1. The given VPC has one subnet per availability zone in the chosen region (this is needed to make sure the automatic availability zone distribution logic for service units will still work).
2.2. Each of these subnets have "automatic public IP" attribute set (this is needed to ensure we can expose services with units in those zones).
2.3. There are other things that can prevent juju from using the given VPC, like restrictive VPC routes, network ACLs or rules, but at this point we should assume the user knows what they're doing when specifying a VPC id
3. Once the specified vpc-id is validated, ensure the EC2 provider uses the id when:
3.1. Running instances - in addition to the zone, the VPC id needs to be explicitly specified.
3.2. Creating/using security groups - pass the VPC id explicitly on creation, use group ids instead of names (as required by AWS VPC API).
4. Displaying the VPC id for each machine in juju status, to give the user some feedback.

I think we should bump this in priority and plan to fix it in the 1.25 release line.