Back to Course

Introduction to AWS Security

0% Complete
0/0 Steps
  1. Introduction

    About the course and authors
  2. AWS cloud architecture
  3. Security concerns with our architecture
  4. Regions and Availability Zones (AZs)
  5. Shared responsibility in the cloud
  6. [Cheat Sheet] AWS Security Services
  7. [LAB] Create a billing alert to avoid surprise bills
  8. Infrastructure Security
    VPC networks
  9. Default VPCs
  10. [DEMO] Creating VPCs and Subnets
  11. How many VPCs should you use?
  12. [DEMO] Subnet, Route Table, and Gateway Configurations
  13. [LAB] [Challenge] Create a VPC with public and private subnets
  14. [LAB] Launching an EC2 instance
  15. [DEMO] Security Groups (SGs)
  16. Security Groups Best Practices
  17. [DEMO] Network Access Control Lists (NACLs)
  18. [Cheat Sheet] SGs vs. NACLs
  19. [LAB] [Challenge] Configure security groups and NACLs to specific requirements
  20. Elastic Load Balancers
  21. [DEMO] AWS WAF
  22. [LAB] [Challenge] Deploy AWS WAF ACL for Application Load Balancer
  23. [DEMO] AWS Network Firewall - Part 1
  24. [DEMO] AWS Network Firewall - Part 2
  25. AWS Shield for DDoS Protection
  26. AWS Firewall Manager
  27. Identity and Access Management (IAM)
    Key Concepts of IAM in AWS
  28. [DEMO] Getting started with IAM in AWS
  29. [DEMO] Creating our first admin user
  30. Assigning permissions with policies
  31. [Cheat Sheet] Anatomy of an AWS IAM Policy
  32. [DEMO] Using Identity Center AWS SSO
  33. IAM Roles
  34. [DEMO] Creating a role for EC2 instances to access S3 buckets
  35. End-User Management with Amazon Cognito
  36. Data Protection
    Data protection in the cloud
  37. EBS Data Protection and Encryption
  38. Amazon RDS Data Protection and Encryption
  39. Key Management with AWS KMS
  40. [Cheat Sheet] Getting Started with AWS KMS
  41. [DEMO] Creating a Symmetric Encryption KMS Key
  42. [Cheat Sheet] Encrypt and Decrypt Data with KMS and Data Keys
  43. [LAB] Encrypt and Decrypt Data with KMS and Data Keys
  44. Amazon S3 Bucket Protection
    Understanding Bucket Ownership
  45. [LAB] Creating Buckets and Uploading Objects in S3
  46. Managing Access to Buckets
  47. [Cheat Sheet] S3 Bucket Policies vs. ACLs vs. IAM Policies
  48. [LAB] [Challenge] Create an IAM role for secure access to S3 based on a scenario
  49. Using Signed URLs
  50. Encrypting S3 Data
  51. [DEMO] Enable S3 Object Versioning
  52. [Cheat Sheet] Amazon S3 Protection Summary
  53. [Cheat Sheet] Create a least privilege S3 bucket policy
  54. Logging, Monitoring, and Incident Response
    AWS Log Types and Auditing Options
  55. [DEMO] Enable S3 Server Access Logs
  56. AWS CloudTrail
  57. Amazon CloudWatch
  58. [DEMO] CloudTrail Security Automation with CloudWatch Logs and SNS
  59. [DEMO] Amazon VPC Flow Logs
  60. Proper Logging and Monitoring
  61. Amazon GuardDuty
  62. [LAB] [DEMO] Enable Threat Detection with GuardDuty
  63. [DEMO] Amazon EventBridge
  64. AWS Config
  65. AWS Systems Manager
  66. [LAB] Secure EC2 Access with SSM Session Manager and KMS
  67. [DEMO] AWS Config Automated Remediation with SSM
  68. Amazon Detective
  69. [LAB] [DEMO] Amazon Inspector
  70. [DEMO] Amazon Macie
  71. [DEMO] AWS Security Hub
  72. [DEMO] Must-have AWS monitoring and alerting with SSK
  73. Multi-Account Security
    [DEMO] AWS Organizations
  74. [DEMO] AWS SCPs and Management Policies
  75. AWS Control Tower
  76. Wrap-up and Key Takeaways
    What now?
Lesson 9 of 76
In Progress

Default VPCs

Christophe December 28, 2022

Access the interactive diagram for this lesson here. (It may ask you to create a free account in order to view. You do not need paid features to view this course’s content so you can ignore that!)

Starting with this lesson, I highly recommend that you create your own AWS account in order to follow along if you don’t already have one. Some of the links in this lesson will only be accessible if you’re logged in to an AWS account, and following along is a better way of learning than simply watching me explain concepts. Creating an account is simple, so I’m not showing you how to do it, but if you need instructions, follow the steps on this page. None of what we do in this specific lesson will end up costing you money, so even though AWS asks for a payment method, you will not accrue any charges as long as you follow my steps.

Default VPC

When you create your AWS account and start using your subscription, Amazon gives what they call a default VPC. This default VPC comes with pre-configured features and parameters to save you time and effort and to make it more beginner friendly.

If they didn’t have this default VPC, it would be overwhelming to a complete beginner. It provides a very quick and convenient way to get you started with AWS. However, in security, we tend to avoid using what is provided to us “by default” because defaults almost always create security holes.

Plus, when you’re dealing with this sort of environment, it’s preferable to have full control over how things are configured and set up.

In any case, let’s take a look at what this default VPC is and how it’s configured, and let’s also talk about some of the security concerns we might face if we end up using it.

CIDR Blocks

In detail, you get one “default” VPC in each AWS region, with a /16 IP block assigned to it.

If you’re not familiar with what /16 refers to, consider checking out our Networking Fundamentals course where we explain what CIDR blocks are. The long story short is that CIDR defines which IP addresses and how many host IP addresses will be allowed on the network. In the case of /16, we are reserving 16 bits for the network mask, and we can have up to 65,536 private IPv4 addresses.

Because this default VPC uses the IPv4 address of 172.31.0.0 with a /16, that means the resources we would launch in this VPC could have IP addresses of 172.31.x.x.

You’ll remember that once we create a VPC, we also need to create subnets. AWS automatically creates a default public subnet with a /20 in each Availability Zone for that specific region. That means you can launch about 4,096 hosts in each subnet. I say about, because AWS reserves some of those IP addresses for services behind the scenes.

Those subnets could look like this:

  • Subnet 1: 172.31.0.0/20
  • Subnet 2: 172.31.16.0/20
  • Subnet 3: 172.31.32.0/20

Where resources launched in subnet 1 would have IP addresses of 172.31.0.x, resources in subnet 2 would have IP addresses of 172.31.16.x, and so on…

CIDR is important to understand when setting up VPCs but it’s not going to be an area of focus for security purposes, so we won’t dive further into explaining that in this course, but here are additional resources that can help you learn more if you’re interested: resource 1, resource 2.

Internet Gateways and Route Tables

AWS also creates an internet gateway and a default route table which routes all traffic to the internet gateway, and this is what gives resources launched in the default VPC access to the open Internet. All instances or other resources that you deploy in this VPC and in these subnets will receive both private and public IP addresses and DNS records. This is one of our first security concerns with default VPCs, since it means that we don’t have any private subnets, and all resources launched in this VPC can be accessed by anyone by default.

Security Groups and ACLs

One way to protect resources launched in default VPCs is to use Security Groups. Another way is to use Network Access Control Lists, also known as ACLs or NACLs. The default VPC will create a default security group and default access control list as well, but you can create different and custom ones as you launch resources.

DHCP Options

Finally, AWS also associates default DHCP options for your AWS account with your default VPC. DHCP is what automatically assigns IP addresses to devices, and DHCP options sets in AWS give you control over DNS servers, domain names, and more.

Customizing default VPCs

These default VPCs are actually quite flexible because we can add new subnets, we can modify route tables, add new route tables, create new security groups and access control lists, etc… You can even create private subnets or make the default subnets private by changing settings…

So should you use default VPCs?

With that said, the usual recommendation is to delete these default VPCs and to start from scratch by creating your own. That way, you don’t forget to change any settings and you have complete control over the VPC, its subnets, and its other configurations. You also don’t end up accidentally launching a resource in a default VPC thinking that you had launched it into a non-default VPC.

Also, you can always re-create a default VPC, so if you end up deleting it and you change your mind later on, you can re-create a new default VPC…but again, this is an uncommon practice.

If you do choose to work with the default VPC that Amazon provides, your very first step should be to remove the default route in order to turn the default public subnets into private ones. If subnets don’t have explicit route table associations, then by default, the subnet is associated with the main route table. You would either need to modify this main route table which would affect all of the subnets, or you would have to create a separate route table and explicitly associate the subnets you want to make private with that new route table.

There’s another issue here worth noting about default VPCs: sometimes, AWS creates new Availability Zones in a Region. For every new AZ that AWS creates in your region, a new, default, and public subnet will be created for you. This is the default behavior for all default VPCs. If you don’t change this, you will end up with public subnets in every new availability zone that AWS creates. You want to avoid this kind of behavior since you need to be in full control of your subnets, especially public ones. Changing this is rather simple: as soon as you modify your VPC, this behavior stops and AWS won’t create default public subnets for those modified VPCs.

Conclusion

We’ve talked about what default VPCs are and how they work, and why it’s usually recommended not to use them and to delete them in order to replace them with non-default VPCs. But how do you create these non-default VPCs? Let’s complete this lesson and let’s find out in the next!

Responses

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.