spell checking docs

.gitignore

@@ -1,2 +1,3 @@
 **/.DS_Store
 **/.mypy_cache
+.vscode/**

00-quick-start/README.md

@@ -1,6 +1,6 @@
 # Serverless Quick Start
 
-In this module you'll be introduced to a basic serverless monolithic three tier web application. What we'll deploy and work with in this module is a simpler version of the Wild Rydes tech stack. The purpose of this is to more easilly understand how serverless architecture works without the added complexity that microservices introduce.
+In this module you'll be introduced to a basic serverless monolithic three tier web application. What we'll deploy and work with in this module is a simpler version of the Wild Rydes tech stack. The purpose of this is to more easily understand how serverless architecture works without the added complexity that microservices introduce.
 
 ## Goals and Objectives:
 

01-up-and-running/02-build-new-service/README.md

@@ -36,13 +36,13 @@ Serverless Framework projects are controlled by the _serverless.yml_ file. In th
 ```yaml
 
 # This is the name of service we'll be deploying. You'll see it in the AWS
-# Cloudfromation stack name.
+# Cloudformation stack name.
 service: <NAME>
 
 # Additional functionality and enhancements to Serverless Framework.
 plugins:
 
-# Reuasable values and or plugin configuration.
+# Reusable values and or plugin configuration.
 custom:
 
 
@@ -61,7 +61,7 @@ provider:
 functions:
 
 
-# Addtional service resources and configuration.
+# Additional service resources and configuration.
 resources:
   # Additional AWS resources , e.g. DynamoDB tables, S3 Buckets, etc, are
   # configured here. For AWS, this is just CloudFormation configuration.
@@ -120,14 +120,14 @@ $ nano serverless.yml
 ```yaml
 
 # This is the name of service we'll be deploying. You'll see it in the AWS
-# Cloudfromation stack name.
+# Cloudformation stack name.
 service: wild-rydes-ride-record
 
 # Additional functionality and enhancements to Serverless Framework.
 plugins:
   - serverless-python-requirements
 
-# Reuasable values and or plugin configuration.
+# Reusable values and or plugin configuration.
 custom:
 
 
@@ -153,7 +153,7 @@ functions:
     timeout: 29
 
 
-# Addtional service resources and configuration.
+# Additional service resources and configuration.
 resources:
   # Additional AWS resources , e.g. DynamoDB tables, S3 Buckets, etc, are
   # configured here. For AWS, this is just CloudFormation configuration.
@@ -248,7 +248,7 @@ The following Serverless Framework docs will help:
 <summary><strong>Hint 2</strong></summary>
 <p>
 
-* __IAM role:__ Your role will need to frant the _dynamodb:PutItem_ permission to the _RideRecordTable_ DynamoDB table. You can use the [Fn::GetAtt function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html#w2ab1c21c10d413c15) to obtain the table's _Arn_ value.
+* __IAM role:__ Your role will need to grant the _dynamodb:PutItem_ permission to the _RideRecordTable_ DynamoDB table. You can use the [Fn::GetAtt function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html#w2ab1c21c10d413c15) to obtain the table's _Arn_ value.
 * __Function environmental variables:__ Use the [Ref function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html#w2ab1c21c10d413c15) to obtain the DynamoDB table's name.
 </p>
 </details>
@@ -344,7 +344,7 @@ Take a look at the sample event under [tests/events/put_ride_record.json](https:
 <details>
 <summary><strong>Hint 2</strong></summary>
 <p>
-This is the Python Boto3 dcumentation for working with a DynamoDB table.
+This is the Python Boto3 documentation for working with a DynamoDB table.
 
 * [Boto3 DynamoDB.Table](https://boto3.readthedocs.io/en/latest/reference/services/dynamodb.html#table)
 </p>
@@ -765,14 +765,14 @@ Q. What are the different sections of the _serverless.yml_ file for?
 
 **plugins:** Serverless Framework's core functionality can be extended by the use of plugins. In this section we list the plugins a service requires.
 
-**custom:** This section is uusally used for two purposes
+**custom:** This section is usually used for two purposes
 
 1) Defining variables that will be used elsewhere in the file
 1) Plugin configuration.
 
 **provider:** This is where we configure the service for the serverless provider the service is to be deployed.
 
-**resources:** Some AWS serverless systems require more than AWS Lambda. This section is where we configure those resources using [AWS CLoudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html).
+**resources:** Some AWS serverless systems require more than AWS Lambda. This section is where we configure those resources using [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html).
 </p>
 </details>
 

02-architecture/01-asynchronous-event-driven/README.md

@@ -2,7 +2,7 @@
 
 In this module we'll cover event driven architecture and asynchronous service communication. We'll do this by refactoring the _wild-rydes-ride-record_ service to support an event driven architecture in addition to its microservice web request architecture.
 
-Additionally, we'll revisit service discovery between services by introducing AWS Systems Manager Paramater Store (SSM).
+Additionally, we'll revisit service discovery between services by introducing AWS Systems Manager Parameter Store (SSM).
 
 ## Goals and Objectives
 
@@ -31,13 +31,13 @@ To improve the user's experience we'll convert the process of recording rides to
 
 ![Service Diagram](../../images/wild-rydes-event-driven.png)
 
-Instead of *RequetRide* in the *wild-rydes* service making a web request to the *wild-rydes-ride-record* service to trigger the *RecordRide* Lambda function, *RequestRide* will publish a message to an SNS topic. The *wild-rydes-ride-record* service will have a function that is subscribed to the SNS topic which will write the ride data to DynamoDB. This will allow *RequestRide* to complete and return information to the user without needing to wait for our backend service to write to DynamoDB.
+Instead of *RequestRide* in the *wild-rydes* service making a web request to the *wild-rydes-ride-record* service to trigger the *RecordRide* Lambda function, *RequestRide* will publish a message to an SNS topic. The *wild-rydes-ride-record* service will have a function that is subscribed to the SNS topic which will write the ride data to DynamoDB. This will allow *RequestRide* to complete and return information to the user without needing to wait for our backend service to write to DynamoDB.
 
 ## Service Discovery
 
- In a previous module we had wild-rydes-ride-record export a URL as a CloudFormation output and wild-rydes queried the value from CloudFormation. This time we’re exporting an SNS topic ARN to AWS Systems Manager Paramater Store (SSM) instead of CloudFormation. SSM is a key-value store and provides an alternative way to perform service discovery in AWS among other uses. We’ll use SSM increasingly in later workshop modules.
+ In a previous module we had wild-rydes-ride-record export a URL as a CloudFormation output and wild-rydes queried the value from CloudFormation. This time we’re exporting an SNS topic ARN to AWS Systems Manager Parameter Store (SSM) instead of CloudFormation. SSM is a key-value store and provides an alternative way to perform service discovery in AWS among other uses. We’ll use SSM increasingly in later workshop modules.
 
-Which should you use? It’s a matter of preference. CloudFormation outputs can only be modified by CloudFormation. However, SSM’s hierarchical key paths make it possible to create IAM policies that grant slective read and write capabilities to different keys.
+Which should you use? It’s a matter of preference. CloudFormation outputs can only be modified by CloudFormation. However, SSM’s hierarchical key paths make it possible to create IAM policies that grant selective read and write capabilities to different keys.
 
 ## Instructions
 
@@ -72,7 +72,7 @@ Create an SNS topic which *RequestRide* will publish ride information too. Inste
 
 This change will:
 * Decrease the average duration of the *RequestRide* function.
-* Reduce the liklihood of downstream services inducing failure.
+* Reduce the likelihood of downstream services inducing failure.
 * Allow for adding more downstream services without altering *RequestRide*
 
 
@@ -179,7 +179,7 @@ Reference the CloudFormation documentation here:
 </p>
 </details>
 
-#### Pass SNS topic ARN to *RequestRide* Lamda function
+#### Pass SNS topic ARN to *RequestRide* Lambda function
 The *RequestRide* function now needs to publish to the SNS topic. Edit _serverless.yml_ to pass the SNS topic's ARN to the *RequestRide* function as an environmental variable named *RIDES_SNS_TOPIC_ARN*. Use the CloudFormation *Ref* function again to get the ARN of the SNS topic you  created in previous steps. While you're here, remove the *RIDE_RECORD_URL* environmental variable as it will no longer be necessary.
 
 Reference the Serverless Framework and CloudFormation documentation here:
@@ -778,7 +778,7 @@ How to trigger a Lambda function via an SNS event can be found here:
 +++ b/serverless.yml
 @@ -16,6 +16,9 @@ custom:
    ddb_table_hash_key: 'RideId'
-   sevrice_url_path_base: '/record'
+   service_url_path_base: '/record'
 
 +  wild_rydes_sns_topic_arn: "${ssm:/wild-rydes/${self:custom.stage}/SnsTopicArn}"
 +
@@ -788,7 +788,7 @@ How to trigger a Lambda function via an SNS event can be found here:
    runtime: python3.6
 @@ -50,6 +53,17 @@ functions:
            method: POST
-           path: "${self:custom.sevrice_url_path_base}"
+           path: "${self:custom.service_url_path_base}"
 
 +  PutRideRecordSns:
 +    handler: handlers/put_ride_record.handler_sns

02-architecture/02-synchronous-requests/README.md

@@ -34,7 +34,7 @@ While continuing with a web microservices pattern using API Gateway and Lambda i
   * API Gateway requests are charged independent of Lambda invocations
 * Added request latency.
 
-In this module we'll demonstrate how to bypass API Gateway and have one Lambda function invoke another directly for making a synchronus request. Instead of an HTTP endpoint providing a stable interface to trigger our code, we will trigger a function handler directly using an [AWS SDK API for Lambda function invocation](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lambda.html#Lambda.Client.invoke). Depending on your needs, this can be a useful pattern for application.
+In this module we'll demonstrate how to bypass API Gateway and have one Lambda function invoke another directly for making a synchronous request. Instead of an HTTP endpoint providing a stable interface to trigger our code, we will trigger a function handler directly using an [AWS SDK API for Lambda function invocation](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lambda.html#Lambda.Client.invoke). Depending on your needs, this can be a useful pattern for application.
 
 ![Lambda Invoke Request](../../images/wild-rydes-lambda-invoke.png)
 
@@ -54,7 +54,7 @@ $ sls deploy -v
 
 ### 2. Refactor *wild-rydes-ride-fleet* *GetUnicorn* for direct invocation.
 
-We'll refactor this service so it's possible to easilly get a unicorn from the fleet by directly invoking the function. When done there will be be a new Lambda function that expects to be invoked directly using the [AWS SDK API for Lambda function invocation](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lambda.html#Lambda.Client.invoke).
+We'll refactor this service so it's possible to easily get a unicorn from the fleet by directly invoking the function. When done there will be be a new Lambda function that expects to be invoked directly using the [AWS SDK API for Lambda function invocation](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lambda.html#Lambda.Client.invoke).
 
 _NOTE: We'll create two Lambda functions because we still need the API Gateway for the *LoadTable* Lambda function and custom resource. This way you're not forced to refactor that too._
 
@@ -75,7 +75,7 @@ Start by renaming the python function `handler()` to `handler_apig()` to indicat
 
 -def handler(event, context):
 -    '''Function entry'''
-+def handler_invoke(event, contect):
++def handler_invoke(event, context):
 +    '''Function entry for Lambda synchronous invoke'''
 +    _logger.debug('Request: {}'.format(json.dumps(event)))
 +
@@ -131,9 +131,9 @@ Your _serverless.yml_ file should now have two functions which correspond to the
 </p>
 </details>
 
-Next, create an SSM paramater named `/wild-rydes-ride-fleet/${self:provider.stage}/RequestUnicornInvokeArn` with a value of the ARN of the *RequestUnicornInvoke* Lambda function. You can use the *Fn::GetAtt* CloudFormation function to get the Arn.
+Next, create an SSM parameter named `/wild-rydes-ride-fleet/${self:provider.stage}/RequestUnicornInvokeArn` with a value of the ARN of the *RequestUnicornInvoke* Lambda function. You can use the *Fn::GetAtt* CloudFormation function to get the Arn.
 
-_NOTE: Serverless Framework renames function resourcess in the template it generates by adding "LambdaFunction" onto the end of the name. You'll need to use the Fn::GetAtt with the renamed resource. eg. RequestUnicornInvoke -> RequestUnicornInvokeLambdaFunction _
+_NOTE: Serverless Framework renames function resources in the template it generates by adding "LambdaFunction" onto the end of the name. You'll need to use the Fn::GetAtt with the renamed resource. eg. RequestUnicornInvoke -> RequestUnicornInvokeLambdaFunction _
 
 * [Cloudformation AWS::SSM::Parameter](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-parameter.html)
 * [Cloudformation function Fn::GetAtt](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-getatt.html)
@@ -318,7 +318,7 @@ Next, the code no longer makes an HTTP GET request using the `requests` module.
 
 The `LAMBDA_CLIENT.invoke()` call returns a Python dictionary. We're interested in the value of the `Payload ` key which has the unicorn information. However the key's value is not a string, it's a file-like object. We'll read the contents of the file-like object, which is a string containing a JSON document, and convert it from binary to ascii. Finally we return that data from the function. _NOTE: We figured most people would get tripped up by having to fetch the response data by reading the contents of a file._
 
-Pyton Boto 3Documentation 
+Python Boto 3Documentation 
 
 - [Boto3 Lambda.Client.invoke()](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lambda.html#Lambda.Client.invoke)
 
@@ -360,7 +360,7 @@ Q. Name benefits of using API Gateway.
   * AWS Cognito
   * Custom authorizers
 * Request throttling
-* AWS WAF integration for filtering malicous traffic.
+* AWS WAF integration for filtering malicious traffic.
 * Ability to generate API documentation
   </p>
   </details>
@@ -391,7 +391,7 @@ Q. Which would you choose and why?
 <details>
 <summary><strong>Possible Answer</strong></summary>
 <p>
-Because where making a request between our own services we can do authentication and authorization, request throttling, and malicous traffic filtering at the user facing service, *wild-rydes*. And since we don't feel we would gain additional advanatges through those benefits of API Gateway on *wild-rydes-ride-fleet*, the cost and latency drawbacks make removing API Gateway appealing.
+Because where making a request between our own services we can do authentication and authorization, request throttling, and malicious traffic filtering at the user facing service, *wild-rydes*. And since we don't feel we would gain additional advantages through those benefits of API Gateway on *wild-rydes-ride-fleet*, the cost and latency drawbacks make removing API Gateway appealing.
 </p>
 </details>
 

03-operations/01-failure/README.md

@@ -54,12 +54,12 @@ This workshop module will involve the following Wild Rydes services.
 To aid us in this module we'll be employing two tools. We'll use one to help us generate failures by automating requests to the service and another tool to help us find the cause of these failures.
 
 #### Artillery
-[Artillery](https://artillery.io/) is a load testing tool taht we will use to simulate traffic on our site. Using this tool we will trigger failures.
+[Artillery](https://artillery.io/) is a load testing tool that we will use to simulate traffic on our site. Using this tool we will trigger failures.
 
 #### Thundra
 [Thundra](https://thundra.io) is a serverless monitoring and observability platform designed for AWS Lambda environments. The platform will collect function invocation metrics and logs that will help us diagnose the cause of the issues we find.
 
-In this workshop we're using Thundra over AWS CloudWatch, which provides metrics and logging automatically for Lambda functions. We picked Thundra in part because we find it easier to navigate and illustreate what we want people to see. _(From a workshop perspective, we also use it because we don't to grant attendees AWS Console access in our accounts.)_
+In this workshop we're using Thundra over AWS CloudWatch, which provides metrics and logging automatically for Lambda functions. We picked Thundra in part because we find it easier to navigate and illustrate what we want people to see. _(From a workshop perspective, we also use it because we don't to grant attendees AWS Console access in our accounts.)_
 
 ## Instructions
 
@@ -378,7 +378,7 @@ Error codes:
 <!-- Start collecting traces and logs -->
 Start collecting metrics and logs from *RequestRide* in *wild-rydes* to the Thundra platform. We'll instrument this function by using the [Thundra Python agent](https://github.com/thundra-io/thundra-lambda-agent-python). (You'll instrument the Lambda functions in *wild-rydes-ride-record* in a later module.) By instrumenting the function we'll allow the Thundra platform to start collecting invocation metrics, logs, and trace the length of time spent performing different actions in the Lambda function's code.
 
-*NOTE: Thundra has the ability to automatically instrument functions through the Serverless Framework plugin [serverless-plugin-thundra](https://github.com/thundra-io/serverless-plugin-thundra). This workshop insruments the function manually to demonstrate the actual work involved. We feel this is important for those coming to serverless without an extensive coding background. We want people to see how approachable this work is for non-developers.*
+*NOTE: Thundra has the ability to automatically instrument functions through the Serverless Framework plugin [serverless-plugin-thundra](https://github.com/thundra-io/serverless-plugin-thundra). This workshop instruments the function manually to demonstrate the actual work involved. We feel this is important for those coming to serverless without an extensive coding background. We want people to see how approachable this work is for non-developers.*
 
 #### Add Thundra module
 <!-- FIXME: Evaluate Thundra automated for time. -->
@@ -768,13 +768,13 @@ Q. What CloudWatch metric alarms should be add to be alerted of issues in *wild-
 <summary><strong>Answer</strong></summary>
 <p>
 #### Lambda
-Key ketrics are:
+Key metrics are:
 * Errors
 * Duration
 * Throttles
 
 #### DynamoDB
-Kery metrics are
+Key metrics are
 * SystemErrors
 * ReadThrottleEvents
 * WriteThrottleEvents