Automating network segmentation with AWS security groups and NACLs

Network segmentation in AWS is a control system, not a single firewall rule. Security groups protect resources at the elastic network interface, while network access control lists (NACLs) filter traffic at the subnet boundary. Used together, they can separate public-facing services, application tiers, databases, administration paths, and shared services.

Manual configuration becomes unreliable as environments grow across multiple accounts and VPCs. A new workload might inherit the wrong subnet, an overly broad inbound rule may remain after a migration, or a temporary exception may never be removed. Infrastructure as code and event-driven automation provide a repeatable way to enforce the intended design.

Australian organisations also need to consider data location, audit evidence, and operational habits. Workloads commonly run in the AWS Asia Pacific (Sydney) or Melbourne regions, teams support hybrid offices over NBN and business circuits, and regulated environments may align controls with the Australian Government Information Security Manual (ISM), the Essential Eight, and Privacy Act obligations.

Understand the two enforcement layers

Security groups are stateful and attached to network interfaces. If an inbound connection is permitted, the response traffic is automatically allowed. Rules can reference other security groups, which is useful for expressing relationships such as “the application tier may connect to the database tier on TCP 5432”.

NACLs are stateless and associated with subnets. Both inbound and outbound traffic must be explicitly permitted, and rules are processed by number from the lowest value upwards. A deny rule can override a later allow rule, making rule ordering and change control particularly important.

A practical design uses security groups for workload identity and least-privilege access, with NACLs providing broad subnet-level guardrails. NACLs should not become a dense copy of every application rule; that approach increases operational risk and makes incident response slower.

Model tiers before writing rules

Start with a segmentation model that reflects traffic flows rather than organisational labels. A typical VPC may contain internet-facing load balancers, private application instances, data services, management tooling, and VPC endpoints. Document which tier initiates each connection, the required port, and whether the flow is internal, hybrid, or internet-bound.

Use separate subnets for materially different trust zones. Public subnets may host load balancers, while application and database subnets remain private. Dedicated management subnets can restrict access to bastion services, Systems Manager endpoints, or approved administration networks.

In Sydney and Melbourne deployments, separate availability zones should retain equivalent controls. A failover event should not move traffic into a subnet with a weaker NACL or an inconsistent route table. Treat the segmentation model as an architecture artefact that can be tested and reviewed.

Store policy as infrastructure code

Terraform, AWS CloudFormation, and AWS CDK can define VPCs, subnet associations, security groups, NACL entries, and rule descriptions in version control. This creates an auditable history and allows peer review before production changes. Variables can represent account, environment, region, and approved CIDR ranges without duplicating the entire policy.

Avoid embedding large lists of individual addresses in application templates. AWS-managed prefix lists, customer-managed prefix lists, and centrally maintained IP address data are easier to update. AWS VPC IP Address Manager (IPAM) can help allocate and track CIDR ranges across accounts, reducing overlap in hybrid environments.

A useful policy convention includes the application owner, purpose, ticket reference, expiry date, and data classification. Tags do not enforce access by themselves, but they allow automation to identify unmanaged or non-compliant resources.

Automate changes safely

A deployment pipeline should validate network policy before applying it. Terraform plan reviews, CloudFormation change sets, policy-as-code checks, and automated tests can detect unrestricted ingress, overlapping CIDRs, invalid rule references, or missing subnet associations. Tools such as Checkov, tfsec, and AWS Config rules can support these checks.

EventBridge can detect events such as a new security group, a changed ingress rule, or a VPC modification. A Lambda function can then record the change, open a remediation ticket, or revert clearly unauthorised activity. Automatic rollback should be limited to well-understood violations; removing a rule during a live incident can interrupt customer traffic or replication.

Use a break-glass process for urgent access. Emergency changes should be time-limited, logged, and reviewed after the event. This is particularly important for Australian teams supporting customers across Perth, Adelaide, Brisbane, and eastern-state time zones.

Control hybrid and shared connectivity

Segmentation must account for VPNs, Direct Connect, transit gateways, and shared services VPCs. A route that exists does not automatically mean traffic is allowed: security groups, NACLs, routing, firewall policies, and on-premises controls all participate in the final path.

Keep administrative access separate from application traffic. Rather than allowing broad corporate CIDR ranges into every workload, use Systems Manager Session Manager, private endpoints, or a narrowly scoped management security group. This reduces exposure when a branch network, home router, or remote-access account is compromised.

For organisations using Telstra, Optus, or other managed connectivity providers, document advertised routes and failover behaviour alongside AWS rules. Test both primary and backup paths. A network policy that works over Direct Connect but fails when traffic moves through a VPN is not operationally complete.

Monitor drift and prove intent

AWS Config, CloudTrail, VPC Flow Logs, and Security Hub provide complementary visibility. Config can identify resources without required controls, CloudTrail records configuration changes, and flow logs show accepted and rejected traffic. Flow logs should be sent to a protected destination with retention aligned to security and compliance requirements.

Build dashboards around meaningful questions: Which security groups allow public administration ports? Which subnets have unexpected NACL associations? Which rejected flows indicate an application dependency rather than an attack? A rejected connection can reveal a genuine segmentation fault, especially after a migration or software update.

For workloads handling personal information, align retention and access to the Privacy Act and the Notifiable Data Breaches scheme. Where customers require Australian data residency, keep logs and supporting services in approved Australian regions and document any cross-border processing.

Apply a practical operating checklist

Automation works best when the policy is simple enough for engineers to understand and strict enough to prevent accidental exposure. The following controls create a useful baseline:

• Deny public access to administrative ports such as SSH and RDP
• Reference security groups instead of broad internal CIDRs where possible
• Apply standard NACLs consistently across equivalent subnets
• Require an owner and expiry date for temporary access rules

A second checklist can guide testing before and after a deployment:

• Verify application-to-database flows from each availability zone
• Test rejected traffic from public, private, and management subnets
• Confirm VPN and Direct Connect failover paths
• Review CloudTrail, Config, and flow-log evidence

Test continuously and refine exceptions

Network segmentation should be tested as code and as a live service. Automated connectivity checks can verify expected flows, while AWS Reachability Analyzer helps diagnose whether routing and security controls permit a path. Include negative tests that confirm prohibited traffic is rejected.

Exceptions should have a clear business reason and a removal date. A temporary vendor connection, migration port, or troubleshooting rule can be represented as a controlled parameter rather than edited directly in production. When the exception expires, the pipeline or an event-driven function can remove it and record the result.

The strongest design makes the secure path the easiest path. Engineers receive reusable modules, approved prefixes, standard security groups, and documented patterns for public, private, and hybrid workloads. This combines least privilege with the reliability required to operate AWS infrastructure across Australia.