What AWS Services Keep You Protected on Each Level
When designing secure systems in the cloud, the Open Systems Interconnection (OSI) model remains a valuable framework. Originally created to describe how data flows through a network, its seven-layer structure, from physical hardware to application-level communication, offers a clear way to think about where and how to apply security controls.
In cloud environments, layered security is essential. No single control is enough to protect against the range of threats modern systems face. Encryption won’t stop SQL injection. A firewall won’t fix a misconfigured IAM policy. Each layer introduces unique risks, and each demands targeted defenses.
This article maps the seven layers of the OSI model to AWS services that help implement defense-in-depth. Whether you’re building cloud-native applications or securing existing workloads, this guide provides a practical approach to aligning architecture and security from the ground up.
The OSI Model and the Shared Responsibility Principle
The OSI model breaks down communication systems into seven distinct layers: physical, data link, network, transport, session, presentation, and application. Each layer plays a specific role, from moving raw bits over hardware to delivering formatted content to end users. In the context of security, these layers help identify where controls are needed and what kinds of threats must be mitigated.
In cloud environments like AWS, security follows a shared responsibility model. AWS manages the infrastructure that supports its services, including physical facilities, networking, storage, and the virtualization layer. Customers are responsible for securing what they put in the cloud, such as data, configurations, access management, and, in some cases, the operating system.
Responsibility for the operating system and application stack depends on the service used. With infrastructure services like Amazon EC2, customers must secure the operating system and any software they install. With fully managed services like Amazon S3 or AWS Lambda, AWS takes care of the operating system, and customers focus on securing their data, permissions, and configurations.
This flexible model gives customers control while reducing operational overhead. Understanding where AWS’s responsibility ends and where yours begins is essential for designing secure cloud architectures.
Layer-by-Layer Breakdown
Each layer of the OSI model represents a distinct part of how data moves and applications function. In a traditional environment, security decisions might be made at the network perimeter. In the cloud, that perimeter shifts, often becoming more fluid and granular. That makes it even more important to approach security from a layered mindset. By examining each OSI layer and identifying the corresponding AWS services that support it, teams can build systems that are both secure and resilient. What follows is a practical breakdown of each layer, its security concerns, and the AWS tools available to address them.
Layer 1: Physical Layer
The physical layer covers the most foundational elements of a computing environment: cabling, power, servers, and access to the physical data centers themselves. In traditional on-premises infrastructure, organizations must manage these controls directly. In the cloud, that responsibility shifts entirely to AWS.
Attacks at the physical layer typically involve direct access to hardware. This can include tampering with network cables, installing rogue devices, or intercepting signals to capture data. Threats such as hardware keyloggers, cold boot attacks, and theft of storage media fall into this category. Environmental risks like power outages or temperature fluctuations can also compromise system availability. Because these attacks bypass software controls entirely, physical security is often the first and most critical line of defense.
AWS owns and operates the hardware, networking, and facilities that support its global infrastructure. Customers do not have physical access to these data centers, nor do they need to manage server racks or climate systems. Instead, AWS provides a range of documentation and tools to verify that its physical controls meet industry standards.
AWS Artifact gives customers access to third-party audit reports and certifications, including SOC 2, ISO 27001, and PCI DSS. These reports offer assurance that AWS maintains strong controls around physical access, environmental security, and hardware lifecycle management.
Although customers don’t interact with the physical layer directly, it’s still important to monitor and audit how their workloads behave within that infrastructure. AWS CloudTrail and AWS Config can surface unusual changes or misconfigurations that, while not directly tied to physical tampering, could indicate security drift within a deployment.
At this layer, trust in AWS’s physical security model is foundational. But visibility, compliance documentation, and smart monitoring still play a role in reinforcing that trust and meeting regulatory requirements.
Layer 2: Data Link Layer
The data link layer handles node-to-node communication and governs how devices use MAC addresses to identify one another within a local network. In traditional infrastructure, this layer is a common target for attacks such as ARP spoofing, MAC flooding, and VLAN hopping methods that allow attackers to intercept traffic, impersonate devices, or move laterally between network segments.
In AWS, Layer 2 is fully abstracted from customers. Amazon VPC is designed to isolate network traffic at the virtualization layer, eliminating direct exposure to MAC addresses or switching infrastructure. There is no concept of a shared broadcast domain, and VPCs are isolated by default unless explicitly connected using services like VPC Peering or Transit Gateway.
To provide visibility into network activity, VPC Flow Logs capture information about IP traffic going to and from network interfaces. While the logs operate at Layer 3, they can reveal unusual communication patterns that may be symptoms of misconfigured resources or attempted lateral movement.
For additional control, AWS Network Firewall allows teams to define stateful traffic rules at the VPC boundary, further segmenting workloads and limiting exposure to potential threats.
By removing direct access to Layer 2 constructs, AWS significantly reduces the attack surface. Still, architects and developers should be aware of how these traditional vulnerabilities translate into cloud environments and design their VPCs accordingly to enforce strong segmentation and observability.
Layer 3: Network Layer
The network layer controls how data is routed between systems using IP addressing. It plays a central role in cloud security architecture, as it’s often the first line of defense against external threats. At this layer, attackers may attempt IP spoofing, network scanning, or distributed denial-of-service (DDoS) attacks to overwhelm resources or probe for vulnerable endpoints.
At the heart of AWS network security is the Amazon Virtual Private Cloud (VPC). A VPC defines a logically isolated network space within the AWS cloud, where you control IP address ranges, subnets, routing, and internet connectivity. By default, VPCs are isolated from one another, and resources inside a VPC are not accessible from the public internet unless explicitly configured. VPCs enable security-first architecture by allowing teams to segment environments, such as separating development, staging, and production, or isolating sensitive services behind private subnets. Combined with route tables, internet gateways, and NAT gateways, VPCs provide a flexible, powerful framework for enforcing network boundaries and minimizing attack surface.
Route tables determine how network traffic is directed within a VPC. Each subnet is associated with a route table, which defines where packets should go based on destination IP ranges. For example, a route might send all internet-bound traffic (0.0.0.0/0) to an internet gateway, or route internal traffic between subnets through a transit gateway or NAT device.
Internet gateways allow resources in a VPC to connect to the public internet. When attached to a VPC and referenced in a route table, an internet gateway enables instances with public IP addresses to send and receive traffic from the internet. Without it, no internet connectivity is possible, even if the security groups and NACLs allow it.
NAT gateways (Network Address Translation) provide outbound internet access for resources in private subnets. They enable instances without public IPs to initiate outbound connections (for things like software updates or external APIs), while blocking unsolicited inbound traffic. This is a common best practice in secure architectures: keep workloads private and allow tightly controlled egress.
To manage access and isolate traffic, AWS provides two key tools: security groups and network access control lists (NACLs). Security groups allow or deny traffic based on IP addresses to aid with traffic isolation in the network layer.
Network ACLs, by contrast, operate at the subnet level and are stateless. Each rule, both inbound and outbound, must be explicitly defined. NACLs are well-suited for broader policies such as blocking known bad IP ranges or enforcing deny-first rules across larger portions of the network. While less flexible than security groups, they offer another layer of isolation and can serve as a safety net for misconfigured security groups.
To protect against network-based threats, AWS includes AWS Shield Standard by default across all accounts. It provides automatic detection and mitigation for common Layer 3 and Layer 4 DDoS attacks, such as SYN floods, UDP reflection, and IP fragmentation abuse. For mission-critical applications, AWS Shield Advanced provides enhanced protection, including real-time visibility, integration with AWS support, and financial safeguards against scaling costs during large attacks. When paired with AWS WAF, Shield Advanced can also block more complex Layer 7 attacks like HTTP floods.
AWS WAF (Web Application Firewall) primarily operates at the application layer, complementing network-layer defenses by filtering traffic based on conditions such as IP addresses, query strings, headers, and geographic origin.
Finally, Amazon Route 53 supports DNS-based failover and traffic routing policies such as latency-based, weighted, or geolocation routing. While these features are not direct security controls, they can enhance resilience. For example, if a primary endpoint is targeted during an attack, Route 53 can route users to a healthy backup, reducing downtime and limiting the effectiveness of the disruption.
Taken together, these tools give architects and developers robust control at the network layer. Amazon VPC provides the foundational structure for isolating workloads, while route tables, internet gateways, and NAT gateways define how traffic flows within and outside the network. Paired with security groups and network ACLs, teams can enforce fine-grained access policies. By incorporating protections from AWS Shield and AWS WAF, organizations can significantly reduce their exposure to external threats by building cloud networks that are both secure and resilient under pressure.
Layer 4: Transport Layer
The transport layer governs how data is transmitted between systems over protocols such as TCP and UDP. At this level, attackers often attempt to exploit open ports, overwhelm systems with malformed packets or connection floods, or entirely disrupt communication channels. Protecting this layer means controlling access to specific ports, managing protocol behavior, and filtering out malicious traffic early in the request flow.
In AWS, many of the tools used at Layer 3 continue to apply but with a different focus.
Security groups act as virtual firewalls at the resource level and operate across both the network (Layer 3) and transport (Layer 4) layers. They allow or deny traffic based on IP addresses (Layer 3) and protocol and port combinations (Layer 4), making them essential for enforcing fine-grained access control. Security groups are stateful, meaning that if you allow inbound traffic on a specific port, such as HTTPS on TCP 443, the corresponding outbound response is automatically permitted. They are tightly scoped, easy to audit, and commonly used to control access to services like EC2 instances, RDS databases, and Lambda functions with VPC access. By filtering traffic based on protocol, port range, and source or destination IP, security groups provide a flexible and reliable way to manage transport-layer security in AWS.
Elastic Load Balancers (ELBs), now known as classic load balancers, play a more prominent role at the transport layer. They terminate TLS/SSL connections, which helps offload encryption responsibilities from backend services and centralizes certificate management. ELBs also serve as the first point of entry for most internet-facing applications, making them critical to inspecting and shaping traffic based on transport-layer behavior. You can use Application Load Balancers for HTTP/HTTPS or Network Load Balancers for lower-level TCP/UDP handling at scale.
Together, these services allow teams to tightly control how transport-layer traffic is accepted, decrypted and routed. By combining port-level filtering, TLS termination, and connection-based controls, AWS enables fine-grained security at a layer where misconfiguration or exposure often leads to denial-of-service vulnerabilities or performance degradation.
Layer 5: Session Layer
The session layer manages the creation, maintenance, and termination of communication sessions between systems. In modern applications, these sessions often involve authenticated users, federated identities, or temporary roles. At this layer, threats like session hijacking, token replay, or unauthorized impersonation can compromise the integrity of secure interactions.
AWS offers several services that address these challenges. AWS Cognito handles user authentication and session token issuance for web and mobile apps. It supports OAuth 2.0, OpenID Connect, and SAML protocols; Cognito also issues ID, access, and refresh tokens to securely manage sessions. Cognito helps enforce multi-factor authentication and provides automatic token expiration, reducing the risk of session misuse.
AWS Identity and Access Management (IAM) provides session-level security for programmatic access. IAM roles use trust policies to define who or what can assume them, whether it’s another AWS service, account, or even an external identity provider. These trust relationships are the foundation of cross-account access, multi-cloud integration, and vendor delegation. When a role is assumed, AWS Security Token Service (STS) issues temporary credentials that expire after a defined duration, minimizing long-term credential exposure.
In enterprise settings, IAM Identity Center (formerly AWS SSO) extends session management to users authenticated via external identity providers like Okta, Azure AD, or Google Workspace. It allows centralized identity and session control across AWS accounts and third-party applications using SAML 2.0 or OIDC.
Amazon API Gateway further enforces session security by validating tokens, applying rate limits, and controlling request quotas. This ensures sessions are not only authenticated but also protected from abuse through throttling and usage plans.
Session security in AWS is not handled by a single service but through a combination of roles, tokens, and identity providers that work together to manage access. Whether it involves user logins, API calls, or cross-account permissions, AWS provides tools to enforce temporary, policy-based sessions that limit risk and improve oversight. With token-based authentication, role assumption, and identity federation, teams can define who has access, under what conditions, and for how long. In environments that span multiple accounts, vendors or clouds, strong session management is critical to maintaining control and reducing the risk of unauthorized access.
Layer 6: Presentation Layer
The presentation layer is responsible for translating, formatting, and securing data before it reaches the application layer. In modern cloud environments, this often means ensuring data is encrypted both in transit and at rest using trusted protocols and managed cryptographic services. Weaknesses at this layer can lead to data leakage, man-in-the-middle attacks, or violations of compliance requirements.
AWS offers several tools to help secure the presentation layer. AWS Certificate Manager (ACM) simplifies the provisioning, deployment, and renewal of SSL/TLS certificates, allowing developers to enforce encrypted connections for services like Application Load Balancers, CloudFront, and API Gateway. By automating certificate management, ACM reduces the risk of expired certificates and enables consistent HTTPS enforcement.
Amazon CloudFront, AWS’s content delivery network, adds another layer of protection for data in transit. It supports full HTTPS enforcement, custom TLS policies, and integration with ACM to secure connections at the edge. By terminating TLS at geographically distributed edge locations, CloudFront helps ensure encrypted data delivery with minimal latency.
For securing data at rest and between services, AWS Key Management Service (KMS) provides centralized encryption key management. KMS is natively integrated with nearly every core AWS service, such as S3, EBS, RDS, Lambda, and DynamoDB, allowing encryption to be enabled with a single setting. In many cases, such as with S3 and EBS, encryption is turned on by default using AWS-managed keys. For greater control, teams can use customer-managed keys (CMKs) to define key rotation policies, restrict access using IAM, and audit usage through AWS CloudTrail. KMS supports envelope encryption and is designed to meet strict security and compliance standards, including FIPS 140–2.
By consistently applying encryption at the presentation layer, organizations can protect sensitive data, meet regulatory requirements, and reduce exposure to common threats. In a well-architected cloud environment, this layer serves as the last line of defense before data reaches the application or user.
Layer 7: Application Layer
The application layer is where users interact with systems and where attackers often strike first. It’s responsible for interpreting user inputs, handling business logic, and delivering responses. This layer is vulnerable to common exploits such as cross-site scripting (XSS), SQL injection (SQLi), and other forms of input-based attacks. Misconfigurations, insecure credentials, and unpatched dependencies can all lead to breaches at this level.
To defend against these risks, AWS offers several tools. AWS WAF (Web Application Firewall) provides customizable rule sets to detect and block common attack patterns, including SQLi, XSS, and bot traffic. It integrates with services like CloudFront, API Gateway, and Application Load Balancer to filter requests before they reach backend services. With managed rules and rate-based controls, WAF helps protect APIs and web applications from abuse and known threats.
Amazon Inspector adds another layer of defense by performing vulnerability scans on EC2 instances, containers, and Lambda functions. It automatically assesses software packages, system configurations, and network exposure, helping teams identify and remediate known vulnerabilities before they can be exploited.
Amazon GuardDuty serves as a threat detection engine, continuously analyzing AWS account activity, VPC flow logs, and DNS queries for signs of compromised resources or malicious behavior. It can alert teams to unauthorized API activity, reconnaissance attempts, or unusual patterns in data access, often catching threats that evade traditional perimeter defenses.
Credential misuse is one of the most common and dangerous risks at the application layer. To help prevent it, AWS provides AWS Secrets Manager, a secure service for storing, retrieving and rotating secrets such as API keys, database credentials and OAuth tokens. Secrets Manager integrates with many AWS services, including RDS, Redshift, and Lambda, allowing applications to fetch credentials programmatically through IAM-authenticated calls rather than hardcoding them into source code or environment variables.
One of Secrets Manager’s most powerful features is automatic rotation. For supported services like Amazon RDS and Amazon DocumentDB, it can rotate passwords on a schedule using AWS Lambda. Developers can also write custom rotation functions for third-party or on-premises systems. This ensures secrets are rotated regularly without requiring manual intervention, reducing the attack surface and eliminating reliance on long-lived credentials.
Together, these tools help secure the application layer by reducing vulnerabilities, filtering malicious inputs and protecting sensitive information. As the final interface between users and data, this layer demands strict attention to validation, monitoring, and credential hygiene, especially in internet-facing workloads.
Defense-in-Depth in Practice
While each layer of the OSI model addresses a different aspect of network communication, security is most effective when protections at each layer work together. AWS provides services that span these layers, creating overlapping safeguards that reduce the likelihood of a single point of failure. This strategy, often referred to as defense in depth, is key to building secure and resilient cloud architectures.
Consider a typical web application hosted in AWS. At the network and transport layers, security groups and network ACLs restrict traffic to only the ports and protocols required. A load balancer terminates TLS connections, enforced by AWS Certificate Manager, ensuring encrypted communication from end users. AWS WAF filters out malicious traffic at the application layer, blocking known attack patterns before they reach backend services. Amazon Inspector scans for unpatched vulnerabilities in the EC2 instances, while GuardDuty monitors traffic and user behavior for suspicious activity.
For data protection, KMS and Secrets Manager work together to encrypt both stored data and credentials, reducing the risk of compromise even if the infrastructure is accessed. IAM roles, trust policies, and session credentials ensure that users, services, and third-party systems only receive access when necessary and only for as long as needed.
Monitoring and auditing tie the entire strategy together. AWS CloudTrail logs API activity, Amazon CloudWatch tracks operational metrics, and AWS Config audits resource configurations. These services provide the visibility and alerting needed to detect and respond to threats in real time.
Automation also plays a critical role. Many AWS security services support triggers and integrations with tools like AWS Lambda, Security Hub, and EventBridge, allowing organizations to automatically remediate common issues such as revoking access, rotating secrets, or quarantining compromised resources.
By layering these services across the OSI model, AWS enables organizations to embed security at every level of the stack — from the physical infrastructure to the application layer. Defense in depth isn’t about depending on a single tool; it’s about designing systems with overlapping, adaptive protections that minimize risk. To take this approach even further, explore how the AWS Well-Architected Framework helps evaluate and improve your cloud security posture across all critical dimensions.
At New Math Data, we build security-informed data and AI systems for customers of all sizes. Reach out or comment below to discuss your experiences or questions related to making your applications more secure at each level!