The Tiered Security Group Pattern: Building Intent-Based Network Boundaries in AWS

Security groups are among the most important—and most frequently misconfigured—security controls in an AWS environment.

A security group acts as a stateful virtual firewall for resources such as EC2 instances, load balancers, and databases. It controls which traffic may enter or leave a resource based on protocol, port, and source or destination. Because security groups are stateful, return traffic for an allowed connection is automatically permitted. (docs.aws.amazon.com)

The simplest implementation might attach one broadly permissive security group to every resource in an application. Although convenient, this approach creates an unnecessarily large attack surface. If one system is compromised, the attacker may be able to communicate directly with databases, management interfaces, monitoring systems, and other sensitive components.

A stronger approach is the Tiered Security Group Pattern.

Instead of treating the VPC as one trusted network, this pattern creates a distinct security boundary around each architectural tier, environment, and application. Communication is permitted only where there is a documented business or technical requirement.

What Is the Tiered Security Group Pattern?

The Tiered Security Group Pattern assigns different security groups to resources with different functions.

A typical three-tier application might use:

• An internet-facing load balancer security group
• A web-tier security group
• An application-tier security group
• A database-tier security group
• An administrative-access security group
• A monitoring or observability security group

Each security group describes the network role of the resources associated with it.

For example:

The resulting communication path is deliberate:

Internet → Load Balancer → Web Tier → Application Tier → Database Tier

The database is not reachable from the internet, the load balancer, or the web tier. It accepts connections only from resources associated with the application-tier security group.

This is network least privilege expressed in architectural terms.

Use Security Group References Instead of Hard-Coded IP Addresses

One of the most valuable characteristics of AWS security groups is the ability to reference another security group as the source or destination of a rule.

Suppose the application tier must accept HTTPS connections from the web tier. The application security group can contain the following inbound rule:

Protocol: TCP
Port: 443
Source: sg-web-tier

The rule effectively says:

Permit TCP port 443 from resources associated with the approved web-tier security group.

This is superior to a rule such as:

Protocol: TCP
Port: 443
Source: 10.20.10.0/24

The CIDR-based rule trusts every resource that can obtain an address within that subnet. The security-group-based rule trusts only resources assigned the expected security identity.

AWS evaluates incoming traffic from a referenced security group using the private IP addresses of the resources associated with that group. (Amazon Elastic Compute Cloud)

Why SG-to-SG references are more resilient

Cloud resources are dynamic. Instances are replaced, containers move, Auto Scaling groups expand and contract, and load balancer nodes change over time.

If access depends on individual IP addresses, every infrastructure change can require a corresponding firewall change. That creates several problems:

• Rules become stale.
• Old addresses remain trusted.
• New instances may not work until rules are updated.
• Operations teams add broad CIDR ranges as a workaround.
• Security reviews become difficult because the purpose of each IP address is unclear.

A security group reference avoids this dependency. Access follows the resource’s assigned role rather than its current IP address.

The rule remains valid when an instance is replaced or an application scales horizontally—as long as the appropriate security group is attached to the new resource.

1. Tier-Based Security Groups

Tier-based security groups separate resources according to their position and function within an architecture.

Load balancer security group

The public load balancer may accept HTTPS traffic from the internet:

Inbound:
TCP 443 from 0.0.0.0/0
TCP 443 from ::/0

Public access should terminate at a deliberately exposed service such as an Application Load Balancer rather than directly on application servers.

If CloudFront is the intended entry point, the load balancer can be restricted further by using the appropriate AWS-managed prefix list instead of accepting traffic from the entire internet.

Web-tier security group

The web tier should accept traffic only from the load balancer security group:

Inbound:
TCP 443 from sg-public-alb

This prevents clients from bypassing the load balancer and connecting directly to a web server—even if routing or another configuration mistake makes the server reachable.

AWS specifically supports configuring target security groups to accept traffic only from the security group associated with a load balancer. (Elastic Load Balancing)

Application-tier security group

The application tier should accept only the protocols required by the web tier:

Inbound:
TCP 8443 from sg-web

A web server compromise would therefore give an attacker access only to the application endpoint explicitly authorized by this rule. It would not automatically provide access to SSH, management interfaces, databases, or unrelated services.

Database-tier security group

The database security group should allow the database port only from the application security group:

Inbound:
TCP 5432 from sg-application

It should not allow database access from:

• The internet
• The complete VPC CIDR
• Every private subnet
• The load balancer
• The web tier
• Developer workstations
• A general-purpose “internal” security group

AWS recommends creating security group rules based on the role of the associated resource—for example, web-server rules for web servers and database-specific rules for database systems. (docs.aws.amazon.com)

Administrative security group

Administrative access deserves its own boundary.

Avoid opening SSH or RDP to the internet. AWS Security Hub treats unrestricted access to SSH, RDP, and other high-risk ports as a significant security issue. (docs.aws.amazon.com)

Where possible, use AWS Systems Manager Session Manager so instances do not require publicly exposed administrative ports. If a bastion host or management appliance is necessary, create a dedicated security group and restrict access to an approved VPN, corporate network, or managed prefix list.

2. Environment-Isolated Security Groups

Production, staging, development, and test environments should not share the same application security groups.

Use separate security group sets such as:

prod-alb-sg
prod-web-sg
prod-app-sg
prod-db-sg

stage-alb-sg
stage-web-sg
stage-app-sg
stage-db-sg

dev-alb-sg
dev-web-sg
dev-app-sg
dev-db-sg

This prevents a development resource from becoming implicitly trusted by production simply because both systems perform a similar function.

For stronger isolation, place environments in separate AWS accounts and VPCs. Security groups then reinforce the account and network boundaries rather than attempting to replace them.

Production security groups should generally have:

• Fewer permitted flows
• Tighter egress controls
• Separate change approval
• Infrastructure-as-code ownership
• Automated compliance monitoring
• Alerts for unauthorized modifications

Development environments can remain flexible without forcing production to inherit the same permissive rules.

Avoid cross-environment references

Rules such as the following should be treated with suspicion:

prod-db-sg:
TCP 5432 from dev-app-sg

If developers need production data access, provide a controlled access mechanism with explicit authentication, authorization, auditing, and time-bounded approval. Do not create a permanent network trust relationship merely because it is operationally convenient.

3. Application-Scoped Security Groups

Tier separation alone may not be sufficient in a shared VPC.

Imagine that ten applications use the same application-tier security group. If the database security group trusts that shared group, every application associated with it may be able to reach the database—even when only one application requires access.

A stronger design gives each application or service its own security groups:

payments-prod-api-sg
payments-prod-db-sg

orders-prod-api-sg
orders-prod-db-sg

customer-prod-api-sg
customer-prod-db-sg

The Payments database accepts traffic only from the Payments application security group. The Orders application cannot connect to it simply because both workloads reside in the same subnet or application tier.

This creates a more meaningful security boundary:

Access is granted to a specific application role, not to a broad category of machines.

Application teams can own the ingress rules for their services, subject to centrally enforced guardrails.

Ingress Should Be Application-Owned

Each service should define who may initiate connections to it.

For example, the team responsible for an internal pricing API might own an ingress security group containing:

TCP 443 from sg-checkout-service
TCP 443 from sg-order-service

These rules clearly identify the approved consumers of the API.

This model improves:

• Ownership
• Change accountability
• Impact analysis
• Incident response
• Architecture reviews
• Automated policy validation

When a service is retired or a dependency is removed, its SG-to-SG rule can be removed without reviewing unrelated subnet ranges.

Treat Shared Egress Security Groups Carefully

Some organizations use a small, centrally managed egress security group for common destinations such as:

• DNS services
• Approved HTTPS endpoints
• Central proxies
• Monitoring collectors
• Patch repositories
• VPC endpoints

This can be useful, but there is an important AWS behavior to understand: when multiple security groups are associated with a resource, their rules are combined. Security groups do not contain explicit deny rules. A permissive rule in any attached security group can therefore undermine tighter rules in the others. (Amazon Virtual Private Cloud)

A shared egress security group should consequently contain only narrowly defined, genuinely common access. Do not attach an “allow all outbound” group and assume an application-specific security group can override it.

For precise egress control, consider a combination of:

• Destination security-group references
• AWS-managed or customer-managed prefix lists
• VPC endpoints
• Central egress proxies
• Route 53 Resolver DNS Firewall
• AWS Network Firewall
• Explicit application-level allowlists

Security Groups Describe Permission, Not Connectivity

An SG-to-SG rule permits traffic; it does not create a network path.

The architecture still requires:

• Valid routes
• Compatible subnet routing
• Correct load balancer configuration
• Working DNS resolution
• Network ACL compatibility
• Listening application services
• VPC peering, Transit Gateway, or another supported connection where applicable

Security group references also require special care when traffic passes through a middlebox or inspection appliance. AWS documents that SG references between the original source and final destination might not work when the traffic is routed through a middlebox. In those cases, private IP addresses or appropriate subnet CIDRs may be required. (Amazon Virtual Private Cloud)

Security-group references should therefore be the default for direct workload relationships, but they are not a universal substitute for understanding the traffic path.

Naming and Tagging Standards

A security group should communicate its purpose without requiring an engineer to inspect every rule.

A practical naming format is:

<application>-<environment>-<tier>-sg

Examples:

payments-prod-alb-sg
payments-prod-api-sg
payments-prod-db-sg
payments-prod-monitoring-sg

Recommended tags include:

Rule descriptions should also be mandatory:

Allow PostgreSQL from Payments API
Allow HTTPS health checks from production ALB
Allow telemetry to central monitoring collector

Descriptions such as “temporary,” “internal,” or “required for testing” provide little governance value and have a habit of becoming permanent.

Infrastructure as Code

Tiered security groups should be created through Terraform, AWS CloudFormation, AWS CDK, or another controlled infrastructure-as-code process.

A simplified Terraform example looks like this:

resource "aws_security_group" "app" {
  name        = "payments-prod-app-sg"
  description = "Security group for the Payments production application tier"
  vpc_id      = aws_vpc.production.id
}

resource "aws_vpc_security_group_ingress_rule" "app_from_web" {
  security_group_id            = aws_security_group.app.id
  referenced_security_group_id = aws_security_group.web.id
  ip_protocol                  = "tcp"
  from_port                    = 8443
  to_port                      = 8443

  description = "Allow application traffic from Payments web tier"
}

resource "aws_security_group" "database" {
  name        = "payments-prod-db-sg"
  description = "Security group for the Payments production database"
  vpc_id      = aws_vpc.production.id
}

resource "aws_vpc_security_group_ingress_rule" "database_from_app" {
  security_group_id            = aws_security_group.database.id
  referenced_security_group_id = aws_security_group.app.id
  ip_protocol                  = "tcp"
  from_port                    = 5432
  to_port                      = 5432

  description = "Allow PostgreSQL from Payments application tier"
}

Infrastructure as code provides version history, peer review, repeatability, and automated testing. It also reduces configuration drift between environments.

Governance and Continuous Validation

A good pattern can deteriorate if nobody monitors it.

Organizations should continuously check for:

• 0.0.0.0/0 and ::/0 on unauthorized ports
• Databases reachable from public or broad internal sources
• SSH and RDP exposed to the internet
• Rules covering entire VPC CIDRs without justification
• Cross-environment access
• Cross-application trust
• Unused security groups
• Duplicate security groups
• Stale referenced security groups
• Security groups changed outside the approved deployment process
• Default security groups containing active rules
• Unrestricted outbound access from sensitive workloads

AWS Config can evaluate security group configurations, while Security Hub provides controls for unrestricted high-risk ports and other unsafe network configurations. AWS Firewall Manager can centrally apply, audit, and remediate security group policies across an AWS organization. It can also identify unused or redundant security groups. (AWS Config)

VPC Flow Logs and Network Access Analyzer can provide additional visibility into actual traffic and unintended network paths. (docs.aws.amazon.com)

Common Anti-Patterns

One security group for the entire application

This eliminates meaningful separation between web, application, database, and administration tiers.

Trusting the entire VPC

A rule allowing a database connection from the complete VPC CIDR treats every workload in the VPC as trusted.

Reusing production SGs in non-production

This creates unintended trust relationships and weakens environment isolation.

Hard-coding individual private IP addresses

This makes security rules fragile and difficult to maintain in an elastic environment.

Leaving the default outbound rule unchanged everywhere

New security groups commonly begin with an outbound rule permitting all traffic. Whether that is acceptable should be an explicit risk decision, not an unnoticed default. AWS allows this rule to be removed and replaced with specific outbound permissions. (Amazon Virtual Private Cloud)

Opening management ports temporarily

Temporary 0.0.0.0/0 SSH and RDP rules are frequently forgotten. Use Session Manager, VPN-based administration, or an automatically expiring access workflow.

Attaching too many security groups

Because rules are aggregated, attaching multiple SGs can create permissions that are difficult to understand. More security groups do not automatically mean more security.

A Practical Design Principle

Every security group rule should answer four questions:

1. Who is initiating the connection?
2. Which service is receiving it?
3. Which protocol and port are required?
4. Why is the connection necessary?

If a rule cannot answer those questions clearly, it is probably too broad.

The Tiered Security Group Pattern transforms security groups from collections of ports and IP addresses into an expression of application architecture:

• The load balancer may communicate with the web tier.
• The web tier may communicate with the application tier.
• The application tier may communicate with its database.
• Monitoring systems may reach defined telemetry endpoints.
• Administrators may enter only through an approved management path.
• Development systems may not communicate with production.
• One application may not inherit access intended for another.

That is the central idea: grant access according to workload identity, architectural tier, application ownership, and environment—not merely according to network location.

When properly implemented, tiered security groups reduce lateral movement, contain compromised workloads, simplify security reviews, and make the intended architecture visible directly in the network policy.

“`
Also read VPC Security Best Practices

The Tiered Security Group Pattern: Building Intent-Based Network Boundaries in AWS

Security groups are among the most important—and most frequently misconfigured—security controls in an AWS environment.

A security group acts as a stateful virtual firewall for resources such as EC2 instances, load balancers, and databases. It controls which traffic may enter or leave a resource based on protocol, port, and source or destination. Because security groups are stateful, return traffic for an allowed connection is automatically permitted.

The simplest implementation might attach one broadly permissive security group to every resource in an application. Although convenient, this approach creates an unnecessarily large attack surface. If one system is compromised, the attacker may be able to communicate directly with databases, management interfaces, monitoring systems, and other sensitive components.

A stronger approach is the Tiered Security Group Pattern.

Instead of treating the VPC as one trusted network, this pattern creates a distinct security boundary around each architectural tier, environment, and application. Communication is permitted only where there is a documented business or technical requirement.

What Is the Tiered Security Group Pattern?

The Tiered Security Group Pattern assigns different security groups to resources with different functions.

A typical three-tier application might use:

• An internet-facing load balancer security group
• A web-tier security group
• An application-tier security group
• A database-tier security group
• An administrative-access security group
• A monitoring or observability security group

Each security group describes the network role of the resources associated with it.

For example:

The resulting communication path is deliberate:

Internet → Load Balancer → Web Tier → Application Tier → Database Tier

The database is not reachable from the internet, the load balancer, or the web tier. It accepts connections only from resources associated with the application-tier security group.

This is network least privilege expressed in architectural terms.

Use Security Group References Instead of Hard-Coded IP Addresses

One of the most valuable characteristics of AWS security groups is the ability to reference another security group as the source or destination of a rule.

Suppose the application tier must accept HTTPS connections from the web tier. The application security group can contain the following inbound rule:

Protocol: TCP
Port: 443
Source: sg-web-tier

The rule effectively says:

Permit TCP port 443 from resources associated with the approved web-tier security group.

This is superior to a rule such as:

Protocol: TCP
Port: 443
Source: 10.20.10.0/24

The CIDR-based rule trusts every resource that can obtain an address within that subnet. The security-group-based rule trusts only resources assigned the expected security identity.

AWS evaluates incoming traffic from a referenced security group using the private IP addresses of the resources associated with that group.

Why SG-to-SG references are more resilient

Cloud resources are dynamic. Instances are replaced, containers move, Auto Scaling groups expand and contract, and load balancer nodes change over time.

If access depends on individual IP addresses, every infrastructure change can require a corresponding firewall change. That creates several problems:

• Rules become stale.
• Old addresses remain trusted.
• New instances may not work until rules are updated.
• Operations teams add broad CIDR ranges as a workaround.
• Security reviews become difficult because the purpose of each IP address is unclear.

A security group reference avoids this dependency. Access follows the resource’s assigned role rather than its current IP address.

The rule remains valid when an instance is replaced or an application scales horizontally—as long as the appropriate security group is attached to the new resource.

1. Tier-Based Security Groups

Tier-based security groups separate resources according to their position and function within an architecture.

Load balancer security group

The public load balancer may accept HTTPS traffic from the internet:

Inbound:
TCP 443 from 0.0.0.0/0
TCP 443 from ::/0

Public access should terminate at a deliberately exposed service such as an Application Load Balancer rather than directly on application servers.

If CloudFront is the intended entry point, the load balancer can be restricted further by using the appropriate AWS-managed prefix list instead of accepting traffic from the entire internet.

Web-tier security group

The web tier should accept traffic only from the load balancer security group:

Inbound:
TCP 443 from sg-public-alb

This prevents clients from bypassing the load balancer and connecting directly to a web server—even if routing or another configuration mistake makes the server reachable.

AWS specifically supports configuring target security groups to accept traffic only from the security group associated with a load balancer.

Application-tier security group

The application tier should accept only the protocols required by the web tier:

Inbound:
TCP 8443 from sg-web

A web server compromise would therefore give an attacker access only to the application endpoint explicitly authorized by this rule. It would not automatically provide access to SSH, management interfaces, databases, or unrelated services.

Database-tier security group

The database security group should allow the database port only from the application security group:

Inbound:
TCP 5432 from sg-application

It should not allow database access from:

• The internet
• The complete VPC CIDR
• Every private subnet
• The load balancer
• The web tier
• Developer workstations
• A general-purpose “internal” security group

AWS recommends creating security group rules based on the role of the associated resource—for example, web-server rules for web servers and database-specific rules for database systems.

Administrative security group

Administrative access deserves its own boundary.

Avoid opening SSH or RDP to the internet. AWS Security Hub treats unrestricted access to SSH, RDP, and other high-risk ports as a significant security issue.

Where possible, use AWS Systems Manager Session Manager so instances do not require publicly exposed administrative ports. If a bastion host or management appliance is necessary, create a dedicated security group and restrict access to an approved VPN, corporate network, or managed prefix list.

2. Environment-Isolated Security Groups

Production, staging, development, and test environments should not share the same application security groups.

Use separate security group sets such as:

prod-alb-sg
prod-web-sg
prod-app-sg
prod-db-sg

stage-alb-sg
stage-web-sg
stage-app-sg
stage-db-sg

dev-alb-sg
dev-web-sg
dev-app-sg
dev-db-sg

This prevents a development resource from becoming implicitly trusted by production simply because both systems perform a similar function.

For stronger isolation, place environments in separate AWS accounts and VPCs. Security groups then reinforce the account and network boundaries rather than attempting to replace them.

Production security groups should generally have:

• Fewer permitted flows
• Tighter egress controls
• Separate change approval
• Infrastructure-as-code ownership
• Automated compliance monitoring
• Alerts for unauthorized modifications

Development environments can remain flexible without forcing production to inherit the same permissive rules.

Avoid cross-environment references

Rules such as the following should be treated with suspicion:

prod-db-sg:
TCP 5432 from dev-app-sg

If developers need production data access, provide a controlled access mechanism with explicit authentication, authorization, auditing, and time-bounded approval. Do not create a permanent network trust relationship merely because it is operationally convenient.

3. Application-Scoped Security Groups

Tier separation alone may not be sufficient in a shared VPC.

Imagine that ten applications use the same application-tier security group. If the database security group trusts that shared group, every application associated with it may be able to reach the database—even when only one application requires access.

A stronger design gives each application or service its own security groups:

payments-prod-api-sg
payments-prod-db-sg

orders-prod-api-sg
orders-prod-db-sg

customer-prod-api-sg
customer-prod-db-sg

The Payments database accepts traffic only from the Payments application security group. The Orders application cannot connect to it simply because both workloads reside in the same subnet or application tier.

This creates a more meaningful security boundary:

Access is granted to a specific application role, not to a broad category of machines.

Application teams can own the ingress rules for their services, subject to centrally enforced guardrails.

Ingress Should Be Application-Owned

Each service should define who may initiate connections to it.

For example, the team responsible for an internal pricing API might own an ingress security group containing:

TCP 443 from sg-checkout-service
TCP 443 from sg-order-service

These rules clearly identify the approved consumers of the API.

This model improves:

• Ownership
• Change accountability
• Impact analysis
• Incident response
• Architecture reviews
• Automated policy validation

When a service is retired or a dependency is removed, its SG-to-SG rule can be removed without reviewing unrelated subnet ranges.

Treat Shared Egress Security Groups Carefully

Some organizations use a small, centrally managed egress security group for common destinations such as:

• DNS services
• Approved HTTPS endpoints
• Central proxies
• Monitoring collectors
• Patch repositories
• VPC endpoints

This can be useful, but there is an important AWS behavior to understand: when multiple security groups are associated with a resource, their rules are combined. Security groups do not contain explicit deny rules. A permissive rule in any attached security group can therefore undermine tighter rules in the others.

A shared egress security group should consequently contain only narrowly defined, genuinely common access. Do not attach an “allow all outbound” group and assume an application-specific security group can override it.

For precise egress control, consider a combination of:

• Destination security-group references
• AWS-managed or customer-managed prefix lists
• VPC endpoints
• Central egress proxies
• Route 53 Resolver DNS Firewall
• AWS Network Firewall
• Explicit application-level allowlists

Security Groups Describe Permission, Not Connectivity

An SG-to-SG rule permits traffic; it does not create a network path.

The architecture still requires:

• Valid routes
• Compatible subnet routing
• Correct load balancer configuration
• Working DNS resolution
• Network ACL compatibility
• Listening application services
• VPC peering, Transit Gateway, or another supported connection where applicable

Security group references also require special care when traffic passes through a middlebox or inspection appliance. AWS documents that SG references between the original source and final destination might not work when the traffic is routed through a middlebox. In those cases, private IP addresses or appropriate subnet CIDRs may be required.

Security-group references should therefore be the default for direct workload relationships, but they are not a universal substitute for understanding the traffic path.

Naming and Tagging Standards

A security group should communicate its purpose without requiring an engineer to inspect every rule.

A practical naming format is:

<application>-<environment>-<tier>-sg

Examples:

payments-prod-alb-sg
payments-prod-api-sg
payments-prod-db-sg
payments-prod-monitoring-sg

Recommended tags include:

Rule descriptions should also be mandatory:

Allow PostgreSQL from Payments API
Allow HTTPS health checks from production ALB
Allow telemetry to central monitoring collector

Descriptions such as “temporary,” “internal,” or “required for testing” provide little governance value and have a habit of becoming permanent.

Infrastructure as Code

Tiered security groups should be created through Terraform, AWS CloudFormation, AWS CDK, or another controlled infrastructure-as-code process.

A simplified Terraform example looks like this:

resource "aws_security_group" "app" {
  name        = "payments-prod-app-sg"
  description = "Security group for the Payments production application tier"
  vpc_id      = aws_vpc.production.id
}

resource "aws_vpc_security_group_ingress_rule" "app_from_web" {
  security_group_id            = aws_security_group.app.id
  referenced_security_group_id = aws_security_group.web.id
  ip_protocol                  = "tcp"
  from_port                    = 8443
  to_port                      = 8443

  description = "Allow application traffic from Payments web tier"
}

resource "aws_security_group" "database" {
  name        = "payments-prod-db-sg"
  description = "Security group for the Payments production database"
  vpc_id      = aws_vpc.production.id
}

resource "aws_vpc_security_group_ingress_rule" "database_from_app" {
  security_group_id            = aws_security_group.database.id
  referenced_security_group_id = aws_security_group.app.id
  ip_protocol                  = "tcp"
  from_port                    = 5432
  to_port                      = 5432

  description = "Allow PostgreSQL from Payments application tier"
}

Infrastructure as code provides version history, peer review, repeatability, and automated testing. It also reduces configuration drift between environments.

Governance and Continuous Validation

A good pattern can deteriorate if nobody monitors it.

Organizations should continuously check for:

• 0.0.0.0/0 and ::/0 on unauthorized ports
• Databases reachable from public or broad internal sources
• SSH and RDP exposed to the internet
• Rules covering entire VPC CIDRs without justification
• Cross-environment access
• Cross-application trust
• Unused security groups
• Duplicate security groups
• Stale referenced security groups
• Security groups changed outside the approved deployment process
• Default security groups containing active rules
• Unrestricted outbound access from sensitive workloads

AWS Config can evaluate security group configurations, while Security Hub provides controls for unrestricted high-risk ports and other unsafe network configurations. AWS Firewall Manager can centrally apply, audit, and remediate security group policies across an AWS organization. It can also identify unused or redundant security groups.

VPC Flow Logs and Network Access Analyzer can provide additional visibility into actual traffic and unintended network paths.

Common Anti-Patterns

One security group for the entire application

This eliminates meaningful separation between web, application, database, and administration tiers.

Trusting the entire VPC

A rule allowing a database connection from the complete VPC CIDR treats every workload in the VPC as trusted.

Reusing production SGs in non-production

This creates unintended trust relationships and weakens environment isolation.

Hard-coding individual private IP addresses

This makes security rules fragile and difficult to maintain in an elastic environment.

Leaving the default outbound rule unchanged everywhere

New security groups commonly begin with an outbound rule permitting all traffic. Whether that is acceptable should be an explicit risk decision, not an unnoticed default. AWS allows this rule to be removed and replaced with specific outbound permissions.

Opening management ports temporarily

Temporary 0.0.0.0/0 SSH and RDP rules are frequently forgotten. Use Session Manager, VPN-based administration, or an automatically expiring access workflow.

Attaching too many security groups

Because rules are aggregated, attaching multiple SGs can create permissions that are difficult to understand. More security groups do not automatically mean more security.

A Practical Design Principle

Every security group rule should answer four questions:

1. Who is initiating the connection?
2. Which service is receiving it?
3. Which protocol and port are required?
4. Why is the connection necessary?

If a rule cannot answer those questions clearly, it is probably too broad.

The Tiered Security Group Pattern transforms security groups from collections of ports and IP addresses into an expression of application architecture:

• The load balancer may communicate with the web tier.
• The web tier may communicate with the application tier.
• The application tier may communicate with its database.
• Monitoring systems may reach defined telemetry endpoints.
• Administrators may enter only through an approved management path.
• Development systems may not communicate with production.
• One application may not inherit access intended for another.

That is the central idea: grant access according to workload identity, architectural tier, application ownership, and environment—not merely according to network location.

When properly implemented, tiered security groups reduce lateral movement, contain compromised workloads, simplify security reviews, and make the intended architecture visible directly in the network policy.

The post Security Groups Design Patterns in AWS appeared first on AWS Security Architect.

DNS Isolation on AWS

DNS isolation on AWS refers to designing your Amazon Web Services environment so that certain workloads or networks can only resolve DNS names you explicitly allow, while blocking or segregating access to all other DNS sources—internal or external.

It is often used for security-sensitive, regulated, or multi-tenant architectures where you want to strictly control what resources can discover each other via DNS.

What DNS Isolation Means

DNS isolation ensures that a workload or subnet does not automatically inherit DNS visibility from the broader VPC or the internet. Instead, you tightly control where it gets DNS answers from (e.g., Route 53 Resolver rules, inbound/outbound resolvers, private hosted zones).

• Isolates DNS Resolution Paths: Prevents workloads from resolving public DNS names or internal/private AWS names not intended for them.
• Controls Resource Discovery: Restricts which internal services can be discovered by name.
• Prevents Data Exfiltration via DNS: Cuts off malware from using DNS to exfiltrate data.

How to Implement DNS Isolation in AWS

1. Disable the Default VPC Resolver

At the subnet level, set enableDnsSupport = false or override DNS servers via DHCP option sets to force workloads to use only your DNS servers.

2. Use Custom DNS Servers or Route 53 Resolver Endpoints

Point instances/subnets to custom DNS appliances or Route 53 outbound resolver endpoints with controlled forwarding rules.

3. Use Route 53 Resolver Rules for Fine-Grained Control

Define conditional forwarding rules, e.g.:

• corp.local → internal DNS server
• serviceA.internal → specific resolver
• Block everything else

4. Private Hosted Zones (PHZs) for Segregation

Attach PHZs only to specific VPCs to achieve multi-tenant DNS isolation and environment separation (dev vs prod).

5. Use Security Groups or Route 53 Resolver DNS Firewall

Create DNS firewall rule groups to:

• Allow only approved domains
• Block malware/TLDs
• Prevent access to external DNS servers

Common Use Cases for DNS Isolation

• Zero-Trust Network Design: Only authorized services resolve each other.
• Regulated Workloads: Ensures workloads resolve only internal names (HIPAA, FedRAMP, PCI).
• Multi-Tenant SaaS Platforms: Each tenant/VPC uses separate PHZs and resolver rules.
• Highly-Sensitive Internal Apps: Prevents accidental communication.
• Preventing Data Exfiltration: Blocks DNS tunneling by design.

Example Architecture for Isolated DNS

VPC (DNS Support Disabled)
   |
   +-- DHCP Option Set: DNS = Custom DNS Servers
   |
   +-- Route 53 Outbound Resolver Endpoint
           |
           |-- RULE: *.corp.local → Internal Data Center DNS
           |-- RULE: *.aws.local → AmazonProvidedDNS (private endpoints only)
           |-- RULE: BLOCK everything else

Workloads in this VPC cannot resolve public DNS, cannot query VPC private DNS unless allowed, and cannot access external resolvers.

The post DNS Isolation on AWS appeared first on AWS Security Architect.

1. Only AWS Security Hub can directly inherit & enforce Org-level guardrails. Deep Native Integration With AWS Control APIs (Preventive + Detective Controls)

Security Hub isn’t just reading posture — it is tightly wired into:

• AWS Organizations / Control Tower

• AWS Config and Config Conformance Packs

• IAM Access Analyzer

• GuardDuty

• Macie

• Inspector

• CloudTrail

• Network Firewall

• RDS Enhanced Monitoring

• Route 53 Resolver DNS Firewall

Wiz can ingest some of this data after it is generated,
but cannot natively participate in enforcement or orchestration because only AWS can modify guardrails at the organization level.

Only AWS Security Hub can directly inherit & enforce Org-level guardrails.

2. Automatic, Native Remediation via SSM Automation Documents

Security Hub integrates natively with:

• AWS Systems Manager Automation

• Pre-built remediation playbooks (SSM documents)

  • e.g., “Enable S3 block-public-access”,

  • “Rotate IAM access keys”,

  • “Encrypt EBS volumes”,

  • “Enable CloudTrail globally”.

Wiz can create tickets, alerts, or send webhook actions —
but it cannot directly run AWS-managed remediation automation.

AWS provides out-of-the-box remediation actions Wiz cannot trigger or manage natively.

3. Organization-Wide Mandatory Controls (FSBP, CIS Benchmarks)

Security Hub offers AWS Foundational Security Best Practices — tuned specifically to AWS internals, such as:

• Ensuring CloudTrail multi-region logging

• Ensuring GuardDuty is enabled in all regions

• Ensuring EBS encryption-by-default

• Ensuring VPC Flow Logs coverage

• Ensuring S3 public access block (account-level)

Wiz can check configurations, but cannot enforce AWS-level mandatory controls such as:

• Forced CloudTrail global

• Forced GuardDuty onboarding

• Automatic region enrollment

• Policy inheritance via Organizations

AWS-native CSPM can enforce security at the root account / org level, Wiz cannot.

4. Guaranteed Data Freshness from AWS APIs (Zero Lag)

AWS-native CSPM tools pull data directly from AWS control-plane APIs with:

• zero throttling issues

• full permission coverage

• immediate state awareness

Wiz relies on:

• periodic scans

• configuration snapshots

• ingestion delays

Security Hub always has the canonical truth from AWS itself.

5. Fully Managed Multi-Account Aggregation Through AWS Organizations

Security Hub can:

• auto-enable itself on new AWS accounts

• apply controls org-wide via delegated admin

• manage cross-account aggregation without custom roles

• ensure region-by-region mandatory configuration

Wiz requires:

• manually setting up IAM roles

• cross-account connectors

• agentless scanning permissions

• manual policy propagation

AWS CSPM has zero maintenance overhead for new accounts and new regions.

Summary: When AWS CSPM Outperforms Wiz

Security Hub is stronger when you need:

Org-level governance
Guaranteed integration correctness
AWS-managed remediations
Compliance-heavy requirements
Zero external dependencies
Cost + security combined governance
Deep AWS internal telemetry

Wiz is stronger when you want:

Attack path analysis
Cloud-graph visualization
Multi-cloud posture
Unified risk context (identity + vuln + config)

The post AWS Security Hub versus Wiz on AWS appeared first on AWS Security Architect.

Shared VPC Host (Public & Private Subnets) + TGW + Security VPC (GWLB); Participant Accounts place ENIs in Shared Subnets

Overview

This architecture uses a Shared VPC model where a central Host Account owns and manages a VPC containing both
Public and Private subnets. Multiple Participant Accounts launch their workloads
(ENIs, EC2 instances, ECS tasks, etc.) directly into these subnets. All inter-VPC and north-south traffic is routed through a
Transit Gateway (TGW) and inspected by a centralized Security VPC hosting
Gateway Load Balancer (GWLB) firewalls.

Key Components

1. Shared VPC Host Account

• Owns the Shared VPC — including subnets, route tables, and TGW attachments.
• Contains:
  • Public Subnets (connected to an Internet Gateway):
    • Host Internet-facing components such as ALBs, NAT Gateways, or public EC2 instances.
    • Default route 0.0.0.0/0 → IGW.
  • Private Subnets (non-Internet-facing):
    • Host backend workloads or participant ENIs.
    • Routes for internal CIDRs (e.g., 10.0.0.0/8) point to the TGW attachment.
• Transit Gateway Attachment:
  • Connects the Shared VPC to the TGW for both east-west and north-south routing.
  • TGW route table determines if traffic is inspected or forwarded to other VPCs.

2. Security Account and Security VPC

• A dedicated account owned by the security team.
• Contains the Gateway Load Balancer (GWLB) and firewall appliances
  (e.g., Palo Alto, FortiGate, Check Point, or Suricata).
• Security VPC details:
  • Subnets per AZ connected to GWLB target groups.
  • TGW attachment with Appliance Mode enabled to maintain flow symmetry.
• GWLB endpoints are used by the Shared VPC’s private route tables to forward traffic for inspection.

3. Transit Gateway (TGW)

• Acts as the central routing fabric connecting:
  • The Shared VPC (Host Account)
  • The Security VPC (Security Account)
  • Any additional application or support VPCs in other accounts
• TGW Route Tables configured for traffic steering:
  • Routes between participant workloads go through the Security VPC for inspection.
  • North-south (Internet-bound) traffic also passes through the Security VPC before reaching the IGW.
  • Blackhole routes prevent direct bypass of inspection.

4. Participant Accounts

• Do not own a VPC; workloads are deployed into exported subnets of the Shared VPC.
• Each participant’s ENIs appear within the Shared VPC’s subnets.
• Participants rely on the Host Account for:
  • Subnet routing configuration
  • Security group and NACL enforcement
  • TGW connectivity and inspection routing

Traffic Flow Scenarios

North–South (Internet Ingress/Egress)

1. Internet traffic enters via the IGW in the Shared VPC’s Public Subnets.
2. Traffic passes through ALB/firewall endpoints and then through the GWLB in the Security VPC for inspection.
3. Allowed traffic is routed via TGW to workloads in private subnets (participant ENIs).
4. Outbound follows the reverse path — Private → TGW → GWLB → IGW.

East–West (Inter-VPC / Internal Traffic)

1. Workload in Shared VPC initiates traffic to another internal VPC.
2. Traffic routes Shared VPC → TGW → Security VPC (inspection) → TGW → destination VPC.
3. All inter-VPC traffic is centrally monitored and inspected.

Operational Benefits

• Centralized governance: Host Account owns routing and TGW attachments ensuring policy consistency.
• Least privilege & separation of duties:
  • Security Account manages firewalls and policies.
  • Host Account manages network infrastructure.
  • Participant Accounts manage only their workloads.
• Scalable & multi-account compliant: Works under AWS Organizations + RAM.
• Reduced operational duplication: One shared IGW/NAT/firewall layer for all accounts.
• Inspection assurance: All traffic (north-south and east-west) passes through GWLB via TGW routing.

Design Best Practices

• Enable Appliance Mode on the Security VPC TGW attachment for stateful symmetry.
• Use dedicated TGW route tables for inspected vs. trusted paths.
• Export both Public and Private subnets to participant accounts for flexible placement.
• Use AWS Firewall Manager or SCPs to enforce inspection and prevent direct IGW use by participants.
• Enable VPC Flow Logs and TGW Flow Logs for audit visibility.

The post Replace DMZ with Shared VPC in AWS appeared first on AWS Security Architect.

AWS Shared VPC Architecture – Segmentation by Ingress Type

In an AWS Shared VPC architecture, the host account owns and manages the VPC, subnets, and routing.
It shares specific subnets with participant accounts through AWS Resource Access Manager (RAM).
This allows each participant account to deploy workloads into shared subnets — without owning or modifying the core VPC networking.

1. Segmentation Models

A. Environment-Based

Each participant account represents an environment (e.g., Dev, Test, Prod).
Subnets within the shared VPC are labeled and shared accordingly:

• Dev Account: dev-public-*, dev-private-* subnets
• Test Account: test-public-*, test-private-* subnets
• Prod Account: prod-public-*, prod-private-*, prod-isolated-* subnets

This keeps environments isolated while maintaining consistent security and routing through a single centrally managed VPC.

B. Workload-Based (by Ingress Profile)

Alternatively, participant accounts may represent workload ingress types:

• Edge / Public Ingress Account: Internet-facing workloads using ALB/NLB, CloudFront origins.
• Private Services Account: Application workloads reachable only through internal ALBs, VPC Lattice, or PrivateLink.
• Data or Regulated Account: Isolated workloads (RDS, MSK, S3 endpoints) accessible only through endpoints or service meshes.

2. Ingress Flow Diagram

          +----------------------+
          |      Internet        |
          +----------+-----------+
                     |
                     v
         +-----------+-----------+
         |  Edge (Public Ingress)|
         |  Account – ALB/NLB    |
         +-----------+-----------+
                     |
                     v
         +-----------+-----------+
         |  Private App Services |
         |  Account – ECS/EKS    |
         +-----------+-----------+
                     |
                     v
         +-----------+-----------+
         |   Data/Isolated Tier  |
         |   Account – RDS, EFS  |
         +-----------------------+

Each tier runs in its own participant account using subnets shared from the host VPC.
Traffic flows from public ALBs → internal services → data layers, all within controlled ingress boundaries.

3. Governance and Control Layers

• Subnet Sharing: Host account shares only the appropriate subnets (public/private/isolated) with each participant account.
• Routing: Host account manages route tables (e.g., IGW routes only for public subnets, NAT or GWLB for private).
• Security Groups: Participant accounts define SGs for their resources; AWS Firewall Manager can enforce org-wide SG policies.
• Network Firewall: Centralized inspection via AWS Network Firewall or GWLB in the host account.
• SCPs & Config: Prevent public resources in private-only accounts; ensure compliance via Config/FMS rules.

4. Example Mapping Table

5. Key Enforcement Mechanisms

• Use AWS Firewall Manager to enforce org-wide SG and NFW policies.
• Apply Service Control Policies (SCPs) to block creation of public ALBs or IGWs in private-only accounts.
• Implement Config Rules for continuous compliance (public IP detection, restricted-ssh).
• Tag subnets and accounts with Environment and IngressType for automation and visibility.

The post DMZs versus Shared VPCs appeared first on AWS Security Architect.

Shared VPC Use Cases & Shared VPC vs Transit Gateway

This document provides additional Shared VPC use cases for AWS Network Firewall and explains how Shared VPCs differ technically and operationally from AWS Transit Gateways (TGWs).

Network Firewall Policies — Shared VPC Support

When AWS Network Firewall is deployed through Firewall Manager in a Shared VPC environment, it provides consistent network-layer inspection across workloads owned by multiple AWS accounts but hosted in a single VPC owned by the networking (host) account.

How Shared VPCs Differ from Transit Gateways

While both Shared VPCs and Transit Gateways enable multi-account connectivity, they operate at different scopes and layers of the network.

Tip: Pair Firewall Manager policies (Network Firewall, Security Group, WAF, DNS Firewall) with centralized logging to S3 or CloudWatch and integrate with AWS Security Hub or GuardDuty for organization-wide visibility and automated compliance.

The post Firewall Manager and Shared VPCs in AWS appeared first on AWS Security Architect.

aws ec2 authorize-security-group-ingress \
  --group-id sg- \
  --source-group sg-

The post AWS Shared VPC vs. Transit Gateways appeared first on AWS Security Architect.

Transit Gateway vs API Gateway — and a Reference Architecture with NGINX

Key Differences

Architecture Diagram

External APIs: Internet → WAF → API Gateway → (private integration via VPC Link) → ALB/NLB → NGINX → services.
Internal APIs: Internal clients → Corp Edge → Transit Gateway → (Internal VPC) → NGINX (internal) → services.

Security Policies

1) API Gateway (External)

• Edge protections: WAF (OWASP, bot control, geo/IP blocks).
• Auth: JWT (Cognito/OIDC), IAM SigV4, or Lambda authorizers.
• Resource policies: Restrict by VPC Endpoint/CloudFront Distribution.
• Threat controls: Throttling, quotas, usage plans, API keys.
• Data protection: TLS 1.2+, request/response validation, payload limits, sensitive header redaction.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "execute-api:Invoke",
    "Resource": "arn:aws:execute-api:us-east-1:123456789012:abcde12345/*/*/*",
    "Condition": {
      "StringNotEquals": {
        "aws:SourceVpce": "vpce-0abc123def4567890",
        "aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC456DEF"
      }
    }
  }]
}

2) NGINX (Reverse Proxy)

• Transport: Enforce TLS; mTLS for service-to-service.
• Identity: Validate JWT (OIDC) or client certs.
• Access control: Path/host routing, IP allow/deny for admin paths, tenant scoping.
• Rate limiting: Per IP/token; connection/request limits.
• Hygiene: Header normalization, body size caps, method allowlists.
• Observability: Structured logs, correlation IDs.

# mTLS
ssl_verify_client on;
ssl_client_certificate /etc/nginx/ca_bundle.pem;

# JWT validation (auth_jwt or OpenResty)
auth_jwt "closed api";
auth_jwt_key_file /etc/nginx/jwks.pem;

# Rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
server {
  listen 443 ssl http2;
  server_name api.example.com;

  limit_req zone=api burst=40 nodelay;
  client_max_body_size 5m;

  location /service-a/ {
    proxy_set_header Authorization $http_authorization;
    proxy_pass http://svc-a:8080;
  }
}

3) Transit Gateway (L3)

• Segmentation: Separate TGW route tables per environment/domain.
• Least-route: Propagate/associate only where needed; deny east‑west by default.
• Inspection: Force inter‑VPC traffic via an inspection VPC/NVA firewall.
• Adjacencies: Complement with Security Groups/NACLs; use VPC endpoints for private API consumption.
• Observability: TGW + VPC Flow Logs for anomalous inter‑VPC flows.

Layered Security Summary

1. Edge: WAF + API Gateway throttling/authorizers.
2. VPC: NGINX enforces mTLS/JWT, routing, rate limits.
3. Network Hub: Transit Gateway confines routes, funnels inspection.
4. Workloads: SG/NACL and app‑level authorization/validation.

The post API Gateway versus Transit Gateway appeared first on AWS Security Architect.

Potential Benefits (Why People Do This)

• Cloudflare: DDoS protection, WAF, CDN, TLS offload, bot protection — global edge network.
• Palo Alto VM-Series: Layer 4-7 inspection, IPS/IDS, app-level policies, advanced logging, east-west traffic inspection within VPCs, integration with enterprise tooling.

Potential Downsides

1⃣ Latency and Performance

• Cloudflare terminates TLS at edge, then re-encrypts to origin (your AWS app).
• Introducing Palo Alto in-line can add latency and path complexity.
• Improper design can cause hairpinning (traffic looping between VPCs/interfaces).

2⃣ Cost Overhead

• Palo Alto VM-Series is costly — licensing, compute, bandwidth.
• Running both Cloudflare and Palo Alto may duplicate features and increase total cost.

3⃣ Operational Complexity

• Two security stacks mean two dashboards, two logging systems, two policy engines.
• Increased burden on security and operations teams.
• Clear ownership boundaries required (who manages Cloudflare vs Palo Alto?).

4⃣ Debugging Complexity

• Failures may require debugging across multiple layers:
  • Cloudflare edge rules
  • Cloudflare WAF
  • Palo Alto firewall policies
  • AWS NACLs, Security Groups, ALB settings

5⃣ TLS / Encryption Conflicts

• Careful design needed for TLS termination:
  • Cloudflare terminates TLS, then Palo Alto inspects plaintext? (often not desirable)
  • Cloudflare passes through TLS, Palo Alto inspects encrypted traffic (requires decryption licenses and proper configuration).
• Improper handling can break mTLS or other sensitive integrations.

6⃣ Overlap in Features

• Cloudflare Advanced WAF is powerful.
• Palo Alto WAF/IPS may introduce redundant protection.
• Requires careful coordination to avoid double blocking and false positives.

7⃣ Routing & Asymmetry

• Improper architecture can cause asymmetric routing:
  • Inbound path through Cloudflare & Palo Alto.
  • Outbound path bypasses Palo Alto.
• This can break stateful firewalling and cause unpredictable behavior.

Summary — When It Makes Sense vs Not

Recommendation: Simple Public Web Apps

For simple public web applications — marketing sites, basic informational apps, low-sensitivity data — Cloudflare alone typically provides sufficient protection:

• Global DDoS protection
• Advanced WAF and bot management
• Global CDN and TLS termination
• Minimal operational overhead

Adding Palo Alto in such scenarios may introduce unnecessary cost and complexity.

Recommendation: Complex High-Traffic eCommerce Web Apps

For high-traffic eCommerce applications with sensitive data (PII, PCI), compliance needs, and fraud prevention requirements:

• Use Cloudflare for edge security (DDoS, TLS, global CDN, bot mitigation).
• Use Palo Alto VM-Series for:
  • Deep application inspection
  • Advanced IPS/IDS
  • East-West traffic security between microservices
  • Detailed logging and forensic analysis

For best performance, ensure traffic paths and TLS flows are carefully designed to avoid latency spikes and asymmetric routing.

Final Advice

• Carefully design traffic path and TLS termination points.
• Define clear responsibility boundaries between Cloudflare and Palo Alto management.
• Monitor latency and debug complexity continuously.
• Justify the cost of dual stack vs using either one effectively.

The post Using Cloudflare and Palo Alto Together on AWS: Pros and Cons appeared first on AWS Security Architect.

Yes, a DMZ (Demilitarized Zone) in the cloud can include both a public subnet and a private subnet. This configuration helps to separate internet-facing resources from internal application layers that require added security.

DMZ Subnet Responsibilities

• Public Subnet: Load balancers, web servers, bastion hosts. Directly accessible from the internet.
• Private Subnet: Backend services like APIs, internal app servers, or firewalls. No direct internet access.

Traffic Flow

1. User sends request to public IP on the DMZ Public Subnet (e.g., via a Load Balancer).
2. Load Balancer forwards request to app servers in the DMZ Private Subnet.
3. App servers in the DMZ Private Subnet may access internal services in the Internal VPC.

Firewall Rules

Security groups – defined at VPC level – enforced at Instance Level

1. DMZ Public Subnet → DMZ Private Subnet

2. DMZ Private Subnet → Internal VPC

Optional: NACL Rules

DMZ Private Subnet NACL

Internal VPC Subnet NACL

The post AWS DMZ Public and Private Subnets, Traffic to Internal VPC appeared first on AWS Security Architect.