Web API | Http Status Codes

 HTTP Status Code Families

1xx – Informational

• Request received, processing continues
• Rarely used in practice
• Example: 100 Continue

---

2xx – Success

• Request was successfully processed
• Most common success responses
• Examples:
• 200 OK → Standard success
• 201 Created → Resource created
• 204 No Content → Success, no response body

---

3xx – Redirection

• Further action needed to complete request
• Client must follow redirect
• Examples:
• 301 Moved Permanently
• 302 Found (Temporary Redirect)
• 304 Not Modified → Cache use

---

4xx – Client Errors

• Problem with the request (client-side issue)
• Examples:
• 400 Bad Request → Invalid input
• 401 Unauthorized → Authentication required
• 403 Forbidden → Access denied
• 404 Not Found → Resource doesn’t exist

---

5xx – Server Errors

• Server failed to fulfill a valid request
• Examples:
• 500 Internal Server Error → Generic failure
• 502 Bad Gateway → Invalid upstream response
• 503 Service Unavailable → Server overloaded/down
• 504 Gateway Timeout → Upstream timeout

AWS - Network Access Control List (ACL)

A Network Access Control List is an optional layer of security to your VPC, that acts as firewall to subnet(s) to control In & Out traffic. A default ACL created with VPC, you can configure ACL as an additional layer of security.

An ephemeral port is a short-lived endpoint that is created by the operating system when a program requests any available user port. The operating system selects the port number from a predefined range, typically between 1024 and 65535, and releases the port after the related TCP connection terminates.
You can use it in outbound list of ACL.

Facts About NACL

1. NACL always evaluated before security groups. That means NACL filtered traffic reaches to security groups.
2. NACL is stateless, which means, any inbound traffic do not have relative out bound traffic automatically, we need to create it.
3. Default Network ACL created when you create VPC, that allows all inbound and outbound traffic, you can customize it as per your requirement.
4. We can create a custom Network ACL that by default denies all inbound and outbound traffic, until we do not add rules to that.
5. A Network ACL can be associated with multiple subnets but a subnet can have association with only one ACL. If you do not explicitly associate subnet to an ACL than it automatically associate with default ACL.
6. Their are separate list of inbound and outbound rules.
7. Inbound/Outbound lists are numbered rules list. that applies descending numbered rules.
   Ex.
   Rule No. 100 allowing http on port 80
   Rule No. 200 denying http on port 80
   Means ACL will allow http on 80
8. You can block specific IPs on ACL but not on security groups.

AWS - Pillars of Well Architected Framework

The pillars of well architected framework

1. Operational Excellence: Ability to run and maintain system, supporting business requirements and technology changes and continually improve supporting process and procedures. 

• Monitoring system health

• Business Matrix
• Customer Experience Matrix 
• System Matrix 
• Operational Matrix

It encompasses areas such as automation, change management, and continuous improvement.

AWS Services: AWS CloudFormation, AWS CloudTrail, AWS Config, AWS Systems Manager, AWS CodePipeline, AWS CodeDeploy, AWS CodeBuild, AWS CloudWatch, AWS Lambda, AWS Step Functions.

2. Security:

It covers areas like identity and access management, data protection, and incident response.

AWS Services: AWS IAM, AWS KMS, AWS CloudTrail, AWS WAF, AWS GuardDuty, AWS Secrets Manager, AWS Certificate Manager, AWS Security Hub, AWS Config, AWS Network Firewall, AWS Shield.

3. Reliability: (Hint: HA + DR + Backups)

It covers areas like fault tolerance, high availability, and backup and recovery strategies.

AWS Services: AWS Auto Scaling, AWS Elastic Load Balancing, AWS Route 53, AWS CloudWatch, AWS Backup, AWS CloudFormation, AWS CloudTrail, AWS Lambda, AWS Step Functions, AWS SNS, AWS SQS.

4. Performance Efficiency:

It covers areas like selection of compute resources, caching, and monitoring.

AWS Services: AWS EC2, AWS Auto Scaling, AWS ElastiCache, AWS CloudWatch, AWS CloudFront, AWS Global Accelerator, AWS PrivateLink, AWS Transit Gateway, AWS Lambda, AWS EFS, AWS FSx.

5. Cost optimization:

It covers areas such as cost-effective resource selection, monitoring expenditure, and identifying opportunities for cost savings.

AWS Services: AWS EC2 Spot Instances, AWS Auto Scaling, AWS Cost Explorer, AWS Trusted Advisor, AWS Budgets, AWS Reserved Instances, AWS Savings Plans, AWS Organizations, AWS Cost and Usage Reports, AWS Lambda, AWS CloudWatch.

6. Sustainability Pillar:

It covers areas like carbon footprint reduction, energy efficiency, and resource optimization.

AWS Services: AWS Graviton instances, Amazon EBS gp3 volumes, AWS Instance Scheduler, AWS Cost Explorer, AWS Trusted Advisor, AWS Compute Optimizer, AWS Ground Station, AWS Snowcone, AWS Lambda, AWS Batch, AWS Glue, AWS Athena.
Weekend scheduled shutdown of EC2s if not in use.

Key word to remember: OSCAR (Replace A by P)

Good articles you should read: 
https://dzone.com/articles/pillars-of-aws-well-architected-framework
https://builder.aws.com/content/2eIXjpD5TI2j00UWUHx159mO9Mw/aws-well-architected-framework-comprehensive-guide
https://www.aws.ps/aws-well-architected-framework/ 
OSCAR (replace A by P)

AWS | Trusted Advisor

An advisor service that scans your resources and infrastructure compare them with best practices and provide recommendations on important aspects like cost, performance, security and fault tolerance.

AWS | Athena Vs S3 Select Vs Redshift Spectrum

Comparison between Athena, S3 Select and Redshift Spectrum

Feature	Amazon S3 Select	Amazon Athena	Amazon Redshift Spectrum
What it is	Query individual objects in S3	Serverless SQL query engine on S3	Query S3 from Redshift
Best for	App-level filtering of single files	Ad-hoc analytics	Enterprise data warehouse extension
Setup	None (API call)	None (serverless)	Requires Redshift cluster
SQL support	Limited (simple SQL)	Full ANSI SQL	Full Redshift SQL
Performance	Good for small object filtering	Good for medium-large datasets	Best for very large datasets
Pricing model	Per data scanned	Per TB scanned	Per TB scanned + Redshift cost
Concurrency	App-controlled	High	Very high
Use case example	Fetch specific rows from JSON/CSV in app	Run analytics on data lake	Join S3 data with warehouse tables

---

When to Use What

Use S3 Select when:

• You need to retrieve specific rows from one object
• You're inside an application
• You want to reduce data transfer

Think: “Filter before downloading.”

---

Use Athena when:

• You have a data lake in S3
• You want SQL without managing infrastructure
• You need BI / analytics

Think: “Serverless analytics on S3.”

---

Use Redshift Spectrum when:

• You already use Redshift
• You want to join warehouse tables + S3 data
• You need enterprise-scale performance

Think: “Extend data warehouse to S3.”

---

Simple Decision Rule

• Single file → S3 Select
• Data lake analytics → Athena
• Enterprise warehouse + S3 → Redshift Spectrum

Athena Vs S3 Select

Amazon Athena

A serverless interactive query service that lets you run full SQL queries directly on data stored in S3.

Amazon S3 Select

A feature of S3 that lets you retrieve only a subset of data from a single object using simple SQL expressions.

---

Key Differences

Feature	Athena	S3 Select
Scope	Query across multiple files	Query within a single object
SQL Support	Full ANSI SQL	Limited SQL (simple SELECT, WHERE)
Use Case	Analytics, reporting, BI	Efficient object-level filtering
Performance	Scans full dataset (optimized by partitioning)	Reads only selected data from object
Pricing	Per TB scanned	Per GB scanned + data returned
Schema	Requires table definition (Glue/Data Catalog)	No external catalog needed
Joins	Yes	No
Aggregations	Yes	Very limited

---

When to Use Each

Use Athena when:

• You need to query large datasets across many files
• You need joins, aggregations, grouping
• You're connecting BI tools (e.g., QuickSight)
• You want serverless analytics without managing infrastructure

Example:

SELECT customer_id, SUM(amount)
FROM transactions
GROUP BY customer_id;

---

Use S3 Select when:

• You need to fetch a small portion of a single large file
• You want to reduce network transfer
• You’re building an application that reads filtered object data
• You need low-latency object-level filtering

Example:

SELECT * FROM s3object s WHERE s.status = 'active'

---

Cost Consideration

• Athena can become expensive if queries scan large unpartitioned datasets.
• S3 Select is often cheaper when extracting small pieces of large objects.

---

Simple Mental Model

• Athena = Data warehouse-style querying over S3
• S3 Select = Smart “grep” inside one S3 file

Docker - Exclude Dev Tools (Docker Optimization)

Do not include development-only tools and packages in the final production container image.

You only keep what is needed to run the app — not what is needed to build or test it.

This reduces image size, vulnerabilities, and startup time, which is very important in AWS environments.

“Removing dev dependencies ensures the production Docker image only contains runtime components, resulting in smaller image size, faster AWS deployments, reduced vulnerabilities, and lower CI/CD and ECR costs.”

How to Achieve: Multi stage docker build 
Create docker file in such a way that makes multi stage build (build then run) 

---

What Are Dev Dependencies?

These are packages/tools used during:

• Local development
• Unit testing
• Debugging
• Building/compiling
• Linting/formatting

But not needed at runtime.

Examples:

Technology	Dev Dependencies
.NET	SDK, test frameworks, analyzers
Node.js	eslint, nodemon, jest
Python	pytest, black
Java	maven, gradle

---

Why Remove Them?

1. Smaller Image

Dev tools are heavy.

Example:

• With SDK + test tools → 1.2 GB
• Runtime only → 200 MB

Smaller image = faster pull from ECR.

---

2. Faster Startup on AWS

Impacts:

• ECS task start
• EKS pod start
• Lambda container cold start

---

3. Better Security

Dev packages increase CVEs.

Removing them:

• Reduces attack surface
• Better ECR / Trivy scan results

---

4. Lower AWS Cost

• Less ECR storage
• Less data transfer
• Faster CI/CD = lower CodeBuild minutes

---

How to Remove Dev Dependencies

.NET Example
Wrong (Includes SDK)

FROM mcr.microsoft.com/dotnet/sdk:8.0

WORKDIR /app

COPY . .

RUN dotnet publish -c Release

ENTRYPOINT ["dotnet", "MyApp.dll"]

SDK stays in final image → huge size.

---

Correct (Multi-Stage)

# Build Stage

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

WORKDIR /src

COPY . .

RUN dotnet publish -c Release -o /out

# Runtime Stage

FROM mcr.microsoft.com/dotnet/aspnet:8.0

WORKDIR /app

COPY --from=build /out .

ENTRYPOINT ["dotnet", "MyApp.dll"]

Now:

• SDK removed
• Only runtime DLLs remain

---

Node.js Example

RUN npm install --production

or

RUN npm ci --omit=dev

---

AWS Impact Example

Without removing dev deps:

• Image size: 600 MB
• ECS startup: 25 sec
• Vulnerabilities: 120

With removal:

• Image size: 150 MB
• ECS startup: 6–8 sec
• Vulnerabilities: 30

---

Simple Analogy

It’s like shipping a car:

• Dev deps = factory tools, welding machines
• Runtime deps = engine, wheels, fuel

Customer only needs the car, not the factory.

Docker - Layer Caching

Layer Caching in Docker means Docker reuses previously built image layers instead of rebuilding everything from scratch.

In AWS + .NET context, this is very important for CI/CD speed, cost, and developer productivity.

“Docker layer caching improves AWS CI/CD performance by reusing unchanged build steps. In .NET, copying the .csproj and running dotnet restore before copying source code prevents unnecessary dependency restores, reducing build time, ECR push size, and deployment latency.”

---

First Understand Docker Layers

Every Dockerfile instruction creates a layer:

FROM ...
WORKDIR ...
COPY ...
RUN ...

Docker stores each layer as a snapshot.

If nothing changes in that step → Docker reuses the cached layer.

---

Why It Matters on AWS

Layer caching helps in:

AWS Service	Benefit
CodeBuild	Faster builds
ECR	Smaller push size
ECS/EKS	Faster deployments
Lambda Containers	Reduced cold start
CI/CD Pipelines	Minutes saved per build

---

Example Without Layer Optimization (.NET)

FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /app
COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o out

Problem:

• Any small code change invalidates COPY . .
• Docker reruns restore + publish
• Slow builds (2–5 minutes)

---

Optimized Version Using Layer Caching

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /app

# Copy only project files first
COPY *.csproj .
RUN dotnet restore

# Then copy rest of source
COPY . .
RUN dotnet publish -c Release -o out

Why This Works

• .csproj changes rarely
• Source code changes frequently

Docker cache logic:

Step	Changes Often?	Cache Used?
COPY *.csproj	Rare	Yes
RUN dotnet restore	Rare	Yes
COPY . .	Often	No
RUN publish	Often	No

So NuGet restore is skipped most builds, saving time.

---

AWS CI/CD Impact Example

Without caching:

• Build time = 6 minutes
• Every commit full rebuild

With caching:

• Build time = 1.5–2 minutes
• Only changed layers rebuilt

In CodeBuild or GitHub Actions, this saves hours per week.

---

ECR Push Optimization

Docker only pushes changed layers.

If only app code changed:

• Push size maybe 20–30 MB
• Instead of 300–500 MB

Less network → faster deploy → lower cost.

---

Real-World Analogy

Think of it like Excel recalculation:

• Change one cell → not entire sheet recalculated
• Docker only rebuilds changed steps

---

Best Practices for Layer Caching (.NET + AWS)

1. Order Matters

Stable steps first, changing steps later.

2. Separate Restore

COPY *.csproj .
RUN dotnet restore

3. Use .dockerignore

Exclude:

• bin/
• obj/
• .git/
• logs/

Reduces invalid cache triggers.

4. Multi-Stage Build

Keeps final image small and cache efficient.

AWS - Linux Alpine images

Using Alpine Linux as the operating system layer of your Docker image instead of a full Linux distro like Ubuntu or Debian.

It is not AWS-specific — but it is very popular on AWS because of performance and cost benefits.

“Alpine base images on AWS reduce container size, improve startup time, lower ECR costs, and reduce vulnerabilities, but require compatibility testing due to musl vs glibc differences.”

---

What is Alpine Linux?

Alpine Linux is a very small, security-focused Linux distribution.

Typical sizes:

Base Image	Approx Size
Ubuntu	70–120 MB
Debian	60–100 MB
Alpine	5–15 MB

So your container becomes much smaller.

---

Example in Dockerfile (.NET)

Normal:

FROM mcr.microsoft.com/dotnet/aspnet:8.0

Alpine:

FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine

Sample Alpine Docker file

FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine

WORKDIR /app

COPY --from=build /app/out .

ENTRYPOINT ["dotnet", "MyApp.dll"]

Difference:

• Same .NET runtime
• Smaller OS layer

---

Why It Matters on AWS

1. Faster Image Pull (ECR → ECS/EKS/Lambda)

Smaller image = faster download.

Example:

• Ubuntu image: 400 MB → 15–20 sec pull
• Alpine image: 90 MB → 3–5 sec pull

This directly impacts:

• Lambda cold start
• ECS task startup
• Auto-scaling speed

---

2. Lower Storage Cost (ECR)

AWS ECR charges for storage.

Smaller image:

• Less GB stored
• Lower monthly cost

---

3. Better Security

Alpine includes:

• Fewer packages
• Smaller attack surface
• Fewer CVEs

Security scans (ECR / Trivy) usually show less vulnerabilities.

---

4. Faster CI/CD Pipelines

In CodeBuild / GitHub Actions:

• Faster build
• Faster push/pull
• Less network usage

---

Where You Use It on AWS

AWS Service	Benefit
ECS Fargate	Faster container start
EKS (Kubernetes)	Faster pod scheduling
Lambda Container	Reduced cold start
CodeBuild	Faster pipelines
ECR	Lower storage cost

---

Important Caveat (Very Important)

Alpine uses musl libc instead of glibc.

Some libraries or native dependencies may fail, especially:

• Image processing libs
• Oracle drivers
• Some older .NET native packages
• Python scientific libs

If your app depends on native binaries, test carefully.

---

When NOT to Use Alpine

Avoid Alpine if:

• You need heavy native libraries
• You see runtime crashes related to libc
• Vendor software requires glibc
• You need full debugging tools

In such cases use:

• -slim images
• Debian slim
• Ubuntu minimal

---

AWS - Multi-Stage Docker Build

Multi stage sample docker file

# Build stage

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

WORKDIR /app

COPY . .

RUN dotnet publish -c Release -o out

# Runtime stage

FROM mcr.microsoft.com/dotnet/aspnet:8.0

WORKDIR /app

COPY --from=build /app/out .

ENTRYPOINT ["dotnet", "MyApp.dll"]

This Dockerfile uses Multi-Stage Build:

• Stage 1 → Build the app
• Stage 2 → Run the app

The RUN command executes during image build time, not when the container starts.

---

Stage 1 – Build Stage

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

• Pulls Microsoft .NET SDK image
• SDK contains compiler, NuGet, build tools
• Named this stage build

---

WORKDIR /app

• Sets working directory inside container to /app
• All next commands run from here

---

COPY . .

• Copies your entire project folder from local machine → container /app
• Includes .csproj, source code, etc.

---

RUN dotnet publish -c Release -o out

This is the key line 

RUN executes a command while building the image.

Think of it as:

“Open a temporary container, run this command, save the result as a new image layer.”

What happens internally

1. Docker creates a temporary container from sdk:8.0
2. Runs:
• dotnet publish -c Release -o out

3. .NET does:

• Restore NuGet packages
• Compile code
• Optimize for Release
• Output DLLs + dependencies into /app/out
4. Docker commits the result as a new image layer
5. Temporary container is deleted

So RUN is build-time execution, not runtime.

Result now inside image:

/app/out/MyApp.dll
/app/out/*.json
/app/out/*.deps.json

---

Stage 2 – Runtime Stage

FROM mcr.microsoft.com/dotnet/aspnet:8.0

• Starts a fresh lightweight image
• No SDK, only runtime
• Much smaller

---

WORKDIR /app

Sets working directory again.

---

COPY --from=build /app/out .

• Copies only compiled output from build stage
• Not source code
• Not SDK
• Only /app/out → /app

This is why image becomes small.

---

ENTRYPOINT ["dotnet", "MyApp.dll"]

This runs when container starts, not during build.

Difference:

Instruction	When it runs
RUN	During docker build
ENTRYPOINT	During docker run

---

Lifecycle Summary
When you run:

docker build -t myapp .

Docker executes:

1. Pull SDK image
2. Copy code
3. RUN dotnet publish → compile app
4. Start new runtime image
5. Copy compiled files
6. Create final image

---

When you run:

docker run myapp

Only this runs:

dotnet MyApp.dll

No compiling happens here.

---

Simple Analogy

• RUN = “Bake the cake in the kitchen”
• ENTRYPOINT = “Serve the cake to the customer”

RUN prepares the app.
ENTRYPOINT executes the app.

---

Why This Is Efficient

Without multi-stage:

• Image ~1–2 GB
• Includes compiler

With multi-stage:

• Image ~150–250 MB
• Only runtime files
• Faster deploys
• More secure

So RUN = build-time command that produces artifacts saved into the image layer.

AWS - Private link, VPC Interface Endpoint, VPC Gateway Endpoint, Direct Connect & VPC Peering

Private link, VPC Interface Endpoint, VPC Gateway Endpoint, Direct Connect & VPC Peering

1️⃣ VPC Endpoint (Big Picture)

A VPC Endpoint lets your VPC privately access AWS services without using the Internet, NAT Gateway, or IGW.

There are two types:

• 🧩 Interface Endpoint
• 🚪 Gateway Endpoint

👉 AWS PrivateLink is the technology behind Interface Endpoints.

---

2️⃣ Interface Endpoint (Powered by AWS PrivateLink)

🔹 What it is

• Creates Elastic Network Interfaces (ENIs) in your subnet
• You access services using private IPs
• Uses AWS PrivateLink

🔹 Supported services

• Most AWS services: SSM, EC2 API, CloudWatch, ECR, Secrets Manager
• Your own services (via NLB)
• SaaS / third-party services

🔹 Key points

• Works across VPCs and accounts
• Uses Security Groups
• Charged per hour + per GB

🎨 Diagram

🟦 VPC A (Consumer)
┌──────────────────────────┐
│  EC2 🖥️                  │
│    │ HTTPS (443)          │
│    ▼                      │
│  🧩 Interface Endpoint    │  ← ENI + Private IP
│    │                      │
└────┼─────────────────────┘
     │ AWS PrivateLink 🔒
     ▼
┌──────────────────────────┐
│ 🟩 AWS Service / NLB     │
│   (SSM / ECR / SaaS)     │
└──────────────────────────┘

🧠 When to use

✅ Private access to AWS services
✅ Expose your service to other VPCs safely
✅ No CIDR overlap issues

---

3️⃣ Gateway Endpoint

🔹 What it is

• Adds routes in your route table
• No ENIs, no Security Groups

• Only supports:

• 🪣 S3
• 📦 DynamoDB

🔹 Key points

• Free
• Scales automatically
• Traffic stays inside AWS network

🎨 Diagram

🟦 VPC
┌────────────────────────────┐
│ EC2 🖥️                     │
│   │                         │
│   ▼ Route Table             │
│  🚪 Gateway Endpoint        │
│   │                         │
└───┼────────────────────────┘
    ▼
🪣 Amazon S3   📦 DynamoDB

🧠 When to use

✅ Access S3/DynamoDB privately
✅ Cheapest & simplest option

---

4️⃣ AWS PrivateLink (Concept)

🔹 What it really is

PrivateLink = Secure service exposure using Interface Endpoints

Think of it as:

“I want to expose my service privately without opening my VPC.”

🎨 Diagram

🟦 VPC A (Client)        🟪 VPC B (Provider)
┌─────────────┐         ┌────────────────┐
│ EC2         │         │  NLB            │
│   │         │         │  + Service 🧩   │
│   ▼         │         └──────▲─────────┘
│ Interface   │                │
│ Endpoint 🧩 │──PrivateLink───┘
└─────────────┘

🧠 When to use

✅ SaaS-like architecture
✅ Cross-account secure access
✅ No VPC peering / no CIDR worries

---

5️⃣ VPC Peering

🔹 What it is

• 1-to-1 private connection between two VPCs
• Uses private IPs
• No transitive routing

🔹 Key points

• Simple, but doesn’t scale well
• CIDR must not overlap
• No Security Group referencing across VPCs

🎨 Diagram

🟦 VPC A                🟨 VPC B
┌──────────┐            ┌──────────┐
│ EC2 🖥️   │────────────│ EC2 🖥️   │
└──────────┘  Peering 🔗 └──────────┘

🧠 When to use

✅ Small number of VPCs
✅ Full network-level access

---

6️⃣ AWS Direct Connect

🔹 What it is

• Dedicated physical connection
• From on-premises → AWS
• Bypasses public internet

🔹 Key points

• Very low latency
• High bandwidth (1–100 Gbps)
• Costly but stable

🎨 Diagram

🏢 On-Prem Data Center
┌───────────────────┐
│ Servers 🖥️        │
└─────────┬─────────┘
          │ Dedicated Fiber 🔵
          ▼
┌────────────────────────┐
│ AWS Direct Connect ⚡  │
└─────────┬──────────────┘
          ▼
🟦 AWS VPC (Private Subnets)

🧠 When to use

✅ Hybrid cloud
✅ Predictable latency & bandwidth
✅ Enterprise workloads

---

7️⃣ One-Look Comparison Table

Feature	Interface Endpoint	Gateway Endpoint	PrivateLink	VPC Peering	Direct Connect
Internet needed	❌	❌	❌	❌	❌
ENI used	✅	❌	✅	❌	❌
Route table change	❌	✅	❌	✅	❌
Security Groups	✅	❌	✅	❌	❌
Cross-account	✅	❌	✅	⚠️	✅
CIDR overlap OK	✅	✅	✅	❌	✅
Typical use	AWS services	S3/DDB	SaaS / APIs	VPC-to-VPC	On-prem

---

8️⃣ Simple Memory Trick 🧠

• 🧩 Interface Endpoint → “ENI + Private IP”
• 🚪 Gateway Endpoint → “Route table only”
• 🔒 PrivateLink → “Secure service publishing”
• 🔗 VPC Peering → “Flat VPC connection”
• ⚡ Direct Connect → “Private fiber to AWS”