AWS

Architecting for the Cloud – AWS Best Practices – Whitepaper – Certification

~ Last updated on : ~ jayendrapatil ~ 5 Comments

Architecting for the Cloud – AWS Best Practices

📋 Important Note: Whitepaper Superseded

The original “Architecting for the Cloud: AWS Best Practices” whitepaper (last updated October 2018) has been superseded by the AWS Well-Architected Framework.

The Well-Architected Framework is now organized into six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability (added in 2021). It receives continuous updates — most recently in November 2024 and April 2025.

This post is maintained for certification study purposes as the core architectural principles remain relevant.

Architecting for the Cloud – AWS Best Practices whitepaper provides architectural patterns and advice on how to design systems that are secure, reliable, high performing, and cost efficient

AWS Design Principles

Scalability

  • While AWS provides virtually unlimited on-demand capacity, the architecture should be designed to take advantage of those resources
  • There are two ways to scale an IT architecture
    • Vertical Scaling
      • takes place through increasing specifications of an individual resource for e.g. updating EC2 instance type with increasing RAM, CPU, IOPS, or networking capabilities
      • will eventually hit a limit, and is not always a cost effective or highly available approach
      • AWS Graviton-based instances (Graviton4 as of 2024) offer up to 40% better price-performance, making vertical scaling more cost-effective
    • Horizontal Scaling
      • takes place through increasing number of resources for e.g. adding more EC2 instances or EBS volumes
      • can help leverage the elasticity of cloud computing
      • not all the architectures can be designed to distribute their workload to multiple resources
      • applications designed should be stateless,
        • that needs no knowledge of previous interactions and stores no session information
        • capacity can be increased and decreased, after running tasks have been drained
      • State, if needed, can be implemented using
        • Low latency external store, for e.g. DynamoDB, ElastiCache (Redis or Memcached), to maintain state information
        • Session affinity, for e.g. ELB sticky sessions, to bind all the transactions of a session to a specific compute resource. However, it cannot be guaranteed or take advantage of newly added resources for existing sessions
      • Load can be distributed across multiple resources using
        • Push model, for e.g. through ELB where it distributes the load across multiple EC2 instances
        • Pull model, for e.g. through SQS or Kinesis where multiple consumers subscribe and consume
      • Distributed processing, for e.g. using EMR or Kinesis, helps process large amounts of data by dividing task and its data into many small fragments of works

Disposable Resources Instead of Fixed Servers

  • Resources need to be treated as temporary disposable resources rather than fixed permanent on-premises resources before
  • AWS focuses on the concept of Immutable infrastructure
    • servers once launched, is never updated throughout its lifetime.
    • updates can be performed on a new server with latest configurations,
    • this ensures resources are always in a consistent (and tested) state and easier rollbacks
  • AWS provides multiple ways to instantiate compute resources in an automated and repeatable way
    • Bootstrapping
      • scripts to configure and setup for e.g. using EC2 user data scripts and cloud-init to install software or copy resources and code
    • Golden Images
      • a snapshot of a particular state of that resource,
      • faster start times and removes dependencies to configuration services or third-party repositories
      • EC2 Image Builder can automate creation, testing, and distribution of golden AMIs
    • Containers
      • AWS supports container workloads through Amazon ECS, Amazon EKS, and AWS Fargate (serverless containers)
      • Docker allows packaging a piece of software in a Docker Image, which is a standardized unit for software development, containing everything the software needs to run: code, runtime, system tools, system libraries, etc
      • AWS Fargate provides serverless compute for containers, eliminating the need to manage underlying EC2 instances
  • Infrastructure as Code
    • AWS assets are programmable, techniques, practices, and tools from software development can be applied to make the whole infrastructure reusable, maintainable, extensible, and testable.
    • AWS provides services for IaC deployment:
      • AWS CloudFormation – declarative JSON/YAML templates for provisioning AWS resources
      • AWS CDK (Cloud Development Kit) – define infrastructure using familiar programming languages (TypeScript, Python, Java, Go, C#) that synthesize to CloudFormation
      • AWS SAM (Serverless Application Model) – simplified CloudFormation for serverless applications
    • Note: AWS OpsWorks reached End of Life on May 26, 2024 and is no longer available. Use AWS Systems Manager, CloudFormation, or CDK as alternatives.

Automation

  • AWS provides various automation tools and services which help improve system’s stability, efficiency and time to market.
    • Elastic Beanstalk
      • a PaaS that allows quick application deployment while handling resource provisioning, load balancing, auto scaling, monitoring etc
    • EC2 Auto Recovery
      • creates CloudWatch alarm that monitors an EC2 instance and automatically recovers it if it becomes impaired.
      • A recovered instance is identical to the original instance, including the instance ID, private & Elastic IP addresses, and all instance metadata.
      • Instance is migrated through reboot, in memory contents are lost.
    • Auto Scaling
      • allows maintain application availability and scale the capacity up or down automatically as per defined conditions
      • supports predictive scaling that uses machine learning to forecast traffic and proactively scale capacity
    • CloudWatch Alarms
      • allows SNS triggers to be configured when a particular metric goes beyond a specified threshold for a specified number of periods
    • Amazon EventBridge (formerly CloudWatch Events)
      • allows real-time stream of system events that describe changes in AWS resources
      • extends capabilities with partner event sources, Schema Registry, and EventBridge Pipes for point-to-point integrations
      • EventBridge Scheduler supports one-time and recurring schedules with built-in retry policies
    • AWS Systems Manager
      • provides operational management for AWS resources including patch management, configuration compliance, and automated runbooks
      • replaces the need for OpsWorks with features like State Manager, Automation, and Run Command
    • Lambda Scheduled Events
      • allows Lambda function creation and direct AWS Lambda to execute it on a regular schedule via EventBridge Scheduler.

Loose Coupling

  • AWS helps loose coupled architecture that reduces interdependencies, a change or failure in a component does not cascade to other components
    • Asynchronous Integration
      • does not involve direct point-to-point interaction but usually through an intermediate durable storage layer for e.g. SQS, Kinesis, EventBridge
      • decouples the components and introduces additional resiliency
      • suitable for any interaction that doesn’t need an immediate response and an ack that a request has been registered will suffice
    • Service Discovery
      • allows new resources to be launched or terminated at any point in time and discovered as well for e.g. using ELB as a single point of contact with hiding the underlying instance details or Route 53 zones to abstract load balancer’s endpoint
      • AWS Cloud Map provides service discovery for cloud resources, allowing applications to discover services via API calls, DNS queries, or directly through the SDK
    • Well-Defined Interfaces
      • allows various components to interact with each other through specific, technology agnostic interfaces for e.g. RESTful APIs with API Gateway
      • Amazon API Gateway supports REST APIs, HTTP APIs, and WebSocket APIs for real-time communication

Services, Not Servers

  • AWS encourages leveraging managed services and serverless architectures to reduce operational overhead
    • Serverless compute – AWS Lambda for event-driven functions, AWS Fargate for serverless containers
    • Managed databases – Amazon RDS, DynamoDB, Aurora Serverless for auto-scaling relational databases
    • Application integration – SQS, SNS, EventBridge, Step Functions for workflow orchestration
    • API management – API Gateway for creating, publishing, and managing APIs at scale

Databases

  • AWS provides different categories of database technologies
    • Relational Databases (RDS)
      • normalizes data into well-defined tabular structures known as tables, which consist of rows and columns
      • provide a powerful query language, flexible indexing capabilities, strong integrity controls, and the ability to combine data from multiple tables in a fast and efficient manner
      • allows vertical scalability by increasing resources and horizontal scalability using Read Replicas for read capacity and sharding or data partitioning for write capacity
      • provides High Availability using Multi-AZ deployment, where data is synchronously replicated
      • Amazon Aurora provides MySQL and PostgreSQL-compatible databases with up to 5x and 3x better throughput respectively, with automatic storage scaling up to 128 TB
      • Aurora Serverless v2 scales capacity automatically based on application demand, ideal for variable workloads
    • NoSQL Databases (DynamoDB)
      • provides databases that trade some of the query and transaction capabilities of relational databases for a more flexible data model that seamlessly scales horizontally
      • perform data partitioning and replication to scale both the reads and writes in a horizontal fashion
      • DynamoDB service synchronously replicates data across three facilities in an AWS region to provide fault tolerance in the event of a server failure or Availability Zone disruption
      • DynamoDB Global Tables provide multi-region, active-active replication for globally distributed applications
      • DynamoDB On-Demand mode eliminates capacity planning by automatically scaling to accommodate workloads
    • Data Warehouse (Redshift)
      • Specialized type of relational database, optimized for analysis and reporting of large amounts of data
      • Redshift achieves efficient storage and optimum query performance through a combination of massively parallel processing (MPP), columnar data storage, and targeted data compression encoding schemes
      • Redshift MPP architecture enables increasing performance by increasing the number of nodes in the data warehouse cluster
      • Redshift Serverless automatically provisions and scales capacity, allowing analytics without cluster management
    • Purpose-Built Databases
      • Amazon ElastiCache – in-memory caching (Redis, Memcached) for sub-millisecond latency
      • Amazon Neptune – graph database for highly connected datasets
      • Amazon Timestream – time series database for IoT and operational applications
      • Amazon MemoryDB for Redis – Redis-compatible, durable, in-memory database
  • For more details refer to AWS Storage Options Whitepaper

Removing Single Points of Failure

  • AWS provides ways to implement redundancy, automate recovery and reduce disruption at every layer of the architecture
  • AWS supports redundancy in the following ways
    • Standby Redundancy
      • When a resource fails, functionality is recovered on a secondary resource using a process called failover.
      • Failover will typically require some time before it completes, and during that period the resource remains unavailable.
      • Secondary resource can either be launched automatically only when needed (to reduce cost), or it can be already running idle (to accelerate failover and minimize disruption).
      • Standby redundancy is often used for stateful components such as relational databases.
    • Active Redundancy
      • requests are distributed to multiple redundant compute resources, if one fails, the rest can simply absorb a larger share of the workload.
      • Compared to standby redundancy, it can achieve better utilization and affect a smaller population when there is a failure.
  • AWS supports replication
    • Synchronous replication
      • acknowledges a transaction after it has been durably stored in both the primary location and its replicas.
      • protects data integrity from the event of a primary node failure
      • used to scale read capacity for queries that require the most up-to-date data (strong consistency).
      • compromises performance and availability
    • Asynchronous replication
      • decouples the primary node from its replicas at the expense of introducing replication lag
      • used to horizontally scale the system’s read capacity for queries that can tolerate that replication lag.
    • Quorum-based replication
      • combines synchronous and asynchronous replication to overcome the challenges of large-scale distributed database systems
      • Replication to multiple nodes can be managed by defining a minimum number of nodes that must participate in a successful write operation
  • AWS provide services to reduce or remove single point of failure
    • Regions, Availability Zones with multiple data centers
    • ELB or Route 53 to configure health checks and mask failure by routing traffic to healthy endpoints
    • Auto Scaling to automatically replace unhealthy nodes
    • EC2 auto-recovery to recover unhealthy impaired nodes
    • S3, DynamoDB with data redundantly stored across multiple facilities
    • Multi-AZ RDS, Aurora (6 copies across 3 AZs), and Read Replicas
    • ElastiCache Redis engine supports replication with automatic failover
    • AWS Elastic Disaster Recovery (DRS) for continuous replication and automated recovery of on-premises and cloud-based applications
  • For more details refer to AWS Disaster Recovery Whitepaper

Optimize for Cost

  • AWS can help organizations reduce capital expenses and drive savings as a result of the AWS economies of scale
  • AWS provides different options which should be utilized as per use case –
    • EC2 pricing models:
      • On-Demand – pay per second/hour with no commitment
      • Savings Plans – commit to a consistent amount of usage (measured in $/hr) for 1 or 3 years; Compute Savings Plans (up to 66% savings) and EC2 Instance Savings Plans (up to 72% savings)
      • Reserved Instances – capacity reservation with up to 72% discount for 1 or 3 year terms
      • Spot Instances – up to 90% discount for fault-tolerant, flexible workloads using spare capacity
      • Dedicated Hosts – single-tenant hardware for compliance and BYOL licensing
    • AWS Graviton instances for up to 40% better price-performance over comparable x86 instances
    • AWS Cost Optimization Hub, Trusted Advisor, and AWS Compute Optimizer to identify cost savings opportunities
    • S3 storage classes:
      • S3 Standard – frequently accessed data
      • S3 Intelligent-Tiering – automatic cost optimization for data with unknown or changing access patterns
      • S3 Standard-Infrequent Access (S3 Standard-IA) – infrequently accessed data
      • S3 One Zone-IA – infrequently accessed data not requiring multi-AZ resilience
      • S3 Glacier Instant Retrieval, Flexible Retrieval, and Deep Archive – long-term archive storage
      • S3 Express One Zone – single-digit millisecond latency for most frequently accessed data (up to 10x faster than S3 Standard)
    • EBS volumes – General Purpose SSD (gp3), Provisioned IOPS SSD (io2 Block Express), Throughput Optimized HDD (st1), Cold HDD (sc1). Note: Magnetic (standard) is a previous-generation volume type; gp3 is recommended as default.
    • Cost Allocation tags to identify costs based on tags
    • Auto Scaling to horizontally scale the capacity up or down based on demand
    • Lambda and Fargate based serverless architectures to never pay for idle or redundant resources
    • Utilize managed services where scaling is handled by AWS for e.g. ELB, CloudFront, Kinesis, SQS, Amazon OpenSearch Service etc.

Caching

  • Caching improves application performance and increases the cost efficiency of an implementation
    • Application Data Caching
      • provides services that help store and retrieve information from fast, managed, in-memory caches
      • Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud and supports two open-source in-memory caching engines: Memcached and Redis
      • Amazon DynamoDB Accelerator (DAX) provides a fully managed, in-memory cache for DynamoDB with microsecond response times
    • Edge Caching
      • allows content to be served by infrastructure that is closer to viewers, lowering latency and giving high, sustained data transfer rates needed to deliver large popular objects to end users at scale.
      • Amazon CloudFront is Content Delivery Network (CDN) consisting of 600+ Points of Presence (edge locations and regional caches), that allows copies of static and dynamic content to be cached
      • CloudFront Functions and Lambda@Edge enable running code at edge locations for request/response manipulation

Security

  • AWS works on shared security responsibility model
    • AWS is responsible for the security of the underlying cloud infrastructure
    • you are responsible for securing the workloads you deploy in AWS
  • AWS also provides ample security features
    • IAM to define a granular set of policies and assign them to users, groups, and AWS resources
    • IAM roles to assign short term credentials to resources, which are automatically distributed and rotated
    • AWS IAM Identity Center (formerly AWS SSO) for centralized workforce identity management and single sign-on across AWS accounts and applications
    • Amazon Cognito, for mobile and web applications, which allows client devices to get controlled access to AWS resources via temporary tokens
    • VPC to isolate parts of infrastructure through the use of subnets, security groups, and routing controls
    • AWS WAF to help protect web applications from SQL injection, cross-site scripting, and other common exploits with managed rule groups
    • CloudWatch logs to collect logs centrally as the servers are temporary
    • CloudTrail for auditing AWS API calls, which delivers a log file to S3 bucket. Logs can then be stored in an immutable manner and automatically processed to either notify or even take action on your behalf, protecting your organization from non-compliance
    • AWS Security Hub – unified security posture management that aggregates findings from GuardDuty, Inspector, Macie, and partner tools with automated compliance checks
    • Amazon GuardDuty – intelligent threat detection using machine learning, anomaly detection, and integrated threat intelligence to identify malicious activity
    • Amazon Inspector – automated vulnerability management that continuously scans EC2 instances, container images (ECR), Lambda functions, and code repositories for software vulnerabilities
    • AWS Config for continuous compliance monitoring, and AWS Trusted Advisor for best practice recommendations across cost, performance, security, fault tolerance, and service limits
  • For more details refer to AWS Security Whitepaper

AWS Well-Architected Framework

  • The AWS Well-Architected Framework is the successor to this whitepaper and provides comprehensive guidance for building secure, high-performing, resilient, and efficient infrastructure
  • The Framework is built on six pillars:
    • Operational Excellence – running and monitoring systems to deliver business value and continually improve processes and procedures
    • Security – protecting information and systems through risk assessments, mitigation strategies, and security best practices
    • Reliability – ensuring workloads perform correctly and consistently, with ability to recover from failures and meet demand
    • Performance Efficiency – using computing resources efficiently to meet requirements and maintain efficiency as demand changes
    • Cost Optimization – avoiding unnecessary costs through understanding spending, selecting the right resources, and scaling to meet needs without overspending
    • Sustainability (added 2021) – minimizing environmental impacts by reducing energy consumption and increasing efficiency of cloud workloads
  • The AWS Well-Architected Tool in the AWS Management Console allows workload reviews against framework best practices
  • AWS also provides Well-Architected Lenses for specific workload types (Serverless, SaaS, Machine Learning, Data Analytics, IoT, etc.)

References

 

AWS Pricing – Whitepaper – Certification

~ Last updated on : ~ jayendrapatil

AWS Pricing Overview

📌 Note: This post has been updated to reflect current AWS pricing models, tools, and features as of 2025. The original AWS Pricing Whitepaper (2016) has been superseded by the How AWS Pricing Works whitepaper (last revised December 2024).

AWS pricing features include

  • Pay as you go
    • No minimum contracts/commitments or long-term contracts required
    • Pay only for services you use that can be stopped when not needed
    • Each service is charged independently, providing flexibility to choose services as needed
  • Pay less when you reserve
    • Services like EC2 and RDS provide Reserved Instances, which offer significantly discounted rates (up to 72% off On-Demand)
    • Savings Plans offer flexible commitment-based pricing with up to 72% savings on compute (EC2, Lambda, Fargate) and database usage
  • Pay even less by using more
    • Services like storage and data transfer offer tiered pricing — the more the usage, the less you pay per gigabyte
    • Consolidated billing to consolidate multiple accounts and get tiering benefits across the organization
  • Pay even less as AWS grows
    • AWS works continuously to reduce costs by reducing data center hardware costs, improving operational efficiencies, lowering power consumption, and generally lowering the cost of doing business
    • AWS has announced over 130 price reductions since launch
  • Free services
    • AWS offers many services free of charge including VPC, Elastic Beanstalk, CloudFormation, IAM, Auto Scaling, OpsWorks, and Organizations (Consolidated Billing)
    • Note: While these services are free, resources provisioned by them (e.g., EC2 instances launched via Elastic Beanstalk) are charged at standard rates
  • AWS Free Tier
    • AWS Free Tier for customers to explore AWS services at no cost
    • ⚠️ Updated July 2025: For new accounts created after July 15, 2025, AWS replaced the traditional 12-month Free Tier with a credit-based model offering up to $200 in credits ($100 at sign-up + $100 earned through activities). Customers choose between a Free plan (6 months) and a Paid plan.
    • Existing accounts (created before July 15, 2025) retain the original 12-month Free Tier structure
    • Always Free offerings remain available (e.g., Lambda 1M requests/month, DynamoDB 25GB, CloudWatch 10 metrics)

AWS Pricing & Cost Management Tools

  • AWS Pricing Calculator — the current tool to estimate costs for AWS services. Provides per-service cost breakdown and aggregate monthly/annual estimates. Supports authenticated in-console mode (GA 2025) that incorporates your discounts and commitments.
    • Note: The AWS Simple Monthly Calculator was retired on March 31, 2023. The AWS TCO Calculator has also been retired. Use the AWS Pricing Calculator for all new estimates.
  • AWS Cost Explorer — visualize, understand, and manage AWS costs and usage over time with custom reports, forecasting, and Savings Plans/RI recommendations.
  • AWS Budgets — set custom budgets and receive alerts when costs or usage exceed thresholds.
  • AWS Cost and Usage Reports (CUR) — comprehensive and customizable reporting on AWS costs with granular line-item data.
  • AWS Billing and Cost Management Console — view current charges, account activity, itemized by service and usage type. Previous months’ billing statements are available.

AWS Pricing Fundamental Characteristics

  • AWS basically charges for
    • Compute
    • Storage
    • Data Transfer Out — aggregated across services (EC2, S3, RDS, DynamoDB, etc.) and charged at the outbound data transfer rate
  • AWS does not charge for
    • Inbound data transfer across all AWS services in all regions
    • Outbound data transfer between AWS services within the same region (in most cases)
  • ⚠️ Public IPv4 Address Charges (Effective Feb 1, 2024):
    • All public IPv4 addresses are charged at $0.005 per IP per hour (~$3.65/month), whether attached to a service or not
    • Applies to EC2, RDS, EKS, NAT Gateway, Load Balancers, VPN, and all services with public IPv4
    • Free Tier includes 750 hours of public IPv4 usage per month for the first 12 months
    • BYOIP (Bring Your Own IP) addresses are not charged
    • AWS recommends adopting IPv6 to reduce costs

AWS Savings Plans

Savings Plans are a flexible pricing model offering savings of up to 72% on AWS compute and database usage in exchange for a commitment to a consistent amount of usage (measured in $/hour) for a 1 or 3-year term.

  • Compute Savings Plans
    • Most flexible — automatically applies to EC2, Lambda, and Fargate usage
    • Up to 66% savings regardless of instance family, size, AZ, Region, OS, or tenancy
  • EC2 Instance Savings Plans
    • Up to 72% savings, applies to a specific instance family in a Region
    • Flexible across size, OS, and tenancy within the committed family
  • SageMaker Savings Plans
    • Up to 64% savings on SageMaker usage
  • Database Savings Plans (launched 2024)
    • Applies to RDS, Aurora, Redshift, Neptune, and other database services
    • 1-year term commitment with flexible coverage across database engines and instance types
  • Payment Options: All Upfront (best discount), Partial Upfront, or No Upfront

AWS Elastic Cloud Compute – EC2

EC2 provides resizable compute capacity in the cloud and the cost depends on –

  • Clock Hours of Server Time
    • Resources are charged for the time they are running
    • EC2 uses per-second billing (minimum 60 seconds) for Linux, Windows, and Ubuntu instances. Some commercial OS instances still use hourly billing.
  • Machine Configuration
    • Depends on the physical capacity — pricing varies with the AWS Region, OS, number of cores, memory, and processor architecture
    • AWS Graviton (Arm-based) instances offer up to 40% better price-performance compared to x86 instances
  • Machine Purchase Type
    • On-Demand Instances — pay for compute capacity per second/hour with no commitments
    • Reserved Instances — 1 or 3-year commitment for up to 72% discount (Standard and Convertible types)
    • Savings Plans — flexible commitment-based pricing (Compute or EC2 Instance plans) for up to 72% savings
    • Spot Instances — use spare EC2 capacity at up to 90% discount compared to On-Demand. Instances can be interrupted with 2-minute notice when capacity is needed back.
    • Dedicated Hosts — physical servers dedicated to your use, useful for licensing compliance
    • Capacity Reservations — reserve capacity in a specific AZ without commitment discount
  • Auto Scaling & Number of Instances
    • Auto Scaling automatically adjusts the number of EC2 instances based on demand
    • No additional charge for Auto Scaling — you pay only for the EC2 instances launched
  • Load Balancing
    • Elastic Load Balancing (ELB) distributes traffic among EC2 instances
    • Charged per Load Balancer Capacity Unit (LCU) per hour for ALB/NLB/GWLB, or per hour + data processed for CLB
  • CloudWatch Monitoring
    • Basic monitoring (5-minute intervals) is available at no additional cost
    • Detailed monitoring (1-minute intervals) is charged per metric per month
  • Elastic IP Addresses
    • ⚠️ Updated Feb 2024: All public IPv4 addresses (including Elastic IPs) are now charged at $0.005/hour whether in-use or idle
    • Previously, only unattached Elastic IPs were charged — this is no longer the case
    • Additional Elastic IPs on a running instance continue to be charged at $0.005/hour
  • Operating Systems and Software Packages
    • OS prices are included in the instance prices for Amazon Linux, Ubuntu, Windows, RHEL, SUSE, and other commercial OS options
    • Commercial software from AWS Marketplace incurs additional licensing costs

AWS Lambda

AWS Lambda lets you run code without provisioning or managing servers and the cost depends on

  • Number of Requests
    • Lambda registers a request each time it starts executing in response to an event notification or invoke call
    • Charges are for the total number of requests across all functions
    • Free Tier: 1 million requests per month (always free)
  • Duration
    • Calculated from the time code begins executing until it returns or terminates, rounded up to the nearest 1 millisecond (updated from 100ms in Dec 2020)
    • Price depends on the amount of memory allocated to the function (128 MB to 10,240 MB)
    • Free Tier: 400,000 GB-seconds per month (always free)
  • Processor Architecture
    • Functions running on ARM/Graviton2 architecture get 20% lower duration charges compared to x86, delivering up to 34% better price-performance
  • Tiered Pricing (introduced 2022)
    • Duration charges are tiered — higher usage tiers get lower per-GB-second rates
    • Applied separately for x86 and Arm architectures
  • Provisioned Concurrency
    • Optional feature to keep functions initialized — charged for provisioned concurrency amount plus duration and requests
  • INIT Phase Billing (effective August 1, 2025)
    • AWS standardized billing for the initialization (INIT) phase across all Lambda configurations
    • Previously, INIT phase for ZIP-packaged functions with managed runtimes was unbilled

AWS Simple Storage Service – S3

S3 provides object storage and the cost depends on

  • Storage Class
    • S3 Standard — frequently accessed data; 99.999999999% durability and 99.99% availability
    • S3 Intelligent-Tiering — automatically moves data between access tiers based on usage patterns; no retrieval charges; small monthly monitoring fee per object
    • S3 Express One Zone (launched Nov 2023) — single-digit millisecond latency, up to 10x faster than S3 Standard, 80% lower request costs; single AZ
    • S3 Standard-IA (Infrequent Access) — lower storage cost, retrieval fee applies; 99.9% availability
    • S3 One Zone-IA — lower cost than Standard-IA, stored in a single AZ; 99.5% availability
    • S3 Glacier Instant Retrieval — archive storage with millisecond retrieval
    • S3 Glacier Flexible Retrieval (formerly S3 Glacier) — minutes to hours retrieval
    • S3 Glacier Deep Archive — lowest cost storage with 12-48 hour retrieval
  • Storage
    • Number and size of objects stored and the storage class selected
  • Requests & Data Retrievals
    • Number and type of requests (GET, PUT, COPY, LIST, etc.) — rates vary by request type and storage class
    • Retrieval fees apply for IA and Glacier classes
  • Data Transfer Out
    • Amount of data transferred out of S3 to the internet (tiered pricing)
    • Data transfer from S3 to CloudFront within the same Region is free (since 2024)
  • Management & Analytics
    • S3 Inventory, S3 Analytics, S3 Storage Lens, and Object Tagging have separate charges

AWS Elastic Block Store – EBS

EBS provides block level storage volumes and the cost depends on

  • Volumes
    • EBS provides multiple volume types:
      • General Purpose SSD (gp3, gp2) — gp3 is the latest generation, 20% lower cost per GB than gp2, with independently configurable IOPS and throughput
      • Provisioned IOPS SSD (io2 Block Express, io2, io1) — for I/O-intensive workloads; io2 Block Express supports up to 256,000 IOPS
      • Throughput Optimized HDD (st1) — for frequently accessed, throughput-intensive workloads
      • Cold HDD (sc1) — lowest cost for infrequently accessed data
    • Charged by the amount provisioned in GB per month until released
  • IOPS
    • gp3: 3,000 IOPS and 125 MiB/s included free; additional IOPS/throughput provisioned separately
    • gp2: IOPS scales with volume size (3 IOPS per GB)
    • io1/io2: Charged per provisioned IOPS per month
    • st1/sc1: No IOPS charges
  • Snapshots
    • Snapshots are stored incrementally in S3, charged per GB-month of data stored
    • EBS Snapshots Archive offers up to 75% lower snapshot storage cost for long-term retention
  • Data Transfer Out
    • Outbound data transfer charges are tiered

AWS Relational Database Service – RDS

RDS provides an easy-to-set-up, operate, and scale relational database in the cloud and the cost depends on

  • Clock Hours of Server Time
    • Resources are charged for the time they are running, from DB instance launch until termination
    • Stopped DB instances still incur storage costs (and are automatically restarted after 7 days)
  • Database Characteristics
    • Pricing varies with the database engine (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, or Aurora), instance size, memory class, and processor (x86 vs. Graviton)
    • Graviton-based instances (r6g, r7g, r8g families) offer better price-performance than x86 equivalents
  • Database Purchase Type
    • On-Demand — pay per hour/second with no commitment
    • Reserved Instances — 1 or 3-year term for significant discounts
    • Database Savings Plans (launched 2024) — flexible commitment-based pricing across RDS, Aurora, Redshift, and Neptune
    • Aurora Serverless — pay per Aurora Capacity Unit (ACU) per second; scales to zero when idle
  • Provisioned Storage
    • Backup storage of up to 100% of provisioned database storage for an active DB Instance is not charged
    • After termination, backup storage is billed per GB per month
  • Additional Storage
    • Backup storage exceeding the free allocation is billed per GB per month
  • Requests (I/O)
    • Number of input and output requests to the database
    • Aurora I/O-Optimized configuration eliminates I/O charges in exchange for ~30% higher compute/storage cost
  • Deployment Type
    • Multi-AZ deployments cost approximately 2x Single-AZ for high availability
    • Multi-AZ with readable standbys (2 replicas) available for Aurora and RDS
  • Data Transfer Out
    • Outbound data transfer costs are tiered
    • Inbound data transfer is free
    • Data transfer between RDS and EC2 in the same AZ is free

AWS CloudFront

CloudFront is a web service for content delivery, distributing content to end users with low latency and high data transfer speeds with no minimum commitments.

  • Traffic Distribution
    • Data transfer and request pricing vary across geographic regions, based on the edge location through which content is served
  • Requests
    • Number and type of requests (HTTP or HTTPS) and the geographic region
  • Data Transfer Out
    • Amount of data transferred out of CloudFront edge locations to the internet
    • Data transfer from S3 origin to CloudFront is free (within the same Region)
  • Flat-Rate Pricing Plans (launched Nov 2025)
    • Fixed monthly fee bundling data transfer, requests, AWS WAF, Shield, DNS (Route 53), logging, and serverless edge compute
    • Includes monthly S3 storage credits
    • No overage charges — predictable pricing for website delivery and security
  • CloudFront Security Savings Bundle
    • Up to 30% savings on CloudFront charges in exchange for a monthly commit (1-year term)
    • Includes AWS WAF charges covered within the commitment

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. How does AWS charge for AWS Lambda?
    1. Users bid on the maximum price they are willing to pay per hour.
    2. Users choose a 1-, 3- or 5-year upfront payment term.
    3. Users pay for the required permanent storage on a file system or in a database.
    4. Users pay based on the number of requests and consumed compute resources.
  2. Which AWS pricing model provides the MOST flexibility without long-term commitment?
    1. Reserved Instances
    2. Savings Plans
    3. On-Demand
    4. Spot Instances
  3. Which tool should be used to estimate costs for a new AWS architecture?
    1. AWS Simple Monthly Calculator
    2. AWS Pricing Calculator
    3. AWS Cost Explorer
    4. AWS Budgets

    Note: The Simple Monthly Calculator was retired in March 2023. AWS Pricing Calculator is the current tool.

  4. Starting February 2024, which statement about AWS public IPv4 addresses is correct?
    1. Only idle Elastic IP addresses are charged
    2. All public IPv4 addresses are charged at $0.005/hour whether in-use or idle
    3. Public IPv4 addresses are free for the first 12 months only
    4. Only addresses not associated with EC2 instances are charged
  5. Which AWS Savings Plan type offers the MOST flexibility?
    1. EC2 Instance Savings Plans
    2. Compute Savings Plans
    3. SageMaker Savings Plans
    4. Database Savings Plans

    Explanation: Compute Savings Plans automatically apply across EC2, Lambda, and Fargate regardless of instance family, size, Region, or OS.

  6. A company wants to reduce EC2 costs by up to 90% but can tolerate interruptions. Which purchase option should they use?
    1. Reserved Instances
    2. On-Demand Instances
    3. Spot Instances
    4. Savings Plans
  7. Which S3 storage class automatically moves objects between access tiers to optimize costs?
    1. S3 Standard
    2. S3 Standard-IA
    3. S3 Intelligent-Tiering
    4. S3 Glacier Flexible Retrieval

References

AWS EC2 Container Service – ECS

~ Last updated on : ~ jayendrapatil ~ 8 Comments

AWS ECS – Elastic Container Service

  • AWS Elastic Container Service (ECS) is a fully managed, highly scalable container orchestration service that supports Docker containers and allows running applications on a managed cluster of EC2 instances, serverless with AWS Fargate, or on-premises with ECS Anywhere.
  • ECS
    • is a regional service that simplifies running application containers in a highly available manner across multiple AZs within a region.
    • eliminates the need to install, operate, and scale the cluster management infrastructure.
    • helps schedule the placement of containers across the cluster based on the resource needs and availability requirements.
    • allows the integration of your own custom scheduler or third-party schedulers to meet business or application specific requirements.
    • provides a serverless option with AWS Fargate.
    • provides a fully managed EC2 option with ECS Managed Instances (launched Sept 2025).
    • supports running containers on on-premises infrastructure with ECS Anywhere.
    • integrates with Service Connect for simplified service-to-service communication.

ECS Launch Types & Capacity Providers

  • ECS supports four launch types/capacity providers: EC2, Fargate, ECS Managed Instances, and External (ECS Anywhere).

EC2 Launch Type

  • EC2 launch type – Configure and deploy EC2 instances in your cluster to run your containers.
  • Provides full control over instance types, placement, scaling, and patching.
  • EC2 launch type is suitable for the following workloads:
    • Workloads that require consistently high CPU core and memory usage
    • Large workloads that need to be optimized for price
    • Applications need to access persistent storage
    • You must directly manage your infrastructure
    • Workloads requiring GPU or specialized instance types
  • Uses Capacity Providers with Auto Scaling Groups for automatic scaling.
  • Supports managed instance draining (2024) to safely drain tasks from EC2 instances being terminated.

ECS Overview Standard

AWS Fargate Launch Type

  • AWS Fargate is a technology that provides a serverless pay-as-you-go option with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances.
  • With AWS Fargate, there is no need to provision, configure, or scale clusters of virtual machines to run containers and also removes the need to choose server types, decide when to scale the clusters or optimize cluster packing.
  • Fargate now supports up to 32 vCPUs and 244 GiB of memory per task (June 2026), significantly expanding from the previous 16 vCPU limit.
  • Supports ephemeral storage up to 200 GiB per task (20 GiB free by default).
  • Supports Amazon EBS volume attachments for high-throughput and data-intensive workloads (2024).
  • Supports ARM-based AWS Graviton processors for better price-performance.
  • Fargate launch type is suitable for the following workloads:
    • Large workloads that need to be optimized for low overhead
    • Small workloads that have an occasional burst
    • Tiny workloads
    • Batch workloads
    • Workloads where you want zero infrastructure management
  • Fargate Platform Version 1.3.0 retired as of June 15, 2026. New tasks cannot use this version. Platform version 1.4.0 or LATEST should be used.
  • Supports weekly event windows to schedule task retirements during non-peak hours (Dec 2025).

ECS Overview

ECS Managed Instances (New – Sept 2025)

  • ECS Managed Instances is a fully managed compute option that combines the operational simplicity of Fargate with the flexibility and control of Amazon EC2.
  • ECS provisions, patches, and replaces instances automatically while providing visibility and control over instance type selection.
  • Key features:
    • Fully managed: AWS handles provisioning, patching, and replacement of EC2 instances.
    • Instance type flexibility: Choose specific instance types or let ECS select optimal types.
    • Visibility: Instances are visible in your AWS account.
    • Cost optimization: Pay for the entire instance plus a management fee (can be more cost-effective than Fargate for steady workloads).
    • Supports EC2 Spot Instances for up to 90% discount (Dec 2025).
    • Supports AWS Trainium and Inferentia accelerators for AI/ML workloads (June 2026).
  • Suitable for workloads that:
    • Need GPU or specialized hardware not available on Fargate
    • Require privileged containers
    • Need more than Fargate’s memory ceiling
    • Want managed infrastructure but need EC2-level flexibility

External Launch Type (ECS Anywhere)

  • ECS Anywhere allows running and managing containers on on-premises servers or virtual machines using the same ECS APIs and tooling.
  • Register external instances to your ECS cluster using AWS Systems Manager (SSM).
  • Uses the EXTERNAL launch type for tasks and services.
  • Suitable for:
    • Hybrid cloud deployments
    • Workloads with data residency requirements
    • Edge computing and latency-sensitive applications
    • Consistent container management across cloud and on-premises

ECS Express Mode (New – Nov 2025)

  • ECS Express Mode enables developers to rapidly launch containerized applications with minimal configuration.
  • Automates infrastructure setup including domains, networking, load balancing, and auto scaling using AWS best practices.
  • Requires only three inputs: a container image, a task execution role, and an infrastructure role.
  • Automatically consolidates up to 25 services behind a single Application Load Balancer using intelligent rule-based routing.
  • All provisioned resources remain fully accessible in your account for complete control and flexibility.
  • No additional charge for using Express Mode (only pay for underlying AWS resources).
  • Available in AWS GovCloud (US) Regions (June 2026).

ECS Components

Containers and Images

  • Applications deployed on ECS must be architected to run in Docker containers, which is a standardized unit of software development, containing everything that the software application needs to run: code, runtime, system tools, system libraries, etc.
  • Containers are created from a read-only template called an image.
  • Images are typically built from a Dockerfile and stored in a registry from which they can be downloaded and run on the container instances.
  • ECS can be configured to access a private Docker image registry within a VPC, Docker Hub, or is integrated with Amazon Elastic Container Registry (ECR).
  • ECR supports up to 100,000 images per repository and 100,000 repositories per region.
  • ECR supports pull through cache to automatically sync images from upstream registries (Docker Hub, GitHub, etc.).
  • ECR supports automatic repository creation on push (Dec 2025).

Clusters

  • An ECS cluster is a logical grouping of tasks and services, and the infrastructure capacity (EC2 instances, Fargate, Managed Instances, or External instances).
  • ECS downloads the container images from the specified registry and runs those images within your cluster.
  • A cluster can use a mix of capacity providers (e.g., Fargate for some services, Managed Instances for others).

Task Definitions

  • Task definition is a description of an application that contains one or more docker containers.
  • Task definition is needed to prepare an application to run on ECS.
  • Task definition is a text file in JSON format that describes one or more containers that form your application.
  • Task definitions specify various parameters for the application, such as containers to use, their repositories, ports to be opened, and data volumes.
  • Task Execution Role is used by the ECS agent and container runtime to prepare the containers to run (e.g., pull images from ECR, manage logs). It is not used by the task itself.
  • Task Role grants additional AWS permissions that are assumed by the containers running in the task.
  • Network mode specifies the Docker networking mode: none, bridge, awsvpc, and host.
    • awsvpc mode is required for Fargate and gives each task its own ENI and private IP.
  • Task definitions support specifying Amazon EBS volumes for persistent, high-performance block storage.
  • Task definitions support specifying Amazon EFS volumes for shared, scalable file storage across tasks.

Tasks and Scheduling

  • A task is the instantiation of a task definition on a container instance within the cluster.
  • After a task definition is created for the application within ECS, you can specify the number of tasks that will run on the cluster.
  • ECS task scheduler is responsible for placing tasks on container instances, with several different scheduling options available.

Services

ECS Deployment Strategies

  • ECS supports four deployment strategies:
    • Rolling Update (default) – New tasks are created as old ones are stopped, keeping capacity roughly constant.
    • Blue/Green Deployment – Runs two full sets of tasks in parallel. Production traffic is shifted to the new (green) revision after validation.
    • Canary Deployment (Oct 2025) – Routes a small percentage of traffic (typically 5-10%) to the new revision with a bake time for monitoring before shifting remaining traffic.
    • Linear Deployment (Oct 2025) – Shifts traffic in equal increments with a bake time between each shift.
  • Blue/green, canary, and linear strategies require ALB, NLB, or Service Connect.
  • Built-in canary and linear deployments achieve feature parity with AWS CodeDeploy, eliminating the need for an external deployment controller.

ECS Service Connect

  • Service Connect provides simplified service-to-service communication with built-in service discovery and service mesh capabilities.
  • Uses a managed Envoy sidecar proxy automatically injected into ECS tasks.
  • Proxies handle routing decisions, retries, and metrics collection, while AWS Cloud Map provides the service registry backend.
  • Allows services to use short names and standard ports to connect across clusters and VPCs in the same Region.
  • Provides standardized metrics and logs for all service-to-service traffic without code changes.
  • Integrates with blue/green, linear, and canary deployment strategies for traffic management during deployments.

Container Agent

  • Container agent runs on each EC2 instance within an ECS cluster.
  • Container Agent sends information about the instance’s current running tasks and resource utilization to ECS, and starts and stops tasks whenever it receives a request from ECS.
  • Not required for Fargate tasks (managed by AWS).

ECS Security

  • GuardDuty Runtime Monitoring – Uses a lightweight security agent to monitor ECS workloads for unauthorized activity, process execution, and network connections.
  • GuardDuty Extended Threat Detection (Dec 2025) – Analyzes multiple security signals across network, runtime behavior, and API activity to detect sophisticated attack patterns for EC2 and ECS.
  • ECS Exec – Allows interactive shell access to running containers for debugging (uses AWS Systems Manager Session Manager).
  • Task-level IAM roles – Each task can have its own IAM role following least privilege principles.
  • Secrets management – Integration with AWS Secrets Manager and SSM Parameter Store for injecting secrets into containers.

ECS Auto Scaling

  • Service Auto Scaling – Automatically adjusts the desired task count based on CloudWatch metrics (target tracking, step scaling).
  • Predictive Scaling (2024) – Uses machine learning to predict future traffic and pre-scales tasks before demand increases.
  • Cluster Auto Scaling – Automatically manages EC2 instance capacity using capacity providers.
  • Supports updating capacity provider configuration for existing services without recreating them (May 2025).

ECS Storage Options

  • Ephemeral Storage – Up to 200 GiB per Fargate task (20 GiB free). Non-persistent, deleted when task stops.
  • Amazon EBS Volumes (2024) – Attach EBS volumes to ECS tasks for high-throughput, data-intensive workloads. One volume per task, configurable size/type/IOPS. Supports creating from snapshots.
  • Amazon EFS Volumes – Shared, persistent file storage accessible by multiple tasks simultaneously. Supports encryption in transit and at rest.
  • Bind Mounts – Share data between containers within the same task.
  • Docker Volumes – EC2 launch type supports Docker volume drivers for third-party storage plugins.

ECS vs Elastic Beanstalk

  • ECS helps in having a more fine-grained control for custom application architectures.
  • Elastic Beanstalk is ideal to leverage the benefits of containers but just want the simplicity of deploying applications from development to production by uploading a container image.
  • Elastic Beanstalk is more of an application management platform that helps customers easily deploy and scale web applications and services.
  • With Elastic Beanstalk, specify container images to be deployed, with the CPU & memory requirements, port mappings and container links.
  • Elastic Beanstalk abstracts the finer details and automatically handles all the details such as provisioning an ECS cluster, balancing load, auto-scaling, monitoring, and placing the containers across the cluster.

ECS vs Lambda

  • ECS is a fully managed container orchestration service that allows running and managing distributed applications in Docker containers with multiple compute options (Fargate, EC2, Managed Instances).
  • AWS Lambda is an event-driven task compute service that runs code (Lambda functions) in response to “events” from event sources like SES, SNS, DynamoDB & Kinesis Streams, CloudWatch etc.
  • ECS is better suited for long-running applications, microservices with consistent traffic, and workloads requiring more than 15 minutes execution time.
  • Lambda is better for short-lived, event-driven workloads with unpredictable traffic patterns.

ECS vs EKS

  • Both ECS and EKS are container orchestration services, but use different orchestration engines.
  • ECS uses AWS-native orchestration, making it simpler to operate with deep AWS integration.
  • EKS uses Kubernetes, providing portability across cloud providers and on-premises environments.
  • Both support Fargate as a serverless compute option.
  • Choose ECS for simpler AWS-native workloads; choose EKS for Kubernetes ecosystem compatibility or multi-cloud portability.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You need a solution to distribute traffic evenly across all of the containers for a task running on Amazon ECS. Your task definitions define dynamic host port mapping for your containers. What AWS feature provides this functionality?
    1. Application Load Balancers support dynamic host port mapping.
    2. CloudFront custom origins support dynamic host port mapping.
    3. All Elastic Load Balancing instances support dynamic host port mapping.
    4. Classic Load Balancers support dynamic host port mapping.
  2. Your security team requires each Amazon ECS task to have an IAM policy that limits the task’s privileges to only those required for its use of AWS services. How can you achieve this?
    1. Use IAM roles for Amazon ECS tasks to associate a specific IAM role with each ECS task definition
    2. Use IAM roles on the Amazon ECS container instances to associate IAM role with each ECS task on that instance
    3. Connect to each running amazon ECS container instance and add discrete credentials
    4. Reboot each Amazon ECS task programmatically to generate new instance metadata for each task
  3. A company wants to run containers on AWS without managing servers but needs to select specific instance types for GPU workloads. Which ECS compute option provides fully managed infrastructure with instance type selection?
    1. EC2 Launch Type with Auto Scaling
    2. AWS Fargate
    3. ECS Managed Instances
    4. ECS Anywhere
  4. A development team wants to deploy a containerized web application on ECS with minimal configuration. They only want to provide a container image and have AWS handle networking, load balancing, and auto scaling. Which ECS feature should they use?
    1. ECS Service with Fargate
    2. ECS Express Mode
    3. ECS Managed Instances
    4. AWS App Runner
  5. A company is deploying a critical microservices update on ECS and wants to route only 5% of traffic to the new version initially, monitor it, then shift remaining traffic. Which deployment strategy should they use?
    1. Rolling update
    2. Blue/Green deployment
    3. Canary deployment
    4. Linear deployment
  6. An organization needs to run ECS tasks on their on-premises servers while managing them from the AWS console. Which ECS feature supports this? [Select TWO]
    1. ECS Anywhere
    2. AWS Fargate
    3. ECS Managed Instances
    4. External launch type
    5. EC2 launch type
  7. A data engineering team needs to attach high-performance block storage to their ECS Fargate tasks for an ETL workload that processes large datasets. Which storage option should they choose?
    1. Increase ephemeral storage to 200 GiB
    2. Attach Amazon EBS volumes to ECS tasks
    3. Use Amazon EFS volumes
    4. Use Docker volumes with a storage plugin
  8. Which ECS feature provides service-to-service communication with built-in service discovery, traffic management during deployments, and standardized metrics without code changes?
    1. AWS Cloud Map
    2. Application Load Balancer
    3. ECS Service Connect
    4. AWS App Mesh

References

AWS Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

~ Last updated on : ~ jayendrapatil ~ 16 Comments

AWS Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

📌 Post Updated: June 2026 — Added Gateway Load Balancer (GWLB), NLB Security Groups support, ALB Mutual TLS, NLB QUIC protocol, ALB JWT verification, ALB Target Optimizer, LCU Reservation, Post-Quantum TLS, and updated EC2-Classic retirement status.

  • Elastic Load Balancing supports four types of load balancers:
    • Classic Load Balancer – CLB (Previous Generation)
    • Application Load Balancer – ALB
    • Network Load Balancer – NLB
    • Gateway Load Balancer – GWLB
  • While there is some overlap in the features, AWS does not maintain feature parity between the different types of load balancers.

⚠️ Classic Load Balancer – Previous Generation

Classic Load Balancer is the previous generation load balancer. AWS recommends using Application Load Balancer for Layer 7 and Network Load Balancer for Layer 4. CLB was originally designed for the EC2-Classic network, which was fully retired in August 2023. While CLB continues to function in VPC, no new features are being added to it.

Migration: Use the AWS Migration Wizard to migrate existing CLBs to ALB or NLB. See Migrate your Classic Load Balancer.

CLB vs ALB vs NLB General

Usage Patterns

  • Classic Load Balancer (Previous Generation)
    • provides basic load balancing across multiple EC2 instances and operates at both the request level and connection level.
    • is intended for applications that were built within the EC2-Classic network. EC2-Classic was fully retired in August 2023.
    • is ideal for simple load balancing of traffic across multiple EC2 instances.
    • AWS recommends migrating to ALB or NLB for all new workloads.
  • Application Load Balancer
    • is ideal for microservices or container-based architectures where there is a need to route traffic to multiple services or load balance across multiple ports on the same EC2 instance.
    • operates at the request level (layer 7), routing traffic to targets – EC2 instances, containers, IP addresses, and Lambda functions based on the content of the request.
    • is ideal for advanced load balancing of HTTP and HTTPS traffic, and provides advanced request routing targeted at delivery of modern application architectures, including microservices and container-based applications.
    • simplifies and improves the security of the application, by ensuring that the latest SSL/TLS ciphers and protocols are used at all times.
    • supports Mutual TLS (mTLS) authentication to verify client certificate-based identities.
    • supports native JWT (JSON Web Token) verification for secure service-to-service authentication.
  • Network Load Balancer
    • operates at the connection level (Layer 4), routing connections to targets – EC2 instances, microservices, and containers – within VPC based on IP protocol data.
    • is ideal for load balancing of TCP, UDP, TLS, and QUIC traffic.
    • is capable of handling millions of requests per second while maintaining ultra-low latencies.
    • is optimized to handle sudden and volatile traffic patterns while using a single static IP address per AZ
    • is integrated with other popular AWS services such as Auto Scaling, ECS, CloudFormation, and AWS Certificate Manager (ACM).
    • now supports security groups (since August 2023) for centralized access control.
    • supports QUIC protocol in passthrough mode (since November 2025) for low-latency mobile and real-time applications.
  • Gateway Load Balancer
    • operates at Layer 3 (network layer), providing a transparent network gateway and distributing traffic to virtual appliances.
    • is ideal for deploying, scaling, and managing third-party virtual appliances such as firewalls, intrusion detection/prevention systems (IDS/IPS), and deep packet inspection systems.
    • combines a transparent network gateway (single entry and exit point for all traffic) with load balancing of virtual appliances.
    • uses the GENEVE protocol on port 6081 to exchange traffic with registered virtual appliance instances.
    • maintains flow stickiness using 5-tuple (default), 3-tuple, or 2-tuple.
  • AWS recommends using Application Load Balancer for Layer 7 and Network Load Balancer for Layer 4 when using VPC.

AWS ELB Classic Load Balancer vs Application Load Balancer
Supported Protocols

  • Classic ELB operates at layer 4 and supports HTTP, HTTPS, TCP, SSL
  • ALB operates at layer 7 and supports HTTP, HTTPS, HTTP/2, gRPC, WebSockets
  • NLB operates at the connection level (Layer 4) and supports TCP, UDP, TLS, QUIC, TCP_QUIC
  • GWLB operates at Layer 3 and listens for all IP packets across all ports

Load Balancing to Multiple Ports on the same instance

  • ALB, NLB, and GWLB support Load Balancing to multiple ports on the same instance
  • CLB does not support load balancing to multiple ports on the same instance

Host-based Routing & Path-based Routing

  • Host-based routing use host conditions to define rules that forward requests to different target groups based on the hostname in the host header. This enables ALB to support multiple domains using a single load balancer.
  • Path-based routing use path conditions to define rules that forward requests to different target groups based on the URL in the request. Each path condition has one path pattern. If the URL in a request matches the path pattern in a listener rule exactly, the request is routed using that rule.
  • Only ALB supports Host-based & Path-based routing.

URL and Host Header Rewrite (ALB – New 2025)

  • ALB now supports URL and Host Header rewrite capabilities (October 2025).
  • Enables modification of request URLs and Host Headers using regex-based pattern matching before routing requests to targets.
  • Useful for URL normalization, path rewriting, and host header transformation without application code changes.
  • Only ALB supports URL and Host Header Rewrite.

CLB vs ALB vs NLB Common configurations and Features

Slow Start

  • By default, a target starts to receive its full share of requests as soon as it is registered with a target group and passes an initial health check.
  • Using slow start mode gives targets time to warm up before the load balancer sends them a full share of requests.
  • Only ALB supports slow start mode

Target Optimizer (ALB – New 2025)

  • ALB Target Optimizer (November 2025) allows you to enforce a maximum number of concurrent requests on a target.
  • Uses an agent installed on each target that tracks concurrent requests and signals the ALB when capacity is available.
  • Enables high-efficiency load balanced applications while maintaining low latency and high availability.
  • Returns 503 errors during overload rather than overwhelming targets.
  • Only ALB supports Target Optimizer.

Static IP and Elastic IP Address

  • NLB automatically provides a static IP per AZ (subnet) that can be used by applications as the front-end IP of the load balancer.
  • NLB also allows the option to assign an Elastic IP per AZ (subnet) thereby providing your own fixed IP.
  • Classic ELB, ALB, and GWLB do not support Static and Elastic IP address

Connection Draining OR Deregistration Delay

  • Connection draining enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy.
  • All Load Balancer types (CLB, ALB, NLB, GWLB) support connection draining/deregistration delay.

Idle Connection Timeout

  • Idle Connection Timeout helps specify a time period, which ELB uses to close the connection if no data has been sent or received by the time that the idle timeout period elapses
  • Can be configured for CLB & ALB (default 60 seconds)
  • Cannot be configured for NLB (350 secs for TCP, 120 secs for UDP)
  • GWLB supports configurable TCP idle timeout (60 to 6000 seconds, since September 2024)
  • It is recommended to enable HTTP keep-alive in the web server settings for the EC2 instances, thus making the ELB reuse the backend connections until the keep-alive timeout expires.

PrivateLink Support

  • CLB and ALB do not support PrivateLink
  • NLB supports PrivateLink (TCP, TLS, UDP)
  • GWLB supports PrivateLink via Gateway Load Balancer Endpoints (GWLBE)

Zonal Isolation

  • NLB and GWLB support Zonal Isolation which supports application architectures in a single zone. It automatically fails over to other healthy AZs, if something fails in an AZ
  • CLB and ALB do not support Zonal Isolation.
  • NLB supports Zonal DNS Affinity (since October 2023), allowing clients to resolve the load balancer DNS to an IP in their same AZ.

Deletion Protection

  • ALB, NLB, and GWLB support Deletion Protection, wherein a load balancer can’t be deleted if deletion protection is enabled
  • CLB does not support deletion protection.

Preserve Source IP address

  • As the ELB intercepts the traffic between the client and the back-end servers, the back-end server does not know the IP address, Protocol, and the Port used between the Client and the Load balancer.
  • Classic ELB (HTTP/HTTPS) and ALB do not preserve the client-side source IP. It needs to be retrieved using X-Forward-XXX.
    • X-Forwarded-For request header to help back-end servers identify the IP address of a client when you use an HTTP or HTTPS load balancer.
    • X-Forwarded-Proto request header to help back-end servers identify the protocol (HTTP/S) that a client used to connect to the server
    • X-Forwarded-Port request header to help back-end servers identify the port that an HTTP or HTTPS load balancer uses to connect to the client.
  • CLB (SSL/TLS) uses Proxy Protocol Version 1 and NLB uses Proxy Protocol Version 2 to provide the information.
  • NLB preserves the client-side source IP or needs Proxy Protocol allowing the back-end to see the IP address of the client.
    • If targets are registered by instance ID or ECS tasks, the source IP addresses of the clients are preserved and provided to the applications.
    • If targets are registered by IP address
      • for TCP & TLS, the source IP addresses are the private IP addresses of the load balancer nodes. Use Proxy Protocol.
      • for UDP & TCP_UDP, it is enabled by default and the source IP addresses of the clients are preserved.
  • GWLB preserves the source IP address as it operates as a transparent bump-in-the-wire.

Health Checks

  • All Load Balancer types support Health checks to determine if the instance is healthy or unhealthy
  • ALB provides health check improvements that allow detailed error codes from 200-399 to be configured
  • ALB supports HTTP, HTTPS, and gRPC health checks
  • NLB and GWLB support TCP, HTTP, and HTTPS health checks
  • CLB supports TCP, SSL/TLS, HTTP, and HTTPS health checks

Security Groups

  • ALB, NLB, and CLB support security groups
  • NLB added security group support in August 2023, enabling centralized access control and inbound rule enforcement
  • GWLB does not support security groups
  • Note: NLB security groups must be associated at creation time; they cannot be added to an existing NLB that was created without them.

Supported Platforms

  • Classic ELB supports both EC2-Classic and EC2-VPC — EC2-Classic was fully retired in August 2023. All load balancers now operate in VPC only.
  • ALB, NLB, and GWLB support only EC2-VPC.
  • CLB now effectively operates only in VPC (EC2-Classic no longer exists).

WebSockets

  • CLB does not support WebSockets
  • ALB, NLB, and GWLB support WebSockets

Cross-zone Load Balancing

  • By default, Load Balancer will distribute requests evenly across its enabled AZs, irrespective of the instances it hosts.
  • Cross-zone Load Balancing help distribute incoming requests evenly across all instances in its enabled AZs.
  • CLB → Cross Zone load balancing is disabled, by default, and can be enabled and free of charge.
  • ALB → Cross Zone load balancing is always enabled at the load balancer level, but can be turned off at the target group level (since November 2022). Free of charge.
  • NLB → Cross Zone load balancing is disabled, by default, and can be enabled but is charged for inter-az data transfer.
  • GWLB → Cross Zone load balancing is disabled, by default, and can be enabled.
  • Zonal Shift & Autoshift: Both ALB and NLB (with cross-zone enabled) now support zonal shift and zonal autoshift (2024) to move traffic away from an impaired AZ.

Sticky Sessions (Cookies)

  • Sticky Sessions (Session Affinity) enables the load balancer to bind a user’s session to a specific instance, which ensures that all requests from the user during the session are sent to the same instance
  • CLB, ALB, and NLB support sticky sessions to maintain session affinity
  • CLB and ALB maintain session stickiness using cookies.
  • NLB supports sticky sessions using a built-in 5-tuple hash table to maintain stickiness across backend servers.
  • NLB idle timeout for TCP connections is 350 seconds. Once the timeout is reached or the session is terminated, the NLB will forget the stickiness and incoming packets will be considered as a new flow and could be load balanced to a new target.
  • NLB QUIC protocol uses QUIC Connection IDs for session stickiness, which is resilient to client IP/NAT changes.

CLB vs ALB vs NLB Security

SSL Termination/Offloading

  • SSL Termination helps decrypt requests from clients before sending them to targets and hence reducing the load. SSL certificate must be installed on the load balancer.
  • CLB, ALB, and NLB support SSL Termination.
  • GWLB does not support SSL offloading (operates at Layer 3).
  • ALB and NLB now support Post-Quantum Key Exchange for TLS (November 2025), using hybrid post-quantum key agreement with ML-KEM algorithm for quantum-resistant encryption.

Mutual TLS (mTLS) Authentication (ALB – New 2023)

  • Mutual TLS extends standard TLS by requiring clients to present X.509 certificates for authentication.
  • ALB can authenticate client certificates from third-party Certificate Authorities or AWS Private Certificate Authority (PCA).
  • Supports certificate revocation checks to restrict access for compromised certificates.
  • Offloads client authentication to the load balancer, eliminating the need for custom authentication in applications.
  • Only ALB supports Mutual TLS authentication.

JWT Verification (ALB – New 2025)

  • ALB now supports native JSON Web Token (JWT) verification (November 2025) for secure service-to-service (S2S) or machine-to-machine (M2M) communications.
  • Validates token signatures, expiration times, and claims without requiring application code changes.
  • Useful for OAuth 2.0 client credentials flow.
  • Only ALB supports native JWT verification.

Server Name Indication

  • CLB only supports a single certificate and does not support SNI
  • ALB and NLB support multiple certificates and use SNI to serve multiple secure websites using a single TLS listener.
    • If the hostname provided by a client matches a single certificate in the certificate list, the load balancer selects this certificate.
    • If a hostname provided by a client matches multiple certificates in the certificate list, the load balancer selects the best certificate that the client can support.

Back-end Server Authentication

  • Back-end Server Authentication enables authentication of the instances.
  • Load balancer communicates with an instance only if the public key that the instance presents to the load balancer matches a public key in the authentication policy for the load balancer.
  • Classic Load Balancer supports Back-end Server Authentication
  • ALB does not support Back-end Server Authentication

Capacity Unit Reservation (New 2024)

  • ALB and NLB support Load Balancer Capacity Unit (LCU) Reservation (November 2024).
  • Allows proactively setting a minimum capacity for the load balancer to prepare for planned traffic spikes.
  • Complements existing auto-scaling, useful for product launches, sales events, or traffic migrations.
  • GWLB added LCU Reservation support in April 2025.
  • ALB, NLB, and GWLB support LCU Reservation.
  • CLB does not support LCU Reservation.

Weighted Target Groups (NLB – New 2025)

  • NLB now supports weighted target groups (November 2025).
  • Allows distributing traffic across multiple target groups with configurable static weights.
  • Enables blue/green and canary deployment strategies with zero downtime without needing multiple load balancers.
  • ALB has long supported weighted target groups via listener rules; NLB now supports this natively.

CloudWatch Metrics

  • All Load Balancer types integrate with CloudWatch to provide metrics, with ALB providing additional metrics
  • ALB and CLB report request counts, error counts, error types, and request latency
  • NLB and GWLB report Active Flow Count, New Flow Count, and Processed Bytes

Access Logs

  • Access logs capture detailed information about requests sent to the load balancer. Each log contains information such as request received time, client’s IP address, latencies, request paths, and server responses
  • All Load Balancer types provide access logs, with ALB providing additional attributes

Gateway Load Balancer (GWLB)

  • Operates at Layer 3 (network layer) as a transparent network gateway combined with load balancing.
  • Designed for deploying, scaling, and managing third-party virtual appliances (firewalls, IDS/IPS, deep packet inspection).
  • Provides a single entry and exit point for all traffic, distributing it to virtual appliances while scaling based on demand.
  • Uses GENEVE encapsulation protocol on port 6081.
  • Supports 5-tuple (default), 3-tuple, or 2-tuple flow stickiness.
  • Accessible via VPC route table entries (not via VIP like ALB/NLB).
  • Target types: IP and Instance.
  • Supports cross-zone load balancing, deletion protection, and connection draining.
  • Supports configurable TCP idle timeout (60–6000 seconds) since September 2024.
  • Supports LCU Reservation since April 2025.
  • Does not support: SSL offloading, security groups, SNI, static/elastic IP, or slow start.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to use load balancer for their application. However, the company wants to forward the requests without any header modification. What service should the company use?
    1. Classic Load Balancer
    2. Network Load Balancer
    3. Application Load Balancer
    4. Use Route 53
  2. A Solutions Architect is building an Amazon ECS-based web application that requires that headers are not modified when being forwarded to Amazon ECS. Which load balancer should the Architect use?
    1. Application Load Balancer
    2. Network Load Balancer
    3. A virtual load balancer appliance from AWS marketplace
    4. Classic Load Balancer
  3. An application tier currently hosts two web services on the same set of instances, listening on different ports. Which AWS service should a solutions architect use to route traffic to the service based on the incoming request?
    1. AWS Application Load Balancer
    2. Amazon CloudFront
    3. Amazon Route 53
    4. AWS Classic Load Balancer
  4. A Solutions Architect needs to deploy an HTTP/HTTPS service on Amazon EC2 instances with support for WebSockets using load balancers. How can the Architect meet these requirements?
    1. Configure a Network Load balancer.
    2. Configure an Application Load Balancer.
    3. Configure a Classic Load Balancer.
    4. Configure a Layer-4 Load Balancer.
  5. A company is hosting an application in AWS for third party access. The third party needs to whitelist the application based on the IP. Which AWS service can the company use in the whitelisting of the IP address?
    1. AWS Application Load Balancer
    2. AWS Classic Load balancer
    3. AWS Network Load Balancer
    4. AWS Route 53
  6. A company needs to deploy inline virtual firewall appliances to inspect all traffic entering and leaving their VPC. The solution must scale automatically with traffic. Which load balancer type should they use?
    1. Application Load Balancer
    2. Network Load Balancer
    3. Classic Load Balancer
    4. Gateway Load Balancer
  7. A solutions architect needs to implement mutual TLS authentication for an application behind a load balancer to verify client certificates. Which load balancer supports this natively?
    1. Application Load Balancer
    2. Network Load Balancer
    3. Classic Load Balancer
    4. Gateway Load Balancer
  8. A company wants to perform blue/green deployments with their Network Load Balancer by gradually shifting traffic between two target groups. Which NLB feature enables this?
    1. Path-based routing
    2. Slow start mode
    3. Weighted target groups
    4. Cross-zone load balancing
  9. An organization wants to prepare their Network Load Balancer for a planned marketing event that will cause a sudden spike in traffic. Which feature should they use?
    1. Cross-zone load balancing
    2. Load Balancer Capacity Unit (LCU) Reservation
    3. Target group health configuration
    4. Slow start mode
  10. A company running a mobile gaming application needs ultra-low latency load balancing with session stickiness that survives client IP changes due to mobile network roaming. Which protocol and load balancer combination best meets this need?
    1. ALB with cookie-based stickiness
    2. NLB with TCP 5-tuple stickiness
    3. NLB with QUIC protocol using Connection ID stickiness
    4. CLB with session cookies

Related Posts

References

AWS API Gateway

~ Last updated on : ~ jayendrapatil ~ 32 Comments

AWS API Gateway

  • AWS API Gateway is a fully managed service that makes it easy for developers to publish, maintain, monitor, and secure APIs at any scale.
  • API Gateway handles all of the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management.
  • API Gateway has no minimum fees or startup costs and charges only for the API calls received and the amount of data transferred out.
  • API Gateway acts as a proxy to the configured backend operations.
  • API Gateway scales automatically to handle the amount of traffic the API receives.
  • API Gateway exposes HTTPS endpoints only for all the APIs created. It does not support unencrypted (HTTP) endpoints.
  • APIs built on API Gateway can accept any payloads sent over HTTP with typical data formats including JSON, XML, query string parameters, and request headers.
  • API Gateway supports three types of APIs:
    • REST APIs – Full-featured API management with request/response transformation, caching, usage plans, and API keys.
    • HTTP APIs – Optimized for serverless workloads with up to 71% cost savings and 60% lower latency compared to REST APIs.
    • WebSocket APIs – For real-time, bidirectional communication between clients and backend services.
  • API Gateway can communicate to multiple backends
    • Lambda functions
    • AWS Step Functions state machines
    • HTTP endpoints exposed through Elastic Beanstalk, ELB or EC2 servers
    • Non AWS hosted HTTP based operations accessible via public Internet
    • Amazon Bedrock AgentCore Gateway (for AI agent tool interactions via MCP)
  • API Gateway endpoints can be public or private:
    • Edge-optimized and Regional endpoints are public to the Internet.
    • Private endpoints can only be accessed from within a VPC using interface VPC endpoints.

AWS API Gateway

API Gateway helps with several aspects of creating and managing APIs

  • Metering
    • automatically meters traffic to the APIs and lets you extract utilization data for each API key.
    • define plans that meter, restrict third-party developer access, configure throttling, and quota limits on a per API key basis
  • Security
    • helps remove authorization concerns from the backend code
    • allows leveraging of AWS administration and security tools, such as IAM and Cognito, to authorize access to APIs
    • can verify signed API calls on your behalf using the same methodology AWS uses for its own APIs.
    • supports custom authorizers written as Lambda functions and verify incoming bearer tokens.
    • supports mutual TLS (mTLS) authentication for REST and HTTP APIs for enhanced client-server identity verification.
    • supports Signature Version 4A (SigV4a) for REST APIs, enabling multi-region request signing for seamless routing and failover between regions.
    • automatically protects the backend systems from distributed denial-of-service (DDoS) attacks, whether attacked with counterfeit requests (Layer 7) or SYN floods (Layer 3).
  • Resiliency
    • helps manage traffic with throttling so that backend operations can withstand traffic spikes.
    • helps improve the performance of the APIs and the latency end users experience by caching the output of API calls to avoid calling the backend every time.
  • Operations Monitoring
    • integrates with CloudWatch and provides a metrics dashboard to monitor calls to API services
    • integrates with CloudWatch Logs to receive errors, access or debug logs
    • provides backend performance metrics covering API calls, latency data and error rates.
    • provides enhanced observability variables in access logs for granular troubleshooting of request errors and latency issues.
  • Lifecycle Management
    • allows multiple API versions and multiple stages (development, staging, production etc.) for each version simultaneously so that existing applications can continue to call previous versions after new API versions are published.
    • saves the history of the deployments, which allows rollback of a stage to a previous deployment at any point, using APIs or console.
  • Designed for Developers
    • allows specifying a mapping template to generate static content to be returned, helping you mock APIs before the backend is ready
    • helps reduce cross-team development effort and time-to-market for applications and allows dependent teams to begin development while backend processes are still built.

API Gateway API Types

REST APIs

  • Full-featured API management with the broadest set of capabilities.
  • Supports request/response transformation using Velocity Template Language (VTL).
  • API keys and usage plans for metering and throttling third-party access.
  • Request validation, API caching, and resource policies.
  • Private API endpoints accessible only from within a VPC.
  • Integration with AWS WAF for web exploit protection.
  • Canary release deployments for safe rollouts.
  • Supports response streaming (November 2025) – progressively streams response payloads to clients without buffering the entire response.
  • Supports private integration with Application Load Balancer directly (November 2025), eliminating the need for an intermediate NLB.
  • Pricing: $3.50 per million requests (first 333M), reducing at scale.

HTTP APIs

  • Optimized for serverless workloads and HTTP backends.
  • Up to 71% cost savings and 60% latency reduction compared to REST APIs.
  • Native JWT authorizer support and OpenID Connect/OAuth 2.0 integration.
  • Simplified configuration with automatic deployments.
  • Supports private integrations with ALB, NLB, and AWS Cloud Map via VPC links.
  • Supports mutual TLS (mTLS) authentication.
  • Does NOT support: API caching, request/response transformation, API keys/usage plans, resource policies, or private API endpoints.
  • Pricing: $1.00 per million requests (first 300M), then $0.90 per million.

WebSocket APIs

  • Supports real-time, bidirectional communication between clients and backend services.
  • Manages persistent connections and message routing based on message content.
  • Supports IAM and Lambda authorization, custom domains, and stage variables.
  • Ideal for chat applications, real-time dashboards, and gaming.
  • Available in most AWS Regions (expanded to 7 additional regions in 2024).
  • Pricing: $1.00 per million messages + $0.25 per million connection minutes.

API Gateway Features

  • Support for stateful (WebSocket) and stateless (HTTP and REST) APIs.
  • Powerful, flexible authentication mechanisms, such as AWS IAM policies, Lambda authorizer functions, and Amazon Cognito user pools.
  • Mutual TLS (mTLS) authentication for client certificate-based identity verification.
  • Signature Version 4A (SigV4a) support for multi-region API access patterns.
  • API Gateway Portals – fully managed developer portals for API discovery, documentation, and governance (November 2025).
  • Canary release deployments for safely rolling out changes.
  • CloudTrail logging and monitoring of API usage and API changes.
  • CloudWatch access logging and execution logging, including the ability to set alarms.
  • Ability to use AWS CloudFormation templates to enable API creation.
  • Support for custom domain names.
  • Integration with AWS WAF for protecting your APIs against common web exploits.
  • Integration with AWS X-Ray for understanding and triaging performance latencies.
  • Response streaming for REST APIs – progressively stream response payloads to clients as they become available (November 2025).
  • Dynamic routing rules for custom domain names based on HTTP headers and/or URL paths (June 2025).
  • Dual-stack (IPv4 and IPv6) endpoint support for REST, HTTP, and WebSocket APIs (March 2025).
  • Private integration with Application Load Balancer for REST APIs without requiring an intermediate NLB (November 2025).
  • Amazon Bedrock AgentCore Gateway integration for exposing REST APIs to AI agents via MCP (December 2025).

API Gateway Throttling and Caching

API Gateway Throttling and Caching

  • Throttling
    • API Gateway provides throttling at multiple levels including global and by service calls and limits can be set for standard rates and bursts.
    • It tracks the number of requests per second. Any requests over the limit will receive a 429 HTTP response.
    • Throttling ensures that API traffic is controlled to help the backend services maintain performance and availability.
  • Caching
    • API Gateway provides API result caching by provisioning an API Gateway cache and specifying its size in gigabytes.
    • Caching helps improve performance and reduces the traffic sent to the back end.
    • Caching is available only for REST APIs (not HTTP APIs or WebSocket APIs).
    • API Gateway handles the request in the following manner
      • If caching is not enabled and throttling limits have not been applied, then all requests pass through to the backend service until the account level throttling limits are reached.
      • With throttling limits defined, the API Gateway will shed necessary amount of requests and send only the defined limit to the back-end
      • If a cache is configured, the API Gateway will return a cached response for duplicate requests for a customizable time, but only if under configured throttling limits. It caches responses from the endpoint for a specified time-to-live (TTL) period, in seconds
  • API Gateway does not arbitrarily limit or throttle invocations to the backend operations and all requests that are not intercepted by throttling and caching settings are sent to your backend operations.

API Gateway Response Streaming

  • API Gateway REST APIs support response streaming, progressively sending response payloads to clients as they become available (November 2025).
  • Eliminates the need to buffer complete responses before transmission, improving API responsiveness.
  • Responses can be streamed for up to 15 minutes.
  • Ideal for streaming LLM (Large Language Model) responses from services like Amazon Bedrock.
  • Works with proxy integrations (Lambda proxy and HTTP proxy).
  • Reduces time-to-first-byte (TTFB) for large responses.

API Gateway Routing Rules

  • Dynamic routing rules enable routing API requests based on HTTP header values, URL base paths, or a combination of both (June 2025).
  • Routing rules are associated with custom domain names.
  • Each rule has conditions, actions, and a priority:
    • Conditions: Up to two header conditions and one base path condition per rule (evaluated with AND logic).
    • Actions: Route to any stage of any REST API within the same account and region.
    • Priority: Numerical value (1 to 1,000,000); lower number = higher priority.
  • Supports wildcard matching in header values for prefix, suffix, and contains patterns.
  • Three routing modes:
    • API mappings only – default mode, base path mappings only.
    • Routing rules then API mappings – rules take precedence, unmatched requests fall back to base path mappings.
    • Routing rules only – recommended mode for new domains.
  • Use cases: API versioning, A/B testing, canary deployments, cell-based architecture routing, tenant-based routing.
  • No additional charges for using routing rules on REST APIs.

API Gateway Endpoint Types

Edge-optimized API Endpoints

  • An edge-optimized API endpoint is best for geographically distributed clients and is the default endpoint type for API Gateway REST APIs.
  • API requests are routed to the nearest CloudFront Point of Presence (POP).
  • Edge-optimized APIs capitalize the names of HTTP headers (for example, Cookie).
  • CloudFront sorts HTTP cookies in natural order by cookie name before forwarding the request to your origin.
  • Any custom domain name used for an edge-optimized API applies across all regions.

Regional API Endpoints

  • A regional API endpoint is intended for clients in the same region.
  • When a client running on an EC2 instance calls an API in the same region, or when an API is intended to serve a small number of clients with high demands, a regional API reduces connection overhead.
  • For a regional API, any custom domain name used is specific to the region where the API is deployed. If you deploy a regional API in multiple regions, it can have the same custom domain name in all regions.
  • Regional API endpoints pass all header names through as-is.

Private API Endpoints

  • A private API endpoint is an API endpoint that can only be accessed from VPC using an interface VPC endpoint.
  • Private API endpoints pass all header names through as-is.
  • Private APIs can only have a dualstack (IPv4 and IPv6) IP address type.

API Gateway Dual-Stack (IPv6) Support

  • API Gateway supports dual-stack (IPv4 and IPv6) endpoints for REST, HTTP, and WebSocket APIs, and custom domain names (March 2025).
  • Available in all commercial and AWS GovCloud (US) Regions.
  • Default IP address type:
    • Regional and edge-optimized APIs: IPv4 (can be changed to dualstack).
    • Private APIs: dualstack only.
  • Custom domain names can also be configured for dualstack operation.
  • Ensures compliance with IPv6 adoption mandates and supports modern network environments.

API Gateway Private Integrations

  • Private integrations allow API Gateway to route requests to backend resources in a VPC without exposing them to the public Internet.
  • Uses VPC links to encapsulate connections between API Gateway and VPC resources.
  • REST APIs – support private integration with:
    • Network Load Balancers (NLB) via VPC links.
    • Application Load Balancers (ALB) directly (November 2025) – eliminates the need for an intermediate NLB, reducing hops and simplifying architecture.
  • HTTP APIs – support private integration with:
    • Application Load Balancers (ALB)
    • Network Load Balancers (NLB)
    • AWS Cloud Map for service discovery
  • VPC links are shared across different routes and APIs.

API Gateway Portals

  • API Gateway Portals is a fully managed developer portal feature (November 2025).
  • Provides a centralized hub for API discovery, documentation, and governance.
  • Eliminates the need for static websites, open source solutions, or third-party portal offerings.
  • Enables businesses to create AWS-native developer portals.
  • Supports publishing APIs as portal products for customer consumption.
  • Simplifies API lifecycle management and reduces fragmentation.

API Gateway and AI/MCP Integration

  • API Gateway REST APIs can be added as targets for Amazon Bedrock AgentCore Gateway (December 2025).
  • Enables AI agents to interact with existing REST APIs using the Model Context Protocol (MCP).
  • AgentCore Gateway translates MCP requests into RESTful requests to API Gateway.
  • Provides built-in security and observability for AI agent tool interactions.
  • Enables intelligent tool discovery through semantic search.
  • Allows organizations to expose both new and existing API endpoints to agentic applications without code changes.

API Gateway Security

  • Authentication & Authorization
    • IAM Authorization – Use IAM policies with SigV4 or SigV4a signed requests.
    • Lambda Authorizers – Custom authorization logic in Lambda functions; supports token-based and request parameter-based authorizers.
    • Cognito User Pools – JWT token validation with Amazon Cognito.
    • JWT Authorizers (HTTP APIs only) – Native support for any OIDC-compliant identity provider.
    • Mutual TLS (mTLS) – Client certificate-based authentication for REST and HTTP APIs.
    • Resource Policies (REST APIs only) – JSON-based policies to control access by source IP, VPC, or AWS account.
  • TLS Security
    • Minimum TLS 1.2 enforced on all API endpoints (completed February 2024).
    • Enhanced TLS security policies available for REST APIs and custom domain names (November 2025).
    • Header remapping feature removed (June 2023) to improve security posture.
  • Integration with AWS WAF – Configurable rules to allow, block, or monitor web requests; protects against common web exploits like SQL injection and cross-site scripting.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are running a mobile media application and are considering API Gateway for the client entry point. What benefits would this provide? Choose 2 answers
    1. Caching API responses
    2. IP blacklisting
    3. Intrusion prevention
    4. Load balancing
    5. Throttling traffic
  2. A company is building a serverless application and needs to choose between API Gateway REST API and HTTP API. The application requires request validation, response caching, and API key management. Which API type should they use?
    1. REST API, because it supports request validation, caching, and API keys/usage plans that HTTP APIs do not offer.
    2. HTTP API, because it is cheaper and supports all features.
    3. Either API type, as they both support the same features.
    4. WebSocket API, as it supports all REST features.
  3. A company wants to allow API consumers to access their REST API from IPv6-only clients. What should they configure?
    1. Create a CloudFront distribution in front of the API.
    2. Configure the API Gateway REST API endpoint to use the dualstack IP address type.
    3. Deploy a Network Load Balancer with IPv6 enabled.
    4. Use an HTTP API instead, as only HTTP APIs support IPv6.
  4. A development team needs to route API traffic to different backend versions based on a custom HTTP header value without changing URL paths. Which API Gateway feature should they use?
    1. Stage variables
    2. Canary deployments
    3. Base path mappings
    4. Routing rules for custom domain names
  5. A company wants to stream responses from their generative AI backend through API Gateway REST API to reduce time-to-first-byte for end users. Which feature enables this?
    1. WebSocket API with callback URL
    2. API Gateway caching with low TTL
    3. Response streaming with proxy integration
    4. Asynchronous Lambda invocation
  6. An organization wants to expose their existing REST APIs to AI agents that use the Model Context Protocol (MCP). Which integration enables this?
    1. Direct Lambda integration with MCP libraries
    2. API Gateway WebSocket API
    3. Amazon Bedrock AgentCore Gateway with API Gateway as a target
    4. Amazon EventBridge API destinations
  7. A company has REST APIs that need to integrate with backend services running on an ALB in a private VPC. Previously this required an intermediate NLB. Which new feature simplifies this?
    1. HTTP API with ALB private integration
    2. REST API direct private integration with Application Load Balancer
    3. VPC Lattice service network
    4. AWS PrivateLink endpoint service

References

AWS Certified DevOps – Professional Exam Learning Path

~ Last updated on : ~ jayendrapatil ~ 46 Comments

⚠️ OUTDATED EXAM VERSION

This post covers the original AWS Certified DevOps – Professional exam blueprint (pre-2019). This exam version has been retired.

The current exam version is DOP-C02, launched in 2023 with significantly updated domains and services.

Please use the updated guides:

This content is maintained for historical reference only.

AWS Certified DevOps – Professional Exam Learning Path (Legacy)

📋 Current Exam: DOP-C02 | 75 Questions | 180 Minutes | $300 USD

DOP-C02 Domains:

  • Domain 1: SDLC Automation (22%)
  • Domain 2: Configuration Management and IaC (17%)
  • Domain 3: Resilient Cloud Solutions (15%)
  • Domain 4: Monitoring and Logging (15%)
  • Domain 5: Incident and Event Response (14%)
  • Domain 6: Security and Compliance (17%)

➡️ View the DOP-C02 Exam Learning Path

Legacy Exam Content (Original Blueprint – Retired)

The original AWS Certified DevOps – Professional exam validated the following:

  • Implement and manage continuous delivery systems and methodologies on AWS
  • Understand, implement, and automate security controls, governance processes, and compliance validation
  • Define and deploy monitoring, metrics, and logging systems on AWS
  • Implement systems that are highly available, scalable, and self-healing on the AWS platform
  • Design, manage, and maintain tools to automate operational processes

AWS Cloud Computing Whitepapers

AWS Certified DevOps – Professional Exam Contents (Legacy)

Domain 1: Continuous Delivery and Process Automation

  • 1.1 Demonstrate an understanding of application lifecycle management:
    • Application deployment management strategies such as rolling deployments and A/B.
    • Version control, testing, build tools and bootstrapping.
      • includes CloudFormation Best Practices esp. Nested Templates for better control, using parameters for reusability
      • includes bootstrapping using userdata
      • includes CloudFormation helper scripts, WaitCondition and Creation Policy
      • includes CloudFormation Custom Resource
      • Using Pre-Baked AMIs
      • Using Docker with Elastic Beanstalk
  • 1.2 Demonstrate an understanding of infrastructure configuration and automation.
  • 1.3 Implement and manage continuous delivery processes using AWS services.
    • includes CodeDeploy
    • OpsWorks reached EOL May 26, 2024 – replaced by AWS Systems Manager in current exam
  • 1.4 Develop and manage scripts and tools to automate operational tasks using the AWS SDKs, CLI, and APIs.
    • includes using CloudFormation helper scripts
    • includes using Elastic Beanstalk container commands

Domain 2: Monitoring, Metrics, and Logging

  • 2.1 Monitor availability and performance.
  • 2.2 Monitor and manage billing and cost optimization processes.
  • 2.3 Aggregate and analyze infrastructure, OS and application log files.
    • includes using CloudWatch logs
    • includes using ELB access logs, CloudTrail logs which can be integrated with CloudWatch logs
  • 2.4 Use metrics to drive the scalability and health of infrastructure and applications.
    • includes using CloudWatch alarms, SNS and AutoScaling
  • 2.5 Analyze data collected from monitoring systems to discern utilization patterns.
    • includes CloudWatch and analysis using CloudWatch metrics
    • includes using Kinesis for real time log analysis
  • 2.6 Manage the lifecycle of application and infrastructure logs
  • 2.7 Leverage the AWS SDKs, CLIs and APIs for metrics and logging.
    • includes CloudWatch logs using CloudWatch agent with logs group, events and metrics

Domain 3: Security, Governance, and Validation

Domain 4: High Availability and Elasticity

  • 4.1 Determine appropriate use of multi-Availability Zone versus multi-region architectures.
  • 4.2 Implement self-healing application architectures.
  • 4.3 Implement the most appropriate front-end scaling architecture.
  • 4.4 Implement the most appropriate middle-tier scaling architecture.
    • includes building scalable architecture using ELB with Auto Scaling
    • includes building loosely coupled scalable architecture using SQS, CloudWatch and AutoScaling and SWF
  • 4.5 Implement the most appropriate data storage scaling architecture.
  • 4.6 Demonstrate an understanding of when to appropriately apply vertical and horizontal scaling concepts.
    • includes basic understanding of horizontal scaling is scale in/out and vertical scaling is scale up/down

AWS Certified DevOps – Professional Exam Resources

⚠️ Note: Many of the original resources listed for this exam version are no longer available:

  • A Cloud Guru — Platform shut down November 2025, migrated to Pluralsight Cloud+
  • Linux Academy — Merged into A Cloud Guru (now Pluralsight)
  • Braincert — Original practice exam links may no longer be active

Recommended Current Resources (DOP-C02)

Key Changes from Legacy Exam to DOP-C02

  • AWS OpsWorks Stacks — Reached End of Life on May 26, 2024. No longer tested. Replaced by AWS Systems Manager for configuration management.
  • AWS CodeCommit — No longer accepting new customers (July 2024). Existing functionality maintained but no new features.
  • New services heavily tested: AWS CDK, AWS SAM, Amazon EventBridge, AWS Step Functions, Amazon ECS/EKS deployments, AWS Security Hub, Amazon GuardDuty, AWS Control Tower
  • Container and serverless focus: DOP-C02 significantly increased coverage of ECS, EKS, Lambda, and Fargate deployment patterns
  • Six domains (expanded from 4) with dedicated domains for Incident Response and Security/Compliance

Related Posts

AWS Certified Developer – Associate Exam Learning Path

~ Last updated on : ~ jayendrapatil ~ 43 Comments

⚠️ OUTDATED EXAM VERSION

This post covers the original AWS Certified Developer – Associate exam (2017), which has been retired.

The current exam version is DVA-C02, released February 2023 and revised December 2024 with new skills including Amazon Q Developer, EventBridge patterns, and resilient application design.

For the current exam:

This page is maintained for historical reference only.

AWS Certified Developer – Associate Exam Learning Path (Original 2017 – RETIRED)

NOTE – This exam version has been retired. The exam has gone through two major revisions since this guide was published:

Current DVA-C02 Exam Overview

The current AWS Certified Developer – Associate (DVA-C02) exam validates proficiency in developing, testing, deploying, and debugging AWS cloud-based applications. Key changes from the original exam include:

DVA-C02 Exam Domains (Current)

  • Domain 1: Development with AWS Services (32%) – Includes Amazon Q Developer, event-driven patterns, resilient application design
  • Domain 2: Security (26%) – IAM, Cognito, KMS, Secrets Manager, WAF, fine-grained access control
  • Domain 3: Deployment (24%) – CI/CD pipelines, deployment strategies (blue/green, canary, rolling), IaC
  • Domain 4: Troubleshooting and Optimization (18%) – X-Ray, CloudWatch, structured logging, caching, performance optimization

Key Services Added Since Original Exam

  • Amazon Q Developer – AI-powered development assistant (added December 2024)
  • Amazon EventBridge – Event-driven architecture patterns
  • AWS Step Functions – Serverless workflow orchestration
  • AWS AppSync – Managed GraphQL service
  • Amazon Cognito – User authentication and authorization
  • AWS Secrets Manager – Secrets management
  • AWS AppConfig – Application configuration management
  • AWS CDK – Infrastructure as code using programming languages
  • Amazon ECS/EKS – Container orchestration
  • AWS CodePipeline/CodeBuild/CodeDeploy – CI/CD services

Services Removed from Scope

  • AWS Copilot – Removed from DVA-C02 v2.1 (December 2024)
  • Amazon CodeGuru – Removed from DVA-C02 v2.1 (December 2024)
  • Amazon SWF – No longer in scope (replaced by Step Functions)

Original 2017 Exam Content (Historical Reference)

The original AWS Developer – Associate exam validated the following:

  • Design, develop and deploy cloud based solutions using AWS
  • Understand the core AWS services, uses, and basic architecture best practices
  • Develop and maintain applications written for Amazon Simple Storage Services (S3), Amazon DynamoDB, Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS), Amazon Simple Workflow Service (SWF), AWS Elastic Beanstalk, and AWS CloudFormation

Domain 1.0: AWS Fundamentals

Domain 2.0: Designing and Developing

Domain 3.0: Deployment and Security

Domain 4.0: Debugging

  • General troubleshooting information and questions
  • Best Practices in debugging

AWS Developer – Associate Exam Resources

For current exam preparation resources, please refer to the DVA-C02 Exam Learning Path.

  • Read the AWS FAQs for important topics, as they cover key points and are good for quick review
  • Sign up for the AWS Free Tier to get hands-on experience
  • Use Cloud Skills Boost (formerly QwikLabs) for guided labs

AWS SysOps Administrator – Associate Exam Learning Path

~ Last updated on : ~ jayendrapatil ~ 75 Comments

⚠️ EXAM RETIRED — Historical Reference Only

The original AWS SysOps Administrator – Associate exam covered in this post was retired in September 2018 and replaced by SOA-C01, then SOA-C02, and most recently by the AWS Certified CloudOps Engineer – Associate (SOA-C03) which launched on September 30, 2025.

This content is maintained for historical reference only. Do NOT use this page for current exam preparation.

Current Exam Path:

Key Changes in SOA-C03: Containers (ECS, EKS, ECR) now in scope, AWS CDK and Terraform tested, multi-account/multi-Region emphasis, 5 domains instead of 6, exam labs removed.

AWS SysOps Administrator – Associate Exam Learning Path

NOTE — This page covers the original (pre-2018) AWS SysOps Administrator exam. This exam version has been retired and superseded multiple times:

The original AWS SysOps Administrator – Associate exam validated the following:

  • Deliver the stability and scalability needed by a business on AWS
  • Provision systems, services and deployment automation on AWS
  • Ensure data integrity and data security on AWS technology
  • Provide guidance on AWS best practices
  • Understand and monitor metrics on AWS

AWS Cloud Computing Whitepapers

AWS SysOps Administrator – Associate Exam Contents (Original Version)

Domain 1.0: Monitoring and Metrics

Domain 2.0: High Availability

Domain 3.0: Analysis

  • Optimize the environment to ensure maximum performance
  • Identify performance bottlenecks and implement remedies
  • Identify potential issues on a given application deployment

Domain 4.0: Deployment and Provisioning

  • Demonstrate the ability to build the environment to conform with the architected design
  • Demonstrate the ability to provision cloud resources and manage implementation automation

Domain 5.0: Data Management

Domain 6.0: Security

  • Implement and manage security policies
  • Ensure data integrity and access controls when using the AWS platform
  • Demonstrate understanding of the shared responsibility model
  • Demonstrate ability to prepare for security assessment use of AWS

Domain 7.0: Networking

  • Demonstrate ability to implement networking features of AWS
    • includes topics VPC
  • Demonstrate ability to implement connectivity features of AWS

Current Exam: AWS Certified CloudOps Engineer – Associate (SOA-C03)

As of September 30, 2025, the SysOps Administrator certification has been renamed and updated to AWS Certified CloudOps Engineer – Associate (SOA-C03). This is not just a name change — the exam scope has expanded significantly.

SOA-C03 Exam Overview

  • Exam Code: SOA-C03
  • Duration: 130 minutes
  • Questions: 65 (multiple-choice and multiple-response)
  • Passing Score: 720/1000
  • Cost: $150 USD
  • Exam Labs: None (removed since March 2023, not returned)
  • Validity: 3 years

SOA-C03 Domains

  • Domain 1: Monitoring, Logging, Analysis, Remediation & Performance Optimization (22%)
  • Domain 2: Reliability and Business Continuity (20%)
  • Domain 3: Deployment, Provisioning, and Automation (18%)
  • Domain 4: Security and Compliance (16%)
  • Domain 5: Networking and Content Delivery (14%)

Key New Topics in SOA-C03

  • Containers: Amazon ECS, EKS, ECR, and Fargate are now in scope
  • Infrastructure as Code: AWS CDK and Terraform explicitly tested
  • Multi-Account: AWS Organizations, Control Tower, SCPs, IAM Identity Center heavily emphasized
  • Modern Observability: Amazon Managed Grafana, Managed Service for Prometheus, CloudWatch Container Insights
  • Database Services: Aurora Serverless v2, RDS Proxy, DynamoDB Accelerator (DAX)
  • Disaster Recovery: AWS Elastic Disaster Recovery (DRS), CloudFormation StackSets
  • Security: AWS Security Hub, Config Organization Rules, KMS multi-Region keys

AWS Certified CloudOps Engineer – Associate Resources

Related Posts

AWS Certified Solution Architect – Associate Exam Learning Path

~ Last updated on : ~ jayendrapatil ~ 430 Comments

AWS Certified Solutions Architect – Associate (SAA-C03) Exam Learning Path

📋 Exam Quick Facts (2026)

  • Current Version: SAA-C03 (launched August 30, 2022)
  • Upcoming Version: SAA-C04 (rolling out Q2-Q3 2026 with increased AI/ML focus)
  • Duration: 130 minutes
  • Questions: 65 (multiple choice or multiple response)
  • Cost: $150 USD
  • Passing Score: 720 out of 1000
  • Validity: 3 years
  • Testing: Pearson VUE (test center or online proctored)

The AWS Certified Solutions Architect – Associate (SAA-C03) validates a candidate’s ability to design solutions based on the AWS Well-Architected Framework. It is one of the most popular and in-demand cloud certifications globally.

The exam validates the following abilities:

  • Design solutions that incorporate AWS services to meet current business requirements and future projected needs
  • Design architectures that are secure, resilient, high-performing, and cost-optimized
  • Review existing solutions and determine improvements
  • Provide implementation guidance based on best practices throughout the workload lifecycle

Refer to the AWS Certified Solutions Architect – Associate (SAA-C03) Exam Guide

SAA-C03 Exam Domains and Weights

Domain Weight
Domain 1: Design Secure Architectures 30%
Domain 2: Design Resilient Architectures 26%
Domain 3: Design High-Performing Architectures 24%
Domain 4: Design Cost-Optimized Architectures 20%

AWS Well-Architected Framework

The SAA-C03 exam is heavily based on the AWS Well-Architected Framework, which comprises six pillars:

  1. Operational Excellence – Run and monitor systems to deliver business value
  2. Security – Protect information, systems, and assets
  3. Reliability – Recover from failures and meet demand
  4. Performance Efficiency – Use resources efficiently
  5. Cost Optimization – Avoid unnecessary costs
  6. Sustainability – Minimize environmental impact (added in 2021)

AWS Cloud Computing Whitepapers

Domain 1: Design Secure Architectures (30%)

This is the highest-weighted domain. Topics include:

1.1 Secure Access to AWS Resources

1.2 Secure Workloads and Applications

1.3 Data Security Controls

Domain 2: Design Resilient Architectures (26%)

2.1 Scalable and Loosely Coupled Architectures

2.2 Highly Available and Fault-Tolerant Architectures

Domain 3: Design High-Performing Architectures (24%)

3.1 Compute

3.2 Storage

3.3 Database

  • Amazon RDS (Multi-AZ, Read Replicas, Aurora)
  • Amazon DynamoDB (On-demand, Provisioned, DAX, Global Tables)
  • Amazon ElastiCache (Redis, Memcached)
  • Amazon Redshift

3.4 Networking & Content Delivery

Domain 4: Design Cost-Optimized Architectures (20%)

  • EC2 Purchasing Options & Savings Plans
  • S3 Lifecycle Policies & Storage Class analysis
  • AWS Cost Explorer, Budgets, and Cost Anomaly Detection
  • Right-sizing recommendations
  • Serverless vs. provisioned cost trade-offs
  • Data transfer costs and optimization
  • Storage Options Whitepaper

Implementation & Deployment Services

Key services tested on the exam for infrastructure deployment:

Monitoring & Logging

Troubleshooting

SAA-C03 Exam Preparation Resources

Recommended Courses

🎓 Top-Rated Video Courses

Practice Exams

📝 Recommended Practice Tests

Hands-On Practice

  • AWS Free Tier
    • Updated (July 2025): New accounts now receive up to $200 in credits ($100 at sign-up + $100 more for completing activities) valid for 6 months on the Free Plan
    • Always Free tier services still available (Lambda, DynamoDB, etc.)
    • Existing accounts retain their original 12-month free tier benefits
  • Google Skills (formerly Qwiklabs / Google Cloud Skills Boost) – Offers some AWS-related labs, though primarily Google Cloud focused
  • AWS Skill Builder Labs – Official hands-on labs (subscription required for most)

Study Tips

  • Read the AWS FAQs for key services (EC2, S3, VPC, RDS, Lambda, IAM)
  • Understand architectural trade-offs, not just service features
  • Focus heavily on security (30% of exam) – IAM, encryption, VPC networking
  • Practice multi-service scenario questions – the exam tests decision-making
  • Recommended prep time: 8-12 weeks with hands-on practice
  • Use the AWS service names list – the exam uses short names for services

SAA-C04 Update (Rolling Out 2026)

🔄 Upcoming Exam Update

AWS is rolling out the SAA-C04 revision in Q2-Q3 2026 with the following changes:

  • Increased emphasis on resilient architecture design (30% of exam)
  • New focus on cost optimization for AI/ML workloads
  • Multi-region resilience architectures
  • Questions on Amazon Bedrock and AI governance frameworks

If you are preparing in mid-2026, check the AWS Certification Coming Soon page for exact transition dates.

Certification Path After SAA

After earning the Solutions Architect – Associate, consider:

  • AWS Certified Solutions Architect – Professional – Advanced architecture (also auto-recertifies your Associate)
  • AWS Certified Security – Specialty – Deep security focus
  • AWS Certified Data Engineer – Associate – Data and analytics focus
  • AWS Certified DevOps Engineer – Professional – CI/CD and automation

Note: Once you earn one AWS Certification, you receive a 50% discount on your next certification exam.

AWS Elasticsearch

~ Last updated on : ~ jayendrapatil ~ 4 Comments

AWS OpenSearch Service

📌 Service Renamed: Amazon Elasticsearch Service was renamed to Amazon OpenSearch Service on September 8, 2021. OpenSearch is an open-source, community-driven fork of Elasticsearch and Kibana. All existing Elasticsearch domains were automatically upgraded. The service now runs OpenSearch (versions 1.x, 2.x) and continues to support Elasticsearch versions 1.5 to 7.10.

  • Amazon OpenSearch Service (formerly Elasticsearch Service) is a managed service that makes it easy to deploy, operate, and scale OpenSearch clusters in the AWS Cloud.
  • OpenSearch is a popular open-source search and analytics engine for use cases such as log analytics, real-time application monitoring, clickstream analytics, vector search for AI/ML, and security analytics (SIEM).
  • OpenSearch Service provides
    • real-time, distributed search and analytics engine
    • ability to provision all the resources for the OpenSearch cluster and launch the cluster
    • easy to use cluster scaling options. Scaling the OpenSearch Service domain by adding or modifying instances, and storage volumes is an online operation that does not require any downtime.
    • self-healing clusters, which automatically detect and replace failed OpenSearch nodes, reducing the overhead associated with self-managed infrastructures
    • domain snapshots to back up and restore domains and replicate domains across AZs
    • data durability
    • enhanced security with IAM access control, fine-grained access control, and security groups
    • node monitoring
    • multiple configurations of CPU, memory, and storage capacity, known as instance types
    • storage volumes for the data using EBS volumes
    • Multiple geographical locations for your resources, known as regions and Availability Zones
    • ability to span cluster nodes across multiple AZs in the same region, known as zone awareness, for high availability and redundancy. OpenSearch Service automatically distributes the primary and replica shards across instances in different AZs.
    • Multi-AZ with Standby deployment option for 99.99% availability SLA with consistent performance for business-critical workloads
    • dedicated master nodes to improve cluster stability
    • data visualization using OpenSearch Dashboards (successor to Kibana)
    • integration with CloudWatch for monitoring OpenSearch domain metrics
    • integration with CloudTrail for auditing configuration API calls to OpenSearch domains
    • integration with S3, Kinesis, and DynamoDB for loading streaming data
    • ability to handle structured and unstructured data
    • HTTP Rest APIs
    • vector database capabilities for k-nearest neighbor (k-NN) search, enabling AI/ML and RAG workloads
    • security analytics for real-time threat detection and SIEM use cases

OpenSearch Domains

  • OpenSearch Service domains are OpenSearch clusters created using the OpenSearch Service console, CLI, or API.
  • Each domain is the cluster in the cloud with the specified compute and storage resources.
  • Enables you to create and delete domains, define infrastructure attributes, and control access and security.
  • OpenSearch Service automates common administrative tasks, such as performing backups, monitoring instances, and patching software once the domain is running.

OpenSearch Serverless

  • Amazon OpenSearch Serverless is a serverless deployment option that removes the need to manage clusters, nodes, or capacity.
  • Automatically provisions, scales, and optimizes infrastructure based on workload demands.
  • Next-generation architecture (GA May 2026) features:
    • Scale to zero — no idle costs when the collection is not in use
    • 20x faster autoscaling — provisions in seconds instead of minutes
    • Up to 60% lower cost compared to provisioning clusters for peak capacity
    • Decoupled storage and compute with usage-based pricing
    • Designed for agentic AI workloads with rapid burst capabilities
  • Supports three collection types: Search, Time series, and Vector search
  • Vector search collections serve as the backend for RAG (Retrieval-Augmented Generation) applications with Amazon Bedrock Knowledge Bases
  • Capacity is measured in OpenSearch Compute Units (OCUs)

OpenSearch Optimized Instances (OR1)

  • OR1 is an OpenSearch-optimized instance family introduced in November 2023.
  • Uses EBS volumes for primary storage with data copied synchronously to S3 for 11 nines (99.999999999%) of durability.
  • Delivers up to 30% price-performance improvement over memory-optimized instances.
  • Ideal for heavy indexing use cases and large-scale log analytics.
  • Supports multi-tier storage with hot and warm tiers powered by S3-backed storage.

OpenSearch Security

  • Access to OpenSearch Service management APIs for operations such as creating and scaling domains are controlled with AWS IAM policies.
  • OpenSearch Service domains can be configured to be accessible with an endpoint within the VPC or a public endpoint accessible to the internet.
  • Network access for VPC endpoints is controlled by security groups and for public endpoints, access can be granted or restricted by IP address.
  • OpenSearch Service provides user authentication via IAM and basic authentication using username and password.
  • Authorization can be granted at the domain level (via Domain Access Policies) as well as at the index, document, and field level (via the fine-grained access control feature).
  • Fine-grained access control extends OpenSearch Dashboards with read-only views and secure multi-tenant support.
  • OpenSearch Service supports integration with Amazon Cognito, allowing end-users to log in to OpenSearch Dashboards through enterprise identity providers such as Microsoft Active Directory using SAML 2.0, Cognito User Pools, and more.
  • OpenSearch Service supports encryption at rest through AWS Key Management Service (KMS), node-to-node encryption over TLS, and the ability to require clients to communicate with HTTPS.
  • Encryption at rest encrypts shards, log files, swap files, and automated S3 snapshots.
  • Security Analytics provides built-in SIEM capabilities with pre-packaged detection rules (Sigma format), automated correlation, and real-time alerting for threat detection.

Multi-AZ with Standby

  • Multi-AZ with Standby is a deployment option that provides 99.99% availability SLA for business-critical workloads.
  • Distributes data nodes across three AZs with standby nodes that are fully provisioned and ready to take over if an AZ fails.
  • Provides consistent performance during AZ failures by automatically failing over to standby nodes.
  • Available for OpenSearch version 1.3 and above in regions with at least three Availability Zones.
  • Recommended as the default deployment option for production workloads.

Vector Search and AI/ML Integration

  • OpenSearch Service supports vector database capabilities using k-nearest neighbor (k-NN) search since 2019.
  • Supports three vector engines: FAISS (Facebook AI Similarity Search), NMSLIB, and Lucene.
  • Supports both exact nearest-neighbor and approximate nearest-neighbor (ANN) matching.
  • Integrates with Amazon Bedrock Knowledge Bases as a vector store for RAG applications.
  • Supports the connector framework to connect to models hosted by various providers (Amazon Bedrock, SageMaker, DeepSeek, OpenAI, Cohere).
  • Search flow pipelines enable chaining of ML models with search for semantic search, hybrid search, and conversational search.
  • Vector search with UltraWarm (2025) enables cost-effective storage of vector embeddings in warm storage tier.
  • Ideal for semantic search, recommendation engines, image similarity, and generative AI applications.

Zero-ETL Integrations and Direct Query

  • OpenSearch Service supports zero-ETL integrations that eliminate the need to build custom data pipelines:
    • DynamoDB zero-ETL — real-time data replication from DynamoDB tables to OpenSearch
    • Amazon DocumentDB zero-ETL — sync DocumentDB collections to OpenSearch indexes
    • Amazon S3 zero-ETL — query operational logs in S3 data lakes without ingestion
    • Amazon Security Lake zero-ETL — security analytics directly on Security Lake data
    • Amazon RDS/Aurora integration — replicate relational data to OpenSearch via OpenSearch Ingestion
  • Direct Query enables querying data in place (S3, CloudWatch Logs, Security Lake, Amazon Managed Service for Prometheus) without building ingestion pipelines using SQL, PPL, or PromQL.
  • Amazon OpenSearch Ingestion is a fully managed, serverless data pipeline for delivering data to OpenSearch Service domains and collections.

OpenSearch Dashboards

  • OpenSearch Dashboards (successor to Kibana) is the visualization and UI tool for OpenSearch Service.
  • Supports visualizations including line charts, bar graphs, pie charts, heatmaps, and more.
  • OpenSearch UI (launched November 2024) provides a modern analytics experience with natural language querying powered by Amazon Q Developer.
  • PPL (Piped Processing Language) provides 35+ commands for log analytics, faceted exploration, and deep analysis.
  • Supports querying across multiple managed clusters, serverless collections, and S3 data sources from a single endpoint.

Storage Tiers

  • OpenSearch Service provides three storage tiers:
    • Hot — high-performance storage for frequently accessed data (EBS or OR1 instances)
    • UltraWarm — cost-effective warm storage backed by S3 for less frequently accessed data (read-only, now also supports vector search)
    • Cold — lowest-cost storage for infrequently accessed data, detached from compute
  • Data can be automatically moved between tiers using Index State Management (ISM) policies.
  • Multi-tier storage with OR1 instances provides a new architecture combining S3 cloud technology with local instance storage.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You need to perform ad-hoc analysis on log data, including searching quickly for specific error codes and reference numbers. Which should you evaluate first?
    1. Amazon OpenSearch Service (OpenSearch Service is a managed service that makes it easy to deploy, operate, and scale OpenSearch clusters in the AWS cloud. OpenSearch is a popular open-source search and analytics engine for use cases such as log analytics, real-time application monitoring, and clickstream analytics. Refer link)
    2. Amazon Redshift
    3. Amazon EMR
    4. Amazon DynamoDB
  2. You are hired as the new head of operations for a SaaS company. Your CTO has asked you to make debugging any part of your entire operation simpler and as fast as possible. She complains that she has no idea what is going on in the complex, service-oriented architecture, because the developers just log to disk, and it’s very hard to find errors in logs on so many services. How can you best meet this requirement and satisfy your CTO?
    1. Copy all log files into AWS S3 using a cron job on each instance. Use an S3 Notification Configuration on the PutBucket event and publish events to AWS Lambda. Use the Lambda to analyze logs as soon as they come in and flag issues.
    2. Begin using CloudWatch Logs on every service. Stream all Log Groups into S3 objects. Use AWS EMR cluster jobs to perform adhoc MapReduce analysis and write new queries when needed.
    3. Copy all log files into AWS S3 using a cron job on each instance. Use an S3 Notification Configuration on the PutBucket event and publish events to AWS Kinesis. Use Apache Spark on AWS EMR to perform at-scale stream processing queries on the log chunks and flag issues.
    4. Begin using CloudWatch Logs on every service. Stream all Log Groups into an Amazon OpenSearch Service Domain running OpenSearch Dashboards and perform log analysis on a search cluster. (Amazon OpenSearch Service with OpenSearch Dashboards is designed specifically for real-time, ad-hoc log analysis and aggregation)
  3. A company wants to implement a security analytics solution to detect threats across its AWS environment in near real-time. The solution should use pre-built detection rules and provide automated correlation of security events. Which approach is most suitable?
    1. Stream VPC Flow Logs to Amazon S3 and query with Amazon Athena on a scheduled basis.
    2. Use Amazon GuardDuty to detect threats and send findings to Amazon SNS for manual review.
    3. Use Amazon OpenSearch Service Security Analytics with pre-packaged Sigma detection rules to correlate and alert on security events in real time. (OpenSearch Service Security Analytics provides built-in SIEM capabilities with Sigma-format detection rules, automated event correlation, and real-time alerting)
    4. Send all logs to Amazon CloudWatch Logs and create metric filters for each threat pattern.
  4. A company needs to build a generative AI application that answers questions based on internal company documents. The solution requires storing vector embeddings and performing similarity searches at scale. Which combination of AWS services should be used? (Select TWO)
    1. Amazon OpenSearch Service as the vector database for storing and searching embeddings
    2. Amazon Bedrock Knowledge Bases with OpenSearch Service as the backend vector store
    3. Amazon DynamoDB with Global Secondary Indexes for similarity search
    4. Amazon RDS with full-text search enabled
    5. Amazon ElastiCache for Redis with vector similarity search

    (Amazon OpenSearch Service provides native k-NN vector search capabilities and integrates with Amazon Bedrock Knowledge Bases for RAG applications. This combination provides scalable vector storage, similarity search, and integration with foundation models.)

  5. A company has operational data in Amazon DynamoDB and wants to enable full-text search and analytics on this data in near real-time without building custom ETL pipelines. Which solution requires the LEAST operational overhead?
    1. Enable DynamoDB Streams and write a Lambda function to index data into OpenSearch Service.
    2. Export DynamoDB data to S3 and use OpenSearch Ingestion to load it into OpenSearch.
    3. Use DynamoDB zero-ETL integration with Amazon OpenSearch Service for automatic real-time replication. (DynamoDB zero-ETL integration with OpenSearch Service provides fully managed, code-free real-time data replication without building custom pipelines)
    4. Use AWS Glue to ETL DynamoDB data into OpenSearch on a scheduled basis.
  6. A startup wants to implement full-text search for their application but does not want to manage infrastructure or pay for idle capacity. They expect bursty traffic patterns with periods of zero usage. Which option is most cost-effective?
    1. Deploy a small OpenSearch Service managed cluster with a single node.
    2. Use Amazon OpenSearch Serverless with scale-to-zero enabled. (OpenSearch Serverless next-generation architecture supports scale to zero with no idle costs, 20x faster autoscaling, and up to 60% cost savings compared to provisioning for peak capacity)
    3. Use Amazon CloudSearch for managed search.
    4. Deploy Elasticsearch on EC2 instances with Auto Scaling.