Networking

Best Practices in Implementing Security Groups for Web Application on AWS

In-Short

CaveatWisdom

Caveat: Its easy to assign source as large VPC wide CIDR range (ex: 10.0.0.0/16) in Security Groups for private instances and avoid painful debugging of data flow however we are opening our systems to a plethora of security vulnerabilities. For example, a compromised system in the network can affect all other systems in the network.

Wisdom:

1. Create and maintain separate private subnets for each tier of the application.
2. Only allow the required traffic for instances, you can do this easily by assigning “Previous Tier Security Group” as the source (from where the traffic is allowed) in the in-bound rule of the “Present tier’s Security Group”.
3. Keep Web Servers as private and always front them with a managed External Elastic Load Balancer.
4. Access the servers through Session Manager in the System Manager Server.

In-Detail

Basics Of Networking in AWS Cloud

Learn about basics of networking in AWS Cloud with Amazon VPC

Planning and Managing Amazon VPC IP Space in an Amazon EKS Cluster

For the sake of simplicity, I will discuss only IPv4 addressing in this post, I will discuss IPv6 addressing in another blog post.

In-Short

CaveatWisdom

Caveat: Planning Amazon VPC IP space and choosing right EC2 instance type is important for Amazon EKS Cluster, or else, Kubernetes can stop creating or scaling pods for want of IP addresses in the cluster and our applications can stop scaling.

Wisdom:

1. Create larger VPC with CIDR range like 10.0.0.0/16 and if needed add additional CIDR ranges to VPC with custom CNI networking
2. Create Subnets with sufficient IPs and if needed use different subnet for secondary ENIs (network interfaces)
3. Choose right type of instance which can support appropriate number of IPs
4. Manage the IP allocation to Pods and creation of ENIs

In-Detail