how to get budget estimate for copilot?

user_139150 0
Viewed 226

When I select "scheduled job" while initiating resources, how is the process handled internally? Can I verify the container in ECS? I guess it will use batch jobs for this option.

# copilot init
Note: It's best to run this command in the root of your Git repository.
Welcome to the Copilot CLI! We're going to walk you through some questions
to help you get set up with an application on ECS. An application is a collection of
containerized services that operate together.


  Which workload type best represents your architecture?  [Use arrows to move, type to filter, ? for more help]
  > Load Balanced Web Service
    Backend Service
    Scheduled Job

What will be the charges if I select backend service or scheduled job?

amazon-web-services
2 Answers

Copilot uses Fargate containers under the hood; therefore, your charges for a backend service are based on the number of containers you have running and the CPU/memory size of those containers. The minimum container size is 0.25 vCPU and 512 GB of reserved memory.

For other service types, your pricing depends on a few more things.

Load Balanced Web Service

Backend Service

  • Fargate containers based on size and number (~$9/month for the smallest possible container)

Scheduled Job

  • Fargate containers based on size, number, and invocation frequency and duration (ie you only pay for the minutes you use)
  • State Machine transitions The first 4000 transitions in a month are free, which corresponds to an invocation frequency of about once every 21 minutes assuming there are no retry transitions. Transitions after that limit are billed at a low rate.

Other notes

All Copilot-deployed resources are grouped with a number of resource tags. You can use those tags to understand billing activity, and even add your own tags via the --resource-tags flag in copilot svc deploy or copilot job deploy.

The tags we use to logically group resources are the following:

Tag Name Value
copilot-application name of the application this resource belongs to
copilot-environment name of the environment this resource belongs to
copilot-service name of the service or job this resource belongs to

The copilot-service tag is used for both jobs and services for legacy reasons.

user_58904220

Copilot refers to these entities as common cloud architectures [1]. I could not find an official document which outlines how these architectures are composed in detail. I guess it might be an implementation detail from the creators' perspective when you look at point one of the AWS Copilot CLI charter [2]:

Users think in terms of architecture, not of infrastructure. Developers creating a new microservice shouldn't have to specify VPCs, load balancer settings, or complex pipeline configuration. They may not know anything about other AWS services. They should be able to specify what "kind" of application it is and how it fits into their overall architecture; the infrastructure should be generated from that.

I have to agree that more sophisticated users always ask themselves how costs of a specific architecture will look like and I completely endorse the idea of having a special Copilot command such as copilot estimate costs service-xy which can be executed before creating the service.

There is some high-level documentation on the architecture types Load Balanced Web Service and Backend Service. [3] It mentions the command copilot svc show in conjunction with the --resources flag [4]:

You can also provide an optional --resources flag to see all AWS resources associated with your service.

I think this gives you the ability to estimate costs right after bringing the services up and running.

A somehow more complicated approach which I frequently apply to understand complex constructs in the AWS CDK is to look at the source code. For example, you could open the corresponding Go file for the Load Balanced Web Service architecture: [5]. Digging into the code, you'll notice that they make it pretty clear that they are using Fargate containers instead of EC2 instances.
That is also what they tell us in the high-level service docs [4]:

You can select a Load Balanced Web Service and Copilot will provision an application load balancer, security groups, an ECS Service and run your service on Fargate.

More on Fargate: [6]

Btw, there is a really interesting comment in the issue section which outlines why they decided against supporting EC2 in the first place [7]:

What features have the team currently explicitly decided against?

EC2 comes to mind. I think we could have built a really nice experience ontop of EC2 instances - but I think there's a difference between building an "abstraction" around ECS / Fargate and building an "illusion" around ECS / EC2. What I mean by that is that if we created the illusion of a fully hands off EC2 experience, customers might be surprised that they are expected to be in charge of patching and security maintenance of those instances. This isn't something that Copilot, a CLI can really automate for people (realistically). We're still trying to figure out a good way to expose EC2 to folks - but we definitely see Fargate as the future.

user_104734690
Related