Sunday, April 12, 2015

VPC Peering in Amazon AWS

VPC peering is an useful option in cases where a dedicated VPN tunnel need not be established between two VPC networks. Typically, the use-case that this scenario fits the most is if there are multiple products and each product is operationally managed by different ops teams. In such cases the two ops teams can install their products in a common region in two separate VPC's and can do the pairing between the two; so that instances in either VPC's can talk to each other. However, before proceeding, it would good to refer to the AWS VPC peering docs below:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html

VPC Peering Limitations

To create a VPC peering connection with another VPC, you need to be aware of the following limitations and rules:
  • You cannot create a VPC peering connection between VPCs that have matching or overlapping CIDR blocks.
  • You cannot create a VPC peering connection between VPCs in different regions.
  • You have a limit on the number active and pending VPC peering connections that you can have per VPC. For more information about VPC limits, see Amazon VPC Limits.
  • VPC peering does not support transitive peering relationships; in a VPC peering connection, your VPC will not have access to any other VPCs that the peer VPC may be peered with. This includes VPC peering connections that are established entirely within your own AWS account. For more information and examples of peering relationships that are supported, see the Amazon VPC Peering Guide.
  • You cannot have more than one VPC peering connection between the same two VPCs at the same time.
  • The Maximum Transmission Unit (MTU) across a VPC peering connection is 1500 bytes.
  • A placement group can span peered VPCs; however, you will not get full-bisection bandwidth between instances in peered VPCs. For more information about placement groups, see Placement Groups in the Amazon EC2 User Guide for Linux Instances.
  • Unicast reverse path forwarding in VPC peering connections is not supported. For more information, see Routing for Response Traffic in the Amazon VPC Peering Guide.
  • You cannot reference a security group from the peer VPC as a source or destination for ingress or egress rules in your security group. Instead, reference CIDR blocks of the peer VPC as the source or destination of your security group's ingress or egress rules.
  • Private DNS values cannot be resolved between instances in peered VPCs.

To establish VPC peering, you can use the below set of steps:-

1. Create vpc peering connection

****************
$aws ec2 create-vpc-peering-connection --vpc-id <source vpc id> --peer-vpc-id <peer vpc id> --peer-owner-id <aws account number of source vpc> 
{
    "VpcPeeringConnection": {
        "Status": {
            "Message": "Initiating Request to <dest vpc aws account #>",
            "Code": "initiating-request"
        },
        "Tags": [],
        "RequesterVpcInfo": {
            "OwnerId": "<aws account number of source vpc>",
            "VpcId": "<source vpc id>",
            "CidrBlock": "198.162.0.0/28"
        },
        "VpcPeeringConnectionId": "pcx-2f5ba346",
        "ExpirationTime": "2015-04-19T04:54:55.000Z",
        "AccepterVpcInfo": {
            "OwnerId": "<aws account number of source vpc>",
            "VpcId": "<peer vpc id>"
        }
    }
}
****************

2. Accept the VPC peering connection from the second VPC

****************
$aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-2f5ba346 
{
    "VpcPeeringConnection": {
        "Status": {
            "Message": "Provisioning",
            "Code": "provisioning"
        },
        "Tags": [],
        "AccepterVpcInfo": {
            "OwnerId": "<aws account number of source vpc>",
            "VpcId": "<peer vpc id>",
            "CidrBlock": "10.98.0.0/16"
        },
        "VpcPeeringConnectionId": "pcx-2f5ba346",
        "RequesterVpcInfo": {
            "OwnerId": "<aws account number of source vpc>",
            "VpcId": "<source vpc id>",
            "CidrBlock": "198.162.0.0/28"
        }
    }
}
****************

3. Add peering connection route to the route tables of both subnets in which instances are located

****************
$aws ec2 create-route --route-table-id rtb-348ebf51 --destination-cidr-block 10.98.0.0/16 --vpc-peering-connection-id pcx-2f5ba346

$aws ec2 create-route --route-table-id rtb-54df1f31 --destination-cidr-block 192.168.0.0/28 --vpc-peering-connection-id pcx-2f5ba346 

****************

4. Check if the peering connection is active

****************
$aws ec2 describe-vpc-peering-connections --profile apix
{
    "VpcPeeringConnections": [
        {
            "Status": {
                "Message": "Active",
                "Code": "active"
            },
            "Tags": [],
            "AccepterVpcInfo": {
                "OwnerId": "<peer aws a/c #>",
                "VpcId": "<peer vpc id>",
                "CidrBlock": "10.98.0.0/16"
            },
            "VpcPeeringConnectionId": "pcx-2f5ba346",
            "RequesterVpcInfo": {
                "OwnerId": "<src aws a/c #>",
                "VpcId": "<source vpc id>",
                "CidrBlock": "198.162.0.0/28"
            }
        }
    ]
}
****************

5. Modify the ingress security rules for each instance to add the other instances **private ip** address

****************
$aws ec2 authorize-security-group-ingress --group-id sg-6e9c550a --protocol tcp --port 22 --cidr 198.162.0.7/32
$aws ec2 authorize-security-group-ingress --group-id sg-7ad9a61e --protocol tcp --port 22 --cidr 10.98.1.108/32
****************

NOTE - Some of the instances that you try to connect to in the peer vpc may be in a subnet that have internet gateway (igw) in its route table entry. In such cases, the instances may have a public or private dns name. However, VPC peering will not work with private dns as per the limitation documented in AWS docs in the above link. If you would still like to have a hostname for the instances, you will need to add a mapping in /etc/hosts file of each instance in the peering vpcs.

6. Check using nmap whether SSH are ports are open and not "filtered"

****************
[ec2-user@ip-198-162-0-7 ~]$ nmap -p 22 10.98.1.108 -P0

Starting Nmap 6.40 ( http://nmap.org ) at 2015-04-12 16:08 EDT
Nmap scan report for 10.98.1.108
Host is up (0.00077s latency).
PORT   STATE SERVICE
22/tcp open  ssh

****************
While VPC peering is useful where the overhead of vpn tunnel is unnecessary, it possible to run into the limitations of data transfer exceeding MTU  limitation of 1500 bytes between the peer vpc's.


3 comments:

  1. Hi Balav,

    Nice article! There's one thing I believe is wrong, Peering doesn't cap the MTU to 1500, you can use jumbo frames as well.

    Cheers!

    ReplyDelete