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

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

 that we received from the credentials.csv in previous steps.

For default region name, use the region id that matches whichever region we plan to use the most frequently.

In general, it's good practice to use the region that is physically closes to us (or closest to our customers) to reduce latency. AWS works hard to ensure that there are many regions available, but it's not guaranteed that each region supports every AWS Service. A full breakdown of regions and their supported service endpoints is available at the 

AWS Documentation page for region endpoints

 and respond to the prompts as shown below.

AWS Access Key ID
:  If you've already set up your 

) as described in the previous section, this value will be pulled automatically. If it shows a value like 

, in the prompt, press enter so that it preserves that value. If you did not set up your shared credentials file. Otherwise, paste in the value from the 

 that was downloaded when you IAM user was created.
  Hint: Usually starts with "AKIA". 

AWS Secret Access Key
: If you've already set up your 

, press enter so that it preserves that value. Otherwise, paste in the value from the 

 file that was downloaded when you IAM user was created.

---
title: How to Login to AWS CLI and Configure Default Region
isPublicLesson: true
description: "The easiest way to configure our local development with our credentials is to run the command `aws configure`"
---

# Configuring the AWS CLI

The easiest way to configure our local development with our credentials is to run the command `aws configure`. We can then paste in the values for `Access Key ID` and `Secret Access Key` that we received from the credentials.csv in previous steps.

For default region name, use the region id that matches whichever region we plan to use the most frequently.

Some common ones:

-   US Virginia: `us-east-1`
-   US Oregon: `us-west-2`
-   EU Frankfurt: `eu-central-1`

I> Selecting default region
I>
I> In general, it's good practice to use the region that is physically closes to us (or closest to our customers) to reduce latency. AWS works hard to ensure that there are many regions available, but it's not guaranteed that each region supports every AWS Service. A full breakdown of regions and their supported service endpoints is available at the [AWS Documentation page for region endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#endpoint-tables)

For our example, we're going to use `us-east-1`.

So from our terminal, we'll run `aws configure` and respond to the prompts as shown below.

AWS Access Key ID
:  If you've already set up your [sharedCredentials File](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/create-shared-credentials-file.html)) as described in the previous section, this value will be pulled automatically. If it shows a value like `[********ABCD]`, in the prompt, press enter so that it preserves that value. If you did not set up your shared credentials file. Otherwise, paste in the value from the `Access Key ID` column of the `Credentials.csv` that was downloaded when you IAM user was created.
  Hint: Usually starts with "AKIA". 

How to Login to AWS CLI and Configure Default Region

Masterclasses

Tutorials

Fullstack React with TypeScript