SES is a fully managed, cloud-based email service that provides an easy, cost-effective way to send and receive email using your own email addresses and domains.
can be used to send both transactional and marketing emails securely, and globally at scale.
processes over a trillion emails each year for customers worldwide across various industries.
acts as an outbound email server and eliminates the need to support its own software or applications to do the heavy lifting of email transport.
acts as an inbound email server to receive emails that can help develop software solutions such as email autoresponders, email unsubscribe systems, and applications that generate customer support tickets from incoming emails.
existing email server can also be configured to send outgoing emails through SES with no change in any settings in the email clients.
Maximum message size including attachments is 40 MB per message (after base64 encoding) when using the SESv2 API or SMTP.
integrated with CloudWatch, CloudTrail, Amazon EventBridge, and Amazon SNS for monitoring and notifications.
available in 24 AWS Regions, including AWS GovCloud (US) Regions.
SES Key Features
Compatible with SMTP
Applications can send email using the SES API (v2 recommended), AWS SDKs in many supported languages (Java, .NET, PHP, Python, Ruby, Go, JavaScript), or the AWS CLI.
Optimized for the highest levels of uptime, availability, and scales as per the demand.
provides statistics on email deliveries, bounces, feedback loop results, emails opened, clicks, etc.
supports DomainKeys Identified Mail (DKIM), Sender Policy Framework (SPF), and Domain-based Message Authentication, Reporting and Conformance (DMARC).
supports flexible deployment: shared, dedicated, and managed dedicated IPs (M-DIPs).
supports attachments with many popular content formats, including documents, images, audio, and video, and scans every attachment for viruses and malware.
integrates with KMS to provide the ability to encrypt the mail that it writes to the S3 bucket.
uses client-side encryption to encrypt the mail before it sends the email to S3.
supports inline email templates directly within API requests, eliminating the need to manage template resources separately.
supports HTTPS custom tracking domains for open and click tracking.
supports configurable maximum delivery time for time-sensitive messages.
enables customers to connect an SES SMTP endpoint to a VPC through a VPC endpoint powered by AWS PrivateLink.
SES v2 API
AWS recommends using the SESv2 API for all new implementations.
While SESv1 API continues to be supported, all new features and capabilities are only available through the SESv2 API.
SESv2 API supports email size of up to 40 MB for both inbound and outbound emails by default.
Migrating to SESv2 API provides access to features like Virtual Deliverability Manager, Mail Manager, Tenants, and Global Endpoints.
Virtual Deliverability Manager (VDM)
VDM is an SES feature that helps enhance email deliverability by providing insights into sending and delivery data.
provides three core components:
Deliverability Insights – view at-a-glance reports on sending and delivery data (bounce rates, opens, clicks) broken down by ISP, sender identity, and configuration set.
Recommendations – notifies senders of deliverability issues and provides actionable recommendations (e.g., DKIM, DMARC configuration issues, BIMI gap detection).
Automatic Implementation – option to allow SES to automatically implement email deliverability improvements like optimizing delivery patterns.
includes automated complaint rate insights as an early warning system to protect sender reputation.
tracks every email’s journey, uncovering opportunities to improve delivery and engagement rates.
Mail Manager
Mail Manager (launched May 2024) provides comprehensive tools to simplify managing large volumes of email communications.
acts as a centralized email gateway for routing, filtering, archiving, and compliance across inbound, outbound, and internal email.
Key capabilities include:
Ingress Endpoints – dedicated email ingress points with IP filtering, TLS, and mutual TLS (mTLS) authentication support.
Rules Engine – powerful rule-based email processing with conditions and actions for routing, archiving, and security enforcement.
SMTP Relay – relay emails to Google Workspace, Microsoft 365, or other email destinations.
Email Archiving – flexible archiving features to meet compliance and record-keeping requirements.
Full Lifecycle Logging – end-to-end logging to CloudWatch, S3, and Firehose.
integrates with Amazon Q Business for email indexing and queries.
supports email journaling and echo spoofing prevention.
available in 17+ AWS Regions including AWS GovCloud (US).
supports Lambda function invocation and Bounce actions directly in rules (added April 2026).
Global Endpoints
Global Endpoints (launched December 2024) provides multi-region resilience for email sending.
allows customers to add a secondary Region, dividing workloads equally in a load-balanced state.
if either Region suffers an outage, traffic automatically shifts to the healthy Region with no customer intervention.
both Regions develop warmed-up IPs in parallel, ensuring both are ready to support 100% of workload at any time.
synchronizes critical parameters between chosen Regions automatically.
compatible with Virtual Deliverability Manager (VDM) and Dedicated IPs (DIPs/M-DIPs).
Tenant Management
SES Tenant Management (launched August 2025) enables isolation and reputation management at the individual tenant level.
allows creation of up to 10,000 isolated tenants within a single AWS account (increasable to 300,000 on request).
each tenant can have its own email identities, configuration sets, templates, and independent reputation metrics.
addresses the challenge where one tenant’s poor email practices could previously pause an entire SES account.
includes automated pause mechanism to limit damage from problematic senders.
enables organizations to manage multiple email streams independently while maintaining centralized oversight.
Dedicated IPs
SES supports three types of IP deployment:
Shared IPs – default, cost-effective option; reputation determined by all emails sent from the shared pool.
Dedicated IPs (Standard) – customer leases dedicated IPs for sole sending reputation control; requires manual warm-up.
Dedicated IPs (Managed / M-DIPs) – AWS automates provisioning, warming up, and scaling of dedicated IPs; pool automatically scales based on usage and ISP policies.
Managed Dedicated IPs eliminate manual support cases and handle IP warmup per ISP individually.
Email Authentication & Bulk Sender Requirements
Gmail and Yahoo implemented new requirements for bulk senders (5,000+ messages/day) effective February 2024, with Microsoft following in May 2025.
Requirements include:
Domain Authentication – SPF, DKIM passing; DMARC record with at least p=none.
One-Click Unsubscribe – RFC 8058 List-Unsubscribe and List-Unsubscribe-Post headers required for bulk/marketing mail.
Low Complaint Rates – spam complaint rates must stay under 0.3% threshold.
SES supports one-click unsubscribe through the subscription management feature and List-Unsubscribe headers.
SES supports BIMI (Brand Indicators for Message Identification) with VDM gap detection.
Event Publishing & Monitoring
SES can publish email sending events to multiple destinations:
Amazon CloudWatch
Amazon Data Firehose
Amazon SNS
Amazon EventBridge (added June 2024) – enables routing events to any EventBridge-supported service.
VDM Advisor recommendations are also published to EventBridge.
supports custom values in feedback headers for better tracking transparency.
TLS version auto-tagging for outgoing messages provides visibility into connection security.
Sending Limits
Production SES has a set of sending limits which include:
Sending Quota – max number of emails in a 24-hour period.
Maximum Send Rate – max number of emails per second.
SES automatically adjusts the limits upward as long as emails are of high quality and they are sent in a controlled manner, as any spike in the email sent might be considered to be spam.
Limits can also be raised by submitting a Quota increase request.
Email Receiving
SES provides complete control over which emails are accepted and what to do with them.
Accept or reject mail based on email address, IP address, or domain of the sender.
After accepting email, actions include:
Store in an Amazon S3 bucket
Execute custom code using AWS Lambda
Publish notifications to Amazon SNS
Route through Mail Manager rules for advanced processing
Mail Manager extends receiving capabilities with SMTP relay to Google Workspace, Microsoft 365, or Amazon Connect.
SES Best Practices
Send high-quality and real production content that the recipients want.
Only send to those who have signed up for the mail.
Implement one-click unsubscribe (RFC 8058) for bulk/marketing emails to comply with Gmail/Yahoo/Microsoft requirements.
Unsubscribe recipients who have not interacted with the business recently.
Have low bounce and complaint rates and remove bounced or complained addresses, using SNS or EventBridge to monitor bounces and complaints, treating them as an opt-out.
Implement SPF, DKIM, and DMARC authentication for all sending domains.
Monitor the sending activity using VDM dashboards and reputation metrics.
Keep spam complaint rates below 0.3%.
Use Global Endpoints for multi-region resilience for critical email workloads.
Use Tenant Management to isolate reputation for multi-tenant email platforms.
Amazon Pinpoint Migration Note
Amazon Pinpoint will reach end of support on October 30, 2026 (no new customers accepted since May 20, 2025).
For email capabilities, customers should migrate to Amazon SES with:
SES for transactional and bulk email sending
SES Tenant Management for multi-tenant isolation
SES Mail Manager for routing and compliance
AWS End User Messaging for SMS/push notification channels
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.
What does Amazon SES stand for?
Simple Elastic Server
Simple Email Service
Software Email Solution
Software Enabled Server
Your startup wants to implement an order fulfillment process for selling a personalized gadget that needs an average of 3-4 days to produce with some orders taking up to 6 months you expect 10 orders per day on your first day. 1000 orders per day after 6 months and 10,000 orders after 12 months. Orders coming in are checked for consistency then dispatched to your manufacturing plant for production quality control packaging shipment and payment processing. If the product does not meet the quality standards at any stage of the process employees may force the process to repeat a step. Customers are notified via email about order status and any critical issues with their orders such as payment failure. Your case architecture includes AWS Elastic Beanstalk for your website with an RDS MySQL instance for customer data and orders. How can you implement the order fulfillment process while making sure that the emails are delivered reliably? [PROFESSIONAL]
Add a business process management application to your Elastic Beanstalk app servers and re-use the RDS database for tracking order status use one of the Elastic Beanstalk instances to send emails to customers.
Use SWF with an Auto Scaling group of activity workers and a decider instance in another Auto Scaling group with min/max=1 Use the decider instance to send emails to customers.
Use SWF with an Auto Scaling group of activity workers and a decider instance in another Auto Scaling group with min/max=1 use SES to send emails to customers.
Use an SQS queue to manage all process tasks Use an Auto Scaling group of EC2 Instances that poll the tasks and execute them. Use SES to send emails to customers.
A company sends millions of marketing emails daily using Amazon SES. They need to ensure emails continue to be delivered even if one AWS Region experiences an outage. What SES feature should they use?
Virtual Deliverability Manager with automatic recommendations
Dedicated IPs (Managed) with automatic warmup
Global Endpoints with a primary and secondary Region configuration
Mail Manager with SMTP relay to multiple regions
A SaaS company uses Amazon SES to send emails on behalf of hundreds of customers. They want to ensure that one customer’s poor email practices do not affect the sending reputation of other customers. What is the MOST appropriate solution?
Create separate AWS accounts for each customer
Use separate configuration sets for each customer
Use dedicated IPs for each customer
Use SES Tenant Management to create isolated tenants with independent reputation metrics
A company needs to process incoming emails, archive them for compliance, apply security filtering, and route them to different internal systems based on recipient addresses. Which Amazon SES feature provides this capability?
SES receipt rules with S3 actions
Virtual Deliverability Manager
SES Mail Manager with ingress endpoints, traffic policies, and rules engine
SES event publishing with EventBridge
A company sending bulk marketing emails through Amazon SES notices that their inbox placement rate has dropped. They want SES to automatically optimize email delivery patterns without manual intervention. Which feature should they enable?
Dedicated IPs (Managed)
Mail Manager traffic policies
Virtual Deliverability Manager with automatic implementation enabled
Global Endpoints with load balancing
Which of the following are requirements that Gmail and Yahoo enforce for bulk email senders since February 2024? (Select THREE)
Aurora Global Database provides a relational database supporting MySQL and PostgreSQL.
Aurora Global Database consists of one primary AWS Region where the data is mastered, and up to five read-only, secondary AWS Regions.
Aurora cluster in the primary AWS Region performs both read and write operations. The clusters in the secondary Regions enable low-latency reads.
Aurora replicates data to the secondary AWS Regions with a typical latency of under a second.
Secondary clusters can be scaled independently by adding one or more DB instances (Aurora Replicas) to serve read-only workloads.
Aurora Global Database uses dedicated infrastructure to replicate the data, leaving database resources available entirely to serve applications.
Applications with a worldwide footprint can use reader instances in the secondary AWS Regions for low-latency reads.
Typical cross-region replication takes less than 1 second.
In case of a disaster or an outage, one of the clusters in a secondary AWS Region can be promoted to take full read/write workloads in under a minute.
However, the process is not automatic. If the primary region becomes unavailable, you must manually remove a secondary region from an Aurora Global Database and promote it to take full reads and writes. You will also need to point the application to the newly promoted region.
Architecture: Single-master, multi-reader (one primary region for writes, multiple secondary regions for reads).
Consistency: Eventual consistency for cross-region reads.
ARC Integration (June 2026): Amazon Application Recovery Controller (ARC) Region switch now supports Aurora serverless scaling and provisioned scaling execution blocks, automating database scaling during multi-Region failover orchestration.
DynamoDB Global tables provide a fully managed, multi-Region, and multi-active database that delivers fast, local, read and write performance for massively scaled, global applications.
Global tables replicate the DynamoDB tables automatically across the choice of AWS Regions and enable reads and writes on all instances.
DynamoDB global table consists of multiple replica tables (one per AWS Region). Every replica has the same table name and the same primary key schema. When an application writes data to a replica table in one Region, DynamoDB propagates the write to the other replica tables in the other AWS Regions automatically.
Global tables enable the read and write of data locally providing single-digit-millisecond latency for the globally distributed application at any scale.
DynamoDB Global tables are designed for 99.999% availability.
DynamoDB Global tables enable the applications to stay highly available even in the unlikely event of isolation or degradation of an entire Region. Applications can redirect to a different Region and perform reads and writes against a different replica table.
Cross-Account Replication (February 2026): DynamoDB Global Tables now support replication across multiple AWS accounts, providing account-level isolation for stronger governance, security, and blast-radius control. Currently supported for MREC tables only.
DynamoDB Global Tables Consistency Modes
DynamoDB Global Tables support two consistency modes:
Provides asynchronous replication with approximately 1-second replication latency for tables between two or more Regions.
Multi-active: All replicas accept reads and writes.
Conflict Resolution: Last Write Wins based on internal timestamp.
RPO: Approximately 1 second (replication delay).
Best for applications that can tolerate eventual consistency.
Supports multi-account global tables for account-level isolation (February 2026).
Multi-Region Strong Consistency (MRSC) – January 2025
Announced at AWS re:Invent 2024 and generally available in January 2025.
Provides synchronous replication across Regions.
Strongly consistent reads always return the latest version of an item, irrespective of the Region.
Zero RPO: Enables Recovery Point Objective of zero.
Item changes are synchronously replicated to at least one other Region before write returns success.
Deployment: Must be deployed in exactly three Regions (3 replicas OR 2 replicas + 1 witness).
Regional Availability: Three Region sets (US, EU, AP) – cannot span Region sets.
Trade-off: Higher write latency compared to MREC due to synchronous replication.
Best for applications requiring global strong consistency and zero data loss.
AWS FIS Integration (January 2026): MRSC global tables now support application resiliency testing with AWS Fault Injection Service (FIS), enabling controlled fault injection experiments to validate failover behavior and regional resilience.
Does not support multi-account model (cross-account replication is MREC only).
Amazon Aurora DSQL (GA May 2025)
Amazon Aurora DSQL is a serverless distributed SQL database with active-active high availability, announced at re:Invent 2024 and generally available since May 27, 2025.
Provides PostgreSQL-compatible (based on PostgreSQL 16) distributed SQL with multi-Region strong consistency.
Active-active architecture: All database resources are peers capable of handling both read and write traffic, within a Region and across Regions. No leader, no failover lag.
Strong consistency: All reads and writes to any Regional endpoint are strongly consistent and durable — not eventually consistent.
Zero RPO: Synchronous data replication with automated zero data loss failover.
Serverless: No servers to provision, patch, or manage. Scales to zero when idle. Provisions in under 60 seconds.
Designed for 99.99% single-Region and 99.999% multi-Region availability.
Multi-Region deployment: Supports linked multi-Region clusters (currently two Regions).
Automatic failover: No manual intervention required. Applications use DNS-based routing (Route 53) for automatic Region redirection.
Independently scales reads, writes, compute, and storage with no manual intervention.
Supports SQL including secondary indexes, joins, and transactions — unlike DynamoDB’s NoSQL model.
Limitations: Based on PostgreSQL 16 but does not support all PostgreSQL features. Subset of commonly used queries and features supported.
Fills the gap between DynamoDB’s serverless economics and Aurora PostgreSQL’s SQL power with global consistency.
Comparison Table
Feature
Aurora Global Database
DynamoDB Global Tables (MREC)
DynamoDB Global Tables (MRSC)
Aurora DSQL
Database Type
Relational (MySQL, PostgreSQL)
NoSQL (Key-Value, Document)
NoSQL (Key-Value, Document)
Relational (PostgreSQL-compatible)
Architecture
Single-master, multi-reader
Multi-active (all replicas read/write)
Multi-active (all replicas read/write)
Active-active (all peers read/write)
Max Regions
1 primary + 5 secondary (6 total)
Unlimited (any Region with DynamoDB)
Exactly 3 Regions
2 linked Regions (multi-Region cluster)
Replication Type
Asynchronous
Asynchronous
Synchronous
Synchronous
Replication Latency
< 1 second
~1 second
Synchronous (no delay)
Synchronous (no delay)
Cross-Region Writes
No (primary region only)
Yes (all replicas)
Yes (all replicas)
Yes (all peers)
Consistency
Eventual (cross-region reads)
Eventual (cross-region reads)
Strong (all reads)
Strong (all reads and writes)
RPO
~1 second
~1 second
Zero (0)
Zero (0)
RTO
< 1 minute (manual failover)
Seconds (automatic)
Seconds (automatic)
Automatic (no manual intervention)
Failover
Manual promotion required
Automatic (redirect to another replica)
Automatic (redirect to another replica)
Automatic (DNS-based routing)
Availability SLA
99.99%
99.999%
99.999%
99.999% (multi-Region)
Serverless
No (instance-based, Serverless v2 option)
Yes (on-demand or provisioned)
Yes (on-demand or provisioned)
Yes (fully serverless, scales to zero)
SQL Support
Full SQL (MySQL/PostgreSQL)
NoSQL API only
NoSQL API only
PostgreSQL-compatible SQL (subset)
Cross-Account
No
Yes (February 2026)
No
No
Use Cases
Complex queries, joins, transactions, relational data
Inventory Management: Global inventory with strict consistency.
Compliance Requirements: Regulations requiring zero data loss.
Three-Region Deployment: Can deploy in exactly three regions within same region set (US, EU, or AP).
When to Choose Aurora DSQL
Global SQL with Strong Consistency: Need SQL (joins, indexes, transactions) with multi-region strong consistency.
Active-Active SQL Writes: Need both regions to accept writes — unlike Aurora Global Database’s single-master.
Serverless with Scale-to-Zero: Want to avoid instance management entirely with pay-per-use pricing.
Zero RPO + SQL: Need zero data loss with relational database capabilities.
Financial Transactions: Global-scale financial apps requiring strong consistency and SQL.
Automatic Failover: Need automated zero-intervention failover (unlike Aurora Global Database’s manual process).
Two-Region Deployment: Workload fits within a two-region active-active topology.
Note: Does not support full PostgreSQL feature set — evaluate supported features for your use case.
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.
A company needs to implement a relational database with a multi-region disaster recovery Recovery Point Objective (RPO) of 1 second and a Recovery Time Objective (RTO) of 1 minute. Which AWS solution can achieve this?
Amazon Aurora Global Database
Amazon DynamoDB global tables
Amazon RDS for MySQL with Multi-AZ enabled
Amazon RDS for MySQL with a cross-Region snapshot copy
A financial services company requires a globally distributed database with zero data loss (RPO = 0) and strong consistency across all regions. Which solution should they choose?
Amazon Aurora Global Database
Amazon DynamoDB Global Tables with MREC
Amazon DynamoDB Global Tables with MRSC
Amazon RDS with cross-region read replicas
A company needs a multi-region database that supports writes in all regions simultaneously with automatic failover. Which solution provides this capability?
Amazon Aurora Global Database
Amazon DynamoDB Global Tables
Amazon RDS Multi-AZ
Amazon Aurora with read replicas
What is the primary difference between Aurora Global Database and DynamoDB Global Tables in terms of write operations?
Aurora supports writes in all regions, DynamoDB only in primary region
Aurora supports writes only in primary region, DynamoDB supports writes in all regions
Both support writes in all regions
Both support writes only in primary region
A company needs to deploy a DynamoDB Global Table with MRSC. How many regions must they deploy in?
Minimum 2 regions
Exactly 3 regions
Up to 5 regions
Unlimited regions
Which of the following statements about Aurora Global Database and DynamoDB Global Tables are correct? (Select TWO)
Aurora Global Database requires manual failover, DynamoDB Global Tables support automatic failover
Aurora Global Database supports NoSQL, DynamoDB supports SQL
DynamoDB Global Tables offer 99.999% availability, Aurora offers 99.99%
Aurora Global Database supports multi-active writes
DynamoDB MRSC has higher replication latency than Aurora
A company needs a globally distributed relational database with active-active writes, serverless operations, and strong consistency. They require SQL support including joins and transactions. Which AWS service best meets these requirements?
Amazon Aurora Global Database
Amazon DynamoDB Global Tables with MRSC
Amazon Aurora DSQL
Amazon RDS with read replicas
A company operates DynamoDB Global Tables and needs to replicate data across multiple AWS accounts for security isolation and governance. Which consistency mode supports this?
Multi-Region Eventual Consistency (MREC)
Multi-Region Strong Consistency (MRSC)
Both MREC and MRSC
Neither — cross-account replication is not supported
Which of the following AWS database solutions provides BOTH zero RPO and active-active multi-region writes with SQL support? (Select TWO)
AWS RDS Aurora is a relational database engine that combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases.
is a fully managed, MySQL- and PostgreSQL-compatible, relational database engine i.e. applications developed with MySQL can switch to Aurora with little or no changes.
delivers up to 6x the throughput of PostgreSQL and MySQL without requiring any changes to most applications
is fully managed as RDS manages the databases, handling time-consuming tasks such as provisioning, patching, backup, recovery, failure detection, and repair.
can scale storage automatically, based on the database usage, from 10GB to 128TiB (up to 256 TiB for Aurora MySQL and Aurora PostgreSQL as of July 2025) in 10GB increments with no impact on database performance
supports Aurora MySQL version 3 (MySQL 8.0 compatible), Aurora MySQL version 4 (MySQL 8.4 compatible, GA May 2026), and Aurora PostgreSQL (up to PostgreSQL 18 as of June 2026)
Aurora MySQL version 1 (MySQL 5.6 compatible) reached End of Life on Feb 28, 2023, and version 2 (MySQL 5.7 compatible) reached end of standard support on Oct 31, 2024 (Extended Support available)
Aurora DB Clusters
Aurora DB cluster consists of one or more DB instances and a cluster volume that manages the data for those DB instances.
A cluster volume is a virtual database storage volume that spans multiple AZs, with each AZ having a copy of the DB cluster data
Two types of DB instances make up an Aurora DB cluster:
Primary DB instance
Supports read and write operations, and performs all data modifications to the cluster volume.
Each DB cluster has one primary DB instance.
Aurora Replica
Connects to the same storage volume as the primary DB instance and supports only read operations.
Each DB cluster can have up to 15 Aurora Replicas in addition to the primary DB instance.
Provides high availability by locating Replicas in separate AZs
Aurora automatically fails over to a Replica in case the primary DB instance becomes unavailable.
Failover priority for Replicas can be specified.
Replicas can also offload read workloads from the primary DB instance
Aurora Multi-Master is no longer available. It was only supported on Aurora MySQL 5.6, which reached End of Life. For multi-writer use cases, consider Aurora Global Database with write forwarding or Amazon Aurora DSQL.
Aurora Connection Endpoints
Aurora involves a cluster of DB instances instead of a single instance
Endpoint refers to an intermediate handler with the hostname and port specified to connect to the cluster
Aurora uses the endpoint mechanism to abstract these connections
Cluster endpoint
Cluster endpoint (or writer endpoint) for a DB cluster connects to the current primary DB instance for that DB cluster.
Cluster endpoint is the only one that can perform write operations such as DDL statements as well as read operations
Each DB cluster has one cluster endpoint and one primary DB instance
Cluster endpoint provides failover support for read/write connections to the DB cluster. If a DB cluster’s current primary DB instance fails, Aurora automatically fails over to a new primary DB instance.
During a failover, the DB cluster continues to serve connection requests to the cluster endpoint from the new primary DB instance, with minimal interruption of service.
Reader endpoint
Reader endpoint for a DB cluster provides load-balancing support for read-only connections to the DB cluster.
Use the reader endpoint for read operations, such as queries.
Reader endpoint reduces the overhead on the primary instance by processing the statements on the read-only Replicas.
Each DB cluster has one reader endpoint.
If the cluster contains one or more Replicas, the reader endpoint load balances each connection request among the Replicas.
Custom endpoint
Custom endpoint for a DB cluster represents a set of DB instances that you choose.
Aurora performs load balancing and chooses one of the instances in the group to handle the connection.
An Aurora DB cluster has no custom endpoints until one is created and up to five custom endpoints can be created for each provisioned cluster.
Custom endpoints are supported on both provisioned and Aurora Serverless v2 clusters.
Instance endpoint
An instance endpoint connects to a specific DB instance within a cluster and provides direct control over connections to the DB cluster.
Each DB instance in a DB cluster has its own unique instance endpoint. So there is one instance endpoint for the current primary DB instance of the DB cluster, and there is one instance endpoint for each of the Replicas in the DB cluster.
High Availability and Replication
Aurora is designed to offer greater than 99.99% availability
provides data durability and reliability
by replicating the database volume six ways across three Availability Zones in a single region
backing up the data continuously to S3.
transparently recovers from physical storage failures; instance failover typically takes less than 30 seconds.
automatically fails over to a new primary DB instance, if the primary DB instance fails, by either promoting an existing Replica to a new primary DB instance or creating a new primary DB instance
automatically divides the database volume into 10GB segments spread across many disks. Each 10GB chunk of the database volume is replicated six ways, across three Availability Zones
is designed to transparently handle
the loss of up to two copies of data without affecting database write availability and
up to three copies without affecting read availability.
provides self-healing storage. Data blocks and disks are continuously scanned for errors and repaired automatically.
Replicas share the same underlying volume as the primary instance. Updates made by the primary are visible to all Replicas.
As Replicas share the same data volume as the primary instance, there is virtually no replication lag.
Any Replica can be promoted to become primary without any data loss and therefore can be used for enhancing fault tolerance in the event of a primary DB Instance failure.
To increase database availability, 1 to 15 replicas can be created in any of 3 AZs, and RDS will automatically include them in failover primary selection in the event of a database outage.
Aurora Failovers
Aurora automatically fails over, if the primary instance in a DB cluster fails, in the following order:
If Aurora Read Replicas are available, promote an existing Read Replica to the new primary instance.
If no Read Replicas are available, then create a new primary instance.
If there are multiple Aurora Read Replicas, the criteria for promotion is based on the priority that is defined for the Read Replicas.
Priority numbers can vary from 0 to 15 and can be modified at any time.
Aurora promotes the Replica with the highest priority (lowest tier number) to the new primary instance.
For Read Replicas with the same priority, Aurora promotes the replica that is largest in size or in an arbitrary manner.
During the failover, AWS modifies the cluster endpoint to point to the newly created/promoted DB instance.
Applications experience a minimal interruption of service if they connect using the cluster endpoint and implement connection retry logic.
Security
Aurora uses SSL/TLS (AES-256) to secure the connection between the database instance and the application
Starting February 2026, all new Aurora clusters are encrypted at rest by default using AWS-owned keys, with no cost or performance impact.
Encryption and decryption are handled seamlessly.
With encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, snapshots, and replicas in the same cluster.
Encryption of existing unencrypted Aurora instances is not supported. Create a new encrypted Aurora instance and migrate the data
Aurora supports IAM database authentication, allowing token-based authentication without passwords.
Backup and Restore
Automated backups are always enabled on Aurora DB Instances.
Backups do not impact database performance.
Aurora also allows the creation of manual snapshots.
Aurora automatically maintains 6 copies of the data across 3 AZs and will automatically attempt to recover the database in a healthy AZ with no data loss.
If in any case, the data is unavailable within Aurora storage,
DB Snapshot can be restored or
the point-in-time restore operation can be performed to a new instance. The latest restorable time for a point-in-time restore operation can be up to 5 minutes in the past.
Restoring a snapshot creates a new Aurora DB instance
Deleting the database deletes all the automated backups (with an option to create a final snapshot), but would not remove the manual snapshots.
Snapshots (including encrypted ones) can be shared with other AWS accounts
Aurora Parallel Query
Aurora Parallel Query refers to the ability to push down and distribute the computational load of a single query across thousands of CPUs in Aurora’s storage layer.
Without Parallel Query, a query issued against an Aurora database would be executed wholly within one instance of the database cluster; this would be similar to how most databases operate.
Parallel Query is a good fit for analytical workloads requiring fresh data and good query performance, even on large tables.
Parallel Query provides the following benefits
Faster performance: Parallel Query can speed up analytical queries by up to 2 orders of magnitude.
Operational simplicity and data freshness: you can issue a query directly over the current transactional data in your Aurora cluster.
Transactional and analytical workloads on the same database: Parallel Query allows Aurora to maintain high transaction throughput alongside concurrent analytical queries.
Parallel Query can be enabled and disabled dynamically at both the global and session level using the aurora_parallel_query parameter.
Parallel Query is available for all current Aurora MySQL versions (MySQL 8.0 and 8.4 compatible).
Aurora Scaling
Aurora storage scaling is built-in and will automatically grow, up to 128 TiB (up to 256 TiB for Aurora MySQL and PostgreSQL as of July 2025), in 10GB increments with no impact on database performance.
There is no need to provision storage in advance
Compute Scaling
Instance scaling
Vertical scaling of the master instance. Memory and CPU resources are modified by changing the DB Instance class.
scaling the read replica and promoting it to master using forced failover which provides a minimal downtime
Read scaling
provides horizontal scaling with up to 15 read replicas
Auto Scaling
Scaling policies to add read replicas with min and max replica count based on scaling CloudWatch CPU or connections metrics condition
Aurora Serverless v2
Provides automatic scaling from 0 to 256 ACUs (512 GiB memory)
Supports scale-to-zero for cost optimization during periods of inactivity (Nov 2024)
Aurora Backtrack
Backtracking “rewinds” the DB cluster to the specified time
Backtracking performs in-place restore and does not create a new instance. There is minimal downtime associated with it.
Backtracking is available for Aurora with MySQL compatibility
Backtracking is not a replacement for backing up the DB cluster so that you can restore it to a point in time.
With backtracking, there is a target backtrack window and an actual backtrack window:
Target backtrack window is the amount of time you WANT the DB cluster can be backtracked for e.g 24 hours. The limit for a backtrack window is 72 hours.
Actual backtrack window is the actual amount of time you CAN backtrack the DB cluster, which can be smaller than the target backtrack window. The actual backtrack window is based on the workload and the storage available for storing information about database changes, called change records
DB cluster with backtracking enabled generates change records.
Aurora retains change records for the target backtrack window and charges an hourly rate for storing them.
Both the target backtrack window and the workload on the DB cluster determine the number of change records stored.
Workload is the number of changes made to the DB cluster in a given amount of time. If the workload is heavy, you store more change records in the backtrack window than you do if your workload is light.
Backtracking affects the entire DB cluster and can’t selectively backtrack a single table or a single data update.
Backtracking provides the following advantages over traditional backup and restore:
Undo mistakes – revert destructive action, such as a DELETE without a WHERE clause
Backtrack DB cluster quickly – Restoring a DB cluster to a point in time launches a new DB cluster and restores it from backup data or a DB cluster snapshot, which can take hours. Backtracking a DB cluster doesn’t require a new DB cluster and rewinds the DB cluster in minutes.
Explore earlier data changes – repeatedly backtrack a DB cluster back and forth in time to help determine when a particular data change occurred
⚠️ Aurora Serverless v1 reached End of Life on March 31, 2025. All v1 clusters have been automatically migrated to Aurora Serverless v2. The information below applies to Aurora Serverless v2.
Amazon Aurora Serverless v2 is an on-demand, autoscaling configuration for the MySQL-compatible and PostgreSQL-compatible editions of Aurora.
An Aurora Serverless v2 DB cluster automatically scales capacity up or down based on the application’s needs, measured in Aurora Capacity Units (ACUs).
enables running database in the cloud without managing any database instances.
provides a cost-effective option for variable, intermittent, or unpredictable workloads.
Key features of Aurora Serverless v2:
Scale to zero – supports scaling down to 0 ACUs, automatically pausing after a period of inactivity and resuming when a connection is requested (Nov 2024)
Maximum capacity – scales up to 256 ACUs (512 GiB memory)
Fine-grained scaling – adjusts capacity in 0.5 ACU increments
Instant scaling – scales instantly to hundreds of thousands of transactions in a fraction of a second
Mixed configurations – can be used alongside provisioned instances in the same cluster
30% better performance – latest platform version (v3, 2026) offers up to 30% performance improvement with enhanced workload-aware scaling
use cases include
Infrequently-Used Applications
New Applications – where the needs and instance size are yet to be determined.
Variable and Unpredictable Workloads – scale as per the needs
Development and Test Databases
Multi-tenant Applications
AI/ML and Agentic Workloads
Supports custom endpoints (unlike Serverless v1)
Supports Aurora Global Database
DB cluster can be accessed from within a VPC. Public access can be configured.
Aurora Global Database
Aurora Global Database consists of one primary AWS Region where the data is mastered, and up to ten read-only, secondary AWS Regions (increased from five in May 2025).
Aurora cluster in the primary AWS Region where your data is mastered performs both read and write operations. The clusters in the secondary Regions enable low-latency reads.
Aurora replicates data to the secondary AWS Regions with a typical latency of under a second.
Secondary clusters can be scaled independently by adding one or more DB instances (Aurora Replicas) to serve read-only workloads.
Aurora Global Database uses dedicated infrastructure to replicate the data, leaving database resources available entirely to serve applications.
Applications with a worldwide footprint can use reader instances in the secondary AWS Regions for low-latency reads.
In case of a disaster or an outage, one of the clusters in a secondary AWS Region can be promoted to take full read/write workloads in under a minute.
Write Forwarding – secondary region clusters can accept writes that are transparently forwarded to the primary region, simplifying global application architecture. Supported for both Aurora MySQL and Aurora PostgreSQL (version 16+).
Global Database Writer Endpoint (Oct 2024) – a fully managed endpoint that automatically routes writes to the current primary region, eliminating application code changes after switchover or failover.
Managed Switchover and Failover – supports planned cross-region switchover (typically under 30 seconds as of May 2025) and unplanned failover for disaster recovery.
Aurora I/O-Optimized
Aurora I/O-Optimized is a cluster configuration that provides improved price performance for I/O-intensive workloads (launched May 2023).
Provides up to 40% cost savings when I/O spend exceeds 25% of current Aurora database spend.
Eliminates charges for read and write I/O operations – you pay only for instance and storage usage.
Supported on both Aurora Serverless v2 and provisioned instances.
Can switch existing clusters to I/O-Optimized once every 30 days; can switch back to Aurora Standard at any time.
Available for both Aurora MySQL and Aurora PostgreSQL.
Aurora Optimized Reads
Aurora Optimized Reads uses local NVMe-based SSD storage available on specific instance types (r6gd, r6id, r8gd, m8gd) to improve query performance.
Provides two features:
Tiered Cache – extends DB instance caching capacity by up to 5x the instance memory by caching pages evicted from the buffer pool on local NVMe storage, providing up to 8x better latency for data previously fetched from Aurora storage.
Temporary Objects – stores temporary tables and sort data on local NVMe, reducing I/O to network-based storage.
Especially beneficial for workloads with datasets exceeding instance memory, including vector search (pgvector) workloads.
Available for Aurora PostgreSQL and Aurora MySQL.
Aurora Zero-ETL Integrations
Aurora zero-ETL integration replicates data from an Aurora DB cluster to supported analytics destinations in near real time, eliminating the need for custom ETL pipelines.
Supported targets include:
Amazon Redshift – for analytics and BI workloads (GA for both Aurora MySQL and Aurora PostgreSQL, 2024)
Amazon SageMaker Lakehouse – for ML and data lake workloads
Within seconds of transactional data being written to Aurora, it is seamlessly available in the target data warehouse.
Fully managed – no infrastructure to manage, no pipelines to build or maintain.
Enables running analytics and ML on transactional data without impacting the production database.
Aurora PostgreSQL Limitless Database
Aurora PostgreSQL Limitless Database provides automated horizontal scaling beyond the limits of a single Aurora instance (GA October 2024).
Scales to handle millions of write transactions per second and petabytes of data within a single database.
Automatically distributes workload across multiple Aurora writer instances using sharding, while maintaining the simplicity of a single database interface.
Uses a router-shard architecture:
Transaction routers – accept connections, route queries to appropriate shards
Data access shards – store subsets of sharded tables, full copies of reference tables, and standard tables
Maintains distributed ACID transactions across shards.
No application changes required beyond specifying which tables to shard.
Serverless – automatically scales based on workload demand.
Amazon Aurora DSQL
Amazon Aurora DSQL is a serverless distributed SQL database designed for always-available applications (GA May 2025).
PostgreSQL-compatible with an active-active distributed architecture.
Designed for 99.99% availability in single-Region and 99.999% availability in multi-Region configurations.
Key features:
Offers the fastest distributed SQL reads and writes
Zero infrastructure management and zero downtime maintenance
Supports strong consistency for all reads and writes to any Regional endpoint
Scales to meet any workload demand without database sharding or instance upgrades
Supports up to 256 TiB of storage
Ideal for globally distributed applications requiring strong consistency, such as financial transactions, gaming, and multi-region SaaS.
Differs from Aurora Global Database: DSQL provides active-active multi-region writes with strong consistency, while Global Database uses asynchronous replication with a single primary writer region.
Creating a clone is faster and more space-efficient than physically copying the data using a different technique such as restoring a snapshot.
Aurora cloning uses a copy-on-write protocol.
Aurora clone requires only minimal additional space when first created. In the beginning, Aurora maintains a single copy of the data, which is used by both the original and new DB clusters.
Aurora allocates new storage only when data changes, either on the source cluster or the cloned cluster.
RDS Extended Support
Amazon RDS Extended Support allows running Aurora MySQL version 2 (MySQL 5.7 compatible) and Aurora PostgreSQL older versions beyond their standard support end dates.
Provides critical security patches after community end of life.
Charged at an additional hourly rate per vCPU.
Databases are automatically enrolled into Extended Support after their standard support end date.
Intended as a bridge during migration to newer major versions (Aurora MySQL 8.0/8.4, Aurora PostgreSQL 16/17/18).
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.
Company wants to use MySQL compatible relational database with greater performance. Which AWS service can be used?
Aurora
RDS
SimpleDB
DynamoDB
An application requires a highly available relational database with an initial storage capacity of 8 TB. The database will grow by 8 GB every day. To support expected traffic, at least eight read replicas will be required to handle database reads. Which option will meet these requirements?
DynamoDB
Amazon S3
Amazon Aurora
Amazon Redshift
A company is migrating their on-premise 10TB MySQL database to AWS. As a compliance requirement, the company wants to have the data replicated across three availability zones. Which Amazon RDS engine meets the above business requirement?
Use Multi-AZ RDS
Use RDS
Use Aurora
Use DynamoDB
A company has an application that requires a globally distributed database with multi-region read access and sub-second replication latency. The application must continue operating if an entire AWS Region becomes unavailable. Which solution meets these requirements?
Deploy Aurora with Multi-AZ enabled
Deploy RDS MySQL with cross-region read replicas
Deploy Aurora Global Database with secondary clusters in multiple regions
Deploy DynamoDB global tables
A startup is building a new application and needs a cost-effective database solution that can automatically scale compute capacity based on demand, including scaling to zero during periods of inactivity. The application uses PostgreSQL. Which is the MOST cost-effective solution?
Aurora provisioned with a db.t3.small instance
Aurora Serverless v2 with minimum capacity set to 0 ACUs
RDS PostgreSQL with a Reserved Instance
Aurora provisioned with Auto Scaling read replicas
A company runs an I/O-intensive OLTP workload on Aurora PostgreSQL. The database I/O costs account for 40% of the total Aurora spend. Which Aurora configuration would provide the best cost optimization? [Select TWO]
Switch to Aurora I/O-Optimized cluster configuration
Enable Aurora Parallel Query
Use Aurora Optimized Reads with r6gd instances for read-heavy replicas
Migrate to Aurora Serverless v1
Use Aurora Standard with provisioned IOPS
A company needs to run near real-time analytics on their Aurora MySQL transactional data in Amazon Redshift without building custom ETL pipelines. Which feature should they use?
Aurora Parallel Query
AWS Glue ETL jobs
Aurora zero-ETL integration with Amazon Redshift
Amazon Kinesis Data Firehose
A company needs a PostgreSQL-compatible database that can automatically scale write throughput horizontally to handle millions of transactions per second without manual sharding. Which solution should they use?
AWS Network Firewall is a stateful, fully managed, network firewall and intrusion detection and prevention service (IDS/IPS) for VPCs.
Network Firewall scales automatically with the network traffic, without the need for deploying and managing any infrastructure.
Network Firewall supports up to 100 Gbps of network traffic per firewall endpoint.
Network Firewall provides Layer 3-7 filtering with deep packet inspection (DPI), domain name filtering, and intrusion prevention capabilities compatible with Suricata rules.
Network Firewall supports native attachment to AWS Transit Gateway, eliminating the need for a separate inspection VPC and enabling capabilities such as flexible cost allocation through Transit Gateway metering policies.
AWS Network Firewall cost covers
an hourly rate for each firewall endpoint,
the amount of traffic and data processing charges, billed by the gigabyte, processed by the firewall endpoint,
an additional hourly rate per region and Availability Zone for Advanced Inspection (TLS inspection) with no additional data processing charges for Advanced Inspection traffic beyond standard processing charges,
standard AWS data transfer charges for all data transferred via the AWS Network Firewall,
hourly and data processing discounts on NAT Gateways that are service-chained with Network Firewall secondary endpoints.
Key features include:
TLS Inspection – decrypts and inspects encrypted outbound HTTPS traffic with SNI session holding for deeper visibility.
Flow Management – Flow Capture provides point-in-time snapshots of active flows for monitoring, and Flow Flush enables selective termination of specific connections.
Session State Replication – replicates flow state across firewall endpoints for high availability, ensuring seamless failover without session loss.
Transit Gateway Native Attachment – attaches directly to Transit Gateway, eliminating the inspection VPC and simplifying centralized architecture.
Managed Rules from AWS Marketplace – supports expanded managed rule groups from partners with up to 10 million domain name indicators and up to 1 million IP addresses per rule group.
Enhanced Console & Monitoring – includes PrivateLink Endpoint analysis, improved filtering for IP addresses and protocols, simplified policy management with point-and-click rule priority adjustment, and pre-configured fields for rule creation.
Gateway Load Balancer helps deploy, scale, and manage virtual appliances, such as firewalls, intrusion detection and prevention systems (IDS/IPS), and deep packet inspection systems.
is architected to handle millions of requests/second, volatile traffic patterns, and introduces extremely low latency.
Gateway Load Balancer operates at Layer 3 (Network Layer) of the OSI model and acts as a transparent network gateway (single entry and exit point for all traffic).
GWLB uses either a 2-tuple, 3-tuple, or 5-tuple hash to define a flow and routes all packets of a flow to one of its backend targets (flow stickiness).
Gateway Load Balancer endpoints (GWLBE) support maximum bandwidth of up to 100 Gbps per endpoint.
AWS Gateway Load Balancer cost covers
charges for each hour or partial hour that a GWLB is running,
the number of Gateway Load Balancer Capacity Units (GLCU) used by Gateway Load Balancer per hour.
GWLB uses Gateway Load Balancer Endpoint (GWLBE) to simplify how applications can securely exchange traffic with GWLB across VPC boundaries. GWLBE is priced and billed separately.
cost of running the third-party virtual appliances (EC2 instances) behind GWLB.
Key features include:
Configurable TCP Idle Timeout – allows configuring TCP idle timeout from 60 seconds to 6000 seconds (default 350 seconds), preventing interruption of long-lived traffic flows.
Target Failover – supports rebalancing existing flows to healthy targets when a target fails or deregisters, reducing failover time and enabling graceful appliance patching.
LCU Reservation – allows proactively setting a minimum bandwidth capacity for the load balancer, complementing auto-scaling for predictable traffic patterns.
Cross-Zone Load Balancing – by default, each GWLB in an AZ distributes traffic within the same AZ only. Enabling cross-zone distributes traffic across all registered healthy targets in all enabled AZs.
Health Check Improvements – configurable health check intervals, HTTP response codes for target health determination, and consecutive response thresholds.
AWS Network Firewall vs. Gateway Load Balancer – Key Differences
Criteria
AWS Network Firewall
Gateway Load Balancer
Use Case
Stateful, managed, network firewall with IDS/IPS compatible with Suricata
Managed service for deploying, scaling and managing third-party virtual appliances
Complexity
Fully AWS managed – handles scalability, availability, and patching
AWS manages GWLB scalability and availability; customer manages virtual appliance scaling and availability
Scale
Supports up to 100 Gbps per firewall endpoint (powered by AWS PrivateLink)
Supports up to 100 Gbps per endpoint
Cost
Firewall endpoint hourly rate + data processing charges
Need native TLS inspection for outbound HTTPS traffic
Want simplified centralized inspection with native Transit Gateway attachment
Prefer lower operational complexity and no EC2 instance management
Need built-in managed threat intelligence rules from AWS and Marketplace partners
When to Choose Gateway Load Balancer
Need specific third-party firewall capabilities (e.g., Palo Alto NGFW, Fortinet, Check Point)
Have existing investment in third-party security appliance policies and expertise
Require advanced features beyond what Suricata rules provide
Need to integrate multiple types of virtual appliances (IDS/IPS + DPI + custom inspection)
Want consistent security policies across cloud and on-premises using the same vendor
Key Architectural Considerations
Appliance mode should be enabled on Transit Gateway when doing east-west (VPC-to-VPC) inspection with either solution.
For multi-Region deployment, set up separate inspection in respective local Regions to avoid inter-Region dependencies and reduce data transfer costs.
Both solutions can be combined – use Network Firewall for standard north-south traffic and GWLB with third-party appliances for specialized deep inspection.
If GWLB cross-zone load balancing is enabled and all targets across all AZs are unhealthy, GWLB fails open (passes traffic without inspection).
Network Firewall with Transit Gateway native attachment eliminates the need for a separate inspection VPC, reducing cost and complexity.
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.
A company needs to inspect all east-west traffic between VPCs in a multi-VPC architecture. They want a fully managed solution with minimal operational overhead and no need to manage EC2 instances. Which solution should they use?
Deploy third-party firewalls on EC2 instances in each VPC
Use AWS Network Firewall with native Transit Gateway attachment
Deploy Gateway Load Balancer with third-party appliances in an inspection VPC
Use VPC security groups and NACLs for all traffic filtering
Answer: b – AWS Network Firewall with native Transit Gateway attachment provides fully managed east-west inspection without requiring a separate inspection VPC or managing virtual appliance instances.
A company has an existing Palo Alto Networks firewall deployment on-premises and wants to maintain consistent security policies across their hybrid environment in AWS. Which solution is most appropriate?
AWS Network Firewall with Suricata rules
AWS WAF with custom rules
Gateway Load Balancer with Palo Alto VM-Series instances
VPC Network Access Analyzer
Answer: c – GWLB enables deployment of the same third-party appliances used on-premises, maintaining consistent security policies across hybrid environments.
A security team needs to inspect encrypted outbound HTTPS traffic from their VPCs to detect data exfiltration attempts. They want a managed service approach. Which feature should they use?
Gateway Load Balancer with SSL termination
AWS Network Firewall TLS Inspection with SNI session holding
AWS WAF with HTTPS rules
VPC Flow Logs with CloudWatch analysis
Answer: b – AWS Network Firewall provides native TLS inspection that decrypts and re-encrypts outbound HTTPS traffic, with SNI session holding for deeper visibility into encrypted connections.
A company uses Gateway Load Balancer with third-party firewall appliances. During maintenance, they need to patch the appliances without dropping existing connections. Which GWLB feature helps?
Cross-zone load balancing
Target Failover with Rebalance mode
Configurable TCP idle timeout
LCU Reservation
Answer: b – Target Failover with Rebalance mode rehashes existing flows and sends them to healthy targets when a target is deregistered, enabling graceful appliance patching during maintenance.
A network engineer needs to troubleshoot a suspected malicious connection that may be traversing their AWS Network Firewall. They want to view active flows without disrupting traffic. Which feature should they use?
VPC Flow Logs
AWS Network Firewall Flow Capture
AWS Network Firewall Flow Flush
CloudWatch Network Monitor
Answer: b – Flow Capture provides point-in-time snapshots of active flows in the firewall’s state table for monitoring and troubleshooting without affecting traffic.
An organization is evaluating the total cost of running network security inspection in AWS. They need both IDS/IPS and domain filtering capabilities. They don’t require third-party appliances. Which option is most cost-effective? (Select TWO considerations)
AWS Network Firewall has lower total cost since it doesn’t require managing EC2 instances
Gateway Load Balancer is cheaper because it only charges for GLCU usage
AWS Network Firewall removed additional data processing charges for TLS inspection in 2026
Gateway Load Balancer cost includes the virtual appliance EC2 instances and licensing
Network Firewall charges for cross-zone data transfer
Answer: a, c – Network Firewall avoids EC2 and third-party licensing costs. The 2026 pricing update removed additional data processing charges for Advanced Inspection (TLS), making it more cost-effective for inspection workloads.
The AWS Certified Advanced Networking – Specialty (ANS-C01) exam is being retired. The last day to take the exam is August 25, 2026.
Certifications earned prior to the retirement will remain active for the standard three-year period. New AWS Certified Advanced Networking – Specialty certifications will not be issued after the retirement date.
If you plan to take this exam, schedule it before August 25, 2026.
I recently certified/recertified for the AWS Certified Advanced Networking – Specialty (ANS-C01). Frankly, Networking is something that I am still diving deep into and I just about managed to get through. So a word of caution, this exam is inline or tougher than the professional exams, especially for the reason that some of the Networking concepts covered are not something you can get your hands dirty with easily.
Specialty exams are tough, lengthy, and tiresome. Most of the questions and answers options have a lot of prose and a lot of reading that needs to be done, so be sure you are prepared and manage your time well.
ANS-C01 exam has 65 questions to be solved in 170 minutes which gives you roughly 2 1/2 minutes to attempt each question. 65 questions consists of 50 scored and 15 unscored questions.
ANS-C01 exam includes two types of questions, multiple-choice and multiple-response.
ANS-C01 has a scaled score between 100 and 1,000. The scaled score needed to pass the exam is 750.
Each question mainly touches multiple AWS services.
Specialty exams currently cost $ 300 + tax.
You can get an additional 30 minutes if English is your second language by requesting Exam Accommodations. It might not be needed for Associate exams but is helpful for Professional and Specialty ones.
As always, mark the questions for review and move on and come back to them after you are done with all.
As always, having a rough architecture or mental picture of the setup helps focus on the areas that you need to improve. Trust me, you will be able to eliminate 2 answers for sure and then need to focus on only the other two. Read the other 2 answers to check the difference area and that would help you reach the right answer or at least have a 50% chance of getting it right.
AWS exams can be taken either remotely or online, I prefer to take them online as it provides a lot of flexibility. Just make sure you have a proper place to take the exam with no disturbance and nothing around you.
Also, if you are taking the AWS Online exam for the first time try to join at least 30 minutes before the actual time as I have had issues with both PSI and Pearson with long wait times.
AWS Certified Networking – Specialty (ANS-C01) exam focuses a lot on Networking concepts involving Hybrid Connectivity with Direct Connect, VPN, Transit Gateway, Direct Connect Gateway, and a bit of VPC, Route 53, ALB, NLB & CloudFront.
help capture information about the IP traffic going to and from network interfaces in the VPC and can help in monitoring the traffic or troubleshooting any connectivity issues
NACLs are stateless and how it is reflected in VPC Flow Logs
If ACCEPT followed by REJECT, inbound was accepted by Security Groups and ACLs. However, rejected by NACLs outbound
If REJECT, inbound was either rejected by Security Groups OR NACLs.
Use pkt-dstaddr instead of dstaddr to track the destination address as dstaddr refers to the primary ENI address always and not the secondary addresses.
(New – Jun 2026) VPC Flow Logs now supports EC2 resource tags and next-hop interface metadata, simplifying network monitoring by eliminating the need to manually correlate flow log data with resource metadata.
DHCP Option Sets esp. how to resolve DNS from both on-premises data center and AWS.
VPC Gateway Endpoints for connectivity with S3 & DynamoDB i.e. VPC -> VPC Gateway Endpoints -> S3/DynamoDB.
VPC Interface Endpoints or Private Links for other AWS services and custom hosted services i.e. VPC -> VPC Interface Endpoint OR Private Link -> S3/Kinesis/SQS/CloudWatch/Any custom endpoint.
S3 gateway endpoints cannot be accessed through VPC Peering, VPN, or Direct Connect. Need HTTP proxy to route traffic.
S3 Private Link can be accessed through VPC Peering, VPN, or Direct Connect. Need to use an endpoint-specific DNS name.
VPC endpoint policy can be configured to control which S3 buckets can be accessed and the S3 Bucket policy can be used to control which VPC (includes all VPC Endpoints) or VPC Endpoint can access it.
(New – Nov 2025) Cross-Region PrivateLink — AWS PrivateLink now supports cross-region connectivity, allowing interface VPC endpoints to connect to AWS services in other Regions within the same partition without needing inter-region peering or Transit Gateway.
Private Link Patterns
Private links allow connectivity for overlapping CIDRs which VPC peering would not.
Connections can be initiated in only one direction i.e. consumer to provider
Provides fine-grained access control and only the endpoint is shared and nothing else.
helps consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
Appliance Mode ensures that network flows are symmetrically routed to the same AZ and network appliance
Transit Gateway Connect attachment can be used to connect SD-WAN to AWS Cloud. This supports GRE.
Transit Gateways are regional and Peering can connect Transit Gateways across regions.
Transit Gateway Network Manager includes events and metrics to monitor the quality of the global network, both in AWS and on-premises.
Transit Gateway Flow Logs — enables capturing detailed information such as source/destination IPs, ports, protocol, traffic counters, timestamps, and metadata for all network flows traversing through the Transit Gateway. Can be published to CloudWatch Logs and S3.
(New – Nov 2024) Transit Gateway now supports Path MTU Discovery (PMTUD) for both IPv4 and IPv6 protocols, improving performance for large packet workloads.
provides a central dashboard to create a global wide-area network connecting resources across your cloud and on-premises environments.
uses a central network policy to define network management and security policies in one location.
now supports direct integration with AWS Direct Connect gateways, enabling routes to be advertised directly between Cloud WAN segments and on-premises environments.
supports Service Insertion for routing traffic through middlebox appliances (firewalls, IDS/IPS).
for organizations with complex multi-region networking needs, Cloud WAN simplifies what would otherwise require multiple Transit Gateways with peering.
for HA, Scalable, Outgoing traffic. Does not support Security Groups or ICMP pings.
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.
supports Private NAT Gateways for internal communication.
(New – Nov 2025) Regional NAT Gateway — a single NAT Gateway that automatically expands and contracts across availability zones based on workload presence, maintaining high availability without needing to deploy one per AZ. Supports Amazon-provided IPs and BYOIP.
LOA-CFA provides the details for partners to connect to the AWS Direct Connect location
Virtual interfaces options – Private Virtual Interface for VPC resources and Public Virtual Interface for Public Resources
Private VIF is for resources within a VPC
Public VIF is for AWS public resources
Transit VIF is for connecting to Transit Gateways via Direct Connect Gateway
Private VIF has a limit of 100 routes and Public VIF of 1000 routes. Summarize the routes if you need to configure more.
(New – Jun 2026) VIF Rate Limiters — allows setting a maximum bandwidth allocation for up to 10 VIFs on a dedicated connection, with capacity increments from 50 Mbps to 1.6 Tbps (when using LAG). Rate limiting applies to traffic both ingressing and egressing the AWS network, helping prevent network congestion on shared connections.
(New – Mar 2025) CloudWatch VIF Metrics — new metrics for VirtualInterfaceBgpStatus, VirtualInterfaceBgpPrefixesAccepted, and VirtualInterfaceBgpPrefixesAdvertised for monitoring BGP health and prefix counts.
it provides a way to connect to multiple VPCs from an on-premises data center using the same Direct Connect connection.
can connect to VGW or TGW.
(New – Nov 2024) Direct Connect Gateway can now be attached directly to AWS Cloud WAN core networks, enabling routes to be advertised between Cloud WAN segments and on-premises.
supports MACsec which delivers native, near line-rate, point-to-point encryption ensuring that data communications between AWS and the data center, office, or colocation facility remain protected.
BGP prefers the shortest AS PATH to get to the destination. Traffic from the VPC to on-premises uses the primary router. This is because the secondary router advertises a longer AS-PATH.
AS PATH prepending doesn’t work when the Direct Connect connections are in different AWS Regions than the VPC.
AS PATH works from AWS to on-premises and Local Pref from on-premises to AWS
Use Local Preference BGP community tags to configure Active/Passive when the connections are from different regions. The higher tag has a higher preference for 7224:7300 > 7224:7100
NO_EXPORT works only for Public VIFs
7224:9100, 7224:9200, and 7224:9300 apply only to public prefixes. Usually used to restrict traffic to regions. Can help control if routes should propagate to the local Region only, all Regions within a continent, or all public Regions.
7224:9100 — Local AWS Region
7224:9200 — All AWS Regions for a continent, North America–wide, Asia Pacific, Europe, the Middle East and Africa
7224:9300 — Global (all public AWS Regions)
7224:8100 — Routes that originate from the same AWS Region in which the AWS Direct Connect point of presence is associated.
7224:8200 — Routes that originate from the same continent with which the AWS Direct Connect point of presence is associated.
provides a highly available and scalable DNS web service.
Routing Policies and their use cases Focus on Weighted, Latency, and Failover routing policies.
supports Alias resource record sets, which enables routing of queries to a CloudFront distribution, Elastic Beanstalk, ELB, an S3 bucket configured as a static website, or another Route 53 resource record set.
ALB provides Content, Host, and Path-based Routing while NLB provides the ability to have a static IP address
Maintain original Client IP to the backend instances using X-Forwarded-for and Proxy Protocol
(Updated – Nov 2023) ALB now supports Mutual TLS (mTLS) — ALB can authenticate clients using X.509 certificates, offloading client certificate verification to the load balancer. Uses Trust Stores to manage CA certificates. Supports both verify mode (validates and passes headers) and passthrough mode.
For NLB with mTLS requirements, still use NLB with TCP listener on port 443 and terminate TLS on the instances.
(New – Nov 2025) Post-Quantum TLS — Both ALB and NLB now support post-quantum key exchange options (ML-KEM) for TLS, providing protection against future quantum computing threats.
NLB
also provides local zonal endpoints to keep the traffic within AZ
can front Private Link endpoints and provide static IPs.
ALB supports Forward Secrecy, through Security Policies, that provide additional safeguards against the eavesdropping of encrypted data, through the use of a unique random session key.
Supports sticky session feature (session affinity) to enable the LB to bind a user’s session to a specific target. This ensures that all requests from the user during the session are sent to the same target. Sticky Sessions is configured on the target groups.
(New – May 2024) Dual-Stack ALB without public IPv4 — internet-facing ALBs can now be provisioned without public IPv4 addresses, enabling IPv6-only client connectivity.
AWS Shield Advanced provides 24×7 access to the AWS Shield Response Team (SRT), protection against DDoS-related spike, and DDoS cost protection to safeguard against scaling charges.
(New – May 2026) AWS Shield Advanced now supports DDoS attack flow logs for enhanced visibility into attack traffic patterns.
helps protect web applications from attacks by allowing rules configuration that allow, block, or monitor (count) web requests based on defined conditions.
integrates with CloudFront, ALB, API Gateway to dynamically detect and prevent attacks
provides secure, VPN-less access to corporate applications using zero trust principles.
evaluates each request based on user identity and device security posture rather than network location.
uses Cedar policy language for fine-grained access policies.
(Feb 2025) now supports non-HTTP(S) protocols (SSH, RDP) — eliminates need for separate VPN solutions for all application types.
achieved FedRAMP High and Moderate authorization (Mar 2025).
alternative to traditional VPN for remote workforce access scenarios.
Monitoring & Management Tools
Understand AWS CloudFormation esp. in terms of Network creation.
Custom resources can be used to handle activities not supported by AWS
While configuring VPN connections use depends_on on route tables to define a dependency on other resources as the VPN gateway route propagation depends on a VPC-gateway attachment when you have a VPN gateway.
fully managed service that provides AWS resource inventory, configuration history, and configuration change notifications to enable security, compliance, and governance.
can be used to monitor resource changes e.g. Security Groups and invoke Systems Manager Automation scripts for remediation.
📋 Last Updated: June 2026. Includes Cross-Region PrivateLink (Nov 2025), NAT Gateway Regional Availability Mode (Nov 2025), Direct Connect VIF Rate Limiters (June 2026), Transit Gateway Flow Logs & Flexible Cost Allocation, AWS Cloud WAN Direct Connect integration, and VPC Lattice Resource Gateway updates.
On-premises -> S3 Private Link -> S3 (Without Internet Gateway or S3 Gateway Endpoint)
Interface endpoints in the VPC can route both in-VPC applications and on-premises applications to S3 over the Amazon network.
On-premises network uses Direct Connect or AWS VPN to connect to VPC.
On-premises applications in VPC A use endpoint-specific DNS names to access S3 through the S3 interface endpoint.
On-premises applications send data to the interface endpoint in the VPC through AWS Direct Connect (or AWS VPN). AWS PrivateLink moves the data from the interface endpoint to S3 over the AWS network.
VPC applications can also send traffic to the interface endpoint. AWS PrivateLink moves the data from the interface endpoint to S3 over the AWS network.
(New – Nov 2025) With Cross-Region PrivateLink, interface VPC endpoints can now connect to S3 (and other AWS services) in other AWS Regions within the same partition, removing the previous “VPC endpoints are regional” limitation.
(New – Nov 2025) S3 gateway and interface VPC endpoints now support IPv6, enabling dual-stack connectivity at no additional cost.
On-premises -> Proxy -> Gateway Endpoint -> S3
VPC endpoints are only accessible from EC2 instances inside a VPC, a local instance must proxy all remote requests before they can utilize a VPC endpoint connection.
Proxy farm proxies S3 traffic to the VPC endpoint. Configure an Auto Scaling group to manage the proxy servers and automatically grow or shrink the number of required instances based on proxy server load.
Note: With the availability of AWS PrivateLink for S3 (interface endpoints), this proxy-based pattern is largely superseded. Interface endpoints are directly accessible from on-premises over Direct Connect or VPN without requiring a proxy.
Direct Connect Gateway + Transit Gateway
AWS Direct Connect Gateway does not support transitive routing and has limits on the number of VGWs that can be connected.
AWS Direct Connect Gateway can be combined with AWS Transit Gateway using transit VIF attachment which enables your network to connect up to three regional centralized routers over a private dedicated connection.
DX Gateway + TGW simplifies the management of connections between a VPC and the on-premises networks over a private connection that can reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than internet-based connections.
With AWS Transit Gateway connected to VPCs, full or partial mesh connectivity can be achieved between the VPCs.
(New – Nov 2024) AWS Cloud WAN now supports direct integration with Direct Connect Gateway, eliminating the need for an intermediary Transit Gateway for global hybrid connectivity.
(New – Nov 2024) Transit Gateway and Cloud WAN now support Path MTU Discovery (PMTUD) for both IPv4 and IPv6, improving performance for large packet workloads.
AWS Direct Connect with VPN as Backup
Be sure that you use the same virtual private gateway for both Direct Connect and the VPN connection to the VPC.
If you are configuring a Border Gateway Protocol (BGP) VPN, advertise the same prefix for Direct Connect and the VPN.
If you are configuring a static VPN, add the same static prefixes to the VPN connection that you are announcing with the Direct Connect virtual interface.
If you are advertising the same routes toward the AWS VPC, the Direct Connect path is always preferred, regardless of AS path prepending.
AWS Direct Connect + VPN
AWS Direct Connect + VPN combines the benefits of the end-to-end secure IPSec connection with low latency and increased bandwidth of the AWS Direct Connect to provide a more consistent network experience than internet-based VPN connections.
AWS Direct Connect public VIF establishes a dedicated network connection between the on-premises network to public AWS resources, such as an Amazon virtual private gateway IPsec endpoint.
A BGP connection is established between the AWS Direct Connect and your router on the public VIF.
Another BGP session or a static router will be established between the virtual private gateway and your router on the IPSec VPN tunnel.
AWS Direct Connect VIF Rate Limiters
(New – June 2026) AWS Direct Connect now supports Virtual Interface (VIF) Rate Limiters on dedicated connections to help prevent network congestion caused by unexpected traffic spikes.
VIF Rate Limiters allow you to set a maximum bandwidth allocation for up to 10 VIFs on a dedicated connection.
Capacity increments range from 50 Mbps to 1.6 Tbps when using a Link Aggregation Group (LAG).
Rate limiting applies to traffic both ingressing and egressing the AWS network.
If traffic exceeds the configured capacity, excess packets are dropped, protecting other VIFs sharing the same connection.
Prevents a single VIF from consuming all available bandwidth, impacting workloads on other VIFs on the same connection.
AWS Direct Connect SiteLink
AWS Direct Connect SiteLink enables direct data transfer between Direct Connect locations, bypassing AWS Regions.
SiteLink interconnects locations worldwide and offers built-in redundancy and resiliency.
Ensures uninterrupted connectivity even during public internet outages or high-traffic periods.
Useful for site-to-site traffic that doesn’t need to traverse an AWS Region (e.g., on-premises to on-premises via AWS backbone).
SiteLink is enabled on a per-VIF basis and charges apply for data transferred between SiteLink-enabled VIFs.
AWS Private Link -> NLB -> ALB
AWS PrivateLink for ALB allows customers to utilize PrivateLink on NLB and route this traffic to a target ALB to utilize the layer 7 benefits.
Static NLB IP Addresses for ALB – with one static IP per AZ on NLB allows full control over the IP addresses and enables various use cases as follows:
Allow listing of IP addresses for firewall rules.
Pointing a DNS Zone apex to an application fronted by an ALB. Utilizing ALB as a target of NLB, a DNS A-record type can be used to resolve your zone apex to the NLB static IP addresses.
When legacy clients cannot utilize DNS resulting in a need for hard-coded IP addresses.
(New – Oct 2024) AWS PrivateLink now supports UDP protocol on NLB over IPv4 and IPv6, and dual-stack NLB UDP support for real-time gaming, VoIP, and media streaming workloads.
(New – Nov 2025) NLB now supports weighted target groups, allowing users to configure static weights among multiple target groups for canary and blue/green deployments.
Alternative: API Gateway Direct ALB Integration (Nov 2025)
Amazon API Gateway REST APIs now support direct private integration with ALB without requiring an intermediate NLB.
This removes the NLB hop for API Gateway use cases, reducing latency and simplifying architecture.
Enables inter-VPC connectivity to internal ALBs using VPC Link V2.
For PrivateLink endpoint services, NLB (or Gateway Load Balancer) is still required as the front end.
Amazon VPC Lattice Resource Configurations and Resource Gateways (GA at re:Invent 2024) enable access to resources like RDS instances, domain names, or IP targets across VPCs and accounts without needing an NLB.
VPC Lattice provides application-layer routing, service discovery, authentication, and observability without complex network configurations.
Supports TCP, TLS, HTTP, and HTTPS protocols.
Resource owners can share resources directly using AWS RAM without deploying Network Load Balancers.
A separate egress VPC in the network services account can be created to route all egress traffic from the spoke VPCs via a NAT gateway sitting in this VPC using Transit Gateway.
As the NAT gateway has an hourly charge, deploying a NAT gateway in every spoke VPC can become cost prohibitive and centralizing NAT can provide cost benefits.
In some edge cases when huge amounts of data is sent through the NAT gateway from a VPC, keeping the NAT local in the VPC to avoid the Transit Gateway data processing charge might be a more cost-effective option.
Two NAT gateways (one in each AZ) provide High Availability.
NAT Gateway Regional Availability Mode (Nov 2025)
(New – Nov 2025) AWS NAT Gateway now supports regional availability mode that automatically expands and contracts across availability zones following your workload footprint.
A single regional NAT Gateway replaces the need for one NAT Gateway per AZ, simplifying setup and management.
Automatically maintains high availability without manual multi-AZ deployment.
Supports both Amazon-provided IP addresses and BYOIP (Bring Your Own IP).
Simplifies centralized egress architectures by reducing the number of NAT Gateways needed.
Can be combined with Amazon VPC IPAM policies for centralized public IPv4 address allocation across organizations.
AWS Cloud WAN + Direct Connect (Alternative to TGW)
(New – Nov 2024) AWS Cloud WAN now supports built-in Direct Connect gateway attachments without requiring intermediary Transit Gateways.
Cloud WAN is a fully managed WAN service that simplifies building, managing, and monitoring global networks connecting resources across AWS Regions and on-premises environments.
Think of Cloud WAN as a managed collection of Transit Gateways working behind the scenes with policy-based network management.
Provides greater flexibility in configuring global hybrid networks with simplified operations.
Supports traffic segmentation across multiple Regions using network segments (similar to TGW route tables).
Ideal for multi-Region environments where managing multiple Transit Gateways and peering becomes complex.
(New – Nov 2024) Amazon VPC Block Public Access (BPA) is a single declarative control that authoritatively blocks internet traffic to and from VPCs.
BPA supersedes any existing VPC settings (including routing tables, security groups, NACLs) to block traffic through Internet Gateways and Egress-only Internet Gateways.
Modes: Bidirectional (blocks all ingress and egress) or Ingress-only (blocks only inbound from internet).
Supports exclusions for specific VPCs or subnets that require internet access.
Available in all commercial AWS Regions including GovCloud and China Regions.
Enables compliance enforcement across multiple accounts and VPCs with AWS Organizations integration.
Useful in centralized egress architectures where only the egress VPC should have internet access.
Transit Gateway Flow Logs enable visibility and insights into network traffic traversing Transit Gateways.
Captures detailed information including source/destination IPs, ports, protocol, traffic counters, timestamps, and metadata.
Supports publishing to Amazon S3 and CloudWatch Logs.
Enables proactive detection of unroutable traffic and network connectivity issues.
Available in all commercial Regions.
Flexible Cost Allocation (Nov 2025)
(New – Nov 2025) Transit Gateway Flexible Cost Allocation (FCA) provides granular control over how data processing costs are allocated across AWS accounts.
Previously, Transit Gateway only used a sender-pay model where the source attachment account owner paid all data usage costs.
FCA enables centralized metering policy with more versatile cost allocation options.
Works with AWS Organizations for cross-account cost distribution.
Direct Connect with High Resiliency – 99.9%
For critical production workloads that require high resiliency, it is recommended to have one connection at multiple locations.
Ensures resilience to connectivity failure due to a fiber cut or a device failure as well as a complete location failure. You can use AWS Direct Connect gateway to access any AWS Region (except AWS Regions in China) from any AWS Direct Connect location.
Direct Connect with Maximum Resiliency – 99.99%
Maximum resilience is achieved by separate connections terminating on separate devices in more than one location.
Ensures resilience to device failure, connectivity failure, and complete location failure.
Use VIF Rate Limiters (June 2026) on each connection to prevent bandwidth contention across VIFs sharing the same dedicated connection.
Key Network Architecture Decision Points
Use Case
Recommended Pattern
When to Use
Private access to S3 from on-premises
PrivateLink (Interface Endpoint)
Direct Connect/VPN connectivity available
Cross-region private service access
Cross-Region PrivateLink
Service consumers in different Region from provider
Multi-VPC hub-and-spoke (single Region)
Transit Gateway
Regional connectivity with route isolation
Global multi-Region WAN
AWS Cloud WAN
Multi-Region with policy-based management
Service-to-service (Layer 7)
VPC Lattice
Application-level routing, auth, and observability
Centralized egress (simplified)
Regional NAT Gateway + TGW
Cost optimization with automatic multi-AZ HA
Block internet access
VPC Block Public Access
Compliance enforcement across organization
Site-to-site via AWS backbone
Direct Connect SiteLink
On-premises to on-premises without traversing a Region
EC2 Spot instances allow access to spare EC2 computing capacity at up to 90% off the On-Demand price.
Spot Instance prices are set by Amazon EC2 and adjust gradually based on long-term trends in supply and demand for Spot Instance capacity, but never exceed On-Demand prices.
Spot Instances can be interrupted by EC2 when EC2 needs the capacity back with a two-minute notification.
Spot instances are a cost-effective choice and can bring the EC2 costs down significantly.
Spot instances can be used for applications flexible in the timing when they can run and also able to handle interruption by storing the state externally for e.g. they are well-suited for data analysis, batch jobs, background processing, and optional tasks
The only difference between an On-Demand Instance and a Spot Instance is that a Spot Instance can be interrupted by Amazon EC2, with two minutes of notice, when EC2 needs the capacity back.
Usual strategy involves using Spot instances with On-Demand or Reserved Instances, which provide a minimum level of guaranteed compute resources, while spot instances provide an additional computation boost.
Spot instances can also be launched with a required duration (also known as Spot blocks), which are not interrupted due to changes in the Spot price.
Spot Blocks (Defined Duration) have been discontinued. Spot Blocks were not available to new customers from July 1, 2021, and support ended entirely on December 31, 2022.
EC2 provides a data feed, sent to an S3 bucket specified during subscription, that describes the Spot instance usage and pricing.
Spot Instances are not suitable for workloads that are inflexible, stateful, fault-intolerant, or tightly coupled between instance nodes.
Well Suited for
Ideal for various stateless, fault-tolerant, or flexible applications such as big data, containerized workloads, CI/CD, high-performance computing (HPC), stateless web servers, image and media rendering, machine learning, and other test & development workloads
Applications that have flexible start and end times
Applications that are only feasible at very low compute prices
Users with urgent computing needs for large amounts of additional capacity
Spot Concepts
Spot capacity pool – A set of unused EC2 instances with the same instance type (for example, m5.large), operating system, Availability Zone, and network platform.
Spot price – Current price of a Spot Instance per hour, set by Amazon EC2 and adjusting gradually based on long-term trends in supply and demand. Spot prices never exceed On-Demand prices.
Spot Instance request
Provides the maximum price per hour that you are willing to pay for a Spot Instance. If unspecified, it defaults to the On-Demand price.
EC2 fulfils the request when the maximum price per hour for the request exceeds the Spot price and if capacity is available.
A Spot Instance request is either one-time or persistent.
EC2 automatically resubmits a persistent Spot request after the Spot Instance associated with the request is terminated.
Spot Instance interruption – EC2 terminates, stops, or hibernates the Spot Instance when capacity is no longer available. EC2 provides a Spot Instance interruption notice, which gives the instance a two-minute warning before it is interrupted.
EC2 Instance Rebalance Recommendation is a signal that notifies when a Spot Instance is at elevated risk of interruption. The signal provides an opportunity to proactively manage the Spot Instance in advance of the two-minute Spot Instance interruption notice.
Spot placement score – indicates how likely it is that a Spot request will succeed in a Region or Availability Zone, scored on a scale from 1 to 10.
Spot Pricing Model
ℹ️ Important: Since 2017, AWS uses a simplified Spot pricing model. Spot prices adjust gradually based on long-term supply and demand trends, not on a real-time bidding/auction system. You no longer need to analyze historical prices or determine bidding strategies. Typical savings are 70-90% over On-Demand prices.
Spot Instance prices are set by Amazon EC2 and adjust gradually based on long-term trends in supply and demand for Spot Instance capacity.
Spot prices never exceed On-Demand prices.
You can specify a maximum price when requesting Spot Instances. If unspecified, it defaults to the On-Demand price.
EC2 fulfils the request when the maximum price per hour exceeds the Spot price and capacity is available.
Everyone pays the same Spot price for the period irrespective of the maximum price specified, given the maximum price is more than the Spot price.
EC2 can interrupt the Spot Instance when the demand for Spot instances rises or when the supply of Spot instances decreases.
When EC2 interrupts a Spot Instance, it provides a two-minute warning before interruption.
Applications on Spot Instances should poll for the termination notice at 5-second intervals or use EventBridge for event-driven handling.
EBS-backed Spot Instance can be stopped, started, rebooted, or terminated.
Spot Instance Billing
Spot Instances use per-second billing (with a minimum of 60 seconds) for Linux and Windows instances.
If Amazon EC2 interrupts the Spot Instance in the first hour, you are not charged for the usage.
If Amazon EC2 interrupts the Spot Instance after the first hour, you are charged for the seconds used.
If you stop or terminate the Spot Instance, you are charged for the seconds used (even in the first hour).
While an interrupted Spot Instance is stopped, you are charged only for the EBS volumes, which are preserved.
Spot Instances Requests
A Spot Instance request is either
One-time
A one-time request remains active until EC2 launches the Spot Instance, the request expires, or you cancel the request.
Persistent
EC2 automatically resubmits a persistent Spot request after the Spot Instance associated with the request is terminated.
A persistent Spot Instance request remains active until it expires or you cancel it, even if the request is fulfilled.
Cancelling spot instance requests does not terminate the instances.
Be sure to cancel the spot request before you terminate the instances, else they would be launched again.
Spot Fleet and EC2 Fleet
⚠️ Spot Fleet is Legacy: AWS strongly discourages using Spot Fleet because it uses a legacy API with no planned investment. Use EC2 Fleet or EC2 Auto Scaling groups instead.
EC2 Fleet (Recommended)
Creates a fleet of both On-Demand Instances and Spot Instances in a single request.
Supports multiple launch specifications that vary by instance type, AMI, Availability Zone, or subnet.
EC2 Fleet types:
instant – Places a synchronous one-time request. Returns launched instances immediately. Recommended when you don’t need auto scaling.
request – Places an asynchronous one-time request. Does not attempt to replenish interrupted capacity.
maintain – Places an asynchronous request and maintains capacity by automatically replenishing interrupted Spot Instances.
Spot Fleet (Legacy – Not Recommended)
Collection of Spot Instances and optionally On-Demand Instances.
Attempts to launch the number of instances to meet the specified target capacity.
Uses a legacy API with no planned investment.
Allocation Strategies
priceCapacityOptimized (Recommended)
Requests Spot Instances from the pools that have the lowest chance of interruption AND the lowest possible price.
Best choice for most Spot workloads: containerized applications, microservices, web applications, data analytics, batch processing.
AWS recommended default strategy.
capacityOptimized
From the pools with optimal capacity for the number of instances launching.
Lowest risk of interruption.
capacityOptimizedPrioritized
Optimizes for capacity first, but honors instance type priorities on a best-effort basis.
Set priority for each instance type using the Priority parameter.
diversified
Distributed across all specified pools.
Good for high availability, long workloads.
lowestPrice (Not Recommended)
From the pool with the lowest price.
AWS does not recommend this strategy because it has the highest risk of interruption for Spot Instances.
Spot Instances Interruption
EC2 Instance Rebalance Recommendations and Spot Instance interruption notices can be used to gracefully handle Spot Instance interruptions.
EC2 Instance Rebalance Recommendation
Signal that notifies when a Spot Instance is at elevated risk of interruption.
Provides an opportunity to proactively manage the Spot Instance in advance of the two-minute interruption notice.
Can be monitored via Amazon EventBridge events.
Capacity Rebalancing feature in Auto Scaling groups and EC2 Fleet automatically acts on these signals.
Spot Instance Interruption Notice
Warning issued two minutes before EC2 interrupts a Spot Instance (except for hibernation, which begins immediately).
Available as an EventBridge event and in instance metadata.
Interruption Behavior – You can specify what happens when a Spot Instance is interrupted:
Terminate (default) – Instance is terminated.
Stop – Instance is stopped and can be restarted when capacity is available. You are charged only for EBS volumes while stopped.
Hibernate – Instance memory (RAM) is saved to EBS root volume. Instance resumes from where it left off when capacity is available. Hibernation begins immediately (no two-minute warning period).
Initiate a Spot Instance Interruption
You can test your application’s fault tolerance by initiating Spot Instance interruptions using AWS Fault Injection Service (AWS FIS).
Available directly from the Amazon EC2 console: Spot Request → Actions → Initiate interruption.
FIS-injected interruptions behave identically to real interruptions (including notifications and configured behaviors).
Spot Placement Score
Indicates how likely it is that a Spot request will succeed in a Region or Availability Zone.
Scored on a scale from 1 to 10 (10 = highly likely to succeed, 1 = not likely to succeed).
Recommends optimal Regions or Availability Zones based on capacity requirements and instance type specifications.
A point-in-time recommendation — capacity can vary over time. It does not guarantee available capacity or predict interruption risk.
Best for workloads that are flexible about instance types and Region/AZ.
Available via Amazon EC2 console, AWS CLI, or SDKs.
Attribute-Based Instance Type Selection
Specify instance attributes (vCPUs, memory, storage, network throughput) rather than specific instance types.
EC2 Auto Scaling or EC2 Fleet automatically identifies and launches matching instances.
Automatically uses newly released instance types as they become available.
Removes the effort of manually selecting specific instance types.
Provides access to an increasingly broad range of Spot Instance capacity, reducing interruption risk.
Ideal for workloads that can be flexible about instance types: HPC, big data, containerized workloads.
Which is the Best Spot Request Method?
CreateAutoScalingGroup (Recommended)
Use when you need multiple instances and want automated lifecycle management.
Supports horizontal scaling between specified minimum and maximum limits.
Best for most workloads that need Spot Instances.
CreateFleet (EC2 Fleet) (Recommended)
Use when you need multiple instances but want to self-manage instance lifecycle.
Creates both On-Demand and Spot Instances in a single request.
Use instant mode if you don’t need auto scaling.
RunInstances
Use if already using RunInstances for On-Demand and want to switch to Spot.
Does not allow mixed instance types in a single request.
RequestSpotFleet – Legacy. DO NOT USE. No planned investment.
RequestSpotInstances – Legacy. DO NOT USE. No planned investment.
Spot Instances vs On-Demand Instances
Spot Instances Best Practices
Be flexible about instance types and Availability Zones
Be flexible across at least 10 instance types for each workload.
Include larger instance types (for vertical scaling) and older generation types (less demand from On-Demand customers).
Ensure all Availability Zones are configured for use in your VPC.
Use attribute-based instance type selection
Specify attributes (vCPUs, memory) instead of specific instance types.
Automatically uses new instance types as they become available.
Use Spot placement scores
Identify optimal Regions and Availability Zones before launching.
Use EC2 Auto Scaling groups or EC2 Fleet to manage aggregate capacity
Think in terms of aggregate capacity (vCPUs, memory, throughput) rather than individual instances.
These services automatically request resources to replace interrupted instances.
Use the price-capacity-optimized allocation strategy
Automatically provisions instances from pools that are least likely to be interrupted AND have the lowest price.
Recommended strategy for most Spot workloads.
Prepare individual instances for interruptions
Make applications fault-tolerant. Store important data externally (S3, EBS, DynamoDB).
Use EventBridge rules to capture rebalance recommendations and interruption notices.
Configure Spot Instances to stop or hibernate instead of terminate if workload is time-flexible.
Use Proactive Capacity Rebalancing
Proactively augments fleet with new Spot Instances before a running instance receives the two-minute interruption notice.
Auto Scaling or EC2 Fleet replaces instances that have received a rebalance recommendation.
Complements the capacity-optimized allocation strategy and mixed instances policy.
Test interruption handling with AWS FIS
Use AWS Fault Injection Service to simulate Spot interruptions.
Amazon EMR, Amazon ECS, AWS Batch, Amazon EKS, Amazon SageMaker, AWS Elastic Beanstalk, Amazon GameLift Servers all integrate with Spot.
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.
You have a video transcoding application running on Amazon EC2. Each instance polls a queue to find out which video should be transcoded, and then runs a transcoding process. If this process is interrupted, the video will be transcoded by another instance based on the queuing system. You have a large backlog of videos, which need to be transcoded, and would like to reduce this backlog by adding more instances. You will need these instances only until the backlog is reduced. Which type of Amazon EC2 instances should you use to reduce the backlog in the most cost efficient way?
Reserved instances
Spot instances
Dedicated instances
On-demand instances
You have a distributed application that periodically processes large volumes of data across multiple Amazon EC2 Instances. The application is designed to recover gracefully from Amazon EC2 instance failures. You are required to accomplish this task in the most cost-effective way. Which of the following will meet your requirements?
Spot Instances
Reserved instances
Dedicated instances
On-Demand instances
A company runs a fault-tolerant batch processing workload on EC2 instances. The workload can be interrupted and resumed. Which allocation strategy should be used with EC2 Fleet to minimize cost while reducing interruptions?
lowestPrice
capacityOptimized
priceCapacityOptimized
diversified
A company wants to run Spot Instances for a containerized workload. They need to identify which AWS Region is most likely to have available Spot capacity for their required instance types. Which feature should they use?
Spot Instance Advisor
Spot placement score
EC2 Fleet instant mode
Capacity Reservations
A company uses Spot Instances for a stateless web application. They want to be notified before interruption so they can gracefully drain connections. Which TWO signals can they use? (Choose 2)
VPC Network Access Analyzer helps identify unintended network access to the resources on AWS.
Network Access Analyzer can be used to
Understand, verify, and improve the network security posture
helps identify unintended network access relative to the security and compliance requirements that enable improving network security.
Demonstrate compliance
can help demonstrate that the network on AWS meets certain compliance requirements.
Network Access Analyzer can help verify the following example requirements:
Network segmentation
verify that the production environment VPCs and development environment VPCs are isolated from one another or systems that process credit card information are isolated from the rest of the environment.
Internet accessibility
can help identify resources that can be accessed from internet gateways, and verify that they are limited to only those resources that have a legitimate need to be accessible from the internet.
Trusted network paths
can help verify that appropriate network controls such as network firewalls and NAT gateways are configured on all network paths between the resources and internet gateways.
Trusted network access
can help verify that the resources have network access only from a trusted IP address range, over specific ports and protocols.
network access requirements can be specified in terms of:
Individual resource IDs, such as vpc-01234567
All resources of a given type, such as AWS::EC2::InternetGateway
All resources with a given tag, using AWS Resource Groups
IP address ranges, port ranges, and traffic protocols
Network Access Analyzer Concepts
Network Access Scopes
Network Access Scopes specifies the network access requirements, which determine the types of findings that the analysis produces.
MatchPaths field help to specify the types of network paths to identify.
ExcludePaths field help to specify the types of network paths to exclude
Findings
Findings are potential paths in the network that match any of the MatchPaths entries in the Network Access Scope, but that do not match any of the ExcludePaths entries in the Network Access Scope.
How Network Access Analyzer Works
Network Access Analyzer uses automated reasoning algorithms to analyze the network paths that a packet can take between resources in an AWS network.
performs a static analysis of a network configuration, meaning that no packets are transmitted in the network as part of this analysis.
produces findings for paths that match a customer-defined Network Access Scope.
only considers the state of the network as described in the network configuration, packet loss that’s due to transient network interruptions or service failures is not considered in this analysis.
Key Features
Automated Reasoning – Uses mathematical logic to analyze all possible network paths without sending actual packets
Compliance Verification – Helps demonstrate compliance with security standards and regulations
Continuous Monitoring – Can be run regularly to detect configuration drift and unintended access
Multi-Account Support – Works across AWS Organizations to analyze network access across multiple accounts
Integration – Integrates with AWS Security Hub for centralized security findings
Regional Availability
VPC Network Access Analyzer is available in most AWS commercial regions
Expanded to additional regions in 2025:
August 2025: Asia Pacific (Jakarta), Asia Pacific (Malaysia), Asia Pacific (Thailand), Europe (Zurich), Middle East (UAE)
September 2025: Asia Pacific (New Zealand), Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Asia Pacific (Taipei), Canada West (Calgary), Israel (Tel Aviv), Mexico (Central)
October 2025: AWS GovCloud (US-West) and AWS GovCloud (US-East)
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.
A security team needs to verify that production VPCs are completely isolated from development VPCs and identify any unintended network paths between them. Which AWS service should they use?
VPC Flow Logs
AWS Config
VPC Network Access Analyzer
Amazon GuardDuty
A company wants to ensure that all traffic from their web applications to the internet passes through their AWS Network Firewall. Which tool can help them identify any paths that bypass the firewall?
VPC Reachability Analyzer
VPC Network Access Analyzer
AWS Security Hub
Amazon Inspector
What type of analysis does VPC Network Access Analyzer perform?
Dynamic analysis by sending test packets through the network
Static analysis of network configuration without transmitting packets
Real-time monitoring of network traffic
Historical analysis of VPC Flow Logs
A compliance officer needs to demonstrate that resources processing credit card information are isolated from other systems. Which VPC Network Access Analyzer feature should they use?
VPC Flow Logs integration
Security group analysis
Network Access Scopes with MatchPaths and ExcludePaths
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 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
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.
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?
Attaching a second Elastic Network interface (ENI) to the NAT instance, and placing it in the private subnet
Attaching an Elastic IP address to the instance in the private subnet
Attaching a second Elastic Network Interface (ENI) to the instance in the private subnet, and placing it in the public subnet
Disabling the Source/Destination Check attribute on the NAT instance
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?
Enable Source/Destination Check on the private Instances.
Enable Source/Destination Check on the NAT instance.
Disable Source/Destination Check on the private instances
Disable Source/Destination Check on the NAT instance
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?
For Inbound allow Source: 20.0.1.0/24 on port 80
For Outbound allow Destination: 0.0.0.0/0 on port 80
For Outbound allow Destination: 0.0.0.0/0 on port 443
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?
Route payment requests through two NAT instances setup for High Availability and whitelist the Elastic IP addresses attached to the NAT instances
Whitelist the VPC Internet Gateway Public IP and route payment requests through the Internet Gateway. (Internet gateway is only to route traffic)
Whitelist the ELB IP addresses and route payment requests from the Application servers through the ELB. (ELB does not have a fixed IP address)
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)
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?
Create a public NAT Gateway in each Availability Zone
Create a Regional NAT Gateway that automatically spans all Availability Zones
Create a private NAT Gateway in each Availability Zone
Use NAT instances with Auto Scaling
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?
Public NAT Gateway with Elastic IP addresses
Regional NAT Gateway in automatic mode
Private NAT Gateway connected to a Transit Gateway
NAT Instance with Source/Destination Check disabled
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?
Create multiple NAT Gateways in the same subnet
Associate secondary IPv4 addresses with the NAT Gateway to increase the connection limit
Increase the NAT Gateway bandwidth allocation
Replace the NAT Gateway with a NAT Instance using a larger instance type
AWS Transit Gateway – TGW is a highly available and scalable service to consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
acts as a Regional virtual router and is a network transit hub that can be used to interconnect VPCs and on-premises networks.
traffic always stays on the global AWS backbone, data is automatically encrypted, and never traverses the public internet, thereby reducing threat vectors, such as common exploits and DDoS attacks.
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 across regions.
Each spoke VPC only needs to connect to the TGW to gain access to other connected VPCs.
provides simpler VPC-to-VPC communication management over VPC Peering with a large number of VPCs.
scales elastically based on the volume of network traffic.
TGW routing operates at layer 3, where the packets are sent to a specific next-hop attachment, based on their destination IP addresses.
AWS Resource Access Manager – RAM can be used to share the TGW with other accounts.
supports Path Maximum Transmission Unit Discovery (PMTUD) for both IPv4 and IPv6, allowing effective mitigation against MTU mismatch issues. (Added Nov 2024)
Transit Gateway Attachments
Transit Gateway attachment is the connection between resources like VPC, VPN, Direct Connect, and the TGW.
TGW attachment is both a source and a destination of packets.
Transit Gateway routes IPv4 and IPv6 packets between attachments using transit gateway route tables.
Route tables can be configured to propagate routes from the route tables for the attached VPCs, VPN connections, and Direct Connect gateways.
When a packet comes from one attachment, it is routed to another attachment using the route that matches the destination IP address.
VPC attached to a TGW must be added a route to the subnet route table in order for traffic to route through the TGW.
Transit Gateway Security Group Referencing
Transit Gateway supports Security Group Referencing across VPCs connected to the same TGW within the same Region. (GA Sep 2024)
allows creating inbound security group rules that reference security groups defined in other VPCs attached to the transit gateway.
simplifies security group management by eliminating the need to hard-code IPv4/IPv6 address ranges for cross-VPC communication.
improves security posture for TGW-based networks by providing more granular, identity-based access control.
must be enabled on the VPC attachment by setting the SecurityGroupReferencingSupport option.
Transit Gateway Peering
Transit Gateway supports the ability to establish peering connections between TGWs in the same and different AWS Regions.
Inter-region Transit Gateway peering
enables customers to extend this connectivity and build global networks spanning multiple AWS Regions.
simplifies routing and inter-connectivity between VPCs and on-premises networks that are serviced and managed via separate TGWs
encrypts inter-region traffic with no single point of failure.
ensures the traffic always stays on the AWS global network and never traverses the public internet, thereby reducing threat vectors, such as common exploits and DDoS attacks.
Intra-region Transit Gateway peering
allows multiple TGWs within the same Region to peer with each other.
provides flexibility to deploy multiple TGWs with separate administrative domains while enabling easy interconnection.
Transit Gateway High Availability
Transit Gateway must be enabled with multiple AZs to ensure availability and to route traffic to the resources in the VPC subnets.
AZ can be enabled by specifying exactly one subnet within the AZ
TGW places a network interface in that subnet using one IP address from the subnet.
TGW can route traffic to all the subnets and not just the specified subnet within the enabled AZ.
Resources that reside in AZs where there is no TGW attachment cannot reach the TGW.
Transit Gateway Appliance Mode
For stateful network appliances in the VPC, appliance mode support for the VPC attachment can be enabled in which the appliance is located.
Appliance Mode ensures that network flows are symmetrically routed to the same AZ and network appliance
Appliance Mode ensures that the same AZ for that VPC attachment is used for the lifetime of a flow of traffic between source and destination.
Appliance Mode also allows the TGW to send traffic to any AZ in the VPC, as long as there is a subnet association in that zone.
Transit Gateway Connect Attachment
Transit Gateway Connect attachment can help establish a connection between a TGW and third-party virtual appliances (such as SD-WAN appliances) running in a VPC.
A Connect attachment supports the Generic Routing Encapsulation (GRE) tunnel protocol for high performance and Border Gateway Protocol (BGP) for dynamic routing.
Transit Gateway VPN Concentrator
AWS Site-to-Site VPN Concentrator is a Transit Gateway attachment type that simplifies multi-site connectivity for distributed enterprises. (Launched Nov 2025)
allows multiple remote sites (25+) to connect through a single VPN attachment to Transit Gateway.
suitable for customers with many low-bandwidth sites (under 100 Mbps per site).
supports up to 100 remote sites per VPN Concentrator with 5 Gbps aggregate bandwidth.
eliminates the need to provision individual VPN connections for each remote site.
Transit Gateway Native Attachments
AWS Network Firewall Native Attachment(Jul 2025)
Network Firewall can attach directly to Transit Gateway, eliminating the need for a dedicated inspection VPC.
simplifies network architecture by removing the need to manage dedicated VPC subnets and route tables for firewall connectivity.
enables flexible cost allocation through Transit Gateway metering policies.
AWS Client VPN Native Attachment(Apr 2026)
AWS Client VPN can attach directly to Transit Gateway without needing an intermediate VPC.
provides centralized remote access to multiple VPCs and on-premises networks directly from the Client VPN endpoint.
preserves source IP addresses end-to-end without SNAT.
Transit Gateway Flow Logs
Transit Gateway Flow Logs enables capturing detailed information about IP traffic going to and from transit gateways.
captures source/destination IPs, ports, protocol, traffic counters, timestamps, and other metadata for all network flows traversing the TGW.
can publish logs to Amazon S3 or Amazon CloudWatch Logs.
provides centralized flow-level visibility from a single point in the network using a single AWS account.
useful for network troubleshooting, security analysis, compliance auditing, and cost chargeback.
Transit Gateway Flexible Cost Allocation
Flexible Cost Allocation (FCA) provides granular control over how Transit Gateway data processing costs are allocated across AWS accounts. (Launched Nov 2025)
Previously, Transit Gateway used only a sender-pay model where the source attachment account owner was responsible for all data usage costs.
FCA enables automatic allocation of all TGW charges including data processing, Site-to-Site VPN Data Transfer Out, Direct Connect Data Transfer Out, and peering charges.
Supports allocation to the source attachment account, destination attachment account, or the central Transit Gateway account.
Metering policies can be configured at attachment-level or individual flow-level granularity.
Available in all commercial AWS Regions with no additional charge for using FCA.
Transit Gateway Per-AZ CloudWatch Metrics
Transit Gateway supports per availability zone (AZ) metrics delivered to CloudWatch. (Added Nov 2024)
provides more granular visibility into traffic distribution across AZs.
helps identify AZ-level traffic imbalances and troubleshoot connectivity issues.
includes metrics such as BytesIn, BytesOut, PacketsIn, PacketsOut, BytesDropCountBlackhole, and BytesDropCountNoRoute.
Transit Gateway Network Manager
AWS Transit Gateway Network Manager (now part of AWS Global Networks for Transit Gateways) provides a single global view of the private network.
includes events and metrics to monitor the quality of the global network, both in AWS and on-premises.
Event alerts specify changes in the topology, routing, and connection status. Usage metrics provide information on up/down connection, bytes in/out, packets in/out, and packets dropped.
seamlessly integrates with SD-WAN solutions.
now supports AWS PrivateLink and IPv6-based connectivity to the management endpoint. (Mar 2025)
Note: For global multi-Region WAN management with policy-based automation, consider AWS Cloud WAN, which provides a managed wide area networking service with built-in Transit Gateway orchestration.
Transit Gateway and AWS Cloud WAN
AWS Cloud WAN is a managed wide area networking (WAN) service that can orchestrate Transit Gateways across multiple Regions.
Cloud WAN provides centralized dashboard, global dynamic routing using BGP, and policy-based network management.
Transit Gateway can be federated with Cloud WAN, allowing gradual migration from TGW-only architectures.
Cloud WAN can replace statically created Transit Gateway peering connections, simplifying inter-region connectivity.
For greenfield deployments requiring multi-Region connectivity, Cloud WAN is recommended over manually peering multiple Transit Gateways.
Transit Gateway remains the optimal choice for single-Region hub-and-spoke architectures.
Transit Gateway Best Practices
Use a separate subnet for each transit gateway VPC attachment.
Create one network ACL and associate it with all of the subnets that are associated with the TGW. Keep the network ACL open in both the inbound and outbound directions.
Associate the same VPC route table with all of the subnets that are associated with the TGW, unless your network design requires multiple VPC route tables (for example, a middle-box VPC that routes traffic through multiple NAT gateways).
Use BGP Site-to-Site VPN connections, if the customer gateway device or firewall for the connection supports multipath, enable the feature.
Enable route propagation for AWS Direct Connect gateway attachments and BGP Site-to-Site VPN attachments.
TGWs are highly available by design and do not need additional TGWs for high availability.
Limit the number of TGW route tables unless the design requires multiple TGW route tables.
For redundancy, use a single TGW in each Region for disaster recovery.
For deployments with multiple TGWs, it is recommended to use a unique ASN for each of them.
Enable Security Group Referencing on VPC attachments to simplify cross-VPC security management.
Use Transit Gateway Flow Logs for centralized network visibility and troubleshooting.
Consider Flexible Cost Allocation for multi-account environments to accurately allocate network costs.
For 5 Gbps VPN throughput, use Large Bandwidth Tunnels (available only with TGW or Cloud WAN attachments). (Nov 2025)
Transit Gateway vs Transit VPC vs VPC Peering
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.
A company is using a VPC peering strategy to connect its VPCs in a single Region to allow for cross-communication. A recent increase in account creations and VPCs has made it difficult to maintain the VPC peering strategy, and the company expects to grow to hundreds of VPCs. There are also new requests to create site-to-site VPNs with some of the VPCs.
A solutions architect has been tasked with creating a centrally managed networking setup for multiple accounts, VPCs, and VPNs.Which networking solution meets these requirements?
Configure shared VPCs and VPNs and share with each other.
Configure a hub-and-spoke VPC and route all traffic through VPC peering.
Configure an AWS Direct Connect connection between all VPCs and VPNs.
Configure a transit gateway with AWS Transit Gateway and connect all VPCs and VPNs
A company hosts its core network services, including directory services and DNS, in its on-premises data center. The data center is connected to the AWS Cloud using AWS Direct Connect (DX). Additional AWS accounts are planned that will require quick, cost-effective, and consistent access to these network services. What should a solutions architect implement to meet these requirements with the LEAST amount of operational overhead?
Create a DX connection in each new account. Route the network traffic to the on-premises servers.
Configure VPC endpoints in the DX VPC for all required services. Route the network traffic to the on-premises servers.
Create a VPN connection between each new account and the DX VPC. Route the network traffic to the on-premises servers.
Configure AWS Transit Gateway between the accounts. Assign DX to the transit gateway and route network traffic to the on-premises servers.
A company has 50 VPCs connected to a Transit Gateway. Multiple application teams in different accounts need to communicate with each other, but the security team requires that cross-VPC security group rules reference specific security groups rather than IP ranges. Which Transit Gateway feature should the solutions architect enable?
Enable Transit Gateway Flow Logs on all attachments.
Enable Security Group Referencing on the VPC attachments to the Transit Gateway.
Create a peering connection between the VPCs.
A large enterprise with 200+ branch offices needs to connect all locations to AWS. Each site requires less than 50 Mbps of bandwidth. The network team wants to minimize the number of VPN connections they need to manage. What is the MOST operationally efficient solution?
Create individual Site-to-Site VPN connections for each branch office to a Transit Gateway.
Use AWS Direct Connect with a Transit Gateway for all branch offices.
Use AWS Site-to-Site VPN Concentrator attachments on Transit Gateway to aggregate multiple sites per attachment.
Deploy software VPN appliances in a shared services VPC.
A company uses a centralized Transit Gateway shared across 20 AWS accounts using AWS RAM. The finance team needs to allocate Transit Gateway data processing costs to the accounts consuming network resources rather than the account that sends the traffic. How should the solutions architect configure this?
Use cost allocation tags on Transit Gateway attachments.
Enable Transit Gateway Flow Logs and build custom billing reports.
Configure Transit Gateway Flexible Cost Allocation (FCA) metering policies to bill the destination attachment account.
Create separate Transit Gateways for each account to track costs independently.
A company wants to centralize traffic inspection for all VPCs without managing a dedicated inspection VPC with firewall endpoints. Which solution provides the simplest architecture? (Select TWO)
Use AWS Network Firewall with native Transit Gateway attachment.
Deploy third-party firewall appliances in each VPC.
Route traffic through Transit Gateway to the Network Firewall attachment for inspection.
Create VPC peering between all VPCs and the inspection VPC.
