Route tables, security groups, and network ACLs

How do route tables function within a VPC, and what is the purpose of the main route table?

Route tables in a VPC define the rules, known as routes, that determine where network traffic from your VPC is directed. Each VPC comes with a main route table that can be modified; this table controls the default routing for all subnets that do not have a route table explicitly associated with them. Subnets must be explicitly associated with a route table that is not the main table to alter their routing decisions.

When configuring a route in a VPC route table, what is the purpose of a local route, and can it be modified or deleted?

The local route in a VPC route table represents the automatic routing for traffic within the VPC itself; it allows for communication among all resources within the VPC. This route is created by AWS and cannot be modified or deleted because it is essential for the VPC’s basic network functionality.

Can Network ACLs (NACLs) in AWS be applied to specific resources, such as EC2 instances, and how do they differ from Security Groups in terms of association?

NACLs cannot be applied directly to specific resources like EC2 instances. Instead, they are associated at the subnet level and apply to all traffic entering and exiting that subnet. In contrast, Security Groups are associated directly with EC2 instances and other resources, providing a more granular level of control over the inbound and outbound traffic for those resources.

What are the key differences between stateful and stateless traffic filtering on AWS, and which AWS security services correspond to each type?

Stateful traffic filtering tracks the state of active connections and automatically allows return traffic without re-evaluation of the rules for each packet. Security Groups in AWS are stateful. Stateless traffic filtering evaluates each packet in isolation, without considering past or future packets. Network ACLs (NACLs) in AWS are stateless; they require rules for both inbound and outbound traffic without maintaining the state of network connections.

In AWS, what is the difference between security group rules and NACL rules regarding rule evaluation?

In security groups, rules are evaluated as a whole, meaning that traffic is allowed if it matches any rule. There is no evaluation order as all rules are applied at the same time. In contrast, NACL rules are processed in numerical order, starting with the lowest numbered rule. As soon as traffic matches a rule, processing stops, and subsequent rules are not evaluated.

How do you ensure high availability for resources in different Availability Zones in terms of route table configurations in AWS?

To ensure high availability across different Availability Zones, each subnet in a separate Availability Zone should be associated with a route table configured to direct traffic appropriately. This includes setting up routes to the Internet via an Internet Gateway or NAT instances/gateways for outbound traffic, as well as proper CIDR block routing to communicate effectively with other subnets.

What are the implications of using an overly permissive security group or NACL rule, and how can this be mitigated?

Overly permissive rules can expose resources to potentially malicious traffic, leading to security vulnerabilities. It is recommended to follow the principle of least privilege, ensuring that only necessary traffic is allowed. Review and revise rules regularly, making sure to restrict access to the least access necessary for resources to operate effectively. You can mitigate risks by conducting regular audits and using automated tools to detect and rectify overly permissive rules.

How would you troubleshoot a situation where an EC2 instance cannot communicate with the Internet, assuming the instance is assigned a public IP?

The troubleshooting steps would include checking:
– The associated security group to ensure it allows outbound Internet traffic (e.g., HTTP/HTTPS).
– The NACLs to verify that the appropriate inbound and outbound rules are in place.
– The route table of the subnet to confirm that a route to an Internet gateway exists.
– If NAT is used, that the instance is in a private subnet and a NAT Gateway or NAT instance is properly configured in a public subnet.
– That the EC2 instance’s network interfaces are correctly configured and active.

Can you briefly explain the process of subnet-to-subnet communication within the same VPC in regards to route tables?

Subnet-to-subnet communication within the same VPC is enabled by default through the local route in VPC route tables. This route is automatically created by AWS and allows for IP traffic to flow between subnets without the need for internet gateways, virtual private gateways, or NAT devices. Custom route table entries are not needed unless the VPC is connected to other networks, like a corporate data center or peered VPCs.

In the context of AWS, when would you consider using a Network ACL in addition to security groups, and what additional protection does it offer?

Network ACLs provide an additional layer of defense as they operate at the subnet level, offering stateless filtering of traffic entering and exiting a subnet. They are useful when you need to implement broad network traffic rules that apply to all resources within a subnet, such as blocking specific IP addresses or preventing traffic between subnets. Using NACLs in addition to security groups can help enforce a more comprehensive security posture by employing both stateless and stateful filtering mechanisms.

Can security groups in AWS reference other security groups, and what is the benefit of this capability?

Yes, security groups in AWS can reference other security groups within the same VPC or peered VPCs. This allows for the creation of more flexible and maintainable security policies, as you can create a hierarchical structure where common rules are centrally managed within a “base” security group, and “derivative” security groups reference the base for common rules while adding their specific rules.