Networking in AWS
Connecting workloads in AWS
As the best practice, workloads are deployed in different Segments/Clusters or Pods for ease of management, security requirements and fault tolerance whether it is in-house data center or in cloud. In terms of Amazon Web Services(AWS) these Segments/Clusters or Pods could be different Virtual Private Cloud(Amazon vpc) in same or different accounts where application are hosted in a logically isolated virtual network that you define..
Cloud workloads can range from a web server to a database to a container.
In many cases workloads need to communicate to each other for providing service to users and this communication is provided through network connectivity.
There are number of private network connectivity services available in AWS and choice of these services may vary use-case to use-case basis.
I am going to talk about different private connectivity options available in AWS and choosing one best suited for a specific use-case and how to configure them through AWS CLI and Console. We should consider price,throughput and latency requirement while deciding on these services.
I assume readers already have basic understanding of computer networking and AWS VPC.
Note: For demonstration purpose I am using basic configuration. You can refer AWS documentation for advance configuration.
EC2 Instances: Two EC2 instances are already running in two different vpc VPC-A and VPC-B and they cannot ping to each other as there is no connectivity between vpc VPC-A and vpc VPC-B.
Instance-1
VPC-A ID: vpc-06c9a7bb62be
VPC-A CIDR 10.100.0.0/16
VPC-A_subnet1: 10.100.0.0/24
[root@ip-10–100–0–236 bin]# ifconfig | grep inet
inet 10.100.0.236 netmask 255.255.255.0 broadcast 10.100.0.255
inet 127.0.0.1 netmask 255.0.0.0
[root@ip-10–100–0–236 bin]#
Instance-2
VPC-B ID: vpc-052d979b9a112cd
VPC-B CIDR : 10.101.0.0/16
VPC-B_subnet1:10.101.0.0/24
[root@ip-10–101–0–56 bin]# ifconfig | grep inet
inet 10.101.0.56 netmask 255.255.255.0 broadcast 10.101.0.255
inet 127.0.0.1 netmask 255.0.0.0
[root@ip-10–101–0–56 bin]#
Currently Instance-1 cannot ping to Instance-2 and vice-versa.
Use-case Scenario 1:
· Workloads are deployed in different vpc and application need bidirectional connectivity.
· Large data transfer is expected.
· Low latency requirement
· High Bandwidth requirement
· Database Sync job
For above use-case VPC Peering would be a good choice.
VPC Peering Configuration:
We will configure vpc-peering connection between VPC-A and VPC-B using AWS CLI.
Step1: Create vpc-peering using AWS CLI
Command: aws ec2 create-vpc-peering-connection — vpc-id <Requester vpc-id> — peer-vpc-id <acceptor vpc-id> — peer-owner-id <account-id of acceptor>
$ aws ec2 create-vpc-peering-connection — vpc-id vpc-06c9a7bb62be — peer-vpc-id vpc-052d979b9a112cd — peer-owner-id 2219769700.
You can now see new vpc-peering connection request in console:
Step2: Accept the vpc-peering request in acceptor account.
Step3: Create route for peer vpc CIDR in subnet routing table, target as vpc-peering
Step4: Now we are able to ping instances from each other.
Note: VPC Peering connections are not transitive that means you cannot setup Spoke/Hub type connectivity.
Use-case Scenario 2:
· Workloads are deployed in different vpc and client/server type connectivity is required. One or many client accessing the application/service.
· Provider and Consumer scenario where you want to allow one or more consumer vpc unidirectional access to a specific service or set of instances in the provider vpc.
· Only the clients in the consumer vpc can initiate a connection to the service in the provider vpc.
· vpc are using overlapping CIDR
· You want to expose service to be consumed by 3rd party without exposing your traffic to the public internet.
· You want your service to be available in AWS Marketplace.
· API style client-server connectivity requirement
· E.g. Shipping of logs to logging servers
For above use-case Private Link would be a good choice.
Private Link Configuration:
I have removed routes via vpc-peering to test Private Link.
Now we will consider instance-1 in provider vpc and instance-2 in consumer vpc. I should be able to connect to instance-1 from instance-2 but not other way around.
For testing, I will connect to instance-1 10.100.0.236 on tcp 22 from instance-2 10.101.0.56 . I have alraedy allowed port 22 in security group from both subnets.
Step1: Create a Network LoadBalancer for your application in provider vpc and configure it for each subnet (Availability Zone) in which the service should be available.
Command: aws elbv2 create-load-balancer — name pl-nlb — type network — subnets subnet-0ed5fe1925f702d..
You can see now in console that network loadbalancer is created.
Add instance-1 as target to NLB which we have just now created.
Step2: Create endpoint service in provider vpc. It will establish a private connection to your load balancer as an endpoint service.
Command: $ aws ec2 create-vpc-endpoint-service-configuration \
— network-load-balancer-arns arn:aws:elasticloadbalancing:us-west-2:3493022350:loadbalancer/net/pl-nlb/8e3019306ba835 \
— acceptance-required
You can see now in console that endpoint service is created.
Step3: Enable service consumers to connect to your service.
· Grant permissions to specific service consumers (AWS accounts, IAM users, and IAM roles) to create a connection to your endpoint service.
· A service consumer that has been granted permissions creates an interface endpoint to your service, optionally in each Availability Zone in which you configured your service.
Execute from consumer account:
Command: aws ec2 create-vpc-endpoint \
— vpc-id <consumer vpc> \
— vpc-endpoint-type Interface \
— service-name <vpc endpoint servicename> \
— subnet-id <consumer subnet> \
— security-group-id <consumer security group> \
$ aws ec2 create-vpc-endpoint \
— vpc-id vpc-052d979b9a112c8 \
— vpc-endpoint-type Interface \
— service-name com.amazonaws.vpce.us-west-2.vpce-svc-0d18d96848b8031 \
— subnet-id subnet-01a1ae7430edd30\
— security-group-id sg-080922c8b97a1c5 \
You can now see in console that vpc endpoint is created.
Step4: Accept endpoint connection in provider account
Step5: We can connect to endpoint now
Note: You can access AWS PrivateLink endpoints over VPC Peering, VPN, and AWS Direct Connect.
Use-case Scenario 3:
· Workload are deployed in different VPC and application need bidirectional connectivity.
· Hub and Spoke connectivity requirement
· When you want to scale connectivity between large number of VPCs
· Need IP multicast support
For above use-case Transit Gateway would be a good choice.
Use-case Scenario 4:
· You want to access workload in your vpc from on-premises network/Data center
· You have requirement of low latency and consistent bandwidth
For above use-case Direct Connect (DX) would be a good choice.
I will cover Transit Gateway and Direct Connect (DX) configuration in next post as I want to keep this post short.
Note: For security purpose I have modified the account ID and other IDs in configuration.
