Steps to provision a new VPC (single region)

Example: Use https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpc:createMode=vpcWithResources Give it a unique name, e.g., outpost For NAT gateways, select “1 per AZ” or use some other tool (e.g., Terraform) Provision a jump server VM Ensure local client can ssh into jump server Ensure jump server can ping the newly created VPC using private IP Both of the above are satisfied by: Manually launch a t2.micro VM in a "public" subnet of the new VPC; select seed-key as keypair; make sure to choose assign public IP Switch to a new ~/.seed environment: for example, cp -r that dir somewhere, and remove ~/.seed/*. Things will still work without this step, but this will make testing easier Add a config file at ~/.seed/config.yaml. Example:

1aws:
2  # The VPC to use in each region.
3  #
4  # If this is set, any region without a unique VPC with this name will not be
5  # able to launch Outpost nodes. Outpost's failover will still properly
6  # function to look for such an eligible region.
7  #
8  # Optional; default: None (Outpost will use the default VPC in each region).
9  vpc_name: outpost-vpc
10
11  # Set to true to use private IPs to communicate between the local client and
12  # any Outpost nodes. This requires the networking stack is properly set up.
13  # Specifically, setting this flag means Outpost will only use subnets that
14  # satisfy both of the following to launch nodes:
15  #  - subnets with name tags containing the substring "private"
16  #  - subnets that are configured to not assign public IPs (the
17  #    `map_public_ip_on_launch` attribute is False)
18  #
19  # This flag is typically set together with 'vpc_name' above and
20  # 'auth.ssh_proxy_command'.
21  #
22  # Optional; default: False.
23  use_internal_ips: True
24
25auth:
26  # If set, this is passed as the '-o ProxyCommand' option for any SSH
27  # connections (including rsync) used to communicate between the local client
28  # and any Outpost nodes. This option is not used between Outpost nodes,
29  # since they may not have such a proxy set up.
30  #
31  # Useful for using a jump server to communicate with Outpost nodes hosted in
32  # private subnets without public IPs.
33  #
34  # Optional; default: None.
35  ssh_proxy_command: ssh -W %h:%p -i ~/.ssh/seed-key -o StrictHostKeyChecking=no ec2-user@xxxxxx

Be sure to replace vpc_name with the newly created VPC name; and in ssh_proxy_command replace <user>@<jump server public IP>. (Alternatively, use your own proxy setup there.) Steps to set up VPC peering between 2 regions Use the above two create 2 VPCs in 2 regions; use the same name Create a VPC Peering Connection Requires: the two VPCs should have non-overlapping CIDR ranges (e.g., 10.0.0.0/16, 10.1.0.0/16, ...) These are specified at VPC creation, and thus requires "network/IP address range planning" Modify the route tables of each VPC Inside VPC 1's each route table, add a route: (Destination=CIDR of the other VPC, e.g., 10.1.0.0/16; Target=pcx-xxxxxx (the peering connection ID)) Inside VPC 2's each route table, add a route: (Destination=CIDR of the other VPC, e.g., 10.0.0.0/16; Target=pcx-xxxxxx (the peering connection ID)) Do this for all route tables, including the single public route table + per-AZ private route tables in each VPC NOTE Technically, only need one direction for "jump server VPC -> seed vpc" (i.e., the above needs only be done for jump server VPC) But between 2 seed VPCs, do both directions (since spot controller can be in any region). More info on peering

Follow the first 5 steps, up to and including 'Update route tables', in https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html Easier to follow tutorial: https://dev.to/aws-builders/a-simple-vpc-peering-tutorial-48mo (no need to do the security group step at the end)