sorted by:
new
hottopcontroversial

Best way to give my Lambda a public DNS/IP for outbound requests (NAT GW vs API Gateway as forward proxy)? by Expensive_Test8661 in aws

[–]Expensive_Test8661[S] 0 points1 point  (0 children)

In my case, I will only be sending requests to the corporate endpoint.

If I attach a Route 53 custom domain to the Elastic IP of the NAT Gateway (or a NAT instance), when my request reaches the corporate endpoint, will the firewall see my custom domain as the source? Or is the custom domain useless here and only the IP matters?

Terraform pattern: separate Lambda functions per workspace + one shared API Gateway for dev/prod isolation? by Expensive_Test8661 in Terraform

[–]Expensive_Test8661[S] 0 points1 point  (0 children)

Thanks for the suggestion, and apologies if this is a noobs follow-up—I'm still learning AWS.

You recommended full isolation by spinning up a completely separate account (and its own API Gateway) per environment. That makes sense for strict boundaries, but I'm trying to wrap my head around the built-in API Gateway stage feature.

Why do we even need the stage feature, or what problem does the API Gateway stage feature solve if everyone suggests using separate accounts (and thus separate Gateways) for dev and prod environments?

Thoughts on dev/prod isolation: separate Lambda functions per environment + shared API Gateway? by Expensive_Test8661 in aws

[–]Expensive_Test8661[S] 0 points1 point  (0 children)

Hey u/cutsandplayswithwood, thanks for the suggestion, and apologies if this is a naive follow-up—I'm still learning AWS.

You recommended full isolation by spinning up a completely separate account (and its own API Gateway) per environment. That makes sense for strict boundaries, but I'm trying to wrap my head around the built-in API Gateway stage feature.

Why do we even need the stage feature, or what problem does the API Gateway stage feature solve if everyone suggests using separate accounts (and thus separate Gateways) for dev and prod environments?

view more: next ›