Amazon Web Services (AWS) Misc Notes, Cheatsheet, Etc.

Resources:

AWS - General Notes

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 in the bref repo
- 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
What is with all the different NodeJS SDKs (aws-sdk/*, aws-amplify/*, etc.)? A lot of them seem to do similar things!?
- Yes, it's confusing, and yes, some libraries or sub-libraries overlap. The answer of which to use is the ever-frustrating "it depends"
- For auth, this post covers aws-sdk vs aws-amplify vs amazon-cognito-identity-js, and the responses to this StackOverflow question are also a good read.
- In general, if you want a high-level easy-to-use SDK and your app is a fairly "typical" web app, you will probably want aws-amplify, whereas if you need to do a whole bunch of low-level stuff and/or with server-side credentials, you might want aws-sdk

Lambdas

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

AWS CLI - Credentials

The default behavior of the AWS CLI is to assume that you want to use the [default] profile, with credentials under the same name.

If you want to use a different profile, you can specify with aws_cmd --profile {name} or AWS_PROFILE={name} aws_cmd.

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:

Create a role that can be assigned to the Parameter, and shared with the Lambda to allow access
Create your parameter and assign your created role while creating
Create your function, and assign the created role

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:

Lambdas - NodeJS - TypeScript (or JSDoc)

Resources:

https://omakoleg.github.io/typescript-practices/content/lambda.html

https://docs.aws.amazon.com/lambda/latest/dg/typescript-handler.html

Here are some extra considerations when writing type-checked NodeJS lambda:

You might want to use .js files instead of TS, with JSDoc providing the type annotations, for an easier build & deploy strategy:
- No dependency or need for a TypeScript compiler
- No dealing with any weird TS ESM interop stuff
- Faster local testing
Types for things like event, context, and callback are provided by the @types/aws-lambda package
- You will also want @types/node if you are doing anything using the Node standard / built-in libraries
You can import / require aws-sdk without explicitly bundling it via package.json. The SDK is included automatically along with each runtime (see tables)
- Note: aws-sdk is v2, @aws-sdk/client-* is v3
  - V3 offers more modular packages (e.g. @aws-sdk/client-s3 if all you need is S3 APIs)

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-built docker image.

AMIs

ECS-optimized Linux AMIs docs
Warnings:
- AL2 is advised against; use AL 2023 instead
  - https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html
How to tell what software will come pre-installed on an AMI? E.g., how to tell which AMIs come with Docker?
- AFAIK, it is kind of a mess. You can search across AMIs and apply filtering, but it doesn't work super well and there does not appear to be a standardized schema exposed for extracting the installed software lists.
- Amazon ECS-Optimized Amazon Linux 2 (AL2) x86_64 AMI is one that comes with Docker
  - See github.com/aws/amazon-ecs-ami for all the ECS-optimized images