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

Now that our AWS Account is largely configured - it is possible to configure an 

 as the development environment to use for developing for AWS Lambda.

These tools are best used for cases where developers are unable to install the required development software onto their local development machine due to technical limitations or permissions issues. See pricing info before using any of these

AWS Workspaces - Standard with Amazon Linux 2

 provides persistent computer workspaces (complete with a GUI) that can be used from almost any client that has access to internet. AWS provides a free-tier eligible workspace bundle called 

 - and that should work just fine with everything shown in this course. It's possible to connect to Amazon Linux Workspaces from Windows, Mac OS, ChromeOS, Android, and iOS. At this time - Linux can connect to some Amazon Linux 2 Workspaces via Firefox or Chrome - though it can connect to Windows workspaces. Hopefully future updates will resolve that issue. If a remote solution is needed for Linux, consider using 

Workspace Pricing information (Important if not using free-tier!)
: 

https://aws.amazon.com/workspaces/pricing/

Instructions for launching an AWS Workspace
: 

https://docs.aws.amazon.com/workspaces/latest/adminguide/getting-started.html

It is also possible to use a plain Amazon Linux 2 EC2 Instance for developing for Lambda. The setup for this is more complex than for AWS Workspaces, but works fine for users familiar with EC2 already.

Remember to select a free-tier qualifying instance (such as 

) if that is important, and ensure that the instance has an AWS Security group that is locked down tight. A standard GUI will not be available easily when taking this path, but this course is very oriented to terminal usage anyhow. Instructions are provided below for using VSCode over SSH, which is recommended when using this setup.

https://code.visualstudio.com/docs/remote/ssh

Create an Administrator Account for Yourself 

 step above, we do not need to create credentials again. The CSV  downloaded at the last step of user creation will have the necessary information present.

Otherwise, we'll need to create a set of credentials using the instructions below.

Never commit any file that contains the secret access key to source control, and do not leave any file that contains it on a shared server, even internally.

 EC2 Servers and application code should never use a secret key to connect to any other EC2 services. 

 (discussed in later chapters) are the ONLY acceptable way to authenticate for applications.

If we ever accidentally commit code with a secret key present, or otherwise find ourselves in a situation where the key may have been leaked - go to the same page where the key was added and click 

 immediately. It will be required to re-provision a new key in that leaked key's place.

With our API Access Credentials in hand (check the 

 file from step above), we can now pre-configure our local development machine to store those values so that they will be used with the AWS tooling.

To do this, follow the instructions provided by AWS to 

. If you already have a shared credentials file configured, you probably do not need to update it unless you are using a different account and IAM user for Lambda development.

We'll hold off on further configuration steps, like setting a default region, until we've got the 

That's it for the AWS-specific portion of setup. Next up, we'll need to configure our local development machine

---
title: How to Configure EC2 and AWS Workspaces Local Credentials
isPublicLesson: true
description: "Here, we'll configure an `AWS Workspace` or `AWS EC2 Instance` as the development environment to use for developing for AWS Lambda."
---

# Configuring Our AWS Workspace

## Remote Workspace - (Optional)

Now that our AWS Account is largely configured - it is possible to configure an `AWS Workspace` or `AWS EC2 Instance` as the development environment to use for developing for AWS Lambda.

**These tools are best used for cases where developers are unable to install the required development software onto their local development machine due to technical limitations or permissions issues. See pricing info before using any of these**

### AWS Workspaces - Standard with Amazon Linux 2

[AWS Workspaces](https://aws.amazon.com/workspaces/) provides persistent computer workspaces (complete with a GUI) that can be used from almost any client that has access to internet. AWS provides a free-tier eligible workspace bundle called `Standard with Amazon Linux 2` - and that should work just fine with everything shown in this course. It's possible to connect to Amazon Linux Workspaces from Windows, Mac OS, ChromeOS, Android, and iOS. At this time - Linux can connect to some Amazon Linux 2 Workspaces via Firefox or Chrome - though it can connect to Windows workspaces. Hopefully future updates will resolve that issue. If a remote solution is needed for Linux, consider using [EC2](#remote-ec2), as shown below

Workspace Pricing information (Important if not using free-tier!)
: <https://aws.amazon.com/workspaces/pricing/>.

Instructions for launching an AWS Workspace
: <https://docs.aws.amazon.com/workspaces/latest/adminguide/getting-started.html>

### AWS EC2 Instance (Amazon Linux 2)

It is also possible to use a plain Amazon Linux 2 EC2 Instance for developing for Lambda. The setup for this is more complex than for AWS Workspaces, but works fine for users familiar with EC2 already.

Remember to select a free-tier qualifying instance (such as `t2.micro`) if that is important, and ensure that the instance has an AWS Security group that is locked down tight. A standard GUI will not be available easily when taking this path, but this course is very oriented to terminal usage anyhow. Instructions are provided below for using VSCode over SSH, which is recommended when using this setup.

Connect VSCode to remote SSH
: <https://code.visualstudio.com/docs/remote/ssh>

## Configure Local AWS Credentials

If we created our own user in the [Create an Administrator Account for Yourself ](#create-user) step above, we do not need to create credentials again. The CSV  downloaded at the last step of user creation will have the necessary information present.

Otherwise, we'll need to create a set of credentials using the instructions below.

-   Navigate to the [IAM console](https://console.aws.amazon.com/iam) 
-   Click `Users` on the left
-   Select our user name from the list of users to the right
-   Click the `Security Credentials` Tab
-   Click the `Create access key` button underneath the `Access keys` header.
-   On the pop-up which appears, click `Download .csv file` and save that file to a secure, local location.

W> Do not commit access keys or share them
W>
W> **Never commit any file that contains the secret access key to source control, and do not leave any file that contains it on a shared server, even internally.** EC2 Servers and application code should never use a secret key to connect to any other EC2 services. `IAM Roles` (discussed in later chapters) are the ONLY acceptable way to authenticate for applications.
W>
W> If we ever accidentally commit code with a secret key present, or otherwise find ourselves in a situation where the key may have been leaked - go to the same page where the key was added and click `deactivate key` immediately. It will be required to re-provision a new key in that leaked key's place.

With our API Access Credentials in hand (check the `Credentials.csv` file from step above), we can now pre-configure our local development machine to store those values so that they will be used with the AWS tooling.

To do this, follow the instructions provided by AWS to [Create a shared Credentials File](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/create-shared-credentials-file.html). If you already have a shared credentials file configured, you probably do not need to update it unless you are using a different account and IAM user for Lambda development.

We'll hold off on further configuration steps, like setting a default region, until we've got the `aws cli` tool installed.

## Configure Local Development Machine

That's it for the AWS-specific portion of setup. Next up, we'll need to configure our local development machine
