AWS VPC (Virtual Private Cloud) is a logically isolated section of the AWS Cloud where you can launch resources in a virtual network that you define, with control over IP addressing, subnets, route tables, and security.

What is the difference between a public and private subnet?

A public subnet has a route to an Internet Gateway allowing direct internet access. A private subnet has no direct route to the internet and uses a NAT Gateway for outbound traffic.

How many VPCs can you have per region?

By default, you can have 5 VPCs per region. This is a soft limit that can be increased by requesting a quota increase from AWS.

What is a VPC CIDR block?

A VPC CIDR block defines the IP address range for your VPC. The allowed block size is between /16 (65,536 IPs) and /28 (16 IPs). You can also add secondary CIDR blocks to expand your VPC.

AWS DDoS Resiliency Best Practices Overview

March 23, 2016 ~ Last updated on : June 26, 2026 ~ jayendrapatil ~ 8 Comments

AWS DDoS Resiliency – Best Practices

📋 Whitepaper Update Notice

The original AWS DDoS Best Practices whitepaper (June 2015) has been updated multiple times, with the latest revision dated August 9, 2023. AWS now marks it as “historical reference.” The current AWS DDoS protection guidance is integrated into the AWS WAF, Shield, and Firewall Manager Developer Guide.

This post has been updated to reflect the modern AWS DDoS protection services including AWS Shield, AWS WAF v2, AWS Firewall Manager, and the new Anti-DDoS Managed Rule Group (2026).

Denial of Service (DoS) is an attack, carried out by a single attacker, which attempts to make a website or application unavailable to the end users.
Distributed Denial of Service (DDoS) is an attack, carried out by multiple attackers either controlled or compromised by a group of collaborators, which generates a flood of requests to the application making it unavailable to the legitimate end users.
DDoS attacks can be segregated by which layer of the OSI model they attack:
- Infrastructure layer attacks (Layer 3 and 4) — SYN/UDP floods, reflection attacks, amplification attacks
- Application layer attacks (Layer 6 and 7) — HTTP/S floods, DNS query floods, SSL/TLS abuse

AWS DDoS Protection Services

AWS Shield Standard — Free, automatic protection for all AWS customers against common infrastructure DDoS attacks (Layer 3/4)
AWS Shield Advanced — Paid managed DDoS protection with enhanced detection, always-on automatic mitigation, 24/7 access to Shield Response Team (SRT), cost protection, and application layer protections
AWS WAF — Web application firewall for application layer (Layer 7) protection with managed rule groups, rate-based rules, and bot control
AWS Firewall Manager — Centralized security policy management across multiple accounts and resources in AWS Organizations
AWS Shield Network Security Director (Preview, 2025) — Analyzes network resources, identifies configuration issues, and provides remediation recommendations for comprehensive DDoS posture

Mitigation Techniques

Minimize the Attack Surface Area

Reduce the attack surface by minimizing the different Internet entry points that allow access to your application
Strategy to minimize the Attack surface area:
- Reduce the number of necessary Internet entry points
- Don’t expose back-end servers
- Eliminate non-critical Internet entry points
- Separate end user traffic from management traffic
- Obfuscate necessary Internet entry points to the level that untrusted end users cannot access them
- Decouple Internet entry points to minimize the effects of attacks
Benefits:
- Minimizes the effective attack vectors and targets
- Less to monitor and protect
Strategy can be achieved using AWS Virtual Private Cloud (VPC):
- Defines a logically isolated virtual network within AWS
- Provides ability to create Public & Private Subnets to launch internet-facing and non-public-facing instances accordingly
- Provides NAT gateway allowing instances in private subnets to have internet access without Public IPs
- Allows creation of Bastion hosts (or use AWS Systems Manager Session Manager) for connecting to instances in private subnets
- Provides security groups for instances and NACLs for subnets to control and limit outbound and inbound traffic
- Supports VPC endpoints (Gateway and Interface) to access AWS services privately without traversing the internet

VPC Architecture

Be Ready to Scale to Absorb the Attack

DDoS attacks mainly aim to overload systems beyond their capacity, rendering them unusable
Scaling out Benefits:
- Helps build a resilient architecture
- Makes the attacker work harder
- Gives you time to think, analyze, and adapt
AWS services for scaling:
- Auto Scaling & Elastic Load Balancing
  - Horizontal scaling using Auto Scaling with ELB (ALB, NLB, or CLB)
  - Auto Scaling allows instances to be added and removed as demand changes
  - ELB distributes traffic across multiple EC2 instances while acting as a single point of contact
  - Auto Scaling automatically registers and deregisters EC2 instances with the ELB during scale-out and scale-in events
  - Application Load Balancer (ALB) integrates natively with AWS WAF for Layer 7 protection
  - Network Load Balancer (NLB) handles millions of requests per second with ultra-low latency for Layer 4 traffic
- EC2 Instance
  - Vertical scaling can be achieved by using appropriate EC2 instance types (e.g., EBS-optimized or ones with 25/100 Gbps network connectivity) to handle the load
- Enhanced Networking
  - Use instances with Enhanced Networking capabilities (ENA) for high packet-per-second performance, low latency networking, and improved scalability
- Amazon CloudFront
  - CloudFront is a CDN that acts as a proxy between end users and Origin servers, distributing content without sending all traffic to the Origin
  - Has inherent ability to mitigate both infrastructure and application layer DDoS attacks by dispersing traffic across multiple edge locations globally
  - AWS has multiple Internet connections for capacity and redundancy at each location, allowing isolation of attack traffic while serving legitimate end users
  - CloudFront filters to ensure only valid TCP connections and HTTP requests are processed, dropping invalid requests (commonly used in UDP & SYN floods, and slow reads)
  - CloudFront Security Dashboard (2023) provides unified CDN and security experience with one-click AWS WAF protection and built-in security monitoring
  - Integrates natively with AWS WAF and AWS Shield Advanced
- Amazon Route 53
  - DDoS attacks also target DNS — if DNS is unavailable, the application is effectively unavailable
  - AWS Route 53 is a highly available and scalable DNS service with capabilities to withstand DDoS attacks:
    - Shuffle Sharding — spreads DNS requests over numerous PoPs using independent sets of edge locations, providing multiple paths to your application
    - Anycast Routing — advertises the same IP address from multiple PoPs, increasing redundancy; if one endpoint is overwhelmed, traffic routes to others
- AWS Global Accelerator
  - Uses static anycast IP addresses as entry points to the AWS global network
  - Integrates with AWS Shield for DDoS mitigation at the edge, including a stateless SYN proxy that challenges new connections and only serves legitimate end users
  - Routes traffic over the AWS backbone network, away from the congested public internet
  - Provides fault isolation and deterministic routing for improved DDoS resiliency

Safeguard Exposed & Hard-to-Scale Resources

If entry points cannot be limited, additional measures to restrict access and protect those entry points without interrupting legitimate end user traffic
AWS services for protection:
- CloudFront
  - Restrict access using Geo Restriction and Origin Access Control (OAC)
  - With Geo Restriction, access can be restricted to whitelisted countries or blocked from blacklisted countries
  - Origin Access Control (OAC) replaces the legacy Origin Access Identity (OAI) — allows access to S3 origins only through CloudFront while denying direct access. OAC supports SSE-KMS, dynamic requests, and all S3 regions.
- Route 53
  - Alias Record sets and Private DNS make it easier to scale infrastructure and respond to DDoS attacks
  - Route 53 health checks enable automatic failover to healthy resources
- AWS WAF (Web Application Firewall)
  - AWS WAF is a fully managed service (not EC2-based) that filters web traffic using customizable rules
  - Integrates directly with CloudFront, ALB, API Gateway, AppSync, App Runner, Cognito, and Verified Access
  - Key capabilities:
    - Rate-based rules — automatically blocks IPs exceeding request thresholds
    - Managed Rule Groups — pre-built rules for OWASP Top 10, known bad inputs, SQL injection, XSS
    - Bot Control — managed bot detection and mitigation covering 650+ unique bots and AI agents
    - Fraud Control — Account Takeover Prevention (ATP) and Account Creation Fraud Prevention (ACFP)
    - Anti-DDoS Managed Rule Group (AWSManagedRulesAntiDDoSRuleSet) — launched March 2026 as the default L7 DDoS protection; establishes traffic baselines, detects anomalies within seconds, and mitigates HTTP floods automatically
    - AI Bot Management — AI Activity Dashboard (Feb 2026) for visibility into AI scrapers, tools, and agents; supports AI traffic monetization
    - Geo-match conditions, IP set rules, regex pattern sets
    - Custom response bodies and headers
  - No longer requires the “WAF sandwich” pattern — AWS WAF is now a native, managed Layer 7 service that does not require separate EC2 instances
- AWS Shield Advanced
  - Provides managed DDoS protection for CloudFront, Route 53, Global Accelerator, ELB, and EC2 Elastic IPs
  - Key features:
    - Always-on detection and automatic mitigation with sub-second time-to-mitigate
    - Application layer automatic mitigation — automatically deploys WAF rules during attacks
    - Shield Response Team (SRT) — 24/7 expert support during active DDoS events
    - Cost protection — credits for scaling charges incurred during DDoS attacks
    - DDoS visibility — real-time metrics, attack notifications, and forensic reports
    - Health-based detection — uses Route 53 health checks to improve detection accuracy and reduce false positives
    - Network Security Director (Preview, June 2025) — discovers resources, visualizes network topology, identifies security misconfigurations, and provides remediation recommendations using Amazon Q Developer
- AWS Firewall Manager
  - Centrally configure and manage AWS WAF rules, Shield Advanced protections, security groups, Network Firewall, and DNS Firewall policies across all accounts in AWS Organizations
  - Automatically applies security policies to new resources as they are created
  - Provides compliance monitoring and reporting

DDOS Resiliency - WAF Sandwich Architecture (Legacy Pattern)

Note: The WAF Sandwich pattern shown above is a legacy architecture. AWS WAF is now a fully managed service that integrates natively with ALB, CloudFront, API Gateway, and other services — no separate EC2-based WAF instances are needed.

Learn Normal Behavior

Understand the normal levels and patterns of traffic for your application and use that as a benchmark for identifying abnormal traffic or resource spikes
Benefits:
- Allows one to spot abnormalities
- Configure alarms with accurate thresholds
- Assists with generating forensic data
AWS services for tracking and detection:
- Amazon CloudWatch
  - Monitor infrastructure and applications running on AWS
  - Collect metrics, log files, and set alarms for when metrics pass predetermined thresholds
  - Shield Advanced publishes DDoS metrics: DDoSDetected, DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond, DDoSAttackRequestsPerSecond
- VPC Flow Logs
  - Capture traffic to instances in a VPC to understand traffic patterns and detect anomalies
  - Can be published to CloudWatch Logs or S3 for analysis
- AWS WAF Logging & Metrics
  - Full logging of all evaluated requests to S3, CloudWatch Logs, or Kinesis Data Firehose
  - Real-time metrics in CloudWatch for blocked/allowed/counted requests
  - Traffic Overview Dashboard (2025) — near-real-time summaries including total requests, blocked requests, bot categories, CAPTCHA solve rates, and top matched rules
- AWS CloudTrail
  - Logs API calls for auditing configuration changes to WAF, Shield, and security groups

Create a Plan for Attacks

Have a plan in place before an attack, which ensures that:
- Architecture has been validated and techniques selected work for the infrastructure
- Costs for increased resiliency have been evaluated and the goals of your defense are understood
- Contact points have been identified
- Runbooks exist for DDoS incident response
AWS Shield Advanced SRT engagement — proactive or reactive engagement with DDoS experts
AWS Support — Business or Enterprise Support plans provide access to 24/7 support during attacks

DDoS-Resilient Reference Architecture

AWS recommends using the following services at the edge for maximum DDoS resiliency:

Edge Layer: Amazon CloudFront + AWS WAF + AWS Shield (Standard/Advanced) + Amazon Route 53
Network Layer: AWS Global Accelerator + Elastic Load Balancing (ALB/NLB) + VPC with NACLs and Security Groups
Application Layer: Auto Scaling groups + EC2 instances in multiple AZs
Management Layer: AWS Firewall Manager for centralized policy management across accounts

Key principle: Push traffic as far from the origin as possible using CloudFront, Global Accelerator, and Route 53 to leverage AWS’s globally distributed DDoS mitigation capacity (terabits scale).

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 are designing a social media site and are considering how to mitigate distributed denial-of-service (DDoS) attacks. Which of the below are viable mitigation techniques? (Choose 3 answers)
1. Add multiple elastic network interfaces (ENIs) to each EC2 instance to increase the network bandwidth.
2. Use dedicated instances to ensure that each instance has the maximum performance possible.
3. Use an Amazon CloudFront distribution for both static and dynamic content.
4. Use an Elastic Load Balancer with auto scaling groups at the web app and Amazon Relational Database Service (RDS) tiers
5. Add alert Amazon CloudWatch to look for high Network in and CPU utilization.
6. Create processes and capabilities to quickly add and remove rules to the instance OS firewall.
You’ve been hired to enhance the overall security posture for a very large e-commerce site. They have a well architected multi-tier application running in a VPC that uses ELBs in front of both the web and the app tier with static assets served directly from S3. They are using a combination of RDS and DynamoDB for their dynamic data and then archiving nightly into S3 for further processing with EMR. They are concerned because they found questionable log entries and suspect someone is attempting to gain unauthorized access. Which approach provides a cost effective scalable mitigation to this kind of attack?
1. Recommend that they lease space at a DirectConnect partner location and establish a 1G DirectConnect connection to their VPC they would then establish Internet connectivity into their space, filter the traffic in hardware Web Application Firewall (WAF). And then pass the traffic through the DirectConnect connection into their application running in their VPC. (Not cost effective)
2. Add previously identified hostile source IPs as an explicit INBOUND DENY NACL to the web tier subnet. (does not protect against new source)
3. Add a WAF tier by creating a new ELB and an AutoScaling group of EC2 Instances running a host-based WAF. They would redirect Route 53 to resolve to the new WAF tier ELB. The WAF tier would then pass the traffic to the current web tier. The web tier Security Groups would be updated to only allow traffic from the WAF tier Security Group (Note: This describes the legacy “WAF sandwich” pattern. In modern AWS, you would simply enable AWS WAF on the existing ALB — no separate EC2 WAF tier is needed.)
4. Remove all but TLS 1.2 from the web tier ELB and enable Advanced Protocol Filtering This will enable the ELB itself to perform WAF functionality. (No advanced protocol filtering in ELB)
A company wants to protect its web application from Layer 7 DDoS attacks and common web exploits. The application uses Amazon CloudFront with an Application Load Balancer origin. Which combination of AWS services provides the MOST effective protection? (Choose 2 answers)
1. Enable AWS Shield Advanced on the CloudFront distribution and ALB with automatic application layer DDoS mitigation
2. Deploy AWS Network Firewall in front of the ALB
3. Associate an AWS WAF web ACL with rate-based rules and the Anti-DDoS Managed Rule Group on the CloudFront distribution
4. Use Security Groups on the ALB to block malicious IPs
5. Enable VPC Flow Logs and manually block attacking IPs
A security team needs to protect multiple AWS accounts’ web applications from DDoS attacks with consistent security policies. Which approach provides centralized management with automatic enforcement?
1. Manually configure AWS WAF rules on each account’s resources
2. Use AWS Firewall Manager to define WAF and Shield Advanced policies across the AWS Organization
3. Deploy third-party WAF appliances in each VPC
4. Use AWS Config rules to audit WAF configurations
Which AWS service provides automatic, always-on protection against common DDoS attacks at no additional cost for ALL AWS customers?
1. AWS WAF
2. AWS Shield Standard
3. AWS Shield Advanced
4. AWS Firewall Manager
A company is experiencing an active DDoS attack on their application behind CloudFront. They have AWS Shield Advanced enabled. Which features are available to help mitigate the attack? (Choose 3 answers)
1. 24/7 access to the AWS Shield Response Team (SRT)
2. Automatic VPC security group rule updates
3. Automatic application layer mitigation through managed WAF rules
4. Cost protection credits for scaling charges incurred during the attack
5. Automatic CloudFront distribution disablement

References

AWS VPC Cheat Sheet – Subnets, Route Tables, NAT & Gateways

March 21, 2016 ~ Last updated on : September 19, 2026 ~ jayendrapatil ~ 201 Comments

AWS VPC – Virtual Private Cloud

AWS VPC – Virtual Private Cloud is a virtual network dedicated to the AWS account. It is logically isolated from other virtual networks in the AWS cloud.
VPC allows the users complete control over their virtual networking environment, including the selection of their own IP address range, creation of subnets, and configuration of route tables and network gateways.
VPC allows you to use both IPv4 and IPv6 in your VPC for secure and easy access to resources and applications.
VPC is a regional service and it spans all of the AZs in the Region. Availability zones (AZ) are multiple, isolated locations within each Region.

VPC Sizing
- VPC needs a set of IP addresses in the form of a Classless Inter-Domain Routing (CIDR) block for e.g, 10.0.0.0/16, which allows 2^16 (65536) IP address to be available
- Allowed CIDR block size is between
  - /28 netmask (minimum with 2^4 – 16 available IP address) and
  - /16 netmask (maximum with 2^16 – 65536 IP address)
- CIDR block from private (non-publicly routable) IP address can be assigned
  - 10.0.0.0 – 10.255.255.255 (10/8 prefix)
  - 172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
  - 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)
- It’s possible to specify a range of publicly routable IP addresses; however, direct access to the Internet is not currently supported from publicly routable CIDR blocks in a VPC
- ~~CIDR block once assigned to the VPC cannot be modified.~~ NOTE – You can now resize VPC. Read AWS blog post.
- Each VPC is separate from any other VPC created with the same CIDR block even if it resides within the same AWS account
Connection between your VPC and corporate or home network can be established, however, the CIDR blocks should be not be overlapping for e.g. VPC with CIDR 10.0.0.0/16 can communicate with 10.1.0.0/16 corporate network but the connections would be dropped if it tries to connect to 10.0.37.0/16 corporate network cause of overlapping IP addresses.
VPC allows you to set tenancy options for the Instances launched in it. By default, the tenancy option is shared. If the dedicated option is selected, all the instances within it are launched on dedicated hardware overriding the individual instance tenancy setting.
Deletion of the VPC is possible only after terminating all instances within the VPC and deleting all the components with the VPC e.g. subnets, security groups, network ACLs, route tables, Internet gateways, VPC peering connections, and DHCP options
VPC Peering provides a networking connection between two VPCs (same or different account and region) that enables routing of traffic between them using private IPv4 addresses or IPv6 addresses.
NAT Gateway enables instances in a private subnet to connect to the Internet but prevents the Internet from initiating connections with the instances.
VPC endpoints enable the creation of a private connection between VPC to supported AWS services and VPC endpoint services powered by PrivateLink using its private IP address.

Subnets

Subnet spans a single Availability Zone, distinct locations engineered to be isolated from failures in other AZs, and cannot span across AZs
Subnet can be configured with an Internet gateway to enable communication over the Internet, or virtual private gateway (VPN) connection to enable communication with your corporate network
Subnet can be Public or Private and it depends on whether it has Internet connectivity i.e. is able to route traffic to the Internet through the IGW
Instances within the Public Subnet should be assigned a Public IP or Elastic IP address to be able to communicate with the Internet
For Subnets not connected to the Internet, but has traffic routed through Virtual Private Gateway only is termed as VPN-only subnet
Subnets can be configured to Enable assignment of the Public IP address to all the Instances launched within the Subnet by default, which can be overridden during the creation of the Instance
Subnet Sizing
- CIDR block assigned to the Subnet can be the same as the VPC CIDR, in this case you can launch only one subnet within your VPC
- CIDR block assigned to the Subnet can be a subset of the VPC CIDR, which allows you to launch multiple subnets within the VPC
- CIDR block assigned to the subnet should not be overlapping
- CIDR block size allowed is between
  - /28 netmask (minimum with 2^4 – 16 available IP address) and
  - /16 netmask (maximum with 2^16 – 65536 IP address)
- AWS reserves 5 IPs address (first 4 and last 1 IP address) in each Subnet which are not available for use and cannot be assigned to an instance. for e.g. for a Subnet with a CIDR block 10.0.0.0/24 the following five IPs are reserved
  - 10.0.0.0: Network address
  - 10.0.0.1: Reserved by AWS for the VPC router
  - 10.0.0.2: Reserved by AWS for mapping to Amazon-provided DNS
  - 10.0.0.3: Reserved by AWS for future use
  - 10.0.0.255: Network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved.
Subnet Routing
- Each Subnet is associated with a route table that controls the traffic.
Subnet Security
- Subnet security can be configured using Security groups and NACLs
- Security groups work at the instance level, and NACLs work at the subnet level

VPC & Subnet Sizing

VPC supports IPv4 and IPv6 addressing and has different CIDR block size limits for each
IPv6 CIDR block can be optionally associated with the VPC
VPC IPv4 CIDR block cannot be modified once created i.e. cannot increase or decrease the size of an existing CIDR block.
However, secondary CIDR blocks can be associated with the VPC to extend the VPC
Limitations
- allowed block size is between a /28 netmask and /16 netmask.
- CIDR block must not overlap with any existing CIDR block that’s associated with the VPC.
- CIDR block must not be the same or larger than the CIDR range of a route in any of the VPC route tables for e.g. for a CIDR block 10.0.0.0/24, can only associate smaller CIDR blocks like 10.0.0.0/25

IP Addresses

Instances launched in the VPC can have Private, Public, and Elastic IP addresses assigned to them and are properties of ENI (Network Interfaces)

Private IP Addresses
- Private IP addresses are not reachable over the Internet, and can be used for communication only between the instances within the VPC
- All instances are assigned a private IP address, within the IP address range of the subnet, to the default network interface
- Primary IP address is associated with the network interface for its lifetime, even when the instance is stopped and restarted and is released only when the instance is terminated
- Additional Private IP addresses, known as secondary private IP address, can be assigned to the instances and these can be reassigned from one network interface to another
Public IP address
- Public IP addresses are reachable over the Internet, and can be used for communication between instances and the Internet, or with other AWS services that have public endpoints
- Public IP address assignment to the Instance depends if the Public IP Addressing is enabled for the Subnet.
- Public IP address can also be assigned to the Instance by enabling the Public IP addressing during the creation of the instance, which overrides the subnet’s public IP addressing attribute
- Public IP address is assigned from AWS pool of IP addresses and it is not associated with the AWS account and hence is released when the instance is stopped and restarted or terminated.
Elastic IP address
- Elastic IP addresses are static, persistent public IP addresses that can be associated and disassociated with the instance, as required
- Elastic IP address is allocated to the VPC and owned by the account unless released.
- A Network Interface can be assigned either a Public IP or an Elastic IP. If you assign an instance, that already has a Public IP, an Elastic IP, the public IP is released
- Elastic IP addresses can be moved from one instance to another, which can be within the same or different VPC within the same account
- Elastic IPs are charged for non-usage i.e. if it is not associated or associated with a stopped instance or an unattached Network Interface

Elastic Network Interface (ENI)

Each Instance is attached to a default elastic network interface (Primary Network Interface eth0) and cannot be detached from the instance
ENI can include the following attributes
- Primary private IP address
- One or more secondary private IP addresses
- One Elastic IP address per private IP address
- One public IP address, which can be auto-assigned to the network interface for eth0 when you launch an instance, but only when you create a network interface for eth0 instead of using an existing ENI
- One or more security groups
- A MAC address
- A source/destination check flag
- A description
ENI’s attributes follow the ENI as it is attached or detached from an instance and reattached to another instance. When an ENI is moved from one instance to another, network traffic is redirected to the new instance.
Multiple ENIs can be attached to an instance and is useful for use cases:
- Create a management network.
- Use network and security appliances in your VPC.
- Create dual-homed instances with workloads/roles on distinct subnets.
- Create a low-budget, high-availability solution.

Route Tables

Route table defines rules, termed as routes, which determine where network traffic from the subnet would be routed
Each VPC has an implicit router to route network traffic
Each VPC has a Main Route table and can have multiple custom route tables created
Each Subnet within a VPC must be associated with a single route table at a time, while a route table can have multiple subnets associated with it
Subnet, if not explicitly associated to a route table, is implicitly associated with the main route table
Every route table contains a local route that enables communication within a VPC which cannot be modified or deleted
Route priority is decided by matching the most specific route in the route table that matches the traffic
Route tables need to be updated to define routes for Internet gateways, Virtual Private gateways, VPC Peering, VPC Endpoints, NAT Devices, etc.

VPC Route Server

Amazon VPC Route Server enables dynamic routing within a VPC using Border Gateway Protocol (BGP), simplifying routing between virtual appliances and cloud workloads.
VPC Route Server was announced GA in April 2025 and expanded to additional regions in January 2026.
Key Capabilities
- Deploy Route Server endpoints in VPC and peer with virtual appliances using BGP
- Dynamically updates VPC and internet gateway route tables with preferred IPv4 or IPv6 routes
- Achieves routing fault tolerance for workloads running in subnets
- Automatically reroutes traffic within a VPC for active/standby failover without static routes or manual intervention
- Standard BGP attributes used for route filtering and selection
Use Cases
- Network appliance high availability (automatic failover via BGP)
- Centralized inspection with Transit Gateway for active/standby architectures
- Third-party firewall and SD-WAN appliance integration
- Replacing custom Lambda-based route failover scripts
VPC Route Server eliminates the need for complex scripting or third-party solutions to handle dynamic routing and failover scenarios within a VPC.

Internet Gateways – IGW

An Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in the VPC and the Internet.
IGW imposes no availability risks or bandwidth constraints on the network traffic.
An Internet gateway serves two purposes:
- To provide a target in the VPC route tables for Internet-routable traffic,
- To perform network address translation (NAT) for instances that have been NOT been assigned public IP addresses.
Enabling Internet access to an Instance requires
- Attaching Internet gateway to the VPC
- Subnet should have route tables associated with the route pointing to the Internet gateway
- Instances should have a Public IP or Elastic IP address assigned
- Security groups and NACLs associated with the Instance should allow relevant traffic

NAT

NAT device enables instances in a private subnet to connect to the Internet or other AWS services, but prevents the Internet from initiating connections with the instances.
NAT devices do not support IPv6 traffic, use an egress-only Internet gateway instead.

Refer to My Blog Post about VPC NAT

Egress-only Internet gateway

Egress-only Internet gateway works as a NAT gateway, but for IPv6 traffic
Egress-only Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound communication over IPv6 from instances in the VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with the instances.
An egress-only Internet gateway is for use with IPv6 traffic only. To enable outbound-only Internet communication over IPv4, use a NAT gateway instead.

Shared VPCs

VPC sharing allows multiple AWS accounts to create their application resources, such as EC2 instances, RDS databases, Redshift clusters, and AWS Lambda functions, into shared, centrally-managed VPCs.
In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations.
After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.

VPC Endpoints

VPC endpoint enables the creation of a private connection between VPC to supported AWS services and VPC endpoint services powered by PrivateLink using its private IP address
Endpoints do not require a public IP address, access over the Internet, NAT device, a VPN connection, or AWS Direct Connect.
Traffic between VPC and AWS service does not leave the Amazon network
Endpoints are virtual devices, that are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and AWS services without imposing availability risks or bandwidth constraints on your network traffic.
Endpoints currently do not support cross-region requests, ensure that the endpoint is created in the same region as the S3 bucket
AWS currently supports the following types of Endpoints
- VPC Gateway Endpoints
- VPC Interface Endpoints

Refer to My Blog Post about VPC Endpoint

VPC Peering

A VPC peering connection is a networking connection between two VPCs that enables the routing of traffic between them using private IPv4 addresses or IPv6 addresses.
VPC peering connection is a one-to-one relationship between two VPCs and can be established between your own VPCs, or with a VPC in another AWS account in the same or different region.
VPC peering helps instances in either VPC can communicate with each other as if they are within the same network using AWS’s existing infrastructure of a VPC to create a peering connection; it is neither a gateway nor a VPN connection and does not rely on a separate piece of physical hardware.
VPC peering does not have any separate charges. However, there are data transfer charges.

Refer to My Blog Post about VPC Peering

VPC VPN Connections

Refer to My Blog Post about AWS VPC VPN Connections

VPC Security

In a VPC, both Security Groups and Network ACLs (NACLS) together help to build a layered network defense.
Security groups – Act as a virtual firewall for associated instances, controlling both inbound and outbound traffic at the instance level
Network access control lists (NACLs) – Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level

Security Groups & NACLs

Refer to My Blog Post about AWS Security Group vs NACLs

VPC Flow logs

VPC Flow Logs 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.
Flow log data can be published to CloudWatch Logs, S3, and Kinesis Data Firehose.
Flow log can be created for the entire VPC, subnets, or each network interface. If enabled, for the entire VPC or subnet all the network interfaces within that resource are monitored.
Flow log can be configured to capture the type of traffic (accepted traffic, rejected traffic, or all traffic).
Flow logs do not capture real-time log streams for network interfaces.
Flow log data is collected outside of the path of the network traffic, and therefore does not affect network throughput or latency.
Flow logs can be created for network interfaces that are created by other AWS services; for e.g., ELB, RDS, ElastiCache, Redshift, and WorkSpaces.
Flow logs do not capture the following traffic
- Traffic generated by instances when they contact the Amazon DNS server.
- Traffic generated by a Windows instance for Amazon Windows license activation.
- Traffic to and from 169.254.169.254 for instance metadata
- Traffic to and from 169.254.169.123 for the Amazon Time Sync Service.
- DHCP traffic.
- Mirrored traffic.
- Traffic to the reserved IP address for the default VPC router.
- Traffic between an endpoint network interface and a Network Load Balancer network interface.
Troubleshooting traffic flow
- 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.

VPC Block Public Access (BPA)

Amazon VPC Block Public Access (BPA) is a simple, declarative control that authoritatively blocks incoming (ingress) and outgoing (egress) VPC traffic through AWS-provided internet paths (launched November 2024).
VPC BPA supersedes any existing VPC settings (route tables, security groups, NACLs) to drop all traffic that would otherwise be exposed to the internet through Internet Gateways (IGW) or Egress-Only Internet Gateways (EIGW).
Key Features
- Single declarative control to block internet access to/from VPCs and subnets
- Can be set to bidirectional block (blocks all ingress and egress) or ingress-only block
- Prevents accidental public exposure regardless of routing and security configuration
- Supports subnet-level exclusions for DMZ architectures
- Centralized enforcement across an AWS Organization
Deployment
- Can be deployed across AWS Organizations using AWS CloudFormation or CLI
- Supports IPv4 and IPv6 traffic blocking
- Available in all commercial AWS regions and AWS China Regions (May 2025)
BPA is useful for accounts that should have no internet access (data processing, backend services) while allowing exceptions for specific subnets that require internet connectivity.

VPC Encryption Controls

VPC Encryption Controls is a security and compliance feature that provides centralized control to monitor and enforce encryption in transit for all traffic flows within and across VPCs in a region (GA 2025, paid feature from March 1, 2026).
VPC Encryption Controls uses both application-layer encryption and built-in encryption in transit capability of AWS Nitro System hardware to ensure encryption enforcement.
Operational Modes
- Monitor mode – Audit the encryption status of traffic flows and identify resources allowing cleartext traffic
- Enforce mode – Prevents creation or use of resources that allow unencrypted traffic; all traffic must be encrypted at hardware layer (Nitro) or application layer (TLS/SSL)
Key Capabilities
- Centralized encryption policy enforcement across VPCs
- Generates audit logs for compliance and reporting
- Identifies resources that allow plaintext traffic
- Works with Transit Gateway for inter-VPC encryption
- Available in AWS GovCloud (US) Regions as of March 2026
Pricing
- Fixed hourly rate for every non-empty VPC (with network interfaces) that has Encryption Controls enabled in either monitor or enforce mode
VPC Encryption Controls helps security teams demonstrate encryption compliance without relying on individual application teams to implement TLS correctly.

AWS VPC IP Address Manager (IPAM)

Amazon VPC IP Address Manager (IPAM) is a fully managed service that simplifies IP address management across AWS environments.
IPAM provides centralized visibility and control over IP address allocations across multiple AWS Regions and accounts within an AWS Organization.
Key benefits of IPAM:
- Eliminates manual IP address tracking via spreadsheets or disparate systems
- Automated IP address allocation and tracking
- Prevents IP address conflicts and overlaps
- Provides holistic view of IP address utilization
- Supports both IPv4 and IPv6 address management
IPAM Features
- Hierarchical pool structure for organizing IP address space
- Automated CIDR allocation for VPCs and subnets
- Cross-region and cross-account IP address visibility
- Integration with AWS Organizations for centralized management
- Compliance monitoring and reporting
- IP address history and audit trails
IPAM Advanced Tier (launched 2025)
- Infoblox infrastructure integration for hybrid cloud IP management
- Manage AWS IP addresses through existing Infoblox workflows
- Available for private scopes
- Enhanced enterprise-grade capabilities
IPAM Integrations
- Application Load Balancer (ALB) integration for predictable IP address blocks (March 2025)
- IPAM Policies support for RDS and Application Load Balancers (January 2026)
- Amazon CloudFront BYOIP for IPv6 through VPC IPAM integration (March 2026)
- VPC CIDR allocation automation
- AWS Resource Access Manager (RAM) for sharing IP pools
- CloudWatch for monitoring and alerting
IPAM Pool Allocation Tags (May 2026)
- Supports tags on IPAM pool allocations for organizing, governing, and controlling access to individual IP address allocations
- Uses same tagging workflows as other AWS resources
- Enables fine-grained access control via IAM policies based on allocation tags
IPAM helps network administrators organize, assign, monitor, and audit IP addresses at scale, reducing management burden and eliminating manual errors.
IPAM is available across all AWS commercial regions, including Asia Pacific (Taipei) as of June 2025.

Amazon VPC Lattice

Amazon VPC Lattice is an application networking service that simplifies service-to-service communication across VPCs and AWS accounts.
VPC Lattice operates at Layer 4 (TCP) and Layer 7 (HTTP/HTTPS) to provide intelligent application-layer routing.
VPC Lattice eliminates the need for complex networking configurations, Transit Gateways, or sidecar-based service meshes.
Key Capabilities
- Service-to-service connectivity across VPCs and accounts without IP address management
- Built-in service discovery and routing
- Application-layer authentication and authorization
- Centralized observability and monitoring
- Zero-trust security model with fine-grained access controls
Service Networks
- Logical container for grouping related services
- Provides consistent security policies across services
- Can be shared across AWS accounts using AWS Resource Access Manager (RAM)
- Enables cross-account connectivity at scale
- VPC can have only one service network association
VPC Lattice vs Traditional Networking
- Simpler than Transit Gateway for service-to-service communication
- No need for VPC Peering connections between every VPC pair
- Application-aware routing based on headers, paths, and methods
- Automatic service discovery without DNS management
- Built-in security without managing security groups across VPCs
Migration from AWS App Mesh
- AWS App Mesh is being discontinued effective September 30, 2026
- VPC Lattice is the recommended replacement for App Mesh workloads
- VPC Lattice provides similar service mesh capabilities without sidecar proxies
- Simplified architecture with centralized management
VPC Lattice integrates with Amazon ECS, EKS, EC2, Lambda, and other compute services.
Resource Configurations (Enhanced 2025-2026)
- Defines private endpoints (IP address or DNS name) within a VPC for cross-account access
- Supports custom domain names for resource configurations (November 2025)
- Supports private domain-name targets for secure cross-account access to privately-hosted resources (May 2026)
- Attached to resource gateways and shared via AWS RAM
Use cases include microservices architectures, multi-account applications, and hybrid cloud connectivity.

AWS Network Firewall

AWS Network Firewall is a fully managed network security service that protects VPCs from network threats.
Network Firewall provides enterprise-grade perimeter defense with deep packet inspection and intrusion prevention.
Key Features
- Stateful and stateless firewall rules
- Deep packet inspection (DPI) for Layer 7 traffic analysis
- Intrusion detection and prevention system (IDS/IPS)
- Domain name filtering and URL filtering
- Protocol detection and blocking
- Geographic IP filtering
Flexible Rules Engine
- Supports thousands of custom firewall rules
- Rules based on domain, port, protocol, IP addresses, and pattern matching
- Suricata-compatible IPS rules for threat detection
- AWS Managed Threat Signatures for known threats
- Active threat defense against command-and-control channels and malicious URLs
Traffic Filtering Capabilities
- Inbound and outbound web filtering for HTTP/HTTPS traffic
- Server Name Indication (SNI) filtering for encrypted traffic
- Application protocol detection and enforcement
- Malware and botnet protection
- DDoS attack mitigation
Deployment and Scalability
- Deployed at VPC subnet boundaries
- Automatically scales based on traffic load
- High availability with 99.99% SLA
- Multi-AZ deployment for redundancy
- No capacity planning required
Logging and Monitoring
- Detailed flow logs for all inspected traffic
- Alert logs for detected threats
- Integration with CloudWatch, S3, and Kinesis Data Firehose
- Real-time visibility into network traffic patterns
- Compliance reporting and audit trails
Network Firewall integrates with AWS Firewall Manager for centralized policy management across multiple accounts and VPCs.
Default Stateful Action Update (June 2026)
- New default stateful action for firewall policies changed to “Application drop established (server-directed only)” replacing “Application drop established (bidirectional)”
- Improves connection reliability for legitimate traffic
- Applies to all newly created firewall policies
Common use cases include perimeter security, egress filtering, threat prevention, and compliance enforcement.

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 business-to-business web application running in a VPC consisting of an Elastic Load Balancer (ELB), web servers, application servers and a database. Your web application should only accept traffic from predefined customer IP addresses. Which two options meet this security requirement? Choose 2 answers
1. Configure web server VPC security groups to allow traffic from your customers’ IPs (Web server is behind the ELB and customer IPs will never reach web servers)
2. Configure your web servers to filter traffic based on the ELB’s “X-forwarded-for” header (get the customer IPs and create a custom filter to restrict access. Refer link)
3. Configure ELB security groups to allow traffic from your customers’ IPs and deny all outbound traffic (ELB will see the customer IPs so can restrict access, deny all is basically have no rules in outbound traffic, implicit, and its stateful so would work)
4. Configure a VPC NACL to allow web traffic from your customers’ IPs and deny all outbound traffic (NACL is stateless, deny all will not work)
A user has created a VPC with public and private subnets using the VPC Wizard. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.0.0/24. Which of the below mentioned entries are required in the main route table to allow the instances in VPC to communicate with each other?
1. Destination : 20.0.0.0/24 and Target : VPC
2. Destination : 20.0.0.0/16 and Target : ALL
3. Destination : 20.0.0.0/0 and Target : ALL
4. Destination : 20.0.0.0/16 and Target : Local
A user has created a VPC with two subnets: one public and one private. The user is planning to run the patch update for the instances in the private subnet. How can the instances in the private subnet connect to the internet?
1. Use the internet gateway with a private IP
2. Allow outbound traffic in the security group for port 80 to allow internet updates
3. The private subnet can never connect to the internet
4. Use NAT with an elastic IP
A user has launched an EC2 instance and installed a website with the Apache webserver. The webserver is running but the user is not able to access the website from the Internet. What can be the possible reason for this failure?
1. The security group of the instance is not configured properly.
2. The instance is not configured with the proper key-pairs.
3. The Apache website cannot be accessed from the Internet.
4. Instance is not configured with an elastic IP.
A user has created a VPC with public and private subnets using the VPC wizard. Which of the below mentioned statements is true in this scenario?
1. AWS VPC will automatically create a NAT instance with the micro size
2. VPC bounds the main route table with a private subnet and a custom route table with a public subnet
3. User has to manually create a NAT instance
4. VPC bounds the main route table with a public subnet and a custom route table with a private subnet
A user has created a VPC with public and private subnets. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.1.0/24 and the public subnet uses CIDR 20.0.0.0/24. The user is planning to host a web server in the public subnet (port 80) and a DB server in the private subnet (port 3306). The user is configuring a security group of the NAT instance. Which of the below mentioned entries is not required for the NAT security group?
1. For Inbound allow Source: 20.0.1.0/24 on port 80
2. For Outbound allow Destination: 0.0.0.0/0 on port 80
3. For Inbound allow Source: 20.0.0.0/24 on port 80
4. For Outbound allow Destination: 0.0.0.0/0 on port 443
A user has created a VPC with CIDR 20.0.0.0/24. The user has used all the IPs of CIDR and wants to increase the size of the VPC. The user has two subnets: public (20.0.0.0/25) and private (20.0.0.128/25). How can the user change the size of the VPC?
1. The user can delete all the instances of the subnet. Change the size of the subnets to 20.0.0.0/32 and 20.0.1.0/32, respectively. Then the user can increase the size of the VPC using CLI
2. It is not possible to change the size of the VPC once it has been created (NOTE – You can now increase the VPC size. Read Post)
3. User can add a subnet with a higher range so that it will automatically increase the size of the VPC
4. User can delete the subnets first and then modify the size of the VPC
A user has created a VPC with the public and private subnets using the VPC wizard. The VPC has CIDR 20.0.0.0/16. The public subnet uses CIDR 20.0.1.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 for the public subnet (WebSecGrp) and the private subnet (DBSecGrp). Which of the below mentioned entries is required in the web server security group (WebSecGrp)?
1. Configure Destination as DB Security group ID (DbSecGrp) for port 3306 Outbound
2. Configure port 80 for Destination 0.0.0.0/0 Outbound
3. Configure port 3306 for source 20.0.0.0/24 InBound
4. Configure port 80 InBound for source 20.0.0.0/16
A user has created a VPC with CIDR 20.0.0.0/16. The user has created one subnet with CIDR 20.0.0.0/16 by mistake. The user is trying to create another subnet of CIDR 20.0.0.1/24. How can the user create the second subnet?
1. There is no need to update the subnet as VPC automatically adjusts the CIDR of the first subnet based on the second subnet’s CIDR
2. The user can modify the first subnet CIDR from the console
3. It is not possible to create a second subnet as one subnet with the same CIDR as the VPC has been created
4. The user can modify the first subnet CIDR with AWS CLI
A user has setup a VPC with CIDR 20.0.0.0/16. The VPC has a private subnet (20.0.1.0/24) and a public subnet (20.0.0.0/24). The user’s data centre has CIDR of 20.0.54.0/24 and 20.1.0.0/24. If the private subnet wants to communicate with the data centre, what will happen?
1. It will allow traffic communication on both the CIDRs of the data centre
2. It will not allow traffic with data centre on CIDR 20.1.0.0/24 but allows traffic communication on 20.0.54.0/24
3. It will not allow traffic communication on any of the data centre CIDRs
4. It will allow traffic with data centre on CIDR 20.1.0.0/24 but does not allow on 20.0.54.0/24 (as the CIDR block would be overlapping)
A user has created a VPC with public and private subnets using the VPC wizard. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.0.0/24 . The NAT instance ID is i-a12345. Which of the below mentioned entries are required in the main route table attached with the private subnet to allow instances to connect with the internet?
1. Destination: 0.0.0.0/0 and Target: i-a12345
2. Destination: 20.0.0.0/0 and Target: 80
3. Destination: 20.0.0.0/0 and Target: i-a12345
4. Destination: 20.0.0.0/24 and Target: i-a12345
A user has created a VPC with CIDR 20.0.0.0/16 using the wizard. The user has created a public subnet CIDR (20.0.0.0/24) and VPN only subnets CIDR (20.0.1.0/24) along with the VPN gateway (vgw-12345) to connect to the user’s data centre. The user’s data centre has CIDR 172.28.0.0/12. The user has also setup a NAT instance (i-123456) to allow traffic to the internet from the VPN subnet. Which of the below mentioned options is not a valid entry for the main route table in this scenario?
1. Destination: 20.0.1.0/24 and Target: i-12345
2. Destination: 0.0.0.0/0 and Target: i-12345
3. Destination: 172.28.0.0/12 and Target: vgw-12345
4. Destination: 20.0.0.0/16 and Target: local
A user has created a VPC with CIDR 20.0.0.0/16. The user has created one subnet with CIDR 20.0.0.0/16 in this VPC. The user is trying to create another subnet with the same VPC for CIDR 20.0.0.1/24. What will happen in this scenario?
1. The VPC will modify the first subnet CIDR automatically to allow the second subnet IP range
2. It is not possible to create a subnet with the same CIDR as VPC
3. The second subnet will be created
4. It will throw a CIDR overlaps error
A user has created a VPC with CIDR 20.0.0.0/16 using the wizard. The user has created both Public and VPN-Only subnets along with hardware VPN access to connect to the user’s data centre. The user has not yet launched any instance as well as modified or deleted any setup. He wants to delete this VPC from the console. Will the console allow the user to delete the VPC?
1. Yes, the console will delete all the setups and also delete the virtual private gateway
2. No, the console will ask the user to manually detach the virtual private gateway first and then allow deleting the VPC
3. Yes, the console will delete all the setups and detach the virtual private gateway
4. No, since the NAT instance is running
A user has created a VPC with the public and private subnets using the VPC wizard. The VPC has CIDR 20.0.0.0/16. The public subnet uses CIDR 20.0.1.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 for the public subnet (WebSecGrp) and the private subnet (DBSecGrp). Which of the below mentioned entries is required in the private subnet database security group (DBSecGrp)?
1. Allow Inbound on port 3306 for Source Web Server Security Group (WebSecGrp)
2. Allow Inbound on port 3306 from source 20.0.0.0/16
3. Allow Outbound on port 3306 for Destination Web Server Security Group (WebSecGrp.
4. Allow Outbound on port 80 for Destination NAT Instance IP
A user has created a VPC with a subnet and a security group. The user has launched an instance in that subnet and attached a public IP. The user is still unable to connect to the instance. The internet gateway has also been created. What can be the reason for the error?
1. The internet gateway is not configured with the route table
2. The private IP is not present
3. The outbound traffic on the security group is disabled
4. The internet gateway is not configured with the security group
A user has created a subnet in VPC and launched an EC2 instance within it. The user has not selected the option to assign the IP address while launching the instance. Which of the below mentioned statements is true with respect to the Instance requiring access to the Internet?
1. The instance will always have a public DNS attached to the instance by default
2. The user can directly attach an elastic IP to the instance
3. The instance will never launch if the public IP is not assigned
4. The user would need to create an internet gateway and then attach an elastic IP to the instance to connect from internet
A user has created a VPC with public and private subnets using the VPC wizard. Which of the below mentioned statements is not true in this scenario?
1. VPC will create a routing instance and attach it with a public subnet
2. VPC will create two subnets
3. VPC will create one internet gateway and attach it to VPC
4. VPC will launch one NAT instance with an elastic IP
A user has created a VPC with the public subnet. The user has created a security group for that VPC. Which of the below mentioned statements is true when a security group is created?
1. It can connect to the AWS services, such as S3 and RDS by default
2. It will have all the inbound traffic by default
3. It will have all the outbound traffic by default
4. It will by default allow traffic to the internet gateway
A user has created a VPC with CIDR 20.0.0.0/16 using VPC Wizard. The user has created a public CIDR (20.0.0.0/24) and a VPN only subnet CIDR (20.0.1.0/24) along with the hardware VPN access to connect to the user’s data centre. Which of the below mentioned components is not present when the VPC is setup with the wizard?
1. Main route table attached with a VPN only subnet
2. A NAT instance configured to allow the VPN subnet instances to connect with the internet
3. Custom route table attached with a public subnet
4. An internet gateway for a public subnet
A user has created a VPC with public and private subnets using the VPC wizard. The user has not launched any instance manually and is trying to delete the VPC. What will happen in this scenario?
1. It will not allow to delete the VPC as it has subnets with route tables
2. It will not allow to delete the VPC since it has a running route instance
3. It will terminate the VPC along with all the instances launched by the wizard
4. It will not allow to delete the VPC since it has a running NAT instance
A user has created a public subnet with VPC and launched an EC2 instance within it. The user is trying to delete the subnet. What will happen in this scenario?
1. It will delete the subnet and make the EC2 instance as a part of the default subnet
2. It will not allow the user to delete the subnet until the instances are terminated
3. It will delete the subnet as well as terminate the instances
4. Subnet can never be deleted independently, but the user has to delete the VPC first
A user has created a VPC with CIDR 20.0.0.0/24. The user has created a public subnet with CIDR 20.0.0.0/25 and a private subnet with CIDR 20.0.0.128/25. The user has launched one instance each in the private and public subnets. Which of the below mentioned options cannot be the correct IP address (private IP) assigned to an instance in the public or private subnet?
1. 20.0.0.255
2. 20.0.0.132
3. 20.0.0.122
4. 20.0.0.55
A user has created a VPC with CIDR 20.0.0.0/16. The user has created public and VPN only subnets along with hardware VPN access to connect to the user’s datacenter. The user wants to make so that all traffic coming to the public subnet follows the organization’s proxy policy. How can the user make this happen?
1. Setting up a NAT with the proxy protocol and configure that the public subnet receives traffic from NAT
2. Setting up a proxy policy in the internet gateway connected with the public subnet
3. It is not possible to setup the proxy policy for a public subnet
4. Setting the route table and security group of the public subnet which receives traffic from a virtual private gateway
A user has created a VPC with CIDR 20.0.0.0/16 using the wizard. The user has created a public subnet CIDR (20.0.0.0/24) and VPN only subnets CIDR (20.0.1.0/24) along with the VPN gateway (vgw-12345) to connect to the user’s data centre. Which of the below mentioned options is a valid entry for the main route table in this scenario?
1. Destination: 20.0.0.0/24 and Target: vgw-12345
2. Destination: 20.0.0.0/16 and Target: ALL
3. Destination: 20.0.1.0/16 and Target: vgw-12345
4. Destination: 0.0.0.0/0 and Target: vgw-12345
Which two components provide connectivity with external networks? When attached to an Amazon VPC which two components provide connectivity with external networks? Choose 2 answers
1. Elastic IPs (EIP) (Does not provide connectivity, public IP address will do as well)
2. NAT Gateway (NAT) (Not Attached to VPC and still needs IGW)
3. Internet Gateway (IGW)
4. Virtual Private Gateway (VGW)
You are attempting to connect to an instance in Amazon VPC without success You have already verified that the VPC has an Internet Gateway (IGW) the instance has an associated Elastic IP (EIP) and correct security group rules are in place. Which VPC component should you evaluate next?
1. The configuration of a NAT instance
2. The configuration of the Routing Table
3. The configuration of the internet Gateway (IGW)
4. The configuration of SRC/DST checking
If you want to launch Amazon Elastic Compute Cloud (EC2) Instances and assign each Instance a predetermined private IP address you should:
1. Assign a group or sequential Elastic IP address to the instances
2. Launch the instances in a Placement Group
3. Launch the instances in the Amazon virtual Private Cloud (VPC)
4. Use standard EC2 instances since each instance gets a private Domain Name Service (DNS) already
5. Launch the Instance from a private Amazon Machine image (AMI)
A user has recently started using EC2. The user launched one EC2 instance in the default subnet in EC2-VPC Which of the below mentioned options is not attached or available with the EC2 instance when it is launched?
1. Public IP address
2. Internet gateway
3. Elastic IP
4. Private IP address
A user has created a VPC with CIDR 20.0.0.0/24. The user has created a public subnet with CIDR 20.0.0.0/25. The user is trying to create the private subnet with CIDR 20.0.0.128/25. Which of the below mentioned statements is true in this scenario?
1. It will not allow the user to create the private subnet due to a CIDR overlap
2. It will allow the user to create a private subnet with CIDR as 20.0.0.128/25
3. This statement is wrong as AWS does not allow CIDR 20.0.0.0/25
4. It will not allow the user to create a private subnet due to a wrong CIDR range
A user has created a VPC with CIDR 20.0.0.0/16 with only a private subnet and VPN connection using the VPC wizard. The user wants to connect to the instance in a private subnet over SSH. How should the user define the security rule for SSH?
1. Allow Inbound traffic on port 22 from the user’s network
2. The user has to create an instance in EC2 Classic with an elastic IP and configure the security group of a private subnet to allow SSH from that elastic IP
3. The user can connect to a instance in a private subnet using the NAT instance
4. Allow Inbound traffic on port 80 and 22 to allow the user to connect to a private subnet over the Internet
A company wants to implement their website in a virtual private cloud (VPC). The web tier will use an Auto Scaling group across multiple Availability Zones (AZs). The database will use Multi-AZ RDS MySQL and should not be publicly accessible. What is the minimum number of subnets that need to be configured in the VPC?
1. 1
2. 2
3. 3
4. 4 (2 public subnets for web instances in multiple AZs and 2 private subnets for RDS Multi-AZ)
Which of the following are characteristics of Amazon VPC subnets? Choose 2 answers
1. Each subnet maps to a single Availability Zone
2. A CIDR block mask of /25 is the smallest range supported
3. Instances in a private subnet can communicate with the Internet only if they have an Elastic IP.
4. By default, all subnets can route between each other, whether they are private or public
5. Each subnet spans at least 2 Availability zones to provide a high-availability environment
You need to design a VPC for a web-application consisting of an Elastic Load Balancer (ELB). a fleet of web/application servers, and an RDS database The entire Infrastructure must be distributed over 2 availability zones. Which VPC configuration works while assuring the database is not available from the Internet?
1. One public subnet for ELB one public subnet for the web-servers, and one private subnet for the database
2. One public subnet for ELB two private subnets for the web-servers, two private subnets for RDS
3. Two public subnets for ELB two private subnets for the web-servers and two private subnets for RDS
4. Two public subnets for ELB two public subnets for the web-servers, and two public subnets for RDS
You have deployed a three-tier web application in a VPC with a CIDR block of 10.0.0.0/28. You initially deploy two web servers, two application servers, two database servers and one NAT instance tor a total of seven EC2 instances. The web, application and database servers are deployed across two availability zones (AZs). You also deploy an ELB in front of the two web servers, and use Route53 for DNS Web traffic gradually increases in the first few days following the deployment, so you attempt to double the number of instances in each tier of the application to handle the new load unfortunately some of these new instances fail to launch. Which of the following could the root caused? (Choose 2 answers) [PROFESSIONAL]
1. The Internet Gateway (IGW) of your VPC has scaled-up adding more instances to handle the traffic spike, reducing the number of available private IP addresses for new instance launches.
2. AWS reserves one IP address in each subnet’s CIDR block for Route53 so you do not have enough addresses left to launch all of the new EC2 instances.
3. AWS reserves the first and the last private IP address in each subnet’s CIDR block so you do not have enough addresses left to launch all of the new EC2 instances.
4. The ELB has scaled-up. Adding more instances to handle the traffic reducing the number of available private IP addresses for new instance launches
5. AWS reserves the first four and the last IP address in each subnet’s CIDR block so you do not have enough addresses left to launch all of the new EC2 instances.
A user wants to access RDS from an EC2 instance using IP addresses. Both RDS and EC2 are in the same region, but different AZs. Which of the below mentioned options help configure that the instance is accessed faster?
1. Configure the Private IP of the Instance in RDS security group (Recommended as the data is transferred within the the Amazon network and not through internet – Refer link)
2. Security group of EC2 allowed in the RDS security group
3. Configuring the elastic IP of the instance in RDS security group
4. Configure the Public IP of the instance in RDS security group
In regards to VPC, select the correct statement:
1. You can associate multiple subnets with the same Route Table.
2. You can associate multiple subnets with the same Route Table, but you can’t associate a subnet with only one Route Table.
3. You can’t associate multiple subnets with the same Route Table.
4. None of these.
You need to design a VPC for a web-application consisting of an ELB a fleet of web application servers, and an RDS DB. The entire infrastructure must be distributed over 2 AZ. Which VPC configuration works while assuring the DB is not available from the Internet?
1. One Public Subnet for ELB, one Public Subnet for the web-servers, and one private subnet for the DB
2. One Public Subnet for ELB, two Private Subnets for the web-servers, and two private subnets for the RDS
3. Two Public Subnets for ELB, two private Subnet for the web-servers, and two private subnet for the RDS
4. Two Public Subnets for ELB, two Public Subnet for the web-servers, and two public subnets for the RDS
You have an Amazon VPC with one private subnet and one public subnet with a Network Address Translator (NAT) server. You are creating a group of Amazon Elastic Cloud Compute (EC2) instances that configure themselves at startup via downloading a bootstrapping script from Amazon Simple Storage Service (S3) that deploys an application via GIT. Which setup provides the highest level of security?
1. Amazon EC2 instances in private subnet, no EIPs, route outgoing traffic via the NAT
2. Amazon EC2 instances in public subnet, no EIPs, route outgoing traffic via the Internet Gateway (IGW)
3. Amazon EC2 instances in private subnet, assign EIPs, route outgoing traffic via the Internet Gateway (IGW)
4. Amazon EC2 instances in public subnet, assign EIPs, route outgoing traffic via the NAT
You have launched an Amazon Elastic Compute Cloud (EC2) instance into a public subnet with a primary private IP address assigned, an internet gateway is attached to the VPC, and the public route table is configured to send all Internet-based traffic to the Internet gateway. The instance security group is set to allow all outbound traffic but cannot access the Internet. Why is the Internet unreachable from this instance?
1. The instance does not have a public IP address
2. The Internet gateway security group must allow all outbound traffic.
3. The instance security group must allow all inbound traffic.
4. The instance “Source/Destination check” property must be enabled.
You have an environment that consists of a public subnet using Amazon VPC and 3 instances that are running in this subnet. These three instances can successfully communicate with other hosts on the Internet. You launch a fourth instance in the same subnet, using the same AMI and security group configuration you used for the others, but find that this instance cannot be accessed from the internet. What should you do to enable Internet access?
1. Deploy a NAT instance into the public subnet.
2. Assign an Elastic IP address to the fourth instance
3. Configure a publically routable IP Address in the host OS of the fourth instance.
4. Modify the routing table for the public subnet.
You have a load balancer configured for VPC, and all back-end Amazon EC2 instances are in service. However, your web browser times out when connecting to the load balancer’s DNS name. Which options are probable causes of this behavior? Choose 2 answers
1. The load balancer was not configured to use a public subnet with an Internet gateway configured
2. The Amazon EC2 instances do not have a dynamically allocated private IP address
3. The security groups or network ACLs are not property configured for web traffic.
4. The load balancer is not configured in a private subnet with a NAT instance.
5. The VPC does not have a VGW configured.
When will you incur costs with an Elastic IP address (EIP)?
1. When an EIP is allocated.
2. When it is allocated and associated with a running instance.
3. When it is allocated and associated with a stopped instance.
4. Costs are incurred regardless of whether the EIP is associated with a running instance.
A company currently has a VPC with EC2 Instances. A new instance being launched, which will host an application that works on IPv6. You need to ensure that this instance can initiate outgoing traffic to the Internet. At the same time, you need to ensure that no incoming connection can be initiated from the Internet on to the instance. Which of the following would you add to the VPC for this requirement?
1. A NAT Instance
2. A NAT Gateway
3. An Internet Gateway
4. An egress-only Internet gateway
A company is deploying a multi-account AWS environment and needs centralized IP address management across all accounts and regions. Which AWS service should they use?
1. AWS Config
2. AWS Systems Manager
3. Amazon VPC IP Address Manager (IPAM)
4. AWS Resource Access Manager
An organization wants to enable service-to-service communication across multiple VPCs and AWS accounts without managing complex networking configurations or Transit Gateways. Which service provides this capability?
1. AWS PrivateLink
2. VPC Peering
3. Amazon VPC Lattice
4. AWS Direct Connect
A security team needs to implement deep packet inspection and intrusion prevention for all traffic entering and leaving their VPC. Which AWS service should they deploy?
1. AWS WAF
2. AWS Shield
3. AWS Network Firewall
4. Security Groups
Your company is currently using AWS App Mesh for service mesh capabilities. What is the recommended migration path given AWS’s service roadmap?
1. Migrate to AWS Cloud Map
2. Migrate to Amazon VPC Lattice (App Mesh EOL September 30, 2026)
3. Continue using App Mesh indefinitely
4. Migrate to Elastic Load Balancing
Which of the following features are provided by Amazon VPC Lattice? Choose 3 answers
1. Built-in service discovery
2. VPN connectivity
3. Cross-account service connectivity
4. Direct Connect integration
5. Application-layer authentication
A network administrator needs to prevent IP address conflicts across 50 AWS accounts in their organization. They want automated CIDR allocation for new VPCs. Which service feature addresses this requirement?
1. VPC Flow Logs
2. AWS VPC IPAM with automated allocation
3. AWS Config Rules
4. VPC CIDR block associations
AWS Network Firewall supports which of the following capabilities? Choose 3 answers
1. Deep packet inspection (DPI)
2. DDoS protection at Layer 3/4 (use AWS Shield)
3. Intrusion detection and prevention (IDS/IPS)
4. Web application firewall rules (use AWS WAF)
5. Domain name and URL filtering
Your organization needs to integrate AWS IP address management with existing Infoblox infrastructure. Which IPAM tier is required?
1. IPAM Basic Tier
2. IPAM Advanced Tier
3. IPAM Standard Tier
4. IPAM Enterprise Tier
A company wants to route HTTP traffic between microservices based on request headers and paths across multiple VPCs. Which service provides this capability?
1. Application Load Balancer
2. AWS Transit Gateway
3. Amazon VPC Lattice (Layer 7 routing)
4. VPC Peering
Which AWS service provides a 99.99% SLA for managed network security with automatic scaling?
1. Security Groups
2. Network ACLs
3. AWS Network Firewall
4. AWS WAF
A company needs to implement dynamic routing between their network virtual appliances and VPC route tables using BGP, with automatic failover when an appliance becomes unavailable. Which service should they use?
1. AWS Transit Gateway
2. Amazon VPC Route Server
3. AWS Direct Connect
4. VPC Peering
An organization wants to ensure no resources in specific VPCs can access or be accessed from the Internet, regardless of security group or route table configurations. Which feature provides this declarative control?
1. Network ACLs with deny rules
2. Security Group restrictions
3. VPC Block Public Access (BPA)
4. AWS WAF IP restrictions
A security team needs to centrally monitor and enforce that all network traffic within their VPCs is encrypted in transit, with audit logs for compliance. Which feature should they enable?
1. AWS CloudTrail
2. VPC Flow Logs
3. VPC Encryption Controls
4. AWS Config Rules
Which of the following statements about VPC Encryption Controls are correct? Choose 2 answers
1. It uses Nitro System hardware encryption and application-layer encryption (TLS/SSL)
2. It encrypts data at rest in EBS volumes
3. It provides monitor mode to audit encryption status and enforce mode to prevent unencrypted traffic
4. It requires VPN connections for all traffic
A company needs to tag individual IP address allocations within their IPAM pools to control access via IAM policies. Which IPAM feature supports this?
1. IPAM hierarchical pools
2. IPAM compliance monitoring
3. IPAM pool allocation tags (May 2026)
4. IPAM Advanced Tier

References

AWS_VPC_User_Guide

AWS VPC IPAM Documentation

Amazon VPC Lattice User Guide

AWS Network Firewall Developer Guide

Amazon VPC Route Server Documentation

VPC Block Public Access Documentation

VPC Encryption Controls Documentation

AWS Regions & Availability Zones – Global Infrastructure Explained

March 20, 2016 ~ Last updated on : July 14, 2026 ~ jayendrapatil ~ 8 Comments

AWS Global Infrastructure

AWS Global Infrastructure enables Amazon Services to be hosted in multiple locations worldwide.
AWS Global Infrastructure provides the ability to place resources and data in multiple locations to improve performance, provide fault tolerance, high availability, and cost optimization.
AWS Global Infrastructure includes Regions, Availability Zones, Edge Locations, Regional Edge Caches, Local Zones, Wavelength Zones, and Dedicated Local Zones.
As of 2026, the AWS Cloud spans 39 Geographic Regions with 123 Availability Zones, 750+ Points of Presence (Edge Locations), 13 Regional Edge Caches, 30+ Local Zones, and 30+ Wavelength Zones.
AWS has announced plans for 7 more Availability Zones and 2 more AWS Regions in the Kingdom of Saudi Arabia and Chile.

Regions

AWS allows customers to place instances and store data within multiple geographic regions called Region.
Each region
- is an independent collection of AWS resources in a defined geography.
- is a separate geographic area and is completely independent
- is a physical location around the world with cluster data centers
- is designed to be completely isolated from the other regions & helps achieve the greatest possible fault tolerance and stability
- consists of at least three physically separate Availability Zones (AZs), with independent power infrastructure, cooling systems, network connectivity, and security systems
Inter-region communication is across the public Internet and appropriate measures should be taken to protect the data using encryption.
Data transfer between regions is charged at the Internet data transfer rate for both the sending and the receiving instances.
Resources aren’t replicated across regions unless done explicitly.
The selection of a Region can be driven by a lot of factors
- Latency – Regions can be selected to be close to the targeted user base to reduce data latency
- Cost – AWS provides the same set of services across all regions, usually, however, the cost would differ from region to region depending upon the cost (due to land, electricity, bandwidth, etc) incurred by Amazon and hence can be cheaper in one region compared to the other
- Legal Compliance – A lot of the countries enforce compliance and regulatory requirements for data to reside within the region itself
- Features – As not all the regions provide all the AWS features and services, the region selection can depend on the Services supported by the region

Recently Launched Regions (2024-2025)

Asia Pacific (Malaysia) – ap-southeast-5 (August 2024)
Canada West (Calgary) – ca-west-1 (2024)
Asia Pacific (Thailand) – ap-southeast-7 (January 2025)
Mexico (Central) – mx-central-1 (January 2025)
Asia Pacific (Taipei) – ap-east-2 (June 2025)
Asia Pacific (New Zealand) – ap-southeast-6 (September 2025)

Availability Zones

Each Region consists of multiple, isolated locations known as Availability Zones and each Availability Zone runs on its own physically distinct, independent infrastructure and is engineered to be highly reliable.
Each Region has at least three isolated Availability Zones (ranging from 3-6).
Each AZ has independent power, cooling, and physical security and is connected via redundant, ultra-low-latency networks.
Each AZ is physically isolated from the others so that an uncommon disaster such as fire, or earthquake would only affect a single AZ.
AZs are geographically separated from each other, within the same region, and act as an independent failure zone.
AZs are redundantly connected to multiple tier-1 transit providers.
All AZs in an AWS Region are interconnected with high-bandwidth, low-latency networking, over fully redundant, dedicated metro fiber providing high-throughput, low-latency networking between AZs.
All traffic between AZs is encrypted.
Multi-AZ feature, distribution of resources across multiple AZs, can be used to distribute instances across multiple AZ to provide High Availability
AWS ensures that resources are distributed across the AZs for a region by independently mapping AZs to identifiers for each account. for e.g. us-east-1 region with us-east-1a AZ might not be the same location as us-east-1a AZ for another account.
To coordinate AZs across accounts, use AZ IDs (e.g., use1-az1), which are unique and consistent identifiers for an Availability Zone across all AWS accounts. AZ IDs can be viewed in the AWS Resource Access Manager (RAM) console.

Edge Locations

Edge locations are locations maintained by AWS through a worldwide network of data centers for the distribution of content.
AWS operates 750+ Points of Presence (Edge Locations) and 13 Regional Edge Caches in 100+ cities across 50+ countries.
Edge locations are connected to the AWS Regions through the AWS network backbone – fully redundant, multiple 100GbE parallel fiber that circles the globe and links with tens of thousands of networks for improved origin fetches and dynamic content acceleration.
These locations are located in most of the major cities around the world and are used by CloudFront (CDN) to distribute content to end-user to reduce latency.
Edge Locations are also used by services such as Route 53, AWS Shield, AWS WAF, and AWS Global Accelerator.

CloudFront Embedded Points of Presence (Embedded POPs)

Embedded POPs are a new type of CloudFront infrastructure (launched February 2024) deployed directly in the last mile of ISP and mobile network operator (MNO) networks.
CloudFront has 600+ embedded POPs deployed across 200+ cities globally.
Embedded POPs are custom-built to deliver large-scale live-stream video, video-on-demand (VOD), and game downloads.
Embedded POPs provide highly scaled capacity for peak traffic events and enable higher quality streaming closer to end viewers.

AWS Local Zones

AWS Local Zones are infrastructure deployments that extend core AWS services—compute, storage, networking, analytics, AI/ML, and database—to more metros worldwide.
With 30+ locations across six continents, AWS Local Zones deliver the performance, security, and reliability of AWS closer to end users and workloads.
Local Zones allow running highly demanding applications that require single-digit millisecond latencies to the end-users such as media & entertainment content creation, real-time gaming, reservoir simulations, electronic design automation, and machine learning.
Each AWS Local Zone location is an extension of an AWS Region where latency-sensitive applications can be hosted using AWS services such as EC2, VPC, EBS, File Storage, and ELB in geographic proximity to end-users.
AWS Local Zones provide a high-bandwidth, secure connection between local workloads and those running in the AWS Region.
AWS Local Zones help seamlessly connect to the full range of services in the AWS Region such as S3 and DynamoDB through the same APIs and toolsets over AWS’s private and high bandwidth network backbone.
Additional services available in select Local Zones include Amazon FSx, Amazon EMR, Amazon ElastiCache, NAT Gateways, AWS Batch, Amazon SageMaker, Amazon Bedrock, Amazon S3, and Amazon RDS.
Local Zones must be explicitly enabled (opted-in) before you can use them.

AWS Local Zones

AWS Dedicated Local Zones

AWS Dedicated Local Zones (launched 2023) are a type of AWS infrastructure that is fully managed by AWS, built for exclusive use by a customer or community, and placed in a customer-specified location or data center.
Dedicated Local Zones are designed to help customers comply with regulatory and digital sovereignty requirements while leveraging the benefits of AWS cloud services.
Dedicated Local Zones offer the same benefits of AWS Local Zones, such as elasticity, scalability, and pay-as-you-go pricing, with added security and governance features.
They can be operated by local AWS personnel and support compute, storage, database, containers, and other services for local processing.
Key use cases include public sector, regulated industries (telecom, finance, healthcare), and organizations with strict data residency requirements.
Dedicated Local Zones support EBS Local Snapshots for data residency within the zone.

AWS Wavelength

AWS Wavelength embeds AWS compute and storage services within 5G networks, providing mobile edge computing infrastructure for developing, deploying, and scaling ultra-low-latency applications.
AWS Wavelength helps seamlessly access the breadth of AWS services in the region.
AWS Wavelength brings AWS services to the edge of the 5G network, minimizing the latency to connect to an application from a mobile device.
Application traffic can reach application servers running in Wavelength Zones without leaving the mobile provider’s network, reducing the extra network hops to the Internet that can result in latencies of more than 100 milliseconds.
AWS developers can deploy applications to Wavelength Zones, enabling single-digit millisecond latencies to mobile devices and end-users.
AWS Wavelength helps deliver applications that require single-digit millisecond latencies such as game and live video streaming, machine learning inference at the edge, and augmented and virtual reality (AR/VR).
AWS Wavelength also supports data residency, low-latency, and resiliency requirements with sovereign-by-design architecture built on the AWS Nitro System.
AWS Wavelength Zones are available with telecom partners globally, with 30+ Wavelength Zones across multiple countries including the US, Europe, Asia, and Africa.
Wavelength Zones are not available in every Region.
Wavelength Zones support EC2 instance families including T3, R5, M5, C5, and G4.

AWS Wavelength Zones

AWS Outposts

AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to customer premises.
Outposts bring native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.
Outposts provide the same AWS APIs, tools, and infrastructure across on-premises and AWS cloud to deliver a truly consistent hybrid experience.
AWS operates, monitors, and manages this capacity as part of an AWS Region.
Outposts are designed for connected environments and can be used to support workloads that need to remain on-premises due to low latency or local data processing needs.

Second-Generation AWS Outposts Racks (2025)

AWS launched second-generation Outposts racks in April 2025 with significant improvements over first-generation.
Second-generation racks support the latest x86-powered EC2 instances (C7i, M7i, R7i) providing up to 40% better performance compared to C5, M5, R5 instances on first-generation racks.
C8i, M8i, and R8i instances are also available, delivering 20% better performance and 2.5x more memory bandwidth.
New features include simplified network scaling and configuration, and accelerated networking instances for ultra-low latency workloads.
Support for multiple local gateway (LGW) routing domains enables network segmentation using both customer-owned IP (CoIP) and direct VPC routing (DVR) modes on the same Outpost.
Satellite Resiliency for AWS Outposts (announced re:Invent 2024) provides a Partner-managed solution for resilient cloud-connected edge computing in remote and geographically dispersed environments.

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.

George has launched three EC2 instances inside the US-East-1a zone with his AWS account. Ray has launched two EC2 instances in the US-East-1a zone with his AWS account. Which of the below mentioned statements will help George and Ray understand the availability zone (AZ) concept better?
1. The instances of George and Ray will be running in the same data centre.
2. All the instances of George and Ray can communicate over a private IP with a minimal cost
3. All the instances of George and Ray can communicate over a private IP without any cost
4. us-east-1a region of George and Ray can be different availability zones (Refer link. An Availability Zone is represented by a region code followed by a letter identifier; for example, us-east-1a. To ensure that resources are distributed across the Availability Zones for a region, we independently map Availability Zones to identifiers for each account. For example, your Availability Zone us-east-1a might not be the same location as us-east-1a for another account. To coordinate AZs between accounts, use AZ IDs (e.g., use1-az1) which are consistent across accounts.)
A company needs to deploy an application with ultra-low latency to mobile users on a 5G network. Which AWS infrastructure option should they use?
1. AWS Local Zones
2. AWS Wavelength
3. AWS Outposts
4. AWS Edge Locations
An organization must ensure that their cloud infrastructure is exclusively dedicated to them and located in their own data center to meet strict regulatory requirements. Which AWS solution addresses this need?
1. AWS Local Zones
2. AWS Wavelength
3. AWS Dedicated Local Zones
4. AWS Outposts
Which of the following is the correct minimum number of Availability Zones per AWS Region?
1. 1
2. 2
3. 3
4. 4
A company wants to serve cached content from infrastructure deployed directly within ISP networks to reduce latency for video streaming. Which CloudFront feature supports this?
1. Regional Edge Caches
2. Lambda@Edge
3. CloudFront Embedded Points of Presence (Embedded POPs)
4. CloudFront Functions
To identify and coordinate the same physical Availability Zone location across multiple AWS accounts, which identifier should be used?
1. AZ Name (e.g., us-east-1a)
2. AZ ID (e.g., use1-az1)
3. Region Code (e.g., us-east-1)
4. Account ID

Reference

AWS Auto Scaling – EC2, ECS & DynamoDB Scaling

March 19, 2016 ~ Last updated on : June 26, 2026 ~ jayendrapatil ~ 59 Comments

Auto Scaling Overview

Auto Scaling provides the ability to ensure a correct number of EC2 instances are always running to handle the load of the application
Auto Scaling helps
- to achieve better fault tolerance, better availability and cost management.
- helps specify scaling policies that can be used to launch and terminate EC2 instances to handle any increase or decrease in demand.
Auto Scaling attempts to distribute instances evenly between the AZs that are enabled for the Auto Scaling group.
Auto Scaling does this by attempting to launch new instances in the AZ with the fewest instances. If the attempt fails, it attempts to launch the instances in another AZ until it succeeds.

Auto Scaling Components

AWS Auto Scaling

Auto Scaling Groups – ASG

Auto Scaling groups are the core of Auto Scaling and contain a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of automatic scaling and management.
ASG requires
- Launch Template (recommended) OR Launch Configuration (deprecated)
  - determine the EC2 template to use for launching the instance
- Minimum & Maximum capacity
  - determine the number of instances when an autoscaling policy is applied.
  - Number of instances cannot grow beyond these boundaries
- Desired capacity
  - to determine the number of instances the ASG must maintain at all times. If missing, it equals the minimum size.
  - Desired capacity is different from minimum capacity.
  - An Auto Scaling group’s desired capacity is the default number of instances that should be running. A group’s minimum capacity is the fewest number of instances the group can have running
- Availability Zones or Subnets in which the instances will be launched.
- Metrics & Health Checks
  - metrics to determine when it should launch or terminate instances and health checks to determine if the instance is healthy or not
ASG starts by launching a desired capacity of instances and maintains this number by performing periodic health checks.
If an instance becomes unhealthy, the ASG terminates and launches a new instance.
ASG can also use scaling policies to increase or decrease the number of instances automatically to meet changing demands
An ASG can contain EC2 instances in one or more AZs within the same region.
ASGs cannot span multiple regions.
ASG can launch On-Demand Instances, Spot Instances, or both when configured to use a launch template.
To merge separate single-zone ASGs into a single ASG spanning multiple AZs, rezone one of the single-zone groups into a multi-zone group, and then delete the other groups. This process works for groups with or without a load balancer, as long as the new multi-zone group is in one of the same AZs as the original single-zone groups.
ASG can be associated with a single launch configuration or template
As the Launch Configuration can’t be modified once created, the only way to update the Launch Configuration for an ASG is to create a new one and associate it with the ASG.
When the launch configuration for the ASG is changed, any new instances launched, use the new configuration parameters, but the existing instances are not affected.
ASG can be deleted from CLI, if it has no running instances else need to set the minimum and desired capacity to 0. This is handled automatically when deleting an ASG from the AWS management console.
Deletion Protection (Jan 2026) – ASGs now support deletion protection with multiple protection levels to prevent accidental deletions. A new IAM policy condition key autoscaling:ForceDelete controls the use of the ForceDelete parameter.

Launch Configuration

⚠️ LAUNCH CONFIGURATION – DEPRECATED

Launch Configurations are being phased out in favor of Launch Templates.

As of January 1, 2023 – No new EC2 instance types are supported in launch configurations.
As of June 1, 2023 – New accounts cannot create launch configurations via the console.
As of October 1, 2024 – New accounts cannot create launch configurations using any method (console, API, CLI, or CloudFormation).
Existing accounts can still use existing launch configurations but should migrate to Launch Templates.

Migration: Use Migrate to Launch Templates guide to transition.

Launch configuration is an instance configuration template that an ASG uses to launch EC2 instances.
Launch configuration is similar to EC2 configuration and involves the selection of the Amazon Machine Image (AMI), block devices, key pair, instance type, security groups, user data, EC2 instance monitoring, instance profile, kernel, ramdisk, the instance tenancy, whether the instance has a public IP address, and is EBS-optimized.
Launch configuration can be associated with multiple ASGs
Launch configuration can’t be modified after creation and needs to be created new if any modification is required.
Basic or detailed monitoring for the instances in the ASG can be enabled when a launch configuration is created.
By default, basic monitoring is enabled when you create the launch configuration using the AWS Management Console, and detailed monitoring is enabled when you create the launch configuration using the AWS CLI or an API
AWS recommends using Launch Template instead. Launch Configurations are deprecated for new accounts.

Launch Template

A Launch Template is similar to a launch configuration, with additional features, and is the recommended and only supported option for new AWS accounts (since Oct 2024).
Launch Template allows multiple versions of a template to be defined.
With versioning, a subset of the full set of parameters can be created and then reused to create other templates or template versions for e.g, a default template that defines common configuration parameters can be created and allow the other parameters to be specified as part of another version of the same template.
Launch Template allows the selection of both Spot and On-Demand Instances or multiple instance types.
Launch templates support EC2 Dedicated Hosts. Dedicated Hosts are physical servers with EC2 instance capacity that are dedicated to your use.
Launch templates provide the following features
- Support for multiple instance types and purchase options in a single ASG.
- Launching Spot Instances with the capacity-optimized allocation strategy.
- Support for launching instances into existing Capacity Reservations through an ASG.
- Support for unlimited mode for burstable performance instances.
- Support for Dedicated Hosts.
- Combining CPU architectures such as Intel, AMD, and ARM (Graviton2/Graviton3/Graviton4)
- Improved governance through IAM controls and versioning.
- Automating instance deployment with Instance Refresh.
- Support for all new EC2 instance types (required since Jan 2023 as launch configs no longer support new types).

Auto Scaling Launch Configuration vs Launch Template

Auto Scaling Launch Template vs Launch Configuration

Auto Scaling Policies

Refer blog post @ Auto Scaling Policies

Predictive Scaling

Predictive Scaling uses machine learning to predict future traffic patterns and proactively scales capacity in advance of predicted changes.
It analyzes historical load data to detect daily and weekly patterns and automatically adjusts forecasts.
Predictive Scaling provisions EC2 instances ahead of anticipated demand, improving availability and reducing the need for over-provisioning.
It works alongside dynamic scaling policies – predictive scaling handles anticipated load changes while dynamic scaling handles unexpected spikes.
Predictive Scaling supports:
- Forecast-only mode for evaluation before activating scaling
- Forecast and scale mode for automatic capacity adjustment
- Custom metrics in addition to predefined CPU, network, and ALB request metrics
Best suited for workloads with recurring, predictable traffic patterns (e.g., business-hour traffic, weekly patterns).

Auto Scaling Cooldown Period

Auto Scaling Cooldown period is a configurable setting for the ASG that helps to ensure that Auto Scaling doesn’t launch or terminate additional instances before the previous scaling activity takes effect and allows the newly launched instances to start handling traffic and reduce load
When ASG dynamically scales using a simple scaling policy and launches an instance, Auto Scaling suspends the scaling activities for the cooldown period (default 300 seconds) to complete before resuming scaling activities
Example Use Case
- You configure a scale out alarm to increase the capacity, if the CPU utilization increases more than 80%
- A CPU spike occurs and causes the alarm to be triggered, Auto Scaling launches a new instance
- However, it would take time for the newly launched instance to be configured, instantiated, and started, let’s say 5 mins
- Without a cooldown period, if another CPU spike occurs Auto Scaling would launch a new instance again and this would continue for 5 mins till the previously launched instance is up and running and started handling traffic
- With a cooldown period, Auto Scaling would suspend the activity for the specified time period enabling the newly launched instance to start handling traffic and reduce the load.
- After the cooldown period, Auto Scaling resumes acting on the alarms
When manually scaling the ASG, the default is not to wait for the cooldown period but can be overridden to honour the cooldown period.
Note that if an instance becomes unhealthy, Auto Scaling does not wait for the cooldown period to complete before replacing the unhealthy instance.
Cooldown periods are automatically applied to dynamic scaling activities for simple scaling policies and are not supported for step scaling or target tracking policies.
Default Instance Warmup – a recommended alternative to cooldown periods. It specifies how long after an instance reaches InService state before it contributes to aggregated CloudWatch metrics. This prevents premature scaling decisions based on incomplete data from newly launched instances.

Auto Scaling Termination Policy

Termination policy helps Auto Scaling decide which instances it should terminate first when Auto Scaling automatically scales in.
Auto Scaling specifies a default termination policy and also provides the ability to create a customized one.

Default Termination Policy

Default termination policy helps ensure that the network architecture spans AZs evenly and instances are selected for termination as follows:-

Selection of Availability Zone
- selects the AZ, in multiple AZs environments, with the most instances and at least one instance that is not protected from scale in.
- selects the AZ with instances that use the oldest launch template or configuration, if there is more than one AZ with the same number of instances
Selection of an Instance within the Availability Zone
- terminates the unprotected instance using the oldest launch template or configuration if one exists.
- terminates unprotected instances closest to the next billing hour, If multiple instances with the oldest launch configuration. This helps in maximizing the use of the EC2 instances that have an hourly charge while minimizing the number of hours billed for EC2 usage.
- terminates instances at random, if more than one unprotected instance is closest to the next billing hour.

Customized Termination Policy

Auto Scaling first assesses the AZs for any imbalance. If an AZ has more instances than the other AZs that are used by the group, then it applies the specified termination policy on the instances from the imbalanced AZ
If the Availability Zones used by the group are balanced, then Auto Scaling applies the specified termination policy.
Following Customized Termination policies are supported:
1. OldestInstance – terminates the oldest instance in the group and can be useful to upgrade to new instance types
2. NewestInstance – terminates the newest instance in the group and can be useful when testing a new launch configuration
3. OldestLaunchConfiguration – terminates instances that have the oldest launch configuration
4. OldestLaunchTemplate – terminates instances that have the oldest launch template
5. ClosestToNextInstanceHour – terminates instances that are closest to the next billing hour and helps to maximize the use of your instances and manage costs.
6. AllocationStrategy – terminates instances to align remaining instances to the allocation strategy for the instance type (Spot or On-Demand).
7. Default – terminates as per the default termination policy

Custom Termination Policy with Lambda

Auto Scaling supports using an AWS Lambda function as a custom termination policy for advanced termination logic.
The Lambda function receives a JSON payload with candidate instances and returns which instances should be terminated.
This provides fine-grained control over termination decisions, e.g., avoiding instances running critical workloads.
Requires granting EC2 Auto Scaling permission via a Lambda resource-based policy.

Instance Refresh

Instance refresh can be used to update the instances in the ASG instead of manually replacing instances a few at a time.
An instance refresh can be helpful when you have a new AMI or a new user data script.
Instance refresh also helps configure the minimum healthy percentage, instance warmup, and checkpoints.
Instance refresh supports two strategies:
- Rolling strategy (default) – Terminates instances and launches new ones in batches while maintaining desired capacity and availability.
- Replace Root Volume strategy (Nov 2025) – Updates instances by replacing only the root EBS volume without terminating the instance. Preserves network interfaces, non-root EBS volumes, and instance store data.
To use an instance refresh:
- Create a new launch template that specifies the new AMI or user data script.
- Start an instance refresh to begin updating the instances in the group immediately.
- EC2 Auto Scaling starts performing a rolling replacement of the instances.
Skip Matching – When enabled, Auto Scaling compares each instance’s current configuration against the desired configuration and only replaces instances that don’t match, skipping already-updated instances.

Warm Pools

A warm pool is a pool of pre-initialized EC2 instances that sits alongside the Auto Scaling group for faster scale-out.
When the application needs to scale out, the ASG draws from the warm pool instead of launching cold instances, significantly reducing startup latency.
Instances in a warm pool can be in one of three states: Stopped, Running, or Hibernated.
Warm pools are ideal for applications with long boot times (e.g., instances that need to load large datasets or perform complex initialization).
Warm pool supports lifecycle hooks to perform custom actions when instances transition between states.
Supports ASGs with mixed instances policies (Nov 2025) – warm pools can now be used with groups that have multiple instance types and purchase options.
Creating a warm pool when not required can lead to unnecessary costs for the stopped/running instances.

Instance Maintenance Policy

Instance Maintenance Policy (Nov 2023) defines whether new instances are launched before or after existing instances are terminated during replacement operations.
Controls replacement behavior for instance refresh, health checks, and AZ rebalancing.
Three preset options:
- Launch before terminating – Provisions new instance first, then terminates old one. Favors availability over cost.
- Terminate and launch – Terminates and launches simultaneously. Favors cost savings over availability.
- Custom policy – Set custom min/max range for available capacity during replacement.
Can be set at the ASG level and overridden for individual instance refresh operations.

Instance Protection

Instance protection controls whether Auto Scaling can terminate a particular instance or not.
Instance protection can be enabled on an ASG or an individual instance as well, at any time
Instances launched within an ASG with Instance protection enabled would inherit the property.
Instance protection starts as soon as the instance is InService and if the Instance is detached, it loses its Instance protection
If all instances in an ASG are protected from termination during scale in and a scale-in event occurs, it can’t terminate any instance and will decrement the desired capacity.
Instance protection does not protect for the below cases
- Manual termination through the EC2 console, the terminate-instances command, or the TerminateInstances API.
- If it fails health checks and must be replaced
- Spot instances in an ASG from interruption

Standby State

Auto Scaling allows putting the InService instances in the Standby state during which the instance is still a part of the ASG but does not serve any requests. This can be used to either troubleshoot an instance or update an instance and return the instance back to service.

An instance can be put into Standby state and it will continue to remain in the Standby state unless exited.
Auto Scaling, by default, decrements the desired capacity for the group and prevents it from launching a new instance. If no decrement is selected, it would launch a new instance
When the instance is in the standby state, the instance can be updated or used for troubleshooting.
If a load balancer is associated with Auto Scaling, the instance is automatically deregistered when the instance is in Standby state and registered again when the instance exits the Standby state

Suspension

Auto Scaling processes can be suspended and then resumed. This can be very useful to investigate a configuration problem or debug an issue with the application, without triggering the Auto Scaling process.
Auto Scaling also performs Administrative Suspension where it would suspend processes for ASGs if the ASG has been trying to launch instances for over 24 hours but has not succeeded in launching any instances.
Auto Scaling processes include
- Launch – Adds a new EC2 instance to the group, increasing its capacity.
- Terminate – Removes an EC2 instance from the group, decreasing its capacity.
- HealthCheck – Checks the health of the instances.
- ReplaceUnhealthy – Terminates instances that are marked as unhealthy and subsequently creates new instances to replace them.
- AlarmNotification – Accepts notifications from CloudWatch alarms that are associated with the group. If suspended, Auto Scaling does not automatically execute policies that would be triggered by an alarm
- ScheduledActions – Performs scheduled actions that you create.
- AddToLoadBalancer – Adds instances to the load balancer when they are launched.
- InstanceRefresh – Terminates and replaces instances using the instance refresh feature.
- AZRebalance – Balances the number of EC2 instances in the group across the Availability Zones in the region.
  - If an AZ either is removed from the ASG or becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected AZ before terminating the unhealthy or unavailable instances
  - When the unhealthy AZ returns to a healthy state, Auto Scaling automatically redistributes the instances evenly across the Availability Zones for the group.
  - Note that if you suspend AZRebalance and a scale out or scale in event occurs, Auto Scaling still tries to balance the Availability Zones for e.g. during scale out, it launches the instance in the Availability Zone with the fewest instances.
  - If you suspend Launch, AZRebalance neither launches new instances nor terminates existing instances. This is because AZRebalance terminates instances only after launching the replacement instances.
  - If you suspend Terminate, the ASG can grow up to 10% larger than its maximum size, because Auto Scaling allows this temporarily during rebalancing activities. If it cannot terminate instances, your ASG could remain above its maximum size until the Terminate process is resumed

Zonal Shift Integration

Zonal Shift (Nov 2024) integrates with Amazon Application Recovery Controller (ARC) to rapidly recover from AZ impairments.
When a zonal shift is activated, Auto Scaling stops dynamic scale-in to preserve capacity and launches new instances in healthy AZs only.
Zonal Autoshift can automatically shift traffic away from an impaired AZ on a periodic basis to test resilience.
Health checks can be configured to either remain enabled or be disabled in the impaired AZ during a zonal shift.
Can be initiated from the EC2 Auto Scaling console, ARC console, or programmatically via AWS SDK.

Strict Availability Zone Balance

Strict AZ Balance (Nov 2024) provides a new provisioning control to strictly balance workloads across Availability Zones.
Unlike the default best-effort balancing, strict mode ensures exact equal distribution across configured AZs.
Provides greater control over instance placement for compliance or performance requirements.

Auto Scaling Lifecycle

Refer to blog post @ Auto Scaling Lifecycle

Autoscaling & ELB

Refer to blog post @ Autoscaling & ELB

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 user is trying to setup a scheduled scaling activity using Auto Scaling. The user wants to setup the recurring schedule. Which of the below mentioned parameters is not required in this case?
1. Maximum size
2. Auto Scaling group name
3. End time
4. Recurrence value
A user has configured Auto Scaling with 3 instances. The user had created a new AMI after updating one of the instances. If the user wants to terminate two specific instances to ensure that Auto Scaling launches an instances with the new launch configuration, which command should he run?
1. as-delete-instance-in-auto-scaling-group <Instance ID> –no-decrement-desired-capacity
2. as-terminate-instance-in-auto-scaling-group <Instance ID> –update-desired-capacity
3. as-terminate-instance-in-auto-scaling-group <Instance ID> –decrement-desired-capacity
4. as-terminate-instance-in-auto-scaling-group <Instance ID> –no-decrement-desired-capacity
A user is planning to scale up an application by 8 AM and scale down by 7 PM daily using Auto Scaling. What should the user do in this case?
1. Setup the scaling policy to scale up and down based on the CloudWatch alarms
2. User should increase the desired capacity at 8 AM and decrease it by 7 PM manually
3. User should setup a batch process which launches the EC2 instance at a specific time
4. Setup scheduled actions to scale up or down at a specific time
An organization has setup Auto Scaling with ELB. Due to some manual error, one of the instances got rebooted. Thus, it failed the Auto Scaling health check. Auto Scaling has marked it for replacement. How can the system admin ensure that the instance does not get terminated?
1. Update the Auto Scaling group to ignore the instance reboot event
2. It is not possible to change the status once it is marked for replacement
3. Manually add that instance to the Auto Scaling group after reboot to avoid replacement
4. Change the health of the instance to healthy using the Auto Scaling commands
A user has configured Auto Scaling with the minimum capacity as 2 and the desired capacity as 2. The user is trying to terminate one of the existing instance with the command: as-terminate-instance-in-auto-scaling-group<Instance ID> –decrement-desired-capacity. What will Auto Scaling do in this scenario?
1. Terminates the instance and does not launch a new instance
2. Terminates the instance and updates the desired capacity to 1
3. Terminates the instance and updates the desired capacity & minimum size to 1
4. Throws an error
An organization has configured Auto Scaling for hosting their application. The system admin wants to understand the Auto Scaling health check process. If the instance is unhealthy, Auto Scaling launches an instance and terminates the unhealthy instance. What is the order execution?
1. Auto Scaling launches a new instance first and then terminates the unhealthy instance
2. Auto Scaling performs the launch and terminate processes in a random order
3. Auto Scaling launches and terminates the instances simultaneously
4. Auto Scaling terminates the instance first and then launches a new instance
A user has configured ELB with Auto Scaling. The user suspended the Auto Scaling terminate process only for a while. What will happen to the availability zone rebalancing process (AZRebalance) during this period?
1. Auto Scaling will not launch or terminate any instances
2. Auto Scaling will allow the instances to grow more than the maximum size
3. Auto Scaling will keep launching instances till the maximum instance size
4. It is not possible to suspend the terminate process while keeping the launch active
An organization has configured Auto Scaling with ELB. There is a memory issue in the application which is causing CPU utilization to go above 90%. The higher CPU usage triggers an event for Auto Scaling as per the scaling policy. If the user wants to find the root cause inside the application without triggering a scaling activity, how can he achieve this?
1. Stop the scaling process until research is completed
2. It is not possible to find the root cause from that instance without triggering scaling
3. Delete Auto Scaling until research is completed
4. Suspend the scaling process until research is completed
A user has configured ELB with Auto Scaling. The user suspended the Auto Scaling Alarm Notification (which notifies Auto Scaling for CloudWatch alarms) process for a while. What will Auto Scaling do during this period?
1. AWS will not receive the alarms from CloudWatch
2. AWS will receive the alarms but will not execute the Auto Scaling policy
3. Auto Scaling will execute the policy but it will not launch the instances until the process is resumed
4. It is not possible to suspend the AlarmNotification process
An organization has configured two single availability zones. The Auto Scaling groups are configured in separate zones. The user wants to merge the groups such that one group spans across multiple zones. How can the user configure this?
1. Run the command as-join-auto-scaling-group to join the two groups
2. Run the command as-update-auto-scaling-group to configure one group to span across zones and delete the other group
3. Run the command as-copy-auto-scaling-group to join the two groups
4. Run the command as-merge-auto-scaling-group to merge the groups
An organization has configured Auto Scaling with ELB. One of the instance health check returns the status as Impaired to Auto Scaling. What will Auto Scaling do in this scenario?
1. Perform a health check until cool down before declaring that the instance has failed
2. Terminate the instance and launch a new instance
3. Notify the user using SNS for the failed state
4. Notify ELB to stop sending traffic to the impaired instance
A user has setup an Auto Scaling group. The group has failed to launch a single instance for more than 24 hours. What will happen to Auto Scaling in this condition
1. Auto Scaling will keep trying to launch the instance for 72 hours
2. Auto Scaling will suspend the scaling process
3. Auto Scaling will start an instance in a separate region
4. The Auto Scaling group will be terminated automatically
A user is planning to setup infrastructure on AWS for the Christmas sales. The user is planning to use Auto Scaling based on the schedule for proactive scaling. What advise would you give to the user?
1. It is good to schedule now because if the user forgets later on it will not scale up
2. The scaling should be setup only one week before Christmas
3. Wait till end of November before scheduling the activity
4. It is not advisable to use scheduled based scaling
A user is trying to setup a recurring Auto Scaling process. The user has setup one process to scale up every day at 8 am and scale down at 7 PM. The user is trying to setup another recurring process which scales up on the 1st of every month at 8 AM and scales down the same day at 7 PM. What will Auto Scaling do in this scenario
1. Auto Scaling will execute both processes but will add just one instance on the 1st
2. Auto Scaling will add two instances on the 1st of the month
3. Auto Scaling will schedule both the processes but execute only one process randomly
4. Auto Scaling will throw an error since there is a conflict in the schedule of two separate Auto Scaling Processes
A sys admin is trying to understand the Auto Scaling activities. Which of the below mentioned processes is not performed by Auto Scaling?
1. Reboot Instance
2. Schedule Actions
3. Replace Unhealthy
4. Availability Zone Re-Balancing
You have started a new job and are reviewing your company’s infrastructure on AWS. You notice one web application where they have an Elastic Load Balancer in front of web instances in an Auto Scaling Group. When you check the metrics for the ELB in CloudWatch you see four healthy instances in Availability Zone (AZ) A and zero in AZ B. There are zero unhealthy instances. What do you need to fix to balance the instances across AZs?
1. Set the ELB to only be attached to another AZ
2. Make sure Auto Scaling is configured to launch in both AZs
3. Make sure your AMI is available in both AZs
4. Make sure the maximum size of the Auto Scaling Group is greater than 4
You have been asked to leverage Amazon VPC EC2 and SQS to implement an application that submits and receives millions of messages per second to a message queue. You want to ensure your application has sufficient bandwidth between your EC2 instances and SQS. Which option will provide the most scalable solution for communicating between the application and SQS?
1. Ensure the application instances are properly configured with an Elastic Load Balancer
2. Ensure the application instances are launched in private subnets with the EBS-optimized option enabled
3. Ensure the application instances are launched in public subnets with the associate-public-IP-address=trueoption enabled
4. Launch application instances in private subnets with an Auto Scaling group and Auto Scaling triggers configured to watch the SQS queue size
You have decided to change the Instance type for instances running in your application tier that are using Auto Scaling. In which area below would you change the instance type definition?
1. Auto Scaling launch configuration or launch template
2. Auto Scaling group
3. Auto Scaling policy
4. Auto Scaling tags
A user is trying to delete an Auto Scaling group from CLI. Which of the below mentioned steps are to be performed by the user?
1. Terminate the instances with the ec2-terminate-instance command
2. Terminate the Auto Scaling instances with the as-terminate-instance command
3. Set the minimum size and desired capacity to 0
4. There is no need to change the capacity. Run the as-delete-group command and it will reset all values to 0
A user has created a web application with Auto Scaling. The user is regularly monitoring the application and he observed that the traffic is highest on Thursday and Friday between 8 AM to 6 PM. What is the best solution to handle scaling in this case?
1. Add a new instance manually by 8 AM Thursday and terminate the same by 6 PM Friday
2. Schedule Auto Scaling to scale up by 8 AM Thursday and scale down after 6 PM on Friday
3. Schedule a policy which may scale up every day at 8 AM and scales down by 6 PM
4. Configure a batch process to add a instance by 8 AM and remove it by Friday 6 PM
A user has configured the Auto Scaling group with the minimum capacity as 3 and the maximum capacity as 5. When the user configures the AS group, how many instances will Auto Scaling launch?
1. 3
2. 0
3. 5
4. 2
A sys admin is maintaining an application on AWS. The application is installed on EC2 and user has configured ELB and Auto Scaling. Considering future load increase, the user is planning to launch new servers proactively so that they get registered with ELB. How can the user add these instances with Auto Scaling?
1. Increase the desired capacity of the Auto Scaling group
2. Increase the maximum limit of the Auto Scaling group
3. Launch an instance manually and register it with ELB on the fly
4. Decrease the minimum limit of the Auto Scaling group
In reviewing the auto scaling events for your application you notice that your application is scaling up and down multiple times in the same hour. What design choice could you make to optimize for the cost while preserving elasticity? Choose 2 answers.
1. Modify the Amazon CloudWatch alarm period that triggers your auto scaling scale down policy.
2. Modify the Auto scaling group termination policy to terminate the oldest instance first.
3. Modify the Auto scaling policy to use scheduled scaling actions.
4. Modify the Auto scaling group cool down timers.
5. Modify the Auto scaling group termination policy to terminate newest instance first.
You have a business critical two tier web app currently deployed in two availability zones in a single region, using Elastic Load Balancing and Auto Scaling. The app depends on synchronous replication (very low latency connectivity) at the database layer. The application needs to remain fully available even if one application Availability Zone goes off-line, and Auto scaling cannot launch new instances in the remaining Availability Zones. How can the current architecture be enhanced to ensure this? [PROFESSIONAL]
1. Deploy in two regions using Weighted Round Robin (WRR), with Auto Scaling minimums set for 100% peak load per region.
2. Deploy in three AZs, with Auto Scaling minimum set to handle 50% peak load per zone.
3. Deploy in three AZs, with Auto Scaling minimum set to handle 33% peak load per zone. (Loss of one AZ will handle only 66% if the autoscaling also fails)
4. Deploy in two regions using Weighted Round Robin (WRR), with Auto Scaling minimums set for 50% peak load per region.
A user has created a launch configuration for Auto Scaling where CloudWatch detailed monitoring is disabled. The user wants to now enable detailed monitoring. How can the user achieve this?
1. Update the Launch config with CLI to set InstanceMonitoringDisabled = false
2. The user should change the Auto Scaling group from the AWS console to enable detailed monitoring
3. Update the Launch config with CLI to set InstanceMonitoring.Enabled = true
4. Create a new Launch Config with detail monitoring enabled and update the Auto Scaling group (Note: For new accounts, create a new Launch Template version instead)
A user has created an Auto Scaling group with default configurations from CLI. The user wants to setup the CloudWatch alarm on the EC2 instances, which are launched by the Auto Scaling group. The user has setup an alarm to monitor the CPU utilization every minute. Which of the below mentioned statements is true?
1. It will fetch the data at every minute but the four data points [corresponding to 4 minutes] will not have value since the EC2 basic monitoring metrics are collected every five minutes
2. It will fetch the data at every minute as detailed monitoring on EC2 will be enabled by the default launch configuration of Auto Scaling
3. The alarm creation will fail since the user has not enabled detailed monitoring on the EC2 instances
4. The user has to first enable detailed monitoring on the EC2 instances to support alarm monitoring at every minute
A customer has a website which shows all the deals available across the market. The site experiences a load of 5 large EC2 instances generally. However, a week before Thanksgiving vacation they encounter a load of almost 20 large instances. The load during that period varies over the day based on the office timings. Which of the below mentioned solutions is cost effective as well as help the website achieve better performance?
1. Keep only 10 instances running and manually launch 10 instances every day during office hours.
2. Setup to run 10 instances during the pre-vacation period and only scale up during the office time by launching 10 more instances using the AutoScaling schedule.
3. During the pre-vacation period setup a scenario where the organization has 15 instances running and 5 instances to scale up and down using Auto Scaling based on the network I/O policy.
4. During the pre-vacation period setup 20 instances to run continuously.
When Auto Scaling is launching a new instance based on condition, which of the below mentioned policies will it follow?
1. Based on the criteria defined with cross zone Load balancing
2. Launch an instance which has the highest load distribution
3. Launch an instance in the AZ with the fewest instances
4. Launch an instance in the AZ which has the highest instances
The user has created multiple AutoScaling groups. The user is trying to create a new AS group but it fails. How can the user know that he has reached the AS group limit specified by AutoScaling in that region?
1. Run the command: as-describe-account-limits
2. Run the command: as-describe-group-limits
3. Run the command: as-max-account-limits
4. Run the command: as-list-account-limits
A user is trying to save some cost on the AWS services. Which of the below mentioned options will not help him save cost?
1. Delete the unutilized EBS volumes once the instance is terminated
2. Delete the Auto Scaling launch configuration after the instances are terminated (Auto Scaling Launch config does not cost anything)
3. Release the elastic IP if not required once the instance is terminated
4. Delete the AWS ELB after the instances are terminated
To scale up the AWS resources using manual Auto Scaling, which of the below mentioned parameters should the user change?
1. Maximum capacity
2. Desired capacity
3. Preferred capacity
4. Current capacity
For AWS Auto Scaling, what is the first transition state an existing instance enters after leaving steady state in Standby mode?
1. Detaching
2. Terminating:Wait
3. Pending (You can put any instance that is in an InService state into a Standby state. This enables you to remove the instance from service, troubleshoot or make changes to it, and then put it back into service. Instances in a Standby state continue to be managed by the Auto Scaling group. However, they are not an active part of your application until you put them back into service. Refer link)
4. EnteringStandby
For AWS Auto Scaling, what is the first transition state an instance enters after leaving steady state when scaling in due to health check failure or decreased load?
1. Terminating (When Auto Scaling responds to a scale in event, it terminates one or more instances. These instances are detached from the Auto Scaling group and enter the Terminating state. Refer link)
2. Detaching
3. Terminating:Wait
4. EnteringStandby
A user has setup Auto Scaling with ELB on the EC2 instances. The user wants to configure that whenever the CPU utilization is below 10%, Auto Scaling should remove one instance. How can the user configure this?
1. The user can get an email using SNS when the CPU utilization is less than 10%. The user can use the desired capacity of Auto Scaling to remove the instance
2. Use CloudWatch to monitor the data and Auto Scaling to remove the instances using scheduled actions
3. Configure CloudWatch to send a notification to Auto Scaling Launch configuration when the CPU utilization is less than 10% and configure the Auto Scaling policy to remove the instance
4. Configure CloudWatch to send a notification to the Auto Scaling group when the CPU Utilization is less than 10% and configure the Auto Scaling policy to remove the instance
A user has enabled detailed CloudWatch metric monitoring on an Auto Scaling group. Which of the below mentioned metrics will help the user identify the total number of instances in an Auto Scaling group including pending, terminating and running instances?
1. GroupTotalInstances (Refer link)
2. GroupSumInstances
3. It is not possible to get a count of all the three metrics together. The user has to find the individual number of running, terminating and pending instances and sum it
4. GroupInstancesCount
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]
1. Add a business process management application to your Elastic Beanstalk app servers and re-use the ROS database for tracking order status use one of the Elastic Beanstalk instances to send emails to customers.
2. 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.
3. 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.
4. 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.
An organization wants to reduce latency for their Auto Scaling group during scale-out events. Their application takes 5 minutes to boot and initialize. Which Auto Scaling feature should they use?
1. Increase the desired capacity permanently
2. Use Predictive Scaling to pre-provision
3. Configure a Warm Pool with pre-initialized instances
4. Set a longer cooldown period
A company has an application with predictable traffic patterns that peaks every weekday at 9 AM and reduces at 6 PM. They want Auto Scaling to proactively provision capacity before the peak. Which scaling approach is most appropriate?
1. Target tracking scaling policy with CPU metric
2. Step scaling policy with CloudWatch alarms
3. Scheduled scaling actions
4. Predictive Scaling policy
A company needs to update the AMI across all instances in their Auto Scaling group without terminating instances, preserving their network interfaces and non-root EBS volumes. Which approach should they use?
1. Create new launch template version and wait for scale-in/scale-out to replace instances
2. Use instance refresh with the rolling strategy
3. Use instance refresh with the replace root volume strategy
4. Manually stop and update each instance
An application team wants to control the order in which instances are replaced during Auto Scaling health check replacements. They want new instances launched BEFORE unhealthy ones are terminated to maintain capacity. Which feature should they configure?
1. Instance protection
2. Lifecycle hooks
3. Instance maintenance policy with “Launch before terminating”
4. Custom termination policy
An Auto Scaling group experiences an Availability Zone impairment. The team wants to quickly shift traffic away from the impaired AZ while preventing Auto Scaling from terminating instances in that zone. Which feature integrates with Auto Scaling to handle this? [PROFESSIONAL]
1. Suspend the AZRebalance process
2. Remove the AZ from the ASG configuration
3. Use Amazon ARC Zonal Shift with the Auto Scaling group
4. Enable cross-zone load balancing on the ELB

References

AWS Auto Scaling User Guide

AWS ELB Monitoring

March 18, 2016 ~ Last updated on : June 23, 2026 ~ jayendrapatil ~ 9 Comments

AWS ELB Monitoring

Elastic Load Balancing publishes data points to Amazon CloudWatch about the load balancers and targets (or back-end instances for Classic Load Balancer).
Elastic Load Balancing reports metrics to CloudWatch only when requests are flowing through the load balancer.
- If there are requests flowing through the load balancer, Elastic Load Balancing measures and sends its metrics in 60-second intervals.
- If there are no requests flowing through the load balancer or no data for a metric, the metric is not reported.
AWS provides four types of load balancers, each with its own monitoring capabilities:
- Application Load Balancer (ALB) – Layer 7, HTTP/HTTPS/gRPC
- Network Load Balancer (NLB) – Layer 4, TCP/UDP/TLS
- Gateway Load Balancer (GWLB) – Layer 3, transparent network gateway
- Classic Load Balancer (CLB) – Previous generation (Layer 4/7)
ELB monitoring options include CloudWatch metrics, access logs, connection logs, health check logs, CloudTrail logs, and CloudWatch Internet Monitor.

CloudWatch Metrics

Classic Load Balancer (CLB) Metrics

CLB metrics use the AWS/ELB namespace.
HealthyHostCount, UnHealthyHostCount
- Number of healthy and unhealthy instances registered with the load balancer.
- Most useful statistics are Average, Min, and Max.
RequestCount
- Number of requests completed or connections made during the specified interval (1 or 5 minutes).
- Most useful statistic is Sum.
Latency
- Time elapsed, in seconds, after the request leaves the load balancer until the headers of the response are received.
- Most useful statistic is Average.
SurgeQueueLength
- Total number of requests that are pending routing.
- Load balancer queues a request if it is unable to establish a connection with a healthy instance in order to route the request.
- Maximum size of the queue is 1,024. Additional requests are rejected when the queue is full.
- Most useful statistic is Max, because it represents the peak of queued requests.
SpilloverCount
- The total number of requests that were rejected because the surge queue is full. Should ideally be 0.
- Most useful statistic is Sum.
HTTPCode_ELB_4XX, HTTPCode_ELB_5XX
- Client and server error codes generated by the load balancer.
- Most useful statistic is Sum.
HTTPCode_Backend_2XX, HTTPCode_Backend_3XX, HTTPCode_Backend_4XX, HTTPCode_Backend_5XX
- Number of HTTP response codes generated by registered instances.
- Most useful statistic is Sum.

Application Load Balancer (ALB) Metrics

ALB metrics use the AWS/ApplicationELB namespace.
ActiveConnectionCount – Total concurrent TCP connections active from clients to the load balancer and from the load balancer to targets. Useful statistic: Sum.
NewConnectionCount – Total new TCP connections established from clients to the load balancer and from the load balancer to targets. Useful statistic: Sum.
RejectedConnectionCount – Number of connections rejected because the load balancer reached its maximum number of connections. Useful statistic: Sum.
RequestCount – Number of requests processed over IPv4 and IPv6. Useful statistic: Sum.
TargetResponseTime – Time elapsed after the request leaves the load balancer until the target starts to send response headers. Useful statistics: Average, pNN.NN (percentiles).
HealthyHostCount, UnHealthyHostCount – Number of healthy/unhealthy targets. Useful statistics: Average, Min, Max.
HTTPCode_Target_2XX_Count through 5XX_Count – HTTP response codes generated by targets. Useful statistic: Sum.
HTTPCode_ELB_4XX_Count, HTTPCode_ELB_5XX_Count – HTTP error codes generated by the load balancer itself. Useful statistic: Sum.
ClientTLSNegotiationErrorCount – TLS connections initiated by clients that did not establish a session with the load balancer. Useful statistic: Sum.
TargetConnectionErrorCount – Connections that were not successfully established between the load balancer and target. Useful statistic: Sum.
ProcessedBytes – Total bytes processed by the load balancer over IPv4 and IPv6. Useful statistic: Sum.
ConsumedLCUs – Number of Load Balancer Capacity Units (LCU) consumed. Used for billing calculations.
RuleEvaluations – Number of rules evaluated while processing requests.
AnomalousHostCount – Number of targets detected with anomalies (used with Automatic Target Weights). Useful statistics: Min, Max.

Network Load Balancer (NLB) Metrics

NLB metrics use the AWS/NetworkELB namespace.
ActiveFlowCount – Total number of concurrent flows (connections) from clients to targets. Useful statistic: Average.
NewFlowCount – Total number of new flows established from clients to targets. Useful statistic: Sum.
ProcessedBytes – Total bytes processed by the load balancer (TCP/TLS, UDP). Useful statistic: Sum.
TCP_Client_Reset_Count, TCP_Target_Reset_Count, TCP_ELB_Reset_Count – Number of reset (RST) packets sent from client, target, or the load balancer.
HealthyHostCount, UnHealthyHostCount – Number of healthy/unhealthy targets.
ConsumedLCUs – Number of Network Load Balancer Capacity Units consumed.
PeakBytesPerSecond – Highest average bytes per second for the load balancer during a period.

Gateway Load Balancer (GWLB) Metrics

GWLB metrics use the AWS/GatewayELB namespace.
ActiveFlowCount, NewFlowCount – Concurrent and new flows from clients to targets.
ProcessedBytes – Total bytes processed by the GWLB.
HealthyHostCount, UnHealthyHostCount – Number of healthy/unhealthy targets.
GWLB does NOT generate access logs since it is a transparent Layer 3 load balancer that does not terminate flows.

Elastic Load Balancer Access Logs

Elastic Load Balancing provides access logs that capture detailed information about all requests sent to the load balancer.
Each log contains information such as the time the request was received, the client’s IP address, latencies, request paths, and server responses.
Access logging is disabled by default and can be enabled without any additional charge. You are only charged for S3 storage.
Access logs are supported for ALB, NLB, and CLB. GWLB does not generate access logs.

ALB Access Logs

ALB publishes a log file for each load balancer node every 5 minutes to Amazon S3.
Log entries include: request type, timestamp, ELB name, client:port, target:port, request processing time, target processing time, response processing time, ELB/target status codes, received/sent bytes, request details, user agent, SSL cipher/protocol, target group ARN, trace ID, and more.

NLB Access Logs

NLB access logs capture information about TLS requests sent to the load balancer.
Logs can be stored in Amazon S3.
New (Nov 2025): NLB access logs now support delivery as CloudWatch Vended Logs, enabling direct delivery to CloudWatch Logs, Amazon Data Firehose, and Amazon S3 with Apache Parquet format support. This allows real-time log analysis using CloudWatch Logs Insights and Live Tail.

ALB Connection Logs

Connection logs capture detailed information about TLS connections established between clients and the ALB.
Useful for troubleshooting TLS client connection issues (e.g., mTLS failures, cipher mismatches).
Connection logs are stored in Amazon S3, with a log file published every 5 minutes.
This is an optional feature, disabled by default.
Log entries include: timestamp, client IP:port, listener port, TLS protocol/cipher, connection status, client certificate details (for mTLS), and more.

ALB Health Check Logs

New (Nov 2025): ALB now supports Health Check Logs that send detailed target health check data directly to a designated Amazon S3 bucket.
This optional feature captures:
- Health check status (healthy/unhealthy)
- Timestamps
- Target identification data
- Failure reasons for unhealthy targets
Health check logs are published every 5 minutes per load balancer node.
Helps troubleshoot intermittent target health check failures without needing to rely solely on CloudWatch metrics.
No additional charge; you pay only for S3 storage.

CloudWatch Internet Monitor

Amazon CloudWatch Internet Monitor provides internet performance and availability measurements for user traffic to load balancers.
Monitors internet traffic patterns and identifies issues that affect internet connectivity between users and AWS.
Supported for both ALB and NLB.
NLB integration (Sep 2024): You can create or associate a monitor for an NLB directly when creating it in the AWS Management Console.
Provides city-level visibility into performance impairments and their geographic scope.

CloudWatch Network Flow Monitor

New (Dec 2024, re:Invent): CloudWatch Network Flow Monitor offers network performance monitoring across AWS managed services.
Provides near real-time visibility into network performance for traffic between compute resources (EC2, EKS), to AWS services (S3, DynamoDB), and to other AWS Regions.
Uses lightweight agents to gather TCP connection performance statistics (packet loss, latency).
Can determine if AWS is the cause of a detected network issue for monitored flows.

ALB Automatic Target Weights (ATW)

New (Nov 2023): ALB supports Automatic Target Weights (ATW), which uses anomaly detection to optimize traffic routing.
ATW detects and mitigates gray failures — situations where a target passes health checks but still returns elevated errors.
Anomaly detection is automatically enabled on HTTP/HTTPS target groups with at least three healthy targets.
ATW analyzes HTTP return status codes and TCP/TLS errors to identify anomalous targets and reduces traffic to them.
Provides the AnomalousHostCount CloudWatch metric to monitor detected anomalies.

CloudWatch Anomaly Detection Alarms

CloudWatch anomaly detection uses machine learning to model expected metric behavior and automatically creates upper and lower bounds.
Can be used with ELB metrics like TargetResponseTime, RequestCount, HTTPCode_ELB_5XX to detect unusual patterns.
Recommended approach for monitoring ELB performance without manually setting static thresholds.
Works with ALB, NLB, CLB, and GWLB metrics.

CloudTrail Logs

AWS CloudTrail captures all API calls to the Elastic Load Balancing API made by or on behalf of your AWS account.
API calls can be made directly, or indirectly through the AWS Management Console, AWS CLI, or SDKs.
CloudTrail stores the information as log files in an Amazon S3 bucket.
Logs can be used to monitor load balancer activity and determine what API call was made, what source IP address was used, who made the call, when it was made, and so on.
Applies to all ELB types (ALB, NLB, GWLB, CLB).

Classic Load Balancer – Migration Recommendation

⚠️ Note: Classic Load Balancer is the previous generation load balancer. AWS strongly recommends migrating to Application Load Balancer (Layer 7) or Network Load Balancer (Layer 4).

EC2-Classic networking was fully retired in August 2023. While CLB continues to function in VPC, no new features are being added to it. Use the AWS Migration Wizard to move to ALB or NLB.

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.

An admin is planning to monitor the ELB. Which of the below mentioned services does not help the admin capture the monitoring information about the ELB activity?
1. ELB Access logs
2. ELB health check
3. CloudWatch metrics
4. ELB API calls with CloudTrail
A customer needs to capture all client connection information from their load balancer every five minutes. The company wants to use this data for analyzing traffic patterns and troubleshooting their applications. Which of the following options meets the customer requirements?
1. Enable AWS CloudTrail for the load balancer.
2. Enable access logs on the load balancer.
3. Install the Amazon CloudWatch Logs agent on the load balancer.
4. Enable Amazon CloudWatch metrics on the load balancer.
Your supervisor has requested a way to analyze traffic patterns for your application. You need to capture all connection information from your load balancer every 10 minutes. Pick a solution from below. Choose the correct answer:
1. Enable access logs on the load balancer.
2. Create a custom metric CloudWatch filter on your load balancer.
3. Use a CloudWatch Logs Agent.
4. Use AWS CloudTrail with your load balancer.
A company runs a web application behind an Application Load Balancer. Some users are experiencing intermittent 5XX errors but health checks show all targets as healthy. Which ALB feature can automatically detect and mitigate this issue?
1. Cross-Zone Load Balancing
2. Automatic Target Weights (ATW)
3. Connection Draining
4. Sticky Sessions
A DevOps engineer needs to troubleshoot why targets behind an ALB are intermittently failing health checks. Which recently introduced feature provides detailed health check failure reasons stored in S3?
1. ALB Access Logs
2. CloudWatch HealthyHostCount metric
3. ALB Health Check Logs
4. AWS CloudTrail
A solutions architect wants to analyze NLB access logs in near real-time using CloudWatch Logs Insights. Which delivery option should they configure?
1. Enable NLB access logs to S3 and create Athena queries
2. Configure NLB access logs as CloudWatch Vended Logs
3. Enable VPC Flow Logs on the NLB
4. Install CloudWatch Agent on NLB nodes
Which of the following is a metric specific to Classic Load Balancer that indicates the load balancer cannot route requests because the queue is full?
1. RejectedConnectionCount
2. TargetConnectionErrorCount
3. SpilloverCount
4. HTTPCode_ELB_503
A company wants to identify if AWS infrastructure is causing latency issues for users connecting to their Network Load Balancer from different geographic locations. Which service should they use?
1. AWS X-Ray
2. CloudWatch Metrics
3. Amazon CloudWatch Internet Monitor
4. VPC Flow Logs

References

AWS Bastion Host – Secure SSH/RDP Access

March 14, 2016 ~ Last updated on : June 26, 2026 ~ jayendrapatil ~ 16 Comments

Bastion Host Overview

📌 2025 Update: Modern Alternatives to Bastion Hosts

While bastion hosts remain a valid architecture pattern, AWS now offers several modern alternatives that eliminate the need for managing a dedicated jump server:

EC2 Instance Connect Endpoint (launched June 2023) – Connect to private instances without a bastion host, public IP, or IGW
AWS Systems Manager Session Manager – IAM-based shell access over HTTPS; no open inbound ports or SSH keys needed
AWS Verified Access – Zero trust access to resources over SSH/RDP protocols (non-HTTP support GA Feb 2025)

The AWS Quick Start for Linux Bastion was archived in October 2024 as part of the full AWS Quick Start program retirement.

Bastion means a structure for Fortification to protect things behind it
In AWS, a Bastion host (also referred to as a Jump server) can be used to securely access instances in the private subnets.
Bastion host launched in the Public subnets would act as a primary access point from the Internet and acts as a proxy to other instances.

Bastion Host

Key points

Bastion host is deployed in the Public subnet and acts as a proxy or a gateway between you and your instances
Bastion host is a security measure that helps to reduce attack on your infrastructure and you have to concentrate to hardening a single layer
Bastion host allows you to login to instances in the Private subnet securely without having to store the private keys on the Bastion host (using ssh-agent forwarding or RDP gateways)
Bastion host security can be further tightened to allow SSH/RDP access from specific trusted IPs or corporate IP ranges
Bastion host for your AWS infrastructure shouldn’t be used for any other purpose, as that could open unnecessary security holes
Security for all the Instances in the private subnet should be hardened to accept SSH/RDP connections only from the Bastion host
Deploy a Bastion host within each Availability Zone for HA, cause if the Bastion instance or the AZ hosting the Bastion server goes down the ability to connect to your private instances is lost completely

Modern Alternatives to Bastion Hosts

EC2 Instance Connect Endpoint (EIC Endpoint)

Launched in June 2023, EC2 Instance Connect Endpoint allows secure connectivity to instances in private subnets from the internet without requiring a bastion host
No IGW in the VPC, no public IP on the instance, and no agent installation required
Supports SSH and RDP connections using private IP addresses
Access is controlled through IAM policies and security groups
Available at no additional cost
One EIC Endpoint per VPC; supported in all AWS Regions except Canada West (Calgary)
Ideal for ad-hoc access to private instances without maintaining bastion infrastructure

AWS Systems Manager Session Manager

Provides secure, auditable instance management without opening inbound ports (no port 22/3389 needed)
No SSH keys to manage – access is controlled entirely through IAM policies
Requires SSM Agent installed on the instance (pre-installed on Amazon Linux 2, Amazon Linux 2023, and many other AMIs)
Provides full audit trail in AWS CloudTrail and session logging to S3/CloudWatch
Supports port forwarding for accessing applications on private instances
Works with instances in private subnets without internet access (via VPC endpoints)
Recommended by AWS as a bastion host replacement for operational access

AWS Verified Access

Provides secure, VPN-less access based on Zero Trust principles
Originally supported only HTTP/HTTPS applications (GA April 2023)
Non-HTTP protocol support (SSH, RDP, TCP) went GA in February 2025
Evaluates access based on user identity and device security posture on every request
Uses Cedar policy language for fine-grained access control
Integrates with identity providers (IdPs) and device trust providers (Jamf, CrowdStrike, etc.)
Achieved FedRAMP High and Moderate authorization (March 2025)
Ideal for enterprise environments requiring identity-aware, device-trust-based access

When to Still Use a Bastion Host

Legacy environments where SSM Agent cannot be installed
Compliance requirements mandating a traditional network perimeter
Environments needing specific protocol support not covered by alternatives
Third-party access where IAM-based solutions are not feasible
AWS certification exams still heavily test bastion host concepts

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 customer is running a multi-tier web application farm in a virtual private cloud (VPC) that is not connected to their corporate network. They are connecting to the VPC over the Internet to manage all of their Amazon EC2 instances running in both the public and private subnets. They have only authorized the bastion-security-group with Microsoft Remote Desktop Protocol (RDP) access to the application instance security groups, but the company wants to further limit administrative access to all of the instances in the VPC. Which of the following Bastion deployment scenarios will meet this requirement?
1. Deploy a Windows Bastion host on the corporate network that has RDP access to all instances in the VPC.
2. Deploy a Windows Bastion host with an Elastic IP address in the public subnet and allow SSH access to the bastion from anywhere.
3. Deploy a Windows Bastion host with an Elastic IP address in the private subnet, and restrict RDP access to the bastion from only the corporate public IP addresses.
4. Deploy a Windows Bastion host with an auto-assigned Public IP address in the public subnet, and allow RDP access to the bastion from only the corporate public IP addresses.
You are designing a system that has a Bastion host. This component needs to be highly available without human intervention. Which of the following approaches would you select?
1. Run the bastion on two instances one in each AZ
2. Run the bastion on an active Instance in one AZ and have an AMI ready to boot up in the event of failure
3. Configure the bastion instance in an Auto Scaling group Specify the Auto Scaling group to include multiple AZs but have a min-size of 1 and max-size of 1
4. Configure an ELB in front of the bastion instance
You’ve been brought in as solutions architect to assist an enterprise customer with their migration of an ecommerce platform to Amazon Virtual Private Cloud (VPC) The previous architect has already deployed a 3- tier VPC. The configuration is as follows: VPC vpc-2f8t>C447
IGW ig-2d8bc445
NACL acl-2080c448
Subnets and Route Tables:
Web server’s subnet-258bc44d
Application server’s subnet-248DC44c
Database server’s subnet-9189c6f9
Route Tables:
rtb-2i8bc449
rtb-238bc44b
Associations:
Subnet-258bc44d: rtb-2i8bc449
Subnet-248DC44c: rtb-238bc44b
Subnet-9189c6f9: rtb-238bc44b
You are now ready to begin deploying EC2 instances into the VPC. Web servers must have direct access to the internet Application and database servers cannot have direct access to the internet. Which configuration below will allow you the ability to remotely administer your application and database servers, as well as allow these servers to retrieve updates from the Internet?
1. Create a bastion and NAT Instance in subnet-258bc44d and add a route from rtb-238bc44b to subnet-258bc44d. (Route should point to the NAT)
2. Add a route from rtb-238bc44b to igw-2d8bc445 and add a bastion and NAT instance within Subnet-248DC44c. (Adding IGW to routertb-238bc44b would expose the Application and Database server to internet. Bastion and NAT should be in public subnet)
3. Create a Bastion and NAT Instance in subnet-258bc44d. Add a route from rtb-238bc44b to igw-2d8bc445. And a new NACL that allows access between subnet-258bc44d and subnet-248bc44c. (Route should point to NAT and not Internet Gateway else it would be internet accessible.)
4. Create a Bastion and NAT instance in subnet-258bc44d and add a route from rtb-238bc44b to the NAT instance. (Bastion and NAT should be in the public subnet. As Web Server has direct access to Internet, the subnet subnet-258bc44d should be public and Route rtb-2i8bc449 pointing to IGW. Route rtb-238bc44b for private subnets should point to NAT for outgoing internet access)
You are tasked with setting up a Linux bastion host for access to Amazon EC2 instances running in your VPC. Only clients connecting from the corporate external public IP address 72.34.51.100 should have SSH access to the host. Which option will meet the customer requirement?
1. Security Group Inbound Rule: Protocol – TCP. Port Range – 22, Source 72.34.51.100/32
2. Security Group Inbound Rule: Protocol – UDP, Port Range – 22, Source 72.34.51.100/32
3. Network ACL Inbound Rule: Protocol – UDP, Port Range – 22, Source 72.34.51.100/32
4. Network ACL Inbound Rule: Protocol – TCP, Port Range-22, Source 72.34.51.100/0
A company needs to provide secure access to EC2 instances in private subnets without managing SSH keys or opening inbound ports. The solution must provide an audit trail of all sessions. Which AWS service should they use?
1. Deploy a bastion host in a public subnet with an Auto Scaling group
2. Use AWS Systems Manager Session Manager with IAM-based access control
3. Use EC2 Instance Connect Endpoint with a public IP on the instances
4. Configure a VPN connection from the corporate network
A solutions architect needs to allow developers to connect via SSH to EC2 instances in a private subnet that has no internet gateway and no NAT gateway. The instances do not have public IP addresses. Which solution requires the LEAST operational overhead?
1. Deploy a bastion host in a public subnet and configure security groups
2. Set up an AWS Site-to-Site VPN connection
3. Create an EC2 Instance Connect Endpoint in the VPC
4. Configure AWS Direct Connect with a private virtual interface
An enterprise wants to implement zero trust access to their internal applications and SSH-based administration of EC2 instances. Access should be granted based on user identity and device security posture without using a VPN or bastion host. Which AWS service meets these requirements?
1. AWS Systems Manager Session Manager
2. EC2 Instance Connect Endpoint
3. AWS Verified Access
4. AWS Client VPN
Which of the following are valid modern alternatives to using a bastion host for accessing private EC2 instances? (Select THREE)
1. AWS Systems Manager Session Manager
2. Amazon Inspector
3. EC2 Instance Connect Endpoint
4. AWS Config
5. AWS Verified Access with non-HTTP protocol support

DynamoDB Consistency Model

AWS Consolidated Billing – Multi-Account Savings

March 13, 2016 ~ Last updated on : June 26, 2026 ~ jayendrapatil ~ 9 Comments

AWS Consolidated Billing

Consolidated billing enables consolidating payments from multiple AWS accounts (Linked or Member Accounts) within the organization to a single account by designating it to be the Management (formerly Payer) Account.
Every organization in AWS Organizations has a management account that pays the charges of all the member accounts.
Consolidated billing is automatically enabled when you create an AWS Organization and is offered at no additional cost.
Consolidate billing
- is strictly an accounting and billing feature.
- allows receiving a combined view of charges incurred by all the associated accounts as well as each of the accounts.
- is not a method for controlling accounts, or provisioning resources for accounts.
Management account is billed for all charges of the member accounts.
Each linked account is still an independent account in every other way.
AWS Organization Consolidated Billing feature does not allow the Management account to access data belonging to the linked account owners. All Features mode needs to be enabled for organizational policies.
However, access to the Management account users can be granted through Cross-Account Access roles.
AWS limits work on the account level only and AWS support is per account only.
All workload resources should reside only within member accounts and no resource should be created in the management account (AWS Well-Architected best practice).

Consolidated Billing Process

AWS Organizations provides consolidated billing so that the combined costs of all the member accounts in your organization can be tracked.
Create an Organization.
Create member accounts or invite existing accounts to join the organization.
Each month AWS charges your management account for all the member accounts in a consolidated bill.
The consolidated bill is available within minutes and includes detailed breakdowns by account, service, and region.

Consolidated Billing Scenarios

Have multiple accounts and want to get a single bill and track each account’s charges for e.g. multiple projects, each with its own AWS account or separate environments (Dev, Prod) within the same project.
Have multiple cost centers to track.
Have acquired a project or company with its own existing AWS account and you want a consolidated bill with your other AWS accounts.
Have multiple organizations and want centralized billing management across them (using AWS Billing Transfer).

Consolidated Billing Benefits

One Bill
- A single bill with a combined view of AWS costs incurred by all accounts is generated.
Easy Tracking
- Detailed cost reports & charges for each of the individual AWS accounts associated with the management account can be easily tracked.
- Use Cost Allocation Tags to categorize and track costs; tags are included in the detailed billing report.
Combined Usage & Volume Discounts
- Charges might actually decrease because AWS combines usage from all the accounts to qualify you for volume pricing discounts.
Free Tier
- Customers that use Consolidated Billing to consolidate payment across multiple accounts will only have access to one free usage tier and it is not combined across accounts.
No Extra Cost
- Consolidated billing is offered at no additional cost.

Volume Pricing Discounts

For billing purposes, AWS treats all the accounts in the organization on the consolidated bill as if they were one account.
AWS combines the usage from all accounts to determine which volume pricing tiers to apply, giving you a lower overall price whenever possible.
This applies to services with tiered pricing such as S3 storage, data transfer, and DynamoDB.

Volume Discounts Example

Example AWS Pricing – AWS charges $0.17/GB for the first 10 TB of data transfer out used, and $0.13/GB for the next 40 TB used that translates into $174.08 per TB for the first 10 TB, and $133.12 per TB for the next 40 TB.
Usage – Bob uses 8 TB of data transfer out during the month, and Susan uses 4 TB (for a total of 12 TB used).
Actual Individual Bill – AWS would have charged Bob and Susan each $174.08 per TB for their usage, for a total of $2088.96.
Volume Discount Bill – Combined 12 TB total that Bob and Susan used, would cost the management account ($174.08 * 10 TB) + ($133.12 * 2 TB) = $1740.80 + $266.24 = $2007.04.

Reserved Instances and Savings Plans Sharing

All member accounts in an Organization on a consolidated bill can receive the hourly cost-benefit of Reserved Instances (RIs) and Savings Plans that are purchased by any other account.
The management account of an organization can turn off Reserved Instance and Savings Plans discount sharing for any accounts in that organization, including the management account.
RIs and Savings Plans discounts aren’t shared between any accounts that have sharing turned off. To share an RI or Savings Plans discount with an account, both accounts must have sharing turned on.
For e.g., Bob and Susan each have an account on Bob’s consolidated bill. Susan has 5 Reserved Instances of the same type, and Bob has none. During one particular hour, Susan uses 3 instances and Bob uses 6, for a total of 9 instances used on Bob’s consolidated bill. AWS will bill 5 as Reserved Instances, and the remaining 4 as normal instances.

RI and Savings Plans Group Sharing (Nov 2025)

RISP Group Sharing provides granular control over how AWS commitments (RIs and Savings Plans) are shared across accounts within an organization.
Allows defining groups of accounts (using AWS Cost Categories) based on business units, projects, regions, or funding sources.
Two sharing options:
- Prioritized Group Sharing – Applies commitments to defined groups first, then shares unused capacity organization-wide.
- Restricted Group Sharing – Keeps commitments exclusively within defined groups for complete isolation when strict boundaries are required.
Addresses the challenge of ensuring Reserved Instances and Savings Plans benefit the teams that actually purchased them.
When using Billing Transfer, Reserved Instances and Savings Plans apply only to the AWS Organization where they were purchased and cannot be shared across multiple Organizations.

AWS Billing Transfer (Nov 2025)

AWS Billing Transfer allows centralized billing management and payment across multiple AWS Organizations.
Customers operating in multi-organization environments can designate a single management account to centrally manage and pay bills for multiple organizations.
Capabilities include:
- Centralized invoice collection across organizations.
- Single payment processing for multiple organizations.
- Detailed cost analysis spanning multiple organizations.
Individual management accounts maintain complete security autonomy over their organizations.
Integrated with AWS Billing Conductor to control how cost data is viewed by organizations and implement advanced cost allocation strategies.
Pricing:
- AWS managed pricing plan – No additional cost.
- Customer managed pricing plan – $50/month per AWS Organization.
- Free trial available through May 31, 2026.
Available in all public AWS Regions (excluding GovCloud (US), China Beijing, and China Ningxia).

AWS Billing View & Custom Billing Views (2024-2025)

AWS Billing View enables scoping and securely sharing exact cost and usage data access levels with stakeholders.
Custom Billing Views represent a filtered view of cost management data that can be:
- Shared with member accounts within an organization, giving business unit owners access to their cost data without management account access.
- Shared with accounts outside the organization (multi-source views).
- Combined from multiple organizations into consolidated multi-source views.
Accessible through AWS Cost Explorer and AWS Budgets.
Enables cross-account cost visibility in AWS Budgets without requiring management account access.

AWS Cost and Usage Report (CUR 2.0) & Data Exports

AWS Data Exports enables creating recurring exports of billing and cost management data to S3.
CUR 2.0 is gradually replacing the Legacy Cost and Usage Report with improvements:
- Static schema for easier data ingestion.
- Additional columns (usage account name, billing account name).
- Collapsed columns to reduce data sparsity.
- Supports FOCUS 1.2 specification for open-source cost data formatting.
In AWS Organizations, both management accounts and member accounts can create Cost and Usage Reports.
Split Cost Allocation Data enables cost visibility for containerized workloads (ECS tasks, EKS pods, AWS Batch jobs) across the entire consolidated billing family, including CPU, memory, and GPU/accelerator resource allocation.

Consolidated Billing Best Practices

~~Paying account should be used solely for accounting and billing purposes~~
Consolidated billing works best with Resource tagging, as tags are included in the detailed billing report, which enables cost to be analyzed and decomposed across multiple dimensions and aggregation levels.
~~Paying account owners should secure their accounts by using MFA (multi-factor authentication) and a strong password~~

Consolidated Billing Best Practices (Current)

Management account should be used solely for billing, governance, and organizational management—no workload resources should be created in it.
Use Cost Allocation Tags to categorize and track costs; tags are included in the detailed billing report for analysis across multiple dimensions.
Secure the management account with MFA, a strong password, and minimal IAM users.
Use AWS Budgets to set cost thresholds and receive alerts.
Use Billing View to delegate cost visibility to business unit owners without sharing management account access.
Leverage RISP Group Sharing to align commitment discounts with the business units that purchased them.
Use Service Control Policies (SCPs) with All Features mode for governance and access control.

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.

An organization is planning to create 5 different AWS accounts considering various security requirements. The organization wants to use a single payee account by using the consolidated billing option. Which of the below mentioned statements is true with respect to the above information?
- Master (Payee) account will get only the total bill and cannot see the cost incurred by each account
- Master (Payee) account can view only the AWS billing details of the linked accounts
- It is not recommended to use consolidated billing since the payee account will have access to the linked accounts
- Each AWS account needs to create an AWS billing policy to provide permission to the payee account
An organization has setup consolidated billing with 3 different AWS accounts. Which of the below mentioned advantages will organization receive in terms of the AWS pricing?
- The consolidated billing does not bring any cost advantage for the organization
- All AWS accounts will be charged for S3 storage by combining the total storage of each account
- EC2 instances of each account will receive a total of 750*3 micro instance hours free
- The free usage tier for all the 3 accounts will be 3 years and not a single year
An organization has added 3 of his AWS accounts to consolidated billing. One of the AWS accounts has purchased a Reserved Instance (RI) of a small instance size in the us-east-1a zone. All other AWS accounts are running instances of a small size in the same zone. What will happen in this case for the RI pricing?
- Only the account that has purchased the RI will get the advantage of RI pricing
- One instance of a small size and running in the us-east-1a zone of each AWS account will get the benefit of RI pricing
- Any single instance from all the three accounts can get the benefit of AWS RI pricing if they are running in the same zone and are of the same size
- If there are more than one instances of a small size running across multiple accounts in the same zone no one will get the benefit of RI
An organization is planning to use AWS for 5 different departments. The finance department is responsible to pay for all the accounts. However, they want the cost separation for each account to map with the right cost centre. How can the finance department achieve this?
- Create 5 separate accounts and make them a part of one consolidated billing
- Create 5 separate accounts and use the IAM cross account access with the roles for better management
- Create 5 separate IAM users and set a different policy for their access
- Create 5 separate IAM groups and add users as per the department’s employees
An AWS account wants to be part of the consolidated billing of his organization’s payee account. How can the owner of that account achieve this?
- The payee account has to request AWS support to link the other accounts with his account
- The owner of the linked account should add the payee account to his master account list from the billing console
- The payee account will send a request to the linked account to be a part of consolidated billing (Check Process)
- The owner of the linked account requests the payee account to add his account to consolidated billing
You are looking to migrate your Development (Dev) and Test environments to AWS. You have decided to use separate AWS accounts to host each environment. You plan to link each accounts bill to a Master AWS account using Consolidated Billing. To make sure you keep within budget you would like to implement a way for administrators in the Master account to have access to stop, delete and/or terminate resources in both the Dev and Test accounts. Identify which option will allow you to achieve this goal.
- Create IAM users in the Master account with full Admin permissions. Create cross-account roles in the Dev and Test accounts that grant the Master account access to the resources in the account by inheriting permissions from the Master account.
- Create IAM users and a cross-account role in the Master account that grants full Admin permissions to the Dev and Test accounts.
- Create IAM users in the Master account. Create cross-account roles in the Dev and Test accounts that have full Admin permissions and grant the Master account access.
- Link the accounts using Consolidated Billing. This will give IAM users in the Master account access to resources in the Dev and Test accounts
When using consolidated billing there are two account types. What are they?
- Paying account and Linked account
- Parent account and Child account
- Main account and Sub account.
- Main account and Secondary account.
A customer needs corporate IT governance and cost oversight of all AWS resources consumed by its divisions. The divisions want to maintain administrative control of the discrete AWS resources they consume and keep those resources separate from the resources of other divisions. Which of the following options, when used together will support the autonomy/control of divisions while enabling corporate IT to maintain governance and cost oversight? Choose 2 answers
- Use AWS Consolidated Billing and disable AWS root account access for the child accounts. (Need to link accounts and disabling root access is just a best practice)
- Enable IAM cross-account access for all corporate IT administrators in each child account. (Provides IT governance)
- Create separate VPCs for each division within the corporate IT AWS account.
- Use AWS Consolidated Billing to link the divisions’ accounts to a parent corporate account (Will provide cost oversight)
- Write all child AWS CloudTrail and Amazon CloudWatch logs to each child account’s Amazon S3 ‘Log’ bucket (Preferred approach would be to store logs from multiple accounts to a single S3 bucket with CloudTrail for IT Governance and CloudWatch alerts for Cost Oversight)
An organization has 10 departments. The organization wants to track the AWS usage of each department. Which of the below mentioned options meets the requirement?
1. Setup IAM groups for each department and track their usage
2. Create separate accounts for each department, but use consolidated billing for payment and tracking
3. Create separate accounts for each department and track them separately
4. Setup IAM users for each department and track their usage
A large enterprise operates multiple AWS Organizations for different business units. They want to centralize invoice collection and payment processing while allowing each organization to maintain security autonomy. Which AWS feature should they use?
- Create a single AWS Organization and move all accounts into it
- Use IAM cross-account roles to access billing in each organization
- Use AWS Billing Transfer to designate a single management account to centrally manage billing across multiple organizations
- Enable consolidated billing in each organization and manually combine invoices
An organization has purchased Reserved Instances in Account A for the engineering team. They want to ensure the RI discounts benefit only the engineering team’s accounts (A, B, and C) and are NOT shared with other accounts in the organization. Which approach provides the most granular control?
- Turn off RI sharing in the management account for all non-engineering accounts
- Purchase Reserved Instances in a separate organization with only engineering accounts
- Use Reserved Instances and Savings Plans Group Sharing with Restricted Group Sharing to limit discount sharing to the engineering group only
- Create a Service Control Policy to prevent other accounts from using Reserved Instances
A company wants to give department managers visibility into their team’s AWS costs without providing access to the management account. Which AWS feature enables this?
- Share IAM credentials for the management account billing console
- Create Custom Billing Views and share them with department manager accounts
- Enable all member accounts to create their own Cost and Usage Reports
- Use AWS Billing Conductor to create separate pro forma bills

References

AWS Support Tiers – Certification

March 11, 2016 ~ Last updated on : June 24, 2026 ~ jayendrapatil ~ 1 Comment

AWS Support Plans

⚠️ Major Update: AWS Support Plans Restructured (Dec 2025)

At AWS re:Invent 2025, AWS announced a fundamental restructuring of Support Plans. The legacy Developer, Business, and Enterprise On-Ramp plans will be discontinued on January 1, 2027.

New Plan Structure:

Basic (free) — unchanged, included for all accounts
Business Support+ — replaces Developer and Business (from $29/month)
Enterprise Support — enhanced with AI capabilities (from $5,000/month)
Unified Operations — new top-tier for mission-critical workloads (from $50,000/month)

All new plans combine AI-powered capabilities with AWS human expertise for proactive, rather than reactive, support.

Current AWS Support Plans (2025+)

AWS now provides four Support tiers — one free tier and three paid plans. Support is per AWS Account (except Enterprise and Unified Operations which aggregate across accounts).

Basic Support (Free)

Included for all AWS customers at no additional charge
Customer Service: 24/7 access to account and billing questions
AWS re:Post community access
AWS Health Dashboard — personalized view of service health
AWS Trusted Advisor — core checks only (service limits)
Documentation, whitepapers, and best-practice guides

Business Support+ (from $29/month)

All features from Basic Support
AI-powered contextual recommendations — 24/7 intelligent troubleshooting
AWS DevOps Agent integration — credits equal to 30% of Support charge
24/7 phone, web, chat, and email technical support
Unlimited support cases and contacts
Response times:
- Business/Mission-critical system down: < 30 minutes
- Production system down: < 1 hour
- Production system impaired: < 4 hours
- System impaired: < 12 hours
- General guidance: < 24 hours
Full set of AWS Trusted Advisor checks
Contextual architectural guidance for your use cases
Third-party software support
AWS Support API for automated case management
AWS Support App in Slack
AWS Support Automation Workflows
AWS Health API access
IAM for controlling access to AWS Support
Pricing: Greater of $29/month or tiered: 9% (first $10K), 7% ($10K-$80K), 5% ($80K-$250K), 3% (over $250K)

Enterprise Support (from $5,000/month)

All features from Business Support+
Designated Technical Account Manager (TAM) — deep AWS knowledge with data-driven insights
AWS DevOps Agent integration — credits equal to 75% of Support charge
AWS Security Incident Response — included at no additional cost
Response times:
- Business/Mission-critical system down: < 15 minutes
- Production system down: < 1 hour
- Production system impaired: < 4 hours
- System impaired: < 12 hours
- General guidance: < 24 hours
AWS Trusted Advisor Priority — prioritized and contextual recommendations
AWS Well-Architected Reviews
Proactive security reviews
Infrastructure event management and planned events support
White-glove billing concierge
Personalized strategic support plan
Consultative architectural reviews and guidance
Interactive programs and hands-on workshops
Pricing: Greater of $5,000/month or tiered: 10% (first $150K), 7% ($150K-$500K), 5% ($500K-$1M), 3% (over $1M)

Unified Operations (from $50,000/month)

All features from Enterprise Support
Designated team: TAM + Domain Specialist Engineers + Senior Billing and Account Specialist + Incident Management Engineers
AWS DevOps Agent integration — credits equal to 100% of Support charge
Response times:
- Business/Mission-critical system down: < 5 minutes (from Incident Management Engineer)
- Production system down: < 1 hour
- Production system impaired: < 4 hours
- System impaired: < 12 hours
- General guidance: < 24 hours
24/7 proactive workload monitoring
Continuous architectural reviews with designated domain specialists
Customized proactive services and resiliency reviews
Critical Workload Reviews
AWS Countdown Premium included (one subscription per month)
AWS Incident Detection and Response included
Global TAM coverage
Pricing: Greater of $50,000/month or tiered: 10% (first $1M), 6% ($1M-$5M), 5% (over $5M)

Legacy Plans (Discontinued January 1, 2027)

⚠️ The following plans are being discontinued on January 1, 2027. Existing subscribers can continue using them until that date or transition to new plans at any time.

Developer Support (Legacy)

All features from Basic Support
Best-practice guidance
Client-side diagnostic tools
Building-block architecture support
Business hours email access to Cloud Support Associates
Migration path: → Business Support+ ($29/month minimum)

Business Support (Legacy)

All features from Developer Support
Phone/Email/Chat support, 1 hour response time for production system down
Use-case guidance
AWS Trusted Advisor — full set of checks
Support API access
Third-party software support
IAM for AWS Support access
Migration path: → Business Support+ ($29/month minimum, improved 30-min response time)

Enterprise On-Ramp (Legacy)

All features from Business Support
Pool of TAMs (shared, not designated)
30-minute response time for critical issues
Concierge support team
Migration path: → Enterprise Support ($5,000/month — automatic upgrade during 2026)

Support Plan Comparison

Feature	Basic	Business Support+	Enterprise	Unified Operations
Pricing	Free	From $29/month	From $5,000/month	From $50,000/month
Critical Response Time	—	< 30 minutes	< 15 minutes	< 5 minutes
Technical Support	—	24/7 phone, web, chat	24/7 phone, web, chat	24/7 phone, web, chat
AI-Powered Assistance	—	✔	✔	✔
Trusted Advisor	Core checks	Full checks	Full + Priority	Full + Priority
TAM	—	—	Designated	Designated + Team
Well-Architected Reviews	—	—	✔	✔
Security Incident Response	—	Additional fee	Included	Included
Proactive Monitoring	—	—	—	24/7 workload monitoring
Third-Party Software Support	—	✔	✔	✔

Key Changes from Legacy to New Plans

Business Support+ replaces both Developer and Business Support
- Lower minimum: $29/month (was $100/month for Business)
- Faster critical response: 30 minutes (was 1 hour)
- New AI-powered troubleshooting and recommendations
- AWS DevOps Agent integration included
Enterprise Support (enhanced)
- Lower minimum: $5,000/month (was $15,000/month)
- AWS Security Incident Response now included at no additional cost
- AWS DevOps Agent credits (75% of Support charge)
- Enhanced AI-powered insights for TAMs
Unified Operations (new tier — replaces Enterprise On-Ramp position conceptually at the top)
- 5-minute response time for critical issues
- Dedicated team: TAM + Domain Engineers + Billing Specialist + Incident Engineers
- 24/7 proactive workload monitoring
- AWS Countdown Premium and Incident Detection & Response included
Enterprise On-Ramp discontinued — customers automatically upgraded to Enterprise Support during 2026

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 are the four levels of AWS Premium Support?
- Basic, Developer, Business, Enterprise [Note: Legacy plans. New structure (2025+) is Basic, Business Support+, Enterprise, Unified Operations]
- Basic, Startup, Business, Enterprise
- Free, Bronze, Silver, Gold
- All support is free
What is the maximum response time for a Business level Premium Support case with a production system down?
- 120 seconds
- 1 hour [Note: With new Business Support+, critical response time is 30 minutes]
- 10 minutes
- 12 hours
A company requires a dedicated Technical Account Manager (TAM) and a response time of less than 15 minutes for business-critical system issues. Which AWS Support plan should they choose?
- Business Support+
- Enterprise Support
- Unified Operations
- Basic Support
Which AWS Support plan provides AI-powered contextual recommendations and 24/7 technical support starting at $29/month?
- Basic Support
- Developer Support
- Business Support+
- Enterprise Support
A large enterprise needs 5-minute response times for mission-critical incidents, designated domain specialist engineers, and 24/7 proactive workload monitoring. Which AWS Support plan meets these requirements?
- Business Support+
- Enterprise Support
- Unified Operations
- Enterprise On-Ramp
Which AWS Support plans include AWS Trusted Advisor with the full set of checks? (Select TWO)
- Basic Support
- Business Support+
- Enterprise Support
- Developer Support
Which AWS Support plan includes AWS Security Incident Response at no additional cost?
- Basic Support
- Business Support+
- Enterprise Support
- Developer Support
A startup wants the minimum AWS Support plan that provides 24/7 phone access to cloud support engineers. Which plan should they choose?
- Basic Support
- Developer Support
- Business Support+
- Enterprise Support

References

AWS Security – Whitepaper – Certification

March 10, 2016 ~ Last updated on : June 23, 2026 ~ jayendrapatil ~ 12 Comments

AWS Security – Whitepaper – Certification

📋 Important Update

The original AWS Security Whitepaper and the “Overview of Security Processes” whitepaper have been archived by AWS and marked as “historical reference only.” AWS now recommends the following current resources:

AWS Well-Architected Framework – Security Pillar (Updated November 2024)
Security, Identity, and Compliance on AWS
The Security Design of the AWS Nitro System (February 2024)

The core concepts below remain relevant for AWS certification exams, updated with current information.

Shared Security Responsibility Model

In the Shared Security Responsibility Model, AWS is responsible for securing the underlying infrastructure that supports the cloud (“Security of the Cloud”), and you’re responsible for anything you put on the cloud or connect to the cloud (“Security in the Cloud”).

AWS Security Shared Responsibility Model

AWS Security Responsibilities (“Security OF the Cloud”)

AWS is responsible for protecting the global infrastructure that runs all of the services offered in the AWS cloud. This infrastructure is comprised of the hardware, software, networking, and facilities that run AWS services.
AWS provides several reports from third-party auditors who have verified their compliance with a variety of computer security standards and regulations (available via AWS Artifact)
AWS is responsible for the security configuration of its products that are considered managed services for e.g. RDS, DynamoDB, Lambda, Fargate
For Managed Services, AWS will handle basic security tasks like guest operating system (OS) and database patching, firewall configuration, and disaster recovery.
AWS infrastructure is built on the AWS Nitro System, which provides hardware-enforced isolation between instances and prohibits administrative access to customer data.

Customer Security Responsibilities (“Security IN the Cloud”)

AWS Infrastructure as a Service (IaaS) products for e.g. EC2, VPC, S3 are completely under your control and require you to perform all of the necessary security configuration and management tasks.
Management of the guest OS (including updates and security patches), any application software or utilities installed on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance
For managed services, you are responsible for configuring logical access controls for the resources, protecting account credentials, and encrypting data at rest and in transit as applicable
Identity and access management using AWS IAM, including MFA, password policies, IAM roles, and least-privilege access
Data encryption at rest and in transit using services like AWS KMS, ACM, and S3 encryption options

Shared Responsibility Model Variations

Infrastructure Services (EC2, EBS, VPC) – Customer manages OS, patching, firewall, encryption
Container Services (RDS, ECS, EMR) – AWS manages OS/platform, customer manages access, firewall rules, data encryption
Abstract Services (S3, DynamoDB, Lambda, SQS) – AWS manages platform entirely, customer manages data classification, IAM policies, and encryption options

AWS Global Infrastructure Security

AWS Nitro System

The AWS Nitro System is the underlying platform for all modern EC2 instances, providing hardware-based security isolation
Virtualization resources are offloaded to dedicated hardware and software, minimizing the attack surface
Nitro System’s security model is locked down and prohibits administrative access, eliminating the possibility of human error and tampering
Nitro Isolation Engine (GA 2025 on Graviton5) – The first commercially deployed formally verified hypervisor, providing mathematically proven isolation between virtual machines
Nitro Enclaves – Provides isolated compute environments for processing highly sensitive data (e.g., PII, healthcare, financial data) with no persistent storage, interactive access, or external networking

AWS Compliance Program

AWS supports 143 security standards and compliance certifications, including:

SOC 1, SOC 2, SOC 3 (covering 188 services as of Spring 2026)
ISO 9001, ISO 27001:2022, ISO 27017, ISO 27018, ISO 27701, ISO 22301, ISO 20000-1
CSA STAR CCM v4.0
FedRAMP (High, Moderate)
PCI DSS Level 1
FIPS 140-3 (upgraded from FIPS 140-2)
HIPAA
GDPR
NIST 800-171 (CMMC 2.0)
C5 (Cloud Computing Compliance Criteria Catalogue)
ITAR
MTCS Level 3
IRAP (Australia)

Compliance reports are available through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports and select online agreements.

Physical and Environmental Security

Storage Decommissioning

When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals.
AWS uses the techniques detailed in NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process.
All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.
Media that stored customer data is not removed from AWS control until it has been securely decommissioned.

Network Security

Amazon Corporate Segregation

AWS Production network is segregated from the Amazon Corporate network and requires a separate set of credentials for logical access.
Amazon Corporate network relies on user IDs, passwords, and Kerberos, while the AWS Production network requires SSH public-key authentication through a bastion host.

Network Monitoring & Protection

AWS utilizes a wide variety of automated monitoring systems to provide a high level of service performance and availability. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts. The tools have the ability to set custom performance metrics thresholds for unusual activity.

AWS network provides protection against traditional network security issues:

DDoS – AWS provides AWS Shield Standard (free, automatic L3/L4 DDoS protection for all AWS customers) and AWS Shield Advanced (paid, advanced L3/L4/L7 DDoS protection with 24/7 DDoS Response Team support, DDoS attack flow logs, and cost protection). AWS WAF now includes an Anti-DDoS Managed Rule Group (2025) for automatic application-layer (L7) DDoS mitigation.
Man in the Middle attacks – AWS APIs are available via SSL/TLS-protected endpoints which provide server authentication. AWS Certificate Manager (ACM) provides free public SSL/TLS certificates.
IP spoofing – AWS-controlled, host-based firewall infrastructure will not permit an instance to send traffic with a source IP or MAC address other than its own.
Port Scanning – Unauthorized port scans by Amazon EC2 customers are a violation of the AWS Acceptable Use Policy. When unauthorized port scanning is detected by AWS, it is stopped and blocked.
Packet Sniffing by other tenants – It is not possible for a virtual instance running in promiscuous mode to receive or “sniff” traffic that is intended for a different virtual instance. The Nitro System hypervisor will not deliver any traffic to them that is not addressed to them. Even two virtual instances that are owned by the same customer located on the same physical host cannot listen to each other’s traffic.

Penetration Testing

Updated Policy: AWS no longer requires prior approval for penetration testing on the following permitted services:

Amazon EC2 instances, WAF, NAT Gateways, and Elastic Load Balancers
Amazon RDS
Amazon CloudFront
Amazon Aurora
Amazon API Gateway
AWS Lambda and Lambda@Edge functions
Amazon Lightsail
AWS Elastic Beanstalk

Prohibited Activities (still require AWS approval): DNS zone walking, DoS/DDoS attacks, port flooding, protocol flooding, request flooding.

Secure Design Principles

Secure software development best practices, which include formal design reviews by the AWS Security Team, threat modeling, and completion of a risk assessment
Static code analysis tools are run as a part of the standard build process
Recurring penetration testing performed by carefully selected industry experts
AWS Nitro System hardware-level isolation with formally verified components
Secure by Design principles documented in the 2024 AWS whitepaper “Building Security from the Ground Up”

AWS Account Security Features

AWS account security features include credentials for access control, HTTPS endpoints for encrypted data transmission, the creation of separate IAM user accounts, user activity logging for security monitoring, and Trusted Advisor security checks.

AWS Credentials

AWS IAM Credentials

Individual User Accounts

Do not use the Root account; instead create an IAM User for each user (or use AWS IAM Identity Center, formerly AWS SSO, for centralized workforce identity management) and provide them with a unique set of credentials with least-privilege access required to perform their job function.

Secure HTTPS Access Points

Use HTTPS (TLS 1.2 minimum, TLS 1.3 recommended), provided by all AWS services, for data transmissions, which uses public-key cryptography to prevent eavesdropping, tampering, and forgery.

Security Logs

Use Amazon CloudTrail which provides logs of all requests for AWS resources within the account and captures information about every API call to every AWS resource you use, including sign-in events. CloudTrail logs can be sent to Amazon S3, CloudWatch Logs, or analyzed through Amazon Security Lake.

Trusted Advisor Security Checks

Use AWS Trusted Advisor which inspects your AWS environment and provides recommendations for cost optimization, performance, security, fault tolerance, service limits, and operational excellence. Security checks include open ports, MFA on root account, exposed access keys, and IAM usage.

AWS Security Services

AWS provides a comprehensive suite of security services that complement the infrastructure security:

Threat Detection & Monitoring

Amazon GuardDuty – Intelligent threat detection service that continuously monitors for malicious activity and unauthorized behavior. Features Extended Threat Detection (2024) using AI/ML to identify attack sequences.
AWS Security Hub – Centralized security posture management with near real-time risk analytics (GA Dec 2025). Unifies GuardDuty, Inspector, Macie, and IAM Access Analyzer findings. Extended plan (2026) offers full-stack enterprise security.
Amazon Detective – Analyzes and visualizes security data to investigate potential security issues and identify root cause.
AWS CloudTrail – Records API calls and account activity for governance, compliance, operational auditing, and risk auditing.

Identity & Access Management

AWS IAM – Manage access to AWS services and resources securely with users, groups, roles, and policies.
AWS IAM Identity Center (formerly AWS SSO) – Centrally manage workforce access to multiple AWS accounts and applications.
IAM Access Analyzer – Identifies external access, internal access, and unused access to your resources. Generates least-privilege policies based on CloudTrail activity.

Data Protection

AWS KMS – Create and manage encryption keys for data encryption across AWS services.
AWS CloudHSM – Hardware security modules for regulatory compliance requirements.
Amazon Macie – Uses machine learning to discover and protect sensitive data in S3.
AWS Certificate Manager (ACM) – Provision, manage, and deploy public and private SSL/TLS certificates.

Network & Application Protection

AWS WAF – Web application firewall to protect against common web exploits with Anti-DDoS Managed Rule Group.
AWS Shield – Standard (free) and Advanced DDoS protection.
AWS Network Firewall – Managed network firewall for VPC traffic filtering.
AWS Firewall Manager – Centrally configure and manage firewall rules across accounts.

Compliance & Governance

AWS Artifact – On-demand access to AWS compliance reports (SOC, ISO, PCI, etc.).
AWS Config – Assess, audit, and evaluate configurations of AWS resources.
AWS Audit Manager – Continuously audit AWS usage to simplify risk and compliance assessment.

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.

In the shared security model, AWS is responsible for which of the following security best practices (check all that apply) :
1. Penetration testing
2. Operating system account security management (User responsibility)
3. Threat modeling
4. User group access management (User responsibility)
5. Static code analysis (AWS development cycle responsibility)
You are running a web-application on AWS consisting of the following components an Elastic Load Balancer (ELB) an Auto-Scaling Group of EC2 instances running Linux/PHP/Apache, and Relational DataBase Service (RDS) MySQL. Which security measures fall into AWS’s responsibility?
1. Protect the EC2 instances against unsolicited access by enforcing the principle of least-privilege access (User responsibility)
2. Protect against IP spoofing or packet sniffing
3. Assure all communication between EC2 instances and ELB is encrypted (User responsibility)
4. Install latest security patches on ELB, RDS and EC2 instances (User responsibility for EC2 OS patches; AWS responsibility for ELB and RDS platform patches)
In AWS, which security aspects are the customer’s responsibility? Choose 4 answers
1. Controlling physical access to compute resources (AWS responsibility)
2. Patch management on the EC2 instances operating system
3. Encryption of EBS (Elastic Block Storage) volumes
4. Life-cycle management of IAM credentials
5. Decommissioning storage devices (AWS responsibility)
6. Security Group and ACL (Access Control List) settings
Per the AWS Acceptable Use Policy, penetration testing of EC2 instances:
1. May be performed by AWS, and will be performed by AWS upon customer request.
2. May be performed by AWS, and is periodically performed by AWS.
3. Are expressly prohibited under all circumstances.
4. May be performed by the customer on their own instances without prior authorization from AWS.
5. May be performed by the customer on their own instances, only if performed from EC2 instances
Note: AWS updated their penetration testing policy — prior approval is no longer required for permitted services including EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, and Elastic Beanstalk. DoS/DDoS testing still requires approval.
Which is an operational process performed by AWS for data security?
1. AES-256 encryption of data stored on any shared storage device (User responsibility)
2. Decommissioning of storage devices using industry-standard practices
3. Background virus scans of EBS volumes and EBS snapshots (No virus scan is performed by AWS on User instances)
4. Replication of data across multiple AWS Regions (AWS does not replicate data across regions unless done by User)
5. Secure wiping of EBS data when an EBS volume is unmounted (data is not wiped off on EBS volume when unmounted and it can be remounted on other EC2 instance)
Which AWS service provides on-demand access to AWS compliance reports such as SOC and ISO certifications?
1. AWS Trusted Advisor
2. AWS Config
3. AWS Artifact
4. Amazon Inspector
Which of the following is a key security feature of the AWS Nitro System? (Select TWO)
1. No administrative access to customer data is possible
2. Automatic patching of customer operating systems
3. Hardware-enforced isolation between instances
4. Automatic encryption of all EBS volumes
5. Built-in antivirus protection
A company wants to centrally view and manage security findings across multiple AWS accounts. Which service should they use?
1. Amazon GuardDuty
2. AWS Security Hub
3. AWS CloudTrail
4. Amazon Detective
Which AWS service provides intelligent threat detection by continuously monitoring for malicious activity using AI/ML?
1. AWS WAF
2. AWS Shield
3. Amazon GuardDuty
4. AWS Config
Under the Shared Responsibility Model, for Amazon RDS, which of the following is the customer’s responsibility? (Select TWO)
1. Patching the database engine (AWS responsibility for managed services)
2. Managing database user accounts and permissions
3. Physical security of the underlying hardware (AWS responsibility)
4. Configuring Security Groups to control network access
5. Replacing failed storage hardware (AWS responsibility)

References

AWS S3 Data Durability

March 8, 2016 ~ Last updated on : July 4, 2026 ~ jayendrapatil

AWS S3 Data Durability

Amazon S3 provides a highly durable storage infrastructure designed for mission-critical and primary data storage.
S3 is designed to provide 99.999999999% (11 nines) durability of objects over a given year.
S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive redundantly store objects on multiple devices across a minimum of three Availability Zones in an AWS Region.
S3 One Zone-IA stores data redundantly across multiple devices within a single Availability Zone. It still offers 11 nines of durability but may be susceptible to data loss in the unlikely case of the loss or damage to all or part of an AWS Availability Zone.
S3 Express One Zone stores data within a single Availability Zone for high-performance, single-digit millisecond latency access. It is designed for 99.95% availability.
To help ensure data durability, Amazon S3 PUT and PUT Object copy operations synchronously store data across multiple facilities before returning SUCCESS.
Once the objects are stored, Amazon S3 maintains their durability by quickly detecting and repairing any lost redundancy.
Amazon S3 regularly verifies the integrity of data stored using checksums and provides auto-healing capability.
S3 is designed to sustain data in the event of the loss of an entire Availability Zone.

S3 Data Integrity Protections

As of December 2024, Amazon S3 provides default data integrity protections for all new object uploads.
AWS SDKs automatically calculate CRC-based checksums (CRC64NVME by default) for uploads as data is transmitted over the network.
S3 independently verifies these checksums and accepts objects only after confirming data integrity was maintained in transit.
If no checksum is provided on upload, S3 automatically calculates and applies a CRC64NVME checksum as default integrity protection.
S3 continually monitors data durability over time with periodic integrity checks of data at rest.

S3 Storage Classes – Durability & Availability Comparison

Storage Class	Durability	Availability	AZs
S3 Standard	99.999999999% (11 nines)	99.99%	≥ 3
S3 Intelligent-Tiering	99.999999999% (11 nines)	99.9%	≥ 3
S3 Express One Zone	99.999999999% (11 nines)	99.95%	1
S3 Standard-IA	99.999999999% (11 nines)	99.9%	≥ 3
S3 One Zone-IA	99.999999999% (11 nines)	99.5%	1
S3 Glacier Instant Retrieval	99.999999999% (11 nines)	99.9%	≥ 3
S3 Glacier Flexible Retrieval	99.999999999% (11 nines)	99.99%	≥ 3
S3 Glacier Deep Archive	99.999999999% (11 nines)	99.99%	≥ 3

Additional Data Protection Features

S3 Versioning – Preserves, retrieves, and restores every version of every object stored in a bucket, allowing easy recovery from unintended user actions and application failures.
S3 Object Lock – Provides Write Once Read Many (WORM) capability, preventing object deletion or overwriting for a specified retention period.
S3 Replication – Enables automatic, asynchronous copying of objects across S3 buckets in same or different AWS Regions for additional redundancy and compliance.
S3 Multi-Region Access Points – Provides a global endpoint to route requests to the nearest replicated bucket, improving availability across regions.

Key Points for Certification Exams

All S3 storage classes are designed for 99.999999999% (11 nines) durability.
S3 Standard stores data across a minimum of 3 AZs – NOT across regions, NOT in a single facility.
S3 One Zone-IA and S3 Express One Zone store data in a single AZ but still provide 11 nines durability.
One Zone classes may lose data if the entire AZ is lost (fire, flood, etc.) – use for re-creatable data only.
S3 provides both durability (data not lost) and availability (data accessible) – these are different metrics.
S3 automatically detects and repairs lost redundancy (auto-healing).

AWS Certification Exam Practice Questions

Question 1:

A customer is leveraging Amazon Simple Storage Service in eu-west-1 to store static content for a web-based property. The customer is storing objects using the Standard Storage class. Where are the customer’s objects replicated?

Single facility in eu-west-1 and a single facility in eu-central-1
Single facility in eu-west-1 and a single facility in us-east-1
Multiple facilities across a minimum of 3 Availability Zones in eu-west-1
A single facility in eu-west-1

Show Answer

Answer: 3

S3 Standard stores objects redundantly across a minimum of three Availability Zones within the same AWS Region. Objects are NOT replicated across regions by default.

Question 2:

A company wants to store infrequently accessed backup data at the lowest possible cost. The data can be re-created if lost. Which S3 storage class should they use?

S3 Standard
S3 Standard-IA
S3 One Zone-IA
S3 Glacier Deep Archive

Show Answer

Answer: 3

S3 One Zone-IA is the best choice for infrequently accessed, re-creatable data as it costs 20% less than S3 Standard-IA. While it stores data in a single AZ (susceptible to AZ-level disasters), it still provides 11 nines durability and the data can be re-created if lost.

Question 3:

What is the designed durability of Amazon S3?

99.99%
99.999%
99.9999999%
99.999999999%

Show Answer

Answer: 4

Amazon S3 is designed for 99.999999999% (11 nines) durability. This applies to all S3 storage classes. Note that durability (data not lost) is different from availability (data accessible when requested).

Question 4:

Which of the following statements about S3 data integrity are correct? (Choose 2)

S3 automatically calculates and verifies checksums for uploaded objects
S3 encrypts data at rest by default using customer-managed keys
S3 regularly performs integrity checks on stored data and automatically repairs any lost redundancy
S3 replicates data across multiple AWS Regions by default

Answer: 1, 3

S3 provides default data integrity protections with automatic CRC-based checksums on upload (since Dec 2024) and performs periodic integrity checks of data at rest with auto-healing. S3 encrypts at rest with SSE-S3 (AWS-managed keys) by default, not customer-managed keys. Cross-region replication must be explicitly configured.

AWS DDoS Resiliency – Best Practices

📋 Whitepaper Update Notice

AWS DDoS Protection Services

Mitigation Techniques

Minimize the Attack Surface Area

Be Ready to Scale to Absorb the Attack

Safeguard Exposed & Hard-to-Scale Resources

Learn Normal Behavior

Create a Plan for Attacks

DDoS-Resilient Reference Architecture

AWS Certification Exam Practice Questions

References

AWS VPC – Virtual Private Cloud

Subnets

VPC & Subnet Sizing

IP Addresses

Elastic Network Interface (ENI)

Route Tables

VPC Route Server

Internet Gateways – IGW

Egress-only Internet gateway

Shared VPCs

VPC VPN Connections

VPC Security

VPC Flow logs

VPC Block Public Access (BPA)

VPC Encryption Controls

AWS VPC IP Address Manager (IPAM)

Amazon VPC Lattice

AWS Network Firewall

AWS Certification Exam Practice Questions

References

Related Topics

AWS Global Infrastructure

Regions

Recently Launched Regions (2024-2025)

Availability Zones

Edge Locations

CloudFront Embedded Points of Presence (Embedded POPs)

AWS Local Zones

AWS Dedicated Local Zones

AWS Wavelength

AWS Outposts

Second-Generation AWS Outposts Racks (2025)

AWS Certification Exam Practice Questions

Reference

Auto Scaling Overview

Auto Scaling Components

Auto Scaling Groups – ASG

Launch Configuration

⚠️ LAUNCH CONFIGURATION – DEPRECATED

Launch Template

Auto Scaling Launch Configuration vs Launch Template

Auto Scaling Policies

Predictive Scaling

Auto Scaling Cooldown Period

Auto Scaling Termination Policy

Default Termination Policy

Customized Termination Policy

Custom Termination Policy with Lambda

Instance Refresh

Warm Pools

Instance Maintenance Policy

Instance Protection

Standby State

Suspension

Zonal Shift Integration

Strict Availability Zone Balance

Auto Scaling Lifecycle

Autoscaling & ELB

AWS Certification Exam Practice Questions

References

AWS ELB Monitoring

CloudWatch Metrics

Classic Load Balancer (CLB) Metrics

Application Load Balancer (ALB) Metrics

Network Load Balancer (NLB) Metrics

Gateway Load Balancer (GWLB) Metrics

Elastic Load Balancer Access Logs

ALB Access Logs