In true newline-fashion, we'll get *rolling* with a practical application right away. We're creating a fully functional, dice-rolling chat bot for Slack!

Create a Serverless Slack Bot with AWS Lambda and Python

Introduction

There's no `AWS Lambda` without `AWS`. That means we'll need a few AWS resources created and configured on the AWS side of things to develop and effectively.

How to Setup a Free AWS Developer Environment

Here, we'll configure an `AWS Workspace` or `AWS EC2 Instance` as the development environment to use for developing for AWS Lambda.

How to Configure EC2 and AWS Workspaces Local Credentials

Configuring Your AWS Environment

We can comfortably develop for AWS Lambda with python on any modern Operating System

Setup a Local Python AWS Lambda Development Environment

We will be using the AWS Lambda runtime for the latest stable version of Python 3 - `python3.7`.

Installing Python 3 and Pyenv on MacOS, Windows, and Linux

The easiest way to configure our local development with our credentials is to run the command `aws configure`

How to Login to AWS CLI and Configure Default Region

Configuring Your Local Machine

How Our Slack Bot "Dicebot" Will Work

How to Create an AWS S3 Bucket for Lambda Artifacts

How to Code a Lambda Hello World Function with AWS SAM

How to Test AWS Lambda Functions Locally With Docker

The Beginner Guide to AWS Lambda Deployment

Creating Hello-world Lambda

How to Create a Slack Bot

How to Code a Python Dice Rolling Simulator Program

How to Turn Serverless Python Lambda Code Into a Slack Bot

Testing Our Serverless Slack Dicebot with Docker Locally

Cleaning Up Our Serverless Dicebot Deployment

Creating Dicebot Lambda

*Serverless Computing* may sound like a scary topic, but with the rise of AWS Lambda and mature tools supporting it - it's more approachable than ever. In this newline course, we're going to learn what serverless technology is and isn't, and why it belongs in your developer toolbox. We'll see that for certain common projects - like custom chat bot creation - AWS Lambda really shines for it's simplicity, affordability, and ability to integrate with the wider AWS ecosystem. 

Some developers love using serverless tech because it helps them save money, scale quickly, and deliver on reliability goals. While all of those things are possible with Lambda (especially cost savings which are common - but certainly not guaranteed), it's the development agility and reduction of operations overhead that drives my love for the service. It's a relief to be able to get right into the code, without worrying about configuring operating systems, deploying containers, or scaling clusters. Serverless on Lambda gives developers the resources needed to write, deploy, and _maintain_ production-ready software - all without significant operational overhead.

In true newline-fashion, we'll get *rolling* with a practical application right away. RPG players rejoice - we're creating a fully functional, dice-rolling chat bot for Slack! While the example bot will be for Slack, the same idea can be easily adapted to create a bot for Telegram, Discord, or nearly any other chat service with a bot API. 

We will be using Python 3 for this project, but it's worth noting that [AWS Lambda works with other common languages and runtimes](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html), including NodeJS, Java, ruby, go, and .NET. The basic mechanisms of creating, testing, and deploying your Lambda do not vary significantly based on your runtime choice.

By the end of this course you'll:

* Deploy a Slack Bot that runs on AWS Lambda
* Understand how to keep your AWS account secure
* Be able to deploy custom Lambda functions
* Understand serverless architecture and how it works

In this course we'll build and deploy a Serverless Slack Bot using AWS Lambda and Python. Along the way you'll learn about proper security, how lambda works, and how to deploy your service.

Create a Serverless Slackbot with AWS Lambda and Python

How to deploy a serverless bot into production

. That means we'll need a few AWS resources created and configured on the AWS side of things to develop and effectively.

Additionally, even if you have all of the above ready - we recommend reading the 

 section to learn how to keep your AWS Account secured.

Spending 15 minutes now will save you hours later if you ever need regain access after a compromise!


A common misconception about AWS is the belief that it is not necessary to secure your account when it’s only being used for testing or minor projects. 

Many attackers don’t want to steal your data - they want to steal your AWS compute resources.

 An attacker will often use compromised accounts to spin up expensive instances for crypto mining or botnet attacks. Sometimes they use unusual AWS regions and dedicated instances so those instances don’t appear visible in a user’s usual dashboard. Some users don’t realize they have been attacked until they receive an expensive bill! Alternatively, AWS may reach out and temporarily disable a compromised account if they detect it is being used for malicious purposes. This can be a serious headache that can affect uptime for anyone running legitimate production services.

A note on Free-Tier usage and costs in AWS

Every exercise in this course will comply with 

. If we are using an account that is still free-tier eligible, there should be no billed charged for completing any exercises as defined in the book. Some projects could potentially incur cost past free-tier with heavy usage (ie, deploying the dicebot project into a popular channel where it gets invoked frequently). However - 

simply deploying and testing these applications will not incur cost if free-tier is active.

 Steps for removing the deployed project from AWS will also be included. 

It is recommended to always cleanup work after completion. We can always re-deploy projects later.

Additional Recommended Reading on this topic

We recognize that exposure to AWS might vary wildly among our readers. You can use the links below to jump to whichever section of the course is most relevant to your needs.

For Developers new to AWS (Standard Signup)

For everyone else, we will need to register a standard AWS Account in our own name, or in our business’ name on the 

. Be aware - creating an AWS Account requires a valid credit card, even if we only intend to use free-tier services and/or promotional credits.

WARNING - Automated Fraud Prevention 
AWS Fraud detection may enforce a hold-period of 

 when registering an account associated with a high-fraud risk locale!

For Members of Organizations that already use AWS  (AWS Organizations)

If your workplace or organization already uses AWS - you may be able to request access to an existing account or ask your AWS Account Admin to provision you a new one through the 

 email address, you can register for a special AWS account that includes promotional credit and other training resources through the 

Security changes only take a few minutes to make, but they will significantly improve the risk posture of an AWS account. Don’t put this step off for later,- 

do it on first login to any new AWS account.

For readers who did not create their own AWS account, and instead were provided access to a user within a shared account - you can log in with that user and skip down to 


Many AWS Organizations-created accounts already have CloudTrail configured by default If CloudTrail is already enabled by organization policy, skip this step.

 is a service which keeps records for the last 90 days worth of management API events in AWS. This includes information about which user logged in, where they logged in from, and any changes they made to account users and permissions. These events are incredibly useful when you need to monitor an account that is shared by multiple users, and have value for auditing purposes even when you don’t plan to share an AWS account.

If you are the owner of your AWS account, it’s highly recommended that you create a custom CloudTrail configuration that spans all regions and logs management events to a S3 bucket for long-term storage. Creating an S3 bucket along with this Trail will allow you to save events longer than the default length of 90 days, but can incur some cost if your account is very active and generates large volumes of data for storage. If you are not running productions services or staying in free-tier is important, you can choose not to configure a S3 bucket. The first management trail you configure in any AWS account is free, so you will only see charges if you create multiple management trails, create data trails (Trails which log in-depth information for AWS Resources beyond basic management resources - very useful for troubleshooting at times), or if you configure a S3 bucket with your trail. You can read more details on 

 and decide if long-term storage is right for you.

Navigate to the AWS CloudTrail console by typing 

 into the home page of the AWS web console.

Create the CloudTrail config by clicking the 1Create trail1 button from the CloudTrail management page.

Configure the trail settings as shown below:

Trail Name
: Name the trail something obvious, like 

 so you don’t lose any potentially data.

Click the blue button below to finish creating the trail. The trail will now appear in the CloudTrail Dashboard.

Billing Alerts are useful to manage your costs, but they also have security benefits since cost-overrun alerts can warn us of a potential account compromise situation.

Contact AWS Support in case of cost concerns

If you ever do find yourself experiencing an unusual cost over-run, contact AWS Support immediately for assistance. If your account was compromised - they can help you lock it down and usually reverse any charges generated by an attacker. 

Even if your account wasn’t compromised, AWS Support will often refund unexpected costs when they happen due to misunderstanding or accidental misconfiguration - so ask!

While still signed in as the root user, go to the 

The screen below should appear with options for enabling alerts.

If you are planning to use free-tier, ensure the box for 

 is checked. You may add an email address into the field shown if you need alerts for free-tier usage alerts to be sent to an email address other than the account default email.

If you would like to receive alerts that are tailored to a specific cost threshold (ie, alert if estimate exceeds $10), then select the 

 Link to go to the CloudWatch page for Billing alerts. See the AWS Documentation  for complete information about configuring 

The default password policy that comes configured with new accounts is comically weak. It’s important to update this policy before you add any new users.

To update the default password policy:
Go to 

 to bring up the policy configuration screen.

The password policy can vary depending on organizational security policy, but aim to be as strong or stronger than the policy shown here:

AWS supports many different regions to allow you to deploy to endpoints closest to your users. In practice though, many AWS customers only ever use one or two regions.

When an AWS account is compromised, attackers often choose to utilize lesser-used regions in hopes that their changes to resource usage will go unnoticed. But more commonly - it’s just easy to forget about resources that were created in rarely-used regions you don’t normally use and end up paying for them longer than you intended.

 page, we can deactivate regions that we do not plan to us. This ensures that any authentication credentials created for our account cannot be used for those de-activated regions.

 option has been clicked on every region except 

Why isn't it possible to deactivate US East (us-east-1)?

 region was the first region created by AWS, and as such, it is a bit of a snowflake. Many services that are not specific to any particular region (“global” services such as 

---
title: How to Setup a Free AWS Developer Environment
isPublicLesson: true
description: "There's no `AWS Lambda` without `AWS`. That means we'll need a few AWS resources created and configured on the AWS side of things to develop and effectively."
---

# AWS Environment Setup

There's no `AWS Lambda` without `AWS`. That means we'll need a few AWS resources created and configured on the AWS side of things to develop and effectively.

Those resources include:

-   Access to an AWS Account
-   An `IAM User` on that AWS Account which has rights to interact with AWS Lambda, and related services. The rights that come with `Administrator Access` or `Power User Access` cover most everything we will touch.
-   API Access Key credentials for our `IAM User`. This key will be saved on our local development machine and used to deploy our Lambda's programatically.

Additionally, even if you have all of the above ready - we recommend reading the [Securing Your AWS Account](#securing-aws) section to learn how to keep your AWS Account secured.

**Spending 15 minutes now will save you hours later if you ever need regain access after a compromise!**

W> **Every AWS Account is a potential target.**
W> A common misconception about AWS is the belief that it is not necessary to secure your account when it’s only being used for testing or minor projects. **Many attackers don’t want to steal your data - they want to steal your AWS compute resources.** An attacker will often use compromised accounts to spin up expensive instances for crypto mining or botnet attacks. Sometimes they use unusual AWS regions and dedicated instances so those instances don’t appear visible in a user’s usual dashboard. Some users don’t realize they have been attacked until they receive an expensive bill! Alternatively, AWS may reach out and temporarily disable a compromised account if they detect it is being used for malicious purposes. This can be a serious headache that can affect uptime for anyone running legitimate production services.

## A note on Free-Tier usage and costs in AWS

Every exercise in this course will comply with [AWS free-tier offerings](https://aws.amazon.com/free/). If we are using an account that is still free-tier eligible, there should be no billed charged for completing any exercises as defined in the book. Some projects could potentially incur cost past free-tier with heavy usage (ie, deploying the dicebot project into a popular channel where it gets invoked frequently). However - _simply deploying and testing these applications will not incur cost if free-tier is active._ Steps for removing the deployed project from AWS will also be included. **It is recommended to always cleanup work after completion. We can always re-deploy projects later.**

> **Additional Recommended Reading on this topic**
>  [Guidance for Avoiding Unexpected Charges](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/checklistforunwantedcharges.html).

## Common AWS Scenarios

We recognize that exposure to AWS might vary wildly among our readers. You can use the links below to jump to whichever section of the course is most relevant to your needs.

-   [I need to create a new AWS Account for myself or my organization](#standard-signup)
-   [My work or school has an AWS Account, but I need access to it](#aws-orgs)
-   [I can log into my AWS Account, but I do not have an API Access Key](#create-user)
-   [I can log into my AWS Account, and I have an API Access Key](#local-config)

## Account Provisioning

### For Developers new to AWS (Standard Signup)

For everyone else, we will need to register a standard AWS Account in our own name, or in our business’ name on the [AWS Signup Page](https://portal.aws.amazon.com/billing/signup). Be aware - creating an AWS Account requires a valid credit card, even if we only intend to use free-tier services and/or promotional credits.

W> WARNING - Automated Fraud Prevention 
W> AWS Fraud detection may enforce a hold-period of **up to 24-hours** when registering an account associated with a high-fraud risk locale!

### For Members of Organizations that already use AWS  (AWS Organizations)

If your workplace or organization already uses AWS - you may be able to request access to an existing account or ask your AWS Account Admin to provision you a new one through the [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create.html#orgs_manage_accounts_create-new) service.

### For Students (AWS Educate)

If you are a student with a valid `.edu` email address, you can register for a special AWS account that includes promotional credit and other training resources through the [AWS Educate Program](https://www.awseducate.com/registration#APP_TYPE).

## Securing an AWS Account

Security changes only take a few minutes to make, but they will significantly improve the risk posture of an AWS account. Don’t put this step off for later,- **do it on first login to any new AWS account.**

For readers who did not create their own AWS account, and instead were provided access to a user within a shared account - you can log in with that user and skip down to [Enable MFA on IAM User](#enable-mfa)

## Configure CloudTrail

I> **Note for Accounts created by `AWS Organization`**
I> Many AWS Organizations-created accounts already have CloudTrail configured by default If CloudTrail is already enabled by organization policy, skip this step.

[CloudTrail](https://aws.amazon.com/cloudtrail/) is a service which keeps records for the last 90 days worth of management API events in AWS. This includes information about which user logged in, where they logged in from, and any changes they made to account users and permissions. These events are incredibly useful when you need to monitor an account that is shared by multiple users, and have value for auditing purposes even when you don’t plan to share an AWS account.

If you are the owner of your AWS account, it’s highly recommended that you create a custom CloudTrail configuration that spans all regions and logs management events to a S3 bucket for long-term storage. Creating an S3 bucket along with this Trail will allow you to save events longer than the default length of 90 days, but can incur some cost if your account is very active and generates large volumes of data for storage. If you are not running productions services or staying in free-tier is important, you can choose not to configure a S3 bucket. The first management trail you configure in any AWS account is free, so you will only see charges if you create multiple management trails, create data trails (Trails which log in-depth information for AWS Resources beyond basic management resources - very useful for troubleshooting at times), or if you configure a S3 bucket with your trail. You can read more details on [pricing](https://aws.amazon.com/cloudtrail/pricing/) and decide if long-term storage is right for you.

### Create a Management Trail

Navigate to the AWS CloudTrail console by typing `CloudTrail` into the home page of the AWS web console.

![AWS Web Console Main Dashboard screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/1-cloudtrail.png)

Create the CloudTrail config by clicking the 1Create trail1 button from the CloudTrail management page.

![AWS Web Console Cloudtrail screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/2-cloudtrail.png)

The next page will look like this:

![AWS Web console Cloudtrail Create screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/3-cloudtrail.png)

Configure the trail settings as shown below:

Trail Name
: Name the trail something obvious, like `ManagementTrail`.

Apply Trail to all regions
: Should be `Yes`.

Read/write events
: Use the default of `All` so you don’t lose any potentially data.

Storage Location

-   Create a new S3 Bucket
-   `Yes` if we decided to store events beyond 90 days in S3 (which may incur small charges beyond free-tier if the account is highly utilized). If selecting `No`, skip the setting below for `S3 Bucket`
-   S3 bucket
-   the name for a new bucket. S3 buckets names must always be globally unique - meaning unique across every AWS account, so try a name formatted like `cloudtrail-mgmt-myname`.

Click the blue button below to finish creating the trail. The trail will now appear in the CloudTrail Dashboard.

![AWS Web console Cloudtrail Created screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/4-cloudtrail.png)

## Billing Alerts

Billing Alerts are useful to manage your costs, but they also have security benefits since cost-overrun alerts can warn us of a potential account compromise situation.

T> Contact AWS Support in case of cost concerns
T>
T> If you ever do find yourself experiencing an unusual cost over-run, contact AWS Support immediately for assistance. If your account was compromised - they can help you lock it down and usually reverse any charges generated by an attacker. **Even if your account wasn’t compromised, AWS Support will often refund unexpected costs when they happen due to misunderstanding or accidental misconfiguration - so ask!**

### Enable Billing Alerts

While still signed in as the root user, go to the [AWS Billing Dashboard](https://console.aws.amazon.com/billing/home?#/)

On the left side, select `Billing Preferences`

![AWS Web console - billing dashboard screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/1-billing.png)

The screen below should appear with options for enabling alerts.

![AWS Web console - billing preferences screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/2-billing.png)

If you are planning to use free-tier, ensure the box for `Receive Free Tier Usage Alerts` is checked. You may add an email address into the field shown if you need alerts for free-tier usage alerts to be sent to an email address other than the account default email.

If you would like to receive alerts that are tailored to a specific cost threshold (ie, alert if estimate exceeds $10), then select the `Receive Billing Alerts` box. From there,  click through on the `Manage Billing Alerts` Link to go to the CloudWatch page for Billing alerts. See the AWS Documentation  for complete information about configuring [CloudWatch Billing Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html#creating_billing_alarm_with_wizard)

## Set a password policy for the account

The default password policy that comes configured with new accounts is comically weak. It’s important to update this policy before you add any new users.

To update the default password policy:
Go to `IAM` > `Account Settings` from the AWS Dashboard.

![AWS Web console -IAM dashboard screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/1-password-policy.png)

Click the grey button that says `Set password policy` to bring up the policy configuration screen.

![AWS Web console -IAM password policy screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/2-password-policy.png)

The password policy can vary depending on organizational security policy, but aim to be as strong or stronger than the policy shown here:

![AWS Web console -IAM password policy screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/3-password-policy.png)

-   Update the character length under “Enforce minimum password length” to AT LEAST 12
-   Require at least one uppercase letter
-   Require at least one lowercase letter
-   Require at least one number
-   Require at least one non-alphanumeric character
-   Enable password expiration of at least 90 days
-   Allow users to change their own password

Save the changes.

## Deactivate Regions not in use (optional)

AWS supports many different regions to allow you to deploy to endpoints closest to your users. In practice though, many AWS customers only ever use one or two regions.

When an AWS account is compromised, attackers often choose to utilize lesser-used regions in hopes that their changes to resource usage will go unnoticed. But more commonly - it’s just easy to forget about resources that were created in rarely-used regions you don’t normally use and end up paying for them longer than you intended.

From the `IAM` > `Account Settings` page, we can deactivate regions that we do not plan to us. This ensures that any authentication credentials created for our account cannot be used for those de-activated regions.

In the example below, the `deactivate` option has been clicked on every region except `us-east-1` and `us-west-2`.

![AWS Web console -IAM account regions screenshot](https://d2uusema5elisf.cloudfront.net/courses/create-a-serverless-slackbot-with-aws-lambda-and-python/module_02/lesson_02.01/public/images/1-deactivate-regions.png)

Q> Why isn't it possible to deactivate US East (us-east-1)?
Q>
Q> The `us-east-1` region was the first region created by AWS, and as such, it is a bit of a snowflake. Many services that are not specific to any particular region (“global” services such as `IAM` and `Billing`), are actually running from `us-east-1`.