AWS、統一した API で多数の AWSサービスに CRUD + List 操作ができる AWS Cloud Control API をリリース

投稿: 2021年10月01日
タグ: 
  クラウド  ニュースネタ

Amazon Web Services(AWS) は AWS上の多数のリソースに対して共通化した API呼び出しが行える「AWS Cloud Control API」をリリースしたと発表しました。

AWS Cloud Control API, a Uniform API to Access AWS & Third-Party Services
https://aws.amazon.com/jp/blogs/aws/announcing-aws-cloud-control-api/open_in_new
  • AWS の多数のサービスに共通して操作できる Cloud Control API がリリース
  • 共通して可能な操作はいわゆる CRUD + List 操作
  • 多くのサービスに対応済みだが、現状 Amazon EC2、S3 等は未サポート
  • 利用によってメリットがあるか、利用前に検討が必要
  • サービスごとに異なる API を統一し、共通化した呼び出しが可能

    AWS 各サービスには、これまでも(これからも) それぞれのサービスで用意された API が利用可能です。 ただ、EC2 なら EC2、Lambda なら Lambda で API の名前やパラメーターも異なっており、それとなく命名は近しいものがありつつも基本的にはサービスごとに理解する必要があります。

    今回リリースされた AWS Cloud Control API はリソース横断で共通の API を用意しており、同じコマンドで多くのリソースへの操作ができるようになっています。

    例えば、Lambda Function の情報取得(List) は以下のような結果になりました。

    AWS CLI
    $aws cloudcontrol list-resources --type-name AWS::Lambda::Function --region us-east-1 { "TypeName": "AWS::Lambda::Function", "ResourceDescriptions": [ { "Identifier": "<<Function名>>", "Properties": "{\"Role\":\"arn:aws:iam::xxxxxxxxxxxx:role/<<Role名>>\",\"FileSystemConfigs\":[],\"FunctionName\":\"<<Function名>>\",\"MemorySize\":128,\"Runtime\":\"nodejs12.x\",\"Description\":\"\",\"TracingConfig\":{\"Mode\":\"PassThrough\"},\"Timeout\":3,\"PackageType\":\"Zip\",\"Handler\":\"index.handler\",\"Arn\":\"arn:aws:lambda:us-east-1:xxxxxxxxxxxx:function:<<Function名>>\",\"Architectures\":[\"x86_64\"]}" } ] }

    用意された API は Create/List/Get/Update/Delete

    リソース横断で API を共通していることから AWS Cloud Control で用意された API Action は基本的に CRUD のみになっています。

    画像_2021-10-01.jpg

    API は共通化されてもリクエストで渡すパラメーターや返ってくるレスポンス(JSON) は当然リソースごとに異なるので、実利用を考えると対象サービスを意識した使い方になるとは思います。

    現状、Amazon EC2 や Amazon S3 は未サポートのため注意が必要

    また、Cloud Control API は既に多くの AWS リソースに対応していますが、Amazon EC2 や S3 は未サポートで今後数カ月のうちに対応する予定とのことです。

    実際、EC2 インスタンスへの List 操作をしてみたらサポートしていないというエラーが返ってきました。

    AWS CLI
    $aws cloudcontrol list-resources --type-name AWS::EC2::Instance An error occurred (UnsupportedActionException) when calling the ListResources operation: Resource type AWS::EC2::Instance does not support LIST action

    対象サービス・リソースの指定は CloudFormation のリソースタイプに準拠、サードパーティのサービスにも対応

    どのサービスのどのリソースに対する操作を行うか、をパラメータで指定するわけですが、そこは CloudFormation のリソース・プロパティタイプが使用されています。
    AWS::Lambda::Function、AWS::Kinesis::Stream というように AWS::サービス名::データタイプ名 というフォーマットになっています。

    AWS resource and property types reference
    https://docs.aws.amazon.com/en_us/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.htmlopen_in_new

    加えて、サードパーティの対応済みサービスも利用可能になっています。 仕組みとしては、CloudFormation レジストリに登録されてリソースを呼ぶ、という形のようです。現状、サードパーティサービスとして DataDog、TrendMicro、MongoDB や AWS の QuickStart などが確認できます。画像_2021-10-01_2.jpg

    誰のための機能か

    『クラウド(AWS) はサービスが多すぎて大変』とはいっても、個別のシステム開発で実際に数十(例えば20以上) のサービスを常用しているケースは多くないでしょうし、 運用途中で利用するサービスが膨大に増えて各サービスの API利用が大変、といったことも稀かと思います。

    そのため、一般的なシステムの場合、Cloud Control API を使えば大幅に開発が楽になる、ということはないと思われます(個々のサービスの API 把握と大差ない)。

    一方、実際に大量の種類の AWSサービスを扱うツールを開発している人にはメリットがあるユースケースもありそうです。

    Cloud Control API に対する実装さえしてしまえば、後はサービスが追加されるたびに Request/Response の JSON フォーマットさえ対応すればよいので開発/テスト工数が削減できそうです。 ただ、これに該当するのはサードパーティのツールベンダーか、大規模組織の社内向け(ツール提供) 組織などに限定されそうではあります。

    もしかしたら、『サービスが多くて それぞれバラバラだから統一した簡単なものを出してくれ』という顧客の声を受けて開発されたのかもしれません。 ただ、統一/共通化しても実際のサービスの複雑さが減るわけではないので、レイヤーを増やして「より複雑さを増す」可能性もありそうです。

    実際、コマンドを共通化してもレスポンスは異なるものが返ってきますし、CRUD で足りない操作は各サービスの API も利用する必要があります。 (全サービスを共通化するコンセプト以上、CRUD より複雑なインタフェースは出せないでしょう)

    まだまだこれから進化してくるとは思いますが、顧客の本当に望むもの、とずれた対応になっている可能性もありそうです。