Norah Klintberg Sakal

Why you need a secure trigger​

Day 12: You build a protected frontend

Today: We build the secure backend that triggers calls

Here's the critical security issue:

Remember your ALB endpoint we built on Day 9 ↗?

https://ai-caller.yourdomain.com

If we add a /make-call endpoint directly to Fargate:

POST https://ai-caller.yourdomain.com/make-call
→ Publicly accessible
→ Anyone can trigger calls
→ Could rack up *huge* OpenAI/Twilio bills
→ Even with frontend auth, the endpoint is exposed

This is not acceptable.

Protect your app from unauthorized use​

Days 9-11: You built the infrastructure

Today: We build the protected frontend

Here's the critical security issue:

When you deploy your AI calling agent:

https://app.yourdomain.com
→ Publicly accessible
→ Anyone can use it
→ Could rack up huge OpenAI/Twilio bills

This is not acceptable.

What you need:

Make it secure​

Day 10: You got a custom domain

Today: We make it secure with HTTPS

Here's the situation:

Your app is accessible at:

http://ai-caller.yourdomain.com

Browser says: ⚠️ "Not secure":

The problem:
❌ Data transmitted in plain text
❌ Anyone can intercept traffic
❌ Users don't trust it
❌ Browser shows scary warnings
❌ Can't use modern web features (WebRTC, microphone access)

What you need:

No more default URLs​

Day 9: You built the front-yard house (ALB)

Today: We give it a real address

Here's the situation: Your ALB has a public endpoint:

fargate-alb-1234567890.us-east-1.elb.amazonaws.com

This works, but:
❌ Impossible to remember
❌ Looks unprofessional
❌ Hard to share
❌ Can't use for SSL certificate (Day 11)

What you want:

ai-caller.yourdomain.com

Clean. Professional. Memorable.

Solution: Route 53 + Custom Domain

Your network needs a front-yard house​

Day 8: You tested and validated your network

Today: We build the front door (Application Load Balancer)

Here's the setup:

Trust, but verify​

Days 3-7: You built the entire network infrastructure

Today: We prove it actually works

Here's the situation:

You've built:
✅ VPC with Internet Gateway
✅ Public and private subnets
✅ NAT Gateway
✅ Route Tables
✅ Security Groups

But you haven't actually tested any of it.

What if:

• NAT Gateway isn't running correctly?
• Route tables have the wrong associations?
• Secure Groups are blocking traffic?
• Something is misconfigured?

You'd fund out after deploying your containers (painful debugging)

Solution: Test first, deploy second.

Your network needs smart locks​

Day 6: You built the roads (route tables)

Today: We add the smart locks (Security Groups)

Here's the problem:

But there's NO security layer yet.

Right now:

• Anyone can try to connect to your containers
• No firewall rules
• No access control

That's a security issue.

Solution: Security Groups

Your gates need directions​

Day 5: You built the back gate (NAT Gateway)

Today: We build the roads that connect everything

Here's the problem:

You have:

✅ Neighborhood front gate (Internet Gateway)
✅ Back gate (NAT Gateway)
✅ Front yards (public subnets)
✅ Back yards (private subnets)

But nothing is connected yet.

Your back yard needs an exit​

Day 4: You divided your VPC into front yards (public) and back yards (private)

Today: We build the back gate (NAT Gateway)

Your neighborhood needs houses​

Day 1: Your AI agent's first phone call Day 1 ↗
Day 2: Give your AI agent a real-world mission Day 2 ↗
Day 3: You claimed your territory (VPC) Day 3 ↗

Today: We'll build our neighborhood with subnets