Amazon SQS

 

• A hosted queue that lets you integrate and decouple distributed software systems and components.
• SQS supports both standard and FIFO queues.
• SQS uses pull based (polling) not push based
• Users can access Amazon SQS from their VPC using VPC endpoints, without using public IPs, and without needing to traverse the public internet. VPC endpoints for Amazon SQS are powered by AWS PrivateLink.

Benefits

• • You control who can send messages to and receive messages from an SQS queue.
  • Supports server-side encryption.
  • SQS stores messages on multiple servers for durability.
  • SQS uses redundant infrastructure to provide highly-concurrent access to messages and high availability for producing and consuming messages.
  • SQS can scale to process each buffered request and handle any load increases or spikes independently.
  • SQS locks your messages during processing, so that multiple producers can send and multiple consumers can receive messages at the same time.

• Types of Queues

Standard Queue	FIFO Queue
Available in all regions Unlimited Throughput – Standard queues support a nearly unlimited number of transactions per seconds (TPS) per action. At-Least-Once Delivery – A message is delivered at least once, but occasionally more than one copy of a message is delivered. Best-Effort Ordering – Occasionally, messages might be delivered in an order different from which they were sent.	Available in the US East (N.Virginia), US East (Ohio) US West (Oregon), EU (Ireland), Asia Pacific (Tokyo) regions. High Throughput – By default, FIFO queues support up to 3,000 messages per second with batching, (Can request a limit increase). FIFO queues support up to 300 messages per second (300 send, receive, or delete operations per second) without batching. Exactly-Once Processing – A message is delivered once and remains available until a consumer processes and deletes it. Duplicates aren’t introduced into the queue. First-in-First-Out Delivery – The order in which messages are sent and received is strictly preserved.
Send data between applications when the throughput is important.	Send data between applications when the order of events is important.

• You can include structured metadata (such as timestamps, geospatial data, signatures, and identifiers) with messages using message attributes.
• Message timers let you specify an initial invisibility period for a message added to a queue. The default (minimum) invisibility period for a message is 0 seconds. The maximum is 15 minutes.
• SQS doesn’t automatically delete a message after receiving it for you, in case you don’t successfully receive the message.
• You can subscribe one or more SQS queues to an Amazon SNS topic from a list of topics available for the selected queue.
• You can configure an existing SQS queue to trigger an AWS Lambda function when new messages arrive in a queue.
  • Your queue and Lambda function must be in the same AWS Region.
  • FIFO queues also support Lambda function triggers.
  • You can associate only one queue with one or more Lambda functions.
  • You can’t associate an encrypted queue that uses an AWS managed Customer Master Key for SQS with a Lambda function in a different AWS account.
• You can delete all the messages in your queue by purging them.
• Long polling helps reduce the cost by eliminating the number of empty responses and false empty responses. While the regular short polling returns immediately, even if the message queue being polled is empty, long polling doesn’t return a response until a message arrives in the message queue, or the long poll times out.
  • Short polling occurs when the WaitTimeSeconds parameter of a ReceiveMessage request is set to 0.
• To prevent other consumers from processing a message redundantly, SQS sets a visibility timeout, a period of time SQS prevents other consumers from receiving and processing the message. The default visibility timeout for a message is 30 seconds. The minimum is 0 seconds. The maximum is 12 hours.

• SQS supports dead-letter queues, which other queues can target for messages that can’t be processed successfully.
• Delay queues let you postpone the delivery of new messages to a queue for a number of seconds.

Basic SQS Architecture

• • Main Parts
    • The components of your distributed system
    • The queue
    • The messages
  • Standard Queues
    • Default queue type.
    • Makes a best effort to preserve the order of messages.
    • Stores copies of your messages on multiple servers for redundancy and high availability.
    • Consumes messages using short polling (default) – take a subset of SQS servers (based on a weighted random distribution) and returns messages from only those servers.
  • FIFO Queues
    • The order in which messages are sent and received is strictly preserved and a message is delivered once and remains available until a consumer processes and deletes it.
    • Duplicates aren’t introduced into the queue.
    • FIFO queues support message groups that allow multiple ordered message groups within a single queue.
  • When you create a new queue, you must specify a queue name unique for your AWS account and region. This becomes your queue url.
    https://sqs.region.amazonaws.com/accountnumber/queuename
  • Each message receives a system-assigned message ID for identifying messages.
  • Every time you receive a message from a queue, you receive a receipt handle for that message.
• You can use cost allocation tags to organize your AWS bill to reflect your own cost structure.
• Send, receive, or delete messages in batches of up to 10 messages or 256KB.

Dead-Letter Queues

• • A dead-letter queue lets you set aside and isolate messages that can’t be processed correctly to determine why their processing didn’t succeed.
  • Setting up a dead-letter queue allows you to do the following:
    • Configure an alarm for any messages delivered to a dead-letter queue.
    • Examine logs for exceptions that might have caused messages to be delivered to a dead-letter queue.
    • Analyze the contents of messages delivered to a dead-letter queue to diagnose software or the producer’s or consumer’s hardware issues.
    • Determine whether you have given your consumer sufficient time to process messages.
  • When to use a dead-letter queue
    • When you have a standard SQS queue, to avoid additional costs from SQS handling failed messages over and over again. Dead-letter queues can help you troubleshoot incorrect message transmission operations.
    • To decrease the number of messages and to reduce the possibility of exposing your system to poison-pill messages (messages that can be received but can’t be processed).
  • When not to use a dead-letter queue
    • When you want to be able to keep retrying the transmission of a message indefinitely in your SQS standard queue.
    • When you don’t want to break the exact order of messages or operations in your SQS FIFO queue.

Best Practices

• • Extend the message’s visibility timeout to the maximum time it takes to process and delete the message. If you don’t know how long it takes to process a message, as long as your consumer still works on the message, keep extending the visibility timeout .
  • Using the appropriate polling mode.
  • Configure a dead-letter queue to capture problematic messages.
  • To avoid inconsistent message processing by standard queues, avoid setting the number of maximum receives to 1 when you configure a dead-letter queue.
  • Don’t create reply queues per message. Instead, create reply queues on startup, per producer, and use a correlation ID message attribute to map replies to requests. Don’t let your producers share reply queues.
  • Reduce cost by batching message actions.
  • Use message deduplication IDs to monitor duplicate sent messages.

Monitoring, Logging, and Automating

• • Monitor SQS queues using CloudWatch
  • Log SQS API Calls Using AWS CloudTrail
  • Automate notifications from AWS Services to SQS using CloudWatch Events

Security

• • Use IAM for user authentication.
  • SQS has its own resource-based permissions system that uses policies written in the same language used for IAM policies.
  • Protect data using Server-Side Encryption and AWS KMS.
  • SSE encrypts messages as soon as Amazon SQS receives them. The messages are stored in encrypted form and Amazon SQS decrypts messages only when they are sent to an authorized consumer.

Pricing

• • You are charged per 1 million SQS requests. Price depends on the type of queue being used. Requests include:
    • API Actions
    • FIFO Requests
    • A single request of 1 to 10 messages, up to a maximum total payload of 256 KB
    • Each 64 KB chunk of a payload is billed as 1 request
    • Interaction with Amazon S3
    • Interaction with AWS KMS
  • Data transfer out of SQS per TB/month after consuming 1 GB for that month

Limits

Limit	Description
Delay queue	The default (minimum) delay for a queue is 0 seconds. The maximum is 15 minutes.
Inflight messages per queue	For most standard queues , there can be a maximum of approximately 120,000 inflight messages (received from a queue by a consumer, but not yet deleted from the queue). You can request a limit increase.
	For FIFO queues, there can be a maximum of 20,000 inflight messages (received from a queue by a consumer, but not yet deleted from the queue).
Queue name	A queue name can have up to 80 characters. The following characters are accepted: alphanumeric characters, hyphens, and underscores. Queue names are case-sensitive.
	The name of a FIFO queue must end with the .fifo suffix. The suffix counts towards the 80-character queue name limit.
Message attributes	A message can contain up to 10 metadata attributes.
Message batch	A single message batch request can include a maximum of 10 messages.
Message throughput	Standard queues support a nearly unlimited number of transactions per second (TPS) per action.
	By default, FIFO queues support up to 3,000 messages per second with batching. FIFO queues support up to 300 messages per second (300 send, receive, or delete operations per second) without batching.
Message visibility timeout	The default visibility timeout for a message is 30 seconds. The minimum is 0 seconds. The maximum is 12 hours.

Amazon SNS

 

• • A web service that makes it easy to set up, operate, and send notifications from the cloud. SNS follows the “publish-subscribe” (pub-sub) messaging paradigm, with notifications being delivered to clients using a “push” mechanism rather than to periodically check or “poll” for new information and updates.

Features

• SNS is an event-driven computing hub that has native integration with a wide variety of AWS event sources (including EC2, S3, and RDS) and AWS event destinations (including SQS, and Lambda).
  • Event-driven computing is a model in which subscriber services automatically perform work in response to events triggered by publisher services. It can automate workflows while decoupling the services that collectively and independently work to fulfil these workflows.
• Message filtering allows a subscriber to create a filter policy, so that it only gets the notifications it is interested in.
• Message fanout occurs when a message is sent to a topic and then replicated and pushed to multiple endpoints. Fanout provides asynchronous event notifications, which in turn allows for parallel processing.
• SNS mobile notifications allows you to fanout mobile push notifications to iOS, Android, Fire OS, Windows and Baidu-based devices. You can also use SNS to fanout text messages (SMS) to 200+ countries and fanout email messages (SMTP).
• Application and system alerts are notifications, triggered by predefined thresholds, sent to specified users by SMS and/or email.
• Push email and text messaging are two ways to transmit messages to individuals or groups via email and/or SMS.
• SNS provides durable storage of all messages that it receives. When SNS receives your Publish request, it stores multiple copies of your message to disk. Before SNS confirms to you that it received your request, it stores the message in multiple Availability Zones within your chosen AWS Region.
• SNS allows you to set a TTL (Time to Live) value for each message. When the TTL expires for a given message that was not delivered and read by an end user, the message is deleted.

SNS provides simple APIs and easy integration with applications.

Publishers and Subscribers

• Publishers communicate asynchronously with subscribers by producing and sending a message to a topic, which is a logical access point and communication channel.
• Subscribers consume or receive the message or notification over one of the supported protocols when they are subscribed to the topic.

• Publishers create topics to send messages, while subscribers subscribe to topics to receive messages.
• SNS FIFO topics support the forwarding of messages to SQS FIFO queues. You can also use SNS to forward messages to standard queues.

SNS Topics

• Instead of including a specific destination address in each message, a publisher sends a message to a topic. SNS matches the topic to a list of subscribers who have subscribed to that topic, and delivers the message to each of those subscribers.
• Each topic has a unique name that identifies the SNS endpoint for publishers to post messages and subscribers to register for notifications.
• A topic can support subscriptions and notification deliveries over multiple transports.

The SNS service will attempt to deliver messages from the publisher in the order they were published into the topic, so no guarantee.

SNS also logs the the delivery status of notification messages sent to topics with the following SNS endpoints:

• Application
• HTTP
• Lambda
• SQS
• Amazon Kinesis Data Firehose

Message Attributes

• Amazon SNS supports delivery of message attributes. Message attributes allow you to provide structured metadata items (such as time stamps, geospatial data, signatures, and identifiers) about the message. Message attributes are optional and separate from, but sent along with, the message body.
• You can use message attributes to help structure the push notification message for mobile endpoints. The attributes are not delivered to the mobile endpoint, as they are when sending messages with message attributes to SQS endpoints.
• You can also use message attributes to make your messages filterable with subscription filter policies. You apply filter policies to topic subscriptions.
• Message attributes contain a name, type, and value that must not be empty or null. The message body should not be empty or null also.

Message Filtering

• A filter policy is a simple JSON object.
• By default, a subscriber of an SNS topic receives every message published to the topic. The filter policy contains attributes that define which messages the subscriber receives.

Raw Message Delivery

• By default, messages are delivered encoded in JSON that provides metadata about the message and topic.
• You can send large payload messages using AWS SDK that supports AWS Signature Version 4 signing.
• You can also enable raw message delivery for messages delivered to either SQS endpoints or HTTP/S endpoints.

System to System Messaging

• When a message is published to an SNS topic that has a Lambda function subscribed to it, the Lambda function is invoked with the payload of the published message. The Lambda function receives the message payload as an input parameter and can manipulate the information in the message, publish the message to other SNS topics, or send the message to other AWS services.
• When you subscribe a SQS queue to a SNS topic, you can publish a message to the topic and SNS sends a SQS message to the subscribed queue. The SQS message contains the subject and message that were published to the topic along with metadata about the message in a JSON document.
• When you subscribe an HTTP/s endpoint to a topic, you can publish a notification to the topic and SNS sends an HTTP POST request delivering the contents of the notification to the subscribed endpoint. When you subscribe the endpoint, you select whether SNS uses HTTP or HTTPS to send the POST request to the endpoint.

User Notifications

• You have the ability to send push notification messages directly to apps on mobile devices. Push notification messages sent to a mobile endpoint can appear in the mobile app as message alerts, badge updates, or even sound alerts.
• Direct addressing allows you to deliver notifications directly to a single endpoint, rather than sending identical messages to all subscribers of a topic. This is useful if you want to deliver precisely targeted messages to each recipient.
• You can use SNS to send text messages, or SMS messages, to SMS-enabled devices. You can send a message directly to a phone number, or you can send a message to multiple phone numbers at once by subscribing those phone numbers to a topic and sending your message to the topic.
• You can use the Delivery Status feature to get information on the final disposition of your SMS message.
• SMS messages that are of high priority to your business should be marked as Transactional. This ensures that messages such as those that contain one-time passwords or PINs get delivered over routes with the highest delivery reliability.
• SMS messages that carry marketing messaging should be marked Promotional. Amazon SNS ensures that such messages are sent over routes that have a reasonable delivery reliability but are substantially cheaper than the most reliable routes.

SNS Delivery Retries

• All messages sent to SNS are processed and delivered immediately. If a message cannot be successfully delivered on the first attempt, SNS implements a 4-phase retry policy:

1) retries with no delay in between attempts

2) retries with some minimum delay between attempts

3) retries with some back-off model (linear or exponential)

4) retries with some maximum delay between attempts

Monitoring

• Monitoring SNS topics using CloudWatch
• Logging SNS API calls using CloudTrail

Security

• SNS provides encrypted topics to protect your messages from unauthorized and anonymous access. The encryption takes place on the server side.
• SNS supports VPC Endpoints via AWS PrivateLink. You can use VPC Endpoints to privately publish messages to SNS topics, from a VPC, without traversing the public internet.
• Using access control policies, you have detailed control over which endpoints a topic allows, who is able to publish to a topic, and under what conditions.
• You can enable AWS X-Ray for your messages passing through Amazon SNS, making it easier to trace and analyze messages as they travel through to the downstream services.

Pricing

• You pay based on the number of notifications you publish, the number of notifications you deliver, and any additional API calls for managing topics and subscriptions. Delivery pricing varies by endpoint type.

Limits

• By default, SNS offers 10 million subscriptions per topic, and 100,000 topics per account.
• A single SMS message can contain a maximum of 140 bytes of information.
• With the exception of SMS messages, SNS messages can contain up to 256 KB of text data.

AWS X-Ray

 

• AWS X-Ray analyzes and debugs production, distributed applications, such as those built using a microservices architecture. With X-Ray, you can identify performance bottlenecks, edge case errors, and other hard to detect issues.

Concepts

• • A segment provides the name of the compute resources running your application logic, details about the request sent by your application, and details about the work done.
  • A segment can break down the data about the work done into subsegments. A subsegment can contain additional details about a call to an AWS service, an external HTTP API, or an SQL database.
    • For services that don’t send their own segments, like Amazon DynamoDB, X-Ray uses subsegments to generate inferred segments and downstream nodes on the service map. This lets you see all of your downstream dependencies, even if they don’t support tracing, or are external.
    • Subsegments represent your application’s view of a downstream call as a client. If the downstream service is also instrumented (like an AWS SDK client), the segment that it sends replaces the inferred segment generated from the upstream client’s subsegment.
  • X-Ray uses the data that your application sends to generate a service graph. Each AWS resource that sends data to X-Ray appears as a service in the graph.
  • A service graph is a JSON document that contains information about the services and resources that make up your application. The X-Ray console uses the service graph to generate a visualization or service map. Service graph data is retained for 30 days.
  • Edges connect the services that work together to serve requests. Edges connect clients to your application, and your application to the downstream services and resources that it uses.
  • A trace ID tracks the path of a request through your application. A trace collects all the segments generated by a single request.
    • That request is typically an HTTP GET or POST request that travels through a load balancer, hits your application code, and generates downstream calls to other AWS services or external web APIs.
  • To ensure efficient tracing and provide a representative sample of the requests that your application serves, the X-Ray SDK applies a sampling algorithm to determine which requests get traced.
    • By default, the X-Ray SDK records the first request each second, and five percent of any additional requests.
  • For advanced tracing, you can drill down to traces for individual requests, or use filter expressions to find traces related to specific paths or users.
  • Groups are a collection of traces that are defined by a filter expression. Groups are identified by their name or an Amazon Resource Name, and contain a filter expression.
  • Annotations are simple key-value pairs that are indexed for use with filter expressions. Use annotations to record data that you want to use to group traces.
    • A segment can contain multiple annotations.
    • System-defined annotations include data added to the segment by AWS services, whereas user-defined annotations are metadata added to a segment by a developer.
  • Metadata are key-value pairs with values of any type, including objects and lists, but that are not indexed. Use metadata to record data you want to store in the trace but don’t need to use for searching traces.
  • When an exception, error or fault occurs while your application is serving an instrumented request, the X-Ray SDK records details about the error, including the stack trace, if available.

Features

• • AWS X-Ray can be used with applications running on Amazon EC2, Amazon ECS, AWS Lambda, AWS Elastic Beanstalk. You just integrate the X-Ray SDK with your application and install the X-Ray agent.
  • AWS X-Ray provides an end-to-end, cross-service, application-centric view of requests flowing through your application by aggregating the data gathered from individual services in your application into a single unit called a trace.
  • The X-Ray SDK captures metadata for requests made to MySQL and PostgreSQL databases (self-hosted, Amazon RDS, Amazon Aurora), and Amazon DynamoDB. It also captures metadata for requests made to Amazon SQS and Amazon SNS.
  • You can set the trace sampling rate that is best suited for your production applications or applications in development. X-Ray continually traces requests made to your application and stores a sampling of the requests for your analysis.
  • AWS X-Ray creates a map of services used by your application with trace data. This provides a view of connections between services in your application and aggregated data for each service, including average latency and failure rates. You can create dependency trees, perform cross-availability zone or region call detections, and more.
  • AWS X-Ray lets you add annotations to data emitted from specific components or services in your application.

How X-Ray Works

• • AWS X-Ray receives data from services as segments. X-Ray then groups segments that have a common request into traces. X-Ray processes the traces to generate a service graph that provides a visual representation of your application.

• X-Ray SDK
  • The X-Ray SDK provides:
    • Interceptors to add to your code to trace incoming HTTP requests
    • Client handlers to instrument AWS SDK clients that your application uses to call other AWS services
    • An HTTP client to use to instrument calls to other internal and external HTTP web services
  • AWS X-Ray supports tracing for applications that are written in Node.js, Java, and .NET.
  • Instead of sending trace data directly to X-Ray, the SDK sends JSON segment documents to an X-Ray daemon process listening for UDP traffic.
  • The X-Ray daemon buffers segments in a queue and uploads them to X-Ray in batches.
• AWS Service Integration and Service Graph
  • You can easily integrate AWS services with AWS X-Ray. Service integration can include adding tracing headers to incoming requests, sending trace data to X-Ray, or running the X-Ray daemon.
  • X-Ray uses trace data from the AWS resources that power your cloud applications to generate a detailed service graph.
  • You can use the service graph to identify bottlenecks, latency spikes, and other issues to solve to improve the performance of your applications.
  • There are four types of X-Ray integration:
    • Active instrumentation – Samples and instruments incoming requests.
    • Passive instrumentation – Instrument requests that have been sampled by another service.
    • Request tracing – Adds a tracing header to all incoming requests and propagates it downstream.
    • Tooling – Runs the X-Ray daemon to receive segments from the X-Ray SDK.
  • The following services provide X-Ray integration:
    • AWS Lambda – Active and passive instrumentation of incoming requests on all runtimes. AWS Lambda adds two nodes to your service map, one for the AWS Lambda service, and one for the function.
    • Amazon API Gateway – Active and passive instrumentation. API Gateway uses sampling rules to determine which requests to record, and adds a node for the gateway stage to your service map.
    • Elastic Load Balancing – Request tracing on application load balancers. The application load balancer adds the trace ID to the request header before sending it to a target group.
    • AWS Elastic Beanstalk – Tooling.

Pricing

• • You pay based on the number of traces recorded, retrieved, and scanned. A trace represents a request to your application and may include multiple data points, such as for calls to other services and database access.
  • The maximum size of a trace is 500 KB.
  • Trace data is retained for 30 days from the time it is recorded at no additional cost.

AWS CodePipeline

 

• A fully managed continuous delivery service that helps you automate your release pipelines for application and infrastructure updates.
• You can easily integrate AWS CodePipeline with third-party services such as GitHub or with your own custom plugin.

Concepts

• • A pipeline defines your release process workflow, and describes how a new code change progresses through your release process.
  • A pipeline comprises a series of stages (e.g., build, test, and deploy), which act as logical divisions in your workflow. Each stage is made up of a sequence of actions, which are tasks such as building code or deploying to test environments.
    • Pipelines must have at least two stages. The first stage of a pipeline is required to be a source stage, and the pipeline is required to additionally have at least one other stage that is a build or deployment stage.
  • Define your pipeline structure through a declarative JSON document that specifies your release workflow and its stages and actions. These documents enable you to update existing pipelines as well as provide starting templates for creating new pipelines.
  • A revision is a change made to the source location defined for your pipeline. It can include source code, build output, configuration, or data. A pipeline can have multiple revisions flowing through it at the same time.
  • A stage is a group of one or more actions. A pipeline can have two or more stages.
  • An action is a task performed on a revision. Pipeline actions occur in a specified order, in serial or in parallel, as determined in the configuration of the stage.
    • You can add actions to your pipeline that are in an AWS Region different from your pipeline.
    • There are six types of actions
      • Source
      • Build
      • Test
      • Deploy
      • Approval
      • Invoke
  • When an action runs, it acts upon a file or set of files called artifacts. These artifacts can be worked upon by later actions in the pipeline. You have an artifact store which is an S3 bucket in the same AWS Region as the pipeline to store items for all pipelines in that Region associated with your account.
  • The stages in a pipeline are connected by transitions. Transitions can be disabled or enabled between stages. If all transitions are enabled, the pipeline runs continuously.
  • An approval action prevents a pipeline from transitioning to the next action until permission is granted. This is useful when you are performing code reviews before code is deployed to the next stage.

Features

• • AWS CodePipeline provides you with a graphical user interface to create, configure, and manage your pipeline and its various stages and actions.
  • A pipeline starts automatically (default) when a change is made in the source location, or when you manually start the pipeline. You can also set up a rule in CloudWatch to automatically start a pipeline when events you specify occur.
  • You can model your build, test, and deployment actions to run in parallel in order to increase your workflow speeds.
  • AWS CodePipeline can pull source code for your pipeline directly from AWS CodeCommit, GitHub, Amazon ECR, or Amazon S3.
  • It can run builds and unit tests in AWS CodeBuild.
  • It can deploy your changes using AWS CodeDeploy, AWS Elastic Beanstalk, Amazon ECS, AWS Fargate, Amazon S3, AWS Service Catalog, AWS CloudFormation, and/or AWS OpsWorks Stacks.
  • You can use the CodePipeline Jenkins plugin to easily register your existing build servers as a custom action.
  • When you use the console to create or edit a pipeline that has a GitHub source, CodePipeline creates a webhook. A webhook is an HTTP notification that detects events in another tool, such as a GitHub repository, and connects those external events to a pipeline. CodePipeline deletes your webhook when you delete your pipeline.
• As a best practice, when you use a Jenkins build provider for your pipeline’s build or test action, install Jenkins on an Amazon EC2 instance and configure a separate EC2 instance profile. Make sure the instance profile grants Jenkins only the AWS permissions required to perform tasks for your project, such as retrieving files from Amazon S3.
• AWS CodePipeline now supports Amazon VPC endpoints powered by AWS PrivateLink. This means you can connect directly to CodePipeline through a private endpoint in your VPC, keeping all traffic inside your VPC and the AWS network.
• You can view details for each of your pipelines, including when actions last ran in the pipeline, whether a transition between stages is enabled or disabled, whether any actions have failed, and other information. You can also view a history page that shows details for all pipeline executions for which history has been recorded. Execution history is retained for up to 12 months.

Limits

• • Maximum number of total pipelines per Region in an AWS account is 300
  • Number of stages in a pipeline is minimum of 2, maximum of 10

Pricing

• • You are charged per active pipeline each month. Newly created pipelines are free to use during the first 30 days after creation.