Database network security is the practice of controlling who and what can connect to your databases over a network. It matters for the DBS-C01 exam because poorly secured network access is the single most common cause of data breaches, and AWS offers a layered set of tools to prevent them. Understanding how to configure a VPC, Security Groups, NACLs, and PrivateLink is essential to designing a secure, scalable database infrastructure on AWS.
Jump to a section
A simple way to picture Database Network Security and VPC Configuration
An apartment building is a protected environment for multiple tenants. Each tenant's unit represents a database server, and the building itself is the Virtual Private Cloud (VPC). The building's front door is the Internet Gateway, the only public entrance. The building's security guard is a Network Access Control List (NACL), checking everyone at the door against a list of allowed people and stopping anyone not on the list, regardless of which apartment they try to visit. Each apartment's front door is a Security Group, a more intelligent checkpoint that only allows someone inside if the tenant inside that specific unit has explicitly invited them. The private elevator that takes a VIP directly from the parking garage to a specific apartment without passing through the lobby is AWS PrivateLink, creating a private connection between services inside and outside the building without ever exposing them to the public internet. The visitor who shows a building access card to the guard is an authorised user connecting to a database. The unexpected delivery person who somehow gets past the guard but cannot open the apartment door is a threat stopped by the Security Group. The building's mailing system, which lets you receive packages without opening your door, is a VPC Endpoint, allowing secure access to AWS services like SQS or DynamoDB from within the VPC without traversing the public internet. Each layer of security works independently, and a failure of one does not mean the apartment is automatically exposed because the next layer still blocks the threat.
To understand database network security on AWS, you first need to understand what a Virtual Private Cloud (VPC) is. A VPC is your own private, isolated section of the AWS cloud where you can launch resources like database servers. Think of it as a private network inside the cloud. By default, nothing outside your VPC can see or reach anything inside it. This is the first and most fundamental layer of security. When you create a database, for example an Amazon RDS instance, you must place it inside a VPC. You choose which VPC, and that database now lives in that private network.
Within a VPC, you create subnets. A subnet is a smaller segment of your VPC's IP address range. You can think of subnets as floors or sections within the building. Some subnets are public, meaning they have a route to the internet, and some are private, meaning they have no direct internet access. Your databases should always be placed in private subnets so they are not directly reachable from the internet.
Now, how do you control traffic into and out of these subnets and the database instances inside them? You use two main tools: Security Groups and Network Access Control Lists (NACLs). Both act as firewalls, but they work at different levels.
A Security Group acts as a virtual firewall for an individual resource, like a single database instance. It operates at the instance level. When you create a Security Group, you define inbound rules that specify which traffic (by IP address, port, and protocol) is allowed to reach the database. You also define outbound rules that control traffic leaving the database. Security Groups are stateful. This means that if you allow an inbound request, the response is automatically allowed, even if you have not explicitly created an outbound rule for it. This makes them simpler to manage. Security Groups only have allow rules, not deny rules. If a rule does not exist, traffic is implicitly denied.
For example, to allow your application server to connect to your MySQL database, you would create an inbound rule in the database's Security Group that allows TCP traffic on port 3306 from the application server's Security Group. You reference the source Security Group, not an IP address. This way, if the application server scales up or down, the rule still works without updates.
A Network Access Control List (NACL) acts as a firewall at the subnet level, not the instance level. A single NACL applies to all resources in a subnet. NACLs are stateless, meaning you must explicitly define both inbound and outbound rules for traffic to flow. If you allow an inbound request, you must also allow the outbound response. NACLs support both allow and deny rules, and rules are evaluated in order by rule number, from lowest to highest. Because NACLs are stateless, they are more complex to configure correctly. They are often used as an additional layer of defence or to block specific bad actors at the subnet boundary.
A common mistake is to assume that a NACL is more secure because it can deny traffic. In reality, the instance-level Security Group is usually the more effective and easier firewall to manage. The exam tests that you know when to use each one.
Next is AWS PrivateLink. PrivateLink allows you to connect your VPC to supported AWS services (like SQS, SNS, or a third-party service) as if they were inside your VPC, without using the public internet. You do this by creating a VPC Endpoint. A VPC Endpoint is a powerful tool for database network security because it means your database or application never has to traverse the public internet to communicate with another AWS service. This reduces exposure to internet-based attacks. There are two types of VPC Endpoints: Interface Endpoints (powered by PrivateLink) and Gateway Endpoints. Gateway Endpoints are used specifically for S3 and DynamoDB. For the DBS-C01 exam, you need to know that using a VPC Endpoint for S3 to access database backups or logs is a security best practice.
Finally, there is the concept of a Bastion Host, sometimes called a jump box. This is a server in a public subnet that acts as a secure gateway. You connect to the bastion host first, and from there you access your private database. This avoids opening the database directly to the internet. The bastion host has a Security Group that only allows SSH or RDP from your corporate IP range, and the database's Security Group only allows traffic from the bastion host's Security Group. This is a common exam pattern.
When you put this all together for a secure database architecture: you have a VPC with public and private subnets. Your database sits in a private subnet. A Security Group on the database allows traffic only from the application server's Security Group on the database port. A NACL on the private subnet provides an extra layer of protection by blocking all traffic except the necessary ports and allowing only ephemeral ports for responses. Access to AWS services for backups or monitoring goes through VPC Endpoints to avoid the public internet. Human access to the database is via a bastion host. Each layer exists to prevent unauthorised access, and together they form a defence-in-depth strategy.
Create a VPC with Public and Private Subnets
You start by creating a Virtual Private Cloud (VPC) to define your isolated network. Within that VPC, you create at least two subnets: a public subnet (with a route to the internet via an Internet Gateway) and a private subnet (with no internet route). The database will be placed in the private subnet to prevent direct internet access.
Create and Configure a Security Group for the Database
You create a Security Group that acts as the firewall for the database instance. You add an inbound rule that allows traffic on the database port (e.g., 3306 for MySQL) from the Security Group of your application server. You do not use IP addresses, only Security Group IDs. You verify no other inbound rules exist, especially not 0.0.0.0/0.
Create and Associate a Custom NACL for the Private Subnet
You create a custom NACL and associate it with the private subnet. You define inbound rules to allow the database port from the application subnet's CIDR range and ephemeral ports for responses. You define outbound rules to allow the return traffic. You explicitly deny all other traffic. This ensures that even if a Security Group rule is misconfigured, the subnet layer still blocks threats.
Set Up a Bastion Host for Administrative Access
You launch a small EC2 instance in the public subnet to act as a bastion host. You secure it by allowing SSH or RDP only from your corporate IP range. You then update the database's Security Group to allow traffic from the bastion host's Security Group. This allows authorised administrators to tunnel through the bastion to reach the database without exposing the database to the internet.
Create VPC Endpoints for AWS Services
To securely access AWS services like S3 for backups or CloudWatch for monitoring, you create VPC Endpoints. For S3 and DynamoDB, you use Gateway Endpoints. For other services like SQS, you use Interface Endpoints (PrivateLink). You update the route tables so traffic to these services goes through the endpoint, avoiding the public internet entirely.
Let us walk through a realistic scenario. You are the junior database administrator at a medium-sized e-commerce company called 'ShopFast'. The company runs its main product catalogue database on Amazon RDS for PostgreSQL. The database contains customer data, pricing, and inventory. The company's application servers run on Amazon EC2 instances, and they need to read and write to this database. The company also uses an S3 bucket to store daily database backups. Your boss asks you to confirm that the database is as secure as possible from network threats.
Here is what you actually do step by step:
First, you log into the AWS Management Console and open the VPC dashboard. You check that the database is in a private subnet. You look at the subnet's route table and confirm there is no route to an Internet Gateway. If there was, you would remove it immediately.
You then look at the Security Group attached to the RDS instance. You see it has an inbound rule allowing TCP on port 5432 (PostgreSQL port) from a specific Security Group ID. You confirm that Security Group ID belongs to the application servers. You check that no other inbound rules exist, especially no rules allowing 0.0.0.0/0 (all IPs). If you found a rule allowing all traffic, that would be a critical security hole.
Next, you review the NACL attached to the private subnet. You verify the inbound rules: rule 100 allows TCP on port 5432 from the application server subnet's CIDR range. Rule 200 allows TCP on ephemeral ports 1024-65535 from the same range (to allow responses). You check that there are no deny rules accidentally blocking legitimate traffic, and no allow rules that are too permissive.
You then investigate how the application servers communicate with S3 for backup storage. You discover they are using a public internet connection. You decide to create a Gateway VPC Endpoint for S3 and attach it to the VPC. After creating the endpoint, you update the route tables so that traffic to S3 goes through the endpoint, not the internet. This change eliminates the risk of data exfiltration over the public internet.
Finally, you set up a bastion host for anyone who needs to manage the database directly (like applying schema changes). You launch a small EC2 instance in a public subnet, harden it by closing all unnecessary ports, and attach a Security Group that only allows SSH from the company's office IP range. You then update the database's Security Group to allow traffic from the bastion host's Security Group on port 5432. You also require SSH key authentication and disable password logins on the bastion host.
At the end of this process, you have achieved a multi-layered secure network architecture. The database has never been exposed to the internet. The only way to reach it is through the application servers or the bastion host, both of which have their own strict security controls. This is exactly the kind of configuration an AWS Database Specialty exam expects you to understand and recommend.
The DBS-C01 exam focuses heavily on practical scenario-based questions about network security. You will rarely be asked to define terms; instead, you will be given a scenario with a potential security vulnerability and asked to choose the best fix. The exam tests your ability to distinguish between Security Groups and NACLs, and to know exactly when to use each.
Here are the specific concepts the exam loves to test:
Stateful vs Stateless firewalls: You must know that Security Groups are stateful and NACLs are stateless. A common question will describe a scenario where outbound traffic is not returning, and you must know that with a NACL you need an explicit outbound allow rule, whereas a Security Group would handle it automatically.
The default NACL: The exam often asks about the default NACL that AWS creates for every VPC. The default NACL allows all inbound and outbound traffic. This is a trap. Beginners assume it is restrictive, but it is actually completely open. If you do not create a custom NACL and associate it, your subnets are wide open at the subnet level.
Security Group source referencing: The exam expects you to know that you should reference a Security Group ID as the source, not an IP address, when allowing traffic between resources in the same VPC. This allows the infrastructure to be dynamic and scalable.
VPC Endpoint types: You need to know which AWS services use Interface Endpoints and which use Gateway Endpoints. Gateway Endpoints are only for S3 and DynamoDB. Everything else (like SQS, SNS, CloudWatch) uses Interface Endpoints (PrivateLink).
Bastion host pattern: The exam will present a scenario where a database is not accessible, and you must identify that the Security Group for the database needs a rule allowing traffic from the bastion host's Security Group. They also test that the bastion host should be in a public subnet.
Traps to watch for: The exam likes to offer a solution that uses a single Security Group with a wide open inbound rule as a quick fix. Always look for the more specific, least-privilege answer. Another trap is using a NACL to control access to a single database instance. NACLs work at the subnet level, so they cannot distinguish between two databases in the same subnet. The correct answer will almost always involve a Security Group.
Key definitions to memorise: VPC (isolated cloud network), subnet (segment of a VPC), Security Group (instance-level stateful firewall), NACL (subnet-level stateless firewall), PrivateLink (private connectivity to services), VPC Endpoint (gateway to a service without the internet), Bastion Host (jump box for secure admin access).
The exam also tests that you understand network segmentation: placing databases in private subnets, and web servers in public subnets. A classic question will ask: 'Your database is in a public subnet. How do you secure it?' The correct answer is to move it to a private subnet and then use a Security Group.
Security Groups are stateful firewalls that operate at the instance level and only support allow rules; they are the primary tool for securing database instances.
Network ACLs are stateless firewalls that operate at the subnet level, support both allow and deny rules, and require explicit outbound rules for response traffic.
Always place databases in private subnets with no direct internet route to minimise their exposure to external threats.
Use Security Group IDs as sources in your rules instead of IP addresses to make your configuration dynamic and more secure.
AWS PrivateLink enables private connectivity between your VPC and AWS services without traversing the public internet, reducing the attack surface.
A bastion host in a public subnet is the standard pattern for granting secure administrative access to databases in private subnets.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Operates at the instance level (attached to a resource like a database)
Stateful (response traffic is automatically allowed)
Only supports allow rules (implicit deny for anything not allowed)
Network ACL (NACL)
Operates at the subnet level (applies to all resources in a subnet)
Stateless (you must explicitly define both inbound and outbound rules)
Supports both allow and deny rules (evaluated in order by rule number)
Public Subnet
Has a route to an Internet Gateway
Typically contains web servers and bastion hosts
Resources can be directly reached from the internet (if Security Groups permit)
Private Subnet
Has no route to an Internet Gateway
Typically contains databases and application servers
Resources cannot be directly reached from the internet
Gateway VPC Endpoint
Used only for S3 and DynamoDB
Free to use (no hourly charge)
Added to the route table as a target
Interface VPC Endpoint (PrivateLink)
Used for most other AWS services (SQS, SNS, CloudWatch, etc.)
Charged per hour and per GB of data processed
Creates an elastic network interface in your subnet
Mistake
A Security Group and a NACL are essentially the same thing, so I only need to configure one of them.
Correct
They work at different layers: a Security Group is a stateful firewall for a single resource, while a NACL is a stateless firewall for an entire subnet. You need both for defence in depth.
The names sound similar, and both involve allow/deny rules. Beginners often assume they are redundant, but they serve different purposes and are both required in a secure architecture.
Mistake
Placing a database in a private subnet means it is completely unreachable and cannot be accessed by my application servers.
Correct
A private subnet simply means the subnet has no direct route to the internet. Resources in the same VPC can still communicate across subnets. Your application servers can reach the database because they are in the same VPC, even if the database is in a private subnet.
The term 'private' sounds like 'inaccessible'. Beginners think private means no one can reach it, but private only means no internet gateway, not no internal connectivity.
Mistake
I can use a VPC Endpoint to give my database a public IP address so it is easier to access.
Correct
A VPC Endpoint is used to connect your VPC to AWS services without traversing the public internet. It does not give any resource a public IP. It is the opposite: it keeps traffic private.
The word 'endpoint' sounds like a destination you can connect to publicly, but in AWS it means a private gateway into a service.
Mistake
If I set a Security Group to allow traffic from my company's IP range, that is the most secure option possible.
Correct
Using a Security Group ID as the source is more secure and scalable than using an IP address. IP addresses can change or be spoofed. A Security Group ID ties the rule to a specific resource (like your application server), not a network location.
Beginners are familiar with IP addresses from home networking and trust them, but in the cloud, dynamic environments make IP-based rules fragile and less secure.
Mistake
A NACL's default deny all rule at the end means that if I don't add any rules, all traffic is denied, which is safe.
Correct
The default NACL for a VPC actually allows all inbound and outbound traffic. You must create and associate a custom NACL with restrictive rules to secure a subnet. The default is wide open.
Common sense says 'default' should be restrictive, but AWS designed it that way to avoid breaking connectivity for new users. The exam tests this counter-intuitive fact.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Security Group is a stateful firewall that operates at the instance level and only has allow rules. A NACL is a stateless firewall that operates at the subnet level and supports both allow and deny rules.
You can, but it is not recommended and is a poor security practice. The best practice is to place databases in a private subnet and use a bastion host for access. The exam will treat a public subnet database as a security flaw.
AWS PrivateLink allows you to connect your VPC to supported AWS services privately. For databases, you might use PrivateLink to connect to a service like Amazon SQS securely, but it is not directly used for database connectivity itself.
Create a Security Group for the database with an inbound rule that allows the database port (e.g., 3306 for MySQL) from the Security Group attached to your application server. Do not use an IP address as the source.
Stateful means the firewall automatically allows the response traffic for any allowed inbound request without requiring an explicit outbound rule. Security Groups are stateful; NACLs are not.
Defence in depth. If a misconfiguration in your Security Group accidentally allows traffic, the NACL at the subnet level can still block it. They provide independent layers of protection.
You've finished Database Network Security and VPC Configuration. Continue through the DBS-C01 study guide to build a complete picture of the exam.
Done with this chapter?