Cost Optimisation

Overview

When creating a Depot environment for development or testing purposes, you might want to reduce cloud expenditures, or reduce the number of resources consumed by multiple environments in a single AWS account.

Read on to learn about the options that Depot provides to reduce costs.

Shared VPC

It is possible to use a shared VPC for multiple Depot environment instances in a target AWS account.

stack.ts

import { Environment } from "@stage-tech/depot-cdk";

const depotEnvironment = new Environment(this, `DepotEnvironment`, {
      account: { name: "my-account", id: "123456789012" },
      name: "example",
      idPrefix: "ex-",
      useSharedVpc: true
});

If you already have a target VPC (created manually or via another CDK stack for example) and wish to use that, instead of a Depot-bootstrapped VPC, then set useSharedVpc to a string value with the name of the VPC you wish to use. It must exist in the same AWS account as the Depot environment.

stack-with-targeted-shared-vpc.ts

import { Environment } from "@stage-tech/depot-cdk";

const depotEnvironment = new Environment(this, `DepotEnvironment`, {
      account: { name: "my-account", id: "123456789012" },
      name: "example",
      idPrefix: "ex-",
      useSharedVpc: "some-other-vpc-name"
});

note

Environments using a shared VPC will place their VPC resources into the same private subnets that other environments use (multi-tenancy). There is no network segregation in this configuration, so keep this limitation in mind. This model is most appropriate for development or test environments.

If you use a deploy-deployed shared VPC do not have full private endpoint support for all AWS services. If you want to ensure depot talks to other AWS services over private endpoints, you should use a dedicated VPC.

Fargate Spot Instances

You can use three different Fargate capacity provider configurations for the Depot API component of your environment. These are pre-canned configurations, and if you don't select one, the standard 'FARGATE' mode will be used - which is that your API will run on a rock-solid Fargate task instance(s).

You can use Fargate Spot instances to massively reduce cost with the downside that your API task may at any point in time (though quite rare) be taken down with only 2 minutes notice by AWS.

• HEAVILY_WEIGHTED_FARGATE_SPOT (every 1 x API task running will be normal FARGATE capacity provisioned, and every 3 more that run will be provisioned as FARGATE_SPOT)
• PREFER_FARGATE_SPOT_ONLY (100:1 ratio - of FARGATE_SPOT to FARGATE. i.e. the API will try to run exclusively on FARGATE_SPOT - cheapest option)
• FARGATE_ONLY (default - only use standard FARGATE capacity provider for the API tasks)

Here is an example environment that declares an API configuration that can scale from 1 to 4 task instances, and that they should all run on FARGATE_SPOT capacity (cheapest):

stack.ts

import { Environment, ApplicationFargateCapacityType } from "@stage-tech/depot-cdk";

new Environment(this, `DepotEnvironment`, {
    account: { name: "example", id: "123456789012" },
    name: "example",
    frontend: {
        scaling: {
          minCount: 1,
          maxCount: 4
        },
        preferredCapacityProvider: ApplicationFargateCapacityType.PREFER_FARGATE_SPOT_ONLY
    }
});

warning

Changing the preferredCapacityProvider setting will result in the Depot Connector Service being replaced. This will involve some API downtime as a new Fargate service is created.

Fargate Spot instance capacity fluctuates based on availability in your region and availability zone(s).

OpenSearch Cost Optimizations

From Depot 5.0.0 and above, if you do not specify ElasticSearch (OpenSearch) instanceType configuration for your Depot ElasticSearch Location, a default instance type of m6g.large.elasticsearch will be chosen. Previously the m4.large.elasticsearch instanceType was the default, which was a slower, costlier configuration to use.

If you need a very minimal development or testing ElasticSearch storage location in your environment, consider further optimising costs by using a credit-based instance types such as t3.small.elasticsearch or t3.medium.elasticsearch. These burstable instance types build up credits over time and are great for minimal performance setups with burst-like usage patterns.