TABLE OF CONTENTS
See the previous part “Security in AWS – Part 2”.
Domain 3: Infrastructure Security
Every system begins with a strong foundation. In AWS, this foundation is the network and the infrastructure that connect all resources together. Infrastructure security defines how data travels, how access is controlled and how communication with the outside world is protected. The goal is to create an environment that is open enough for legitimate use but closed to unauthorized access or accidental exposure.
This domain focuses on how AWS services help to build secure and resilient environments through isolation, encryption and protection against external threats. Services such as Amazon Virtual Private Cloud (VPC), Security Groups, Network ACLs, NAT and Internet Gateways, Virtual Private Gateway (VGW), Site-to-Site VPN, VPC Endpoints, Amazon CloudFront, AWS Certificate Manager (ACM) and AWS Shield play key roles in maintaining infrastructure security. Each of them contributes a specific layer of defense, from private networking to encryption and global threat protection.
The following overview describes how these services work together to build secure cloud foundations.
Amazon VPC, Security Groups and Network ACLs
Amazon Virtual Private Cloud (VPC) is the foundation for creating secure and isolated environments in AWS. It allows organizations to design their own virtual networks with complete control over IP addressing, routing, and connectivity. Within a VPC, applications, databases and supporting services can operate in a protected space that behaves much like a traditional on-premises data center but with the scalability and flexibility of the cloud.
Security within a VPC is maintained primarily through two mechanisms: Security Groups and Network Access Control Lists (ACLs). Security Groups act as virtual firewalls at the instance level. They define which inbound and outbound traffic is allowed based on rules that specify protocol, port and source or destination. For instance, a web server might only permit inbound HTTPS traffic from the internet and allow outbound connections to an internal database subnet. Security Groups are stateful, meaning that if a connection is allowed in one direction, the return traffic is automatically permitted.
Network ACLs operate at the subnet level and serve as an additional security boundary. They are stateless, so every inbound and outbound rule must be defined separately. ACLs are often used to block known malicious IP ranges or enforce stricter segmentation between application tiers. By combining Security Groups and ACLs, organizations can achieve a layered defense model that protects both individual resources and entire subnet zones.
Internet Gateway, NAT Gateway, Virtual Private Gateway and VPN
Most systems need to connect with the outside world in some way and AWS provides several options to make that both possible and safe. The Internet Gateway (IGW) allows communication between a VPC and the public internet, enabling users to reach web applications hosted in AWS. When workloads inside private subnets need to connect outward without being exposed themselves, a NAT Gateway (NAT) handles that task. It lets private instances initiate outbound connections, such as downloading updates or contacting APIs, while keeping them invisible from the internet.
For private, encrypted communication between AWS and on-premises environments, the Virtual Private Gateway (VGW) and Site-to-Site VPN (S2S VPN) provide secure tunnels over the internet. These are often used in hybrid setups where part of the infrastructure remains on local servers and part runs in AWS. The encryption ensures that data moving between locations stays private and tamper-proof.
VPC Endpoints and Endpoint Policies
A VPC Endpoint provides a secure and private connection between resources inside a VPC and supported AWS services such as Amazon S3, DynamoDB, SNS and many others, without requiring traffic to traverse the public internet. Instead of passing through an Internet Gateway or NAT Gateway, the traffic stays entirely within the AWS network, which improves both security and performance. This design eliminates exposure to external networks, reduces the risk of data interception and helps organizations meet compliance requirements for private connectivity.
There are two main types of VPC Endpoints: Gateway Endpoints and Interface Endpoints. Gateway Endpoints are used primarily for services like S3 and DynamoDB. They add routes to the VPC’s route tables that direct traffic securely to those services through the AWS backbone. Interface Endpoints, on the other hand, create Elastic Network Interfaces (ENIs) inside the VPC that connect directly to supported AWS services or third-party SaaS providers. Interface Endpoints are powered by AWS PrivateLink, which extends private connectivity to a broader set of services.
Each VPC Endpoint can have its own resource policy, which specifies who can use the endpoint, what actions they can perform and which resources are accessible. This enables precise control over data flow and enforces least privilege principles at the network level.
For example, an organization might configure an S3 Gateway Endpoint policy that allows only an application running in a specific private subnet to access a designated S3 bucket, while denying all other traffic. This ensures that even within the internal network, only authorized applications and users can interact with sensitive data.
In addition to security benefits, VPC Endpoints also improve reliability and performance. Since traffic never leaves the AWS network, latency is lower and data transfer costs are reduced. For workloads that rely heavily on AWS services, this can lead to more consistent performance and simpler compliance management, as no external connectivity needs to be justified or monitored.
By integrating VPC Endpoints into network architecture, organizations create a secure, efficient and predictable communication path between applications and AWS services. This approach combines the privacy of a local network with the scale and resilience of the AWS infrastructure.
Amazon CloudFront
Amazon CloudFront is a global content delivery network (CDN) designed to deliver websites, videos and applications to users with low latency and high transfer speed. It works by caching copies of frequently requested content at AWS edge locations around the world, reducing the distance between the user and the data. While performance is its most visible feature, CloudFront also provides an important layer of security for applications and data.
By acting as an intermediary between users and the origin server, CloudFront hides the origin’s direct address and helps protect it from attacks. One of its key security capabilities is Origin Access Control (OAC), which ensures that content stored in services like Amazon S3 is only accessible through CloudFront. This prevents users from bypassing the CDN and requesting files directly from the source. OAC replaces the older Origin Access Identity (OAI) mechanism, offering stronger security and better integration with S3 bucket policies.
CloudFront also supports geo-restrictions, allowing organizations to limit content availability based on user location. This feature is commonly used for compliance, licensing, or security reasons, ensuring that data or media are only accessible from approved countries or regions.
Access control can be further refined with signed URLs and signed cookies, which restrict how and when specific content can be accessed. For example, a streaming service can issue temporary signed URLs to paying subscribers, while signed cookies can grant short-term access to multiple protected files. Field-level encryption adds another layer of protection by allowing sensitive parts of requests (such as form fields containing personal information or payment details) to be encrypted before they leave the viewer’s browser and decrypted only by authorized components at the origin.
Through Lambda@Edge, CloudFront can also run custom logic directly at edge locations. This enables developers to validate authentication tokens, rewrite requests, filter suspicious headers or personalize responses without sending traffic back to the origin. Running such logic close to users not only improves performance but also enhances security by blocking harmful traffic early.
AWS Certificate Manager (ACM)
Encrypting traffic is one of the most important parts of securing communication between users, applications and services. It ensures that data exchanged over the internet or internal networks remains private, tamper-proof and trustworthy. AWS Certificate Manager (ACM) simplifies the entire lifecycle of SSL/TLS certificates, which are the foundation of secure HTTPS connections.
Instead of manually generating, installing and renewing certificates, ACM automates all of these steps. It can create new public or private certificates, deploy them to supported AWS resources and renew them automatically before expiration. This removes the operational burden and eliminates one of the most common causes of unexpected outages – expired certificates.
ACM integrates directly with services such as Amazon CloudFront, Elastic Load Balancing (ELB) and API Gateway. With just a few clicks, encryption in transit can be applied to web applications, APIs or backend systems without manual configuration. ACM also supports private certificate authorities (CAs) through AWS Private CA, which allows organizations to issue and manage internal certificates for applications and devices that are not exposed to the internet.
Certificates issued by ACM are stored securely and managed at scale. Developers can request certificates programmatically using AWS SDKs or the CLI, which makes it easy to integrate encryption into automated deployment pipelines.
ACM also ensures that certificates use modern cryptographic standards. It automatically supports strong encryption algorithms and enforces secure protocols, helping maintain compliance with industry requirements such as PCI DSS or ISO 27001. Combined with CloudFront and AWS Shield, ACM forms a critical part of the perimeter security layer for internet-facing workloads.
By automating certificate management and enforcing encryption everywhere, AWS Certificate Manager reduces operational risk, simplifies compliance and helps ensure that all communication across applications remains secure, reliable and trusted.
AWS WAF
AWS Web Application Firewall (WAF) protects web applications from unwanted or harmful internet traffic. It acts as a filter between users and the application, inspecting incoming requests and deciding whether to allow or block them based on a set of defined rules. WAF operates at the application layer, which means it can detect and stop attacks that go beyond basic network protection.
It is commonly used with services such as Application Load Balancer, Amazon CloudFront or API Gateway. These are the points where user requests first enter the AWS environment, making them ideal places to inspect traffic. WAF rules can control access based on various factors like the IP address of the requester, the country they are connecting from, specific request patterns or the rate of requests coming in over a short period. For example, if too many requests arrive from the same source within seconds, WAF can temporarily block that traffic to prevent overload or abuse.
To make setup easier, AWS provides managed rule groups that automatically protect against known threats such as SQL injection or cross-site scripting. These are among the most common ways attackers try to manipulate or gain access to applications, so having automated protection for them significantly reduces risk.
WAF also provides visibility into what kind of traffic reaches an application. Its metrics and detailed logs can be sent to Amazon CloudWatch or Amazon S3 for analysis. EventBridge can then use those logs to trigger automated actions, such as blocking an IP range that shows suspicious behavior.
We can think about AWS WAF as a smart security guard for web applications. It not only blocks malicious traffic but also provides insights into how applications are being accessed, helping maintain both security and performance.
AWS Shield and DDoS Protection
AWS Shield provides automatic protection against Distributed Denial of Service (DDoS) attacks, which are attempts to overwhelm servers with excessive traffic. Shield Standard is enabled for all AWS customers by default and offers protection for common attack types.
For applications that require higher levels of defense, Shield Advanced adds real-time monitoring, detailed attack reports and access to the AWS DDoS Response Team (DRT). It also integrates with CloudFront and Route 53 to protect globally distributed resources.
Shield acts as a constant safeguard at the network edge, keeping applications available even during high-volume attacks. Combined with CloudFront, it ensures that legitimate users can always access services while malicious traffic is filtered out before it reaches the core infrastructure.
Real Use-Case Scenario
In this section, I will present a real-world example of how we apply the services described in “Infrastructure Security” at Klika.
This example illustrates a classic three-tier secured infrastructure architecture that we provisioned at one of our projects.
Let’s assume we have containerized applications running in an Amazon EKS cluster. These applications need access to Amazon RDS databases, as well as several AWS services such as S3, SNS and SQS. They must not be directly reachable from the Internet, only through a public Application Load Balancer (ALB) using HTTPS with a valid public certificate. However, the applications themselves should still be able to initiate outbound connections to the Internet when needed. Additionally, static content should be delivered to users with minimal latency. From a security perspective, the entire infrastructure must follow the principle of least privilege.
Take a look at Figure 2 and its explanation below.
For static content, we deploy Amazon CloudFront with an S3 bucket as its origin. The bucket policy allows access only through the CloudFront Origin Access Control (OAC), ensuring there is no direct public access to the bucket. In front of CloudFront, we place AWS WAF, which protects against common Layer-7 web attacks. The Cloudfront itself can restrict user’s requests based on their geolocation.
For the containerized applications, we provision a VPC with three subnets: public, private, and database subnets. The public subnet hosts the ALB, which serves HTTPS traffic using a certificate from AWS Certificate Manager (ACM). The private subnet contains the EKS worker nodes where the containerized applications run. The database subnet hosts the RDS instances.
Each tier has its own Security Group, allowing access only from the relevant layer. The ALB Security Group allows inbound HTTPS (443) from 0.0.0.0/0. The EKS worker nodes Security Group allows inbound HTTP or application-specific ports from the ALB Security Group. Finally, RDS Security Group allows inbound traffic only on the database port (for example, 3306) from the EKS worker nodes Security Group.
To enable outbound access to the Internet, the EKS worker nodes use a NAT Gateway configured in the private subnet route table. Additionally, when applications need to communicate with SQS, SNS or S3, they do so through VPC Gateway or Interface Endpoints, ensuring that traffic remains within the secure AWS network backbone instead of traversing the public Internet. As an additional security measure, each VPC Endpoint has its own policy document that restricts access to specific private subnet CIDR ranges.
With this architecture, we ensure a secure environment that follows AWS best practices. The setup minimizes exposure to the Internet, enforces strict network segmentation, applies the principle of least privilege and leverages native AWS services for infrastructure security.
Now that we’ve seen these tools in action, let’s conclude this article with a quick recap of what we’ve learned.
Infrastructure Security Recap
| Function | Primary Services | Objective |
|---|---|---|
| Network isolation | VPC, Security Groups, Network ACLs | Control inbound and outbound traffic within AWS environments |
| Secure connectivity | Internet Gateway, NAT Gateway, VGW, Site-to-Site VPN | Enable secure communication between private and public networks |
| Private service access | VPC Endpoints | Connect to AWS services without exposing traffic to the public internet |
| Secure content delivery | CloudFront (OAC, Geo restrictions, Signed URLs, Field-Level Encryption, Lambda@Edge) | Distribute data securely with global reach and fine-grained access control |
| Certificate management | AWS Certificate Manager (ACM) | Simplify SSL/TLS certificate creation and renewal for encrypted communication |
| Application protection | AWS WAF | Filter malicious web traffic |
| DDoS protection | AWS Shield (Standard, Advanced) | Defend public applications against large-scale denial-of-service attacks |
See the next part “Security in AWS – Part 4: Identity and Access Management”.
By Pavel Luksha, Senior DevOps Engineer, Klika Tech, Inc.