What is Wrong With my VPC Configuration?

VPC Configuration Done Incorrectly

The AWS Virtual Private Cloud (VPC) is a service meant to segment parts of the cloud to form new private circles for keeping certain services and databases off the grid.  Users can configure a VPC to control all traffic both going in and out with complete control over what is private, who has access, and how much they have access to.  But while the controls are tight, using a VCP can be a bit esoteric at times and there’s plenty of room for error.  Configured incorrectly, a user can unintentionally undermine the whole purpose of having a VPC in the first place.

As mentioned earlier, AWS does not manually confirm if a VPC is properly configured and solely relies on the user’s ability to configure their VPC to their own needs.  Granted, this is usually a result of some developers still adapting to the AWS Cloud and not realizing the full depth of what’s required.  Even developers who do have the potential expertise to properly configure a VPC are still vulnerable to these pitfalls.  Having the expertise of someone who has previously configured a VPC can help significantly in avoiding this issue.  For more information on the VPC, our article covers the topic in greater detail.

VPC Configuration Done Incorrectly

The Amazon Virtual Private Cloud (VPC) is a service meant to segment parts of the cloud to form new private circles for keeping certain services and databases off the grid.  Users can configure a VPC to control all traffic both going in and out with complete control over what is private, who has access, and how much they have access to.  But while the controls are tight, using a VCP can be a bit esoteric at times and there’s plenty of room for error.  Configured incorrectly, a user can unintentionally undermine the whole purpose of having a VPC in the first place.

As mentioned earlier, AWS does not manually confirm if a VPC is properly configured and solely relies on the user’s ability to configure their VPC to their own needs.  Granted, this is usually a result of some developers still adapting to the AWS Cloud and not realizing the full depth of what’s required.  Even developers who do have the potential expertise to properly configure a VPC are still vulnerable to these pitfalls.  Having the expertise of someone who has previously configured a VPC can help significantly in avoiding this issue.  For more information on the VPC, our article covers the topic in greater detail.

Is it Actually Private?

Firstly, using the same routing table for all subnets can turn into a headache.  While it does make the VPC simpler, it leaves databases and otherwise private services into public ones available for normal use along with other public access points on the front end.  Then there’s setting up separate subnets, but unintentionally setting that subnet to the public instead of private.

A third factor that needs to be considered is having a network access translation (NAT) gateway.  Configured properly, the NAT gateway allows only outgoing traffic so that private devices can still get updates and resources they might need.  But to reiterate, the NAT will also block all incoming traffic too.  The public network will have to sit between the private networks and the internet where the private networks have no direct connection to the internet.  When the public network becomes compromised, the connection between the VPC interior and exterior can be severed while avoiding any data loss in its entirety.  Finally, having that extra buffer between the expendable public network and the indispensable private network provides an easier cutoff point to stop inbound DDoS or malware attacks.

Is it Actually Private?

Firstly, using the same routing table for all subnets can turn into a headache.  While it does make the VPC simpler, it leaves databases and otherwise private services into public ones available for normal use along with other public access points on the front end.  Then there’s setting up separate subnets, but unintentionally setting that subnet to the public instead of private.

A third factor that needs to be considered is having a network access translation (NAT) gateway.  Configured properly, the NAT gateway allows only outgoing traffic so that private devices can still get updates and resources they might need.  But to reiterate, the NAT will also block all incoming traffic too.  The public network will have to sit between the private networks and the internet where the private networks have no direct connection to the internet.  When the public network becomes compromised, the connection between the VPC interior and exterior can be severed while avoiding any data loss in its entirety.  Finally, having that extra buffer between the expendable public network and the indispensable private network provides an easier cutoff point to stop inbound DDoS or malware attacks.

How to Verify if it is Public?

With the cause for what can go wrong, it’s important to thoroughly check every facet to ensure the VPC is truly private.  There are a number of settings that can be relatively easily inspected to ensure the configuration is correct.

• • The number of subnets: As outlined earlier, having both public and private databases and services on the same public subnet just makes everything public.  Ensuring that there’s more than one is the easiest mistake to remedy.

• • Public or Private: As an extension of the previous point, public services can also be accidentally hidden if they are on a private subnet.

• • Consistent across Availability Zones: Wherever these issues are present, they could have been replicated during expansion.

• • Route tables: In the case of outages, route tables will redirect incoming traffic to mitigate the incoming traffic to still-running instances.  Keep these logic trees separated into their respective subnet types.

• • Using a NAT or direct internet connection: The buffer is a gateway that can be shut at a moment’s notice and can come in handy when the network is hit hard by an attack.

How to Verify if it is Public?

With the cause for what can go wrong, it’s important to thoroughly check every facet to ensure the VPC is truly private.  There are a number of settings that can be relatively easily inspected to ensure the configuration is correct.

• • The number of subnets: As outlined earlier, having both public and private databases and services on the same public subnet just makes everything public.  Ensuring that there’s more than one is the easiest mistake to remedy.

• • Public or Private: As an extension of the previous point, public services can also be accidentally hidden if they are on a private subnet.

• • Consistent across Availability Zones: Wherever these issues are present, they could have been replicated during expansion.
• • Route tables: In the case of outages, route tables will redirect incoming traffic to mitigate the incoming traffic to still-running instances.  Keep these logic trees separated into their respective subnet types.
• • Using a NAT or direct internet connection: The buffer is a gateway that can be shut at a moment’s notice and can come in handy when the network is hit hard by an attack.

New VPC Requirement and Legacy Builds

Due to security concerns, modern iterations of EC2 now require the use of a VPC to allow continued operation on AWS.  While Classic EC2 can still run, maintenance and updates have now been sunset.  Concerns that immigrating to newer versions of EC2 are legitimate, but the longer-term security impacts do not justify remaining on older cloud hardware.  If migration really can impact stored data, a cloud expert can help make the transition.

Because the newer iterations of EC2 still receive support, there will be newer controls and features compared to legacy versions.  In a AWS Virtual Private Cloud, the connections to an EC2 instance can be greatly controlled and limited with whitelists or blacklists being made at various levels.  Because development to legacy EC2 has been cut, these are features the older version will not receive.

New VPC Requirement and Legacy Builds

Due to security concerns, modern iterations of EC2 now require the use of a VPC to allow continued operation on AWS.  While Classic EC2 can still run, maintenance and updates have now been sunset.  Concerns that immigrating to newer versions of EC2 are legitimate, but the longer-term security impacts do not justify remaining on older cloud hardware.  If migration really can impact stored data, a cloud expert can help make the transition.

Because the newer iterations of EC2 still receive support, there will be newer controls and features compared to legacy versions.  In a VPC, the connections to an EC2 instance can be greatly controlled and limited with whitelists or blacklists being made at various levels.  Because development to legacy EC2 has been cut, these are features the older version will not receive.