Console-to-Codeがやってきた！触ってみた！

みなさん、いかがお過ごしでしょうか！？
私は気温の乱高下に体がついていきません。。

さて、先日Console-to-Codeの一般提供開始が発表されましたね！
https://aws.amazon.com/jp/about-aws/whats-new/2024/10/general-availability-console-to-code-generate-code/
この投稿ではConsole-to-Codeとは？について説明させていただき、軽く触った感じを共有したいと思います！

Console-to-Codeとは

Console-to-Codeは、AWSマネジメントコンソールでの操作を自動的に記録し、それをコマンドもしくはIaCのコードに変換する機能です。ユーザーはコンソールでリソースを構築・設定した後、その操作を選択してCLI/CloudFormation/CDKの形式でコードを生成できます。これにより、プロトタイピングから本番環境のデプロイへの移行が大幅に楽になります。コード生成にはAmazon Q Developerが利用されています。現時点ではEC2/VPC/RDSをサポートしています。

まとめると

コンソール操作からIaCコードを生成してくれる
コードの形式はCLI/CloudFormation/CDK
機能の裏ではQ Developerが動いている
現時点でサポートしているサービスはEC2/VPC/RDS

ユーザガイドを読んでみる

ユーザガイドを読んで、もう少し深掘りしていきます。
https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/console-to-code.html

読んでわかったポイントを以下にまとめます。

CLI形式だと生成できる回数に制限はなく、CDK/CloudFormationでは無料利用枠において回数制限があり、回数制限をなくすにはProプランが必要
対応する形式はCLI/CDK(Java/Python/TypeScript)/CloudFormation(JSON/YAML)
異なるサービスに跨っても1つの記録としてコード生成することが可能(ただしコード生成はサービスごとになる)

無料枠/Proにおける回数制限

At the Free tier, there is no fixed monthly limit to the number of times you can record your console actions and generate CLI commands based on those actions. However, there is a limit to how many times per month you can generate code to use with the AWS CDK or AWS CloudFormation based on your recorded actions.

無料利用枠では、コンソールアクションを記録し、そのアクションに基づいて CLI コマンドを生成できる回数に月ごとの固定制限はありません。ただし、記録したアクションに基づいて AWS CDK または AWS CloudFormation で使用するコードを生成できる回数には月ごとに制限があります。

At the Pro tier, there is no fixed monthly limit to the number of times you can generate code for the AWS CDK or CloudFormation.

Pro レベルでは、AWS CDK または CloudFormation のコードを生成できる回数に月ごとの固定制限はありません。

サポートフォーマット

Console-to-Code can currently generate infrastructure-as-code (IaC) in the following languages and formats:

Console-to-Code は現在、次の言語と形式でインフラストラクチャアズコード (IaC) を生成できます。

CDK Java
CDK Python
CDK TypeScript
CloudFormation JSON
CloudFormation YAML

異なるサービスにまたがるコンソール操作のコード生成

Console-to-Code works across multiple services, saving its own state for as long as your browser tab is open.

Console-to-Code は複数のサービスにまたがって動作し、ブラウザタブが開いている限り、独自の状態を保存します。

実際に試してみた結果、現時点では複数のサービスを1つのコード(ファイル)として生成することはできませんでした。サービスごとでファイルが分割されてしまいます。

試してみる

それではConsole-to-Codeを実際に試していきたいと思います。

準備

VPCを作っていきたいと思います。VPCの画面にてコンソールの右端にあるボタンをクリックします。

Console-to-Codeの画面が展開されるので、「記録を開始」をクリックします。

すると「記録が進行中」という表示がされます。記録されたアクションにコンソールの操作が記録されて、蓄積されていくようなイメージでしょうか。

VPCとサブネット/ルートテーブルなどの関連リソースを作成します。

「VPCを作成」の横に「Preview code」ボタンが表示されていました。これをクリックすると

CLIコードのプレビューが見れるようです。

VPCの作成を実際に行うと、記録されたアクションが増えていきます。

ついでにEC2も作成します。EC2の画面に移動して、作成したVPC上にインスタンスを作成していきます。

「停止」をクリックして、記録を停止しました。

CloudFormationもしくはCDKに整形したいアクション(CLI)をチェックして、「CFN YAMLを生成」をクリックすると、出力したい形式を選択できます。ここではCFN JSONを選択します。

(ここで気づいたのですが、どうやらEC2とVPCを同時にコード変換できないようです。サービスごとに変換していくしかないようです。そのため、EC2のみコード変換することにします。)

コードが作成されました。
末尾にはQ Developerが推論した文章が記載されています。

出力されたコードも貼っておきます。

{
  "Resources": {
    "KeyPair": {
      "Type": "AWS::EC2::KeyPair",
      "Properties": {
        "KeyName": "test-keypair",
        "KeyType": "rsa",
        "PublicKeyMaterial": {
          "Fn::GetAtt": [
            "KeyPairResource",
            "PublicKey"
          ]
        }
      }
    },
    "KeyPairResource": {
      "Type": "AWS::CloudFormation::WaitConditionHandle",
      "Properties": {}
    },
    "SecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "launch-wizard-1 created 2024-10-17T01:06:32.901Z",
        "GroupName": "launch-wizard-1",
        "SecurityGroupIngress": [
          {
            "CidrIp": "0.0.0.0/0",
            "FromPort": 22,
            "IpProtocol": "tcp",
            "ToPort": 22
          }
        ],
        "VpcId": "vpc-0cb4f0bd440aff752"
      }
    },
    "Instance": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "ImageId": "ami-050cd642fd83388e4",
        "InstanceType": "t2.micro",
        "KeyName": {
          "Ref": "KeyPair"
        },
        "NetworkInterfaces": [
          {
            "AssociatePublicIpAddress": "true",
            "DeviceIndex": "0",
            "GroupSet": [
              {
                "Ref": "SecurityGroup"
              }
            ],
            "SubnetId": "subnet-06df413131a953e28"
          }
        ],
        "CreditSpecification": {
          "CPUCredits": "standard"
        },
        "Tags": [
          {
            "Key": "Name",
            "Value": "test-instance"
          }
        ],
        "MetadataOptions": {
          "HttpEndpoint": "enabled",
          "HttpPutResponseHopLimit": 2,
          "HttpTokens": "required"
        },
        "PrivateDnsNameOptions": {
          "HostnameType": "ip-name",
          "EnableResourceNameDnsARecord": "false",
          "EnableResourceNameDnsAAAARecord": "false"
        }
      }
    }

ここでは実際にこのテンプレートをCloudFormationでデプロイするところまではやらないでおきます。ひとまず、どのような流れでコードが作成されるかまでの確認としておきます。

所感など

Console-to-Codeはプロンプト作成を代理するという立ち位置のツールなのかなと思います。IaCのコードを生成AIで作成するにしても、情報量が多すぎてプロンプト作成が大変です。Console-to-Codeではその手間を大幅に削減してくれるはずです。
まだ対応しているリソースが少ない、そして実際に触ってみて複数のサービスを1つのコードに統合することができない、という具合に成熟にはまだ時間がかかりそうな印象です。引き続きウォッチしていきたいと思います。
ただ出力されたCloudFormationなどを生成AIでTerraformに変換したりするなど、応用次第では色々ユースケースがありそうです。
触ってみた感じ、コンソール→CLI→CloudFormation/CDKという流れコード生成が行われているように見受けられました。そして、CLI→CloudFormation/CDKの変換にてQ Developerが利用されているような感じでした。

Console-to-Codeがやってきた！触ってみた！