Skip to content
Ryan Pendergast edited this page Sep 9, 2015 · 11 revisions

Why do you use an S3 bucket to store env vars?

You never want to store your service keys / credentials in version control. IAM policies for S3 allow for fine grain access control. You only give access to the bucket that contains env vars to people with authority to deploy code.

Why only 1 S3 bucket for env vars?

S3 buckets are a limited resource and one of the only globally unique assets in AWS. This combined with the fact that we prefer convention over configuration led us down this decision. Instead of one bucket per project per stage, we have one bucket and based on convention store data for your JAWS projects and stages.

The convention is:

s3://<proj jaws.json:envVarBucket.name>/JAWS/envVars/<projectName>/<stage>

Why optimize code before deployment?

The smaller the size of code, the quicker your container gets up and running. The less code in the execution path, the quicker your runtime VM returns a result. Both of these statements verified by AWS Lambda engineers. See this issue for an in depth background.

Clone this wiki locally