Skip to main content

VPC and Subnets


Good video that explains the basics of [AWS VPC & Subnets][vpcsubnet]

Vocab

  • Elastic IPs - Public IPs
  • NAT Gateway - redirecting outgoing internet access, allows private instances access internet. Redirect to NAT Gateway and translates internal IPs to Public ones which is of the NAT Gateway.

Configure AWS Lambda to VPC and Subnet for Static IP​

  1. Create a new VPC to run your code in (or use an existing VPC)
  2. Create a new Internet Gateway to communicate with the Internet from inside your VPC
  3. Create a Public Subnet and add a new route to the route table which routes to your Internet Gateway from 0.0.0.0/0
  4. Create a new Elastic IP address.
  5. Create a new NAT Gateway and assign it to the Public Subnet and Elastic IP address that you just created.
  6. Create two Private Subnet and add a new route to the route table which routes to your NAT Gateway from 0.0.0.0/0. Since it is recommended to add lambda to two subnets for high-availability, both subnets should use the route which routes to the NAT Gateway from 0.0.0.0/0
  7. In your lambda, go to Configuration and then Permissions. Click the Role name and attach a new policy called AWSLambdaVPCAccessExecutionRole. This gives lambda the ability to create, describe and delete Elastic Network interfaces in the two subnets.
  8. Then in Configuration, go to VPC, and connect your VPC, along with the two subnets you created.

By default, a lamda is deployed to AWS managed VPC.

Article Video


Custom Domain on API Gateway and CloudFront

1. Set up DNS records on Route53​

  • If you domain name provider is not Route53, first add the domain name in Route 53.
    • Route 53 will generate NS records (name servers) which you will need to add to your domain wherever it resides. Just add the Name Servers in your domain name provider for that domain.
  • Add an Alias A record for www.chaine.dev`` that routes to chaine.dev`

2. Create a Certificate​

  • Head over to Certificate Manager and create a certificate for your domain. Make sure to add the additional names:
chaine.dev
*.chaine.dev  // this will cover all subdomains
www.chaine.dev

Add the end of the certificate creation process, check the button to add the certificate to Route53. If this isn't done automatically, you will need to do it manually or else your site won't be secured by the certificate.

3. Create CloudFront Distribution​

Create a CloudFront Distribution. The way this setup works is CloudFront will handle all requests from everywhere and then redirect them to where you need them to go. This is done by creating an alias A record that points to the CloudFront distribution in Route53.

  • Enter Origin Domain Name. If your primary domain chaine.dev is pointing to your webpage, then enter that domain here. I.e. if it is your GitHub pages, this would be something like chaineapp.github.io/website. You can change this later, don't worry.
  • Keep all default options, except choose HTTPS Only for Origin Protocol Policy
  • For price class, you can choose U.S., Canada, and Europe if your app isn't needed on all Edge locations to save on costs
  • Add your Alternate Domain Names (CNAMEs). Include these:
chaineapp.com
www.chaineapp.com
*.chaineapp.com
  • Select Custom SSL Certificate and choose the certificate you created earlier
  • Select Security Policy TLSv1.2_2019 or the recommended ones
  • Create this CloudFront

4. Add CloudFront as A record​

Go back to Route53 and add CloudFront as an alia A record. When you select alias, select the option Alias to CloudFront distribution and choose your newly created CloudFront.

5. Setup Custom Domain in API Gateway​

Head over to API Gateway and select Custom domain names on the left.

  • Put your domain name, i.e. chaine.dev and click create. It should take 10-12 minutes for it to connect, sometimes faster.

6. Setup API Gateway in CloudFront​

Now, remember CloudFront controls where to route traffic to. So, since traffic to chaine.dev is being routed to your GitHub pages website, you want your API traffic to route to chaine.dev/api

  • In CloudFront, select your distribution
  • Go to Origins and Origin Groups, and click Create Origin
  • Add your API Gateway domain name. It is important to NOT include the https:// or https://wwwelse it won'y work. For example, your origin domain name should be something like:
9b5zity92a.execute-api.us-east-1.amazonaws.com
  • If you have multiple urls for this domain, create an origin for each and enter the url path in the Origin Path. You will create an Origin for each url of your API.
  • Most default options should be good, just avoid HTTP. Then create this origin.

Once you create an Origin, it won't just start working. You have to tell CloudFront which path for chaine.dev should take traffic to your newly created origin.

This is called a Behavior for obvious reasons. Head over to the Behaviors tab and click Create Behavior.

The Path Pattern here refers to the path of your URL, not of your API. When you created your Origin, the Origin Path refers to the path of your API. Notice the difference?

Now lets say you created a staging API origin and want all traffic for staging to go to chaine.dev/api/v1/staging. In the Path Pattern, simply add /api/v1/staging.

For the Origin, you guessed it, select the API Gateway Origin you creaetd earlier, and select Redirects HTTP to HTTPs.

For Allowed HTTP Methods, choose the option that applies for this path. If you will allow users to just GET some data, then you only need the first one. But most APIs that users consume and add data to will have multiple (3rd option).

  • You can get more complex with all the different options, but for simplicity its not needed. Just Create and you're all set.