AWS Certified Generative AI Developer - Professional: Networking, IAM, VPC endpoints

networking, IM and VPC endpoints,

private Geni on AWS. This is the day

where AWS stops asking whether you can

build Geni and starts asking whether you

can build it without accidentally

exposing everything to the internet.

This is about privacy, lease privilege,

and control. Imagine this. A large bank

wants to use Amazon Bedrock for internal

workflows. They say three things very

clearly. No traffic over the public

internet. No broad IM permissions.

Everything must be auditable. Those

three requirements immediately force

your architecture in a very specific

direction. You must get IM VPC endpoints

and encryption right. This is the story

AWS is testing. Let's start with IM.

Because IM is AWS's favorite blunt

instrument. IM answers one simple

question. Who is allowed to do what? And

AWS expects you to answer that question

precisely. There are two types of IM

policies you must understand. Identity

based policies attached to users or

roles. They define what this identity

can do. Resource-based policies attached

to resources like S3 buckets or KMS

keys. They define who can access this

resource. Both matter in Genai systems.

The most important rule is least

privilege. Only allow the actions needed

only on the resources required. And

remember this AWS law, an explicit deny

always beats an allow. In Geni

architectures, AWS expects you to

separate IM roles, not one giant role,

separate responsibilities. First is the

application runtime role. This is the

role used by Lambda, ECS, or EC2. It

usually needs permission to invoke

bedrock models, retrieve from a

knowledge base if you're using one, read

from S3 for prompts or documents, and

possibly access open search if you built

custom rag. This role should never have

wildcard permissions.

Second is the data ingestion or indexing

role. This role is used by pipelines

that read documents from S3, generate

embeddings, and write to a vector store.

It does not need permission to invoke

models for user traffic. Keep it

separate. Third is the human or admin

role. This is for engineers. Creating

knowledge bases, updating guardrails,

changing configurations. This role

should never be used by the application

at runtime. AWS loves this separation.

Now, let's talk about common IM exam

traps. If you see bedrock on, that's

wrong. If you see one role doing

runtime, ingestion, and admin work,

that's wrong. If you see encrypted S3 or

secrets without KMS permissions, also

wrong. Most people forget KMS. AWS does

not. A bonus topic the exam loves is IM

conditions. Conditions let you say when

and from where an action is allowed. You

might restrict access based on the

source VPC endpoint, resource tags or

encryption requirements. For example,

allowing S3 access only when requests

come from a specific VPC endpoint. This

is very exam friendly. Now let's move to

networking, specifically VPC endpoints.

This is how you keep traffic private.

There are two types of VPC endpoints you

must know. Gateway endpoints are used

for S3 and DynamoB. They work at the

route table level. They are simple,

cheap, and very common. Interface

endpoints use AWS private link. They

create elastic network interfaces in

your subnets. Most AWS service APIs,

including Genai adjacent services, use

interface endpoints. DNS resolves the

service name to a private IP. No

internet involved. Why does this matter

for Genai? Because if you want private

calls from Lambda or ECS, no net

gateway, controlled outbound traffic,

and compliance with no public internet

rules, you use VPC endpoints. This is

not optional in regulated environments.

Here's the exam pattern to recognize. If

the question says must not traverse the

public internet, private connectivity,

NNAT, or compliance requirements, the

correct answer includes VPC endpoints

always. Now visualize the core private

geni architecture AWS expects. Your

application runs in private subnets. No

public IPs. You use an S3 gateway

endpoint for documents, prompts, and

logs. You use interface endpoints for

AWS service APIs. Your vector store

lives inside the VPC or is accessed

privately. Outbound internet is blocked

or tightly controlled. This is what good

looks like. Security groups matter here.

They are stateful and used everywhere.

They allow your app to talk to endpoint

network interfaces, open search, and

internal APIs. Network ACL exist, but

are rarely the primary answer unless the

question specifically asks about

subnetwide controls. Keep it simple.

Routing is also straightforward. Private

subnets route to interface endpoints

through ENIs. S3 traffic goes through

the gateway endpoint.NAT gateways are

used only if absolutely required and

often avoided in regulated setups. Now

let's map common exam scenarios. If

documents are in S3 and ingestion must

be private, use an S3 gateway endpoint

and an IM role with S3 get object and

KMS decrypt. If an app must call an AWS

service privately, use an interface

endpoint and security group rules. If

access to S3 must be allowed only

through an endpoint, use an S3 bucket

policy with the source VPC

condition. If everything must be

encrypted, use KMS and remember to grant

K canrip cryps decrypt permissions. This

is where many people fail.

Before we finish, here's the exam grade

checklist. Separate IM roles for runtime

ingestion and admin. Use least privilege

actions and scoped resources. Use S3

gateway endpoints for private S3 access.

Use interface endpoints for private

service API calls. Restrict access using

a source VPC where appropriate. Never

forget KMS permissions. Log everything

using Cloudatch and X-Ray. And here is

the one sentence to lock it all in. IM

decides who may do what. VPC endpoints

decide how traffic gets there privately.

If you remember that, this entire topic

becomes easy.