Configuration Reference

This section enumerates all the options that can be provided in the slam.yaml configuration file.

Core Options

  • name

    The name of the project.

  • description

    A description for the project.

  • function

    Options that describe the function that is being deployed.

    • module

      The Python module or package that contains the application callable.

    • app

      The name of the function or callable to invoke.

  • requirements

    The project’s requirements filename.

  • devstage

    The name of the stage designated as the development stage.

  • environment

    A collection of variables, specified as key-value pairs, that are made available to the Lambda function as environment variables.

    Example:

    environment:
  IN_LAMBDA: "1"
  ADMIN_URL: "1.2.3.4"

  • stage_environments

    A collection of stages. Each stage contains a collection of variables, given as key-value pairs. These variables are exposed as environment variables to the Lambda function when running on the stage.

    Example:

    stage_environments:
  dev:
    DEBUG: "1"
  prod:
    DEBUG: "0"

    Note: When using multiple stages, it is important to that any stage variables defined in this section are given values for all stages. This is necessary because sometimes AWS reuses Lambda containers, so environment variables from a previous invocation on a different stage may still exist.

  • aws

    A collection of settings specific to AWS.

    • s3_bucket

      The bucket on S3 where Lambda packages are to be stored. If this bucket does not exist, it is created during the deployment.

    • lambda_timeout

      The timeout, in seconds, for the Lambda function.

    • lambda_memory

      The memory size, in megabytes, for the Lambda function.

    • lambda_security_groups

      If the Lambda function needs to access resources inside a VPC, this entry must contain the list of security groups for the function to use. When VPC access is not desired, this entry must be left blank.

    • lambda_subnet_ids

      If the Lambda function needs to access resources inside a VPC, this entry must contain the list of subnet IDs in that VPC that have to be connected to the function. When VPC access is not desired, this entry must be left blank.

    • lambda_managed_policies

      This entry can define additional managed policies to be assigned to the Lambda function execution role. These can be AWS managed policies (you can provide just the policy name, such as AWSLambdaDynamoDBExecutionRole), or custom managed policies, for which you must provide the fully qualified ARN.

    • lambda_inline_policies

      This entry can define additonal inline policies to be assigned to the Lambda function execution role.

    • cfn_resources

      A list of additional Cloudformation resources to add to the deployment.

    • cfn_outputs

      A list of additional Cloudformation outputs to add to the deployment.

WSGI Plugin

  • wsgi

    If this configuration option exists, the project is assumed to be a web application compliant with the WSGI protocol. The values under the function option (described above) are assumed to be of the WSGI callable.

    The following options provide more details on how the WSGI deployment should be configured:

    • deploy_api_gateway

      If set to true (the default), an API Gateway resource is created to map to the Lambda function, so that HTTP requests can be made transparently. If set to false, no API Gateway resources are deployed.

    • log_stages

      A list of stages that are configured to include API Gateway logging. For included stages, API Gateway will produce detailed logging. For stages not included, logging will only be produced for errors. This option is only meaningful when deploy_api_gateway is set to true.

DynamoDB Plugin

  • dynamodb_tables

    A collection of DynamoDB tables to create for each stage. Each table entry is defined by the table name, and contains a sub-collection of settings that define the table schema.

    Tables created by this plugin have a name with the format stage.name, so for example, for a project that defines dev and prod stages, a table named mytable in the configuration will result in DynamoDB tables dev.mytable and prod.mytable created.

    • attributes

      A collection of attributes, as key-value pairs where the key is the attribute name, and the value is the attribute type. Attribute types are defined by DynamoDB and can be "S" for string, "N" for number, "B" for binary, and "BOOL" for boolean.

    • key

      The name of the attribute that is the table’s hash key, or a list of two elements with the attributes that are the table’s hash and range keys.

    • read_throughput

      The read throughput units for the table.

    • write_throughput

      The write throughput units for the table.

    • local_secondary_indexes

      A collection of local secondary indexes to define for the table. The indexes are defined by their name, and contain a sub-collection that specifies their structure.

      • key

        Same as the table-level key attribute. For a local secondary index, the hash key must match the key selected for the table-level index.

      • project

        The attributes to project on this index. If set to "all" all table attributes are projected. Else it can be set to a list of attribute names to project, or to an empty list to only project the key attributes.

    • global_secondary_indexes

      A collection of global secondary indexes to define for the table. The indexes are defined by their name, and contain a sub-collection that specifies their structure.

      • key

        Same as the table-level key attribute.

      • project

        The attributes to project on this index. If set to "all" all table attributes are projected. Else it can be set to a list of attribute names to project, or to an empty list to only project the key attributes.

      • read_throughput

        The read throughput units for the index.

      • write_throughput

        The write throughput units for the index.

    Example:

    dynamodb_tables:
  # a simple table with "id" as hash key
  mytable:
    attributes:
      id: "S"
    key: "id"
    read_throughput: 1
    write_throughput: 1

  # a more complex table with hash/sort keys and secondary indexes
  mytable2:
    attributes:
      id: "S"
      name: "S"
      age: "N"
    key: ["id", "name"]
    read_throughput: 1
    write_throughput: 1
    local_secondary_indexes:
      myindex:
        key: ["id", "age"]
        project: ["name"]
    global_secondary_indexes:
      myindex2:
        key: ["age", "name"]
        project: "all"
        read_throughput: 1
        write_throughput: 1