Google Cloud Run vs AWS Lambda

大きな違い：Cloud Runが動かす単位はコンテナ、Lambdaは関数。

Cloud Runは同じコンテナインスタンスの中で複数のリクエストを並行に処理できる。

一瞬だけ大量の資源が必要で残りは必要無い（I/O待ちとか）という場合では同じインスタンスの計算資源を共用した方が金銭コスト的に都合が良い、かも。

Cloud RunもLambdaも計算資源（vCPUとメモリ）の使用時間が課金対象。

参考：

Cold start時の最初のスケーリングが比較的高速になる、かも。

Cloud Functionsと比較するなら「コンテナなので任意の言語、任意のライブラリが使える」という違いもあるが、Lambdaはcustom runtimesを使うことによって任意の言語が使えるのでLambdaと比較する場合はそこまで大きな違いではない。

同じ部分

Scale-to-zero：アイドルなときはインスタンス数がゼロになる。

したがって使っていないときはお金がかからない。

Cold startできる。

ステートレス：ある呼び出しの挙動が、前の呼び出しによって設定された状態に依存しないように設計する。

たとえばある呼び出しで何かしらローカルにファイルを作っても、別の呼び出しでそのファイルの存在を期待してはいけない。

（「設定されたランタイムに処理系があること」みたいなステートには依存せざるを得ないので、ステートレスと呼ぶのは個人的にはちょっと違和感がある……）

Cloud RunおよびLambda単体で見るのではなくて、クラウドプラットフォーム総体としても見ておいた方が良いかもしれない。

GCPとAWSではサービスの種類の数が違うし、サービス間連携の在り方も違う。

例：

ストレージのイベントから呼び出す場合、GCPだとPub/Sub設定して……となるが、AWSならS3のイベント通知機能が直接Lambdaをinvokeできる。

APIとしてHTTP endpointを公開する場合、LambdaだとAPI Gateway使うかElastic Load Balancer設定するか……となるが、Cloud Runなら単体でできる。

「VPCの中からしかアクセスできないようにできるの？」とかも（2020年8月時点ではCloud Runはできない）。

参考

これはPart 1で、後にも続いている。Part 3が結論としてユースケース別にpros/consをまとめてくださっていて読みやすい。