Understanding AWS service latency

Understanding service latency is a critical aspect in designing and developing applications on AWS. In this blog we will look at the service latency and service limits of some of the commonly used data collection services in AWS. 

Latency considerations for "Real time" data collection services:

Amazon Kinesis Data Streams and Amazon SQS can be used for real time data collection. It is important to understand the limits of each of these service to determine how they fit in the application architecture.

Amazon Data Streams limits –

• 1 MB/Sec or 1000 Messages/Sec Per Shard for Write.
• 2 MB/Sec Per Shard for Read for all consumers. 5 API calls /Sec Per Shard for Read for all Consumers.
• This means Amazon Data Streams have a latency of about 200ms. Go with Amazon Data Streams when you are looking for "real time" data at scale with low latency. 
• However remember that there is no auto scaling of shards in Amazon Kinesis Data Streams. You have to pre-calculate your shard requirements and manage the shards yourself. 
• If you need to add (Shard Splitting) or delete (Merging Shards) shards, then you have to do this yourself. Also resharding is not instantaneous and has several limitations.  

 

Amazon SQS limits –

• Max message size is 256KB.
• Standard queues provided unlimited transactions per second while FIFO queues supports 300 messages/Sec without batching and 3000 messages/Sec with batching.
• Low latency of 10ms to about 100ms.

Amazon Kinesis Enhanced Fan out –

• Works with AWS Lambda and KCL. Consumers have to subscribe by using the SubscribeToShard().
• Push mechanism where Amazon Kinesis will push the data and each consumer will get 2MB/Sec per Shard.
• Amazon Kinesis Enhanced Fan out has latency of about 70ms. Consider using Amazon Kinesis Enhanced Fan out if you are looking for low latency. 
• However remember that this low latency comes at an additional cost. 

Latency considerations for "Near-Real time" data collection services:

Amazon Kinesis Data Firehose is meant for near real time data collection. Unlike Amazon Data Streams, Amazon Kinesis Data Firehose is fully managed and there is no need to worry about Shards. However there are few points you need to remember about Amazon Kinesis Data Firehose which makes it near real time and not real time. 

• Amazon Kinesis Data Firehose uses an internal buffer and data is flushed based on time and size rules. The minimum buffer time is 60 Seconds. So Amazon Kinesis Data Firehose has a minimum latency of 60 seconds.
• Provides automated scaling - no need to worry about shards
• Does not store data - unlike Amazon Kinesis Data Streams which can store data for 1 to 7 days.

Key take away - 

The key here is to understand when to use which AWS service. 

For example - 

• If your requirement is to write to Amazon S3 directly and you are ok with some latency, choose Amazon Kinesis Firehose. Amazon Kinesis Firehose is a managed service, can auto scale and can write to Amazon S3 directly. 
• If your requirement is to write to Amazon S3 in real time, then use a KCL based application running on Amazon EC2 or use AWS Lambda to poll your Amazon Kinesis Data Streams and write to Amazon S3.  

Latency considerations for applications deployed on Amazon EC2:

There are two types of latencies for Amazon EC2 that are in an Auto scaling group.

1)     Amazon EC2 creation latency (Time it takes to spin up a new Amazon EC2) – 

      Monitor the Amazon EC2 metrics using Amazon CloudWatch and trigger AWS Auto Scaling of Amazon EC2 based on a lower metric threshold.

2)    Communication latency between your Amazon EC2 – 

      Use Instance Placement Groups and Cluster Placement strategies to achieve low network latency and high network throughput for your Amazon EC2.

If you are using AWS CloudFormation,

        "PlacementGroup" : {
          "Type" : "AWS::EC2::PlacementGroup",
          "Properties" : {
               "Strategy" : "cluster"
          }
        }

Latency considerations for applications deployed on AWS Lambda:

AWS Lambda has latency of about 100ms for cold starts. If your architecture demands AWS Lambda will low latency, choose AWS Lambda Provisioned Concurrency. This keeps some AWS Lambda in ready state which will help reduce AWS Lambda cold starts.

~ Narendra V Joshi