Service connections
Read time: 6 minutes
Last edited: Aug 15, 2024
Overview
This topic explains what service connections are and how LaunchDarkly uses them to calculate your bill.
About service connections
When a LaunchDarkly server-side SDK initializes, it creates a persistent streaming connection that allows you to update flag values in near real-time. LaunchDarkly SDKs can initialize in a virtual or physical operating system (OS) instance, such as a server, virtual machine (VM), pod, or container. They can also initialize in ephemeral processes and serverless architecture.
A service connection is one instance of one server-side SDK connected to one LaunchDarkly environment for a time period measured in minutes. Only server-side SDKs count toward measuring service connections. If you have multiple SDKs or SDK instances in the same application, each unique connection between an SDK and an environment contributes to the calculation of service connections.
Client-side SDKs are measured by the number of contexts they encounter, not by the relationship between the SDK and an environment. To learn more, read How client-side SDKs affect billing.
How we calculate service connections
A LaunchDarkly service connection is measured in connection time: you accrue one service connection when one SDK is connected to one LaunchDarkly environment for one month. This is because much of the value you get from LaunchDarkly is based on the persistent connection that offers you control over your software. We calculate service connections based on the number of minutes per month you are connected to LaunchDarkly. LaunchDarkly assumes 43,800 minutes per month.
You can scale service connections up and down. Our calculation will align with the total amount of time each service connection is connected to LaunchDarkly. We do not round service connections up or down, but we may combine them: if one service connection is connected to LaunchDarkly for half of a month and another service connection is connected for half of a month, we calculate that as one service connection. We also include connections to pre-production environments as service connections for billing purposes. We support your unique architecture by focusing on the time spent connected, and calculating the service connections for you.
A good way to estimate your potential service connections is to count the total number of back-end services that use a LaunchDarkly server-side SDK and are running your application. These services might be pods, containers, virtual machines, replicas, environments, and so on. For example, how many containers are running across your EC2 instances? How many committed pods do you have running in Kubernetes monthly? You can also contact Sales to discuss your potential service connection usage in more detail. If you are an existing customer and have questions on your service connection usage, start a Support ticket.
How service connections affect your bill
LaunchDarkly offers monthly and annual billing options. We can also customize billing plans to more precisely meet your needs.
If you are on a subscription billing plan, you commit to a certain amount of service connections each month. LaunchDarkly will also bill you at the beginning of each month for any usage in excess of these prepaid entitlements from the prior month. You can change your monthly entitlements from the Billing page. To learn more, read The Billing tab.
Server-side SDKs and service connection-based billing
Certain SDKs have special considerations regarding streaming connections to LaunchDarkly.
Ruby and Python
Ruby and Python applications operate in web contexts that fork off processes to handle requests. In both languages, you must initialize an instance of the SDK for each process. That connection is only maintained for as long as the process exists.
PHP and Apex
PHP's shared-nothing architecture prevents LaunchDarkly from using the streaming API connection across requests. Because of this, LaunchDarkly’s streaming API does not connect to PHP SDKs. Instead, the SDK polls for flag values. Apex SDKs operate in a similar way. To learn more, read How an SDK in polling mode affects billing.
The LaunchDarkly Relay Proxy and service connection-based billing
If you use the Relay Proxy, we calculate your bill based on the number of server-side SDKs connected to the Relay Proxy.
Relay Proxy offline mode
In highly secure infrastructure, you can use the Relay Proxy in offline mode. In this circumstance, contact Sales to determine the best solution for your needs.
Serverless architecture and service connection-based billing
In a serverless architecture, you initialize the LaunchDarkly SDK at function initialization time to call for the flag values. Assuming a service connection averages 43,800 minutes if your average invocation duration is one minute, we count each invocation as 1/43,800 of a service connection. If your average duration is one second, we count each invocation as 1/2,628,000 of a service connection.
LaunchDarkly measures service connections with one-minute granularity. If your average duration is less than one minute, we record a representative sample of execution each minute.
In order to estimate your usage for a serverless architecture, we use the average duration of your Lambda and the number of invocations per month.
Here are some representative examples of this calculation:
| Average Lambda duration | Example service connection calculation |
|---|---|
| Many minutes | Each invocation is billed for the time it actually runs, rounded to the nearest minute: 1/43,800 of a service connection each minute. |
| Between one and two minutes | Imagine a scenario where each invocation lasts 75 seconds. LaunchDarkly will sample each Lambda invocation once, and the invocation will be billed at minimum one minute (1/43,800 of a service connection). One quarter of invocations, on average, will cross the one minute sample boundary twice and be billed for two minutes (2/43,800 service connection). The total service connections billed therefore averages out to 75 seconds per Lambda invocation. |
| A few seconds | Imagine a scenario where you have a single Lambda function with an average duration of 15 seconds. If this Lambda is invoked four times within a minute, it accumulates a total runtime of 60 seconds. LaunchDarkly samples at the beginning and end of the minute, so the sampling records, on average, only one of the four Lambda invocations. Therefore, we count this as just 60 seconds of connection time or 1/43,800 of a service connection. |
| Less than a second | LaunchDarkly samples the number of running Lambdas each minute, and bills 1/43,800 of a service connection for each one. If your average Lambda duration is 100ms, LaunchDarkly will record 1/600 of the actual invocations, but bill each one for 60,000ms (the one-minute minimum granularity), which averages out to the same cost. |
To determine your Lambda function's average invocation duration, refer to your AWS console. To learn more about using LaunchDarkly with Lambda, read Using LaunchDarkly with AWS Lambda.
How an SDK in polling mode affects billing
You can configure an SDK to poll LaunchDarkly at certain intervals to download flag values, rather than maintaining a persistent connection. Persistent SDK connections follow our best practices and allow for near-instantaneous streamed flag updates, which are more powerful because they don't introduce a delay, but in some circumstances polling may be appropriate.
LaunchDarkly calculates 732 monthly poll requests from an SDK as one service connection. This assumes 30.5 days per month, and multiplies that by 24 hours for each day. This calculation means one polling request per hour per service connection costs the same as maintaining one persistent streaming connection per service connection. If you configure an SDK to poll more frequently, your costs will increase. Likewise, if you configure an SDK to poll less frequently, your costs will decrease, but flag updates may occur more slowly than they did before the change. To learn more about configuring your SDK, read Configuration.
How client-side SDKs affect billing
Client-side SDKs are calculated by the number of contexts encountering your applications. A context is defined as any unique entity that encounters a feature flag. Contexts are defined by their kind, for example, user, device, or account. Unless your plan stipulates otherwise, you are only billed for the context kind you use the most. We refer to the one context kind that impacts billing as the “primary context kind.” Context-based billing occurs every month.