当我选择"调度作业"；在启动资源时，如何在内部处理流程？我可以验证ECS中的容器吗？我想它将使用批处理作业用于此选项。
# 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
如果我选择后端服务或计划作业，费用是多少？
Copilot在引擎盖下使用Fargate容器；因此，您对后端服务的收费是基于您运行的容器数量和这些容器的CPU/内存大小。最小容器大小为0.25 vCPU和512 GB的保留内存。
对于其他服务类型，您的定价还取决于其他一些因素。
负载平衡Web服务
- Fargate集装箱基于尺寸和数量(对于最小的集装箱，每月约9美元)
- 应用程序负载均衡器(每月约20美元，具体取决于流量)
后端服务
- Fargate集装箱基于尺寸和数量(对于最小的集装箱，每月约9美元)
计划作业
- 基于大小、数量、调用频率和持续时间的Fargate容器(即您只为使用的分钟数付费)
- 状态机转换一个月内的前4000个转换是免费的，这相当于假设没有重试转换，大约每21分钟调用一次。超过该限额后的转换将以较低的费率计费
其他注意事项
Copilot部署的所有资源都使用许多资源标签进行分组。您可以使用这些标签来了解计费活动，甚至可以通过copilot svc deploy或copilot job deploy中的--resource-tags标志添加自己的标签。
我们用来对资源进行逻辑分组的标签如下：
| 标记名 | |
|---|---|
| 副驾驶应用程序 | 此资源所属的应用程序的名称 |
| copilot环境 | 此资源所属环境的名称 |
| 副驾驶服务 | 此资源所属的服务或作业的名称 |
Copilot将这些实体称为通用云架构[1]。我找不到一份官方文件来详细介绍这些架构是如何组成的。我想，当您查看AWS Copilot CLI章程[2]的第一点时，从创建者的角度来看，这可能是一个实现细节：
用户从架构而非基础设施的角度进行思考。创建新微服务的开发人员不必指定VPC、负载均衡器设置或复杂的管道配置他们可能对其他AWS服务一无所知他们应该能够指定什么"；种类"；它是应用程序，以及它如何融入其整体架构；基础设施应该由此产生。
我必须同意，更复杂的用户总是问自己特定体系结构的成本会是什么样子，我完全赞成使用一个特殊的Copilot命令，如copilot estimate costs service-xy，它可以在创建服务之前执行。
有一些关于架构类型负载平衡Web服务和后端服务 您还可以提供一个可选的--resources标志来查看与您的服务相关的所有AWS资源。 我认为这使您能够在启动并运行服务后立即估计成本。 我经常使用一种更复杂的方法来理解AWS CDK中的复杂结构，那就是查看源代码。例如，您可以为负载平衡Web服务体系结构打开相应的Go文件：[5]。深入研究代码，您会注意到它们非常清楚地表明，它们使用的是Fargate容器，而不是EC2实例 您可以选择负载平衡Web服务，Copilot将提供应用程序负载均衡器、安全组和ECS服务，并在Fargate上运行您的服务。 更多关于Fargate的信息：[6] 顺便说一句，问题部分有一条非常有趣的评论，概述了他们最初决定不支持EC2的原因[7]： 团队目前明确决定反对哪些功能？ EC2浮现在脑海中。我认为我们本可以在EC2实例上构建一个非常好的体验，但我认为构建一个"；抽象"；围绕ECS/Fargate；幻觉；围绕ECS/EC2。我的意思是，如果我们创造了一种完全不干涉EC2体验的假象，客户可能会惊讶于他们将负责这些实例的修补和安全维护。这不是Copilot，一个CLI可以真正为人们自动化的东西(现实地)。我们仍在试图找到一种向人们展示EC2的好方法，但我们肯定认为法盖特是未来。
这也是他们在高级服务文档[4]中告诉我们的：