本記事で学べること

・Amazon Cognotoの概要
・カスタム属性の種類や運用

はじめに

本記事では、Amazon Cognito のカスタム属性とその運用について解説します。

AWS Cognito とは

AWS Cognitoとは、アプリケーションでユーザー認証とアクセス制御を実装するためのサービスで、ユーザー属性をカスタマイズできる機能を提供しています。

カスタム属性とは

カスタム属性とは、ユーザーの属性情報に追加の情報を含めるために使用されます。たとえば、ユーザーのプロフィール写真、電話番号、または会社名などが挙げられます。

ユーザープール属性の種類

1. 標準属性：Cognitoが提供する基本的な属性で、名前、メールアドレス、電話番号などが含まれます。
2. カスタム属性：アプリケーションで定義する追加の属性で、属性名とデータ型を指定できます。

カスタム属性の運用

カスタム属性の運用については、次のようなことを考慮する必要があります。
 

1. アプリケーションで必要な属性を適切に定義することが重要です。必要な属性が定義されていない場合、アプリケーションで必要な機能を実現できません。
2. 属性データのバリデーションを実装することが重要です。属性データが正しくない場合、アプリケーションが正しく動作しない可能性があります。
3. 属性データを適切に保管することが重要です。属性データには、個人情報などの機密情報が含まれる可能性があるため、適切なセキュリティ対策が必要です。
4. 属性データの変更に対するアプリケーションの振る舞いを定義することが重要です。変更によってアプリケーションが影響を受ける可能性があるため、変更時には注意深く対処する必要があります。

まとめ

本記事では、Amazon Cognitoのカスタム属性とその運用について解説してきました。カスタム属性には、標準属性、カスタム属性があります。また、カスタム属性の運用には、属性の適切な定義、バリデーション、保管、および変更に対するアプリケーションの振る舞いの定義が必要となってきます。ぜひ本記事の内容を参考にして、Amazon Cognitoのカスタム属性を使いこなせるようになってください。

本記事で学べること

・NoSQLの概要
・各種サービスの長所・短所やユースケース

はじめに

近年において、NoSQL　の需要が高まりつつあります。これは、NoSQL　がリレーショナルデータベースよりもビッグデータの処理に向いているためです。そこで今回は、NoSQL　の代表である、Amazon DynamoDB　とGoogle Cloud Firestore　について、

1. 可用性

2. 機能性

3. バックアップ

4. データ構造

の観点から比較したいと思います。

はじめに、NoSQL　について説明したいと思います。
NoSQLとは、従来型のRDBMS¹　とは異なる非関係データベースの総称です。NoSQL　は、大規模なデータや複雑なデータ構造を扱うために開発されたデータベースで、スケーラビリティや柔軟性に優れています。
NoSQL　には、以下のような種類があります。

・キーバリューストア

・ドキュメントデータベース

・グラフデータベース

・列データベース

キーバリューストアは、キーと値のペアを格納するデータベースです。キーと値は任意の型を持ち、データの検索や追加が高速です。
ドキュメントデータベースは、ドキュメントと呼ばれる単位でデータを格納するデータベースです。ドキュメントは　JSON　や　XML　などのテキスト形式で記述され、データの追加や変更が容易です。

グラフデータベースは、ノードとエッジと呼ばれる単位でデータを格納するデータベースです。ノードはデータの要素を表し、エッジはノード間の関係を表します。グラフデータベースは、ソーシャルネットワークや金融取引などのデータに適しています。

列データベースは、列と呼ばれる単位でデータを格納するデータベースです。列はタプルと呼ばれる行に格納され、データの検索や追加が高速です。

NoSQL　は、従来型の　RDBMS　では対応できないデータの保存や処理に適しています。大規模なデータや複雑なデータ構造を扱うアプリケーションでは、NoSQL　の使用が検討されます。

Amazon DynamoDB　とは

Amazon DynamoDB　は、AWS　が提供するフルマネージド　NoSQL　データベースサービスです。DynamoDB　は、従来型の　RDBMS　とは異なり、データ量だけでなく、スループットに基づき購入するデータベースです。
DynamoDB　は、スケーラビリティ、耐久性、可用性に優れたデータベースです。DynamoDB　は、自動的にスケーリングし、データの損失を防ぎ、高可用性を実現します。
DynamoDB　は、ウェブアプリケーション、モバイルアプリケーション、IoTアプリケーションなど、さまざまなアプリケーションに使用され、大規模なデータや複雑なデータ構造を扱うアプリケーションに適しています。

Google Cloud Firestore　とは

Google Cloud Firestore　は、Google Cloud Platform　が提供するフルマネージド NoSQL データベースサービスです。Firestore は、ドキュメントベースのデータベースで、JSON　ドキュメントを保存することができます。Firestore　は、スケーラブルで、耐久性が高く、使いやすいデータベースです。
Firestore　も　DynamoDB　同様、ウェブアプリケーション、モバイルアプリケーション、IoT　アプリケーションなど、さまざまなアプリケーションに使用され、大規模なデータや複雑なデータ構造を扱うアプリケーションに適しています。
さらに、Firestore　は、Google Cloud Platform　で提供される他のサービスと統合することができます。たとえば、Firestore　は、Cloud Functions、Cloud Storage、Cloud Pub/Sub　などのサービスと統合することができます。

比較

可用性

• DynamoDB　は、自動でデータを複製し、同じリージョン²内の複数のAZ³に保存します。
• Firestore　は、リージョンレプリケーションを用いることで、同じリージョン内の複数の　AZ　にデータを複製することができます。ロケーションをマルチリージョンに選択した場合は、データを複製して元々それがあったリージョンだけでなく、さらに少なくとも2つの異なるリージョンにも保存することができますが、マルチリージョンに対応したリージョンは、europe　と　united states　のみなので、日本国内での利用を考えると現実的ではありません。

可用性は、どちらも優れていますが、自動で複製できる分だけ　DynamoDB　の方が使いやすいといえます。

機能性

• DynamoDB　は、データセットの大きさに関わらず、1秒ミリ単位でリクエストに応じることができます。
• Firestore　は、高い可用性と耐用性を実現するため、DynamoDB　ほど速い応答を返すことはできません。

機能性に関しては、DynamoDB　がおすすめといえます。

バックアップ

• DynamoDB　において、ユーザーは2つのバックアップ方法を使うことができます。1つ目は、AWS Backup　を使う方法です。Backup　を使うことでユーザーはすべてのテーブルをバックアップをすることができます。2つ目は、Point- in -Time リカバリを使う方法です。これを使うことで、現在のテーブルを過去30日以内の状態に戻すことができます。
• Firestore　において、ユーザーは　Google DataStore　を用いてインポート/エクスポートのワークフローを作らなければいけません。このワークフローは非常に複雑で、作るのが難しいです。

バックアップの観点からは、DynamoDB　がおすすめです。

データ構造

• DynamoDBは、キーバリュー型と呼ばれる、キーとバリューをペアで格納するデータベースです。
• FireStoreは、ドキュメント型と呼ばれる、JSON　などのドキュメントをそのまま格納するデータベースです。

データベースにおいては、キーバリュー型が基本的であり、ドキュメント型は　JSON　などのドキュメントの扱いも学ばなくてはならないため、学習コストは、DynamoDB　の方が低いといえます。ただし、ドキュメント型のデータベースは、データを自由な形式で保存できるというメリットがあります。FireStore　であれば、複雑なデータ設計に対応可能となります。

ユースケース

DynamoDB

• ゲームステートとプレーヤーのデータストアやプレイヤーのセッション履歴のデータストア

Firestre

• オフラインファーストアプリケーションやリアルタイムアプリケーション

まとめ

本記事では、Amazon DynamoDB　と　Google Cloud Firestore　について4つの観点から比較しました。
可用性の観点、機能性の観点、バックアップの観点からは、DynamoDB　がおすすめです。データ構造の観点では、学習コストの低さを選ぶなら　DynamoDB　がおすすめですが、データ設計が複雑な開発を行いたいときはFirestoreを使うと良いと思います。
初めは　DynamoDB　を使ってみて、NoSQL　に慣れてきて複雑なデータ設計を組みたくなったら、ぜひ　Firestore　にも挑戦してみてください。

語句の説明

本記事が想定する読者

本記事は、AWS　コンピューティングサービスを利用して、アプリケーション開発を行いたいエンジニアやエンジニア志望の方

はじめに

本記事では、AWS　が提供するコンピューティングサービスである、Amazon ECS　と　Amazon EKS　について、

1. コストパフォーマンス

2. 柔軟性

3. 運用コスト

4. 学習コスト

5. サービスとしての幅

の観点から、詳しく解説します。

Amazon ECS　とは

Amazon ECS　は、Docker¹　コンテナを実行および管理するためのフルマネージドサービスです。ECS　を使用すると、コンテナを作成、起動、停止、スケーリングできます。また、ECS　は、コンテナのネットワーク、ストレージ、セキュリティを管理することもできます。
ECS　は、Web　アプリケーション、バックエンドサービス、データ処理タスクなどのコンテナ化されたアプリケーションを実行するために使用できます。ECS　は、DevOps²　チームやアプリケーション開発者にとって、コンテナ化されたアプリケーションを迅速かつ簡単にデプロイおよび管理するための強力なツールです。

Amazon EKS とは

Amazon EKS は、AWS が提供する完全マネージド　Kubernetes³　サービスです。EKS　を使用すると、Kubernetes　クラスターを作成、管理、スケーリングできます。EKS　は、ECS　同様、コンテナ化されたアプリケーションを実行するための強力なツールです。

比較

コストパフォーマンス

• ECS　は、データプレーン⁴の利用料金分のみが課金されます。
• EKS は、EKS クラスターを立てているだけで、その時間分の料金が発生します。

これらの点を考慮すると、ECS の方が極めてコストパフォーマンスが高いでしょう。

柔軟性

• ECS は、AWS オリジナルのソフトウェアをベースに構築されているため、AWS 上でしか稼働しません。
• Kubernetes をもとに開発されているクラウドサービスは、Microsoft Azure やGoogle Cloud Platform などがあります。これにより、EKS は、AWS 以外の様々なサービスと併用することができます。さらに、他のクラウドへの移行も簡単に行えます。

以上を踏まえると、EKS の方が柔軟性が高いといえます。

運用コスト

• Kubernetes はオープンソースで、世界中の開発者によって開発が進められているため、アップデートが3か月に１回のペースで実施されています。Kubernetes のアップデートの都度、EKS もバージョンアップしなくてはならないため、運用が非常に難しいです。

EKS と比べると、ECS の方が運用しやすいでしょう。

学習コスト

• Kubernetes の使い方を理解することは難しいと言われています。柔軟な設定が可能なKubernetes は、その分だけ選択肢が多くなり、必然的に勉強することが多くなってしまいます。さらに、Kubernetes は定期的にアップデートされるため、その都度変更の差分を学ばなくてはなりません。

学習コストは ECS の方が低いです。

サービスとしての幅

• ECS はコンテナをデプロイするだけのサービスです。例えば、アプリを公開するには、別のサービスを利用する必要があります。
• EKS はコンテナをデプロイすることに加えて、ロードバランサー⁵など、アプリや Web サイトを公開するためのリソースを包括的に管理できるサービスです。

サービスとしての幅は EKS の方が広いといえます。

まとめ

本記事では、Amazon ECS とAmazon EKS について３つの観点から解説しました。
コストパフォーマンスの点では、データプレーンの利用料金分のみが課金される ECS が、柔軟性では、AWS 以外の様々なサービスとも併用できる EKS が優れているといえます。また、運用コストの観点では、Kubernetes のアップデートに合わせてバージョンアップしなければならない EKS に比べると ECS の方が優れているでしょう。さらに、ECS の方がはるかに学習コストが低いこと、サービスの幅は EKS の方が広いことも抑えておきたいです。
実際の開発では ECS の機能で十分なケースがほとんどであるので、Kubernetes を使いこなす自信がない人は、ECS を利用すると良いと思います。

語句の説明

本記事で学べること

・Lambda、Fargateの概要
・サーバーレスの概念
・各種サービスの長所・短所やユースケース

はじめに

AWSは様々なコンピューティングサービスを提供しています。これは、アプリケーション開発にとってよいことだと思えますが、開発初心者にとっては混乱の元になってしまうでしょう。
そこで、本記事では、AWSが提供する2つのサーバーレスのサービス、AWS LambdaとAWS Fargateについて、

1. コストパフォーマンス

2. 柔軟性

3. 学習コスト

の観点から、詳しく解説していきます。

本記事の内容を理解するには、サーバーレスに関する知識が必要となるので、まず、サーバーレスのサービスがどのようなものなのかを説明しようと思います。

サーバーレスサービスとは、サーバーハードウェアやインフラの管理をサービスプロバイダーが行ってくれるクラウドコンピューティングサービスです。ユーザーは、サーバーインスタンスやストレージ容量などのリソースを必要に応じて使用し、使用した分だけ課金されます。
サーバレスサービスには、以下のメリットがあります。

・インフラの管理が不要で、コストを削減できます。

・開発に集中でき、生産性を向上させることができます。

・スケーラビリティに優れており、急激なトラフィックの増加にも対応できます。

サーバレスサービスは、Webアプリケーション開発、モバイルアプリケーション開発、データ分析、IoTなど、さまざまな用途に使用されています。

AWS Lambda とは

AWS Lambdaは、AWSが提供するサーバーレスコンピューティングサービスです。サーバーやクラスターについて心配することなく、コードを実行できます。AWS Lambda は、イベントが発生したときにコードを実行する環境を提供します。イベントには、HTTP リクエスト、メッセージキュー、データベースの変更など、さまざまなものがあります。AWS Lambda は、ウェブアプリケーション、バックエンドサービス、データ分析など、さまざまな目的に使用できます。
AWS Lambda のメリットは、次のとおりです。

・サーバーやクラスターを管理する必要がない

・スケーラブルで、イベントが発生するたびに自動的にコードを実行できる

AWS Lambda を使えば、サーバーやクラスターを管理する必要がなく、サーバへの負荷対策も容易に行えます。

Amazon Fargateとは

AWS Fargate は、コンテナを実行するために必要なインフラストラクチャを管理する必要がないように設計されたサーバーレスコンピューティングサービスです。コンテナを実行するために必要なインフラストラクチャをAWSが管理するので、ユーザーはコンテナの作成と管理のみに集中することができます。
Fargate は、Amazon ECS¹ と統合されており、ECS を使用してコンテナを作成、デプロイ、スケーリング、管理することができます。ウェブアプリケーション、バックエンドサービス、データ分析など、さまざまな目的で使用されています。
AWS Fargate のメリットは、次のとおりです。

・コンテナを実行するために必要なインフラストラクチャを管理する必要がない

・スケーラブルで、負荷に応じてコンテナの数を自動的に調整できる

AWS Fargate を使えば、コンテナを実行するために必要なインフラストラクチャを管理する必要がないので、効率的にコンテナを運用することができます。

比較

コストパフォーマンス

• AWS Lambda は、必要なときにしか起動しないため、料金は使用時間のみで決まります。さらに、毎月、リクエスト100万件は無料枠で提供されます。
• AWS Fargate は、最低実行数を設定するため、実行に対して料金が発生します。

コストパフォーマンスの観点では、Lambda の方が良いです。

柔軟性

• Lambda の実行時間は15分以内に制限され、開発言語も、nodeJS 、 Python 、 Go 、 Java 、 Ruby 、Net 、 C# に制限されます。ただし、開発で必要な言語は基本的にそろっていると考えて良いです。
• Fargate の実行時間には制限がありません。また、コンテナを使用するため自由度が
  高く、開発言語にも制限がありません。

柔軟性を重視するなら、Fargate がおすすめです。

学習コスト

• Lambda を使う上では、実行する OS や制約のみを理解すれば大丈夫です。
• Fargate は、ECS 、Docker についての理解が必要となります。しかし、アプリケー
  ションのアーキテクチャが把握しやすいというメリットはあります。

学習コストは、Lambda の方が低いといえます。

ユースケース

AWS Lambda は小規模な処理を行うときに、他のサービスと組み合わせて利用されます。具体的には、API Gateway と組み合わせた API システムや Amazon EventBridge と組み合わせた cron システム、 SQS と組み合わせた非同期処理に利用されることが多いです。 API システムは、主に API の管理や実行を容易にしてくれる仕組みを指し、例えば、Amazon EventBridge と組み合わせた cron システムは、1日に1回の夜間のデータベース定期メンテナンスや1時間ごとに売上の集計をコンピュータに自動で行わせることができます。また、SQS と組み合わせた非同期処理は、EC サイトのクレジットカード決済処理に使われます。

一方、AWS Fargate は大規模な処理を行うときに利用されます。具体的には、大規模なウェブアプリケーションを開発するときやコンテナワークロードの実行とスケーリングを行うとき、Pass² などのプラットフォーム向けのマイクロサービスバックエンドを利用するときなどに使われます。また、先述したように、Docker を使う場合にも利用されます。

まとめ

本記事では、AWS が提供するサーバーレスサービス、AWS Lambda と AWS Fargate について解説しました。
コストパフォーマンスでは、必要なときにしか起動しない Lambda が、柔軟性では、実行時間に制限がない Fargate が優れています。また、学習コストの観点ではLambda の方が低いといえます。
AWS を使った開発に自信がない方は、まず初めに、コストパフォーマンスが高く、学習コストが低い Lambda を使ってみると良いでしょう。そのあとで、Fargate にも挑戦してみてください。

語句の説明

本記事で学べること

・Lambda、ECS、Batchの概要
・サーバーレスの概念
・コンテナの概念
・各種サービスの長所・短所やユースケース

はじめに

AWS は様々なコンピューティングサービスを提供しています。これは、アプリケーション開発にとってよいことだと思えますが、開発初心者にとっては混乱の元にもなります。
そこで本記事では、AWS が提供する3つのサービス、AWS Lambda、AWS ECS、AWS Batch について、

1. コストパフォーマンス

2. 柔軟性

3. 機能

の観点から、詳しく解説します。

本記事の内容を理解するには、サーバーレスとコンテナに関する知識が必要となるので、まず、サーバーレスとコンテナのサービスがどのようなものなのかを説明しようと思います。

サーバーレスサービスとは

サーバーレスサービスとは、サーバーハードウェアやインフラの管理をサービスプロバイダーが行ってくれるクラウドコンピューティングサービスです。ユーザーは、サーバーインスタンスやストレージ容量などのリソースを必要に応じて使用し、使用した分だけ課金されます。
サーバレスサービスには、以下のメリットがあります。

・インフラの管理が不要で、コストを削減できます。

・開発に集中でき、生産性を向上させることができます。

・スケーラビリティに優れており、急激なトラフィックの増加にも対応できます。

サーバレスサービスは、Webアプリケーション開発、モバイルアプリケーション開発、データ分析、 IoT など、さまざまな用途に使用されています。
サーバレスサービスの代表的なサービスには、以下のようなものがあります。

・ AWS Lambda (本記事で紹介する)

・ Microsoft Azure Functions

・ Google Cloud Functions

・ IBM Cloud Functions

サーバレスサービスは、クラウドコンピューティングの新しいトレンドであり、今後ますます普及していくと考えられています。

(サーバーレスのサービスに関してはこちらをチェック↓)

サーバーレスのサービスを使うなら？ AWS Lambda vs Azure Functions vs Cloud Functions

AWS でサーバーレスのサービスを使うなら？ AWS Lambda vs AWS Fargate

コンテナサービスとは

コンテナサービスは、コンテナ技術を活用してアプリケーションのデプロイ、実行、管理を行うためのクラウドサービスのことを指します。コンテナは、アプリケーションやその依存関係、ランタイム環境などを包含した軽量な仮想化ユニットです。コンテナサービスを利用することで、アプリケーションをより効率的にデプロイし、スケーラビリティを向上させ、管理を簡素化できます。
具体的な利点には、以下のようなものがあります:

・アプリケーションの環境をコンテナに包含するため、環境の差異による問題を軽減することができます。

・コンテナは軽量で高速に起動し、リソースの効率的な利用が可能です。

・スケーラビリティが向上し、負荷の増減に柔軟に対応できます。

・マイクロサービスアーキテクチャの実現に適しており、疎結合なアプリケーションの構築が容易です。

ただし、コンテナサービスを導入する際には、セキュリティやネットワークの設定、監視、管理などに注意を払う必要があります。適切な設計とベストプラクティスを実践することが重要です。

代表的なコンテナサービスとしては、Docker　や　Kubernetes（クーバネティス）があります。
 

Docker

Dockerは、コンテナ技術のパイオニアであり、アプリケーションやその依存関係をコンテナにパッケージ化し、実行環境を完全に隔離することができます。多くのクラウドプロバイダー（AWS、Azure、Google Cloudなど）は、Dockerコンテナをホストするためのマネージドサービスを提供しています。これにより、コンテナのデプロイ、スケーリング、監視などを容易に行えます。
 

Kubernetes

Kubernetesは、コンテナオーケストレーションシステムであり、複数のコンテナのデプロイ、スケーリング、自動復旧、バージョン管理などを行うことができます。Kubernetesはオープンソースプロジェクトであり、多くのクラウドプロバイダーやオンプレミス環境でも利用されています。また、Kubernetesは非常に柔軟で拡張性があり、さまざまなアプリケーションのデプロイに適しています。
 

AWS Lambda とは

AWS Lambda は、 AWS が提供するサーバーレスコンピューティングサービスです。サーバーやクラスターについて心配することなく、コードを実行できます。 AWS Lambda は、イベントが発生したときにコードを実行する環境を提供します。イベントには、 HTTP リクエスト、メッセージキュー、データベースの変更など、さまざまなものがあります。 AWS Lambda は、ウェブアプリケーション、バックエンドサービス、データ分析など、さまざまな目的に使用できます。
AWS Lambda のメリットは、次のとおりです。

・サーバーやクラスターを管理する必要がない

・スケーラブルで、イベントが発生するたびに自動的にコードを実行できる

AWS Lambda を使えば、サーバーやクラスターを管理する必要がなく、サーバへの負荷対策も容易に行えます。

Amazon ECS とは

Amazon ECS は、Amazon EC2¹ と一緒に用いられ、Docker コンテナを実行および管理するためのフルマネージドサービスです。 ECS を使用すると、コンテナを作成、デプロイ、スケーリング、管理することができます。ECS は、ウェブアプリケーション、バックエンドサービス、データ分析など、さまざまな目的に使用できます。
ECS のメリットは、次のとおりです。

・コンテナの作成、デプロイ、スケーリング、管理を簡単に行える

・スケーラブルで、負荷に応じてコンテナの数を自動的に調整できる

ECS を使えば、コンテナの作成、デプロイ、スケーリング、管理を簡単に行えるので、効率的にコンテナを運用することができます。

AWS Batch とは

AWS Batch は、バッチ処理ジョブをスケーラブルかつ簡単に実行するためのサービスです。 AWS Batch を使用すると、バッチ処理ジョブを作成、スケジュール、および実行することができます。 AWS Batch は、コンピューティングインスタンスの自動スケーリングをサポートしているため、バッチ処理ジョブの負荷に合わせてコンピューティングインスタンスの数を自動的に調整することができます。
AWS Batch のメリットは、次のとおりです。

・バッチ処理ジョブをスケーラブルかつ簡単に実行できる

・コンピューティングインスタンスの自動スケーリングをサポートしているため、バッチ処理ジョブの負荷に合わせてコンピューティングインスタンスの数を自動的に調整できる

AWS Batch を使えば、バッチ処理ジョブをスケーラブルかつ簡単に実行できるため、効率的にバッチ処理ジョブを運用することができます。

比較

可用性

• Lambda　では、メモリが設定した値で足りなくなった場合、コンソール上でメモリ量を増やせすことができ、毎秒のリクエスト数が突然増えても問題なく処理されます。
• ECS では、メモリが足りなくなった場合、メモリ量をコンソールで増やすことはできません。新規にインスタンスを起動し、プログラムを実行できる環境を再度整えてからプログラムを実行する必要があります。
• Batch も ECS と同じです。

可用性の観点では、Lambda の方が良いです。

柔軟性

• Lambda の実行時間は15分以内に制限され、開発言語も、nodeJS 、Python 、Go 、Java 、Ruby 、Net 、C# に制限されます。ただし、開発で必要な言語は基本的にそろっていると考えて良いです。
• ECS や Batch は、必要に応じてサーバーのスペックを自由に選ぶことができます。

柔軟性の観点では、ECS と Batch が優れているといえます。

機能性

• Lambda は処理時間が15分を過ぎたら強制的に停止されます。
• ECS は15分以上の処理ができます。
• Batch は15分以上の処理ができ、さらに Amazon ECS よりも大規模な処理に適しています。

機能性の観点では、ECS と Batch がおすすめです。

コスト

• Lambda は、必要なときにしか起動しないため、料金は使用時間のみで決まります。　さらに、毎月、リクエスト100万件は無料枠で提供されます。
• ECS は、EC2 インスタンスを起動している時間も課金されます。
• Batch は、 コンピューティングリソース分の料金がかかります。

これら3つは、料金形態が大きく異なり、単純な比較が難しいので、条件を設定して具体的なコストを紹介することにします。
以下では、

・128MBで十分動作可能なプロセス

・1回あたり3秒かかるAPIを想定

・毎秒1リクエスト

の場合について、1ヶ月のコストを算出することにします。
 

Lambda

・リクエスト数
　86,400(回/日) * 30(日) = 2,592,000(回)
　2,592,000(回) – 1,000,000(回)※無料枠 = 1,592,000(回)
　1,592,000(回) / 1,000,000(回) * 0.20(USD) = 0.3184(USD)
・実行時間
　0.128(GB/回) * 3(秒) = 0.384(GB秒/回)
　0.384(GB秒/回) * 86,400(回/日) * 30(日) = 995,328(GB秒)
　995,328(GB秒) – 400,000(GB秒)※無料枠 = 595,328(GB秒)
　595,328(GB秒) * 0.0000166667(USD) = 9.9222(USD)

計： 0.3184 + 9.9222 = 10.2406(USD)

EC2

2vCPU, 0.5GiBMemoryのt3.nanoインスタンス1台の場合

計: 0.0068(USD/h) * 24(時間) * 30(日) = 4.896(USD)

AWS Batch

2vCPU, 0.5GiBMemoryのt3.nanoインスタンス1台の場合

計: 0.0068(USD/h) * 24(時間) * 30(日) = 4.896(USD)

ユースケース

Lambda は小規模な処理を行うときに、他のサービスと組み合わせて利用されます。具体的には、API Gateway と組み合わせた API システムや Amazon EventBridge と組み合わせた cron システム、SQS と組み合わせた非同期処理に利用されることが多いです。

• API Gateway と組み合わせた API システムは、主にAPIの管理や実行を容易にしてくれる仕組みを指します。
• Amazon EventBridge と組み合わせた cron システムは、例えば、1日に1回の夜間のデータベース定期メンテナンスや、1時間ごとに売上の集計をコンピュータに自動で行わせることができます。
• SQS と組み合わせた非同期処理は、 EC サイトのクレジットカード決済処理に使われます。

ECS は長い時間がかかる大規模な処理を行うときに利用されます。具体的には、マイクロサービス²やバッチジョブなどに利用されます。

Batch は大規模かつ ECS のサービスクォータ³を超える数の並列処理を要するバッチ処理を行う場合に利用されます。具体的には、ライフサイエンスや計算化学、臨床モデリングなどの分野や金融サービスにおける取引に関するデータ処理や機密情報の分析に利用されます。 Batch は、一般的な企業が扱うにはオーバースペックであり、主に大企業や研究機関で活躍します。

まとめ

本記事では、AWS が提供するコンピューティングサービスである、AWS Lambda 、Amazon ECS 、AWS Batch について解説しました。
初心者にとっては、Lambda　が使いやすいこと、Batch は一般的な開発ではオーバースペックであるということを頭に入れておいてください。
AWS を使った開発が初めての方は、まず初めに Lambda を使い、慣れてきたら ECS も使ってみると良いでしょう。

語句の説明