# Centralized inbound inspection
Internet-facing applications, by their nature, have a larger attack surface and are exposed to categories of threats most other types of applications don’t have to face. Having the necessary protection from attacks on these types of applications, and minimizing the impact surface area, are a core part of any security strategy.
As you deploy applications in your Landing Zone, many apps will be accessed by the users over the public internet (for example, through a Content Delivery Network (CDN), or through a public facing web-application) via a public facing load balancer, API gateway or directly through an internet gateway. You can secure your workloads and applications in this case by using AWS Web Application Firewall (AWS WAF) for Inbound Application Inspection, or alternatively IDS/IPS Inbound Inspection using Gateway Load Balancer or AWS Network Firewall.
As you continue to deploy applications in your Landing Zone, you might have a requirement to inspect inbound internet traffic. You can achieve this in multiple ways, using either distributed, centralized, or combined inspection architectures using Gateway Load Balancer running your third-party firewall appliances or AWS Network Firewall with advance DPI and IDS/IPS capabilities through the use of open source Suricata rules. This section covers both Gateway Load Balancer and AWS Network Firewall in a centralized deployment, using AWS Transit Gateway acting as a central hub for routing traffic.
## AWS WAF and AWS Firewall Manager for inspecting inbound traffic from the internet
AWS WAF is a web application firewall that helps protect your web applications or APIs against common web exploits and bots that may affect availability, compromise security, or consume excessive resources. AWS WAF gives you control over how traffic reaches your applications by enabling you to create security rules that control bot traffic and block common attack patterns, such as SQL injection or cross-site scripting (XSS). You can also customize rules that filter out specific traffic patterns.
You can deploy AWS WAF on Amazon CloudFront as part of your CDN solution, the Application Load Balancer that fronts your web servers, Amazon API Gateway for your REST APIs, or AWS AppSync for your GraphQL APIs.
Once you deploy AWS WAF, you can then create your own traffic filter rules using the visual rule builder, code in JSON, managed rules maintained by AWS, or you can subscribe to third-party rules from the AWS Marketplace. These rules can filter out unwanted traffic by evaluating the traffic against the specified patterns. You can further use Amazon CloudWatch for monitoring incoming traffic metrics and logging.
For centralized management across all your accounts and applications in AWS Organizations, you can use AWS Firewall Manager. AWS Firewall Manager is a security management service which allows you to centrally configure and manage firewall rules. As your new applications are created, AWS Firewall Manager makes it easy to bring new applications and resources into compliance by enforcing a common set of security rules.
Using AWS Firewall Manager, you can easily roll out AWS WAF rules for your Application Load Balancers, API Gateway instances, and Amazon CloudFront distributions. AWS Firewall Manager integrates with AWS Managed Rules for AWS WAF, which gives you an easy way to deploy pre-configured, curated AWS WAF rules on your applications. For more information on centrally managing AWS WAF with AWS Firewall Manager, refer to [Centrally manage AWS WAF (API v2) and AWS Managed Rules at scale with AWS Firewall Manager](https://aws.amazon.com/blogs/security/centrally-manage-aws-waf-api-v2-and-aws-managed-rules-at-scale-with-firewall-manager/).
![\[A diagram depicting centralized inbound traffic inspection using AWS WAF\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/inbound-traffic-inspection-with-waf.png)
In the preceding architecture, applications are running on Amazon EC2 instances in multiple availability zones in the private subnets. There is a public-facing Application Load Balancer (ALB) deployed in front of the Amazon EC2 instances, load balancing the requests between different targets. The AWS WAF is associated with the ALB.
### Advantages
+ With [AWS WAF Bot Control](https://aws.amazon.com/waf/features/bot-control/), you get visibility and control over common and pervasive bot traffic to your applications.
+ With [Managed Rules for AWS WAF](https://aws.amazon.com/marketplace/solutions/security/waf-managed-rules), you can quickly get started and protect your web application or APIs against common threats. You can select from many rule types, such as those that address issues such as the Open Web Application Security Project (OWASP) Top 10 security risks, threats specific to Content Management Systems (CMS) like WordPress or Joomla, or even emerging Common Vulnerabilities and Exposures (CVE). Managed rules are automatically updated as new issues emerge, so that you can spend more time building applications.
+ AWS WAF is a managed service and no appliance is needed for inspection in this architecture. In addition, it provides near real-time logs through [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/). AWS WAF gives near real-time visibility into your web traffic, which you can use to create new rules or alerts in Amazon CloudWatch.
### Key considerations
+ This architecture is best suited for HTTP header inspection and distributed inspections, because AWS WAF is integrated on a per-ALB, CloudFront distribution and API Gateway. AWS WAF does not log the request body.
+ Traffic going to a second set of ALB (if present) may not get inspected by the same AWS WAF instance; because a new request would be made to the second set of ALB.
# Centralized inbound inspection with third-party appliances
In this architectural design pattern, you deploy third-party firewall appliances on Amazon EC2 across multiple availability zones behind an Elastic Load Balancer (ELB) such as an Application/Network Load Balancer in a separate Inspection VPC.
The Inspection VPC along with other Spoke VPCs are connected together through a Transit Gateway as VPC attachments. The applications in Spoke VPCs are frontend by an internal ELB which can be either ALB or NLB depending on the application type. The clients over the internet connect to the DNS of the external ELB in the inspection VPC which routes the traffic to one of the Firewall appliances. The Firewall inspects the traffic and then routes the traffic to the Spoke VPC through Transit Gateway using the DNS of the internal ELB as shown in the following figure. For more information regarding inbound security inspection with third-party appliances, refer to the [How to integrate third-party firewall appliances into an AWS environment](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-integrate-third-party-firewall-appliances-into-an-aws-environment/) blog post.
![\[A diagram depicting centralized ingress traffic inspection using third-party appliances and ELB\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-third-party.png)
## Advantages
+ This architecture can support any application type for inspection and advanced inspection capabilities offered through third-party firewall appliances.
+ This pattern supports DNS based routing from firewall appliances to spoke VPCs, which allows the applications in Spoke VPCs to scale independently behind an ELB.
+ You can use Auto Scaling with the ELB to scale the firewall appliances in the Inspection VPC.
## Key considerations
+ You need to deploy multiple firewall appliances across Availability Zones for high availability.
+ The firewall needs to be configured with and perform Source NAT in order to maintain flow symmetry, which means the client IP address won’t be visible to the application.
+ Consider deploying Transit Gateway and Inspection VPC in the Network Services account.
+ Additional third-party vendor firewall licensing/support cost. Amazon EC2 charges are dependent on instance type.
# Inspecting inbound traffic from the internet using firewall appliances with Gateway Load Balancer
Customers use third-party next-generation firewalls (NGFW) and intrusion prevention systems (IPS) as part of their defense in depth strategy. Traditionally these often are dedicated hardware or software/virtual appliances. You can use Gateway Load Balancer to scale these virtual appliances horizontally to inspect traffic from and to your VPC, as shown in the following figure.
![\[A diagram depicting centralized ingress traffic inspection using firewall appliances with Gateway Load Balancer\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-fa.png)
In the preceding architecture, Gateway Load Balancer endpoints are deployed into each Availability Zone in a separate edge VPC. The next-generation firewalls, intrusion prevention systems etc. are deployed behind the Gateway Load Balancer in the centralized appliance VPC. This appliance VPC can be in the same AWS account as the spoke VPCs or different AWS account. Virtual appliances can be configured to use Auto Scaling groups and are registered automatically with the Gateway Load Balancer, allowing auto scaling of the security layer.
These virtual appliances can be managed by accessing their management interfaces through an Internet Gateway (IGW) or using a bastion host setup in the appliance VPC.
Using the VPC ingress routing feature, the edge route table is updated to route inbound traffic from internet to firewall appliances behind Gateway Load Balancer. Inspected traffic is routed via Gateway Load Balancer endpoints to target VPC instance. Refer to the [Introducing AWS Gateway Load Balancer: Supported architecture patterns](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/) blog post for details on various ways to use Gateway Load Balancer.
# Using the AWS Network Firewall for centralized ingress
In this architecture, ingress traffic is inspected by AWS Network Firewall before reaching the rest of the VPCs. In this setup, traffic is split among all firewall endpoints deployed in the Edge VPC. You deploy a public subnet between the firewall endpoint and the Transit Gateway subnet. You can use an ALB or NLB, which contain IP targets in your spoke VPCs while handling Auto Scaling for targets behind them.
![\[A diagram depicting ingress traffic inspection using AWS Network Firewall\]](http://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-using-aws-nf.png)
To simplify deployment and management of AWS Network Firewall in this model, AWS Firewall Manager can be used. Firewall Manager allows you to centrally administer your different firewalls by automatically applying protection you create in the centralized location to multiple accounts. Firewall Manager supports both distributed and centralized deployment models for Network Firewall. The blog post [How to deploy AWS Network Firewall by using AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/) provides more details on the model.
## Deep Packet Inspection (DPI) with AWS Network Firewall
Network Firewall can perform deep packet inspection (DPI) on ingress traffic. Using a Transport Layer Security (TLS) certificate stored in AWS Certificate Manager (ACM), Network Firewall can decrypt packets, perform DPI, and re-encrypt packets. There are a few considerations for setting up DPI with Network Firewall. First, a trusted TLS certificate must be stored in ACM. Second, Network Firewall rules must be configured to correctly send packets for decryption and re-encryption. Refer to the blog post [TLS inspection configuration for encrypted traffic and AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-traffic-and-aws-network-firewall/) for more details.
## Key considerations for AWS Network Firewall in a centralized ingress architecture
+ Elastic Load Balancing in Edge VPC can only have IP addresses as target types, not a hostname. In the preceding figure, the targets are the private IPs of the Network Load Balancer in spoke VPCs. Using IP targets behind the ELB in the edge VPC results in the loss of Auto Scaling.
+ Consider using AWS Firewall Manager as a single pane of glass for your firewall endpoints.
+ This deployment model uses traffic inspection right as it enters the edge VPC, so it has the potential to reduce the overall cost of your inspection architecture.