Why doesn't Bedrock use a Gateway Endpoint?

Imagine the scale.

Amazon S3 stores objects and is optimized for very high-bandwidth data transfer.

Gateway Endpoints were specifically designed for these storage services.

Amazon Bedrock is an API-based service. Each request is similar to making an HTTPS API call such as:

InvokeModel

API services fit naturally behind PrivateLink.

Why doesn't S3 use an Interface Endpoint?

It could, but it would be inefficient.

Suppose you're uploading a 10 TB dataset for model training.

If every byte flowed through an ENI, it would introduce unnecessary complexity and cost.

Gateway Endpoints are optimized for this kind of traffic.

Visual Comparison

Gateway Endpoint

EC2/Lambda

      │

 Route Table

      │

 Gateway Endpoint

      │

Amazon S3

Notice there is no network interface.

Interface Endpoint

EC2/Lambda

      │

Security Group

      │

Private ENI

      │

PrivateLink

      │

Amazon Bedrock

Notice the ENI and security group.

Security Differences

Gateway Endpoint

Security is controlled using:

Route tables

IAM policies

S3 bucket policies

DynamoDB policies

Endpoint policies

There are no security groups because there is no ENI.

Interface Endpoint

Security is controlled using:

Security groups

IAM policies

Endpoint policies

Because an Interface Endpoint has an ENI, it behaves like a network interface attached to your VPC.

Cost Comparison

Feature Gateway Endpoint Interface Endpoint

Hourly charge No Yes

Data processing charge No Yes (typically)

ENI created No Yes

Security groups No Yes

Route table entry Yes No (DNS resolves to ENI)

AI Workload Example

Suppose you're building a document Q&A system.

Documents

↓

Amazon S3

↓

Lambda

↓

Amazon Bedrock

↓

Secrets Manager

Recommended endpoints:

Service Endpoint Type Why

Amazon S3 Gateway Endpoint Efficient access to large document storage

Amazon Bedrock Interface Endpoint Private API calls to foundation models

AWS Secrets Manager Interface Endpoint Secure retrieval of credentials

Amazon CloudWatch Logs Interface Endpoint Private logging

AWS KMS Interface Endpoint Private encryption key operations

This minimizes internet exposure while using the most appropriate endpoint type for each service.

Exam Memory Trick

Think of it this way:

Gateway Endpoint = "Route me directly to a regional storage service."

➜ Used only for Amazon S3 and Amazon DynamoDB.

Interface Endpoint (PrivateLink) = "Give me a private network interface so I can call an API privately."

➜ Used for most AWS managed services, including Amazon Bedrock, AWS Secrets Manager, Amazon CloudWatch, AWS KMS, and many others.

Quick exam shortcut

If an AWS exam question asks:

"Need private access to Amazon S3 or DynamoDB?" → Choose a Gateway Endpoint.

"Need private access to almost any other AWS managed service (including Bedrock)?" → Choose an Interface Endpoint (AWS PrivateLink).

Remember that both keep traffic on the AWS network; they differ in how they provide that private connectivity and which services they support.

What is AWS Interface Endpoint (AWS PrivateLink)

This works differently.

AWS creates an Elastic Network Interface (ENI) inside your subnet.

           Private Subnet

 Lambda

    │

 ENI (Private IP)

    │

AWS PrivateLink

    │

Amazon Bedrock

From Lambda's perspective, it is communicating with a private IP address inside the VPC.

Behind the scenes, AWS routes the traffic to the managed service.

Characteristics

Creates one or more ENIs

Gets private IP addresses

Uses security groups

Supports thousands of AWS and partner services

Has hourly and data processing charges

What is AWS Gateway Endpoint

Think of this as adding a private route inside your VPC.

You don't create an elastic network interface (ENI). Instead, AWS adds a route to your route table that sends traffic destined for S3 or DynamoDB directly over the AWS network.

VPC

+------------------------------------+

 Lambda

    │

 Route Table

    │

Gateway Endpoint

    │

Amazon S3

There is no NAT Gateway, no Internet Gateway, and no ENI.

The route table simply knows that requests for S3 or DynamoDB should stay on the AWS backbone.

Characteristics

Free (no hourly endpoint charge)

Very high throughput

Simple routing

Only supports:

Amazon S3

Amazon DynamoDB

What are the recommended VPC/Gateway endpoints for various AWS Services?

 

This is one of the most frequently tested networking concepts in AWS AI Professional, AWS Solutions Architect, and AWS Developer exams. The confusion comes from the fact that both provide private access, but they work very differently.

Why do we have two types of VPC Endpoints?

AWS has hundreds of managed services.

Not all services communicate in the same way.

Some services (like Amazon S3 and Amazon DynamoDB) are massive regional storage services that use a different networking architecture than services such as Amazon Bedrock, Amazon Secrets Manager, or Amazon CloudWatch.

As a result, AWS provides two endpoint types:

Endpoint Type Used For Example Services

Gateway Endpoint High-throughput regional storage services Amazon S3, Amazon DynamoDB

Interface Endpoint (AWS PrivateLink) Most other AWS services Amazon Bedrock, Secrets Manager, CloudWatch, Systems Manager, KMS, SageMaker Runtime

AWS Multi-language Call Center Assistant Use case

Business Problem

Customer uploads voice.

Need

Speech

↓

Translate

↓

Summarize

↓

Generate response

↓

Speech output

Architecture

Voice

S3

Lambda

Transcribe

Bedrock

Translate

Polly

Customer

Flow

Audio uploaded

↓

Amazon Transcribe

↓

Text

↓

Bedrock summarizes

↓

Translate

↓

Amazon Polly speaks

↓

Return audio

Services

S3

Lambda

Transcribe

Bedrock

Translate

Polly

Why Not Let LLM Process Audio?

Foundation models are text-based unless using multimodal models.

AWS speech services provide better accuracy and lower cost.

Decision Matrix (Exam Favorite)

Requirement Best AWS Service Why

Store documents S3 Durable, scalable object storage

OCR Textract Structured text extraction

Semantic search Bedrock Knowledge Bases Managed RAG

Generate embeddings Bedrock Managed embedding models

Business logic Lambda Serverless orchestration

REST API API Gateway Secure API front door

User authentication IAM / Amazon Cognito Secure access control

Structured data DynamoDB Low-latency NoSQL storage

Logs CloudWatch Monitoring and troubleshooting

Voice to text Transcribe Automatic speech recognition

Text to speech Polly Natural speech synthesis

Translation Translate Neural machine translation

Architecture Selection Cheat Sheet

Scenario AWS Architecture Pattern

Chat with enterprise documents S3 → Knowledge Base → Bedrock → Lambda

Customer support with live order data API Gateway → Lambda → Database → Bedrock

Invoice processing S3 → Lambda → Textract → Bedrock → DynamoDB

Personalized recommendations API Gateway → Lambda → DynamoDB → Bedrock

Voice assistant S3 → Transcribe → Bedrock → Translate → Polly

Key exam takeaway

A recurring pattern in AWS AI architectures is to let managed AWS services perform specialized tasks (for example, Textract for OCR, Transcribe for speech-to-text, or Knowledge Bases for retrieval) and use AWS Lambda to orchestrate workflows, retrieve business data, and enforce authorization. Amazon Bedrock is then used primarily for generative AI tasks such as summarization, question answering, content generation, or reasoning, rather than directly accessing enterprise systems or replacing specialized AI services. This separation of responsibilities is a common design principle tested in AWS AI Professional certification scenarios.

AWS AI Professional - When to use which AWS Lex vs AWS Bedrock Agents

 QBased on everything you've covered in both parts of your blog, here's a comprehensive summary that captures both the **fundamentals** and the **AI-specific capabilities** of OpenTelemetry.

Exam Decision Table

Requirement Choose Reason

Intent-based chatbot Amazon Lex Purpose-built for conversational workflows

Multi-turn slot filling Amazon Lex Native dialog management

Retrieve order status AWS Lambda Calls enterprise systems securely

Generate natural explanations Amazon Bedrock LLM reasoning and text generation

Summarize conversations Amazon Bedrock LLM summarization

Execute business logic AWS Lambda Orchestration and integration

Build a customer support bot with both transactional and generative capabilities Lex + Lambda + Bedrock Best of both worlds

An exam tip

A useful way to think about these services is:

Amazon Lex = How do I conduct the conversation? (intents, slots, dialog flow)

AWS Lambda = How do I retrieve or update enterprise data?

Amazon Bedrock = How do I reason over information or generate natural language?

If a scenario emphasizes structured conversations, slot filling, and predictable workflows, Lex is usually the stronger choice. If it emphasizes open-ended questions, summarization, content generation, or reasoning, Bedrock becomes the key service. Many real-world AWS architectures combine all three.

AWS AI Professional : Differences between Amazon Lex vs Bedrock Agent based chat

Excellent question. This is exactly the kind of architectural trade-off the **AWS Certified AI Engineer/AI Professional** exam tests.

The short answer is:

**Yes, Amazon Lex can absolutely be used in Scenario 2.** In fact, if the question is "build a chatbot", Lex is often the best answer. My previous architecture focused on a **Generative AI chatbot using Bedrock**, whereas **Lex is a conversational interface service**. They solve different parts of the problem.

Let's compare them.

---

# Option 1: Bedrock + Lambda (What I showed)

```

User

   │

API Gateway

   │

Lambda

   │

Order Database

   │

Bedrock

   │

Response

```

Lambda performs:

* User authentication

* Order lookup

* Prompt construction

* Calls Bedrock

This is ideal when responses require:

* reasoning

* summarization

* natural conversation

* generation

Example

Customer asks

> I ordered a laptop last week. Can you tell me when it'll arrive, and if it's delayed, explain why?

The application retrieves the order details and Bedrock generates a natural response such as:

> Your laptop was shipped yesterday and is expected to arrive on Thursday. The one-day delay was caused by severe weather affecting the regional distribution center.

This type of response benefits from an LLM.

---

# Option 2: Amazon Lex

```

Customer

   Lex Bot

Intent

Lambda

Order DB

Return Status

Lex Response

```

Lex understands:

* intents

* slots

* conversation flow

For example:

Customer:

> Where is my order?

Lex:

"What is your Order ID?"

Customer:

> 12345

Lex invokes Lambda.

Lambda queries the database.

Lex replies:

> Your order is shipped.

No LLM is required.

---

# Can Lex access enterprise systems?

Yes.

This is one of its primary capabilities.

The typical flow is:

```

Lex

↓

Lambda

↓

ERP

↓

CRM

↓

SAP

↓

Salesforce

↓

Order Database

↓

Return result

```

Lex itself doesn't directly connect to databases.

Instead, it invokes Lambda, which integrates with enterprise systems.

---

# When is Lex the better choice?

Suppose your call center only needs to answer:

* Order status

* Reset password

* Account balance

* Cancel order

* Book appointment

These are deterministic workflows.

Lex is ideal because:

* Lower cost

* Lower latency

* Predictable responses

* Built-in dialog management

* Slot filling

* Intent recognition

No hallucination risk.

---

# Where Lex struggles

Imagine the customer asks:

> My package is delayed. Based on my purchase history, what would you recommend while I wait?

Lex cannot generate rich, contextual answers.

It relies on predefined intents and responses.

A foundation model such as Bedrock excels here.

---

# The modern AWS architecture

Increasingly, enterprises combine both services.

```

                 Customer

                     │

                 Amazon Lex

                     │

         Understand Intent

                     │

                Invoke Lambda

                     │

          ┌──────────┴───────────┐

          │                      │

     Order Database         Amazon Bedrock

          │                      │

          └──────────┬───────────┘

                     │

              Final Response

```

For example:

Customer:

> I ordered a phone two weeks ago. Is it delayed? If so, write an apology email that I can send to my manager because I won't have the device before my business trip.

Flow:

1. Lex identifies the intent ("Order Inquiry").

2. Lambda retrieves the order information.

3. Lambda sends the order details and the user's request to Bedrock.

4. Bedrock generates a personalized explanation and apology email.

5. Lex delivers the response.

Lex manages the conversation, while Bedrock provides reasoning and content generation.

---

# Exam Decision Table

| Requirement                                                                      | Choose                 | Reason                                     |

| -------------------------------------------------------------------------------- | ---------------------- | ------------------------------------------ |

| Intent-based chatbot                                                             | Amazon Lex             | Purpose-built for conversational workflows |

| Multi-turn slot filling                                                          | Amazon Lex             | Native dialog management                   |

| Retrieve order status                                                            | AWS Lambda             | Calls enterprise systems securely          |

| Generate natural explanations                                                    | Amazon Bedrock         | LLM reasoning and text generation          |

| Summarize conversations                                                          | Amazon Bedrock         | LLM summarization                          |

| Execute business logic                                                           | AWS Lambda             | Orchestration and integration              |

| Build a customer support bot with both transactional and generative capabilities | Lex + Lambda + Bedrock | Best of both worlds                        |

### An exam tip

A useful way to think about these services is:

* **Amazon Lex** = *How do I conduct the conversation?* (intents, slots, dialog flow)

* **AWS Lambda** = *How do I retrieve or update enterprise data?*

* **Amazon Bedrock** = *How do I reason over information or generate natural language?*

If a scenario emphasizes **structured conversations, slot filling, and predictable workflows**, Lex is usually the stronger choice. If it emphasizes **open-ended questions, summarization, content generation, or reasoning**, Bedrock becomes the key service. Many real-world AWS architectures combine all three.