Most AWS setups start with VPNs and broad IAM permissions. Over time, users often receive more access than they need, devices are rarely checked, and network-based trust replaces actual verification. This creates security gaps that increase over time.
A stolen credential on a trusted network can provide access across your AWS accounts and resources. A developer with overly broad IAM permissions can access resources they should never touch. A contractor using an unmanaged device can connect to internal applications without any device check.
Zero Trust removes the assumption that users or devices inside the network are safe. Every access request is verified, no matter where it comes from, which device is used, or who the user is.
In AWS, three services are used to implement this:
- IAM Identity Center — controls who gets access, with what permissions, and for how long
- AWS Verified Access — controls access to internal applications based on user identity and device posture, without requiring a VPN
- Amazon GuardDuty — continuously monitors for threats and detects suspicious activity that bypasses access controls
This guide covers how to configure these three services to implement Zero Trust security in your AWS setup.
Contents
- 1 Zero Trust in AWS
- 2 How AWS Zero Trust Services Are Structured?
- 3 AWS Zero Trust Licensing (2026)
- 4 What to Check Before Starting?
- 5 Set Up IAM Identity Center for Centralized Access
- 6 Set Up AWS Verified Access for Application Access Without a VPN
- 7 Enable Amazon GuardDuty for Continuous Threat Detection
- 8 Common GuardDuty Threat Signals
- 9 How These Services Create a Zero Trust Security Model?
- 10 AWS Zero Trust Security with Netstager Technologies
Zero Trust in AWS
Zero Trust is a security approach based on the idea of never trusting users, devices, or network connections automatically. No user, device, or network connection is trusted by default, including those already inside your AWS accounts and resources.
Traditional security depends heavily on network boundaries. If a user or device is already inside the network, it is often treated as safe. Zero Trust removes this assumption completely.
In AWS, Zero Trust means:
• Every user authenticates through a central identity system before accessing any resource
• Permissions are limited to exactly what each role requires and nothing more
• Applications are accessed based on verified identity and device health instead of network location
• All activity is continuously monitored for suspicious behaviour and possible threats
This is the same concept used in Conditional Access Policies in Microsoft 365. In AWS, IAM Identity Center, Verified Access, and GuardDuty provide identity verification, access control, and threat monitoring before users reach AWS resources and applications.
How AWS Zero Trust Services Are Structured?
Each service handles a different part of Zero Trust security. Together, they create a complete access control and threat monitoring setup.
| Service | What it does | Zero Trust role |
|---|---|---|
| IAM Identity Center | Manages user identities, groups, and permission sets for multiple AWS accounts | Identity verification and least privilege access |
| AWS Verified Access | Controls access to internal applications based on identity and device posture | Application access control without a VPN |
| Amazon GuardDuty | Monitors AWS activity for threats using AI and ML | Continuous threat detection and attack sequence identification |
AWS Zero Trust Licensing (2026)
All three services are available for standard AWS accounts. Costs are based on usage rather than licensing tiers.
| Service | Availability | Cost model |
|---|---|---|
| IAM Identity Center | Free | No additional charge |
| AWS Verified Access | Available in commercial AWS regions | Per hour per endpoint + data processed |
| Amazon GuardDuty | Free 30-day trial, then paid | Per volume of data analyzed |
| GuardDuty Extended Threat Detection | Automatically enabled for GuardDuty customers | No additional cost |
What to Check Before Starting?
Before configuring these services, complete two checks to avoid access issues later.
Step 1: Create an Emergency Access Account
An emergency access account is a separate IAM user with AdministratorAccess that remains independent from your normal identity workflows. This account exists only to recover access if IAM Identity Center or other configurations cause access problems.
Set this up with the following:
• Create an IAM user directly in the AWS root account with AdministratorAccess
• Use a long, complex password stored in a secure offline location
• Enable MFA on this account
• Do not use this account for daily work
• Set a CloudTrail alarm for any sign-in activity on this account
Step 2: Review Existing IAM Users and Permissions
Before setting up IAM Identity Center, review what is already configured in your AWS accounts and IAM setup.
Go to: AWS Console → IAM → Users.
Check for:
• IAM users with long-term access keys still active
• Users with AdministratorAccess or broad wildcard permissions
• Service accounts with more permissions than needed
The purpose is to move away from direct IAM user access and use role-based access through IAM Identity Center instead. Existing users should be reviewed and migrated gradually, not removed immediately.
Set Up IAM Identity Center for Centralized Access
IAM Identity Center is the identity base for Zero Trust in AWS. It manages who can access which AWS accounts and applications using time-limited role-based permissions instead of permanent credentials.
Step 1: Enable IAM Identity Center
Before setting up IAM Identity Center, review what is already configured in your AWS accounts and IAM setup.
Go to: AWS Console → IAM Identity Center → Enable.
Enable it in the AWS Region closest to your users. For India-based setups, use ap-south-1 (Mumbai).
If you are using AWS Organizations, enable IAM Identity Center from the management account. This provides centralized control over all member accounts.
Step 2: Connect Your Identity Source
IAM Identity Center supports three identity sources:
| Identity source | Best suited for |
|---|---|
| Built-in Identity Center directory | Organizations with no existing identity provider |
| Microsoft Entra ID (Azure AD) | Organizations already using Microsoft 365 |
| External SAML 2.0 provider (Okta, Google Workspace) | Organizations using third-party identity providers |
If your organization uses Microsoft 365, connect Microsoft Entra ID as the identity source. This enables users single sign-on across both Microsoft 365 and AWS using one set of credentials, the same identity, applying the same policies.
Before setting up IAM Identity Center, review what is already configured in your AWS accounts and IAM setup.
Go to: IAM Identity Center → Settings → Identity source → Change → External identity provider.
Follow the SAML configuration steps to connect your provider.
Step 3: Create Permission Sets
Permission sets control what a user can do when they access an AWS account. They replace direct IAM user permissions with role-based access that expires after a set duration.
Go to: IAM Identity Center → Permission sets → Create permission set.
Create separate permission sets for each role:
| Permission set | Policy | Session duration |
|---|---|---|
| Developers | PowerUserAccess or custom policy | 8 hours |
| Security team | SecurityAudit + ReadOnlyAccess | 4 hours |
| Administrators | AdministratorAccess | 1 hour |
| Read-only analysts | ReadOnlyAccess | 8 hours |
Step 4: Assign Users and Groups to Accounts
Go to: IAM Identity Center → AWS accounts → Select account → Assign users and groups.
Assign groups, not individual users, to accounts. This makes permission handling easier when team members change roles or leave.
Each group should match a business role: Developers, Security, Finance, Operations. Assign only the permission set appropriate for that role.
Set Up AWS Verified Access for Application Access Without a VPN
AWS Verified Access controls access to internal applications such as internal dashboards, admin tools, databases, and development setups based on verified user identity and device posture. Users connect directly without needing a VPN.
This mirrors how Conditional Access Policies control access to Microsoft 365 apps. The difference is that Verified Access applies at the application level inside AWS, evaluating identity and device health before each connection.
Step 1: Create a Verified Access Instance
Go to: AWS Console → VPC → Verified Access → Instances → Create Verified Access instance.
The instance is the central point that handles authentication and policy control for all applications you protect.
Step 2: Connect an Identity Provider
Go to: Verified Access Instance → Trust providers → Add trust provider.
Select your identity provider:
| Identity provider | When to use |
|---|---|
| IAM Identity Center | Recommended if you completed the IAM Identity Center setup above |
| OIDC provider | For Okta, Google Workspace, or other OIDC-compatible providers |
Connecting IAM Identity Center uses the same user identities that control AWS account access also control application access, maintaining verification at every layer.
Step 3: Set Up Device Posture Checks
Go to: Verified Access Instance → Trust providers → Add trust provider → Device trust provider.
Supported device management services:
| Service | Best suited for |
|---|---|
| Jamf | macOS and iOS devices |
| CrowdStrike Falcon | Windows and macOS devices |
| Microsoft Intune | Mixed device setups |
After connecting, you can require conditions such as:
- Device is enrolled and managed
- OS version meets the minimum requirement
- Antivirus or endpoint protection is active
- Disk encryption is enabled
Step 4: Create a Verified Access Group
Go to: Verified Access → Groups → Create group.
A group sets the access policy applied to a set of applications. Write the policy using Cedar policy language.
Example – allow access only when the user is authenticated and the device is managed:
permit(principal, action, resource)
when {
context.identity.sub != "" &&
context.device.managed == true
};Step 3: Create Verified Access Endpoints
A Verified Access endpoint is the protected entry point for each application.
Go to: Verified Access → Endpoints → Create endpoint.
| Setting | Setup Value |
|---|---|
| Endpoint type | Application Load Balancer or Network Interface |
| Target | Your internal application’s load balancer or EC2 instance |
| Verified Access group | Select the group created above |
| Protocol | HTTPS for web apps, TCP for non-HTTP resources |
For non-HTTP resources including RDS databases, SSH connections, or RDP sessions, select the TCP endpoint type. This applies Zero Trust access to database administrators and DevOps teams without requiring a VPN or bastion host.
Enable Amazon GuardDuty for Continuous Threat Detection
IAM Identity Center and Verified Access control access to AWS resources and applications. GuardDuty monitors activity after access is granted. It continuously monitors AWS activity and detects threats that access controls cannot always prevent, including the misuse of stolen credentials during a legitimate session or unusual API activity that may indicate an active security incident.
Step 1: Enable GuardDuty
Go to: AWS Console → GuardDuty → Get started → Enable GuardDuty.
Enable it in every AWS Region you use. GuardDuty runs separately in each Region, so any Region that is not monitored can become a blind spot, even if you do not currently run workloads there. Attackers sometimes target inactive Regions because monitoring may be overlooked.
If you use AWS Organizations, enable GuardDuty from the management account and set it as the GuardDuty administrator account. This centralizes findings from all member accounts into a single view.
GuardDuty Extended Threat Detection is automatically enabled at no additional cost once GuardDuty is active.
Step 2: Enable Protection Plans
GuardDuty’s foundational detection covers CloudTrail logs, DNS logs, and VPC Flow Logs. Additional protection plans extend coverage to specific services.
Go to: GuardDuty → Protection plans.
| Protection plan | What it monitors | Recommended for |
|---|---|---|
| S3 Protection | S3 bucket activity and access patterns | All organizations using S3 |
| EKS Protection | Kubernetes audit logs and runtime behavior | Organizations running EKS |
| Runtime Monitoring (EC2) | OS-level process and network activity | Organizations running EC2 workloads |
| RDS Protection | Login anomalies on RDS databases | Organizations using RDS |
| Lambda Protection | Unusual Lambda function behavior | Organizations using serverless workloads |
| Malware Protection | Scans EBS volumes and S3 objects | All organizations |
Step 3: Understand GuardDuty Extended Threat Detection
GuardDuty Extended Threat Detection uses AI and ML to connect multiple security signals from different AWS services, time periods, and accounts. Instead of generating dozens of individual alerts, it identifies the complete attack path and presents it as a single high-severity finding.
It analyzes network activity, process runtime behaviour, malware execution, and AWS API activity over extended periods to identify attack patterns that individual alerts may not reveal.
Common attack patterns it detects:
| Attack sequence | What GuardDuty identifies |
|---|---|
| Credential compromise + data exfiltration | IAM credential stolen → S3 enumeration → bulk download of sensitive files |
| Container compromise | Suspicious container deployment → persistence attempt → crypto mining → reverse shell |
| EC2 instance compromise | Unusual process execution → lateral movement → command-and-control connection |
| Privilege escalation | API calls to modify IAM policies → assume high-privilege role → access sensitive resources |
Each finding includes an incident summary, a detailed event timeline, MITRE ATT&CK mapping, and remediation steps.
Step 4: Set Up Automated Alerts
GuardDuty findings are displayed in the AWS Management Console, but for faster response, route them to your team automatically.
Set Up Automated Alerts
It analyzes network activity, process runtime behaviour, malware execution, and AWS API activity over extended periods to identify attack patterns that individual alerts may not reveal.
Go to: Amazon EventBridge → Rules → Create rule.
Set the event source to GuardDuty findings and route by severity:
| Severity | Route to |
|---|---|
| Critical (attack sequences) | SNS → immediate email or SMS alert |
| High | AWS Security Hub + team notification |
| Medium | Security Hub for weekly review |
Common GuardDuty Threat Signals
GuardDuty detects over 100 finding types. These are some of the most relevant for organizations implementing a Zero Trust security model:
| Finding | What it means |
|---|---|
| UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B | Successful console login from an unusual location |
| CredentialAccess:IAMUser/AnomalousBehavior | IAM credentials used in an unusual pattern |
| Recon:IAMUser/MaliciousIPCaller | API calls from a known malicious IP address |
| Impact:S3/AnomalousBehavior | Unusual S3 access pattern suggesting data exfiltration |
| Execution:EC2/SuspiciousTool | Known attack tool or crypto miner running on EC2 |
| AttackSequence:IAM/CompromisedCredentials | Full credential compromise and exfiltration sequence |
How These Services Create a Zero Trust Security Model?
The three services cover the three stages of Zero Trust: verify before access, control what is accessed, and monitor after access is granted.
| Stage | Service | What it does |
|---|---|---|
| Verify identity | IAM Identity Center | Authenticates users and assigns time-limited role-based permissions |
| Control access | AWS Verified Access | Checks identity and device posture before granting access to each application |
| Detect threats | GuardDuty + Extended Threat Detection | Monitors all activity and identifies complete attack paths involving multiple AWS services |
A sign-in attempt is processed through IAM Identity Center first. If the user is authenticated and their permission set is valid, they can access the AWS console or applications protected by Verified Access. GuardDuty monitors all activity after that point, detecting suspicious behaviour, unauthorized access attempts, or data exfiltration, and combining related events into a single actionable finding.
The next stage after this setup includes implementing MFA for all users, applying Service Control Policies (SCPs), removing long-term credentials, and maintaining these controls as your AWS accounts and resources expand.
AWS Zero Trust Security with Netstager Technologies
Setting up IAM Identity Center, Verified Access, and GuardDuty individually is manageable. Keeping them aligned as your AWS accounts, applications, and teams expand requires ongoing attention.
In most cases, issues appear after the initial setup: permission sets with excessive access, Verified Access endpoints added without proper policies, GuardDuty findings that have not been reviewed, or access keys that remain active longer than intended. These gaps are not always visible until something goes wrong.
After Setup: What Needs Regular Review
- Permission drift – Users can accumulate access over time. Permission sets assigned during onboarding may provide more access than necessary later.
- Unused access keys – Long-term IAM credentials that are no longer being used remain a risk until they are explicitly disabled.
- New applications – Each new internal application should be added to Verified Access with a reviewed policy rather than being accessible through open network rules.
- GuardDuty findings backlog – Findings that are not reviewed can accumulate, making it harder to identify genuine threats.
- AWS account sprawl – New accounts added to AWS Organizations should have GuardDuty and IAM Identity Center enabled before they are used.
- Regulatory changes – GDPR, HIPAA, or local data protection requirements can influence how access controls and logs are managed.
Netstager Technologies, an AWS Partner in Kerala, provides AWS security implementation services including IAM Identity Center, AWS Verified Access, GuardDuty, and Zero Trust access controls.
Our AWS Zero Trust Service Includes
|
Security Baseline Assessment
Review of your existing AWS accounts, IAM users, active permissions, long-term access keys, and current GuardDuty status to identify security gaps before implementing additional controls.
|
|
IAM Identity Center Setup and Migration
Setup of IAM Identity Center with your identity provider, creation of permission sets aligned to your team structure, and migration from direct IAM users to role-based access.
|
|
Verified Access Deployment
Setup of Verified Access instances, identity and device trust providers, access group policies, and endpoints for internal applications, replacing VPN access or open security group rules.
|
|
GuardDuty Configuration and Alerting
Enabling GuardDuty in all active Regions and accounts, activating relevant protection plans, and setting up automated alerts for critical and high-severity findings.
|
|
Cross-Platform Identity Alignment
For organizations using Microsoft 365 and AWS together, Microsoft Entra ID can be connected as the identity source for both platforms so the same users, groups, and MFA policies are used on both platforms.
|
|
Ongoing Monitoring and Review
Review of GuardDuty findings, IAM access activity, Verified Access logs, and permission sets, with updates as teams, applications, and AWS accounts change.
|
To start, review, or maintain your AWS security setup, connect with Netstager Technologies.
