【AWS】新しいAWSの開発環境について考えてみた


## はじめに

この記事は、AWSの開発環境について考えてみた内容をまとめたものです。
主な内容としては検討内容などを中心に書きます。（思いついたことなど）
誤りなどがあれば書き直していく予定です。

内容につきましては2024年8月27日時点の内容で記載しております。あらかじめご了承ください。
なお、本記事の内容は筆者の見解を多分に含んでおり、加えて何かを断定するものではございません。

## CodeCommitやCloud9の廃止について

2024年某日、CodeCommitを含む一部のサービスについて終了のお知らせが発表されました。
CodeCommitについてはAWSのre:postに記載があり、そこで周知があったようです。
（公式に発表されたわけではないので多くの人が気づかなかったと思います。）

[対象のre:post](https://repost.aws/questions/QUshILm0xbTjWJZSD8afYVgA/codecommit-cannot-create-a-repository#ANa5lXt9nwSiGyN8fGlmOA-Q)

※なお、現在はAWSのre:postに記載のコメントについては削除済となっており閲覧は不可

以降、以下の公式ブログにてアナウンスがありました。

> After careful consideration, we have made the decision to close new customer access to AWS CodeCommit, effective July 25, 2024. AWS CodeCommit existing customers can continue to use the service as normal. AWS continues to invest in security, availability, and performance improvements for AWS CodeCommit, but we do not plan to introduce new features.
>

日本語訳

> 慎重に検討した結果、2024 年 7 月 25 日をもって、AWS CodeCommit への新規顧客アクセスを終了することを決定しました。AWS CodeCommit の既存のお客様は、引き続き通常どおりサービスをご利用いただけます。AWS は、AWS CodeCommit のセキュリティ、可用性、パフォーマンスの向上に投資を続けていますが、新機能の導入は予定していません。

引用：[How to migrate your AWS CodeCommit repository to another Git provider](https://aws.amazon.com/jp/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)

つまり、今後は新規でのCodeCommitの利用ができなくなるということです。
ただし、現在利用している方については引き続き利用可能とのことですが、今後の運用も考えたときにどうするかということが問題となります。

また、CodeCommitに併せてCloud9も終了するとのことで、Cloud9についても新規での利用ができなくなるとのことです。

> 慎重に検討を重ねた結果、 2024 年 7 月 25 日をもちまして、 AWS Cloud9 について、新規のお客様向けのアクセスを閉じることを決定いたしました。 AWS Cloud9 を既にお使いのお客様は、これまで通りサービスをご利用いただくことが可能です。 AWS は AWS Cloud9 のセキュリティ、可用性、パフォーマンスの改善に引き続き投資を行ってまいりますが、新機能の導入は予定しておりません。

引用：[AWS Cloud9 から AWS IDE Toolkits または AWS CloudShell に移行する方法](https://aws.amazon.com/jp/blogs/news/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/)

## 問題を整理

CodeCommitやCloud9が利用できなくなるということで、新しい開発環境をどうするかということが問題となります。具体的には今までAWS上で完結して利用できていたものが利用できなくなります。

なお、筆者は以下のような書籍を出していることもあり、今後のハンズオンの運用を考える立場にあります。

[CodeシリーズでハッピーなCI/CDを構築しよう【AWSハンズオン虎の巻シリーズ】: 知識がなくても手を動かしながらCI/CDをAWS上に実装できる一冊！ - Amazon](https://amzn.asia/d/2b2CX0e)

※宣伝の意図はありません。あくまで参考までに。

つまり、書籍に関してはCodeCommitを前提にしているため、おおむねすべてのハンズオンが使えなくなるということになります。

## そもそもCodeCommitやCloud9を使っていた理由

書籍ではCodeCommitを使っていましたが、その理由としては以下のようなものがあります。

- AWSのサービスだけで開発環境を構築できることを紹介したい
- CodeCommitはAWSのアカウントがあれば、だれでも気軽に使える
  - ただし、業務で利用するかというと賛否両論
- 他のリポジトリサービスアカウントを作成する必要がない
  - GitHub、GitLabなど

Cloud9については以下のような理由があります。

- AWSのサービスだけで開発環境を構築できる
- 開発環境を構築するのが簡単
  - 環境テンプレートがあるのでジャンプスタートが可能

また、本番環境や業務においてもCodeCommitやCloud9を使っている場合があるかと思います。

## 構成図で整理する

今までの開発環境を構成図で整理してみます。
従来のCodeシリーズとCloud9を使った開発環境を想定しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/18672f28-94dc-12b6-ef03-31b5c09fe96b.png)

こうやって整理するとCodeCommitやCloud9がなくなると影響範囲がどれくらいになるか理解できると思います。

## 開発環境どうする

なくなることを踏まえて、新しい開発環境をどうするかを考えます。

まず考えるべきこととしては以下のようなものがあります。

- リポジトリサービスは何を使うか
- 統合開発環境（IDE）は何を使うか

順番に見ていきましょう。

## リポジトリサービスは何を使うか

これはGitHubやGitLab、Bitbucketなどがあります。
どれを使うかは好みや業務での利用状況によると思いますが、世界的な採用率ではGitHubが高いです。

GitHubの採用率が高いことは以下の情報から伺えます。

- [開発者は1億人を超えている](https://github.blog/news-insights/company-news/100-million-developers-and-counting/)
  - [米国、インド、中国からの利用者が多い](https://octoverse.github.com/2022/global-tech-talent)
- [Fortune 100 企業の約 30% がオープン ソース プログラム オフィス (OSPO) を持っている](https://github.blog/news-insights/research/the-state-of-open-source-and-ai/)

また、AWSではGitHubとの連携も進んでおり、GitHub Actionsを使ってCI/CDを構築することも可能になっています。

- [AWS 上で大規模な GitHub Actions のセルフホステッドランナーを使用する際のベストプラクティス](https://aws.amazon.com/jp/blogs/news/best-practices-working-with-self-hosted-github-action-runners-at-scale-on-aws/)

ちなみにAWSとGitHubの連携については認証方法のことが話題に挙がりますが、最近ではOIDCを使った認証も可能になっています。

[アマゾン ウェブ サービスでの OpenID Connect の構成](https://docs.github.com/ja/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)

さらにCodeBuildはGitHub Actionsとの連携も可能になっています。

[2024/04/24 AWS CodeBuild がマネージド型の GitHub Action ランナーのサポートを開始](https://aws.amazon.com/jp/about-aws/whats-new/2024/04/aws-codebuild-managed-github-action-runners/)

AWS SAMを使っている場合は公式ドキュメントにGitHub Actionsを使ったデプロイ方法も記載されています。

[GitHub アクションを使用して でデプロイする AWS SAM](https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/deploying-using-github.html)

以上のことからGitHubを使うことをおすすめしますが、GitLabやBitbucketのほうが使い慣れているという場合はそれらを使うのもありだと思います。
また、業務の場合は社内で使われているものを使いましょう。

## 統合開発環境（IDE）は何を使うか

Cloud9が利用できなくなるということで、新しいIDEを使う必要があります。
ではどんなIDEを使うかというと、以下のような選択肢があります。

- Amazon CodeCatalyst（Dev Environments）
- Amazon SageMaker Studio
- GitHub Codespaces

GitHubとの連携を考えるとGitHub Codespacesがおすすめですが、AWSのサービスを使いたい場合はCodeCatalyst（Dev Environments）やSageMaker Studioをおすすめします。
CodeCatalystはGitHubとの連携が可能であり、Visual Studio CodeをCloud上で起動して利用できます。
以上のことから、開発環境はVisual Studio Codeを前提とした開発環境を構築したほうが良いと考えられます。

なお、趣旨からズレることにはなりますが、`AWS IDE Toolkits`という拡張機能がVisual Studio Codeにはありますので
拡張機能を前提にした開発環境を構築するのもありだと思います。

再掲：[AWS Cloud9 から AWS IDE Toolkits または AWS CloudShell に移行する方法](https://aws.amazon.com/jp/blogs/news/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/)

### AWS CloudShellはどうなの

AWS CloudShellはAWSのコンソール上でCLIを使うことができるサービスです。
身の回りでもよく聞きますが、AWS CloudShellを使ってアプリケーションをデプロイするといったことは可能です。

ただし、AWS CloudShellはちょっとしたAWSリソースへのアクセスや操作などに使うことを目的にしたほうが良いです。

理由としては筆者の体験ベースにはなりますが、コンテナイメージをビルドする時にCloudShellのスペックが足りませんでした。（主に容量の面で）
そのため、CloudShellを使う場合はあくまでCLI操作に使うことをおすすめします。

## まとめ

以上のことから、新しい開発環境を構築する際には以下のような選択肢があります。

- リポジトリサービス
  - GitHub
  - GitLab
  - Bitbucket

- 統合開発環境（IDE）
  - Amazon CodeCatalyst（Dev Environments）
  - Amazon SageMaker Studio
  - GitHub Codespaces
  - Visual Studio Code（AWS IDE Toolkits）
- その他
  - AWS CloudShell（CLI操作に使う）

ただし、ここに書いたことはあくまで筆者の考えであり、他にも選択肢はあると思います。
また、業務での利用状況によっても選択肢は変わると思いますので、自分たちの状況に合わせて選択していただければと思います。

2024/08/28 追記
Amazon SageMaker Studioは開発と言っても(ML)開発なのでアプリケーション開発とはまた違った使い方にはなると思います。

とはいえ、IDEなのでやろうと思えば、コンテナイメージのビルドやアプリケーションのビルドが可能であるため
開発環境になりえるかなと考えました。

## おわり