THE AWS CERTIFIED DEVELOPER – ASSOCIATE EXAM TOPICS COVERED IN THIS CHAPTER MAY INCLUDE, BUT ARE NOT LIMITED TO, THE FOLLOWING:

• Domain 1: Deployment
•  1.4 Deploy serverless applications.
• Domain 2: Security
•  2.1 Make authenticated calls to AWS Services.
•  2.3 Implement application authentication and authorization.
• Domain 3: Development with AWS Services
•  3.1 Write code for serverless applications.
•  3.2 Translate functional requirements into application design.
•  3.3 Implement application design into application code.
•  3.3 Write code that interacts with AWS Services by using APIs, SDKs, and AWS CLI.
• Domain 5: Monitoring and Troubleshooting
•  5.1 Write code that you can monitor.

Introduction to Serverless Applications

In the previous chapter, you learned about AWS Lambda and how you can write functions that run in a serverless manner. A serverless application is typically a combination of AWS Lambda and other Amazon services. You build serverless applications to allow developers to focus on their core product instead of the need to manage and operate servers or runtimes in the cloud or on-premises. This reduces overhead and lets developers reclaim time and energy that can be better spent developing reliable, scalable products and new features for applications.

Serverless applications have the following three main benefits:

• No server management
• Flexible scaling
• Automated high availability

Without server management, you no longer have to provision or maintain servers. With AWS Lambda, you upload your code, run it, and focus on your application updates.

With flexible scaling, you no longer have to disable Amazon Elastic Compute Cloud (Amazon EC2) instances to scale them vertically, groups do not need to be auto-scaled, and you do not need to create Amazon CloudWatch alarms to add them to load balancers. With AWS Lambda, you adjust the units of consumption (memory and execution time) and AWS adjusts the rest of the instance appropriately.

Finally, serverless applications have built-in availability and fault tolerance. You do not need to architect for these capabilities, as the services that run the application provide them by default. Additionally, when periods of low traffic occur in the web application, you do not spend money on Amazon EC2 instances that do not run at their full capacity.

Web Server with Amazon Simple Storage Service (Presentation Tier)

Amazon Simple Storage Service (Amazon S3) can store HTML, CSS, images, and JavaScript files within an Amazon S3 bucket, and can host the website like a traditional web server. Though Amazon S3 hosts static websites, today many websites are dynamic applications, where you can use JavaScript to create HTTP requests. These HTTP requests are sent to a Representational State Transfer (REST) endpoint service called Amazon API Gateway, which allows the application to save and retrieve data dynamically.

Amazon API Gateway opens up a variety of application tier possibilities. An internet-accessible HTTPS API can be consumed by any client capable of HTTPS communication. Some common presentation tier examples that you could use for your application’s include the following:

Mobile app Not only can you integrate with custom business logic via Amazon API Gateway and AWS Lambda, you can use Amazon Cognito to create and manage user identities.

Static website content hosted in Amazon S3 You can enable your Amazon API Gateway APIs to be cross-origin resource sharing–compliant. This allows web browsers to invoke your APIs directly from within the static web pages.

Any other HTTPS-enabled client device Many devices can connect and communicate via HTTPS. There is nothing unique or proprietary about how clients communicate with the APIs that you create with the Amazon API Gateway service; it is pure HTTPS. No specific client software or licenses are required.

Additionally, there are several JavaScript frameworks that are widely available today, such as Angular and React, which allow you to benefit from a Model-View-Controller (MVC) architecture.

aws S3 website s3://examplebucket/ --index-document index.html --error-document error.html

aws s3api put-bucket-acl --bucket examplebucket --grant-write  'URI="http://acs.amazonaws.com.cn/groups/s3/LogDelivery"' --grant-read-acp 'URI="http://acs.amazonaws.com.cn/groups/s3/LogDelivery"'

 
aws s3api put-bucket-logging --bucket examplebucket --bucket-logging-status file://logging.json

{
  "LoggingEnabled": {
    "TargetBucket": "examplebucket",
    "TargetPrefix": "examplebucket/",
    "TargetGrants": [
      {
        "Grantee": {
          "Type": "AmazonCustomerByEmail",
          "EmailAddress": "[email protected]"

        },
        "Permission": "FULL_CONTROL"
      },
      {
        "Grantee": {
          "Type": "Group",
          "URI": "http://acs.amazonaws.com/groups/global/AllUsers"

        },
        "Permission": "READ"
      }
    ]
  }
}

Speeding Up Content Delivery with Amazon CloudFront

Latency is an increasingly important aspect when you deliver web applications to the end user, as you always want your end user to have an efficient, low-latency experience on your website. Increased latency can result in both decreased customer satisfaction and decreased sales. One way to decrease latency is to use Amazon CloudFront to move your content closer to your end users. Amazon CloudFront has two delivery methods to deliver content. The first is a web distribution, and this is for storing of .html, .css, and graphic files. Amazon CloudFront also provides the ability to have an RTMP distribution, which speeds up distribution of your streaming media files using Adoble Flash Media Server’s RTMP protocol. An RTMP distribution allows an end user to begin playing a media file before the file has finished downloading from a CloudFront edge location.

To use Amazon CloudFront with your Amazon S3 static website, perform these tasks:

1. Choose a delivery method.

   In the example, Amazon S3 is used to store a static web page; thus, you will be using the Web delivery method. However, as mentioned previously, you could also use RTMP for streaming media files.

2. Specify the cache behavior. A cache behavior lets you configure a variety of CloudFront functionality for a given URL path pattern for files on your website.
3. Choose the distribution settings and network that you want to use. For example, you can use all edge locations or only U.S., Canada, and Europe locations.

Amazon CloudFront enables you to cache your data to minimize redundant data-retrieval operations. Amazon CloudFront reduces the number of requests to which your origin server must respond directly. This reduces the load on your origin server and reduces latency because more objects are served from Amazon CloudFront edge locations, which are closer to your users.

The Amazon S3 bucket pushes the first request to Amazon CloudFront’s cache. The second, third, and n^th requests pull from the Amazon CloudFront’s cache at a lower latency and cost, as shown in Figure 13.1.

The more requests that Amazon CloudFront is able to serve from edge caches as a proportion of all requests (that is, the greater the cache hit ratio), the fewer viewer requests that Amazon CloudFront needs to forward to your origin to get the latest version or a unique version of an object. You can view the percentage of viewer requests that are hits, misses, and errors in the Amazon CloudFront console.

A number of factors affect the cache hit ratio. You can adjust your Amazon CloudFront distribution configuration to improve the cache hit ratio.

Use Amazon CloudFront with Amazon S3 to improve your performance, decrease your application’s latency and costs, and provide a better user experience. Amazon CloudFront is also a serverless service, and it fits well with serverless stack services, especially when you use it in conjunction with Amazon S3.

Dynamic Data with Amazon API Gateway (Logic or App Tier)

This section details how to use dynamic data with the Amazon API Gateway service in a logic tier or app tier.

Amazon API Gateway is a fully managed, serverless AWS service, with no server that runs inside your environment to define, deploy, monitor, maintain, and secure APIs at any scale. Clients integrate with the APIs that use standard HTTPS requests. Amazon API Gateway can integrate with a service-oriented multitier architecture with Amazon services, such as AWS Lambda and Amazon EC2. It also has specific features and qualities that make it a powerful edge for your logic tier. You can use these features and qualities to enhance and build your dynamic web application.

The Amazon API Gateway integration strategy that provides access to your code includes the following:

Control service Uses REST to provide access to Amazon services, such as AWS Lambda, Amazon Kinesis, Amazon S3, and Amazon DynamoDB. The access methods include the following:

• Consoles
• CLI
• SDKs
• REST API requests and responses

Execution service Uses standard HTTP protocols or language-specific SDKs to deploy API access to backend functionality.

{api-id}.execute-api.{region}.amazonaws.com

{api-id}.execute-api.region.amazonaws.com/menu

[
 {
     "id": 1,
     "menu-item": "cheese pizza",
     "price": "14.99"
 },
 {
     "id": 2,
     "menu-item": "pepperoni pizza",
     "price": "17.99"
 }
]

Monitoring Amazon API Gateway with Amazon CloudWatch

Amazon API Gateway also integrates with Amazon CloudWatch. Amazon CloudWatch provides preconfigured metrics to help you monitor your APIs and build both dashboards and alarms. At the time of this writing, there are nine metrics available by default with Amazon CloudWatch, as shown in Table 13.1.

Metric	Description
4XXError	The number of client-side errors captured in a specified period. The Sum statistic represents this metric, namely, the total count of the 4XXError errors in the given period. The Average statistic represents the 4XXError error rate, namely, the total count of the 4XXError errors divided by the total number of requests during the period. The denominator corresponds to the Count metric. Unit: Count
5XXError	The number of server-side errors captured in a given period. The Sum statistic represents this metric, namely, the total count of the 5XXError errors in the given period. The Average statistic represents the 5XXError error rate, namely, the total count of the 5XXError errors divided by the total number of requests during the period. The denominator corresponds to the Count metric. Unit: Count
CacheHitCount	The number of requests served from the API cache in a given period. The Sum statistic represents this metric, namely, the total count of the cache hits in the specified period. The Average statistic represents the cache hit rate, namely, the total count of the cache hits divided by the total number of requests during the period. The denominator corresponds to the Count metric. Unit: Count
CacheMissCount	The number of requests served from the backend in a given period, when API caching is enabled. The Sum statistic represents this metric, namely, the total count of the cache misses in the specified period. The Average statistic represents the cache miss rate, namely, the total count of the cache hits divided by the total number of requests during the period. The denominator corresponds to the Count metric. Unit: Count
Count	The total number API requests in a given period. The SampleCount statistic represents this metric. Unit: Count
IntegrationLatency	The time between when Amazon API Gateway relays a request to the backend and when it receives a response from the backend. Unit: Millisecond
Latency	The time between when Amazon API Gateway receives a request from a client and when it returns a response to the client. The latency includes the integration latency and other Amazon API Gateway overhead. Unit: Millisecond

See Figure 13.2 for a sample dashboard.

If you use Amazon CloudWatch with Amazon API Gateway, you can monitor your application from an API standpoint to see whether any issues occur as the application is being used. Particularly, you can view metrics such as CacheMissCount and Latency.

User Authentication with Amazon Cognito

A crucial aspect of building web applications is user authentication. Nearly every web application today has a user authentication system. From banking websites to social media websites, user authentication is a critical component to secure your web and mobile applications. Amazon Cognito allows for simple and secure user sign-up, sign-in, and access control mechanisms designed to handle web application authentication.

Amazon Cognito includes the following features:

• Amazon Cognito user pools, which are secure and scalable user directories
• Amazon Cognito identity pools (federated identities), which offer social and enterprise identity federation
• Standards-based Web Identity Federation Authentication through Open Authorization (OAuth) 2.0, Security Assertion Markup Language (SAML) 2.0, and OpenID Connect (OIDC) support
• Multi-factor authentication
• Encryption for data at rest and data in transit
• Access control with AWS Identity and Access Management (IAM) integration
• Easy application integration (prebuilt user interface)
• iOS Object C, Android, iOS Swift, and JavaScript
• Adherence to compliance requirements such as Payment Card Industry Data Security Standard (PCI DSS)

Device Tracking and Remembering

If you enable multi-factor authentication, this increases the security of an application to require a second authentication challenge from the user. However, this does require a new two-factor sign-in after a prolonged absence of activity, even when the user device has not been signed out or shut off.

With device tracking and remembering, you can save that user’s device and remember it so that they do not have to provide a token again, as the application has already seen this specific device. Figure 13.3 shows how to enable this feature.

The specifics of the configuration terminology include the following:

Tracked A tracked device is assigned a set of device credentials and consists of a key and secret key pair. You can view all tracked devices for a specific user on the Users screen of the Amazon Cognito console. In addition, you can view the devices metadata (whether it is remembered, the time it began being tracked, the last authenticated time, and such) and the devices usage.

Remembered A remembered device is also tracked. During user authentication, the key and secret pair assigned to a remembered device authenticates the device to verify that it is the same device that the user previously used to sign in to the application. You can view remembered devices in the Amazon Cognito console.

Not remembered A not-remembered device, while still tracked, is treated as if it was never used during the user authentication flow. The device credentials are not used to authenticate the device. The new APIs in the AWS Mobile SDK do not expose these devices, but you can see them in the Amazon Cognito console.

The first configuration setting reads “Do you want to remember devices?” and has the following options:

No (the default) Devices are neither remembered nor tracked.

Always Every device used with your application is remembered.

User opt-in The user’s device is remembered only if that user opts to remember the device. This enables your users to decide whether your application should remember the devices they use to sign in, though all devices are tracked regardless of which setting they choose. This is a useful option when you require a higher security level, but the user may sign in from a shared device. For example, if a user signs in to a banking application from a public computer at a library, the user requires the option to decide whether their device is to be remembered.

The second configuration option is “Do you want to use a remembered device to suppress the second factor during multi-factor authentication (MFA)?” It appears when you select either Always or User Opt-In for the first configuration option. The second factor suppression option enables your application to use a remembered device as a second factor of authentication, and it suppresses the SMS-based challenge in the MFA flow. This feature works together with MFA, and it requires MFA to be enabled for the user pool. The device must first be remembered before it can be used to suppress the SMS-based challenge. Upon the initial sign-in with a new device, the user must complete the SMS challenge. Afterward, the user no longer has to complete the SMS challenge.

User Interface Customization

An Amazon Cognito user pool includes a prebuilt user interface (UI) that you can use inside of your application to build a user authentication flow quickly, as shown in Figure 13.4.

You can modify the UI with the AWS Management Console, the AWS CLI, or the API. You can also upload your own custom logo with a maximum file size of 100 KB. The CSS classes you can customize in the prebuilt UI are as follows:

• background-customizable
• banner-customizable
• errorMessage-customizable
• idpButton-customizable
• idpButton-customizable:hover
• inputField-customizable
• inputField-customizable:focus
• label-customizable
• legalText-customizable
• logo-customizable
• submitButton-customizable
• submitButton-customizable:hover
• textDescription-customizable

You can customize the UI and CLI with two commands: get-ui-customization to retrieve the customization settings and set-ui-customization to set the UI customization, as shown in the following example code:

aws cognito-idp get-ui-customization
aws cognito-idp set-ui-customization --user-pool-id <your-user-pool-id> --client-id <your-app-client-id> --image-file <path-to-logo-image-file>  --css ".label-customizable{ color: <color>;}"

aws cognito-idp create-user-pool --pool-name <value>

Standard Three-Tier vs. the Serverless Stack

This chapter has introduced serverless services and their benefits. Now that you know about some of the serverless services that are available in AWS, let’s compare a traditional three-tier application against a serverless application architecture. Figure 13.5 shows a typical three-tier web application.

Source: https://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_web_01.pdf

This architecture uses the following components and services:

• Routing: Amazon Route 53
• Content distribution network (CDN): Amazon CloudFront
• Static data: Amazon S3
• High availability/decoupling: Application load balancers
• Web servers: Amazon EC2 with Auto Scaling
• App servers: Amazon EC2 with Auto Scaling
• Database: Amazon RDS in a multi-AZ configuration

Amazon Route 53 provides a DNS service that allows you to take domain names such as examplecompany.com and translate them to an IP address that points to running servers.

The CDN shown in Figure 13.6 is the Amazon CloudFront service, which improves your site performance with the use of its global content delivery network.

Source: https://aws.amazon.com/getting-started/projects/build-serverless-web-app-lambda-apigateway-s3-dynamodb-cognito/

Amazon S3 stores your static files such as photos or movie files.

Application load balancers are responsible for distributing load across Availability Zones to your Amazon EC2 servers, which run your web application with a service such as Apache or NGINX.

Application servers are responsible for performing business logic prior to storing the data in your database servers that are run by Amazon RDS.

Amazon RDS is the managed database server, and it can run an Amazon Aurora, Microsoft SQL Server, Oracle SQL Server, MySQL, PostgreSQL, or MariaDB database server.

While this architecture is a robust and highly available service, there are several downsides, including the fact that you have to manage servers. You are responsible for patching those servers, preventing downtime associated with those patches, and proper server scaling.

In a typical serverless web application architecture, you also run a web application, but you have zero servers that run inside your AWS account, as shown in Figure 13.6.

Serverless web application architecture services include the following:

• Routing: Amazon Route 53
• Web servers/static data: Amazon S3
• User authentication: Amazon Cognito user pools
• App servers: Amazon API Gateway and AWS Lambda
• Database: Amazon DynamoDB

Amazon Route 53 is your DNS, and you can use Amazon CloudFront for your CDN.

You can also use Amazon S3 for your web servers. In this architecture, you use Amazon S3 to host your entire static website. You use JavaScript to make API calls to the Amazon API Gateway service.

For your business or application servers, you use Amazon API Gateway in conjunction with AWS Lambda. This allows you to retrieve and save data dynamically.

You use Amazon DynamoDB as a serverless database service, and you do not provision any Amazon EC2s inside of your Amazon VPC account. Amazon DynamoDB is also a great database service for storing session state for stateful applications. You can use Amazon RDS instead if you need a relational database. However, it would not then be a fully serverless stack. There is a new service released called Amazon Aurora Serverless, which is a full RDS MySQL 5.6–compatible service that is completely serverless. This would allow you to run a traditional SQL database, but one that has the benefit of being serverless. Amazon Aurora Serverless is discussed in the next section.

You use Amazon Cognito user pools for user authentication, which provides a secure user directory that can scale to hundreds of millions of users. Amazon Cognito User Pools is a fully managed service with no servers for you to manage. While user authentication was not shown in Figure 13.6, you can use your web server tier to talk to a user directory, such as Lightweight Directory Access Protocol (LDAP), for user authentication.

As you can see, while some of the components are the same, you may use them in slightly different ways. By taking advantage of the AWS global network, you can develop fully scalable, highly available web applications—all without having to worry about maintaining or patching servers.

Amazon Aurora Serverless

Amazon Aurora Serverless is an on-demand, auto-scaling configuration for the Aurora MySQL-compatible edition, where the database automatically starts, shuts down, and scales up or down as needed by your application. This allows you to run a traditional SQL database in the cloud without needing to manage any infrastructure or instances.

With Amazon Aurora Serverless, you also get the same high availability as traditional Amazon Aurora, which means that you get six-way replication across three Availability Zones inside of a region in order to prevent against data loss.

Amazon Aurora Serverless is great for infrequently used applications, new applications, variable workloads, unpredictable workloads, development and test databases, and multitenant applications. This is because you can scale automatically when you need to and scale down when application demand is not high. This can help cut costs and save you the heartache of managing your own database infrastructure.

Amazon Aurora Serverless is easy to set up, either through the console or directly with the CLI. To create an Amazon Aurora Serverless cluster with the CLI, you can run the following command:

aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora --engine-version 5.6.10a 
--engine-mode serverless --scaling-configuration  MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true 
--master-username user-name --master-user-password password 
--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2  –region us-east-1

Amazon Aurora Serverless gives you many of the similar benefits as other serverless technologies, such as AWS Lambda, but from a database perspective. Managing databases is hard work, and with Amazon Aurora Serverless, you can utilize a database that automatically scales and you don’t have to manage any of the underlying infrastructure.

AWS Serverless Application Model

The AWS Serverless Application Model (AWS SAM) allows you to create and manage resources in your serverless application with AWS CloudFormation to define your serverless application infrastructure as a SAM template. A SAM template is a JSON or YAML configuration file that describes the AWS Lambda functions, API endpoints, tables, and other resources in your application. With simple commands, you upload this template to AWS CloudFormation, which creates the individual resources and groups them into an AWS CloudFormation stack for ease of management. When you update your AWS SAM template, you re-deploy the changes to this stack. AWS CloudFormation updates the individual resources for you.

AWS SAM is an extension of AWS CloudFormation. You can define resources by using the AWS CloudFormation in your AWS SAM template. This is a powerful feature, as you can use AWS SAM to create a template of your serverless infrastructure, which you can then build into a DevOps pipeline. For example, examine the following:

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: 'Example of Multiple-Origin CORS using API Gateway and Lambda'
Resources:
  ExampleRoot:
    Type: 'AWS::Serverless::Function'
    Properties:
      CodeUri: '.'
      Handler: 'routes/root.handler'
      Runtime: 'nodejs8.10'
      Events:
        Get:
          Type: 'Api'
          Properties:
            Path: '/'
            Method: 'get'
  ExampleTest:
    Type: 'AWS::Serverless::Function'
    Properties:
      CodeUri: '.'
      Handler: 'routes/test.handler'
      Runtime: 'nodejs8.10'
      Events:
        Delete:
          Type: 'Api'
          Properties:
            Path: '/test'
            Method: 'delete'
        Options:
          Type: 'Api'
          Properties:
            Path: '/test'
            Method: 'options'
 
Outputs:
    ExampleApi:
      Description: "API Gateway endpoint URL for Prod stage for API Gateway Multi-Origin CORS Function"
      Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region} .amazonaws.com/Prod/"
    ExampleRoot:
      Description: "API Gateway Multi-Origin CORS Lambda Function (Root) ARN"
      Value: !GetAtt ExampleRoot.Arn
    ExampleRootIamRole:
      Description: "Implicit IAM Role created for API Gateway Multi-Origin CORS Function (Root)"
      Value: !GetAtt ExampleRootRole.Arn
    ExampleTest:
      Description: "API Gateway Multi-Origin CORS Lambda Function (Test) ARN"
      Value: !GetAtt ExampleTest.Arn
    ExampleTestIamRole:
      Description: "Implicit IAM Role created for API Gateway Multi-Origin CORS Function (Test)"
      Value: !GetAtt ExampleTestRole.Arn

In the previous code example, you create two AWS Lambda functions and then associate three different Amazon API Gateway endpoints to trigger those functions. To deploy this AWS SAM template, download the template and all of the necessary dependencies from here:

https://github.com/awslabs/serverless-application-model/tree/develop/examples/apps/api-gateway-multiple-origin-cors

AWS SAM is similar to AWS CloudFormation, with a few key differences, as shown in the second line:

Transform: 'AWS::Serverless-2016-10-31'

This important line of code transforms the AWS SAM template into an AWS CloudFormation template. Without it, the AWS SAM template will not work.

Similar to the AWS CloudFormation, you also have a Resources property where you define infrastructure to provision. The difference is that you provision serverless services with a new Type called AWS::Serverless::Function. This provisions an AWS Lambda function to define all properties from an AWS Lambda point of view. AWS Lambda includes Properties, such as MemorySize, Timeout, Role, Runtime, Handler, and others.

While you can create an AWS Lambda function with AWS CloudFormation using AWS::Lambda::Function, the benefit of AWS SAM lies in a property called Event, where you can tie in a trigger to an AWS Lambda function, all from within the AWS::Serverless::Function resource. This Event property makes it simple to provision an AWS Lambda function and configure it with an Amazon API Gateway trigger. If you use AWS CloudFormation, you would have to declare an Amazon API Gateway separately with AWS::ApiGateway::Resource.

To summarize, AWS SAM allows you to provision serverless resources more rapidly with less code by extending AWS CloudFormation.

AWS SAM CLI

Now that we’ve addressed AWS SAM, let’s take a closer look at the AWS SAM CLI. With AWS SAM, you can define templates, in JSON or YAML, which are designed for provisioning serverless applications through AWS CloudFormation.

AWS SAM CLI is a command line interface tool that creates an environment in which you can develop, test, and analyze your serverless-based application, all locally. This allows you to test your AWS Lambda functions before uploading them to the AWS service. AWS SAM CLI also allows you to develop and test your code quickly, and this gives you the ability to test it locally, which allows you to develop it faster. Previously, you would have had to upload your code each time you wanted to test an AWS Lambda function. Now, with the AWS SAM CLI, you can develop faster and get your application out the door more quickly.

To use AWS SAM CLI, you must meet a few prerequisites. You must install Docker, have Python 2.7 or 3.6 installed, have pip installed, install the AWS CLI, and finally install the AWS SAM CLI. You can read more about how to install AWS SAM CLI at https://github.com/awslabs/aws-sam-cli.

With AWS SAM CLI, you must define three key things.

• You must have a valid AWS SAM template, which defines a serverless application.
• You must have the AWS Lambda function defined. This can be in any valid language that Lambda currently supports, such as Node.js, Java 8, Python, and so on.
• You must have an event source. An event source is simply an event.json file that contains all the data that the Lambda function expects to receive. Valid event sources are as follows:
  • Amazon Alexa
  • Amazon API Gateway
  • AWS Batch
  • AWS CloudFormation
  • Amazon CloudFront
  • AWS CodeCommit
  • AWS CodePipeline
  • Amazon Cognito
  • AWS Config
  • Amazon DynamoDB
  • Amazon Kinesis
  • Amazon Lex
  • Amazon Rekognition
  • Amazon Simple Storage Service (Amazon S3)
  • Amazon Simple Email Service (Amazon SES)
  • Amazon Simple Notification Service (Amazon SNS)
  • Amazon Simple Queue Service (Amazon SQS)
  • AWS Step Functions

To generate this JSON event source, you can simply run this command in the AWS SAM CLI:

sam local generate-event <service> <event>

AWS SAM CLI is a great tool that allows developers to iterate quickly on their serverless applications. You will learn how to create and test an AWS Lambda function locally in the “Exercises” section of this chapter.

AWS Serverless Application Repository

The AWS Serverless Application Repository enables you to deploy code samples, components, and complete applications quickly for common use cases, such as web and mobile backends, event and data processing, logging, monitoring, Internet of Things (IoT), and more. Each application is packaged with an AWS SAM template that defines the AWS resources. Publicly shared applications also include a link to the application’s source code. There is no additional charge to use the serverless application repository. You pay only for the AWS resources you use in the applications you deploy.

You can also use the serverless application repository to publish your own applications and share them within your team, across your organization, or with the community at large. This allows you to see what other people and organizations are developing.

Serverless Application Use Cases

Case studies on running serverless applications are located at the following URLs:

• The Coca-Cola Company:
• https://aws.amazon.com/blogs/aws/things-go-better-with-step-functions/
• FINRA:
• https://aws.amazon.com/solutions/case-studies/finra-data-validation/
• iRobot:
• https://aws.amazon.com/solutions/case-studies/irobot/
• Localytics:
• https://aws.amazon.com/solutions/case-studies/localytics/

Summary

This chapter covered the AWS serverless core services, how to store your static files inside of Amazon S3, how to use Amazon CloudFront in conjunction with Amazon S3, how to integrate your application with user authentication flows using Amazon Cognito, and how to deploy and scale your API quickly and automatically with Amazon API Gateway.

Serverless applications have three main benefits: no server management, flexible scaling, and automated high availability. Without server management, you no longer have to provision or maintain servers. With AWS Lambda, you upload your code, run it, and focus on your application updates. With flexible scaling, you no longer have to disable Amazon EC2 instances to scale them vertically, groups do not need to be auto-scaled, and you do not need to create Amazon CloudWatch alarms to add them to load balancers. With AWS Lambda, you adjust the units of consumption (memory and execution time), and AWS adjusts the rest of the instance appropriately. Finally, serverless applications have built-in availability and fault tolerance. When periods of low traffic occur, you do not spend money on Amazon EC2 instances that do not run at their full capacity.

You can use an Amazon S3 web server to create your presentation tier. Within an Amazon S3 bucket, you can store HTML, CSS, and JavaScript files. JavaScript can create HTTP requests. These HTTP requests are sent to a REST endpoint service called Amazon API Gateway, which allows the application to save and retrieve data dynamically by triggering a Lambda function.

After you create your Amazon S3 bucket, you configure it to use static website hosting in the AWS Management Console and enter an endpoint that reflects your AWS Region.

Amazon S3 allows you to configure web traffic logs to capture information, such as the number of visitors who access your website in the Amazon S3 bucket.

One way to decrease latency and improve your performance is to use Amazon CloudFront with Amazon S3 to move your content closer to your end users. Amazon CloudFront is a serverless service.

The Amazon API Gateway is a fully managed service designed to define, deploy, and maintain APIs. Clients integrate with the APIs using standard HTTPS requests. Amazon API Gateway can integrate with a service-oriented multitier architecture. The Amazon API Gateway provides dynamic data in the logic or app tier.

There are three types of endpoints for Amazon API Gateway: regional endpoints, edge-optimized endpoints, and private endpoints.

In the Amazon API Gateway service, you expose addressable resources as a tree of API Resources entities, with the root resource (/) at the top of the hierarchy. The root resource is relative to the API’s base URL, which consists of the API endpoint and a stage name.

You use Amazon API Gateways to help drive down the total response-time latency of your API. Amazon API Gateway uses the HTTP protocol to process these HTTP methods and send/receive data to and from the backend. Serverless data is sent to AWS Lambda to process.

You can use Amazon Route 53 to create a more user-friendly domain name instead of using the default host name (Amazon S3 endpoint). To support two subdomains, you create two Amazon S3 buckets that match your domain name and subdomain.

A stage is a named reference to a deployment, which is a snapshot of the API. Use a stage to manage and optimize a particular deployment. You create stages for each of your environments such as DEV, TEST, and PROD, so you can develop and update your API and applications without affecting production. Use Amazon API Gateway to set up authorizers with Amazon Cognito user pools on an AWS Lambda function. This enables you to secure your APIs.

An Amazon Cognito user pool includes a prebuilt user interface (UI) that you can use inside your application to build a user authentication flow quickly. A user pool is a user directory in Amazon Cognito. With a user pool, your users can sign in to your web or mobile app through Amazon Cognito. Users can also sign in through social identity providers such as Facebook or Amazon and through Security Assertion Markup Language (SAML) identity providers.

Amazon Cognito identity pools allow you to create unique identities and assign permissions for your users to help you integrate with authentication providers. With the combination of user pools and identity pools, you can create a serverless user authentication system.

You can choose how users sign in with a username, an email address, and/or a phone number and to select attributes. Attributes are properties that you want to store about your end users. You can also configure password policies. Multi-factor authentication (MFA) prevents anyone from signing in to a system without authenticating through two different sources, such as a password and a mobile device–generated token. You create an Amazon Cognito role to send Short Message Service (SMS) messages to users.

The AWS Serverless Application Model (AWS SAM) allows you to create and manage resources in your serverless application with AWS CloudFormation as a SAM template. A SAM template is a JSON or YAML file that describes the AWS Lambda function, API endpoints, and other resources. You upload the template to AWS CloudFormation to create a stack. When you update your AWS SAM template, you redeploy the changes to this stack, and AWS CloudFormation updates the resources. You can use AWS SAM to create a template of your serverless infrastructure, which you can then build into a DevOps pipeline.

The Transform: 'AWS::Serverless-2016-10-31' code converts the AWS SAM template into an AWS CloudFormation template.

The AWS Serverless Application Repository enables you to deploy code samples, components, and complete applications for common use cases. Each application is packaged with an AWS SAM template that defines the AWS resources.

Additionally, you learned the differences between the standard three-tier web applications and the AWS serverless stack. You learned how to build your infrastructure quickly with AWS SAM and AWS SAM CLI for testing and development purposes.

Exam Essentials

Know serverless applications’ three main benefits. The benefits are as follows:

• No server management
• Flexible scaling
• Automated high availability

Know what no server management means. Without server management, you no longer have to provision or maintain servers. With AWS Lambda, you upload your code, run it, and focus on your application updates.

Know what flexible scaling means. With flexible scaling, you no longer have to disable Amazon Elastic Compute Cloud (Amazon EC2) instances to scale them vertically, groups do not need to be auto-scaled, and you do not need to create Amazon CloudWatch alarms to add them to load balancers. With AWS Lambda, you adjust the units of consumption (memory and execution time), and AWS adjusts the rest of the instances appropriately.

Know what serverless applications mean. Serverless applications have built-in availability and fault tolerance. You do not need to architect for these capabilities, as the services that run the application provide them by default. Additionally, when periods of low traffic occur on the web application, you do not spend money on Amazon EC2 instances that do not run at their full capacity.

Know what services are serverless. On the exam, it is important to understand which Amazon services are serverless and which ones are not. The following services are serverless:

• Amazon API Gateway
• AWS Lambda
• Amazon SQS
• Amazon SNS
• Amazon Kinesis
• Amazon Cognito
• Amazon Aurora Serverless
• Amazon S3

Know how to host a serverless web application. Hosting a serverless application means that you need Amazon S3 to host your static website, which comprises your HTML, JavaScript, and CSS files. For your database infrastructure, you can use Amazon DynamoDB or Amazon Aurora Serverless. For your business logic tier, you can use AWS Lambda. For DNS services, you can utilize Amazon Route 53. If you need the ability to host an API, you can use Amazon API Gateway. Finally, if you need to decrease latency to portions of your application, you can utilize services like Amazon CloudFront, which allows you to host your content at the edge.

Resources to Review

• Serverless Computing and Applications:
• https://aws.amazon.com/serverless/
• Amazon S3 Website Endpoints:
• https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_website_region_endpoints
• Amazon Cognito FAQs:
• https://aws.amazon.com/cognito/faqs/
• Amazon API Gateway FAQ:
• https://aws.amazon.com/api-gateway/faqs/
• AWS Well-Architected Framework—Serverless Applications Lens:
• https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf
• Serverless Architectures with AWS Lambda:
• https://d1.awsstatic.com/whitepapers/serverless-architectures-with-aws-lambda.pdf
• AWS Serverless Multi-Tier Architectures (Amazon API Gateway and AWS Lambda):
• https://d1.awsstatic.com/whitepapers/AWS_Serverless_Multi-Tier_Architectures.pdf
• Serverless Streaming Architectures and Best Practices:
• https://d1.awsstatic.com/whitepapers/Serverless_Streaming_Architecture_Best_Practices.pdf
• Optimizing Enterprise Economics with Serverless Architectures:
• https://d1.awsstatic.com/whitepapers/optimizing-enterprise-economics-serverless-architectures.pdf
• Common Serverless Architectures discussed at re:Invent 2017 (Video):
• https://www.youtube.com/watch?v=xJcm9V2jagc
• AWS Serverless Application Model (AWS SAM) FAQs:
• https://aws.amazon.com/serverless/sam/faqs/

Exercises

For this “Exercises” section, expand the OpenPets API Template that comes with Amazon API Gateway and build a frontend with HTML and JavaScript. You use AWS Lambda for some compute processing to save data to an Amazon DynamoDB database.