sentence-cased titles

Author: mwunderl

doc_source/API_Reference.md

@@ -1,16 +1,16 @@
-# API Reference<a name="API_Reference"></a>
+# API reference<a name="API_Reference"></a>
 
-This section contains the AWS Lambda API Reference documentation\. When making the API calls, you will need to authenticate your request by providing a signature\. AWS Lambda supports signature version 4\. For more information, see [Signature Version 4 Signing Process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *Amazon Web Services General Reference*\. 
+This section contains the AWS Lambda API Reference documentation\. When making the API calls, you will need to authenticate your request by providing a signature\. AWS Lambda supports signature version 4\. For more information, see [Signature Version 4 signing process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *Amazon Web Services General Reference*\. 
 
-For an overview of the service, see [What Is AWS Lambda?](welcome.md)\. 
+For an overview of the service, see [What is AWS Lambda?](welcome.md)\. 
 
 You can use the AWS CLI to explore the AWS Lambda API\. This guide provides several tutorials that use the AWS CLI\.
 
 **Topics**
 + [Actions](API_Operations.md)
 + [Data Types](API_Types.md)
 
-## Certificate Errors When Using an SDK<a name="cert-errors"></a>
+## Certificate errors when using an SDK<a name="cert-errors"></a>
 
 Because AWS SDKs use the CA certificates from your computer, changes to the certificates on the AWS servers can cause connection failures when you attempt to use an SDK\. You can prevent these failures by keeping your computer's CA certificates and operating system up\-to\-date\. If you encounter this issue in a corporate environment and do not manage your own computer, you might need to ask an administrator to assist with the update process\. The following list shows minimum operating system and Java versions:
 + Microsoft Windows versions that have updates from January 2005 or later installed contain at least one of the required CAs in their trust list\. 
@@ -23,4 +23,4 @@ When accessing the AWS Lambda management console or AWS Lambda API endpoints, wh
 + Starfield Services Root Certificate Authority \- G2
 + Starfield Class 2 Certification Authority
 
-Root certificates from the first two authorities are available from [Amazon Trust Services](https://www.amazontrust.com/repository/), but keeping your computer up\-to\-date is the more straightforward solution\. To learn more about ACM\-provided certificates, see [AWS Certificate Manager FAQs\.](https://aws.amazon.com/certificate-manager/faqs/#certificates) 
+Root certificates from the first two authorities are available from [Amazon trust services](https://www.amazontrust.com/repository/), but keeping your computer up\-to\-date is the more straightforward solution\. To learn more about ACM\-provided certificates, see [AWS Certificate Manager FAQs\.](https://aws.amazon.com/certificate-manager/faqs/#certificates) 

doc_source/access-control-identity-based.md

@@ -1,4 +1,4 @@
-# Identity\-based IAM Policies for AWS Lambda<a name="access-control-identity-based"></a>
+# Identity\-based IAM policies for AWS Lambda<a name="access-control-identity-based"></a>
 
 You can use identity\-based policies in AWS Identity and Access Management \(IAM\) to grant users in your account access to Lambda\. Identity\-based policies can apply to users directly, or to groups and roles that are associated with a user\. You can also grant users in another account permission to assume a role in your account and access your Lambda resources\.
 
@@ -10,15 +10,15 @@ Lambda provides managed policies that grant access to Lambda API actions and, in
 Managed policies grant permission to API actions without restricting the functions or layers that a user can modify\. For finer\-grained control, you can create your own policies that limit the scope of a user's permissions\.
 
 **Topics**
-+ [Function Development](#permissions-user-function)
-+ [Layer Development and Use](#permissions-user-layer)
-+ [Cross\-Account Roles](#permissions-user-xaccount)
++ [Function development](#permissions-user-function)
++ [Layer development and use](#permissions-user-layer)
++ [Cross\-account roles](#permissions-user-xaccount)
 
-## Function Development<a name="permissions-user-function"></a>
+## Function development<a name="permissions-user-function"></a>
 
 The following shows an example of a permissions policy with limited scope\. It allows a user to create and manage Lambda functions named with a designated prefix \(`intern-`\), and configured with a designated execution role\.
 
-**Example Function Development Policy**  
+**Example Function development policy**  
 
 ```
 {
@@ -164,11 +164,11 @@ This policy allows a user to get started with Lambda, without putting other user
 
 When you configure triggers for your function, you need access to use the AWS service that invokes your function\. For example, to configure an Amazon S3 trigger, you need permission to Amazon S3 actions to manage bucket notifications\. Many of these permissions are included in the **AWSLambdaFullAccess** managed policy\. Example policies are available in this guide's [GitHub repository](https://github.com/awsdocs/aws-lambda-developer-guide/tree/master/iam-policies)\.
 
-## Layer Development and Use<a name="permissions-user-layer"></a>
+## Layer development and use<a name="permissions-user-layer"></a>
 
 The following policy grants a user permission to create layers and use them with functions\. The resource patterns allow the user to work in any AWS Region and with any layer version, as long as the name of the layer starts with `test-`\.
 
-**Example Layer Development Policy**  
+**Example Layer development policy**  
 
 ```
 {
@@ -223,10 +223,10 @@ You can also enforce layer use during function creation and configuration with t
 
 To ensure that the condition applies, verify that no other statements grant the user permission to these actions\.
 
-## Cross\-Account Roles<a name="permissions-user-xaccount"></a>
+## Cross\-account roles<a name="permissions-user-xaccount"></a>
 
 You can apply any of the preceding policies and statements to a role, which you can then share with another account to give it access to your Lambda resources\. Unlike an IAM user, a role doesn't have credentials for authentication\. Instead, it has a *trust policy* that specifies who can assume the role and use its permissions\.
 
 You can use cross\-account roles to give accounts that you trust access to Lambda actions and resources\. If you just want to grant permission to invoke a function or use a layer, use [resource\-based policies](access-control-resource-based.md) instead\.
 
-For more information, see [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the *IAM User Guide*\.
+For more information, see [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the *IAM User Guide*\.

doc_source/access-control-resource-based.md

@@ -1,4 +1,4 @@
-# Using Resource\-Based Policies for AWS Lambda<a name="access-control-resource-based"></a>
+# Using resource\-based policies for AWS Lambda<a name="access-control-resource-based"></a>
 
 AWS Lambda supports resource\-based permissions policies for Lambda functions and layers\. Resource\-based policies let you grant usage permission to other accounts on a per\-resource basis\. You also use a resource\-based policy to allow an AWS service to invoke your function\.
 
@@ -23,12 +23,12 @@ You can only update resource\-based policies for Lambda resources within the sco
 Resource\-based policies apply to a single function, version, alias, or layer version\. They grant permission to one or more services and accounts\. For trusted accounts that you want to have access to multiple resources, or to use API actions that resource\-based policies don't support, you can use [cross\-account roles](access-control-identity-based.md)\.
 
 **Topics**
-+ [Granting Function Access to AWS Services](#permissions-resource-serviceinvoke)
-+ [Granting Function Access to Other Accounts](#permissions-resource-xaccountinvoke)
-+ [Granting Layer Access to Other Accounts](#permissions-resource-xaccountlayer)
-+ [Cleaning Up Resource\-Based Policies](#permissions-resource-cleanup)
++ [Granting function access to AWS services](#permissions-resource-serviceinvoke)
++ [Granting function access to other accounts](#permissions-resource-xaccountinvoke)
++ [Granting layer access to other accounts](#permissions-resource-xaccountlayer)
++ [Cleaning up resource\-based policies](#permissions-resource-cleanup)
 
-## Granting Function Access to AWS Services<a name="permissions-resource-serviceinvoke"></a>
+## Granting function access to AWS services<a name="permissions-resource-serviceinvoke"></a>
 
 When you [use an AWS service to invoke your function](lambda-services.md), you grant permission in a statement on a resource\-based policy\. You can apply the statement to the function, or limit it to a single version or alias\.
 
@@ -57,7 +57,7 @@ $ aws lambda add-permission --function-name my-function --action lambda:InvokeFu
 --principal s3.amazonaws.com --source-arn arn:aws:s3:::my-bucket-123456 --source-account 123456789012
 ```
 
-## Granting Function Access to Other Accounts<a name="permissions-resource-xaccountinvoke"></a>
+## Granting function access to other accounts<a name="permissions-resource-xaccountinvoke"></a>
 
 To grant permissions to another AWS account, specify the account ID as the `principal`\. The following example grants account `210987654321` permission to invoke `my-function` with the `prod` alias\.
 
@@ -85,7 +85,7 @@ You can then update the alias to point to new versions as needed\. When you upda
 
 You can grant cross\-account access for most API actions that [operate on an existing function](lambda-api-permissions-ref.md#permissions-resources-function)\. For example, you could grant access to `lambda:ListAliases` to let an account get a list of aliases, or `lambda:GetFunction` to let them download your function code\. Add each permission separately, or use `lambda:*` to grant access to all actions for the specified function\.
 
-**Cross\-Account APIs**
+**Cross\-account APIs**
 + [Invoke](API_Invoke.md)
 + [GetFunction](API_GetFunction.md)
 + [GetFunctionConfiguration](API_GetFunctionConfiguration.md)
@@ -107,7 +107,7 @@ You can grant cross\-account access for most API actions that [operate on an exi
 
 To grant other accounts permission for multiple functions, or for actions that don't operate on a function, use [roles](access-control-identity-based.md)\.
 
-## Granting Layer Access to Other Accounts<a name="permissions-resource-xaccountlayer"></a>
+## Granting layer access to other accounts<a name="permissions-resource-xaccountlayer"></a>
 
 To grant layer\-usage permission to another account, add a statement to the layer version's permissions policy with the `add-layer-version-permission` command\. In each statement, you can grant permission to a single account, all accounts, or an organization\.
 
@@ -130,7 +130,7 @@ b0cd9796-d4eb-4564-939f-de7fe0b42236    {"Sid":"engineering-org","Effect":"Allow
 
 To grant permission to all AWS accounts, use `*` for the principal, and omit the organization ID\. For multiple accounts or organizations, add multiple statements\.
 
-## Cleaning Up Resource\-Based Policies<a name="permissions-resource-cleanup"></a>
+## Cleaning up resource\-based policies<a name="permissions-resource-cleanup"></a>
 
 To view a function's resource\-based policy, use the `get-policy` command\.
 

doc_source/applications-console.md

@@ -1,4 +1,4 @@
-# Managing Applications in the AWS Lambda Console<a name="applications-console"></a>
+# Managing applications in the AWS Lambda console<a name="applications-console"></a>
 
 The AWS Lambda console helps you monitor and manage your [Lambda applications](deploying-lambda-apps.md)\. The **Applications** menu lists AWS CloudFormation stacks with Lambda functions\. The menu includes stacks that you launch in AWS CloudFormation by using the AWS CloudFormation console, the AWS Serverless Application Repository, the AWS CLI, or the AWS SAM CLI\.
 
@@ -13,7 +13,7 @@ The overview shows the following information about your application\.
 + **AWS CloudFormation template** or **SAM template** – The template that defines your application\.
 + **Resources** – The AWS resources that are defined in your application's template\. To manage your application's Lambda functions, choose a function name from the list\.
 
-## Monitoring Applications<a name="applications-console-monitoring"></a>
+## Monitoring applications<a name="applications-console-monitoring"></a>
 
 The **Monitoring** tab shows an Amazon CloudWatch dashboard with aggregate metrics for the resources in your application\.
 
@@ -25,11 +25,11 @@ The **Monitoring** tab shows an Amazon CloudWatch dashboard with aggregate metri
 
 By default, the Lambda console shows a basic dashboard\. You can customize this page by defining custom dashboards in your application template\. When your template includes one or more dashboards, the page shows your dashboards instead of the default dashboard\. You can switch between dashboards with the drop\-down menu on the top right of the page\.
 
-## Custom Monitoring Dashboards<a name="applications-console-dashboards"></a>
+## Custom monitoring dashboards<a name="applications-console-dashboards"></a>
 
 Customize your application monitoring page by adding one or more Amazon CloudWatch dashboards to your application template with the [AWS::CloudWatch::Dashboard](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-dashboard.html) resource type\. The following example creates a dashboard with a single widget that graphs the number of invocations of a function named `my-function`\.
 
-**Example Function Dashboard Template**  
+**Example Function dashboard template**  
 
 ```
 Resources:
@@ -88,4 +88,4 @@ You can get the definition for any of the widgets in the default monitoring dash
 
 1. Choose **Source**\.
 
-For more information about authoring CloudWatch dashboards and widgets, see [Dashboard Body Structure and Syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html) in the *Amazon CloudWatch API Reference*\.
+For more information about authoring CloudWatch dashboards and widgets, see [Dashboard body structure and syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html) in the *Amazon CloudWatch API Reference*\.