VPN

AWS Verified Access – Zero Trust Application Access

~ Last updated on : ~ Kiro Agent ~ Leave a comment

AWS Verified Access – Zero Trust Application Access

AWS Verified Access provides secure access to corporate applications and resources without requiring a virtual private network (VPN). It implements Zero Trust security principles by evaluating each access request in real time against fine-grained policies based on user identity and device security posture, ensuring that only authenticated and authorized users on compliant devices can reach your applications.

📢 Key Updates (2024–2025):

  • December 2024: Non-HTTP(S) protocol support (SSH, RDP, TCP) launched in preview
  • February 2025: Non-HTTP(S) support became generally available
  • March 2025: Achieved FedRAMP High and Moderate authorization
  • 2025: RDS endpoint type added for direct database access
  • 2025: Network CIDR endpoint type for IP-range-based access
  • 2025: AWS Connectivity Client for non-HTTP resources
AWS Verified Access — Zero Trust Flow
User
(Browser/Device)
→
Verified Access
1. Check Identity (Okta/IdC)
2. Check Device (CrowdStrike)
3. Evaluate Cedar Policy
→ Allow/Deny →
Application
(ALB / NI / RDS)
❌ No VPN needed • Per-request evaluation • Never trust, always verify

Zero Trust Principles

AWS Verified Access is built on the “never trust, always verify” model. Traditional perimeter-based security grants broad network access once a user connects via VPN. Zero Trust eliminates implicit trust by:

  • Verifying every request: Each application access request is evaluated independently — no persistent trust based on network location
  • Least-privilege access: Users get access only to specific applications they need, not the entire network
  • Continuous validation: Identity and device posture are checked on every request, not just at initial connection
  • Assume breach: The architecture limits lateral movement — compromising one application doesn’t grant access to others
  • Context-aware decisions: Access decisions combine multiple signals: user identity, group membership, device health, and security posture

Architecture Components

AWS Verified Access consists of four core components that work together to enforce zero trust access:

Verified Access Instance

  • The top-level container that evaluates access requests and enforces policies
  • Each instance is associated with one or more trust providers
  • Supports AWS WAF integration for additional web security (SQL injection, XSS protection)
  • Logging is configured at the instance level (S3, CloudWatch Logs, Kinesis Data Firehose)
  • Can be shared across AWS accounts using AWS Resource Access Manager (RAM)

Verified Access Trust Providers

  • External services that supply user identity and device security posture data
  • Two categories: Identity trust providers (who the user is) and Device trust providers (device health status)
  • Each Verified Access instance can have one identity provider and multiple device trust providers
  • Trust data is passed to Cedar policies for access evaluation

Verified Access Groups

  • Logical groupings of endpoints with similar security requirements
  • Group-level access policies apply to all endpoints in the group
  • Simplifies policy management — define once, apply to many applications
  • Each group is associated with a Verified Access instance

Verified Access Endpoints

  • Represent individual applications or resources that users access
  • Each endpoint belongs to a Verified Access group and inherits its policy
  • Optional endpoint-level policy for additional application-specific controls
  • Four endpoint types:
    • Load Balancer: Routes requests to ALB or NLB for application distribution
    • Network Interface: Sends requests to a specific ENI with protocol and port
    • Network CIDR: Routes requests to a specified IP address range
    • Amazon RDS: Provides access to RDS instances, clusters, or DB proxies

How AWS Verified Access Works

AWS Verified Access evaluates every access request using a combination of user identity verification and device posture assessment, eliminating the need for a VPN:

  1. User requests access to a corporate application via its Verified Access endpoint URL (e.g., app.example.com)
  2. Authentication: The user is redirected to the configured identity provider (IAM Identity Center or OIDC-compatible IdP) for authentication
  3. Device posture check: The device trust provider assesses the device’s security state (OS patch level, firewall status, disk encryption, malware protection)
  4. Policy evaluation: Verified Access evaluates Cedar policies using the identity and device trust data against group-level and endpoint-level policies
  5. Access decision: If both policies return Allow, the request is forwarded to the application; otherwise, access is denied
  6. Logging: Every access attempt (allowed or denied) is logged for audit and security analysis

For non-HTTP(S) applications (SSH, RDP, TCP), users install the AWS Verified Access Connectivity Client on their devices. The client encrypts traffic, attaches user identity and device context, and routes it to Verified Access for policy enforcement before forwarding to the target resource.

Trust Providers

Identity Trust Providers

Identity trust providers authenticate users and supply identity claims (email, groups, roles) to Cedar policies:

Provider Type Details
AWS IAM Identity Center Native Direct integration; supports SAML 2.0 federation with external IdPs; provides user/group attributes
Okta OIDC OpenID Connect integration; supplies user identity, group membership, and custom claims
Ping Identity OIDC OpenID Connect integration; enterprise identity verification and SSO
Any OIDC Provider OIDC Any standards-compliant OIDC identity provider (Azure AD, Google Workspace, Auth0, etc.)

Device Trust Providers

Device trust providers assess the security posture of the user’s device and provide device health signals:

Provider Supported Platforms Trust Signals
CrowdStrike Windows 10, Windows 11 Zero Trust Assessment (ZTA) score, OS version, sensor status, policy compliance
Jamf macOS Device compliance, risk score, OS patch level, FileVault encryption, firewall status
JumpCloud Windows, macOS Device compliance status, disk encryption, OS version, screen lock, firewall
💡 Important: You can configure one identity trust provider and multiple device trust providers per Verified Access instance. Verified Access currently supports Google Chrome and Mozilla Firefox browsers for device trust context collection.

Cedar Policy Language

Access policies in AWS Verified Access are written in Cedar, an open-source policy language developed by AWS. Cedar provides:

  • Human-readable syntax: Policies resemble natural language — easy to write and audit
  • Provably correct evaluation: Uses automated reasoning to ensure deterministic results
  • RBAC and ABAC support: Role-based and attribute-based access control in a single policy
  • Principal/Action/Resource model: Defines who can do what on which resource under which conditions

Example Cedar Policy — Allow engineering team on compliant devices:

Example Cedar Policy — Deny access from non-compliant devices:

Integration with Application Load Balancer (ALB)

AWS Verified Access integrates with Application Load Balancers as a primary endpoint type for HTTP(S) applications:

  • Load Balancer endpoint type: Verified Access forwards authenticated and authorized requests to an internal ALB or NLB
  • No public exposure needed: The ALB remains in a private subnet — only Verified Access endpoints are internet-facing
  • Health checks maintained: ALB continues to perform health checks on target applications
  • WAF at both layers: AWS WAF can be attached to both the Verified Access instance and the ALB for defense-in-depth
  • Signed identity headers: Verified Access injects signed user identity information into HTTP headers forwarded to the ALB, allowing applications to identify the authenticated user without separate authentication logic
  • On-premises applications: By pointing a Verified Access endpoint at an NLB with IP targets, you can provide zero trust access to on-premises applications connected via Direct Connect or VPN

Architecture Pattern: Verified Access + ALB

AWS WAF Integration

  • Associate an AWS WAF Web ACL with a Verified Access instance for additional protection
  • Provides protection against common exploits: SQL injection, XSS, known bad IPs
  • With IAM Identity Center: WAF inspects traffic before user authentication
  • With OIDC providers: WAF inspects traffic after user authentication
  • Rate limiting and geo-blocking rules apply at the Verified Access level

Use Cases

1. Replacing Traditional VPN

  • Eliminate VPN infrastructure management, licensing costs, and scalability issues
  • Remove broad network access — users access only the applications they need
  • Reduce VPN-related support tickets (connectivity issues, split tunneling, performance)
  • No client software needed for HTTP(S) applications (browser-only access)
  • Gradual migration: run Verified Access alongside Client VPN during transition

2. BYOD (Bring Your Own Device) Access

  • Enable personal device access to corporate applications without VPN tunnel to corporate network
  • Device trust providers verify minimum security posture (encryption, patches, antivirus)
  • Conditional access: allow browser-based apps from BYOD but restrict sensitive resources to managed devices
  • No corporate certificates or VPN profiles needed on personal devices

3. Contractor and Third-Party Access

  • Grant time-limited, application-specific access to external contractors
  • Federate contractor identities through OIDC without creating AWS or corporate accounts
  • Apply stricter device posture requirements or limit to specific applications
  • Easy revocation: update group policy or remove contractor from IdP group

4. Multi-Account Application Access

  • Share Verified Access instances across accounts using AWS Resource Access Manager
  • Centralize access policies while applications remain in separate AWS accounts
  • Consistent security posture across organizational units

5. Securing Non-HTTP Resources

  • Provide zero trust access to SSH sessions, RDP desktops, and TCP-based applications
  • Uses AWS Verified Access Connectivity Client on user devices
  • Supports access to RDS databases without exposing them publicly
  • Apply same identity and device trust policies to infrastructure access

AWS Verified Access vs Client VPN vs Direct Connect vs PrivateLink

Feature Verified Access AWS Client VPN AWS Direct Connect AWS PrivateLink
Primary Purpose Zero trust application access without VPN Remote user VPN connectivity to VPC Dedicated private network connection from on-premises Private connectivity between VPCs and services
Access Model Per-application, per-request Network-level (full VPC access via tunnel) Network-level (Layer 2/3) Service-specific (endpoint to service)
Client Required No (browser for HTTP); Yes (Connectivity Client for non-HTTP) Yes (OpenVPN-compatible client) No (hardware router at on-premises) No
Identity Verification Every request (IdP + device posture) At connection time (certificate + optional MFA) None (network-level only) None (relies on VPC security)
Device Posture Yes (CrowdStrike, Jamf, JumpCloud) No No No
Zero Trust Yes — core design principle No — perimeter-based once connected No — dedicated circuit Partial — limits service exposure
Lateral Movement Risk Minimal (app-level isolation) High (VPC network access) Medium (depends on routing) Low (service-specific)
Protocol Support HTTP(S), SSH, RDP, TCP All TCP/UDP (tunnel) All protocols (Layer 2/3) TCP (NLB-based)
Scalability Fully managed, auto-scales Scales with VPN endpoints Fixed bandwidth (1/10/100 Gbps) Scales automatically
Best For Remote workforce, BYOD, contractors, zero trust Full network access for remote employees Hybrid cloud, high-bandwidth on-premises connectivity Service-to-service private connectivity, SaaS delivery

Pricing

AWS Verified Access uses a pay-as-you-go model with no upfront commitment or minimum fees:

HTTP(S) Applications

Dimension Rate (US East – Ohio)
Application hours (first 200 apps × 744 hrs) $0.27 per app-hour
Application hours (above 148,800 app-hours/month) $0.20 per app-hour
Data processed $0.02 per GB

Non-HTTP(S) Applications

Dimension Rate (US East – Ohio)
Non-HTTP endpoint hours $0.20 per endpoint-hour
Connections (above 100 free per endpoint/hour) $0.001 per connection-hour
💰 Cost Example: 10 HTTP(S) applications running 24/7 for a month with 5 GB total data processed: (10 × 744 × $0.27) + (5 × $0.02) = $2,008.90/month. Additional standard AWS data transfer charges apply.

Logging and Observability

AWS Verified Access logs every access attempt (both allowed and denied), providing centralized visibility for security audits and incident response:

Log Destinations

  • Amazon S3: Long-term archival, Athena queries, and compliance retention
  • Amazon CloudWatch Logs: Real-time monitoring, alarms, and dashboards
  • Amazon Kinesis Data Firehose: Stream to SIEM tools, Splunk, Datadog, or OpenSearch

Log Contents

  • Timestamp and request ID
  • Source IP address and port
  • Verified Access instance, group, and endpoint IDs
  • Access decision (Allow or Deny)
  • User identity information (from trust provider)
  • Device trust data (optionally included)
  • HTTP method, URI, status code (for HTTP requests)
  • Policy evaluation details
💡 Tip: Enable trust data inclusion in logs to capture the full identity and device context for each request. This aids forensic investigation but increases log volume and storage costs.

AWS Certification Exam Relevance

Exam Relevance Key Topics
AWS Security Specialty (SCS-C02) ⭐⭐⭐ High Zero trust architecture, identity-based access, device posture, policy evaluation, WAF integration, logging for compliance
Solutions Architect Professional (SAP-C02) ⭐⭐⭐ High VPN replacement patterns, hybrid access architecture, multi-account access, choosing between connectivity options
Solutions Architect Associate (SAA-C03) ⭐⭐ Medium Understanding when to use Verified Access vs VPN vs PrivateLink; basic zero trust concepts
Advanced Networking Specialty (ANS-C01) ⭐⭐⭐ High Endpoint types, ALB/NLB integration, DNS configuration, non-HTTP protocol support, Network Firewall integration

AWS Verified Access Practice Questions

  1. A company wants to provide secure access to internal web applications for remote employees without deploying VPN infrastructure. They require per-request identity verification and device compliance checks. Which AWS service should they use?

    1. AWS Client VPN with MFA
    2. AWS PrivateLink with VPC endpoints
    3. AWS Verified Access
    4. Amazon CloudFront with signed URLs
    Show Answer

    Answer: C –

    Explanation: AWS Verified Access provides secure application access without VPN by evaluating each request against identity and device posture policies. Client VPN provides network-level access, not per-application zero trust. PrivateLink is for service-to-service connectivity within AWS. CloudFront signed URLs don’t provide identity/device verification.

  2. An organization is configuring AWS Verified Access and needs to enforce that users can only access applications from devices with disk encryption enabled and an up-to-date OS. Which combination of trust providers should they configure? (Choose TWO)

    1. AWS IAM Identity Center as an identity trust provider
    2. CrowdStrike as a device trust provider
    3. Amazon Cognito as an identity trust provider
    4. AWS Config as a device trust provider
    5. Amazon Inspector as a device posture provider
    Show Answer

    Answer: A, B

    Explanation: Verified Access requires an identity trust provider (IAM Identity Center or OIDC) and a device trust provider (CrowdStrike, Jamf, or JumpCloud). CrowdStrike provides device posture signals including disk encryption and OS version. Amazon Cognito, AWS Config, and Inspector are not supported as Verified Access trust providers.

  3. A security engineer is writing a Cedar policy for AWS Verified Access that should allow access only to users in the “finance” group who have a CrowdStrike ZTA assessment of “pass”. Which policy correctly implements this requirement?

    1. allow(principal in Group::"finance", action, resource) when { context.device.crowdstrike.overall_assessment == "pass" };
    2. permit(principal, action, resource) when { context.identity.groups.contains("finance") && context.device.crowdstrike.overall_assessment == "pass" };
    3. grant(principal, action, resource) when { identity.group == "finance" AND device.assessment == "pass" };
    4. permit(principal, action, resource) when { context.identity.email.endsWith("@finance.com") };
    Show Answer

    Answer: B –

    Explanation: Cedar policies use permit or forbid keywords (not “allow” or “grant”). The trust data is accessed via the context object, with identity data under context.identity and device data under context.device.[provider]. Option B correctly checks both group membership and device assessment.

  4. A company currently uses AWS Client VPN but wants to migrate to AWS Verified Access for their web applications. During the transition, they need to maintain access for applications that use SSH and RDP. What should the solutions architect recommend?

    1. Use Verified Access for all applications immediately — it supports all protocols
    2. Use Verified Access for HTTP(S) applications and deploy the AWS Verified Access Connectivity Client for SSH/RDP access to non-HTTP endpoints
    3. Continue using Client VPN for SSH/RDP; Verified Access only supports HTTP(S)
    4. Use AWS Systems Manager Session Manager for SSH/RDP and Verified Access for HTTP(S) only
    Show Answer

    Answer: B –

    Explanation: Since February 2025, AWS Verified Access supports non-HTTP(S) protocols (SSH, RDP, TCP) through the AWS Verified Access Connectivity Client. Users install the client on their devices to access non-HTTP resources with the same zero trust policy enforcement. This eliminates the need for Client VPN for these protocols.

  5. An organization needs to log all Verified Access requests for compliance auditing, including the identity claims and device posture data used in each access decision. Where can they send these logs? (Choose THREE)

    1. Amazon S3
    2. Amazon CloudWatch Logs
    3. Amazon Kinesis Data Firehose
    4. AWS CloudTrail
    5. Amazon DynamoDB
    6. Amazon SQS
    Show Answer

    Answer: A, B, C

    Explanation: AWS Verified Access supports three log destinations: Amazon S3, CloudWatch Logs, and Kinesis Data Firehose. Trust data (identity and device context) can optionally be included in these logs. CloudTrail records API calls for Verified Access management operations but does not capture per-request access logs. DynamoDB and SQS are not supported log destinations.

Frequently Asked Questions

What is AWS Verified Access?

AWS Verified Access provides secure access to corporate applications without a VPN. It evaluates each request against identity and device posture policies using Cedar policy language, following zero trust principles of ‘never trust, always verify’.

How does Verified Access replace VPN?

Instead of granting broad network access via VPN, Verified Access grants per-application access based on user identity and device security posture. Users connect directly to applications through their browser without installing VPN clients.

What trust providers does Verified Access support?

For identity: IAM Identity Center, Okta, Ping Identity, and any OIDC provider. For device posture: CrowdStrike, Jamf, and JumpCloud. You can combine identity + device trust for stronger security.

Related Posts

References

AWS Cloud Migration Services – 7R Strategies

~ Last updated on : ~ jayendrapatil ~ 6 Comments

🔄 MAJOR UPDATE NOTICE – June 2026

The AWS migration services landscape has undergone significant changes:

  • AWS Migration Hub – No longer accepting new customers (Nov 2025). Replaced by AWS Transform.
  • AWS Application Discovery Service – No longer accepting new customers (Nov 2025). Replaced by AWS Transform.
  • AWS Server Migration Service (SMS) – Discontinued (March 2022). Replaced by AWS Transform MGN.
  • AWS Application Migration Service (MGN) – Rebranded to AWS Transform MGN (June 2026).
  • AWS Snowmobile – Retired (March 2024).
  • AWS Snowball Edge – Only available to existing customers (Nov 2025). New customers should use AWS DataSync or AWS Data Transfer Terminal.

See new sections below for AWS Transform, AWS DataSync, AWS Data Transfer Terminal, and AWS Interconnect.

AWS Cloud Migration Services

  • AWS Cloud Migration services help to address a lot of common use cases such as
    • cloud migration,
    • disaster recovery,
    • data center decommission, and
    • content distribution.
  • For migrating data from on-premises to AWS, the major aspect for consideration are
    • amount of data and network speed
    • data security in transit
    • existing application knowledge for recreation

Application & Database Cloud Migration Services

AWS Transform

  • is the next-generation migration and modernization service launched in May 2025, replacing AWS Migration Hub and integrating multiple migration capabilities into a unified platform.
  • uses agentic AI to automate discovery, dependency mapping, migration planning, network conversion, and EC2 instance optimization.
  • accelerates full-stack Windows modernization, mainframe modernization, and VMware migration.
  • provides a unified experience that consolidates capabilities previously spread across Migration Hub, Application Discovery Service, and Application Migration Service.
  • generates migration plans for tens of thousands of servers and applications in hours.
  • automatically creates or updates landing zones, modernizes and right-sizes networks, and containerizes applications during migration.
  • supports custom transformations of code, APIs, frameworks, and more—making tech stacks AI-ready while eliminating technical debt.
  • Key capabilities include:
    • AWS Transform for VMware – Automates VMware-to-AWS migration with dependency mapping, wave planning, and network configuration conversions.
    • AWS Transform MGN (formerly Application Migration Service) – Proven replication engine for lift-and-shift migrations.
    • Strategy Recommendations – AI-driven migration and modernization strategy building.
    • EC2 Instance Recommendations – Cost estimation for running existing servers in AWS.
    • Migration Journeys – Prescriptive guided migration and modernization workflows.

AWS Transform MGN (formerly AWS Application Migration Service)

  • is the primary migration service for lift-and-shift migrations to AWS (rebranded from AWS Application Migration Service in June 2026).
  • simplifies migration by allowing the same automated process for a wide range of applications, without changes to applications, their architecture, or the migrated servers.
  • supports non-disruptive tests prior to cutover.
  • performs continuous block-level replication of source servers to AWS.
  • supports migration from physical, virtual, or cloud servers to AWS.
  • replaces both AWS Server Migration Service (SMS) and CloudEndure Migration.
  • is used to Re-host (lift-and-shift).

AWS Migration Hub (Maintenance Mode)

⚠️ Note: AWS Migration Hub stopped accepting new customers on November 7, 2025. Existing customers can continue using the service. New customers should use AWS Transform.

  • provides a centralized, single place to discover the existing servers, plan migrations, and track the status of each application migration.
  • provides visibility into the application portfolio and streamlines planning and tracking.
  • helps visualize the connections and the status of the migrating servers and databases, regardless of which migration tool is used.
  • stores all the data in the selected Home Region and provides a single repository of discovery and migration planning information for the entire portfolio and a single view of migrations into multiple AWS Regions.
  • helps track the status of the migrations in all AWS Regions, provided the migration tools are available in that Region.
  • helps understand the environment by letting you explore information collected by AWS discovery tools and stored in the AWS Application Discovery Service’s repository.
  • supports migration status updates from the following tools:
  • migration tools send migration status to the selected Home Region
  • supports EC2 instance recommendations, that provide you with the ability to estimate the cost of running the existing servers in AWS.
  • supports Strategy Recommendations, that help easily build a migration and modernization strategy for the applications running on-premises or in AWS.
  • All current Migration Hub features, including Strategy Recommendations, EC2 Instance Recommendations, Migration Hub Journeys, and Orchestrator, are available in AWS Transform with improved functionality.

AWS Application Discovery Service (Maintenance Mode)

⚠️ Note: AWS Application Discovery Service stopped accepting new customers on November 7, 2025. The Discovery Connector was deprecated on November 17, 2025. New customers should use AWS Transform for VM discovery and assessment.

  • AWS Application Discovery Service helps plan migration to the AWS cloud by collecting usage and configuration data about the on-premises servers.
  • helps enterprises obtain a snapshot of the current state of their data center servers by collecting server specification information, hardware configuration, performance data, details of running processes, and network connections
  • is integrated with AWS Migration Hub,
    • which simplifies migration tracking as it aggregates migration status information into a single console.
    • can help view the discovered servers, group them into applications, and then track the migration status of each application.
  • discovered data for all the regions is stored in the AWS Migration Hub home Region.
  • The data can be exported for analysis in Microsoft Excel or AWS analysis tools such as Amazon Athena and Amazon QuickSight.
  • supports Agentless Collector (for VMware environments) and Discovery Agent (for all environments) for performing discovery and collecting data about the on-premises servers.
  • Note: The Discovery Connector (agentless, vCenter-based) was deprecated on November 17, 2025. The Agentless Collector (supports network connection discovery since November 2024) remains available for existing customers.

AWS Server Migration Service (SMS)

⚠️ DEPRECATED: AWS Server Migration Service was discontinued on March 31, 2022. Use AWS Transform MGN (formerly Application Migration Service) for all lift-and-shift migrations.

  • was an agentless service that made it easier and faster to migrate thousands of on-premises workloads to AWS.
  • helped automate, schedule, and track incremental replications of live server volumes, making it easier to coordinate large-scale server migrations.
  • supported migration of virtual machines from VMware vSphere, Windows Hyper-V and Azure VM to AWS.
  • replicated each server volume, which was saved as a new AMI, which could be launched as an EC2 instance.
  • was a significant enhancement of EC2 VM Import/Export service.
  • was used to Re-host.
  • Migration Path: Use AWS Transform MGN, which supports physical, virtual, and cloud servers with continuous block-level replication and non-disruptive testing.

AWS Database Migration Service (DMS)

  • helps migrate databases to AWS quickly and securely.
  • source database remains fully operational during the migration, minimizing downtime to applications that rely on the database.
  • supports homogeneous migrations such as Oracle to Oracle, as well as heterogeneous migrations between different database platforms, such as Oracle or Microsoft SQL Server to Amazon Aurora.
  • monitors for replication tasks, network or host failures, and automatically provisions a host replacement in case of failures that can’t be repaired
  • supports both one-time data migration into RDS and EC2-based databases as well as for continuous data replication
  • supports continuous replication of the data with high availability and consolidate databases into a petabyte-scale data warehouse by streaming data to Amazon Redshift and Amazon S3
  • provides free AWS Schema Conversion Tool (SCT) that automates the conversion of Oracle PL/SQL and SQL Server T-SQL code to equivalent code in the Amazon Aurora / MySQL dialect of SQL or the equivalent PL/pgSQL code in PostgreSQL
  • AWS DMS Serverless (launched June 2023)
    • automatically provisions, scales, and manages migration resources without infrastructure management.
    • removes the need for capacity estimation, provisioning, cost-optimization, and version/patch management.
    • supports automatic storage scaling beyond the default 100GB limit for large transaction volumes.
    • supports S3 source endpoints for migrating CSV or Parquet data.
    • supports homogeneous migrations via CLI, SDK, and API with fully automated replication (October 2024).
    • supports premigration assessments to identify potential issues before migration.
  • Note: AWS DMS Fleet Advisor reaches end of support on May 20, 2026.

AWS EC2 VM Import/Export

  • allows easy import of virtual machine images from existing environment to EC2 instances and export them back to on-premises environment
  • allows leveraging of existing investments in the virtual machines, built to meet compliance requirements, configuration management and IT security by bringing those virtual machines into EC2 as ready-to-use instances
  • Common usages include
    • Migrate Existing Applications and Workloads to EC2, allowing preserving of the software and settings configured in the existing VMs.
    • Copy Your VM Image Catalog to EC2
    • Create a Disaster Recovery Repository for your VM images
  • Note: For server migrations, AWS Transform MGN is the recommended service as it provides continuous replication, non-disruptive testing, and automated cutover. VM Import/Export remains available for specific image import/export use cases.

Data Transfer Services

VPN

  • connection utilizes IPSec to establish encrypted network connectivity between on-premises network and VPC over the Internet.
  • connections can be configured in minutes and a good solution for an immediate need, have low to modest bandwidth requirements, and can tolerate the inherent variability in Internet-based connectivity.
  • still requires internet and be configured using VGW and CGW

AWS Direct Connect

  • provides a dedicated physical connection between the corporate network and AWS Direct Connect location with no data transfer over the Internet.
  • helps bypass Internet service providers (ISPs) in the network path
  • helps reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than with Internet-based connection
  • takes time to setup and involves third parties
  • are not redundant and would need another direct connect connection or a VPN connection
  • Security
    • provides a dedicated physical connection without internet
    • For additional security can be used with VPN
    • Supports MACsec (IEEE 802.1AE) encryption on dedicated connections and supported partner interconnects for Layer 2 encryption.
  • Recent Updates:
    • Native 400 Gbps Dedicated Connections available at select locations (July 2024).
    • Direct Connect gateway can now associate directly with AWS Cloud WAN core network without intermediate Transit Gateway (November 2024).
    • 4-byte Autonomous System (AS) number support for virtual interfaces (September 2025).

AWS Interconnect (NEW – GA April 2026)

  • is a managed connectivity service that simplifies connectivity into AWS, launched as GA in April 2026.
  • enables customers to establish private, high-speed network connections with dedicated bandwidth to and from AWS across hybrid and multicloud environments.
  • AWS Interconnect – Last Mile
    • automates the end-to-end process of establishing private, resilient connectivity between customer on-premises locations and AWS.
    • customers select their location, preferred AWS Region, and bandwidth speed—everything else is automated.
    • automates complex network configuration including BGP peering, VLAN configuration, and ASN assignment.
    • supports dynamic bandwidth scaling from 1 Gbps to 100 Gbps through the AWS console with zero downtime maintenance.
  • AWS Interconnect – Multicloud
    • enables private, secure connectivity between AWS VPCs and other cloud environments (e.g., Google Cloud).
    • uses pre-built capacity pools between AWS and partner cloud providers, eliminating physical cross-connect management.
    • connection can be established in minutes through a simple two-step creation and approval process.
  • simplifies what previously required Direct Connect setup with third-party coordination.

AWS Snow Family

⚠️ Availability Changes:

  • Snowmobile – Retired (March 2024).
  • Snowcone (HDD and SSD) – Discontinued (November 2024).
  • Previous-gen Snowball Edge devices (Storage Optimized 80TB, Compute Optimized 52 vCPU, Compute Optimized GPU) – Discontinued (November 2024).
  • Snowball Edge (latest generation) – Available to existing customers only (November 2025). New customers should use AWS DataSync for online transfers or AWS Data Transfer Terminal for physical transfers.
  • AWS Snowball Edge (latest generation)
    • is a petabyte-scale data transfer service built around a secure device that moves data into and out of the AWS Cloud quickly and efficiently.
    • transfers the data to S3 bucket.
    • transfer times are about a week from start to finish.
    • commonly used to ship terabytes or petabytes of analytics data, healthcare and life sciences data, video libraries, image repositories, backups, and archives as part of data center shutdown, tape replacement, or application migration projects.
    • contains embedded computing platform that helps perform simple processing tasks.
    • can be rack shelved and may also be clustered together, making it simpler to collect and store data in extremely remote locations.
    • commonly used in environments with intermittent connectivity (such as manufacturing, industrial, and transportation); or in extremely remote locations (such as military or maritime operations) before shipping them back to AWS data centers.
    • delivers serverless computing applications at the network edge using AWS Greengrass and Lambda functions.
    • Only available to existing customers as of November 7, 2025.
  • AWS Snowmobile (RETIRED)
    • Retired in March 2024. AWS no longer offers this service.
    • Previously moved up to 100PB of data in a 45-foot long ruggedized shipping container.
    • Was ideal for multi-petabyte or Exabyte-scale digital media migrations and datacenter shutdowns.
    • Alternatives: For large-scale transfers, use AWS Data Transfer Terminal or multiple Snowball Edge devices (existing customers), or AWS DataSync for online transfers.

AWS Import/Export (Legacy – Upgraded to Snowball)

  • accelerated moving large amounts of data into and out of AWS using secure Snowball appliances
  • AWS transferred the data directly onto and off of the storage devices using Amazon’s high-speed internal network, bypassing the Internet
  • Data Migration
    • for significant data size, AWS Import/Export was faster than Internet transfer and more cost-effective than upgrading the connectivity
    • if loading the data over the Internet would take a week or more, AWS Import/Export should be considered
    • data from appliances could be imported to S3, Glacier and EBS volumes and exported from S3
    • not suitable for applications that cannot tolerate offline transfer time
  • Security
    • Snowball uses an industry-standard Trusted Platform Module (TPM) that has a dedicated processor designed to detect any unauthorized modifications to the hardware, firmware, or software to physically secure the AWS Snowball device.
  • Note: With Snow Family availability changes, new customers should use AWS DataSync or AWS Data Transfer Terminal.

AWS DataSync (Recommended for Online Transfers)

  • is an online data movement service that simplifies and accelerates data migrations to AWS.
  • moves data quickly and securely between on-premises storage, edge locations, other cloud providers, and AWS Storage.
  • automates scheduling, monitoring, encryption, and end-to-end data validation.
  • recommended replacement for AWS Snow Family for new customers needing online data transfer.
  • Key Features:
    • Transfers file and object data between storage services.
    • Supports on-premises NFS, SMB, HDFS, self-managed object storage, AWS S3, EFS, FSx, and more.
    • Automatic encryption in-flight and end-to-end data integrity validation.
    • DataSync Discovery – Provides visibility into on-premises storage performance and utilization with migration recommendations.
    • Enhanced Mode (May 2025) – Supports cross-cloud transfers without requiring a DataSync agent, with higher performance and scalability.
  • Use Cases:
    • Online data migration to AWS Storage services.
    • Ongoing data replication between on-premises and cloud.
    • Cross-cloud data movement (AWS to/from other cloud providers).
    • Large-scale data migrations with automated scheduling.

AWS Data Transfer Terminal (NEW – December 2024)

  • are physical locations around the world where customers bring data storage devices and connect them to the AWS network for high-speed, secure data transfer.
  • recommended replacement for AWS Snow Family for new customers needing physical data transfer.
  • provides a secure, upload-ready, physical location—customers bring their own storage devices.
  • enables upload to any AWS endpoint including Amazon S3, Amazon EFS, or others using a high-throughput connection.
  • suited for data transfer or migration use cases where large amounts of data need to be transferred quickly.
  • customers can also bring Snowball Edge devices to these locations for upload.
  • Key Differences from Snow Family:
    • Customer brings their own storage devices (no AWS-provided appliance).
    • No shipping required—customer physically visits the terminal.
    • Direct connection to AWS high-speed network at the terminal location.
    • On-demand access without device ordering lead times.

AWS Storage Gateway

  • connects an on-premises software appliance with cloud-based storage to provide seamless and secure integration between an organization’s on-premises IT environment and the AWS storage infrastructure
  • provides low-latency performance by maintaining frequently accessed data on-premises while securely storing all of the data encrypted in S3 or Glacier.
  • for disaster recovery scenarios, Storage Gateway, together with EC2, can serve as a cloud-hosted solution that mirrors the entire production environment
  • Gateway Types:
    • S3 File Gateway – NFS/SMB access to S3 objects.
    • FSx File Gateway – Local cache for Windows-based file shares on FSx for Windows File Server. (No longer accepting new customers as of October 2024.)
    • Volume Gateway (Cached) – S3 holds primary data, frequently accessed data cached locally.
    • Volume Gateway (Stored) – Entire data stored locally, asynchronously backed up to S3.
    • Tape Gateway – iSCSI-based virtual tape library (VTL) for offline data archiving.
  • Security
    • Encrypts all data in transit to and from AWS by using SSL/TLS.
    • All data in AWS Storage Gateway is encrypted at rest using AES-256.
    • Authentication between the gateway and iSCSI initiators can be secured by using Challenge-Handshake Authentication Protocol (CHAP).
  • Recent Updates:
    • Migrating from Amazon Linux 2 to AL2023 (required before June 30, 2026 AL2 EOL).
    • IPv6 support for Storage Gateway endpoints, APIs, and appliance interfaces (September 2025).
    • Terraform modules support AL2023 with Elastic IP association for private activations (March 2026).

Simple Storage Service – S3

  • Data Transfer
    • Files up to 5GB can be transferred using single operation
    • Multipart uploads can be used to upload files up to 5 TB and speed up data uploads by dividing the file into multiple parts
    • transfer rate still limited by the network speed
    • S3 Transfer Acceleration uses CloudFront edge locations to accelerate uploads over long distances.
  • Security
    • Data in transit can be secured by using SSL/TLS or client-side encryption.
    • Encrypt data at-rest by performing server-side encryption using Amazon S3-Managed Keys (SSE-S3), AWS Key Management Service (KMS)-Managed Keys (SSE-KMS), or Customer Provided Keys (SSE-C). Or by performing client-side encryption using AWS KMS–Managed Customer Master Key (CMK) or Client-Side Master Key.
    • Note: SSE-S3 is now applied by default to all new objects (January 2023).

AWS Migration Strategy Summary

Use Case Recommended Service (2025+) Previous Service
Migration planning & discovery AWS Transform Migration Hub + Application Discovery Service
Lift-and-shift server migration AWS Transform MGN SMS → Application Migration Service
Database migration AWS DMS / DMS Serverless AWS DMS
Online data transfer AWS DataSync Snow Family / Storage Gateway
Physical bulk data transfer AWS Data Transfer Terminal Snow Family (Snowball/Snowmobile)
Private network connectivity AWS Direct Connect / AWS Interconnect AWS Direct Connect
Hybrid storage AWS Storage Gateway AWS Storage Gateway
VM image import VM Import/Export VM Import/Export

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your must architect the migration of a web application to AWS. The application consists of Linux web servers running a custom web server. You are required to save the logs generated from the application to a durable location. What options could you select to migrate the application to AWS? (Choose 2)
    1. Create an AWS Elastic Beanstalk application using the custom web server platform. Specify the web server executable and the application project and source files. Enable log file rotation to Amazon Simple Storage Service (S3). (EB does not work with Custom server executable)
    2. Create Dockerfile for the application. Create an AWS OpsWorks stack consisting of a custom layer. Create custom recipes to install Docker and to deploy your Docker container using the Dockerfile. Create custom recipes to install and configure the application to publish the logs to Amazon CloudWatch Logs (OpsWorks Stacks is now deprecated (EOL May 2024). Also, the last sentence mentions configure the application to push the logs to S3, which would need changes to application as it needs to use SDK or CLI)
    3. Create Dockerfile for the application. Create an AWS OpsWorks stack consisting of a Docker layer that uses the Dockerfile. Create custom recipes to install and configure Amazon Kinesis to publish the logs into Amazon CloudWatch. (Kinesis not needed, OpsWorks deprecated)
    4. Create a Dockerfile for the application. Create an AWS Elastic Beanstalk application using the Docker platform and the Dockerfile. Enable logging the Docker configuration to automatically publish the application logs. Enable log file rotation to Amazon S3. (Use Docker configuration with awslogs and EB with Docker)
    5. Use VM import/Export to import a virtual machine image of the server into AWS as an AMI. Create an Amazon Elastic Compute Cloud (EC2) instance from AMI, and install and configure the Amazon CloudWatch Logs agent. Create a new AMI from the instance. Create an AWS Elastic Beanstalk application using the AMI platform and the new AMI. (Use VM Import/Export to create AMI and CloudWatch logs agent to log)
  2. Your company hosts an on-premises legacy engineering application with 900GB of data shared via a central file server. The engineering data consists of thousands of individual files ranging in size from megabytes to multiple gigabytes. Engineers typically modify 5-10 percent of the files a day. Your CTO would like to migrate this application to AWS, but only if the application can be migrated over the weekend to minimize user downtime. You calculate that it will take a minimum of 48 hours to transfer 900GB of data using your company’s existing 45-Mbps Internet connection. After replicating the application’s environment in AWS, which option will allow you to move the application’s data to AWS without losing any data and within the given timeframe?
    1. Copy the data to Amazon S3 using multiple threads and multi-part upload for large files over the weekend, and work in parallel with your developers to reconfigure the replicated application environment to leverage Amazon S3 to serve the engineering files. (Still limited by 45 Mbps speed with minimum 48 hours when utilized to max)
    2. Sync the application data to Amazon S3 starting a week before the migration, on Friday morning perform a final sync, and copy the entire data set to your AWS file server after the sync completes. (Works best as the data changes can be propagated over the week and are fractional and downtime would be known. Note: AWS DataSync would be ideal for this use case today.)
    3. Copy the application data to a 1-TB USB drive on Friday and immediately send overnight, with Saturday delivery, the USB drive to AWS Import/Export to be imported as an EBS volume, mount the resulting EBS volume to your AWS file server on Sunday. (Downtime is not known when the data upload would be done, although Amazon says the same day the package is received)
    4. Leverage the AWS Storage Gateway to create a Gateway-Stored volume. On Friday copy the application data to the Storage Gateway volume. After the data has been copied, perform a snapshot of the volume and restore the volume as an EBS volume to be attached to your AWS file server on Sunday. (Still uses the internet)
  3. You are tasked with moving a legacy application from a virtual machine running inside your datacenter to an Amazon VPC. Unfortunately this app requires access to a number of on-premises services and no one who configured the app still works for your company. Even worse there’s no documentation for it. What will allow the application running inside the VPC to reach back and access its internal dependencies without being reconfigured? (Choose 3 answers)
    1. An AWS Direct Connect link between the VPC and the network housing the internal services
    2. An Internet Gateway to allow a VPN connection. (Virtual and Customer gateway is needed)
    3. An Elastic IP address on the VPC instance
    4. An IP address space that does not conflict with the one on-premises
    5. Entries in Amazon Route 53 that allow the Instance to resolve its dependencies’ IP addresses
    6. A VM Import of the current virtual machine
  4. An enterprise runs 103 line-of-business applications on virtual machines in an on-premises data center. Many of the applications are simple PHP, Java, or Ruby web applications, are no longer actively developed, and serve little traffic. Which approach should be used to migrate these applications to AWS with the LOWEST infrastructure costs?
    1. Deploy the applications to single-instance AWS Elastic Beanstalk environments without a load balancer.
    2. Use AWS SMS to create AMIs for each virtual machine and run them in Amazon EC2. (Note: AWS SMS is deprecated. AWS Transform MGN would be the equivalent today.)
    3. Convert each application to a Docker image and deploy to a small Amazon ECS cluster behind an Application Load Balancer.
    4. Use VM Import/Export to create AMIs for each virtual machine and run them in single-instance AWS Elastic Beanstalk environments by configuring a custom image.
  5. [NEW] A company needs to migrate 500 VMware virtual machines to AWS with minimal downtime. The company wants automated dependency mapping, wave planning, and network conversion. Which service should they use?
    1. AWS Server Migration Service
    2. AWS Migration Hub with Application Migration Service
    3. AWS Transform for VMware (AWS Transform for VMware provides automated dependency mapping, wave planning, and network configuration conversions using agentic AI.)
    4. VM Import/Export with CloudFormation
  6. [NEW] A company needs to transfer 50TB of data to AWS S3 as quickly as possible. They are a new AWS customer. Which combination of services should they consider? (Choose 2)
    1. AWS Snowball Edge (Not available to new customers since November 2025)
    2. AWS Data Transfer Terminal (Physical location for high-speed upload using customer’s own devices. Available to new customers.)
    3. AWS DataSync (Online data transfer with automated scheduling, encryption, and validation.)
    4. AWS Snowmobile (Retired in March 2024)
  7. [NEW] A company wants to establish private connectivity between their AWS VPCs and Google Cloud environment without managing physical cross-connects. Which service should they use?
    1. AWS Direct Connect with VPN overlay
    2. AWS Site-to-Site VPN
    3. AWS Interconnect – Multicloud (Provides pre-built capacity pools between AWS and partner cloud providers, eliminating physical cross-connect management. GA April 2026.)
    4. AWS Transit Gateway with peering
  8. [NEW] A company wants to migrate databases to AWS with minimal infrastructure management. They need automatic scaling and don’t want to manage replication instances. Which service option should they use?
    1. AWS DMS with provisioned replication instances
    2. AWS DMS Serverless (Automatically provisions, scales, and manages migration resources. Supports automatic storage scaling and premigration assessments.)
    3. AWS SCT with manual migration
    4. AWS Glue ETL jobs

References

AWS VPN

~ Last updated on : ~ jayendrapatil ~ 21 Comments

AWS VPC VPN

  • AWS VPN connections are used to extend on-premises data centers to AWS.
  • VPN connections provide secure IPSec connections between the data center or branch office and the AWS resources.
  • AWS Site-to-Site VPN or AWS Hardware VPN or AWS Managed VPN
    • Connectivity can be established by creating an IPSec, hardware VPN connection between the VPC and the remote network.
    • On the AWS side of the VPN connection, a Virtual Private Gateway (VGW) or Transit Gateway provides two VPN endpoints for automatic failover.
    • On the customer side, a customer gateway (CGW) needs to be configured, which is the physical device or software application on the remote side of the VPN connection
  • AWS Client VPN
    • AWS Client VPN is a managed client-based VPN service that enables secure access to AWS resources and resources in the on-premises network.
  • AWS VPN CloudHub
    • For more than one remote network e.g. multiple branch offices, multiple AWS hardware VPN connections can be created via the VPC to enable communication between these networks
  • AWS Software VPN
    • A VPN connection can be created to the remote network by using an EC2 instance in the VPC that’s running a third-party software VPN appliance.
    • AWS does not provide or maintain third-party software VPN appliances; however, there is a range of products provided by partners and open source communities.
  • AWS Direct Connect provides a dedicated private connection from a remote network to the VPC. Direct Connect can be combined with an AWS hardware VPN connection to create an IPsec-encrypted connection

AWS Site-to-Site VPN Options (2025)

  • As of November 2025, AWS Site-to-Site VPN includes five distinct options:
    • Standard VPN with VGW – Up to 1.25 Gbps per tunnel; terminates on a Virtual Private Gateway.
    • Standard VPN with TGW or Cloud WAN – Up to 1.25 Gbps per tunnel; terminates on a Transit Gateway or AWS Cloud WAN. Supports ECMP for higher aggregate bandwidth.
    • Large Bandwidth Tunnel with TGW – Up to 5 Gbps per tunnel (launched November 2025); a 4x improvement over the standard 1.25 Gbps limit. Ideal for bandwidth-intensive hybrid applications, big data migrations, and disaster recovery.
    • VPN Concentrator – Simplifies multi-site connectivity for distributed enterprises (launched November 2025). Supports up to 100 low-bandwidth remote sites (under 100 Mbps each) through a single Transit Gateway attachment with 5 Gbps aggregate bandwidth.
    • Accelerated VPN – Uses AWS Global Accelerator to route traffic through the nearest AWS edge location, reducing internet distance and improving performance. Supported on Transit Gateway.
  • Private IP VPN – Enables Site-to-Site VPN connections over AWS Direct Connect using private IP addresses. Encrypts DX traffic between on-premises networks and AWS without traversing the public internet. Requires Transit Gateway.

VPN Components

AWS VPN Components

  • Virtual Private Gateway – VGW
    • A virtual private gateway is the VPN concentrator on the AWS side of the VPN connection
    • Supports standard bandwidth (up to 1.25 Gbps per tunnel)
    • Does not support IPv6 for Site-to-Site VPN connections
    • Does not support ECMP
  • Customer Gateway – CGW
    • A customer gateway is a physical device or software application on the customer side of the VPN connection.
    • When a VPN connection is created, the VPN tunnel comes up when traffic is generated from the remote side of the VPN connection.
    • By default, VGW is not the initiator; CGW must bring up the tunnels for the Site-to-Site VPN connection by generating traffic and initiating the Internet Key Exchange (IKE) negotiation process.
    • If the VPN connection experiences a period of idle time, usually 10 seconds, depending on the configuration, the tunnel may go down. To prevent this, a network monitoring tool to generate keepalive pings; for e.g. by using IP SLA.
  • Transit Gateway
    • A transit gateway is a transit hub that can be used to interconnect VPCs and on-premises networks.
    • A Site-to-Site VPN connection on a transit gateway can support either IPv4 traffic or IPv6 traffic inside the VPN tunnels.
    • Supports ECMP (Equal Cost Multi-Path) routing for aggregating bandwidth across multiple VPN tunnels (up to 50 Gbps).
    • Supports large bandwidth tunnels (up to 5 Gbps per tunnel).
    • Supports IPv6 addresses for outer tunnel IPs (announced July 2025), enabling full IPv6 migration (IPv6-in-IPv6) and IPv4-in-IPv6 configurations.
    • Supports VPN Concentrator attachments for multi-site connectivity.
    • Supports Private IP VPN connections over Direct Connect.
  • AWS Cloud WAN
    • AWS Cloud WAN is a managed wide area networking service for building and managing global networks.
    • Site-to-Site VPN connections can be attached to Cloud WAN core networks for global hybrid connectivity.
    • Supports IPv6 outer tunnel IPs (same as Transit Gateway).
  • A Site-to-Site VPN connection offers two VPN tunnels between a VGW or a transit gateway on the AWS side, and a CGW (which represents a VPN device) on the remote (on-premises) side.

VPN Routing Options

  • For a VPN connection, the route table for the subnets should be updated with the type of routing (static or dynamic) that you plan to use.
  • Route tables determine where network traffic is directed. Traffic destined for the VPN connections must be routed to the virtual private gateway.
  • The type of routing can depend on the make and model of the CGW device
    • Static Routing
      • If your device does not support BGP, specify static routing.
      • Using static routing, the routes (IP prefixes) can be specified that should be communicated to the virtual private gateway.
      • Devices that don’t support BGP may also perform health checks to assist failover to the second tunnel when needed.
    • BGP Dynamic Routing
      • If the VPN device supports Border Gateway Protocol (BGP), specify dynamic routing with the VPN connection.
      • When using a BGP device, static routes need not be specified to the VPN connection because the device uses BGP for auto-discovery and to advertise its routes to the virtual private gateway.
      • BGP-capable devices are recommended as the BGP protocol offers robust liveness detection checks that can assist failover to the second VPN tunnel if the first tunnel goes down.
  • Only IP prefixes known to the virtual private gateway, either through BGP advertisement or static route entry, can receive traffic from the VPC.
  • Virtual private gateway does not route any other traffic destined outside of the advertised BGP, static route entries, or its attached VPC CIDR.

VPN Route Priority

  • Longest prefix match applies.
  • If the prefixes are the same, then the VGW prioritizes routes as follows, from most preferred to least preferred:
    • BGP propagated routes from an AWS Direct Connect connection
    • Manually added static routes for a Site-to-Site VPN connection
    • BGP propagated routes from a Site-to-Site VPN connection
    • Prefix with the shortest AS PATH is preferred for matching prefixes where each Site-to-Site VPN connection uses BGP
    • Path with the lowest multi-exit discriminators (MEDs) value is preferred when the AS PATHs are the same length and if the first AS in the AS_SEQUENCE is the same across multiple paths.

VPN Bandwidth and Throughput

  • Standard VPN Tunnel: Up to 1.25 Gbps per tunnel (default)
  • Large Bandwidth VPN Tunnel: Up to 5 Gbps per tunnel (available on Transit Gateway, launched November 2025)
    • Supports modifying tunnel bandwidth on existing VPN connections (announced May 2026) without changing IP addresses, CIDR blocks, or pre-shared keys
  • VPN Concentrator Tunnel: Up to 100 Mbps per tunnel, 5 Gbps aggregate per concentrator
  • ECMP (Transit Gateway): Up to 50 Gbps aggregate bandwidth using multiple VPN tunnels with ECMP configured (each flow limited to max bandwidth per tunnel)
  • Many factors affect realized bandwidth including packet size, traffic mix (TCP/UDP), shaping or throttling policies on intermediate networks, internet weather, and specific application requirements.

VPN Limitations

  • supports only IPSec tunnel mode. Transport mode is currently not supported.
  • supports only one VGW can be attached to a VPC at a time.
  • does not support IPv6 traffic on a virtual private gateway. (IPv6 is supported on Transit Gateway and Cloud WAN.)
  • does not support Path MTU Discovery.
  • does not support overlapping CIDR blocks for the networks. It is recommended to use non-overlapping CIDR blocks.
  • does not support transitive routing. So for traffic from on-premises to AWS via a virtual private gateway, it
    • does not support Internet connectivity through Internet Gateway
    • does not support Internet connectivity through NAT Gateway
    • does not support VPC Peered resources access through VPC Peering
    • does not support S3, DynamoDB access through VPC Gateway Endpoint
    • However, Internet connectivity through NAT instance and VPC Interface Endpoint or PrivateLink services are accessible.
  • provides a bandwidth of 1.25 Gbps per tunnel for standard VPN connections. Large bandwidth tunnels support up to 5 Gbps per tunnel on Transit Gateway.
  • MTU is 1446 bytes and MSS is 1406 bytes. Jumbo frames are not supported.

VPN Tunnel Endpoint Lifecycle Control

  • The VPN Tunnel Endpoint Lifecycle Control feature enables scheduling endpoint replacements at a time that aligns with business and operational needs, prior to the service-mandated deadline.
  • Provides advanced notice of upcoming maintenance updates to help plan and minimize service disruptions.
  • When enabled, AWS notifies before performing tunnel endpoint replacements.
  • Users can accept the maintenance update at a convenient time or let it apply automatically by the deadline.
  • During a tunnel endpoint update, AWS applies replacement to one tunnel at a time to ensure continuous connectivity.
  • Available in most AWS commercial and GovCloud regions.

VPN Monitoring

  • AWS Site-to-Site VPN automatically sends notifications to the AWS Health Dashboard
  • AWS Site-to-Site VPN is integrated with CloudWatch with the following metrics available
    • TunnelState
      • The state of the tunnels.
      • For static VPNs, 0 indicates DOWN and 1 indicates UP.
      • For BGP VPNs, 1 indicates ESTABLISHED and 0 is used for all other states.
      • For both types of VPNs, values between 0 and 1 indicate at least one tunnel is not UP.
    • TunnelDataIn
      • The bytes received on the AWS side of the connection through the VPN tunnel from a customer gateway.
      • This metric counts the data after decryption.
    • TunnelDataOut
      • The bytes sent from the AWS side of the connection through the VPN tunnel to the customer gateway.
      • This metric counts the data before encryption.
    • ConcentratorBandwidthUsage
      • The bandwidth usage for a Site-to-Site VPN Concentrator connection.
      • Available only for VPN connections using a VPN Concentrator.
      • Units: Bits per second
  • Site-to-Site VPN Logs
    • VPN logs can be published to Amazon CloudWatch Logs for detailed analysis of VPN connection activity.
    • Provides tunnel activity logs for troubleshooting connectivity issues.
  • Amazon CloudWatch Network Synthetic Monitor
    • Supports hybrid monitors for networking built with AWS Direct Connect and AWS Site-to-Site VPN.
    • Provides proactive monitoring of hybrid connectivity health.

IPv6 Support for Site-to-Site VPN

  • Inner Tunnel IPv6: Supported on Transit Gateway and Cloud WAN. Allows IPv4 or IPv6 traffic inside VPN tunnels.
  • Outer Tunnel IPv6 (July 2025): Site-to-Site VPN now supports IPv6 addresses for outer tunnel IPs on Transit Gateway and Cloud WAN connections.
  • Enables full IPv6 migration with IPv6 addresses for both outer tunnel IPs and inner packet IPs (IPv6-in-IPv6).
  • Supports IPv6 outer tunnel IPs with IPv4 inner packet IPs (IPv4-in-IPv6).
  • Helps customers with IPv6-only network mandates meet regulatory and compliance needs.
  • IPv6 VPNs support the same throughput (Gbps and PPS), MTU, and route limits as IPv4 VPNs.
  • Note: Virtual private gateways do NOT support IPv6 for Site-to-Site VPN connections. IPv6 requires Transit Gateway or Cloud WAN.

VPN Concentrator (November 2025)

  • AWS Site-to-Site VPN Concentrator simplifies multi-site connectivity for distributed enterprises with many low-bandwidth remote sites.
  • Suitable for customers needing to connect 25+ remote sites to AWS, with each site needing low bandwidth (under 100 Mbps).
  • Allows up to 100 remote sites to connect through a single VPN Concentrator attachment to AWS Transit Gateway.
  • Provides 5 Gbps aggregate bandwidth shared across all connected sites.
  • Eliminates the need to deploy and manage multiple virtual appliances for HA and connectivity.
  • AWS manages high availability across multiple Availability Zones.
  • Can be used with eero integration for simplified remote site connectivity without manual tunnel configuration.
  • Quotas:
    • Up to 50 VPN Concentrators per Region
    • Up to 5 VPN Concentrators per Transit Gateway or Cloud WAN
    • Up to 100 remote sites per VPN Concentrator

VPN Connection Redundancy

VPN Connection Redundancy

  • A VPN connection is used to connect the customer network to a VPC.
  • Each VPN connection has two tunnels to help ensure connectivity in case one of the VPN connections becomes unavailable, with each tunnel using a unique virtual private gateway public IP address.
  • Both tunnels should be configured for redundancy.
  • When one tunnel becomes unavailable, for e.g. down for maintenance, network traffic is automatically routed to the available tunnel for that specific VPN connection.
  • To protect against a loss of connectivity in case the customer gateway becomes unavailable, a second VPN connection can be set up to the VPC and virtual private gateway by using a second customer gateway.
  • Customer gateway IP address for the second VPN connection must be publicly accessible.
  • By using redundant VPN connections and CGWs, maintenance on one of the customer gateways can be performed while traffic continues to flow over the second customer gateway’s VPN connection.
  • Dynamically routed VPN connections using the Border Gateway Protocol (BGP) are recommended, if available, to exchange routing information between the customer gateways and the virtual private gateways.
  • Statically routed VPN connections require static routes for the network to be entered on the customer gateway side.
  • BGP-advertised and statically entered route information allows gateways on both sides to determine which tunnels are available and reroute traffic if a failure occurs.

Multiple Site-to-Site VPN Connections

VPN Connection

  • VPC has an attached virtual private gateway, and the remote network includes a customer gateway, which must be configured to enable the
    VPN connection.
  • Routing must be set up so that any traffic from the VPC bound for the remote network is routed to the virtual private gateway.
  • Each VPN has two tunnels associated with it that can be configured on the customer router, as is not a single point of failure
  • Multiple VPN connections to a single VPC can be created, and a second CGW can be configured to create a redundant connection to the same external location or to create VPN connections to multiple geographic locations.

VPN CloudHub

  • VPN CloudHub can be used to provide secure communication between multiple on-premises sites if you have multiple VPN connections
  • VPN CloudHub operates on a simple hub-and-spoke model using a Virtual Private gateway in a detached mode that can be used without a VPC.
  • Design is suitable for customers with multiple branch offices and existing
    Internet connections who’d like to implement a convenient, potentially low-cost hub-and-spoke model for primary or backup connectivity between these remote offices
  • Note: For large-scale multi-site connectivity (25+ sites), consider using the newer VPN Concentrator feature with Transit Gateway, which provides a managed, scalable alternative.

VPN CloudHub Architecture

  • VPN CloudHub architecture with blue dashed lines indicates network
    traffic between remote sites being routed over their VPN connections.
  • AWS VPN CloudHub requires a virtual private gateway with multiple customer gateways.
  • Each customer gateway must use a unique Border Gateway Protocol (BGP) Autonomous System Number (ASN)
  • Customer gateways advertise the appropriate routes (BGP prefixes) over their VPN connections.
  • Routing advertisements are received and re-advertised to each BGP peer, enabling each site to send data to and receive data from the other sites.
  • Routes for each spoke must have unique ASNs and the sites must not have overlapping IP ranges.
  • Each site can also send and receive data from the VPC as if they were using a standard VPN connection.
  • Sites that use AWS Direct Connect connections to the virtual private gateway can also be part of the AWS VPN CloudHub.
  • To configure the AWS VPN CloudHub,
    • multiple customer gateways can be created, each with the unique public IP address of the gateway and the ASN.
    • a VPN connection can be created from each customer gateway to a common virtual private gateway.
    • each VPN connection must advertise its specific BGP routes. This is done using the network statements in the VPN configuration files for the VPN connection.

Private IP VPN over Direct Connect

  • AWS Site-to-Site VPN Private IP VPN enables deploying VPN connections over Direct Connect using private IP addresses.
  • Direct Connect provides a private, dedicated connection but is not encrypted. Private IP VPN adds IPSec encryption to DX traffic.
  • Requires a Transit Gateway with a Direct Connect Gateway attachment.
  • Traffic stays on the AWS private network and never traverses the public internet.
  • Satisfies security and compliance regulations requiring encryption at layer 3 for dedicated connections.
  • Configuration:
    • Create or use an existing Transit Gateway with a private IP CIDR block.
    • Establish a Direct Connect connection and Transit VIF to a Direct Connect Gateway.
    • Create a Private IP VPN connection specifying private outside IP address type.

Accelerated Site-to-Site VPN

  • An accelerated VPN connection uses AWS Global Accelerator to route traffic from the on-premises network to the nearest AWS edge location.
  • Reduces the distance over which data is shared on the internet by leveraging the AWS global fiber network.
  • Improves performance for VPN connections where the customer gateway is geographically distant from the AWS Region.
  • Requires a Transit Gateway (not supported on VGW).
  • Each accelerated VPN connection uses two Global Accelerator resources (one per tunnel).
  • Default quota: 10 accelerated Site-to-Site VPN connections per Region (adjustable).

VPN vs Direct Connect

AWS Direct Connect vs VPN

VPN Quotas

  • Customer gateways per Region: 50 (adjustable)
  • Virtual private gateways per Region: 5 (adjustable)
  • Site-to-Site VPN connections per Region: 50 (adjustable)
  • Site-to-Site VPN connections per virtual private gateway: 10 (adjustable)
  • Accelerated VPN connections per Region: 10 (adjustable)
  • Large Bandwidth Tunnel connections per Region: 50 (adjustable)
  • VPN Concentrators per Region: 50 (adjustable)
  • VPN Concentrators per Transit Gateway or Cloud WAN: 5 (adjustable)
  • Remote sites per VPN Concentrator: 100 (adjustable)
  • Dynamic routes advertised from CGW to VPN on VGW: 100 (not adjustable)
  • Routes advertised from VPN on VGW to CGW: 1,000 (not adjustable)
  • Dynamic routes advertised from CGW to VPN on Transit Gateway: 1,000 (not adjustable)
  • Routes advertised from VPN on Transit Gateway to CGW: 5,000 (not adjustable)

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have in total 5 offices, and the entire employee-related information is stored under AWS VPC instances. Now all the offices want to connect the instances in VPC using VPN. Which of the below help you to implement this?
    1. you can have redundant customer gateways between your data center and your VPC
    2. you can have multiple locations connected to the AWS VPN CloudHub
    3. You have to define 5 different static IP addresses in route table.
    4. 1 and 2
    5. 1,2 and 3
  2. You have in total of 15 offices, and the entire employee-related information is stored under AWS VPC instances. Now all the offices want to connect the instances in VPC using VPN. What problem do you see in this scenario?
    1. You can not create more than 1 VPN connections with single VPC (Can be created)
    2. You can not create more than 10 VPN connections with single VPC (soft limit can be extended)
    3. When you create multiple VPN connections, the virtual private gateway can not sends network traffic to the appropriate VPN connection using statically assigned routes. (Can route the traffic to correct connection)
    4. Statically assigned routes cannot be configured in case of more than 1 VPN with the virtual private gateway. (can be configured)
    5. None of above
  3. You have been asked to virtually extend two existing data centers into AWS to support a highly available application that depends on existing, on-premises resources located in multiple data centers and static content that is served from an Amazon Simple Storage Service (S3) bucket. Your design currently includes a dual-tunnel VPN connection between your CGW and VGW. Which component of your architecture represents a potential single point of failure that you should consider changing to make the solution more highly available?
    1. Add another VGW in a different Availability Zone and create another dual-tunnel VPN connection.
    2. Add another CGW in a different data center and create another dual-tunnel VPN connection. (Refer link)
    3. Add a second VGW in a different Availability Zone, and a CGW in a different data center, and create another dual-tunnel.
    4. No changes are necessary: the network architecture is currently highly available.
  4. You are designing network connectivity for your fat client application. The application is designed for business travelers who must be able to connect to it from their hotel rooms, cafes, public Wi-Fi hotspots, and elsewhere on the Internet. You do not want to publish the application on the Internet. Which network design meets the above requirements while minimizing deployment and operational costs? [PROFESSIONAL]
    1. Implement AWS Direct Connect, and create a private interface to your VPC. Create a public subnet and place your application servers in it. (High Cost and does not minimize deployment)
    2. Implement Elastic Load Balancing with an SSL listener that terminates the back-end connection to the application. (Needs to be published to internet)
    3. Configure an IPsec VPN connection, and provide the users with the configuration details. Create a public subnet in your VPC, and place your application servers in it. (Instances still in public subnet are internet accessible)
    4. Configure an SSL VPN solution in a public subnet of your VPC, then install and configure SSL VPN client software on all user computers. Create a private subnet in your VPC and place your application servers in it. (Cost effective and can be in private subnet as well. Note: AWS Client VPN is the managed alternative for this use case.)
  5. You are designing a connectivity solution between on-premises infrastructure and Amazon VPC Your server’s on-premises will De communicating with your VPC instances You will De establishing IPSec tunnels over the internet You will be using VPN gateways and terminating the IPsec tunnels on AWS-supported customer gateways. Which of the following objectives would you achieve by implementing an IPSec tunnel as outlined above? (Choose 4 answers) [PROFESSIONAL]
    1. End-to-end protection of data in transit
    2. End-to-end Identity authentication
    3. Data encryption across the Internet
    4. Protection of data in transit over the Internet
    5. Peer identity authentication between VPN gateway and customer gateway
    6. Data integrity protection across the Internet
  6. A development team that is currently doing a nightly six-hour build which is lengthening over time on-premises with a large and mostly under utilized server would like to transition to a continuous integration model of development on AWS with multiple builds triggered within the same day. However, they are concerned about cost, security and how to integrate with existing on-premises applications such as their LDAP and email servers, which cannot move off-premises. The development environment needs a source code repository; a project management system with a MySQL database resources for performing the builds and a storage location for QA to pick up builds from. What AWS services combination would you recommend to meet the development team’s requirements? [PROFESSIONAL]
    1. A Bastion host Amazon EC2 instance running a VPN server for access from on-premises, Amazon EC2 for the source code repository with attached Amazon EBS volumes, Amazon EC2 and Amazon RDS MySQL for the project management system, EIP for the source code repository and project management system, Amazon SQL for a build queue, An Amazon Auto Scaling group of Amazon EC2 instances for performing builds and Amazon Simple Email Service for sending the build output. (Bastion is not for VPN connectivity also SES should not be used)
    2. An AWS Storage Gateway for connecting on-premises software applications with cloud-based storage securely, Amazon EC2 for the resource code repository with attached Amazon EBS volumes, Amazon EC2 and Amazon RDS MySQL for the project management system, EIPs for the source code repository and project management system, Amazon Simple Notification Service for a notification initiated build, An Auto Scaling group of Amazon EC2 instances for performing builds and Amazon S3 for the build output. (Storage Gateway does provide secure connectivity but still needs VPN. SNS alone cannot handle builds)
    3. An AWS Storage Gateway for connecting on-premises software applications with cloud-based storage securely, Amazon EC2 for the resource code repository with attached Amazon EBS volumes, Amazon EC2 and Amazon RDS MySQL for the project management system, EIPs for the source code repository and project management system, Amazon SQS for a build queue, An Amazon Elastic Map Reduce (EMR) cluster of Amazon EC2 instances for performing builds and Amazon CloudFront for the build output. (Storage Gateway does not provide secure connectivity, still needs VPN. EMR is not ideal for performing builds as it needs normal EC2 instances)
    4. A VPC with a VPN Gateway back to their on-premises servers, Amazon EC2 for the source-code repository with attached Amazon EBS volumes, Amazon EC2 and Amazon RDS MySQL for the project management system, EIPs for the source code repository and project management system, SQS for a build queue, An Auto Scaling group of EC2 instances for performing builds and S3 for the build output. (VPN gateway is required for secure connectivity. SQS for build queue and EC2 for builds)
  7. A company has 50 branch offices and wants to connect all of them to AWS. Each branch has bandwidth requirements under 50 Mbps. Which AWS VPN solution is most cost-effective and operationally simple?
    1. Create 50 individual Site-to-Site VPN connections to a Transit Gateway (Works but higher cost and operational overhead with 50 separate VPN connections)
    2. Use a VPN Concentrator on Transit Gateway to connect all branches through a single attachment (VPN Concentrator supports up to 100 sites with under 100 Mbps each, single TGW attachment simplifies management)
    3. Use VPN CloudHub with a Virtual Private Gateway (VPN CloudHub works but limited to VGW capabilities and doesn’t scale as easily)
    4. Deploy EC2-based VPN appliances in multiple AZs (Self-managed, higher operational overhead)
  8. A company requires encrypted connectivity between their on-premises data center and AWS over their existing Direct Connect connection. The traffic must not traverse the public internet. Which solution meets these requirements?
    1. Configure a standard Site-to-Site VPN over the internet as backup to Direct Connect (Traffic traverses the public internet)
    2. Configure a Private IP VPN connection over Direct Connect using Transit Gateway (Private IP VPN encrypts DX traffic using private IP addresses without internet traversal)
    3. Enable MACsec on Direct Connect and use VGW for VPN termination (MACsec provides L2 encryption but VGW doesn’t support Private IP VPN)
    4. Use AWS Client VPN over Direct Connect (Client VPN is for remote user access, not site-to-site connectivity)
  9. A company needs to migrate large datasets to AWS and requires more than 1.25 Gbps of VPN bandwidth per tunnel. What should they configure?
    1. Create multiple standard VPN connections and enable ECMP on a VGW (VGW does not support ECMP)
    2. Use Accelerated VPN with Global Accelerator to increase per-tunnel bandwidth (Accelerated VPN improves latency but does not increase per-tunnel bandwidth beyond standard limits)
    3. Configure a Large Bandwidth Tunnel VPN connection on Transit Gateway for up to 5 Gbps per tunnel (Large Bandwidth Tunnels support up to 5 Gbps per tunnel on TGW)
    4. Configure Direct Connect with 10 Gbps dedicated connection (Meets bandwidth needs but is not a VPN solution and takes longer to provision)
  10. An organization has VPN connections from multiple branch offices to AWS. The VPN performance is poor because the branches are far from the AWS Region. What can improve VPN performance without changing the on-premises equipment? (Choose 2)
    1. Enable Accelerated VPN using AWS Global Accelerator on Transit Gateway (Routes traffic to the nearest AWS edge location to reduce internet distance)
    2. Enable VPN CloudHub on a Virtual Private Gateway (VPN CloudHub is for inter-site communication, not for improving performance)
    3. Use Large Bandwidth Tunnels (5 Gbps) on Transit Gateway (Higher per-tunnel bandwidth can improve throughput for bandwidth-constrained connections)
    4. Configure Private IP VPN over Direct Connect (Requires Direct Connect infrastructure, changes the connectivity model)
    5. Add more VPN tunnels with ECMP on VGW (VGW does not support ECMP)

References

AWS VPC NAT Gateway vs NAT Instance – Comparison

NAT Gateway High Availability
~ Last updated on : ~ jayendrapatil ~ 22 Comments

AWS NAT

  • AWS NAT – Network Address Translation devices, launched in the public subnet, enables instances in a private subnet to connect to the Internet but prevents the Internet from initiating connections with the instances.
  • Instances in private subnets would need an internet connection for performing software updates or trying to access external services.
  • NAT device performs the function of both address translation and port address translation (PAT)
  • NAT instance prevents instances to be directly exposed to the Internet and having to be launched in a Public subnet and assigning of the Elastic IP address to all, which are limited.
  • NAT device routes the traffic, from the private subnet to the Internet, by replacing the source IP address with its address and it translates the address back to the instances’ private IP addresses for the response traffic.
  • AWS allows NAT configuration in 2 ways
    • NAT Gateway, managed service by AWS (recommended)
    • NAT Instance (legacy, not recommended)

NAT Gateway

  • NAT gateway is an AWS managed NAT service that provides better availability, higher bandwidth, and requires less administrative effort.
  • A NAT gateway supports 5 Gbps of bandwidth and automatically scales up to 100 Gbps. For higher bursts requirements, the workload can be distributed by splitting the resources into multiple subnets and creating a NAT gateway in each subnet.
  • A NAT gateway can process one million packets per second and automatically scales up to ten million packets per second. Beyond this limit, a NAT gateway will drop packets.
  • Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone (for zonal NAT gateways).
  • A NAT gateway supports the TCP, UDP, and ICMP protocols.
  • NAT gateways are supported for IPv4 or IPv6 traffic. For IPv6 traffic, NAT gateway performs NAT64. By using this in conjunction with DNS64 (available on Route 53 Resolver), IPv6 workloads in a subnet can communicate with IPv4 resources.
  • NAT gateway cannot be associated with a security group. Security can be configured for the instances in the private subnets to control the traffic.
  • Network ACL can be used to control the traffic to and from the subnet. NACL applies to the NAT gateway’s traffic, which uses ports 1024-65535
  • NAT gateway when created receives an elastic network interface that’s automatically assigned a private IP address from the IP address range of the subnet. Attributes of this network interface cannot be modified.
  • NAT gateway cannot send traffic over VPC endpoints, VPN connections, AWS Direct Connect, or VPC peering connections. The private subnet’s route table should be modified to route the traffic directly to these devices.
  • NAT gateway can route traffic to Transit Gateways and virtual private gateways (for private NAT gateways) or through Transit Gateway for Site-to-Site VPN/Direct Connect traffic.
  • NAT gateway times out the connection if it is idle for 350 seconds or more. To prevent the connection from being dropped, initiate more traffic over the connection or enable TCP keepalive on the instance with a value of less than 350 seconds.
  • NAT gateways currently do not support the IPsec protocol.
  • NAT gateways support traffic with a maximum transmission unit (MTU) of 8500 bytes.
  • Each IPv4 address can support up to 55,000 simultaneous connections to each unique destination. You can increase this limit by associating up to 8 IPv4 addresses to your NAT gateways (1 primary IPv4 address and 7 secondary IPv4 addresses). By default, you can associate up to 2 Elastic IP addresses per public NAT gateway (quota increase available).

NAT Gateway Types

  • Public NAT Gateway
    • Enables instances in private subnets to connect to the internet
    • Requires an Elastic IP address
    • Must be created in a public subnet (for zonal mode)
    • Supports up to 8 IPv4 addresses (1 primary + 7 secondary)
  • Private NAT Gateway
    • Enables instances in private subnets to connect to other VPCs or on-premises networks via Transit Gateway or virtual private gateway
    • Does not require an Elastic IP address
    • Uses private IP address for source NAT
    • Cannot be used for internet connectivity
    • Useful for communication between VPCs with overlapping CIDR ranges

Regional NAT Gateway (Announced November 2025)

  • A regional NAT gateway automatically expands across Availability Zones based on workload presence, unlike standard zonal NAT gateways which operate in a single AZ.
  • Does not require a public subnet – creates its own route table with a pre-configured route to the internet gateway.
  • Provides automatic high availability without manual multi-AZ configuration.
  • Simplifies setup – no need to create/delete NAT Gateways or edit route tables when workloads expand to new AZs.
  • Supports up to 32 IP addresses per Availability Zone (compared to 8 for zonal NAT gateways).
  • May take up to 60 minutes to expand to a new AZ after a resource is launched there.
  • Supports two modes:
    • Automatic mode – AWS manages IP addresses and AZ expansion (recommended)
    • Manual mode – You manually manage IP addresses and control AZ expansion/contraction
  • Supports AWS Transit Gateway as a valid route in the regional NAT gateway route table.
  • Does not support private NAT connectivity (use zonal NAT gateways for private NAT use cases).
  • Available in all commercial AWS Regions (except AWS GovCloud and China Regions).

Regional NAT Gateway vs Zonal NAT Gateway

  • Zonal NAT Gateway (Traditional)
    • Created in a specific Availability Zone
    • Requires a public subnet in each AZ for high availability
    • Requires manual creation of NAT Gateway in each AZ
    • Requires route table updates for each AZ
    • Supports up to 8 IP addresses
    • Supports both public and private connectivity types
    • Best for: Predictable, static workloads; private NAT use cases
  • Regional NAT Gateway
    • Automatically spans all AZs based on workload presence
    • No public subnet required
    • Single NAT Gateway resource to manage
    • Automatic routing across AZs
    • Supports up to 32 IP addresses per AZ
    • Public connectivity only (no private NAT support)
    • Best for: Dynamic workloads that scale across AZs, simplified management, new deployments

NAT Gateway High Availability

NAT Instance

⚠️ NAT Instance – Legacy (Not Recommended)

The NAT AMI is built on the last version of Amazon Linux AMI, 2018.03, which reached end of standard support on December 31, 2020 and end of maintenance support on December 31, 2023.

AWS recommends migrating to a NAT Gateway for better availability, higher bandwidth, and less administrative effort.

If NAT instances are required for your use case (e.g., cost optimization for non-production environments), you can create your own NAT AMI from a current version of Amazon Linux.

NAT Gateway vs NAT Instance

NAT Gateway vs NAT Instance

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. After launching an instance that you intend to serve as a NAT (Network Address Translation) device in a public subnet you modify your route tables to have the NAT device be the target of internet bound traffic of your private subnet. When you try and make an outbound connection to the Internet from an instance in the private subnet, you are not successful. Which of the following steps could resolve the issue?
    1. Attaching a second Elastic Network interface (ENI) to the NAT instance, and placing it in the private subnet
    2. Attaching an Elastic IP address to the instance in the private subnet
    3. Attaching a second Elastic Network Interface (ENI) to the instance in the private subnet, and placing it in the public subnet
    4. Disabling the Source/Destination Check attribute on the NAT instance
  2. You manually launch a NAT AMI in a public subnet. The network is properly configured. Security groups and network access control lists are property configured. Instances in a private subnet can access the NAT. The NAT can access the Internet. However, private instances cannot access the Internet. What additional step is required to allow access from the private instances?
    1. Enable Source/Destination Check on the private Instances.
    2. Enable Source/Destination Check on the NAT instance.
    3. Disable Source/Destination Check on the private instances
    4. Disable Source/Destination Check on the NAT instance
  3. A user has created a VPC with public and private subnets. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.1.0/24 and the public subnet uses CIDR 20.0.0.0/24. The user is planning to host a web server in the public subnet (port 80. and a DB server in the private subnet (port 3306.. The user is configuring a security group of the NAT instance. Which of the below mentioned entries is not required for the NAT security group?
    1. For Inbound allow Source: 20.0.1.0/24 on port 80
    2. For Outbound allow Destination: 0.0.0.0/0 on port 80
    3. For Inbound allow Source: 20.0.0.0/24 on port 80 (Refer NAT Instance Documentation)
    4. For Outbound allow Destination: 0.0.0.0/0 on port 443
  4. A web company is looking to implement an external payment service into their highly available application deployed in a VPC. Their application EC2 instances are behind a public facing ELB. Auto scaling is used to add additional instances as traffic increases. Under normal load the application runs 2 instances in the Auto Scaling group but at peak it can scale 3x in size. The application instances need to communicate with the payment service over the Internet, which requires whitelisting of all public IP addresses used to communicate with it. A maximum of 4 whitelisting IP addresses are allowed at a time and can be added through an API. How should they architect their solution?
    1. Route payment requests through two NAT instances setup for High Availability and whitelist the Elastic IP addresses attached to the NAT instances
    2. Whitelist the VPC Internet Gateway Public IP and route payment requests through the Internet Gateway. (Internet gateway is only to route traffic)
    3. Whitelist the ELB IP addresses and route payment requests from the Application servers through the ELB. (ELB does not have a fixed IP address)
    4. Automatically assign public IP addresses to the application instances in the Auto Scaling group and run a script on boot that adds each instances public IP address to the payment validation whitelist API. (would exceed the allowed 4 IP addresses)
  5. A company needs to provide internet access to instances in private subnets across multiple Availability Zones with automatic high availability and simplified management. Which NAT Gateway option should they use?
    1. Create a public NAT Gateway in each Availability Zone
    2. Create a Regional NAT Gateway that automatically spans all Availability Zones
    3. Create a private NAT Gateway in each Availability Zone
    4. Use NAT instances with Auto Scaling
  6. An organization has two VPCs with overlapping CIDR ranges that need to communicate with each other through a Transit Gateway. Which NAT Gateway type should be used to enable this communication?
    1. Public NAT Gateway with Elastic IP addresses
    2. Regional NAT Gateway in automatic mode
    3. Private NAT Gateway connected to a Transit Gateway
    4. NAT Instance with Source/Destination Check disabled
  7. A company’s NAT Gateway is experiencing port exhaustion when communicating with a popular third-party API endpoint. What is the most effective solution to increase the number of simultaneous connections?
    1. Create multiple NAT Gateways in the same subnet
    2. Associate secondary IPv4 addresses with the NAT Gateway to increase the connection limit
    3. Increase the NAT Gateway bandwidth allocation
    4. Replace the NAT Gateway with a NAT Instance using a larger instance type

Related Posts

References

AWS Network Connectivity Options

~ Last updated on : ~ jayendrapatil ~ 3 Comments

AWS Network Connectivity Options

Internet Gateway

  • provides Internet connectivity to VPC
  • is a horizontally scaled, redundant, and highly available component that allows communication between instances in your VPC and the internet.
  • imposes no availability risks or bandwidth constraints on your network traffic.
  • serves two purposes: to provide a target in the VPC route tables for internet-routable traffic and to perform NAT for instances that have not been assigned public IPv4 addresses.
  • supports IPv4 and IPv6 traffic.

NAT Gateway

  • enables instances in a private subnet to connect to the internet or other AWS services, but prevents the Internet from initiating connections with the instances.
  • Public NAT gateway allows instances in private subnets to connect to the internet through the NAT gateway’s Elastic IP address.
  • Private NAT gateway allows instances in private subnets to connect to other VPCs or the on-premises network using its private IP address for source NAT.
  • Regional NAT Gateway (New – Nov 2025) – automatically expands across Availability Zones based on workload presence. Unlike standard (zonal) NAT gateways which operate in a single AZ, regional NAT gateways follow workloads to provide automatic high availability without requiring a public subnet to host the gateway.

Egress Only Internet Gateway

  • NAT devices are not supported for IPv6 traffic, use an Egress-only Internet gateway instead
  • Egress-only Internet gateway is a horizontally scaled, redundant, and highly available VPC component
  • Egress-only Internet gateway allows outbound communication over IPv6 from instances in the VPC to the Internet and prevents the Internet from initiating an IPv6 connection with your instances.

VPC Endpoints

  • VPC endpoint provides a private connection from VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
  • Instances in the VPC do not require public IP addresses to communicate with resources in the service. Traffic between the VPC and the other service does not leave the Amazon network.
  • VPC Endpoints are virtual devices and are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and services without imposing availability risks or bandwidth constraints on the network traffic.
  • VPC Endpoints are of three types
    • Interface Endpoints – is an elastic network interface with a private IP address that serves as an entry point for traffic destined to supported services.
    • Gateway Endpoints – is a gateway that is a target for a specified route in your route table, used for traffic destined to a supported AWS service. Currently only Amazon S3 and DynamoDB.
    • Resource Endpoints (New – Dec 2024) – enables private access to a specific resource (e.g., RDS database, IP address, or domain name) in another VPC or on-premises environment shared via AWS RAM, without requiring an NLB.
  • Cross-Region PrivateLink (Nov 2025) – Interface VPC endpoints now support cross-region connectivity, breaking the previous limitation that endpoints were regional-only. This enables connecting to VPC endpoint services hosted in other AWS Regions within the same partition.

VPC Private LinksAWS Private Links

  • provides private connectivity between VPCs, AWS services, and your on-premises networks without exposing your traffic to the public internet.
  • helps privately expose a service/application residing in one VPC (service provider) to other VPCs (consumer) within an AWS Region in a way that only consumer VPCs initiate connections to the service provider VPC.
  • With ALB as a target of NLB, ALB’s advanced routing capabilities can be combined with AWS PrivateLink.
  • VPC Resource Gateway (Dec 2024) – allows sharing any VPC resource (RDS databases, domain names, IP addresses) via AWS RAM. Consumers access these resources privately using VPC endpoints without needing an NLB, simplifying hybrid networking.
  • Cross-Region Connectivity (Nov 2025) – PrivateLink now supports native cross-region access for both AWS services and customer endpoint services, enabling global private connectivity from a single Region deployment.

VPC Peering

  • enables networking connection between two VPCs to route traffic between them using private IPv4 addresses or IPv6 addresses
  • connections can be created between your own VPCs, or with a VPC in another AWS account.
  • enables full bidirectional connectivity between the VPCs
  • supports inter-region VPC peering connection
  • Inter-region peering now supports jumbo frames (up to 8500 bytes MTU) and full instance bandwidth (Mar 2025)
  • uses existing underlying AWS infrastructure
  • does not have a single point of failure for communication or a bandwidth bottleneck.
  • VPC Peering connections have limitations
    • cannot be used with Overlapping CIDR blocks
    • does not provide Transitive peering
    • does not support Edge to Edge routing through Gateway or private connection
  • is best used when resources in one VPC must communicate with resources in another VPC, the environment of both VPCs is controlled and secured, and the number of VPCs to be connected is less than 10
  • supports a limit of 125 active peering connections per VPC
  • Simplified Billing (Apr 2025) – AWS simplified VPC Peering billing; no changes to data transfer pricing but billing structure is streamlined.

VPN CloudHub

  • AWS VPN CloudHub allows you to securely communicate from one site to another using AWS Managed VPN or Direct Connect
  • AWS VPN CloudHub operates on a simple hub-and-spoke model that can be used with or without a VPC
  • AWS VPN CloudHub can be used if you have multiple branch offices and existing internet connections and would like to implement a convenient, potentially low cost hub-and-spoke model for primary or backup connectivity between these remote offices.
  • AWS VPN CloudHub leverages VPC virtual private gateway with multiple gateways, each using unique BGP autonomous system numbers (ASNs).

Transit VPC

⚠️ Note: Transit VPC is a legacy architecture pattern. AWS recommends using AWS Transit Gateway or AWS Cloud WAN for new deployments, which provide managed, highly available hub-and-spoke connectivity without the operational overhead of managing EC2-based virtual appliances.

  • A transit VPC is a common strategy for connecting multiple, geographically disperse VPCs and remote networks in order to create a global network transit center.
  • A transit VPC simplifies network management and minimizes the number of connections required to connect multiple VPCs and remote networks
  • Transit VPC can be used to support important use cases
    • Private Networking – You can build a private network that spans two or more AWS Regions.
    • Shared Connectivity – Multiple VPCs can share connections to data centers, partner networks, and other clouds.
    • Cross-Account AWS Usage – The VPCs and the AWS resources within them can reside in multiple AWS accounts.
  • Transit VPC design helps implement more complex routing rules, such as network address translation between overlapping network ranges, or to add additional network-level packet filtering or inspection.
  • Transit VPC
    • supports Transitive routing using the overlay VPN network — allowing for a simpler hub and spoke design.
    • supports network address translation between overlapping network ranges.
    • supports vendor functionality around advanced security (layer 7 firewall/IPS/IDS) using third-party software on EC2
    • leverages instance-based routing that increases costs while lowering availability and limiting the bandwidth.
    • Customers are responsible for managing the HA and redundancy of EC2 instances running the third-party vendor virtual appliance

Transit Gateway

Transit Gateway

  • is a highly available and scalable service to consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
  • is a Regional resource and can connect thousands of VPCs within the same AWS Region.
  • TGWs across different regions can peer with each other to enable VPC communications within the same or different regions.
  • provides simpler VPC-to-VPC communication management over VPC Peering with a large number of VPCs.
  • enables you to attach VPCs (across accounts) and VPN connections in the same Region and route traffic between them.
  • support dynamic and static routing between attached VPCs and VPN connections
  • removes the need for using full mesh VPC Peering and Transit VPC
  • Transit Gateway Flow Logs – enables capturing detailed telemetry (source/destination IPs, ports, protocol, traffic counters, timestamps) for all network flows traversing the Transit Gateway. Logs can be published to CloudWatch Logs, S3, or Firehose.
  • Flexible Cost Allocation (Nov 2025) – provides granular control over how Transit Gateway data processing costs are allocated across AWS accounts within AWS Organizations.

AWS Cloud WAN

  • is a managed wide area networking (WAN) service that helps build, manage, and monitor a unified global network connecting cloud and on-premises resources.
  • provides a central dashboard and network policies to create a global network spanning multiple locations, removing the need to configure and manage different networks using different technologies.
  • uses a policy-based automation system to define network segments, attach VPCs, VPN connections, and SD-WAN products.
  • simplifies global network management compared to manually managing Transit Gateways across regions.
  • key features include:
    • Central Dashboard – manage branch offices, data centers, VPN connections, SD-WAN, VPCs, and Transit Gateways from one place.
    • Network Policies – define how traffic is routed between segments with policy-based controls.
    • Service Insertion (2024) – streamlines integrating security and inspection services (e.g., Network Firewall) into global networks.
    • Routing Policy (Nov 2025) – enables route filtering, summarization, and BGP path manipulation for fine-grained traffic control at scale.
    • Security Group Referencing & Enhanced DNS (Jun 2025) – simplifies security group management and DNS resolution across Cloud WAN segments.
  • can be used as a migration path from Transit Gateway for organizations needing global, multi-Region network management.
  • available in AWS GovCloud (US) Regions as of Jun 2026.

Hybrid Connectivity

AWS Network Connectivity Decision Tree

Virtual Private Network (VPN)

VPC Managed VPN Connection

AWS Site-to-Site VPN

  • VPC provides the option of creating an IPsec VPN connection between remote customer networks and their VPC over the internet
  • AWS managed VPN endpoint includes automated multi–data center redundancy & failover built into the AWS side of the VPN connection
  • AWS managed VPN consists of two parts
    • Virtual Private Gateway (VPG) on AWS side
    • Customer Gateway (CGW) on the on-premises data center
  • AWS Site-to-Site VPN only provides Site-to-Site VPN connectivity. It does not provide Point-to-Site VPC connectivity (use AWS Client VPN for that).
  • Virtual Private Gateway are Highly Available as it represents two distinct VPN endpoints, physically located in separate data centers to increase the availability of the VPN connection.
  • High Availability on the on-premises data center must be handled by creating additional Customer Gateway.
  • AWS Site-to-Site VPN connections are low cost, quick to setup and start with compared to Direct Connect. However, they are not reliable as they traverse through Internet.
  • 5 Gbps Bandwidth Tunnels (Nov 2025) – supports VPN connections with up to 5 Gbps bandwidth per tunnel, a 4x improvement from the previous 1.25 Gbps limit. Beneficial for bandwidth-intensive hybrid applications, big data migrations, and disaster recovery. Bandwidth can be modified on existing connections without changing on-premises configuration (May 2026).
  • IPv6 Support for Outer Tunnel IPs (Jul 2025) – supports IPv6 addresses on outer tunnel IPs, enabling full IPv6-only VPN connectivity (IPv6-in-IPv6) and mixed (IPv4-in-IPv6) configurations without IPv6>IPv4>IPv6 translation.
  • VPN Concentrator (Nov 2025) – a new feature that simplifies multi-site connectivity for distributed enterprises with 25+ remote sites needing low bandwidth (under 100 Mbps each). Connects multiple remote sites through a single VPN attachment to Transit Gateway with 5 Gbps aggregate bandwidth.

AWS Client VPN

  • is a fully managed, scalable VPN service that provides an endpoint for users to establish a secure remote access (Point-to-Site) connection to the AWS network.
  • uses OpenVPN-based VPN client software for secure connectivity.
  • handles Point-to-Site VPN connectivity that AWS Site-to-Site VPN does not provide (e.g., remote worker/mobile access).
  • supports authentication via Active Directory, SAML-based federated authentication, and mutual certificate authentication.
  • IPv6 Connectivity (Aug 2025) – now supports full IPv6 connectivity for Client VPN endpoints, allowing connections to IPv6 resources in VPCs and from clients on IPv6 networks.

Software VPN

  • VPC offers the flexibility to fully manage both sides of the VPC connectivity by creating a VPN connection between your remote network and a software VPN appliance running in your VPC network.
  • Software VPNs help manage both ends of the VPN connection either for compliance purposes or for leveraging gateway devices that are not currently supported by Amazon VPC’s VPN solution.
  • Software VPNs allows you to handle Point-to-Site connectivity (though AWS Client VPN is now the recommended managed alternative).
  • Software VPNs, with the above design, introduces a single point of failure and needs to be handled.

Direct Connect – DX

  • AWS Direct Connect helps establish a dedicated private connection between an on-premises network and AWS.
  • Direct Connect can reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than internet-based or VPN connections
  • Direct Connect uses industry-standard VLANs to access EC2 instances running within a VPC using private IP addresses
  • Direct Connect lets you establish
    • Dedicated Connection: A 1G, 10G, or 100G physical Ethernet connection associated with a single customer through AWS.
    • Hosted Connection: A physical Ethernet connection that an AWS Direct Connect Partner provisions on behalf of a customer. Speeds range from 50 Mbps to 10 Gbps.
  • Direct Connect provides the following Virtual Interfaces
    • Private virtual interface – to access a VPC using private IP addresses.
    • Public virtual interface – to access all AWS public services using public IP addresses.
    • Transit virtual interface – to access one or more transit gateways associated with Direct Connect gateways.
  • Direct Connect connections are not redundant as each connection consists of a single dedicated connection between ports on your router and an Amazon router
  • Direct Connect High Availability can be configured using
    • Multiple Direct Connect connections
    • Back-up IPSec VPN connection
  • SiteLink – enables sending data between AWS Direct Connect locations to create private network connections between offices and data centers in a global network, bypassing AWS Regions. Data travels over the shortest path between locations using the AWS global network backbone.
  • VIF Rate Limiters (Jun 2026) – supports Virtual Interface Rate Limiters on dedicated connections to prevent network congestion caused by unexpected traffic spikes on a VIF, protecting other VIFs on the same connection.

LAGs

  • Direct Connect link aggregation group (LAG) is a logical interface that uses the Link Aggregation Control Protocol (LACP) to aggregate multiple connections at a single AWS Direct Connect endpoint, allowing you to treat them as a single, managed connection.
  • LAGs need the following
    • All connections in the LAG must use the same bandwidth.
    • A maximum of four connections in a LAG. Each connection in the LAG counts toward the overall connection limit for the Region.
    • All connections in the LAG must terminate at the same AWS Direct Connect endpoint.

Direct Connect Gateway

  • is a globally available resource to enable connections to multiple VPCs across different regions or AWS accounts.
  • allows you to connect an AWS Direct Connect connection to one or more VPCs in the account that are located in the same or different regions
  • allows connecting any participating VPCs from one private VIF, reducing Direct Connect management.
  • can be created in any public region and accessed from all other public regions
  • can also access the public resources in any AWS Region using a public virtual interface.
  • supports connecting up to 20 VPCs (via VGWs) globally over a single private VIF.

AWS Interconnect – Multicloud

  • is a new managed connectivity service (GA Apr 2026) that simplifies multicloud connectivity between AWS and other cloud service providers.
  • provides simple, resilient, high-speed private connections to other CSPs without needing to manage physical cross-connects or third-party providers.
  • attaches to a Direct Connect Gateway on the AWS side.
  • supported CSPs:
    • Google Cloud – Generally Available
    • Oracle Cloud Infrastructure (OCI) – Preview (May 2026)
    • Microsoft Azure – Coming later in 2026
  • offers a Free Tier – fully managed 500 Mbps interconnect to another CSP at no charge on the AWS side (May 2026).
  • eliminates complex multicloud networking setups that previously required physical Direct Connect connections and manual peering arrangements.

Amazon VPC Lattice

  • is an application networking service that consistently connects, monitors, and secures communications between services and resources across VPCs and accounts.
  • automatically manages network connectivity and application layer routing between services across different VPCs and AWS accounts.
  • abstracts IP address dependencies, allowing applications to communicate securely without direct network routing.
  • supports HTTP, HTTPS, gRPC, TLS, and TCP protocols.
  • key features include:
    • Service Networks – logical grouping of services with shared access and observability policies.
    • Service Network VPC Endpoints – allows VPCs to connect to service networks via VPC endpoints.
    • VPC Resources Support (re:Invent 2024) – enables connectivity to TCP resources such as databases, domain names, and IP addresses across VPCs and accounts.
    • Auth Policies – fine-grained access control using IAM-based policies at the service network and service level.
  • can replace complex Transit Gateway and PrivateLink configurations for service-to-service communication within a Region.
  • does not natively support cross-Region service access; requires a proxy solution for external Region connectivity.

Amazon VPC Route Server

  • is a new managed service (GA Apr 2025) that enables dynamic routing within Amazon VPC using Border Gateway Protocol (BGP).
  • allows deploying endpoints in a VPC and peering them with virtual appliances to advertise routes using BGP.
  • filters received routes using standard BGP attributes and propagates selected routes to specified VPC route tables.
  • dynamically updates VPC and internet gateway route tables with preferred IPv4 or IPv6 routes for routing fault tolerance.
  • eliminates the need for complex scripting or Lambda-based failover mechanisms for virtual appliance routing.
  • key use cases:
    • Automatic active/standby failover for inspection appliances
    • Dynamic routing between cloud applications and on-premises systems via virtual appliances
    • Integration with Transit Gateway for centralized inspection architectures
  • Logging Enhancements (Jun 2025) – provides real-time monitoring of BGP and BFD session states, historical peer-to-peer session data, with delivery via CloudWatch, S3, Data Firehose, or AWS CLI.

References