AWS EKS vs ECS – Decision Guide

AWS EKS vs ECS – Decision Guide

  • AWS offers two container orchestration services: ECS (AWS-native) and EKS (managed Kubernetes).
  • Both support Fargate (serverless) and EC2 launch types for running containers.
  • The choice depends on team expertise, portability needs, ecosystem requirements, and operational preferences.

EKS vs ECS Comparison

Feature Amazon ECS Amazon EKS
Orchestrator AWS-proprietary Kubernetes (CNCF standard)
Learning Curve Lower — simpler concepts Steeper — Kubernetes complexity
Portability AWS-only Multi-cloud, on-premises (EKS Anywhere), hybrid
Control Plane Cost Free $0.10/hour (~$73/month) per cluster; or EKS Auto Mode
Compute Options Fargate, EC2, External (ECS Anywhere) Fargate, EC2 (managed/self-managed), Karpenter, EKS Anywhere
Auto Scaling Service Auto Scaling + Capacity Providers HPA, VPA, Karpenter, Cluster Autoscaler
Networking awsvpc mode (ENI per task), Service Connect VPC CNI (pod IPs from VPC), service mesh (Istio, App Mesh)
Service Mesh ECS Service Connect (built-in) Istio, Linkerd, App Mesh, or VPC Lattice
Load Balancing ALB/NLB direct integration AWS Load Balancer Controller (ALB/NLB via ingress)
CI/CD CodeDeploy (blue/green), CodePipeline Flux, ArgoCD, Helm, CodePipeline, GitHub Actions
Observability Container Insights, X-Ray, FireLens Container Insights, Prometheus, Grafana, ADOT
Secrets Secrets Manager / Parameter Store integration Secrets Store CSI Driver, External Secrets
Windows Containers Supported (EC2 only) Supported (EC2 only)
GPU Workloads Supported Supported (better ecosystem for ML)
Ecosystem AWS-native tools Massive CNCF ecosystem (Helm, operators, CRDs)

When to Choose ECS

  • AWS-only deployment — no multi-cloud or on-premises Kubernetes needed.
  • Simplicity — smaller teams who want containers without Kubernetes complexity.
  • Cost-sensitive — no control plane fee ($73/month savings per cluster).
  • Tight AWS integration — native IAM task roles, Service Connect, CodeDeploy blue/green.
  • Getting started with containers — lower barrier to entry.
  • Fargate-first — ECS + Fargate is the simplest serverless container path.
  • Best for: Microservices on AWS, web apps, APIs, batch processing, startups.

When to Choose EKS

  • Kubernetes expertise exists — team already knows Kubernetes or uses it elsewhere.
  • Multi-cloud / hybrid — need portability to GKE, AKS, or on-premises (EKS Anywhere).
  • Rich ecosystem needed — Helm charts, operators, Istio, Argo, Prometheus, custom CRDs.
  • Complex scheduling — advanced pod placement, affinities, taints/tolerations, DaemonSets.
  • ML/AI workloads — better tooling for GPU scheduling, Kubeflow, Ray, distributed training.
  • Stateful workloads — StatefulSets, persistent volumes, operators for databases.
  • Regulatory requirements — some compliance frameworks mandate Kubernetes for container orchestration.
  • Best for: Platform teams, ML pipelines, multi-cloud strategies, complex microservices, ISVs.

EKS Auto Mode

  • Launched Dec 2024 — fully managed compute, networking, and storage for EKS.
  • AWS manages node provisioning, scaling, OS patching, and security updates.
  • Eliminates the need for managed node groups or self-managed nodes.
  • Combines the Kubernetes API with ECS-level operational simplicity.
  • Best for teams who want Kubernetes API compatibility without node management overhead.

Fargate: ECS vs EKS

  • Fargate works with both ECS and EKS — serverless compute for containers either way.
  • ECS on Fargate: Simpler configuration, native task definitions.
  • EKS on Fargate: Kubernetes pod spec, but with Fargate limitations (no DaemonSets, no privileged containers, no persistent volumes with EBS).
  • ECS Fargate supports more features (ephemeral storage up to 200 GiB, EFS, exec).

Decision Flowchart

  • Need Kubernetes API compatibility? → EKS
  • Need multi-cloud portability? → EKS
  • Team has no Kubernetes experience? → ECS
  • Want zero control plane cost? → ECS
  • Need Helm charts / operators / CRDs? → EKS
  • Just need to run containers simply? → ECS + Fargate
  • Want Kubernetes without node management? → EKS Auto Mode

AWS Certification Exam Practice Questions

  1. A startup with a small team wants to deploy containerized microservices on AWS with minimal operational overhead and no Kubernetes experience. They want serverless compute. Which option is most appropriate?
    1. EKS with managed node groups
    2. ECS with Fargate
    3. EKS with Fargate
    4. EKS Auto Mode
  2. A company runs Kubernetes on-premises and in GCP. They want to extend to AWS while maintaining the same Kubernetes manifests, Helm charts, and CI/CD pipelines. Which service should they use?
    1. ECS with EC2
    2. ECS with Fargate
    3. EKS
    4. App Runner
  3. An organization wants to run containers on Kubernetes but doesn’t want to manage nodes, patching, or scaling of the underlying compute. Which option provides this?
    1. ECS with Fargate
    2. EKS with self-managed nodes
    3. EKS Auto Mode
    4. ECS with EC2 and Capacity Providers
  4. A machine learning team needs to schedule GPU workloads with custom Kubernetes operators, use Kubeflow for training pipelines, and deploy models with Karpenter for cost-optimized scaling. Which is appropriate?
    1. ECS with GPU instances
    2. SageMaker
    3. EKS with EC2 (GPU) and Karpenter
    4. ECS with Fargate
  5. A company wants built-in service-to-service communication with automatic retries, circuit breaking, and observability without installing a service mesh like Istio. Which feature provides this on ECS?
    1. App Mesh
    2. VPC Lattice
    3. ECS Service Connect
    4. Cloud Map

Related Posts

References

Amazon ECS Developer Guide

Amazon EKS User Guide

EKS Auto Mode

AWS RDS vs DynamoDB – When to Use Which

AWS RDS vs DynamoDB

  • AWS offers both relational (RDS/Aurora) and NoSQL (DynamoDB) managed database services.
  • Choosing between them depends on data model, access patterns, scale requirements, and consistency needs.
  • Many architectures use both — RDS for transactional data and DynamoDB for high-scale, low-latency access patterns.

RDS vs DynamoDB Comparison

Feature Amazon RDS / Aurora Amazon DynamoDB
Type Relational (SQL) NoSQL (key-value / document)
Data Model Fixed schema, tables with relationships Flexible schema, single-table design
Query Language SQL (complex joins, aggregations) PartiQL / API (key-based access, limited filtering)
Scaling Vertical (instance size) + Read Replicas; Aurora Limitless for horizontal Horizontal (automatic, unlimited); on-demand or provisioned
Performance Depends on instance size; millisecond queries Single-digit millisecond at any scale; DAX for microsecond
Max Storage RDS: 64 TiB; Aurora: 128 TiB Unlimited
Consistency ACID transactions, strong consistency Eventually consistent (default); strong consistent reads available
Transactions Full SQL transactions (multi-table) TransactWriteItems/TransactGetItems (up to 100 items)
Joins Native SQL JOINs across tables No joins — denormalize or use application-side logic
Indexes B-tree, hash, GIN, full-text GSI (up to 20), LSI (up to 5)
HA / DR Multi-AZ (sync replication); Aurora Global Database Multi-AZ by default; Global Tables (multi-Region active-active)
Serverless Aurora Serverless v2 (scales to zero possible) On-demand mode (true pay-per-request, scales to zero)
Backup Automated snapshots, PITR (5-min granularity) Continuous backups, PITR (1-second granularity)
Pricing Model Instance hours + storage + I/O Read/Write capacity units or per-request
Maintenance Maintenance windows, patching required Zero maintenance, fully managed
Analytics Native SQL analytics, zero-ETL to Redshift Zero-ETL to Redshift/OpenSearch; export to S3

When to Choose RDS / Aurora

  • Complex queries — need SQL JOINs, aggregations, subqueries, window functions.
  • ACID transactions — financial systems, order processing, inventory management.
  • Existing relational schema — migrating from on-premises MySQL/PostgreSQL/Oracle/SQL Server.
  • Reporting workloads — need ad-hoc queries across multiple tables.
  • Normalized data model — relationships between entities are primary concern.
  • Moderate scale — up to hundreds of thousands of requests/second (Aurora).
  • Examples: E-commerce orders, banking, ERP, CMS with complex relationships.

When to Choose DynamoDB

  • Known access patterns — you can design a key schema around how data is queried.
  • Massive scale — millions of requests/second with consistent single-digit millisecond latency.
  • Simple key-value or document lookups — get/put by primary key.
  • Serverless / event-driven architectures — pairs naturally with Lambda.
  • Global applications — multi-Region active-active with Global Tables.
  • Variable/spiky traffic — on-demand mode handles any traffic without pre-provisioning.
  • Zero operational overhead — no patching, no maintenance windows.
  • Examples: Gaming leaderboards, session stores, IoT data, shopping carts, user profiles.

Using Both Together

  • Common pattern: RDS for source of truth (transactions) + DynamoDB for read-heavy access (caching, APIs).
  • Use DynamoDB Streams + Lambda to sync DynamoDB changes to RDS (or vice versa).
  • Use zero-ETL from Aurora/DynamoDB to Redshift for unified analytics.
  • Example: E-commerce — RDS for order processing, DynamoDB for product catalog and session data.

AWS Certification Exam Practice Questions

  1. A social media application needs to store user profiles and serve them with single-digit millisecond latency at millions of requests per second globally. Which database is most appropriate?
    1. Aurora PostgreSQL with read replicas
    2. DynamoDB with Global Tables
    3. RDS MySQL Multi-AZ
    4. ElastiCache Redis
  2. A financial application requires complex multi-table transactions where a transfer must debit one account and credit another atomically, with full SQL reporting capabilities. Which is most appropriate?
    1. DynamoDB with TransactWriteItems
    2. Aurora PostgreSQL with Multi-AZ
    3. DynamoDB with DAX
    4. Aurora Serverless with DynamoDB Streams
  3. A startup wants to minimize operational overhead with zero maintenance, pay only for actual usage, and handle unpredictable traffic spikes from 0 to 100K requests/second. Which option is best?
    1. Aurora Serverless v2
    2. DynamoDB On-Demand mode
    3. RDS with Auto Scaling read replicas
    4. Aurora with Provisioned capacity
  4. An analytics team needs to run complex ad-hoc SQL queries with JOINs across customer, order, and product tables without knowing access patterns in advance. Which is appropriate?
    1. DynamoDB with GSIs
    2. DynamoDB with PartiQL
    3. Aurora PostgreSQL
    4. DynamoDB export to S3 + Athena
  5. A gaming company stores player sessions in DynamoDB and order history in Aurora. They want unified analytics across both datasets without ETL pipelines. Which feature enables this?
    1. DynamoDB Streams to Aurora via Lambda
    2. Zero-ETL from both Aurora and DynamoDB to Redshift
    3. DynamoDB export to S3 + Aurora export to S3
    4. Federated queries in Athena

Related Posts

References

Amazon DynamoDB Developer Guide

Amazon Aurora User Guide

Amazon Q Business & Q Developer

🎓 Build AI Skills with Google
Learn practical AI skills and earn a Google Certificate. No experience required – learn at your own pace.
Start the Google AI Essentials Learning Path →

Amazon Q Business Overview

  • Amazon Q Business is a fully managed generative AI assistant for enterprises that can answer questions, provide summaries, generate content, and take actions based on enterprise data.
  • Connects to 40+ enterprise data sources (S3, SharePoint, Confluence, Slack, Salesforce, Google Drive, Gmail, Jira, ServiceNow, databases, and more).
  • Provides secure, accurate answers grounded in company data with citations and source attribution.
  • Respects existing access controls and permissions — users only see answers from data they’re authorized to access (ACL-aware).
  • Previously known as “Amazon Q for Business” — rebranded as Amazon Q Business (GA April 2024).

Key Features

  • Enterprise Search — natural language search across all connected data sources with ranked results.
  • Conversational AI — multi-turn conversations with context retention.
  • Content Generation — draft emails, reports, summaries, blog posts based on enterprise data.
  • Document Summarization — summarize long documents, meeting transcripts, and reports.
  • Actions & Plugins — perform tasks like creating Jira tickets, sending emails, updating Salesforce records.
  • Custom Plugins — build custom actions using OpenAPI schemas.
  • Amazon Q Apps — no-code app builder for creating lightweight gen-AI applications from natural language descriptions.
  • Data Insights — ask questions about structured data (databases, spreadsheets) with auto-generated visualizations.

Data Sources & Connectors

  • AWS Sources: S3, RDS, Aurora, Redshift, DynamoDB, WorkDocs
  • Collaboration: Slack, Microsoft Teams, Confluence, SharePoint Online, Google Drive
  • Productivity: Gmail, Outlook, OneDrive, Box, Dropbox
  • CRM/ITSM: Salesforce, ServiceNow, Zendesk
  • Development: Jira, GitHub, GitLab
  • Databases: PostgreSQL, MySQL, SQL Server, Oracle
  • Custom: Web Crawler, Custom connectors via API
  • Supports incremental sync — only indexes changed content.
  • 40+ pre-built connectors available.

Security & Access Control

  • ACL-aware retrieval — respects source system permissions (if a user can’t access a SharePoint doc, Q won’t use it in answers).
  • IAM Identity Center integration — SSO with corporate identity providers (Okta, Azure AD, Ping).
  • Encryption — data encrypted at rest (KMS, customer-managed keys supported) and in transit (TLS 1.2+).
  • VPC support — keep data connector traffic within VPC.
  • Admin controls — block specific topics, configure response behavior, set global/topic-level guardrails.
  • Audit logging — CloudTrail integration for all API calls.
  • Data retention — configurable conversation history retention.

Amazon Q Apps

  • No-code app builder — create gen-AI powered apps by describing them in natural language.
  • Apps can include: text generation, file upload, data queries, and custom actions.
  • App library — share apps across the organization.
  • Built on top of Q Business data and permissions.
  • Example apps: Meeting summarizer, FAQ generator, onboarding assistant, report builder.

Amazon Q Developer

  • Separate product from Q Business — focused on software development assistance.
  • Code generation — inline code suggestions in IDEs (VS Code, JetBrains, Visual Studio).
  • Code transformation — automated Java version upgrades (Java 8/11 → 17), .NET upgrades.
  • Chat — answer questions about AWS services, your codebase, and best practices.
  • /dev agent — implement features from natural language descriptions across multiple files.
  • /review — automated code review with security scanning.
  • AWS Console integration — troubleshoot errors, explain resources, generate CLI commands.
  • Customization — connect to private repositories for organization-specific suggestions.
  • Operational investigations — diagnose and resolve operational issues in AWS.

Amazon Q Business vs Amazon Bedrock

Feature Amazon Q Business Amazon Bedrock
Purpose Turnkey enterprise AI assistant Build custom gen-AI applications
Target User Business users, IT admins Developers, ML engineers
Customization Configure connectors, guardrails, plugins Full control: model selection, fine-tuning, agents, RAG
Data Integration 40+ pre-built connectors, automatic indexing Knowledge Bases (S3, web, custom), manual setup
Access Control ACL-aware (respects source permissions) IAM-based, manual implementation
Coding Required No (configuration only) Yes (API integration)
Use When Enterprise search, Q&A on company docs Custom AI apps, chatbots, content pipelines

Pricing

  • Q Business Lite — $3/user/month (search, Q&A, summaries).
  • Q Business Pro — $20/user/month (Lite features + plugins, actions, Q Apps, admin controls).
  • Q Developer Free Tier — limited code suggestions per month.
  • Q Developer Pro — $19/user/month (unlimited suggestions, /dev agent, code transformation).
  • Index pricing — based on document count and storage.

AWS Certification Exam Practice Questions

  1. A company wants employees to ask questions about internal policies, HR documents, and project wikis stored across SharePoint and Confluence. The solution must respect existing document permissions. Which service is most appropriate?
    1. Amazon Bedrock with Knowledge Bases
    2. Amazon Q Business
    3. Amazon Kendra
    4. Amazon Lex with Lambda
  2. A development team needs AI-assisted code reviews and the ability to automatically upgrade their Java 8 applications to Java 17. Which service provides this?
    1. Amazon Q Business
    2. Amazon CodeWhisperer
    3. Amazon Q Developer
    4. Amazon Bedrock Agents
  3. An organization using Amazon Q Business wants non-technical employees to create simple AI-powered apps (like a meeting summarizer) without writing code. Which feature enables this?
    1. Custom plugins
    2. Bedrock Flows
    3. Amazon Q Apps
    4. Bedrock Studio
  4. A security team needs to ensure that when employees use the company’s AI assistant, a junior analyst cannot receive answers from executive-level strategy documents they don’t have access to in SharePoint. How does Q Business handle this?
    1. Guardrails block the content category
    2. Admin manually configures document-level permissions
    3. ACL-aware retrieval automatically respects source system permissions
    4. IAM policies restrict Q Business API calls
  5. A company is choosing between Amazon Q Business and Amazon Bedrock Knowledge Bases for their internal document Q&A system. They have 40,000 employees, documents in 8 different systems, and no ML engineering team. Which should they choose?
    1. Bedrock Knowledge Bases (more flexible)
    2. Amazon Q Business (turnkey, 40+ connectors, no code needed)
    3. Amazon Kendra (purpose-built search)
    4. Custom RAG solution on EC2

Related Posts

References

Amazon Q Business User Guide

Amazon Q Developer User Guide

Amazon Q Business Product Page

Amazon Q Developer Product Page

Amazon Bedrock – Generative AI Service

🎓 Build AI Skills with Google
Learn practical AI skills and earn a Google Certificate. No experience required – learn at your own pace.
Start the Google AI Essentials Learning Path →

Amazon Bedrock Overview

  • Amazon Bedrock is a fully managed service that provides access to high-performing foundation models (FMs) from leading AI companies through a single API.
  • Bedrock enables building and scaling generative AI applications without managing infrastructure or training models from scratch.
  • All data remains private — Bedrock does NOT use customer data to train or improve base models.
  • Supports text generation, image generation, embeddings, chat, and multi-modal use cases.

Foundation Models

  • Amazon — Nova (Micro, Lite, Pro, Premier), Titan (Text, Embeddings, Image, Multimodal)
  • Anthropic — Claude (Haiku, Sonnet, Opus) family
  • Meta — Llama 3.x and Llama 4 models
  • Mistral AI — Mistral Large, Mistral Small
  • Cohere — Command R, Command R+, Embed
  • AI21 Labs — Jamba models
  • Stability AI — Stable Diffusion (image generation)
  • DeepSeek — DeepSeek-R1 (reasoning model)
  • Models are accessed via the InvokeModel API — no need to provision instances.
  • Cross-Region Inference — automatically routes requests to available regions for higher throughput.
  • Inference Profiles — predefined configurations for consistent model behavior.

Amazon Bedrock Agents

  • Build autonomous AI agents that can plan, orchestrate, and execute multi-step tasks.
  • Agents can invoke APIs, query databases, and interact with enterprise systems.
  • Action Groups — define what actions an agent can take (Lambda functions, API schemas).
  • Knowledge Bases — give agents access to company data for RAG (Retrieval-Augmented Generation).
  • Multi-agent collaboration — agents can delegate tasks to other specialized agents.
  • Return of control — pause agent execution and return control to the application for human-in-the-loop workflows.
  • Code Interpreter — agents can generate and execute code to perform calculations and data analysis.
  • Memory — agents retain context across conversations for personalized interactions.

Amazon Bedrock Knowledge Bases

  • Implements Retrieval-Augmented Generation (RAG) — connects FMs to company data sources.
  • Data sources: S3, Confluence, SharePoint, Salesforce, Web Crawler, custom connectors.
  • Vector stores: OpenSearch Serverless, Aurora PostgreSQL, Pinecone, Redis Enterprise, MongoDB Atlas, Neptune Analytics.
  • Chunking strategies: Fixed-size, semantic, hierarchical, no chunking.
  • Parsing: Built-in parsers for PDF, Word, HTML, Markdown, CSV, Excel.
  • Advanced RAG:
    • Metadata filtering — filter results by document attributes
    • Hybrid search — combines semantic + keyword search
    • Re-ranking — uses a re-ranker model to improve result relevance
    • Query decomposition — breaks complex queries into sub-queries
  • GraphRAG — uses knowledge graphs (Neptune) for relationship-aware retrieval.

Amazon Bedrock Guardrails

  • Implement safeguards for generative AI applications — works with any FM on Bedrock or custom models.
  • Content filters — block harmful content categories (hate, insults, sexual, violence, misconduct) with configurable thresholds.
  • Denied topics — define topics the model should refuse to discuss.
  • Word filters — block specific words, phrases, or profanity.
  • Sensitive information filters (PII) — detect and redact/mask PII (names, SSN, credit cards, etc.).
  • Contextual grounding checks — detect hallucinations by verifying responses against source material.
  • Automated Reasoning checks — uses formal logic to validate factual accuracy.
  • Guardrails can be applied to both inputs and outputs.
  • Works with Bedrock Agents, Knowledge Bases, and direct InvokeModel calls.
  • ApplyGuardrail API — apply guardrails to any text, even outside Bedrock.

Amazon Bedrock Model Customization

  • Fine-tuning — train a model on your specific data to improve performance for your use case.
  • Continued Pre-training — train a model on domain-specific unlabeled data for deeper domain knowledge.
  • Model Distillation — transfer capabilities from a larger teacher model to a smaller, faster student model.
  • Custom models are private — only accessible in your account.
  • Training data stored in S3, encrypted with KMS.
  • Provisioned Throughput — purchase dedicated capacity for custom or base models for consistent performance.

Amazon Bedrock Model Evaluation

  • Compare model performance using automatic evaluation (built-in metrics) or human evaluation (human reviewers).
  • Automatic metrics: accuracy, robustness, toxicity, BERTScore, ROUGE.
  • LLM-as-a-judge — use a foundation model to evaluate outputs of other models.
  • Compare multiple models side-by-side for your specific use case.
  • Results stored in S3 for analysis.

Amazon Bedrock Flows

  • Visual workflow builder for creating generative AI pipelines.
  • Chain prompts, knowledge bases, agents, guardrails, and Lambda functions into workflows.
  • Supports conditional branching, parallel execution, and iterative loops.
  • Version and deploy flows independently.

Amazon Bedrock Prompt Management

  • Create, version, and manage prompts centrally.
  • Prompt variables — use placeholders for dynamic content.
  • Prompt Caching — cache context for frequently used long prompts to reduce latency and cost.
  • Intelligent Prompt Routing — automatically routes requests to the optimal model based on prompt complexity.

Amazon Bedrock Studio

  • Web-based playground for non-technical users to build and test generative AI applications.
  • Create projects with shared resources (agents, knowledge bases, guardrails).
  • SSO integration via IAM Identity Center for team collaboration.

Amazon Nova Models

  • Amazon’s own family of foundation models, purpose-built for Bedrock.
  • Nova Micro — text-only, lowest latency, lowest cost (ideal for simple tasks).
  • Nova Lite — multimodal (text, image, video input), fast and cost-effective.
  • Nova Pro — multimodal, best balance of accuracy, speed, and cost.
  • Nova Premier — most capable, best for complex reasoning and agentic workflows.
  • Nova Canvas — image generation with watermark detection.
  • Nova Reel — video generation (up to 6 seconds).
  • Nova Sonic — speech-to-speech model for natural conversations.

Bedrock Security

  • Data privacy — customer data is NOT used to train base models; model inputs/outputs are not shared.
  • Encryption — data encrypted in transit (TLS 1.2+) and at rest (KMS). Customer-managed keys supported.
  • VPC connectivity — access Bedrock via VPC endpoints (PrivateLink) for private network traffic.
  • IAM integration — fine-grained access control with IAM policies, resource-based policies.
  • Model access control — explicitly enable which models are available in your account.
  • CloudTrail logging — all API calls logged for auditing.
  • Model Invocation Logging — log prompts and responses to S3/CloudWatch for compliance.
  • Service Control Policies — restrict Bedrock usage at the organization level.

Bedrock Pricing

  • On-Demand — pay per input/output token (no commitment, most flexible).
  • Batch Inference — up to 50% cheaper for non-time-sensitive workloads.
  • Provisioned Throughput — reserved capacity with committed model units (1-month or 6-month terms).
  • Model Customization — charged per training token processed.
  • Knowledge Bases — charged per storage and retrieval query.
  • Guardrails — charged per 1,000 text units processed.

AWS Certification Exam Practice Questions

  1. A company wants to build a customer support chatbot that can access company documentation stored in S3 to answer questions accurately. Which Bedrock feature should they use?
    1. Fine-tuning
    2. Knowledge Bases (RAG)
    3. Guardrails
    4. Model Evaluation
  2. An organization needs to ensure their generative AI application never discusses competitor products and redacts any PII from responses. Which Bedrock feature provides this?
    1. Knowledge Bases
    2. Model Customization
    3. Guardrails (denied topics + PII filters)
    4. Prompt Management
  3. A startup wants to reduce the latency and cost of their Bedrock application that uses Claude for simple classification tasks. Which approach is most cost-effective?
    1. Provisioned Throughput for Claude
    2. Fine-tune Claude on classification data
    3. Use Intelligent Prompt Routing or switch to Nova Micro
    4. Use Batch Inference
  4. A financial services company requires that all Bedrock API traffic stays within their private network and all prompts/responses are logged for regulatory compliance. Which features should they enable?
    1. CloudTrail + S3 encryption
    2. VPC endpoints (PrivateLink) + Model Invocation Logging
    3. Guardrails + Knowledge Bases
    4. IAM policies + Batch Inference
  5. A company wants an AI agent that can look up customer orders in DynamoDB, check shipping status via an API, and send email notifications. Which Bedrock feature enables this?
    1. Knowledge Bases
    2. Bedrock Flows
    3. Bedrock Agents with Action Groups
    4. Model Customization
  6. An enterprise needs to transfer the capabilities of a large, expensive model to a smaller model for production use to reduce inference costs while maintaining quality. Which feature supports this?
    1. Fine-tuning
    2. Continued Pre-training
    3. Model Distillation
    4. Provisioned Throughput

Related Posts

References

Amazon Bedrock User Guide

Amazon Bedrock Agents

Amazon Bedrock Knowledge Bases

Amazon Bedrock Guardrails

Amazon Bedrock Pricing

AWS Route 53 Routing Policies Comparison

AWS Route 53 Routing Policies Comparison

  • Amazon Route 53 supports 7 routing policies that determine how DNS queries are answered.
  • Choosing the right routing policy depends on whether you need failover, latency optimization, geographic restrictions, or traffic distribution.
  • Multiple policies can be combined using alias records and health checks for complex routing architectures.

Route 53 Routing Policies Comparison

Policy Use Case How It Works Health Checks
Simple Single resource, no special routing Returns all values in random order No (can’t attach)
Weighted Traffic distribution, blue/green, A/B testing Routes based on assigned weights (0-255) Yes
Latency-based Best performance for global users Routes to region with lowest latency Yes
Failover Active-passive disaster recovery Primary until unhealthy, then secondary Yes (required for primary)
Geolocation Content localization, compliance, restrictions Routes based on user’s geographic location Yes
Geoproximity Route based on resource location + bias Routes to nearest resource; bias expands/shrinks coverage Yes
Multivalue Answer Simple load balancing with health checks Returns up to 8 healthy records randomly Yes
IP-based Route by client IP/CIDR (ISP optimization) Routes based on client subnet CIDR mapping Yes

Simple Routing

  • Routes traffic to a single resource (or multiple values returned in random order).
  • Cannot attach health checks to simple routing records.
  • If multiple values are returned, client chooses one randomly (client-side load balancing).
  • Can only have one record per name with simple routing.
  • Best for: Single server, single resource behind a load balancer.

Weighted Routing

  • Routes traffic based on weights assigned to records (0-255).
  • Traffic proportion = record weight / sum of all weights for the same name.
  • Setting weight to 0 stops traffic to that resource (useful for maintenance).
  • If all records have weight 0, traffic is distributed equally.
  • Supports health checks – unhealthy records removed from responses.
  • Best for: Blue/green deployments (90/10 split), A/B testing, gradual migrations, load distribution across regions.

Latency-based Routing

  • Routes traffic to the region with the lowest network latency for the user.
  • Latency is measured between the user’s DNS resolver and AWS regions.
  • Requires resources in multiple AWS regions.
  • Supports health checks – if lowest-latency resource is unhealthy, routes to next-best.
  • Latency data is updated periodically by AWS (not real-time per request).
  • Best for: Global applications deployed in multiple regions needing best user experience.

Failover Routing

  • Routes traffic to primary resource when healthy, secondary when primary fails health check.
  • Active-passive configuration – only one designation per record set (primary or secondary).
  • Health check required on primary record; optional on secondary.
  • Secondary can point to a static S3 website (maintenance page) or another resource.
  • Can be combined with other routing policies using alias records.
  • Best for: Disaster recovery, maintenance pages, active-passive HA architectures.

Geolocation Routing

  • Routes traffic based on geographic location of the user (continent, country, or US state).
  • Most specific match wins – state > country > continent > default.
  • A default record is recommended – users from unmapped locations get this response.
  • If no default and no match, Route 53 returns “no answer”.
  • Does NOT route to closest resource – routes to the location you configure (use geoproximity for nearest).
  • Best for: Content localization (language), compliance (restrict access by country), serving region-specific content.

Geoproximity Routing

  • Routes traffic based on geographic distance between user and resources.
  • Bias values (-99 to +99) expand or shrink the geographic area that routes to a resource.
  • Positive bias = attracts more traffic (expands coverage area).
  • Negative bias = repels traffic (shrinks coverage area).
  • Supports both AWS resources (auto-detects region) and non-AWS resources (specify latitude/longitude).
  • Requires Route 53 Traffic Flow to use geoproximity routing.
  • Best for: Routing to nearest resource with ability to shift traffic between regions using bias.

Multivalue Answer Routing

  • Returns up to 8 healthy records in response to each DNS query.
  • Similar to simple routing but supports health checks – only healthy resources returned.
  • Not a substitute for a load balancer but provides basic DNS-level load balancing with health checking.
  • Each record can have its own health check.
  • Best for: Basic load distribution with health checking when you don’t need ELB.

IP-based Routing

  • Routes traffic based on client’s source IP address mapped to CIDR blocks.
  • Create CIDR collections with locations, then map records to locations.
  • Useful when you know the IP ranges of your users (corporate networks, ISPs).
  • More precise than geolocation – routes based on actual network, not estimated location.
  • Best for: ISP-specific routing, enterprise users with known IP ranges, optimizing costs by routing to specific endpoints.

Combining Routing Policies

  • Alias records can point to other Route 53 record sets, enabling policy combinations.
  • Example: Latency → Weighted (route to nearest region, then split between blue/green within region).
  • Example: Failover → Latency (primary is latency-based across regions, secondary is S3 static page).
  • Example: Geolocation → Failover (per-country routing with DR fallback).
  • Traffic Flow – visual editor for building complex routing trees with multiple policies.

AWS Certification Exam Practice Questions

  1. A company wants to gradually migrate traffic from an on-premises data center to AWS by sending 10% of traffic to AWS initially, increasing over time. Which routing policy supports this?
    1. Latency-based
    2. Weighted
    3. Failover
    4. Geolocation
  2. An application deployed in us-east-1 and eu-west-1 should route users to whichever region provides the fastest response. Which routing policy is appropriate?
    1. Geolocation
    2. Geoproximity
    3. Latency-based
    4. Weighted (50/50)
  3. A streaming service must serve different content libraries to users in different countries due to licensing restrictions. Which routing policy enforces this?
    1. Latency-based
    2. Geolocation
    3. Geoproximity
    4. IP-based
  4. A company needs to route traffic to the nearest data center but temporarily shift more traffic to a new region during a migration. Which routing policy allows adjusting the geographic coverage area?
    1. Geolocation with failover
    2. Weighted with latency
    3. Geoproximity with bias
    4. Multivalue answer
  5. An architect needs DNS-level health checking where unhealthy endpoints are automatically removed from DNS responses, but a full load balancer is not required. Which policy provides this with multiple IPs?
    1. Simple routing
    2. Weighted routing
    3. Failover routing
    4. Multivalue answer routing

Related Posts

References

Route 53 Routing Policies

Route 53 Traffic Flow

AWS Transit Gateway vs VPC Peering vs PrivateLink

AWS Transit Gateway vs VPC Peering vs PrivateLink

  • AWS provides multiple VPC connectivity options, each designed for different network topologies and use cases.
  • VPC Peering is point-to-point, Transit Gateway is a hub for many-to-many connectivity, and PrivateLink is for private service access without network exposure.
  • Choice depends on number of VPCs, routing requirements, security posture, and cost.

Transit Gateway vs VPC Peering vs PrivateLink Comparison

Feature VPC Peering Transit Gateway PrivateLink
Topology Point-to-point (1:1) Hub-and-spoke (many:many) Service endpoint (consumer:provider)
Transitive Routing No Yes No (service access only)
Scale 125 peering connections per VPC 5,000 attachments per TGW Unlimited endpoints
Cross-Region Yes (inter-region peering) Yes (inter-region peering) Yes (with inter-region support)
Cross-Account Yes Yes (RAM sharing) Yes
CIDR Overlap Not allowed Not allowed (per attachment) Allowed (uses ENI in consumer VPC)
Network Exposure Full VPC network visible to peer Full VPC network via route tables Only the service endpoint exposed
Bandwidth No limit (same as inter-AZ) Up to 50 Gbps per attachment Up to 100 Gbps per endpoint
Cost Data transfer only (no hourly charge) Hourly per attachment + data processing Hourly per endpoint + data processing
Use Case Few VPCs, simple connectivity Many VPCs, centralized routing, VPN/DX aggregation Expose service privately, SaaS connectivity, zero-trust
Route Management Update route tables in both VPCs Centralized route tables on TGW No route table changes needed
Security Security groups + NACLs Security groups + NACLs + TGW route tables Minimum exposure (only service port)

When to Choose Which

  • Choose VPC Peering – Small number of VPCs (2-5), simple point-to-point connectivity, lowest cost, no transitive routing needed.
  • Choose Transit Gateway – Many VPCs needing full mesh connectivity, centralized VPN/Direct Connect, shared services VPC, network segmentation with route tables.
  • Choose PrivateLink – Expose a specific service to other accounts/VPCs without full network access, overlapping CIDRs, SaaS service consumption, zero-trust architecture.
  • Combine TGW + PrivateLink – Transit Gateway for general connectivity between VPCs, PrivateLink for specific service access with minimal exposure.

AWS Certification Exam Practice Questions

  1. A company has 50 VPCs that all need to communicate with a shared services VPC and a centralized Direct Connect connection. Which connectivity solution scales best?
    1. VPC Peering (50 connections)
    2. Transit Gateway
    3. PrivateLink
    4. VPN to each VPC
  2. A SaaS provider needs to expose their service to customers in different AWS accounts without exposing their entire VPC network. The customer VPCs have overlapping CIDR ranges. Which solution works?
    1. VPC Peering
    2. Transit Gateway
    3. PrivateLink
    4. Site-to-Site VPN
  3. Two VPCs in the same region need connectivity. The traffic volume is minimal, cost is a priority, and no transitive routing is needed. What is the most cost-effective solution?
    1. Transit Gateway
    2. VPC Peering
    3. PrivateLink
    4. AWS Cloud WAN
  4. An organization needs VPC A to route traffic through VPC B to reach VPC C. Which service supports this transitive routing?
    1. VPC Peering
    2. PrivateLink
    3. Transit Gateway
    4. Internet Gateway

Related Posts

References

AWS Transit Gateway Guide

VPC Peering Guide

AWS PrivateLink Guide

AWS CloudFront vs Global Accelerator

AWS CloudFront vs Global Accelerator

  • Both CloudFront and Global Accelerator use the AWS global edge network to improve performance, but they serve different purposes.
  • CloudFront is a Content Delivery Network (CDN) that caches content at edge locations.
  • Global Accelerator routes traffic over the AWS backbone to the optimal regional endpoint without caching.

CloudFront vs Global Accelerator Comparison

Feature CloudFront Global Accelerator
Purpose Content caching and delivery (CDN) Network traffic acceleration (no caching)
Layer Layer 7 (HTTP/HTTPS/WebSocket) Layer 4 (TCP/UDP)
Caching Yes – caches content at 400+ edge locations No caching – proxies all requests to origin
Static IP No (uses DNS-based routing) Yes – 2 anycast static IPs
IP Whitelisting Difficult (IPs change) Easy (fixed anycast IPs)
Protocols HTTP, HTTPS, WebSocket TCP, UDP
DNS Propagation Affected by DNS TTL during failover Instant failover (no DNS change, same IPs)
Failover Origin failover (primary/secondary) Automatic endpoint failover (<30 seconds)
DDoS Protection AWS Shield Standard (Shield Advanced optional) AWS Shield Standard (Shield Advanced optional)
WAF Integration Yes (AWS WAF) No
Origins/Endpoints S3, ALB, EC2, custom HTTP origins ALB, NLB, EC2, Elastic IP
Client Affinity No (stateless caching) Yes (source IP based)
Best For Static/dynamic web content, APIs, video streaming Gaming, IoT, VoIP, non-HTTP apps needing fixed IPs

When to Choose Which

  • Choose CloudFront – Web applications, static asset delivery, video streaming, API acceleration with caching, need WAF integration.
  • Choose Global Accelerator – Non-HTTP protocols (TCP/UDP gaming, IoT), need static IP for whitelisting, instant failover without DNS propagation, multi-region active-active.
  • Use Both Together – CloudFront for cacheable content + Global Accelerator for the origin endpoint requiring fixed IPs and fast failover.

AWS Certification Exam Practice Questions

  1. A gaming company needs to route UDP traffic to the nearest regional server with sub-30-second failover and static IPs for firewall whitelisting. Which service should they use?
    1. CloudFront
    2. Route 53 latency-based routing
    3. Global Accelerator
    4. ALB with multi-region
  2. A media company wants to serve video content and static assets globally with lowest latency and reduce origin load. Which service is most appropriate?
    1. Global Accelerator
    2. CloudFront
    3. S3 Transfer Acceleration
    4. Route 53 geolocation routing
  3. An application needs both fast failover (no DNS propagation delay) and static anycast IP addresses for a TCP-based service. The content is dynamic and cannot be cached. Which service fits?
    1. CloudFront with cache disabled
    2. Global Accelerator
    3. Route 53 with health checks
    4. NLB with Elastic IPs

Related Posts

References

Amazon CloudFront Developer Guide

AWS Global Accelerator Developer Guide

AWS VPN

AWS VPC VPN

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

AWS Site-to-Site VPN Options (2025)

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

VPN Components

AWS VPN Components

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

VPN Routing Options

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

VPN Route Priority

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

VPN Bandwidth and Throughput

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

VPN Limitations

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

VPN Tunnel Endpoint Lifecycle Control

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

VPN Monitoring

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

IPv6 Support for Site-to-Site VPN

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

VPN Concentrator (November 2025)

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

VPN Connection Redundancy

VPN Connection Redundancy

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

Multiple Site-to-Site VPN Connections

VPN Connection

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

VPN CloudHub

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

VPN CloudHub Architecture

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

Private IP VPN over Direct Connect

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

Accelerated Site-to-Site VPN

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

VPN vs Direct Connect

AWS Direct Connect vs VPN

VPN Quotas

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

AWS Certification Exam Practice Questions

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

References

AWS VPC Endpoints – Gateway & Interface Endpoints

VPC Endpoints

AWS VPC Endpoints

  • VPC Endpoints enable the creation of a private connection between VPC to supported AWS services and VPC endpoint services powered by PrivateLink using its private IP address
  • Endpoints do not require a public IP address, access over the Internet, NAT device, a VPN connection, or AWS Direct Connect.
  • Traffic between VPC and AWS service does not leave the Amazon network
  • Endpoints are virtual devices, that are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and AWS services without imposing availability risks or bandwidth constraints on your network traffic.
  • AWS currently supports the following types of Endpoints
    • VPC Gateway Endpoints – target for a route in a route table (S3 and DynamoDB only, free)
    • VPC Interface Endpoints (PrivateLink) – ENI-based, supports 100+ AWS services
    • VPC Resource Endpoints (GA Dec 2024) – direct access to VPC resources (e.g., RDS, EC2 instances, IP/domain targets) across accounts without a load balancer
    • Gateway Load Balancer Endpoints – route traffic to network virtual appliances (firewalls, IDS/IPS) deployed behind a Gateway Load Balancer

VPC Endpoints

VPC Gateway Endpoints

  • A VPC Gateway Endpoint is a gateway that is a target for a specified route in the route table, used for traffic destined for a supported AWS service.
  • Gateway Endpoints currently supports S3 and DynamoDB services only.
  • Gateway Endpoints do not require an Internet gateway or a NAT device for the VPC.
  • Gateway endpoints do not enable AWS PrivateLink.
  • Gateway Endpoints are available at no additional charge.
  • Gateway Endpoints do not support cross-region requests – they must be created in the same Region as the S3 bucket or DynamoDB table.
  • Gateway Endpoints do not allow access from on-premises networks, from peered VPCs in other AWS Regions, or through a Transit Gateway. Use Interface Endpoints for those scenarios.
  • VPC Endpoint policy and Resource-based policies can be used for fine-grained access control.
  • S3 Gateway Endpoints now support IPv6 (announced November 2025) – both dual-stack and IPv6-only configurations are supported.
"AWS

VPC Interface Endpoints – PrivateLink

AWS Private Links

  • VPC Interface endpoints enable connectivity to services powered by AWS PrivateLink.
  • Services include AWS services like CloudTrail, CloudWatch, etc., services hosted by other AWS customers and partners in their own VPCs (referred to as endpoint services), and supported AWS Marketplace partner services.
  • Interface Endpoints only allow traffic from VPC resources to the endpoints and not vice versa.
  • PrivateLink endpoints can be accessed across both intra- and inter-region VPC peering connections, Direct Connect, and VPN connections.
  • VPC Interface Endpoints, by default, have an address like vpce-svc-01234567890abcdef.us-east-1.vpce.amazonaws.com which needs application changes to point to the service.
  • Private DNS name feature allows consumers to use AWS service public default DNS names which would point to the private VPC endpoint service.
  • Interface Endpoints can be used to create custom applications in VPC and configure them as an AWS PrivateLink-powered service (referred to as an endpoint service) exposed through a Network Load Balancer.
  • Custom applications can be hosted within AWS or on-premises (via Direct Connect or VPN)
  • Interface Endpoints are billed per hour per AZ provisioned, plus per-GB data processing charges. See AWS PrivateLink Pricing.

Cross-Region PrivateLink (GA November 2024)

  • AWS PrivateLink now supports native cross-region connectivity, breaking the previous limitation that VPC endpoints were regional-only.
  • As a service consumer, you can privately connect to VPC endpoint services hosted in other AWS Regions within the same partition, without cross-region peering or exposing data to the public internet.
  • As a service provider, you can offer your endpoint service to customers in all Regions from a single Region without deploying infrastructure in each Region.
  • Cross-region connectivity for custom endpoint services (customer-hosted) launched Nov 2024.
  • Cross-region connectivity for AWS services (e.g., S3, ECR, Route 53) launched Nov 2025.
  • Traffic remains on the AWS backbone and does not traverse the public internet.
  • Available within the same AWS partition (commercial, GovCloud, China) across all supported Regions.

VPC Resource Endpoints (GA December 2024)

  • Resource Endpoints are a new type of VPC endpoint introduced at re:Invent 2024 that provide private access to specific VPC resources across accounts.
  • Resource Endpoints allow you to privately access a resource (e.g., an RDS database, EC2 instance, IP address, or domain name) in another VPC without requiring a Network Load Balancer.
  • A VPC resource is represented by a resource configuration, which is associated with a resource gateway.
  • Resources can be shared across accounts using AWS Resource Access Manager (RAM).
  • Supports TCP traffic only (UDP is not supported).
  • Network connections must be initiated from the VPC containing the resource endpoint (unidirectional).
  • Currently supported ARN-based resources include Amazon RDS instances.
  • Also supports connectivity to any resource by IP address or domain name target.
  • DNS names are automatically provisioned with format: endpoint_id.rcfgId.randomHash.vpc-lattice-rsc.region.on.aws
  • Private DNS is supported for ARN-based resources (e.g., RDS), allowing continued use of the resource’s original DNS name.
  • Supports IPv4, IPv6, and dual-stack addressing.
  • Integrates with Amazon VPC Lattice for advanced service networking scenarios.
  • Billed per hour per endpoint provisioned, plus per-GB data processing. Resource gateways billed per-GB data processed.

Gateway Load Balancer Endpoints

  • Gateway Load Balancer (GWLB) Endpoints provide private connectivity between your VPC and network virtual appliances (firewalls, IDS/IPS, deep packet inspection) deployed in a service provider VPC behind a Gateway Load Balancer.
  • GWLB Endpoints serve as an entry/exit point in your VPC for traffic inspection.
  • Used as a target in route tables to transparently route traffic through security appliances.
  • Each GWLB endpoint can support up to 10 Gbps per AZ and auto-scales up to 100 Gbps.
  • Supports ingress routing from Internet Gateway and Virtual Private Gateway for inline traffic inspection.
  • Commonly used in centralized security inspection architectures with AWS Transit Gateway.

S3 VPC Endpoints Strategy

S3 is now accessible with both Gateway Endpoints and Interface Endpoints.

  • Gateway Endpoint – Free, route-table based, same-Region only, no on-premises or cross-region access. Recommended for most in-Region workloads.
  • Interface Endpoint – Hourly + per-GB charges, ENI-based, accessible from on-premises (via Direct Connect/VPN), across VPC peering, Transit Gateway, and now cross-region (via Cross-Region PrivateLink, Nov 2025).
  • Both Gateway and Interface VPC Endpoints for S3 now support IPv6 (November 2025).

S3 Strategy - VPC Gateway Endpoints vs VPC Interface Endpoints

VPC Endpoint Policies & Security

  • VPC Endpoint policies control which AWS principals can use the endpoint to access the service.
  • Endpoint policies can be attached to Gateway, Interface, and Resource endpoints.
  • Security groups can be attached to Interface and Resource endpoints to control inbound/outbound traffic.
  • New IAM Condition Keys (August 2025) for organization-wide network perimeter controls:
    • aws:VpceAccount – Restrict requests based on the account that owns the VPC endpoint.
    • aws:VpceOrgID – Restrict based on the AWS Organization ID of the endpoint owner.
    • aws:VpceOrgPaths – Restrict based on organizational unit paths of the endpoint owner.
  • These new keys complement the existing aws:sourceVpce and aws:sourceVpc condition keys and enable scalable network perimeter controls across entire AWS Organizations without hard-coding VPC endpoint IDs.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have an application running on an Amazon EC2 instance that uploads 10 GB video objects to amazon S3. Video uploads are taking longer than expected inspite of using multipart upload cause of internet bandwidth, resulting in poor application performance. Which action can help improve the upload performance?
    1. Apply an Amazon S3 bucket policy
    2. Use Amazon EBS provisioned IOPS
    3. Use VPC endpoints for S3
    4. Request a service limit increase
  2. What are the services supported by VPC endpoints, using Gateway endpoint type? Choose 2 answers
    1. Amazon S3
    2. Amazon EFS
    3. Amazon DynamoDB
    4. Amazon Glacier
    5. Amazon SQS
  3. What are the different types of endpoint types supported by VPC endpoints? Choose 2 Answers [Note: As of 2024, AWS now supports additional endpoint types including Resource Endpoints and Gateway Load Balancer Endpoints. This question reflects the original SAA exam scope.]
    1. Gateway
    2. Classic
    3. Interface
    4. Virtual
    5. Network
  4. An application running on EC2 instances processes sensitive information stored on Amazon S3. The information is accessed over the Internet. The security team is concerned that the Internet connectivity to Amazon S3 is a security risk. Which solution will resolve the security concern?
    1. Access the data through an Internet Gateway.
    2. Access the data through a VPN connection.
    3. Access the data through a NAT Gateway.
    4. Access the data through a VPC endpoint for Amazon S3.
  5. You need to design a VPC for a three-tier architecture, a web application consisting of an Elastic Load Balancer (ELB), a fleet of web/application servers, and a backend consisting of an RDS database. The entire Infrastructure must be distributed over 2 availability zones. Which VPC configuration works while assuring the least components are exposed to Internet?
    1. Two public subnets for ELB, two private subnets for the web-servers, two private subnets for RDS and DynamoDB
    2. Two public subnets for ELB and web-servers, two private subnets for RDS and DynamoDB
    3. Two public subnets for ELB, two private subnets for the web-servers, two private subnets for RDS and VPC Endpoints for DynamoDB
    4. Two public subnets for ELB and web-servers, two private subnets for RDS and VPC Endpoints for DynamoDB
  6. A company needs to access Amazon S3 buckets in a different AWS Region privately without exposing traffic to the public internet. Which solution should they use?
    1. Use Gateway VPC Endpoints for cross-region S3 access
    2. Use Interface VPC Endpoints with Cross-Region PrivateLink for S3
    3. Set up VPC peering between regions and use Gateway Endpoints
    4. Use AWS Direct Connect with public VIF
  7. A SaaS provider needs to give customers in multiple AWS accounts private access to an Amazon RDS database without deploying a Network Load Balancer. Which solution meets this requirement?
    1. Create a VPC peering connection to each customer account
    2. Use an Interface VPC Endpoint with an NLB in front of the RDS instance
    3. Create a resource configuration for the RDS instance and share it via AWS RAM, allowing customers to create Resource Endpoints
    4. Use AWS Transit Gateway to connect all customer VPCs
  8. A security team wants to ensure that all API requests from their AWS Organization pass through their organization’s VPC endpoints, without hard-coding individual endpoint IDs in policies. Which approach should they use?
    1. Use aws:sourceVpce condition key with wildcard values
    2. Use aws:sourceVpc condition key listing all VPC IDs
    3. Use aws:VpceOrgID condition key to validate requests originate from endpoints owned by their organization
    4. Create a custom IAM policy for each VPC endpoint

References

AWS PrivateLink – VPC Endpoints

Access VPC Resources through AWS PrivateLink

AWS Announces Access to VPC Resources over PrivateLink (Dec 2024)

AWS PrivateLink Cross-Region Connectivity (Nov 2024)

Cross-Region PrivateLink for AWS Services (Nov 2025)

IPv6 for Amazon S3 VPC Endpoints (Nov 2025)

New VPC Endpoint IAM Condition Keys (Aug 2025)

Gateway Load Balancer Endpoints

AWS VPC Peering – Cross-Account, Cross-Region & Limitations

AWS VPC Peering

VPC Peering

🆕 Recent Updates (2025)

  • March 2025: Inter-region VPC peering now supports jumbo frames (up to 8500 bytes MTU) and full instance bandwidth.
  • April 2025: VPC Peering billing simplified with dedicated usage type for better cost visibility.
  • November 2025: VPC Encryption Controls launched to audit and enforce encryption on VPC peering traffic.
  • A VPC peering connection is a networking connection between two VPCs that enables routing of traffic between them using private IPv4 addresses or IPv6 addresses.
  • VPC peering connection
    • can be established between your own VPCs, or with a VPC in another AWS account in the same or different region.
    • is a one-to-one relationship between two VPCs.
    • supports intra and inter-region peering connections.
  • With VPC peering,
    • Instances in either VPC can communicate with each other as if they are within the same network
    • AWS uses the existing infrastructure of a VPC to create a peering connection; it is neither a gateway nor a VPN connection and does not rely on a separate piece of physical hardware.
    • There is no single point of failure for communication or a bandwidth bottleneck
    • All inter-region traffic is encrypted with no single point of failure, or bandwidth bottleneck. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks.
    • EC2 instances can use full instance bandwidth for inter-region VPC peering traffic (previously limited to 50% for instances with 32+ vCPUs, or 5 Gbps for smaller instances).
  • VPC peering pricing
    • There is no charge to create a VPC peering connection.
    • All data transfer over a VPC peering connection that stays within an Availability Zone (AZ) is free, even if it’s between different accounts.
    • Charges apply for data transfer over VPC peering connections that cross Availability Zones and Regions.
    • Since April 2025, VPC Peering billing uses a dedicated usage type (Region-Name-VpcPeering-In/Out-Bytes) for easier cost tracking in Cost Explorer and Cost and Usage Reports.

AWS VPC Peering

VPC Peering Connectivity

  • To create a VPC peering connection, the owner of the requester VPC sends a request to the owner of the accepted VPC.
  • Accepter VPC can be owned by the same account or a different AWS account.
  • Once the Accepter VPC accepts the peering connection request, the peering connection is activated.
  • Route tables on both the VPCs should be manually updated to allow traffic
  • Security groups on the instances should allow traffic to and from the peered VPCs.

VPC Peering Limitations & Rules

  1. Does not support Overlapping or matching IPv4 or IPv6 CIDR blocks.
  2. Does not support transitive peering relationships i.e. the VPC does not have access to any other VPCs that the peer VPC may be peered with even if established entirely within your own AWS account
  3. Does not support Edge to Edge Routing Through a Gateway or Private Connection
  4. In a VPC peering connection, the VPC does not have access to any other connection that the peer VPC may have and vice versa. Connections that the peer VPC can include
    1. A VPN connection or an AWS Direct Connect connection to a corporate network
    2. An Internet connection through an Internet gateway
    3. An Internet connection in a private subnet through a NAT device
    4. A VPC endpoint to an AWS service; for example, an endpoint to S3.
  5. VPC peering connections quotas
    • Default limit of 50 active VPC peering connections per VPC, which can be increased up to a maximum of 125.
    • Default limit of 25 outstanding VPC peering connection requests.
    • Unaccepted VPC peering connection requests expire after 1 week (168 hours).
  6. Only one peering connection can be established between the same two VPCs at the same time.
  7. Jumbo frames (MTU up to 8500 bytes) are supported for peering connections both within the same region and across regions.
  8. A placement group can span peered VPCs that are in the same region; however, you do not get full-bisection bandwidth between instances in peered VPCs
  9. Inter-region VPC peering connections
    1. Updated March 2025: The Maximum Transmission Unit (MTU) across an inter-region peering connection is now 8500 bytes (jumbo frames supported). Previously limited to 1500 bytes.
    2. Security group rule that references a peer VPC security group cannot be created for cross-region peering.
    3. EC2 instances can use full instance bandwidth for inter-region peering (no longer limited to 50% or 5 Gbps).
  10. Any tags created for the peering connection are only applied in the account or region in which they were created
  11. Unicast reverse path forwarding in peering connections is not supported
  12. Instance’s Public DNS can be resolved to its private IP address across peered VPCs when DNS resolution is enabled for the VPC peering connection.

⚠️ DEPRECATED FEATURE

EC2-Classic and ClassicLink were retired on August 15, 2023.

The original content mentioned ClassicLink connections to EC2-Classic instances. This feature is no longer available.

Migration: All resources must be migrated to VPC. EC2-Classic is no longer supported.

VPC Peering Encryption

  • All inter-region VPC peering traffic is encrypted with AES-256 before leaving AWS data centers.
  • Intra-region traffic between Nitro-based EC2 instances is also encrypted transparently.
  • VPC Encryption Controls (November 2025):
    • Provides ability to monitor, audit, and enforce encryption in transit within and across VPCs.
    • Automatically applies hardware-based AES-256 encryption on traffic between VPC resources including Fargate, NLB, and ALB.
    • Helps demonstrate compliance with encryption standards (HIPAA, PCI DSS).
    • Can identify VPC resources unintentionally allowing plaintext traffic.
    • Generates audit logs for compliance and reporting.

VPC Peering Troubleshooting

  • Verify that the VPC peering connection is in the Active state.
  • Be sure to update the route tables for the peering connection. Verify that the correct routes exist for connections to the IP address range of the peered VPCs through the appropriate gateway.
  • Verify that an ALLOW rule exists in the network access control (NACL) table for the required traffic.
  • Verify that the security group rules allow network traffic between the peered VPCs.
  • Verify using VPC flow logs that the required traffic isn’t rejected at the source or destination. This rejection might occur due to the permissions associated with security groups or network ACLs.
  • Be sure that no firewall rules block network traffic between the peered VPCs. Use network utilities such as traceroute (Linux) or tracert (Windows) to check rules for firewalls such as iptables (Linux) or Windows Firewall (Windows).
  • For DNS resolution issues, ensure that DNS resolution is enabled for the VPC peering connection to resolve public DNS hostnames to private IP addresses.

VPC Peering Architecture

AWS VPC Architecture

  • VPC Peering can be applied to create shared services or perform authentication with an on-premises instance
  • This would help create a single point of contact, as well limiting the VPN connections to a single account or VPC

VPC Peering vs Transit Gateway vs PrivateLink vs VPC Lattice

VPC Peering vs Transit VPC vs Transit Gateway

When to Use Each Solution

  • VPC Peering
    • Best for: Simple, direct connections between a small number of VPCs (typically less than 10)
    • Advantages: No additional cost for the connection itself, low latency, simple setup, full instance bandwidth inter-region
    • Limitations: Does not support transitive routing, becomes complex at scale (mesh topology), limited to 125 peering connections per VPC
  • AWS Transit Gateway
    • Best for: Hub-and-spoke architecture with many VPCs (10+), centralized routing, hybrid connectivity
    • Advantages: Supports transitive routing, centralized management, scales to thousands of VPCs, integrates with Direct Connect and VPN
    • Limitations: Additional cost per attachment and data processing, slightly higher latency than direct peering
  • AWS PrivateLink
    • Best for: Service-to-service connectivity, exposing services to multiple consumers, SaaS applications
    • Advantages: Unidirectional access, no VPC CIDR overlap issues, enhanced security, supports cross-account and cross-region access
    • Limitations: Requires Network Load Balancer or Gateway Load Balancer, additional cost, one-way communication by default
  • Amazon VPC Lattice
    • Best for: Application-layer service-to-service networking across VPCs and accounts
    • Advantages: No NLB required (unlike PrivateLink), built-in service discovery, IAM-based authorization, cross-VPC/cross-account without CIDR coordination, TLS termination at data plane
    • Limitations: Application-layer (L7) only, newer service with evolving feature set
    • Note: AWS App Mesh is being discontinued (EOL September 30, 2026); VPC Lattice is the recommended migration path

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 currently have 2 development environments hosted in 2 different VPCs in an AWS account in the same region. There is now a need for resources from one VPC to access another. How can this be accomplished?
    1. Establish a Direct Connect connection.
    2. Establish a VPN connection.
    3. Establish VPC Peering.
    4. Establish Subnet Peering.
  2. A company has an AWS account that contains three VPCs (Dev, Test, and Prod) in the same region. Test is peered to both Prod and Dev. All VPCs have non-overlapping CIDR blocks. The company wants to push minor code releases from Dev to Prod to speed up the time to market. Which of the following options helps the company accomplish this?
    1. Create a new peering connection Between Prod and Dev along with appropriate routes.
    2. Create a new entry to Prod in the Dev route table using the peering connection as the target.
    3. Attach a second gateway to Dev. Add a new entry in the Prod route table identifying the gateway as the target.
    4. The VPCs have non-overlapping CIDR blocks in the same account. The route tables contain local routes for all VPCs.
  3. A company has 2 AWS accounts that have individual VPCs. The VPCs are in different AWS regions and need to communicate with each other. The VPCs have non-overlapping CIDR blocks. Which of the following would be a cost-effective connectivity option?
    1. Use VPN connections
    2. Use VPC peering between the 2 VPC’s
    3. Use AWS Direct Connect
    4. Use a NAT gateway
  4. A company needs to connect 15 VPCs across multiple AWS accounts and regions with centralized routing and management. Which solution is most appropriate?
    1. Create VPC peering connections between all VPCs
    2. Use AWS Transit Gateway with a hub-and-spoke architecture
    3. Use AWS PrivateLink for all connections
    4. Use multiple VPN connections
  5. A SaaS provider wants to expose their application running in their VPC to multiple customer VPCs without requiring VPC peering or overlapping CIDR concerns. Which solution should they use?
    1. VPC Peering with each customer VPC
    2. AWS Transit Gateway
    3. AWS PrivateLink with VPC endpoint service
    4. Internet Gateway with security groups
  6. A company needs to transfer large amounts of data between VPCs in different AWS regions with maximum throughput. Which statement about inter-region VPC peering is correct? (Updated 2025)
    1. Inter-region VPC peering is limited to 1500 bytes MTU and 5 Gbps bandwidth
    2. Inter-region VPC peering does not support encryption
    3. Inter-region VPC peering supports jumbo frames (8500 bytes MTU) and full EC2 instance bandwidth
    4. Inter-region VPC peering requires a Transit Gateway attachment
  7. A company wants to audit and enforce encryption on all traffic flowing through their VPC peering connections to meet PCI DSS compliance. Which AWS feature should they use?
    1. AWS CloudTrail encryption logging
    2. VPC Flow Logs with encryption filter
    3. VPC Encryption Controls
    4. AWS Network Firewall with TLS inspection

Related Posts

References

AWS VPC Peering

VPC Peering Connection Quotas

EC2 Bandwidth and Jumbo Frames for Inter-Region Peering (March 2025)

VPC Peering Billing Simplification (April 2025)

VPC Encryption Controls (November 2025)