Introduction

In a Virtual Private Cloud (VPC), the concept of "virtual private" implies that the resources within the VPC are logically isolated from resources in other VPCs and are dedicated to a specific customer or organization. This means that, within the boundaries of a VPC, your resources are private and not shared with other customers by default. Here are key points:

1. Logical Isolation:

   • A VPC provides logical isolation in the cloud environment. The IP address range, subnets, and resources within a VPC are separate from those of other VPCs.

2. Tenant Isolation:

   • Each VPC is associated with a specific AWS account, and resources within the VPC are dedicated to that account. This ensures that the resources are private and used exclusively by the account owner.

3. Private IP Addressing:

   • Instances within a VPC use private IP addresses for communication within the VPC. Public IP addresses can be assigned to instances in public subnets for internet communication, but this is still controlled within the VPC.

4. Resource Access Controls:

   • Access controls, such as Security Groups and Network Access Control Lists (ACLs), are used to control inbound and outbound traffic within the VPC. These controls are specific to the resources within the VPC.

5. Data Isolation:

   • The data stored within instances and storage resources in a VPC is private to that VPC. Access controls and encryption can be used to enhance data security.

While resources within a VPC are logically isolated, it's important to note the following:

• Shared Infrastructure: While the logical separation is in place, the underlying physical infrastructure (servers, networking equipment, storage) is shared among multiple customers by the cloud provider. Virtualization technologies ensure the logical isolation of resources.

• Regional Scope: A VPC is confined to a specific AWS region. Within that region, there may be multiple Availability Zones (AZs) where resources can be deployed for redundancy.

Subnet

• A subnet, short for "subnetwork," is a logical subdivision of an IP network. Subnetting allows you to divide a larger network into smaller, more manageable segments.

• Each subnet has its own unique range of IP addresses and operates as an independent network within the larger network.

• Subnetting is commonly used to improve network performance, security, and organization.

• Different departments in a subnet have access to different servers, hence we perform subnetworking

Subnet Security

etwork Access Control Lists (NACLs) control the security of a subnet in a cloud environment, such as Amazon Web Services (AWS). NACLs act as a stateless firewall at the subnet level, allowing you to define rules that control inbound and outbound traffic to and from instances within the subnet.

Key points about how NACLs control security within a subnet:

1. Ingress and Egress Rules:

   • NACLs consist of both inbound (ingress) and outbound (egress) rules. Each rule defines a specific set of conditions, such as source IP address, destination IP address, port, and protocol.

2. Rule Evaluation Order:

   • NACL rules are processed in rule number order. When a packet matches a rule, further rule processing stops. It's important to consider the order of rules when defining NACLs.

3. Allow and Deny Rules:

   • Each rule in an NACL is either an allow rule (permitting traffic) or a deny rule (blocking traffic). Rules are defined based on criteria such as IP address ranges, port numbers, and protocols.

4. Stateless Operation:

   • NACLs are stateless, meaning that the rules for inbound and outbound traffic are separate. If you allow inbound traffic, it doesn't automatically allow the corresponding outbound traffic, and vice versa.

5. Association with Subnets:

   • NACLs are associated with specific subnets within a Virtual Private Cloud (VPC). Each subnet can be associated with only one NACL at a time.

6. Default NACL:

   • Each VPC comes with a default NACL that allows all inbound and outbound traffic. You can modify the default NACL or create custom NACLs to meet specific security requirements.

7. Logging:

   • NACLs can be configured to log specific traffic events, providing visibility into network activity for monitoring and auditing purposes.

Example NACL Rules:

• Rule 100: Allow inbound traffic from a specific IP range on port 80.

• Rule 200: Deny all inbound traffic.

• Rule 300: Allow all outbound traffic.

NACLs complement security groups, which operate at the instance level. While security groups are stateful and control traffic at the instance level, NACLs provide an additional layer of security at the subnet level, helping to enforce security policies for all instances within the subnet.

VPC Peering

VPC peering is a networking connection between two Virtual Private Clouds (VPCs) in a cloud environment, allowing them to communicate with each other securely. This capability enables instances within the peered VPCs to communicate as if they were on the same network, even though they may belong to different AWS accounts or regions.

Key points about VPC peering:

1. Direct Network Connection:

   • VPC peering establishes a direct network connection between two VPCs. This connection is private and does not traverse the public internet.

2. Cross-Account and Cross-Region Peering:

   • VPC peering can occur between VPCs in the same AWS account or between VPCs in different AWS accounts. It can also occur between VPCs in the same region or different regions.

3. Private IP Address Communication:

   • Instances in the peered VPCs can communicate with each other using their private IP addresses, as if they were part of the same network. Traffic between peered VPCs is encrypted and does not leave the AWS network.

4. Transitive Peering:

   • VPC peering supports transitive relationships. If VPC A is peered with VPC B and VPC B is peered with VPC C, then instances in VPC A can communicate with instances in VPC C, even though there is no direct peering connection between VPC A and VPC C.

5. Security Considerations:

   • VPC peering does not modify the security groups, network ACLs, or route tables of the peered VPCs. You need to ensure that the necessary rules are in place to allow the desired traffic.

6. CIDR Block Overlapping:

   • The CIDR blocks of the peered VPCs must not overlap. The IP address ranges must be unique to avoid conflicts.

7. No Transit Traffic:

   • VPC peering does not support transitive traffic. If VPC A is peered with VPC B and VPC B is peered with VPC C, instances in VPC A cannot communicate directly with instances in VPC C through VPC B.

Setting up VPC peering involves creating a peering connection and accepting the peering request in each VPC. Once established, the peering connection allows for private and secure communication between instances in the peered VPCs.