The list of organizations that have suffered high-profile cyber attacks grows longer by the week. As a result, CIOs and IT leaders have put network security under a bright spotlight. Cloud Security Posture Management (CSPM) is a rapidly growing area of interest AND specialism.
With CSPM in focus, AWS is keen to make it known that the responsibility for cloud security is shared. We (cloud consumers) are responsible for a portion. They (AWS & Azure) are accountable for everything else.
So, why are we here? Well, of all the measures we can take to prevent attacks on our cloud, secure VPCs are perhaps the most effective.
Everything you'll read below is to help you get there.
What is an AWS VPC?
In AWS, VPC is an acronym for Virtual Private Cloud. A VPC is a virtual space that you can use to launch AWS resources into virtual networks.
The virtual network is similar to a traditional on-prem data center operated network, but it comes with all the features & benefits we now closely associate with AWS hosting.
Because an AWS VPC is essentially moving IP traffic into and around your AWS Regions, it's also your first line of defence. When configured correctly, a VPC acts as an extra layer of protection - the result is a scalable, secure, logically isolated non-public area inside your public cloud.
Amazon doesn't charge to use a VPC, but there are charges for using some elements, e.g. NAT gateways and traffic mirroring.
Here are the key ways to create, access and manage your VPCs:
AWS Management Console: AWS' own web interface.
AWS CLI (Command Line Interface): A command-based option that supports a wide range of AWS services on Windows, Mac, and Linux.
AWS SDKs: Language-specific APIs that take care of connection details, including calculating signatures and error handling.
AWS Query API: Low-level API actions that you call using HTTPS requests. This is the most direct way to access Amazon VPC, but you'll need to handle low-level details such as signature hash generation, and error handling.
Cloud Management Tools: Powerful tools, like Hyperglance, utilise AWS' APIs to deliver you insightful views, security monitoring, cost optimization, and best-in-class automation options.
13 AWS VPC Security Best Practices
These 13 best practices won't leave you feeling unlucky. We recommend following as many of them as you can:
1. Choose the Appropriate VPC Type
When setting up a VPC, think carefully about its requirements (now and in the future). Make the right choice now, save valuable time later!
The four initial choices are:
- VPC with a single public subnet only
- VPC with public and private subnets
- VPC with public and private subnets and AWS Site-to-Site VPN access
- VPC with a private subnet only and AWS Site-to-Site VPN access
2. Choose the Right CIDR Block
You should consider the number of IP addresses you require, and data center connectivity before you choose your CIDR block.
VPC IPv4 blocks can be between /28 and /16 in size. An IPv6 VPC is a fixed size of /56 (in CIDR notation).
Pick carefully, and leave some capacity. You can change your IPv4 VPC size by adding/removing up to 4 'secondary' CIDRs. You can't change the size of the IPv6 address range of your VPC.
Also, make sure that your VPC IP address ranges of your VPC don't overlap with the IP address ranges of your existing network.
3. Use Multi-AZ Deployments
Hopefully, when it comes to data, the cost is less critical to your organization than high availability... if that's the case then be sure to choose Multi-AZ deployments. Each AZ runs using its own power and connectivity, giving you the best chances in the case of an AZ failing completely.
4. Isolate Your Environments
You'd do this on-premises, and it's much safer to do the same in the cloud. The best practice is to split your production, staging, and pre-production environments across different VPCs.
Image courtesy of AWS
5. Use Security Groups To Control Resource Access
It's vital that you factor in AWS Identity Access Management (IAM) when you're planning and setting up your VPC. Think about the users, applications and services that need to access your VPC. VPCs are a high-risk area, so don't be afraid to create and assign granular resource-level permissions that reflect your organization's requirements.
Instances can have up to 5 groups assigned to them. When you create your new security groups, no inbound traffic is allowed by default - you'll need to create a rule if you want to change that. Ingress & egress traffic is controlled separately, so will require separate rules.
6. Create a Network Access Control List (NACL)
IAM security groups should be your primary method for controlling VPC network access. Importantly, security groups can contain rules that reference other groups, and they can perform stateful packet filtering - which makes them more flexible than NACLs. However, NACLs can be used (sparingly) to create secondary, stateless guardrails, e.g denying a specific subset of traffic, or high-level subnet controls.
Unlike security groups, NACL gives you the option to create allow and deny rules. To help you manage your list, NACL rules are also numbered (by you). The rules are then evaluated and run in order of their number, lowest to highest.
By default, a VPC has a default NACL that allows all inbound and outbound traffic. A custom NACL, when you create one, does the opposite. Each subnet can only be associated with one NACL, but an NACL can be attached to multiple subnets. Be careful with subnets that aren't associated with an NACL as they will automatically inherit your default NACL (allowing all ingress and egress traffic).
7. Use VPC Flow Logs to Monitor IP Traffic
Given that your VPC is your packet gateway, we'd recommend using VPC Flow Logs to capture information about the IP traffic that's going to and from network interfaces in your VPC (or subnet).
VPC Flow Logs are a great way to monitor traffic that reaches your instance, but they're also great for diagnosing common problems, e.g. overly prohibitive security group rules preventing traffic. Don't forget to publish flow log data to CloudWatch and/or S3.
8. Use an Elastic IP For External Communication
When a service needs to be able to communicate externally, be sure to associate it with AWS Elastic IP (EIP). An EIP allows you to quickly remap addresses to different instances - should you need to, you can use them to mask the failure of some software or an instance. EIPs are also great for when you need a consistent IP, e.g. for DNS.
Once you've done associated an EIP, whitelist those IPv4 (EIP doesn't currently support IPv6) addresses within the services that need the access.
9. Be Mindful When Using Elastic Load Balancing
Whenever you're using Elastic Load Balancing (ELB) for web applications, make sure you place other EC2 instances (that don't require outside-world access) into private subnets. Only the ELBs should be in a public subnet.
10. Use AWS SFTP
If you ever need to transfer files/objects into a VPC, we'd recommend using AWS SFTP. When you do this, you utilise VPC endpoints, avoiding public IP addresses (and the internet) altogether. You also get to leverage AWS PrivateLink.
11. Set Up VPC Peering
VPC Peering allows you to route traffic between two AWS VPCs, via private IPs.
Importantly, VPC Peering connections don't depend on physical hardware like a gateway or VPN connection. Instead, peering connections are created using utilise the VPC's existing infrastructure. This can be especially useful if you have applications that require private & secure connections across multiple VPCs or accounts, or even a supplier's infrastructure.
12. Forge a Tagging Strategy
Securing your resources is tricky when you can't identify them in the first place - let alone keep track of what happens after. When it comes to setting up and optimizing your cloud, an effective resource tagging strategy is a must. If you're unsure what to do here, check out our detailed tagging guide & best practices.
13. Implement Monitoring & Automation
The best-in-class cloud security tools include hundreds of rule-based checks (here are Hyperglance's security checks as an example). Also, look out for codeless implementations, the ability to customise and create your own rules, as well as flexible notification options (e.g. SNS, email, Slack).
Ideally, choose a tool that also lets you plug all those checks into a suite of automations. Having the option to automate remediations is a gamechanger for most, and will save your team valuable time and risk. Also, look for a tool that has built-in cost management - chances are that it'll quickly pay for itself, potentially many times over.
With cloud security contributing to more and more news headlines, VPC security isn't something to compromise on.
It's critical that you spend time planning your VPC security - ideally documenting your standards. Set regular review points to ensure that your standards are up to date and utilise the newest technology.
Once you've worked with stakeholders to implement the best practices, use monitoring and automation tools to uphold your standards. That's when it's time to start using a tool like Hyperglance to really leverage your cloud's potential.
As part of its cloud management suite of features, Hyperglance includes VPC security led rules, alerting, and remediations/automations. That's in addition to enlightening, real-time architecture diagrams and searchable inventory... and lots more.
In addition to AWS security monitoring & automation, Hyperglance allows you to manage costs & reduce your bill, all with built-in interactive diagrams & inventory.
Experience it all, for free, with a 14-day trial.