# Network Architecture Hardening and Compliance

> Chapter 7 of the Courseiva AWS-NETWORKING-SPECIALTY curriculum — https://courseiva.com/learn/aws-networking-specialty/network-architecture-hardening-and-compliance

**Official objective:** 3.3 — Implement network governance and compliance using AWS Config, security groups, and network ACLs.

## Introduction

How do you stop a stranger from walking into a private cloud network and stealing your company’s customer data? In AWS, you use three main tools: security groups, network ACLs, and AWS Config to build a hardened, compliant network that blocks attacks and passes audits. For the ANS-C01 exam, understanding how these tools work together to enforce access rules and detect misconfigurations is essential — it is the difference between a secure architecture and a breach waiting to happen.

## The Museum Security System Analogy

A museum holds priceless artefacts behind glass cases. Its security system does not rely on a single lock. Instead, it has layers: a fence around the perimeter, guards at the entrance, motion sensors in the galleries, and reinforced glass on each display case. Each layer serves a distinct purpose and stops a different type of threat.

In a cloud network, security groups and network ACLs work exactly like these layered museum defences. The fence is the outer network ACL — a stateless filter that checks traffic based on IP addresses and port numbers before anything enters or leaves an entire subnet (a group of resources). The gallery motion sensors are the security groups — stateful firewalls that track active sessions and allow return traffic automatically. They sit right next to each resource (like an Amazon EC2 instance) and control what comes in and out.

AWS Config is the security audit team. It walks through every room, every case, every guard post, and checks that each lock is properly configured and follows the museum’s rules. If a guard leaves a door open, Config raises an alert. If a display case is missing its glass, Config logs the violation. Together, these three tools enforce network governance and compliance: they define who can enter, what they can touch, and ensure the rules never accidentally get loosened.

## Core explanation

Network architecture hardening and compliance is the practice of locking down your cloud network so that only the right traffic can flow, and proving to auditors that the locks are correctly installed. In AWS, the three primary tools are security groups, network ACLs (access control lists), and AWS Config.

A security group acts as a virtual firewall for a single AWS resource, such as an Amazon EC2 instance (a virtual server in the cloud). It is stateful, meaning if you allow incoming traffic on a specific port, the security group automatically remembers that connection and allows the response traffic to leave, even if you have not defined an explicit outbound rule for it. Security groups only support allow rules — you cannot write a rule that explicitly denies traffic. By default, all inbound traffic is denied, and all outbound traffic is allowed. You can only add allow rules to open specific ports, IP ranges, or other security groups.

A network ACL is a stateless firewall that operates at the subnet level. A subnet is a logical subdivision of a Virtual Private Cloud (VPC) — your private network segment in AWS. Unlike security groups, network ACLs support both allow and deny rules. They are evaluated in numerical order (from lowest rule number to highest). Because network ACLs are stateless, you must explicitly define both inbound and outbound rules for permitted traffic; the ACL does not track connection state. If you allow inbound HTTP traffic from the internet, you must also specify an outbound rule allowing the response traffic back. This makes network ACLs ideal for setting broad boundaries, like blocking traffic from entire countries or known malicious IP ranges.

AWS Config is a fully managed service that continuously monitors your AWS resources and evaluates their configurations against rules you define. For example, you can create a Config rule that requires every security group to restrict SSH access (port 22) to a specific IP range used by your administrators. If someone opens SSH to the entire internet (0.0.0.0/0), AWS Config will detect the change, flag it as a non-compliant resource, and — if you set it up — trigger an automatic remediation action, such as sending an alert or reverting the change. AWS Config does not prevent changes; it detects them after they happen and helps you enforce governance.

These three tools work together to implement defence in depth — the principle of using multiple layers of security so that if one fails, another still protects you. A typical hardened architecture looks like this:

- The VPC has a network ACL applied to each subnet, blocking known-bad IP ranges and ports that should never be used (for example, blocking all inbound traffic on port 3389 for Remote Desktop Protocol from the public internet).
- Each EC2 instance in the subnet has a security group that allows only the specific ports required for its role, such as port 443 (HTTPS) for a web server.
- AWS Config continuously scans all security groups and network ACLs to ensure they match the approved baseline. If someone modifies a rule outside of the change management process, Config flags it and can automatically revert the change.

Why does this matter for compliance? Many regulations, such as PCI DSS (Payment Card Industry Data Security Standard), require you to restrict network access based on business need and to log all configuration changes. AWS Config gives you a compliance dashboard showing exactly which resources violate your rules, and it can produce reports for auditors. The combination of security groups (fine-grained control per resource) and network ACLs (broad subnet-level filters) satisfies the requirement for layered network controls.

For the ANS-C01 exam, you must understand the exact differences between security groups and network ACLs: statefulness, rule numbering (ACLs are ordered, security groups are not), default behaviours, and support for deny rules. You also need to know how AWS Config evaluates resources, how to set up custom rules with AWS Lambda (a serverless compute service) for auto-remediation, and how to use Config aggregators to view compliance across multiple AWS accounts and regions. These details appear in scenario-based questions where you must choose the correct tool for a given requirement.

## Real-world context

Imagine you work at a fintech startup that handles credit card transactions. Your compliance officer tells you that the company needs to pass a PCI DSS audit in two weeks. The auditor will check that only authorised individuals can reach the database servers and that every change to the firewall rules is logged and reviewed.

Here is what you actually do step by step:

First, you design the network layout inside a VPC. You create three subnets: one public-facing for the web servers (which must accept traffic from the internet on port 443), one private for the application servers (which only talk to the web servers and the database), and one isolated for the database servers (which should never communicate directly with the internet).

Next, you apply network ACLs to each subnet. For the public subnet, you write an ACL that allows inbound HTTPS (port 443) from 0.0.0.0/0 but blocks all other inbound ports. Because ACLs are stateless, you add a corresponding outbound rule allowing ephemeral ports (1024-65535) back to the internet to satisfy the response traffic. For the database subnet, the ACL blocks all inbound traffic except from the application subnet's IP range on port 3306 (MySQL).

Then you create security groups. The web server security group allows inbound HTTPS from 0.0.0.0/0 and nothing else. The application security group allows inbound traffic only from the web security group (not from a specific IP, but from the security group itself). The database security group allows inbound MySQL traffic only from the application security group. This way, if an attacker compromises the web server, they still cannot reach the database directly because the database security group only trusts traffic from the application group.

Now you enable AWS Config with the PCI DSS security hub standard. You create a custom Config rule using AWS Lambda that checks every security group for rules that allow SSH (port 22) from 0.0.0.0/0. If any such rule appears, the Lambda function automatically sends an alert to the security team and — if you configure it — removes the offending rule. You also set up an SNS (Simple Notification Service) topic to email the compliance officer whenever a change is detected.

During the audit, the auditor asks to see all the changes made to security groups in the last 90 days. You open the AWS Config timeline for each security group, which shows every configuration change, who made it (the IAM user or role), and when. Because Config stores the entire configuration history, you can demonstrate that every change was tracked and that no unauthorised modifications occurred.

The real world value is this: without AWS Config, you would have to manually check each security group every day — impossible at scale. Without network ACLs, a single misconfigured security group could expose your database directly to the internet. By layering all three, you protect your company from breaches, pass audits, and sleep better at night.

## Exam focus

The ANS-C01 exam tests network architecture hardening and compliance in at least four distinct ways: scenario selection, difference spotting, compliance mapping, and troubleshooting.

First, scenario selection questions describe a business requirement and ask you to choose the correct tool. For example: 'A company needs to block all inbound traffic from a specific malicious IP address at the subnet boundary. Which should they use?' The correct answer is a network ACL because it supports deny rules and operates at the subnet level. The trap option is a security group, which only supports allow rules.

Second, difference spotting questions directly ask you to compare security groups and network ACLs. Examiners love the stateful versus stateless distinction. A typical trap: they describe a scenario where outbound traffic is blocked and ask why — the answer is often that the network ACL is missing the corresponding outbound rule, not that the security group is blocking it (because security groups allow outbound by default). Memorise these contrasts:

- Security groups: stateful, only allow rules, evaluated as a whole (no rule numbers), applied to an instance or elastic network interface.
- Network ACLs: stateless, allow and deny rules, evaluated in order (lowest number first), applied to a subnet.

Third, compliance mapping questions ask you to link a specific compliance requirement to the appropriate AWS service. For instance, 'Which service provides a compliance dashboard showing compliance status against a rule that SSH is not open to the internet?' Answer: AWS Config. They may also ask about AWS Config aggregated rules across multiple accounts using an aggregator. Know that Config can evaluate custom rules written in AWS Lambda and that it can automatically remediate non-compliant resources using Systems Manager Automation or Lambda.

Fourth, troubleshooting questions present a configuration that is not working and ask you to identify the cause. For example: 'An administrator configured a security group to allow inbound HTTP traffic from the internet, but users cannot reach the web server. What is the most likely issue?' The trap is that the administrator forgot to check the network ACL, which by default denies all inbound traffic. The correct answer is that the network ACL on the subnet is blocking the traffic.

Exam traps often revolve around default behaviour. Remember: a newly created network ACL denies all inbound and outbound traffic until you explicitly add rules. A newly created security group denies all inbound but allows all outbound. If you do not attach a security group to a resource, AWS denies all traffic to that resource (though it is possible to launch an instance without a security group, but then no traffic can reach it).

The exam also tests AWS Config rule types: managed rules (predefined by AWS, like 'restricted-ssh') and custom rules (written in Lambda). You must know that Config does not prevent changes — it only detects and reports. For automatic remediation, you need to configure an action in Config itself or use EventBridge to trigger a Lambda function.

Finally, be prepared for multi-account questions. For example, a company has 50 AWS accounts and wants to enforce that all security groups in all accounts block port 22 from the internet. The solution is to deploy an AWS Config rule in each account using a StackSet (AWS CloudFormation) and aggregate the results to a central account using an aggregator. Do not confuse this with AWS Organizations service control policies (SCPs), which restrict permissions but do not evaluate resource configurations.

## Step by step

1. **Define compliance rules** — First, identify the specific security rules your organisation must follow, such as 'SSH must be restricted to a specific internal IP range' or 'no security group should allow inbound traffic on port 3389 from 0.0.0.0/0'. Write these rules as human-readable policies.
2. **Translate rules into AWS Config rules** — Either select a managed AWS Config rule that matches your requirement (e.g., 'restricted-ssh') or write a custom rule in AWS Lambda that evaluates each resource against your policy. Deploy these rules in every account and region where you need compliance.
3. **Apply baseline network ACLs per subnet** — Create network ACLs for each subnet in your VPC with explicit allow and deny rules matching your compliance requirements. Because ACLs are stateless, ensure you include corresponding outbound rules for all allowed inbound traffic. Apply the ACL to the subnet.
4. **Define and attach security groups per resource** — Create security groups for each type of resource (web server, application server, database) with the minimum required ports and sources. Attach the correct security group to each EC2 instance or elastic network interface. Use security group IDs as sources instead of IP ranges where possible to simplify management.
5. **Enable AWS Config and set up remediation** — Turn on AWS Config in your account. For critical rules, configure automatic remediation using Systems Manager Automation or a Lambda function. For example, if a security group rule opens SSH to the internet, the Lambda can delete that rule and log the event.
6. **Monitor and audit periodically** — Review AWS Config compliance dashboard weekly or set up automated alerts via Amazon SNS for any non-compliant changes. Use Config's timeline feature to produce audit trails for compliance officers. Update rules as business requirements change.

## Comparisons

### Security Group vs Network ACL

**Security Group:**
- Stateful: automatically allows return traffic
- Supports only allow rules
- Applies to individual resources (EC2, ENI)

**Network ACL:**
- Stateless: requires explicit outbound rules
- Supports both allow and deny rules
- Applies to entire subnets

### Security Group vs Network ACL

**Security Group:**
- Rules are evaluated as a whole (no order)
- Default: denies all inbound, allows all outbound
- Cannot block traffic from specific IP addresses you want to deny

**Network ACL:**
- Rules evaluated in numerical order (lowest number first)
- Default: denies all inbound and outbound
- Can block traffic from specific IP addresses using deny rules

### AWS Config vs AWS CloudTrail

**AWS Config:**
- Monitors resource configurations for compliance
- Evaluates against rules you define
- Provides a compliance dashboard and timeline of changes

**AWS CloudTrail:**
- Records API calls made to AWS
- Captures who made changes, what changed, and when
- Does not evaluate configuration against rules

## Diagram

_Flow of traffic from the internet through a network ACL and security group, showing how both layers must permit the traffic for the application to receive it._

```mermaid
flowchart TD
    A[Internet] -->|Inbound traffic| B[Network ACL at Subnet]
    B --> C{ACL rule match?}
    C -->|Allow| D[Security Group on Instance]
    C -->|Deny| E[Traffic dropped]
    D --> F{Inbound rule in SG?}
    F -->|Allow| G[Application]
    F -->|Deny by default| E
    G -->|Response traffic| H[Security Group stateful return]
    H --> I[Network ACL outbound rule]
    I --> A
```

## Common misconceptions

- **Misconception:** Security groups and network ACLs provide the same level of security, so you only need one. **Reality:** Security groups and network ACLs serve different purposes and should be used together. Security groups protect individual resources with stateful filtering; network ACLs provide a stateless perimeter barrier at the subnet level. Using both creates defence in depth. (Beginners see both as 'firewalls' and assume they are redundant, but they work at different layers of the OSI model and have different features (deny rules, statefulness, rule ordering).)
- **Misconception:** If I allow inbound traffic on a security group, the return traffic is automatically allowed because security groups are stateful, so I do not need to worry about network ACLs. **Reality:** Security groups are stateful, but network ACLs are not. If a network ACL is applied to the subnet, it must explicitly allow the inbound and outbound traffic. The statefulness of the security group does not bypass the network ACL. (People think statefulness means 'all traffic related to an allowed connection is allowed everywhere', when it only applies to the security group level, not the subnet ACL level.)
- **Misconception:** AWS Config can block changes to security groups that violate a rule. **Reality:** AWS Config only detects and reports non-compliant resources. It does not block changes in real time. To automatically revert or remediate, you must configure custom actions using AWS Lambda, Systems Manager Automation, or EventBridge. (The term 'compliance' leads people to think Config enforces rules proactively, similar to a firewall. In reality, it is a detective control, not a preventive one.)
- **Misconception:** A network ACL with a single deny rule for a malicious IP address will block that IP from reaching any instance in the subnet. **Reality:** A network ACL evaluates rules in numerical order. If any rule with a lower number allows traffic, that traffic will be permitted even if a higher-numbered deny rule exists. The deny rule only applies if no allow rule matches first. (People think deny rules automatically override allow rules, but ACLs are processed top-down, and the first matching rule wins.)

## Key takeaways

- Security groups are stateful and only support allow rules, while network ACLs are stateless and support both allow and deny rules evaluated in order.
- Defence in depth in AWS means using security groups at the resource level and network ACLs at the subnet level together.
- AWS Config is a detective control that monitors resource configurations and reports non-compliance, but it does not prevent changes in real time.
- A newly created network ACL denies all inbound and outbound traffic by default, while a new security group denies inbound but allows outbound.
- To automatically remediate a non-compliant security group rule, you must combine AWS Config with a custom action such as an AWS Lambda function.
- For multi-account compliance, use AWS Config aggregators to centralise compliance views from multiple accounts and regions.

## FAQ

**What is the difference between a security group and a network ACL in AWS?**

A security group is a stateful firewall that protects individual resources (like an EC2 instance) and only supports allow rules. A network ACL is a stateless firewall that protects an entire subnet and supports both allow and deny rules, evaluated in numerical order.

**Can I use both a security group and a network ACL on the same EC2 instance?**

Yes, you can and should use both. The network ACL is applied at the subnet level and filters traffic before it reaches the instance. The security group then filters traffic further at the instance level. Both must permit the traffic for it to reach the application.

**How does AWS Config help with compliance?**

AWS Config continuously evaluates the configuration of your AWS resources against rules you define. It generates compliance reports, sends alerts when resources become non-compliant, and can trigger automatic remediation through Lambda functions or Systems Manager Automation.

**What happens if I do not attach any security group to an EC2 instance?**

If you launch an EC2 instance without attaching a security group, AWS will not assign a default group. The instance will have no inbound or outbound rules, meaning all traffic to and from the instance will be blocked. This is rarely desirable.

**Why do I need to add outbound rules to a network ACL?**

Network ACLs are stateless, meaning they do not track the state of connections. If you allow inbound traffic on a network ACL, you must also explicitly allow the outbound response traffic on the same ACL, otherwise the response will be blocked and the connection will fail.

**How can I enforce the same security group rules across multiple AWS accounts?**

You can use AWS CloudFormation StackSets to deploy the same security group configuration and AWS Config rules across multiple accounts. Then aggregate the compliance results into a central account using an AWS Config aggregator.

## Check your understanding

1. **What is the key difference in statefulness between a security group and a network ACL?**

   Answer: A security group is stateful (automatically allows return traffic for allowed inbound connections), while a network ACL is stateless (requires explicit outbound rules for response traffic).

2. **If you need to block all inbound traffic from a specific IP address at the subnet level, which AWS service should you use?**

   Answer: You should use a network ACL, because it supports deny rules and operates at the subnet boundary. A security group only supports allow rules.

3. **What is the default behaviour of a newly created network ACL?**

   Answer: A newly created network ACL denies all inbound and outbound traffic by default. You must add rules to allow desired traffic.

4. **How can you automatically revert a security group rule that violates a compliance policy?**

   Answer: Use AWS Config with a custom rule backed by an AWS Lambda function that detects the non-compliance and calls the EC2 API to revoke the offending rule.

5. **Can AWS Config prevent a user from making a change to a security group in real time?**

   Answer: No, AWS Config is a detective control that detects and reports changes after they occur. It cannot block changes in real time. For prevention, use IAM policies or service control policies.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-networking-specialty/network-architecture-hardening-and-compliance