As more and more enterprises choose cloud computing services like AWS, cloud computing environments are becoming increasingly complex. Enterprises must develop comprehensive and proactive security strategies, establishing them from the start and evolving them as infrastructure expands to maintain the security of systems and data.

AWS infrastructure security has been designed as one of the most flexible and secure cloud computing environments available today. Its design goal is to provide a highly scalable and highly reliable platform that enables customers to quickly and securely deploy applications and data. AWS operates under a "shared responsibility" security model. AWS is responsible for the security of the underlying cloud infrastructure, while users are responsible for protecting workloads deployed on AWS.

Among the infrastructure provided by AWS, Amazon Virtual Private Cloud (VPC) plays a very important role. VPC brings powerful networking capabilities, including static private IP addresses, elastic network interfaces, secure Bastion host setup, DHCP options, advanced network access control, VPN connections, and transfer of internal IPs and NICs between instances. In terms of network security, Amazon VPC provides advanced security features such as security groups and network access control lists, enabling inbound and outbound filtering at the instance and subnet levels. Understanding best practices for using Amazon VPC is beneficial for enterprises whether they are maintaining existing VPC networks or planning to migrate to AWS environments.

1. Choose the Right VPC Configuration for Your Needs

VPC is the foundation of your network architecture. Designing a good VPC network architecture requires careful consideration of subnets, internet gateways, NAT gateways, virtual private gateways, peering connections, VPC endpoints, and more. Although there are ways to resize a VPC, given the complexity and importance of VPC to your systems, it is strongly recommended that when planning your VPC, you design your Amazon VPC based on expansion needs at least two years into the future.

Today, when you go to the "Amazon VPC" page in the AWS Management Console and select "Launch VPC Wizard," you will see four basic options for network architecture:

1. Amazon VPC with a Single Public Subnet
2. Amazon VPC with Public and Private Subnets
3. Amazon VPC with Public and Private Subnets and AWS Site-to-Site VPN Access
4. Amazon VPC with a Private Subnet Only and AWS Site-to-Site VPN Access

Carefully consider your current and future requirements before selecting the most appropriate configuration.

2. Choose the Right CIDR for Your VPC

When designing your Amazon VPC, you must consider the number of IP addresses needed and the type of connection to your data center before selecting a CIDR block, including RFC 1918 or publicly routable IP ranges. Currently, you cannot change or modify the CIDR set for an Amazon VPC, so it is best to choose a CIDR block with more IP addresses. Additionally, when designing a hybrid architecture for Amazon VPC to communicate with on-premises data centers, ensure that the CIDR ranges used in Amazon VPC do not overlap or conflict with CIDR blocks in your on-premises data center. To resize a VPC, you can expand it by adding up to 4 secondary IPv4 CIDRs to the existing VPC, or shrink it by removing secondary CIDR blocks. However, you cannot change the size of the IPv6 address range of a VPC.

3. Isolate VPC Environments

Physical isolation that exists in on-premises environments should also be an important principle in cloud environment practices. Many best practices indicate that it is best to create a separate Amazon VPC for development, production, and staging. Many people are accustomed to managing pre-release, production, and development environments in a single VPC, but managing such an Amazon VPC with different security weights is extremely challenging. Instead, I recommend using separate VPCs for different environments.

4. Strengthen Protection of Your AWS VPC

Systems running mission-critical workloads require multiple layers of security. The following approaches can effectively protect your Amazon VPC:

• AWS WAF is a web application firewall that helps protect web applications and APIs deployed on VPCs from common web exploits that could affect availability, compromise security, or consume excessive resources.
• The Amazon Web Services Marketplace offers third-party web application firewalls, firewalls, and other tools that can be used to protect Amazon VPC.
• To prevent unauthorized use or intrusion into the network, you can configure Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS).
• With privileged identity access management, you can audit and monitor administrator access to VPCs.
• To securely transfer information between Amazon VPCs across different regions or between Amazon VPCs and on-premises data centers, you can configure Site-to-Site VPN.
• Another option for secure information transfer is AWS Transfer for Secure File Transfer (AWS SFTP). With AWS SFTP, you can use VPC endpoints and avoid using public IP addresses or going through the internet. Additionally, AWS SFTP's VPC endpoints leverage security features through AWS PrivateLink, which provides a dedicated connection between VPCs and AWS services.

5. Understand Network Firewalls and Security on VPC

AWS provides a virtual firewall function through "security groups" that controls inbound and outbound traffic at the instance level. However, managing AWS network security differs from using traditional network firewalls. The central component of AWS firewalls is the "security group," which is essentially what other firewall vendors call a policy (or collection of rules). However, it is important to understand the key differences between security groups and traditional firewall policies.

First, in AWS, security group rules do not have a specific "action" to declare whether traffic is allowed or dropped. This is because, unlike traditional firewall rules, rules in AWS security groups are allowed by default.

Second, AWS security group rules can specify either a traffic source or a traffic destination, but not both in the same rule. For inbound rules, there is a source that indicates where traffic comes from, but no destination telling traffic where to go. For outbound rules, the reverse is true: you can set a destination but cannot specify a source. The reason is that AWS security groups always set the unspecified side (source or destination) to the EC2 instance using that security group.

AWS is very flexible in allowing these security group rules to be applied. Just as traditional security policies can be applied to multiple firewalls, you can apply a single security group to multiple instances. AWS also allows the reverse — applying multiple security groups to a single EC2 instance, meaning that instance inherits rules from all associated security groups. This is one of AWS's unique features, allowing you to create security groups for specific functions or operating systems and then mix and match them to meet business needs.

6. Do Not Open Ports Unless Necessary

Opening ports for 0.0.0.0/0 (or ::/0 for IPv6) in security groups to allow instances in a VPC is one of the most common mistakes professionals make when configuring security groups. Users end up opening their cloud network and exposing their cloud resources and data to external threats. When formulating policies in security groups, follow the Principle of Least Privilege (POLP) — only open the ports that are needed, rather than exposing the network to threats for the sake of simplified management. Similarly, close unnecessary system ports.

7. Enable and Configure VPC Flow Logs

You can now enable AWS VPC Flow Logs at the VPC, subnet, or network interface (ENI) level to capture information about IP traffic flowing to and from network interfaces in your VPC. You can typically configure AWS VPC Flow Logs to capture accepted and rejected entries for ENIs and security groups flowing through EC2, ELB, and some other services. By scanning these VPC flow log entries, you can detect attack patterns and alert on abnormal activity and traffic within the VPC.

You don't need to worry about the impact of VPC flow logs on your production network. Flow log data collection occurs outside the VPC network traffic path, so it does not affect network throughput or latency.

8. Make Good Use of VPC Peering

A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network.

AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of communication failure and no bandwidth bottleneck.

From a security perspective, VPC peering network traffic stays within the private IP space. All inter-region traffic is encrypted, with no single point of failure or bandwidth bottleneck. Traffic stays within the global AWS backbone and never traverses the public internet, reducing exposure to threats such as common exploits and DDoS attacks. VPC peering can meet many needs, such as:

• Interconnected applications that need private and secure access within AWS. This often occurs in large enterprises running multiple VPCs in a single region.
• Systems deployed by business units in different AWS accounts that need shared or private access. Some large organizations have different AWS accounts for various business units, departments, or teams, with varying communication needs between groups.
• Better system integration access, such as customers peering their VPC with a core vendor's VPC.

9. The Cheapest Security Tool — Tags

That's right — tags. Tagging resources in your VPC is extremely important. You can, and should, use tagging strategies to effectively organize resources for management, reporting, and analysis. For large and complex network infrastructure, there are many angles to management, especially for security issues. With this in mind, maintain best practices through any tagging strategy and update it promptly when things change. As you adopt more and more automation tools, you will realize how important a well-designed tagging scheme is for the security and manageability of your VPC.

10. Integrate Security into DevOps

Undeniably, cloud computing is a new frontier, and the risks and challenges of cloud security are growing daily. There are not enough cloud security experts in the market, and it is difficult for enterprises to find professionals proficient in the latest cloud computing technologies. Even when teams hire excellent security personnel, those who can write code are often used for development rather than security management.

A good rule of thumb is that security can be achieved regardless of whether an enterprise has a Security Operations Center (SOC) or Information Security (Infosec) experts. In modern organizations, security should not only be the responsibility of security experts or SecOps teams — it should be a shared goal across the entire team, from top to bottom. Keep in mind that the better the tools and processes in your team, the fewer security experts you need. My recommendations are:

• Build a DevOps culture with security built in, which can be summarized as "improving the organization's security culture."
• Provide security training for all staff. Security is everyone's job — not just those with "security" in their job title.
• Establish the awareness of "People + Responsibility = Security" throughout the enterprise.

Source: https://aws.amazon.com/cn/blogs/china/ten-best-practices-for-vpc-security/

Back to Tech Blog