Changing User State Locations

The sticky sessions concept was a predecessor of the concept of single sign-on (SSO), which requires an end user to sign on once and doesn’t require another sign-on. Of course, in case the initial server has issues and is unavailable, it is necessary to find a better location for storing the user state information. There are a number of ways to solve this problem.

One solution is to store user session information on your computer system in your browser cache rather than on the application server. When the end user communicates with the application again, that user sends a session token along with the URL for the application. The load balancer checks the session information; if it is still valid, the end user is sent to any available application server. There might be only two servers, or there might be hundreds of them, but the user session information is not stored on the servers. For this example, the server is not holding on to and maintaining the session state information for the user; it is free from managing this information, and the server is now stateless and just dealing with application requests. If the server were responsible for holding on to and managing the session information, it would be defined as stateful; the server would be responsible for storing and maintaining and updating all states—application, application data, and user session states. The session token would be stored at the client and would have to be presented to the load balancer multiple times to continue the user session in progress.

This is a very simple example of the concept of stateless processing. In this example, no user session information is being retained by the server. However, there is still stateful information being used by the application server, even though its primary purpose as part of the application stack is now defined as stateless; the server is a generic copy, as every application server is built using exactly the same image.

A properly designed application hosted in the cloud uses key AWS services to secure both the user and application states and the application data records:

• The user authentication credentials must be stored in an AWS Identity and Access Management (IAM) database or similar authentication database; the user account information is stateful, which means their credentials remain the same until changed by the end user.

• The application state (of orders and requests, for example) is stored in some sort of messaging queue, such as in Amazon Simple Queue Service (SQS), which is discussed later in this chapter.

• The application data is stored in a database solution, most likely with a primary and standby database design.

If you look at the entire communication process from client to application—for example, ordering something from Amazon.com—you can see that the essential data that is generated is a combination of stateful and stateless data (see Table 4-2). Keep in mind that stateless data is not retained forever but for only a period of time. This period of time could be during an authenticated user session while ordering a product, listening to music online, or playing games online. The Amazon order process involves the following stateful and stateless data:

• Stateful data includes changing user account information, purchases, history, refunds, games played, high scores, music listened to, or music downloaded.

• Stateless data includes user session information, such as information on browsing for products, browsing for games, review account information, or searching for music.

Where does the application stack/system need to store the data? If the data should be stored long term in a database, the data is stateful. The data needs to be stored as a permanent record, and from time to time it will be updated and changed, but it still needs to be persistently stored.

If the data is being used for a short time, or potentially even a longer time but not permanently, the data is defined as stateless; it is useful for a short or longer period of time, but it can be discarded after it has been used (for example, user session information) or processed (for example, items in a shopping cart).

Stateless data sometimes changes format and is retained forever, in which case it becomes stateful. Social media could provide an example here, as every speck of information generated is saved.

User Session Management

There are two common ways to manage AWS user sessions:

• Sticky sessions: When you deploy an application load balancer (ALB), you can enable sticky sessions by opening the attributes of the target group of registered servers that will be served content by the load balancer. The term sticky means that once you start a user session with a particular application server, the session will continue on that application server, and the load balancer will honor that relationship for the life of the user session. The drawback is that if the application server fails, all session information is lost.

• Distributed session management: Another way to address shared data storage for user sessions is to use an in-memory key/value store hosted by ElastiCache and deploy either Redis or Memcached to cache HTTP session state. In-memory data stores are fast and can be used to cache any information, including HTTP session information. For a simple solution with no redundancy, you could choose to employ ElastiCache for Memcached, but this provides no replication support. For a redundant distributed session solution, you could deploy ElastiCache for Redis, which supports replication of the stored information between multiple nodes across multiple availability zones. Figure 4-3 shows the operation of a distributed cache. When the user communicates with the application stack, the session information is stored in an ElastiCache for Redis distributed cache. When Server A fails, the user session can be continued on Server B because the user session information has been stored in ElastiCache instead of in the application server.

For the AWS Certified Solutions Architect - Associate (SAA-C02) exam, you need to understand the concepts of stateful and stateless data storage options well enough to be able to provide advice as an AWS architect to your developers as to what AWS architectural solutions are available for the various types of data that will be stored and retrieved. This chapter looks at the AWS services shown in Figure 4-4 that store both stateless and stateful data.

Amazon SNS

Amazon Simple Notification Service (SNS) enables you to send messages using push notifications from a publisher to a subscriber. An example of a publisher could be any AWS service. A subscriber could be an end user, AWS service, EC2 instance, or Lambda, the serverless service hosted at AWS. SNS can send both individual or bulk messages to a large number of recipients, or subscribers. (Think of push notifications as the messages you get when you install a new application on your smartphone.) SNS allows you to decouple your applications into smaller independent components that relay messages or events to distributed applications, move data between S3 objects stores, or react when changes occur to a DynamoDB table, or Cloud Watch alarms.

SNS is completely integrated with the built-in AWS monitoring service CloudWatch. Every AWS service has a number of CloudWatch metrics, and each metric can be utilized for monitoring many key components of each service. When issues or situations occur that need attention, an alarm can issue numerous SNS notifications. SNS messages are stored across multiple geographically dispersed servers, and the service is designed to be fully scalable and capable of supporting your application communication needs. SNS can send messages from applications to users or from one application to other application services at AWS. SNS can be used as an important building block in designing and deploying hosted application stacks at AWS. Every AWS service can communicate as a publisher sending messages and notifications to SNS topics.

To receive notifications from SNS you or the appropriate service must subscribe to a topic. Each SNS topic has a choice of subscribers, as shown in Figure 4-5, including serverless Lambda functions, queues, microservices, and other delivery streams, such as the following:

• AWS Lambda: Custom functions that can execute any API at AWS

• Amazon SQS: Queues that relay the received messages to subscribed services

• Amazon Kinesis Data Firehose: A service that ingests streaming data into S3, Redshift, or Elasticsearch data stores for further analysis

• HTTP/S endpoints: Endpoints that deliver notifications to a specific URL

• Email: Email subscribers

SNS is commonly used for sending event notifications when AWS service failures occur. However, for the AWS Certified Solutions Architect - Associate (SAA-C02) exam, you need to understand that SNS also allows you to send messages to other distributed services that are part of an application stack hosted at AWS. Event updates and notifications concerning approvals, changes to inventory, or shipment status can be immediately delivered to system components as well as to end users. For example, when you order a product at Amazon.com, many SNS notifications are executed in the background while completing your order. The process works as follows:

Step 1. You order a new set of dishes.

Step 2. A notification is issued to check for stock.

Step 3. After confirmation of inventory, the order is placed against your account.

Step 4. Your credit card information is checked.

Step 5. Taxes and relevant fees are added to the order.

Step 6. Shipping is calculated.

Step 7. An email is sent to your email account, thanking you for the order.

To use SNS, you start by creating a topic that is linked to a specific event type or subject. Subscribers can subscribe to selected topics and receive notifications. When you create an SNS topic, you define policies such as who can publish messages to the topic and what notification protocols are allowed for delivery of the message. Figure 4-6 illustrates the creation of a notification topic.

One of the most common deployment methods involves using Simple Notification Service and Simple Queue Service together. Most applications hosted at AWS are deployed using multiple EC2 instances. AWS best practice dictates that no data should be stored on the EC2 instances, including any application state. Instead, you should store the important information that is being worked on by the application servers in centralized SQS queues, as shown in Figure 4-7.

SNS Cheat Sheet

For the AWS Certified Solutions Architect - Associate (SAA-C02) exam, you need to understand the following critical aspects of SNS:

• SNS provides push-based delivery from AWS.

• SNS supports notifications over HTTP/HTTPS, via email, to SQS queue endpoints, as well as SMS messages.

• SNS is easily integrated with AWS hosted applications.

• SNS message delivery involves multiple transport protocols.

• JSON is the supported data type.

• SNS supports event notifications and application monitoring.

• Every AWS service supports SNS.

• SNS messages are stored redundantly across multiple availability zones.

Amazon SQS

Amazon Simple Queue Service (SQS) is a distributed message queuing service for storing messages in transit between systems and applications. SQS allows you to decouple your application components from their application state so that any application server failure does not result in application data loss (see Figure 4-8). There is no limit to the number of messages that can be held in each SQS queue. For example, say that you start a business that provides the service of converting photographs that are uploaded into multiple resolutions. When a photograph is uploaded, it is placed in four separate queues, named lo-res, hi-res, 4k, and 6k. Tiers of EC2 instances poll their respective queues; when pictures are uploaded, the software hosted on the EC2 instances carries out the changes to the pictures’ resolutions and delivers the finished pictures to the respective S3 buckets.

SQS can be used with the following AWS services:

• DynamoDB: You can use SQS to transfer messages to DynamoDB by using a Lambda function.

• EC2 instances: You can scale an Auto Scaling group up or down when messages in the SQS queue increase.

• ECS: A worker task within a container executes a script that polls for SQS messages and downloads and processes them as necessary.

• RDS: A lightweight daemon connects to an SQS queue and consumes messages into a SQL database.

• S3: Changes to a bucket’s contents enable event notifications to an SQS queue.

• Lambda function: You can connect any custom function to an SQS queue to consume messages.

SQS Cheat Sheet

For the AWS Certified Solutions Architect - Associate (SAA-C02) exam, you need to understand the following critical aspects of SQS:

• SQS uses pull-based, not push-based, polling.

• The visibility timeout is the amount of time a message is unavailable after a message starts to be processed.

• If a message cannot be processed within the visibility timeout period, the message again becomes available in the queue for processing.

• If a job is processed successfully within the visibility timeout period, the message is deleted.

• The maximum visibility timeout period is 12 hours.

• Queues can be either standard or first in, first out (FIFO).

• First-in-first-out (FIFO) preserves the exact order in which messages are sent and received.

• The maximum size of SQS messages is 256 KB.

• IAM can control who reads and writes messages.

• Queues can be encrypted and can use Server-Side Encryption (SSE).

AWS Step Functions

AWS Step Functions is an interesting combination of SQS queues and SNS notifications integrated with application logic. Step Functions allows you to orchestrate numerous Lambda functions and multiple AWS services into a serverless GUI-driven application process. You can create multiple states by creating what a state machine. Each defined state machine workflow has checkpoints that maintain your workflow and its state throughout each of the defined stages. The output of each stage in the workflow is the starting point of the next stage, and the steps execute in the precise order defined by state machine logic. At each stage, decisions are made based on the supplied input parameters, actions are performed, and output is passed to the next stage, as shown in Figure 4-9.

Step functions also have built-in application-level controls, including try/catch and retry and rollback capabilities to help deal with errors and exceptions automatically. The following are examples of functions that are possible with Step Functions:

• Consolidating data from multiple databases into a unified report

• Fulfilling orders or tracking inventory processes

• Implementing a user registration process

• Implementing a custom workflow

The state machine that makes up each step function is defined by two integrated components:

• Activity tasks: These tasks allow you to assign a specific step in your defined workflow to software code running externally. The external function polls the function it is associated with for any required work requests; when required, it performs its work and returns the results. The activity task can run on any application that is able to make an HTTP connection from its location, such as an EC2 instance hosted at AWS, a mobile device, or an on-premises server.

• Service tasks: These tasks allow you to connect steps in your defined workflow to a supported AWS service. In contrast to an activity task, a service task pushes requests to other AWS services; the service performs its action, reports back to the workflow once the action is completed, and moves to the next step. Examples of service tasks include the following:

  • Running an Amazon Elastic Container Service (ECS) or Fargate task hosted in a VPC

  • Submitting an AWS batch job and waiting for completion

  • Retrieving or placing a new item into a Dynamo DB table

The building blocks of Step Functions automate the relationship between SNS (the service tasks) and SQS (the activity tasks). Step Functions integrates SNS and SQS with a logical processing framework. In addition, you can add the SNS notification service to a Step Functions workflow at the end of processing to trigger notifications. For example, when your workflow is successful, you can trigger another service or signal completion. Workflow failure could trigger additional communications back to developers indicating the problem and relevant error messages.

AWS Step Functions state machines are defined using JSON as the declarative language. You can create activity tasks by using any AWS SDK that supports code written in Node.js, Python, Go, or C#. There are two choices for creating workflows:

• Express workflows: You use express workflows for workloads with high event rates of more than 100,000 per second and short durations of less than 5 minutes.

• Standard workflows: Standard workflows are suitable for long-running durable and auditable workflows that may include machine learning models, generating reports, and the processing of credit cards. Standard workflows guarantee one execution of each workflow step with a maximum duration of 1 year; you can also inspect a processing workflow during and after the workflow execution has completed.

Table 4-3 compares the functions and use cases of SNS, SQS, and Step Functions.

API Gateway Cheat Sheet

For the AWS Certified Solutions Architect - Associate (SAA-C02) exam, you need to understand the following critical aspects of APIs:

• With AWS, developers can publish, maintain, and secure APIs at any scale.

• API Gateway can process up to hundreds of thousands of concurrent API calls.

• API Gateway works together with Lambda to create the application-facing serverless infrastructure.

• CloudFront can be used as a public endpoint for API Gateway requests.

• Edge-optimized APIs can be used for clients in different geographic locations. API requests are routed to the nearest edge location.

• Regional API endpoints are designed for clients in the same AWS region.

• Private API endpoints can only be accessed from a VPC using an interface VPC endpoint.

• API Gateway can scale to any traffic level required.

• API Gateway logs track performance metrics for the backend, including API calls, latency, and error rates.

• You pay only when your hosted APIs are called. The API calls that are received are billed based on the amount of data that is transferred out.

• API keys can be created and distributed to developers.

• API requests can be throttled to prevent overloading your backend services.

Step 1: Create a Static Website

The first step in building the serverless web app just described is to create a website that can be hosted in an S3 bucket (see Figure 4-18). Because the website is going to be hosted in an S3 bucket, it can be a simple static website with no dynamic assets. After you configure the S3 bucket for website hosting, all the HTML, Cascading Style Sheets (CSS), images, and web server files are uploaded and stored.

You provide a URL via email using a registered domain owned by the company to each corporate user who wants to sign up for the conference. To host a website, you need to ensure that the S3 bucket has public read access and upload the DNS records on Route 53 by adding alias records that point to the website.

Step 2: Handle User Authentication

You need to create a Cognito user pool for the users who will be registering for the conference (see Figure 4-19). The corporate users will use their corporate email addresses to register themselves as new users on the website. You need to configure Cognito to send a user who registers on the conference website a standard confirmation email that includes a verification code the user then uses to confirm his or her identity.

After the users have successfully signed in to the website, a JavaScript function communicates with AWS Cognito, authenticating them using the Secure Remote Password (SRP) protocol and returning a web token that will be used to identify users as they request access to the conference.

Step 3: Create the Serverless Backend Components

You create a Lambda function that, when it is called from the API hosted at API Gateway, registers users to the conference and sends them an attendance code. When each user registers for the conference, the registration request is stored in a DynamoDB table that returns a registration code to the end user (see Figure 4-20).

Step 4: Set Up the API Gateway

Next, you have the registration request invoke the Lambda function, which is securely called from the browser of the user carrying out the registration as a RESTful API call to Amazon API Gateway (see Figure 4-21). This background process allows registered users to register for the conference. (Remember that the registered users have already been approved through registration and verification by being a member of the Cognito user pool.)

On user devices, JavaScript works in the background with the publicly exposed API hosted by API Gateway to carry out a stateful RESTful request. Representational State Transfer (REST) is a key authentication component of the AWS cloud, and RESTful APIs are the most common AWS API format. REST uses the following HTTP verbs to describe the type of each request:

• GET: Request a record

• PUT: Update a record

• POST: Create a record

• DELETE: Delete a record

A user who types a URL into a browser is carrying out a GET request. Submitting a request for the conference is a POST request.

RESTful communication is defined as stateless, which means that all the information needed to process a RESTful request is self-contained within the actual request; the server doesn’t need additional information to be able to process the request. The beauty of this design is that you don’t need any of your own servers at the backend. You just need Lambda hosting your functions, which are called based on the logic of the application and the application request that is carried out by the user.

Step 5: Register for Conference

The user sees none of the infrastructure that has been described to this point and just wants to register for the conference. Figure 4-22 shows the user interface.