Amazon Web Services (AWS) Misc Notes, Cheatsheet, Etc. - WIP
Light
help

Quick Links:

General

AWS is overwhelming, to put things lightly, and there are so many things that are probably second nature to those that work with AWS often, but can seem perplexing to those just coming onboard.

Here are some questions I had when learning and jotted down the answers to:

  • What is the deal with the naming conventions? For example, to create a named parameter (for use with Parameter Store program), they recommend /dev/parameterStoreBlog/appSecrets

    • Certain programs, such as Parameter Store, allow you to organize assets by hierarchy, rather than flat, so the slashes allow you to do so (detail).

      • Note that the hierarchy style starts with a slash - /subdir/thing, not subdir/thing
    • When a program does not offer a hierarchy based structure, or just for naming the last part of the name, some popular standards are things like:

      • {app}-{thing}-{environment}-{region}-{everything else (ID, OS, etc)}
      • Where environment means, production | development | etc - or shorthand - p | d | etc
  • AWS SAM vs Serverless?

    • This post does a great job of covering some of the differences between SAM and Serverless.
    • Another comparison bref
    • In general, SAM has:

      • Benefits over Serverless:

        • Better local execution and dev
        • Abstraction over CloudFormation means less work to convert into native CloudFormation
        • Tighter integration with AWS stack; get newer features faster
      • Downsides:

        • Tied to AWS only (aka vendor-lock), whereas Serverless supports multiple platforms
        • Most SAM solutions are newer and less popular than Serverless; you will find less resources
        • Tends to require more verbose commands and flags

Lamdba

Local development

"Serverless" CLI:

As opposed to Azure and GCP, both of which have strong CLIs and local development tools, AWS is slightly lacking, and the majority of guides you will come across will recommend that you use serverless (serverless cli, aka "serverless framework") to scaffold, create, and deploy AWS lamdbda functions.

The serverless framework also shares many similarities with AWS SAM (Serverless Application Model) framework. Now that both SAM and AWS Toolkit for VSCode are being worked on more, it might be worth giving them a shot if the majority of your stack is on AWS.

AWS SAM (Serverless Application Model)

AWS SAM is an open-source framework, similar to "Serverless", where config files (often .yml) and special syntax can be used to represent resources and configurations for serverless stack components.

There is a SAM CLI, and the AWS Toolkit VSCode extension builds on both the regular AWS CLI, as well as the SAM CLI.

SAM itself builds upon other AWS components, but primarily upon AWS CloudFormation.

Native CLI:

AWS does offer its own CLI, but it can be complicated to use - see this doc page on create-function for example: here

NEW: AWS Toolkit for VSCode

Made generally available in July 2019, the AWS Toolkit for Visual Studio Code is an extension that builds on AWS SAM, and like the Azure extension, lets you develop and execute locally, and is tightly integrated with VSCode.

Using Parameter Store with Lambda

Steps:

  1. Create a role that can be assigned to the Parameter, and shared with the Lambda to allow access
  2. Create your parameter and assign your created role while creating
  3. Create your function, and assign the created role
  4. In your function, you can retrieve the parameter by creating a client and then calling the correct method (depending on code)

    • In the AWS NodeJS SDK, you would probably want to use SSM, like so:

      const ssmClient = new AWS.SSM();
      
      // Callback style
      ssmClient.getParameter({
      	Name: 'MY_PARAM_KEY_NAME',
      	WithDecryption: true
      }, (err, data) => {
      	if (err) console.log(err, err.stack);
      	else {
      		// Do something with data!
      		myProcessor(data);
      	}
      });

Building an API using Lambda

Quick notes:

  • It is pretty much guaranteed that you will need to use:

    • AWS API Gateway
    • HTTP triggers
  • If you need to persist data between API calls, you will need to use something like:

    • DynamoDB
    • Parameter store
    • S3
    • etc.

HTTP APIs vs REST APIs: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html

Guides:

DynamoDB

Local Testing

You can find the guide for setting up a local version of DynamoDB here, which covers multiple options. The easiest, if you already have Docker installed, is probably the pre-build docker image.

Markdown Source Last Updated:
Sun Jan 19 2020 03:24:02 GMT+0000 (Coordinated Universal Time)
Markdown Source Created:
Mon Dec 30 2019 04:30:33 GMT+0000 (Coordinated Universal Time)