suKTech24

Three-Tier Web Application Security Part 1 : Attack Surface

Weekly #10-2025 – By suktech24, Sun 6 July 2025, Estimated reading time : 26 mins

This week, I decided to focus on exploring web application architecture – especially how to dissect an architecture from the attacker’s perspectives. When thinking about how to approach this, a few resources come to my mind. They are :

  1. AWS
    • AWS Well-Architected – If you check AWS Well-Architected Lenses, there are many whitepapers which also contain reference architectures. The industries vary and so are technologies.
    • AWS Blog – Another place is AWS Blogs. Customers who have used AWS services shared their experiences and some include excellent architecture diagrams.
  2. Azure
  3. Google

I chose the AWS Three-Tier Web Architecture Workshop as my starting point. The workshop walks through details steps for building three tier web app.

In part-2, I will revisit the same architecture from a defender’s perspective – exploring how security controls, vulnerability, remediation and monitoring can mitigate the potential attacks and risks.

In this blog post, the followings will be discussed :

  1. Overview of Architecture
  2. Attack Surface – Application Load Balancer
    • 2.1. Distributed Denial of Service (DDoS)
    • 2.2. ALB Misconfiguration
  3. Attack Surface – Web Tier
    • 3.1 Cross Site Request Forgery also known as XSRF or session riding
    • 3.2. Path traversal ( Directory traversal attack)
    • 3.3. HTTP Host header attack
    • 3.4. File inclusion attack
    • 3.5. Cross Site Scripting ( XSS)
    • 3.6. Unpatched software vulnerability
    • 3.7. Server Side Request Forgery (SSRF)
  4. Attack Surface – App Tier
    • 4.1. SQL Injection
    • 4.2. API Abuse exploiting missing/weak Authentication, Insecure JWT Token validation (forged token), Missing MFA, and unauthorized API requests
    • 4.3. Dependency Vulnerabilities – Outdated or vulnerable npm packages
    • 4.4. Internal ALB misconfiguration – Same as ALB misconfiguration
    • 4.5. API key exposure
  5. Attack Surface – Database Tier
    • SQLi – See SQLi under Application Tier
    • Unauthorized Access via stolen IAM credentials or overly permissive SG or misconfigured network rules
    • Data exfiltration
    • Unauthorized access to unencrypted DB snapshots or snapshots stored in S3
    • Misconfiguration
    • Overprivileged DB Users
  6. Attack Surface Virtual Private Cloud (VPC), Network Controls and Infrastructure
    • VPC misconfiguration – Public subnets hosting sensitive resources
    • Exploiting open ports
    • Misconfigured SG and NACL
  7. AWS Services used

1. Overview of AWS Three Tier Web Architecture

“In this architecture, a public-facing Application Load Balancer forwards client traffic to web tier EC2 instances. The web tier is running Nginx webservers that are configured to serve a React.js website and redirects our API calls to the application tier’s internal facing load balancer.

The internal facing load balancer then forwards that traffic to the application tier, which is written in Node.js. The application tier manipulates data in an Aurora MySQL multi-AZ database and returns it to the web tier. Load balancing, health checks and autoscaling groups are created at each layer to maintain the availability of this architecture.”

AWS Three Tier Web Architecture, referenced from https://catalog.us-east-1.prod.workshops.aws/workshops/85cd2bb2-7f79-4e96-bdee-8078e469752a/en-US/introduction

If you’re interested in implementing or learning about a similar three-tier architecture using Azure resources, consider exploring the following guides and examples

Azure Three Tier Web Architecture, referenced from https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier

2. Attack Surface – Application Load Balancer

In above AWS Three Tier Web Architecture diagram, every AWS service used along with configuration and communication paths, contributes to the overall attack service.

  • Attack Surface
    • ALB listener rules, Security Groups
    • AWS WAF integration
    • Potential Threats include below.
  • Public facing Application Load Balancer (ALB) – In this architecture, the public-facing Application Load Balancer (ALB)—listening on ports 80 (HTTP) and 443 (HTTPS)—and its associated DNS serve as the primary internet entry point. Potential attacks are listed below.
  • 2.1. Distributed Denial of Service (DDoS) (T1498 – Network Denial of Service)- A Denial of Service (DoS) attack is a malicious attempt to affect the availability of a targeted system, such as a website or application, to legitimate end users. Typically, attackers generate large volumes of packets or requests ultimately overwhelming the target system. In case of a Distributed Denial of Service (DDoS) attack, and the attacker uses multiple compromised or controlled sources to generate the attack.
    • Sourced from, https://www.devo.com/glossary/ddos-attacks/
    • Application Layer Attacks (Attacks at OSI Layer 6 and 7)
      • While these attacks are less common, they also tend to be more sophisticated. These attacks are typically small in volume compared to the Infrastructure layer attacks but tend to focus on particular expensive parts of the application thereby making it unavailable for real users. For instance, a flood of HTTP requests to a login page, or an expensive search API.
    • Infrastructure Layer Attacks (Attacks at OSI Layer 3 and 4)
      • These are also the most common type of DDoS attack and include vectors like synchronized (SYN) floods and other reflection attacks like User Datagram Packet (UDP) floods. These attacks are usually large in volume and aim to overload the capacity of the network or the application servers. But fortunately, these are also the type of attacks that have clear signatures and are easier to detect.
    • DDoS Attacks
  • 2.2. ALB misconfiguration
    • Miggo Research identified a critical configuration-based vulnerability, dubbed ALBeast, affecting applications that utilize AWS Application Load Balancer (ALB) for authentication. This flaw can facilitate authentication and authorization bypass in applications exposed to the internet that relies on ALB’s authentication mechanisms.
    • Misconfiguration: Applications misconfigured as ALB target groups and accessible directly, bypassing the ALB, can be exploited. Attackers can use a shared public key server for all AWS accounts in the region (e.g., https://public-keys.auth.elb.region.amazonaws.com/key-id) to set an arbitrary key ID (kid). This allows the attacker to supply a public key that the application uses to validate the forged ALB JWT token. Following Miggo Research‘s report, AWS updated their documentation to refine best practices for configuring Security Group restrictions.
    • This AuthN/AuthZ bypass can compromise affected applications’ confidentiality, integrity, and availability. Threat actors can exploit impacted applications by leveraging this configuration-based vulnerability, leading to unauthorized access to business resources, data breaches, and data exfiltration.

3. Attack Surface – Web Tier

Web Tier ( EC2, Nginx, React) – In web tier, there are EC2 instances in the public subnets and they run the Nginx front-end.

  • Attack Surface
    • Unpatched OS or nginx
    • Read.js – JavaScript bundles and dependencies
    • EC2 instances e.g. Amazon Linux, SG, SSH access, instance metadata
    • Potential attacks are listed below.
  • 3.1 Cross Site Request Forgery also known as XSRF or session riding, is an attack approach where threat actors trick trusted users of an application into performing unintended actions. 
  • CSRF attacks exploit the trust that web applications have in authenticated users. This trust makes the apps automatically accept HTTP verbs (POST, GET, PUT, and DELETE) sent from the users’ browsers, and CSRF attacks then go unchecked because apps are unable to distinguish requests generated by legitimate users from requests originating from hackers who are forcing legitimate users to perform unwanted actions.
  • Sourced from, https://www.brightsec.com/blog/cross-site-request-forgery-csrf/
  • Here’s how CSRF works step-by-step:
    • Step 1: The CSRF attacker builds an exploit script or URL.
    • Step 2: The attacker tricks users into clicking the link or executing the script via social engineering.
    • Step 3: A user who is already logged in sends the malicious request, the effect of which is only detected after the attack is successful.
  • AWS Detector Library
    • Cross-site request forgery (CSRF) vulnerabilities allow attackers to perform unauthorized actions by exploiting weaknesses in request validation and loose restrictions. Failure to properly validate inputs like tokens or origins and enabling unsafe methods without route restrictions makes it possible for attackers to construct requests that users unknowingly execute while authenticated. Fixing these issues requires adding comprehensive validation of tokens, origins, and other inputs as well as tighter restrictions on routes, HTTP methods, and CORS policies. Implementing robust validation and restrictions makes it difficult for attackers to trick users into taking unintended actions through CSRF attacks.
  • Example vulnerability
    • CVE-2023-5455 – A Cross-site request forgery vulnerability exists in ipa/session/login_password in all supported versions of IPA. This flaw allows an attacker to trick the user into submitting a request that could perform actions as the user, resulting in a loss of confidentiality and system integrity. During community penetration testing it was found that for certain HTTP end-points FreeIPA does not ensure CSRF protection. Due to implementation details one cannot use this flaw for reflection of a cookie representing already logged-in user. An attacker would always have to go through a new authentication attempt.
    • CVE-2023-41942 – A cross-site request forgery (CSRF) vulnerability has been identified in Jenkins AWS CodeCommit Trigger Plugin versions 3.0.12 and earlier. The vulnerability stems from an HTTP endpoint in the AWS CodeCommit Trigger Plugin that does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. When successfully exploited, this vulnerability allows attackers to clear the SQS queue. The vulnerability is particularly concerning as it affects all versions of the AWS CodeCommit Trigger Plugin up to and including version 3.0.12.
  • 3.2. Path traversal ( Directory traversal attack)
    • Sourced from, https://www.wallarm.com/what/path-traversal-attack
    • This attack aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. It should be noted that access to files is limited by system operational access control (such as in the case of locked or in-use files on the Microsoft Windows operating system).
    • This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing”, “catalog cross” and “backtracking”.
    • Amazon Detector Library Python
      • Constructing path names with unsanitized user input can lead to path traversal attacks (for example, ../../..) that allow an attacker access to file system resources.
    • Example
    • Example vulnerability
      • CVE-2025-22873 – A directory traversal vulnerability was discovered in the Go programming language’s os package in versions prior to 1.24.3. The vulnerability allows improper access to the parent directory of an os.Root by opening a filename ending in “../”. When exploited, this vulnerability permits an attacker to open the parent directory of the Root, though it does not allow access to ancestors of the parent or files contained within the parent directory. This issue has been fixed in Go 1.24.3, where Root now correctly returns an error when such access is attempted.
      • ALAS-2025-2815
  • 3.3. HTTP Host header attack
    • At the heart of every HTTP request is the Host header, a critical component that designates the target server’s hostname. Host Header attacks leverage this essential header to manipulate request routing, deceive servers, and breach web applications. These attacks include various techniques, such as cache poisoning, domain hijacking, and proxy bypass, each posing unique threats to web security.
      • Cache Poisoning: This attack vector exploits vulnerabilities in caching mechanisms by manipulating the Host header to poison cache entries. Subsequent requests served from the tainted cache may contain malicious content, leading to potential data breaches or the dissemination of harmful payloads to unsuspecting users.
      • Proxy Bypass: Misconfigured proxies or load balancers can inadvertently expose servers to Host Header attacks. Attackers exploit these weaknesses to bypass security controls, directly access internal resources, or inject malicious payloads into backend systems.
    • Examples
  • 3.4. File inclusion attack
    • File inclusion vulnerabilities can be primarily found on web applications that utilize a scripting runtime. These vulnerabilities give attackers access to sensitive files on their web servers or allow them to utilize include functionality to carry out malicious files on their servers. With access to unauthorized files, attackers can attain sensitive information or further compromise the victim’s networks.
    • Most file inclusion vulnerabilities are, like a lot of file-related vulnerabilities, due to weak validation processes that give access to user input without legitimate validation.
    • There are two file inclusion vulnerability types : Local file inclusion (LFI) and remote file inclusion (RFI).
    • The main difference between the two has to do with where a compromised file is originally located.
      • LFI vulnerabilities are exploited through a file stored on the target server. When website or web application inputs aren’t properly sanitized, local files on a server become vulnerable to attacks. User inputs that contain paths to files and are incorrectly validated, attackers can gain access to those files and retrieve sensitive files in other directories.
      • RFIs use a file from a third-party source. Though similar, RFI vulnerabilities will utilize an external source, as opposed to accessing files within the local server, to execute an attack. Attackers will make use of the “dynamic file include” command to insert harmful external files or scripts. Without proper sanitization of files, attackers can take advantage of web applications to insert external files with harmful scripts.
    • AWS WAF Rule – Linux operating system managed rule group. The Linux operating system rule group contains rules that block request patterns associated with the exploitation of vulnerabilities specific to Linux, including Linux-specific Local File Inclusion (LFI) attacks. 
    • AWS WAF Managed Rules – Baseline rule groups
      • Rule name – GenericRFI_QUERYARGUMENTS
        • Inspects the values of all query parameters for attempts to exploit RFI (Remote File Inclusion) in web applications by embedding URLs that contain IPv4 addresses. Examples include patterns like http://, https://, ftp://, ftps://, and file://, with an IPv4 host header in the exploit attempt.
        • Rule action: Block
        • Label: awswaf:managed:aws:core-rule-set:GenericRFI_QueryArguments
  • 3.5. Cross Site Scripting ( XSS)
    • Cross-site scripting (also known as XSS) are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. 
    • An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site.
    • There are three main types of XSS attacks. These are:
      • Reflected XSS, where the malicious script comes from the current HTTP request.
      • Stored XSS, where the malicious script comes from the website’s database.
      • DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.
    • Amazon Detector Library Python
      • User-controllable input must be sanitized before it’s included in output used to dynamically generate a web page. Unsanitized user input can introduce cross-side scripting (XSS) vulnerabilities that can lead to inadvertedly running malicious code in a trusted context.
    • In AWS WAF, you can create a rule for the part of the web request that you want AWS WAF to inspect.
    • Example vulnerability
      • CVE-2025-27088 – A Reflected Cross-site Scripting (XSS) vulnerability was discovered in oxyno-zeta/s3-proxy, an AWS S3 proxy written in Go. The vulnerability exists in the folder-list template implementation where the Request.URL.Path variable is rendered directly into the HTML without proper sanitization or escaping. The affected template allows users to interact with the URL path, which can be exploited by crafting malicious URLs containing injected HTML or JavaScript.
  • 3.6. Unpatched software vulnerability
    • ALASNGINX1-2024-007
      • NGINX Open Source and NGINX Plus have a vulnerability in the ngx_http_mp4_module, which might allow an attacker to over-read NGINX worker memory resulting in its termination, using a specially crafted mp4 file. The issue only affects NGINX if it is built with the ngx_http_mp4_module and the mp4 directive is used in the configuration file. Additionally, the attack is possible only if an attacker can trigger the processing of a specially crafted mp4 file with the ngx_http_mp4_module.
  • 3.7. Server Side Request Forgery (SSRF)

4. Attack Surface – Application Tier

  • Attack surface
    • Internal ALB listener rules, Security Groups, and routing configurations
    • Node.js (application tier, which is written in Node.js) Application code, npm dependencies and API endpoints
    • EC2 instances – OS vulnerabilities, instance metadata
    • API endpoints – Exposed endpoints, Authentication and authorization
    • Potential Attacks include below:
  • 4.1. SQL Injection
    • A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.
    • SQL injection types
    • Sourced from, https://www.researchgate.net/figure/SQL-Injection-Categories-and-Types-proached-through-various-techniques-which-are-broadly_fig1_292997018
    • AWS WAF SQL injection attack rule statement – An SQL injection rule statement inspects for malicious SQL code. Attackers insert malicious SQL code into web requests in order to do things like modify your database or extract data from it.
    • Amazon Detector Library Python – User-provided inputs must be sanitized before being used to generate a SQL database query. An attacker can create and use untrusted input to run query statements that read, modify, or delete database content.
    • Example CVE
      • CVE-2024-32888 – The Amazon JDBC Driver for Redshift is a Type 4 JDBC driver that provides database connectivity through the standard JDBC application program interfaces (APIs) available in the Java Platform, Enterprise Editions. Prior to version 2.1.0.28, SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code which has a vulnerable SQL that negates a parameter value. There is no vulnerability in the driver when using the default, extended query mode.
  • 4.2. API Abuse exploiting missing/weak Authentication, Insecure JWT Token validation (forged token), Missing MFA, and unauthorized API requests
    • Amazon Detector Library Python – Failure to verify a user’s identity results in improper authentication. This can allow an attacker to acquire privileges to access sensitive data in your application.
    • Amazon Detector Library Python – The endpoint is potentially accessible to not authorized users. If it contains sensitive information, like log files for example, it may lead to privilege escalation.
  • 4.3. Dependency Vulnerabilities – Outdated or vulnerable npm packages
  • 4.4. Internal ALB misconfiguration – Same as ALB misconfiguration
  • 4.5. API key exposure

5. Attack Surface – Database Tier

  • Attack surface
    • Aurora MySQL DB – DB engine, schema, Authentication credentials and access controls, Security Group (SG) and Network Access Control List (NACL) rules for DB access, DB storage – not encrypting the data at rest , backup and snapshot config
  • SQLi – See SQLi under Application Tier
  • Unauthorized Access via stolen IAM credentials or overly permissive SG or misconfigured network rules
  • Data exfiltration
  • Unauthorized access to unencrypted DB snapshots or snapshots stored in S3
  • Misconfiguration
  • Overprivileged DB Users

5. Attack Surface – Virtual Private Cloud (VPC), Network Controls and Infrastructure

  • Attack Surface
    • VPC config – public and private subnets, route tables, internet gateways
    • Security Group and NACL
    • Autoscaling groups – auto scaling policies
    • CloudWatch and CloudTrail monitoring
  • VPC misconfiguration – Public subnets hosting sensitive resources
  • Exploiting open ports
  • Misconfigured SG and NACL

6. Attack Surface – Identity and Access Management and Monitoring

  • Attack Surface
    • IAM roles and policies assigned to EC2 instance, ALB , etc.
    • IAM groups
    • Access keys and credentials
  • Compromised credentials
  • Privileged escalation via backdoor IAM role
  • Disabling CloudTrail and CloudWatch events

7. AWS Services

The following list includes AWS services used in this three-tier web application, as well as additional services. Although not part of this specific deployment, are commonly used in real-world production environments.

  1. AWS API Gateway
    • Amazon API Gateway is an AWS service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. API developers can create APIs that access AWS or other web services, as well as data stored in the AWS Cloud. As an API Gateway API developer, you can create APIs for use in your own client applications. Or you can make your APIs available to third-party app developers. 
  2. Amazon Aurora
    • Amazon Aurora (Aurora) is a fully managed relational database engine that’s compatible with MySQL and PostgreSQL. You already know how MySQL and PostgreSQL combine the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. The code, tools, and applications you use today with your existing MySQL and PostgreSQL databases can be used with Aurora. With some workloads, Aurora can deliver up to five times the throughput of MySQL and up to three times the throughput of PostgreSQL without requiring changes to most of your existing applications.
    • Aurora includes a high-performance storage subsystem. Its MySQL- and PostgreSQL-compatible database engines are customized to take advantage of that fast distributed storage. The underlying storage grows automatically as needed.
  3. Amazon CloudWatch
    • Amazon CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time, and offers many tools to give you system-wide observability of your application performance, operational health, and resource utilization.
    • Metrics collect and track key performance data at user-defined intervals. Many AWS services automatically report metrics into CloudWatch, and you can also publish custom metrics in CloudWatch from your applications.
  4. AWS Application Load Balancer (ALB)
    • Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of its registered targets, and routes traffic only to the healthy targets. Elastic Load Balancing scales your load balancer as your incoming traffic changes over time. 
    • An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model. After the load balancer receives a request, it evaluates the listener rules in priority order to determine which rule to apply, and then selects a target from the target group for the rule action. You can configure listener rules to route requests to different target groups based on the content of the application traffic. 
  5. AWS AutoScaling
    • AWS Auto Scaling monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost. Using AWS Auto Scaling, it’s easy to setup application scaling for multiple resources across multiple services in minutes. The service provides a simple, powerful user interface that lets you build scaling plans for resources including Amazon EC2 instances and Spot Fleets, Amazon ECS tasks, Amazon DynamoDB tables and indexes, and Amazon Aurora Replicas. 
  6. AWS Certificate Manager
    • AWS Certificate Manager (ACM) handles the complexity of creating, storing, and renewing public and private SSL/TLS X.509 certificates and keys that protect your AWS websites and applications. You can provide certificates for your integrated AWS services either by issuing them directly with ACM or by importing third-party certificates into the ACM management system. ACM certificates can secure singular domain names, multiple specific domain names, wildcard domains, or combinations of these. 
  7. AWS CloudFront
    • Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations. When a user requests content that you’re serving with CloudFront, the request is routed to the edge location that provides the lowest latency (time delay), so that content is delivered with the best possible performance.
  8. AWS CloudTrail
    • CloudTrail is a web service that records AWS API calls for your AWS account and delivers log files to an Amazon S3 bucket. The recorded information includes the identity of the user, the start time of the AWS API call, the source IP address, the request parameters, and the response elements returned by the service.
  9. AWS Lambda
    • You can use AWS Lambda to run code without provisioning or managing servers. Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, and logging. With Lambda, all you need to do is supply your code in one of the language runtimes that Lambda supports. You organize your code into Lambda functions. The Lambda service runs your function only when needed and scales automatically.
  10. AWS Route53
    • Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. You can use Route 53 to perform three main functions in any combination: domain registration, DNS routing, and health checking.
  11. AWS VPC
    • With Amazon Virtual Private Cloud (Amazon VPC), you can launch AWS resources in a logically isolated virtual network that you’ve defined. This virtual network closely resembles a traditional network that you’d operate in your own data center, with the benefits of using the scalable infrastructure of AWS.
    • AWS Subnets
      • A subnet is a range of IP addresses in your VPC. A subnet must reside in a single Availability Zone. After you add subnets, you can deploy AWS resources in your VPC.
      • Each subnet must reside entirely within one Availability Zone and cannot span zones. By launching AWS resources in separate Availability Zones, you can protect your applications from the failure of a single Availability Zone.
      • Subnet types
        • Public subnet – The subnet has a direct route to an internet gateway. Resources in a public subnet can access the public internet.
        • Private subnet – The subnet does not have a direct route to an internet gateway. Resources in a private subnet require a NAT device to access the public internet.
        • VPN-only subnet – The subnet has a route to a Site-to-Site VPN connection through a virtual private gateway. The subnet does not have a route to an internet gateway.
        • Isolated subnet – The subnet has no routes to destinations outside its VPC. Resources in an isolated subnet can only access or be accessed by other resources in the same VPC.
    • AWS VPC endpoint
      • A VPC endpoint enables customers to privately connect to supported AWS services and VPC endpoint services powered by AWS PrivateLink. Amazon VPC instances do not require public IP addresses to communicate with resources of the service. Traffic between an Amazon VPC and a service does not leave the Amazon network.
      • VPC endpoints are virtual devices. They are horizontally scaled, redundant, and highly available Amazon VPC components that allow communication between instances in an Amazon VPC and services without imposing availability risks or bandwidth constraints on network traffic. There are two types of VPC endpoints:
      • interface endpoints
      • gateway endpoints
    • AWS Private Link
      • You can use Amazon VPC to define a virtual private cloud (VPC), which is a logically isolated virtual network. You can allow the clients in your VPC to connect to destinations outside that VPC. For example, add an internet gateway to the VPC to allow access to the internet, or add a VPN connection to allow access to your on-premises network. Alternatively, use AWS PrivateLink to allow the clients in your VPC to connect to services and resources in other VPCs using private IP addresses, as if those services and resources were hosted directly in your VPC.
      • AWS PrivateLink is a highly available, scalable technology that you can use to privately connect your VPC to services and resources as if they were in your VPC. You do not need to use an internet gateway, NAT device, public IP address, AWS Direct Connect connection, or AWS Site-to-Site VPN connection to allow communication with the service or resource from your private subnets. Therefore, you control the specific API endpoints, sites, services, and resources that are reachable from your VPC.
  12. AWS WAF
    • AWS WAF is a web application firewall that lets you monitor the HTTP(S) requests that are forwarded to your protected web application resources. You can protect the following resource types:
      • Amazon CloudFront distribution
      • Amazon API Gateway REST API
      • Application Load Balancer, etc.
    • AWS WAF lets you control access to your content. Based on criteria that you specify, such as the IP addresses that requests originate from or the values of query strings, the service associated with your protected resource responds to requests either with the requested content, with an HTTP 403 status code (Forbidden), or with a custom response.

Leave a comment