本記事では、以下の前提で解説します。<ul><li>プライベートサブネット内にEC2インスタンスが配置されている</li><li>AWS Identity and Access Management (IAM) の適切な設定がされている</li></ul>

前提

EC2 Instance Connectを使用すれば、踏み台サーバーや有料のVPCエンドポイントを作成する必要がありません。よってコストを削減することができます（個人的にこれが一番嬉しい） プライベートサブネットにあるEC2にEICを利用するには、EC2 Instance Connect Endpoint を作成する必要がありますが、インターフェース型のVPCエンドポイントとは異なり、料金は発生しません。

1. コストを抑えられる

従来のSSH接続では、秘密鍵の管理が必要ですが、EICでは一時的なSSHキーを使用するため、鍵の管理や漏洩リスクを減らすことができます。

2. SSH鍵の管理が不要

IAMポリシーを利用して、どのユーザーがどのEC2にアクセスできるかを制御できます。これにより、必要な権限を持つユーザーだけがEC2に接続できるようになります。

3. 簡単なIAM権限管理

踏み台サーバーによるSSH接続、SSM Session Manager、EC2 Instance Connectの比較をするとこんな感じです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/40af26630c574f1d8b2f46376efbffe4/image.png" alt="">

比較表

EC2 Instance Connectを利用するメリット

先に言っておくと、使いづらいところもあります。<ul><li>一つのVPCに対して1つのEICエンドポイントしか設定できない<ul><li>複数サブネットにEC2がある場合は不便です。。</li></ul></li><li>DBeaverなどのデータベース管理ツールでSSHトンネルでのDBインスタンスへの接続はできない<ul><li>上記を実現するには踏み台サーバー一択かも？</li></ul></li></ul>

EC2 Instance Connectの痒いところ

プライベートサブネットにあるEC2にEICを利用するには、EC2 Instance Connect Endpoint （以下、EICエンドポイント） を作成する必要があります。ただその前に、EICエンドポイントにアタッチするセキュリティグループを作成します。<ul><li>インバウンドルール<ul><li>特に設定する必要なし。</li></ul></li><li>アウトバウンドルール<ul><li>EC2インスタンスのセキュリティグループを許可します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d669783403354aae839c61f44ec51a4c/image.png" alt=""></li></ul></li></ul>上記ルールを設定すればOK。

1. EC2 Instance Connect エンドポイント用のセキュリティグループを作成

次に、先ほど作成したセキュリティグループを使ってEICエンドポイントを作成します。<ul><li>VPCマネジメントコンソールで「エンドポイント」を選択し、「エンドポイントを作成」をクリック</li><li>タイプ：「EC2 インスタンス接続エンドポイント」を選択<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/a9770ac435804063afbff87a4ae21783/image.png" alt=""></li><li>ネットワーク設定<ul><li>EC2インスタンスが配置されているVPCを選択します。</li></ul></li><li>セキュリティグループ<ul><li>1で作成したセキュリティグループをアタッチします。</li></ul></li><li>サブネット<ul><li>EC2インスタンスが配置されているサブネットを選択します。</li></ul></li><li>※見落としがち！クライアントIPの保持<ul><li>SSH接続先のEC2にIP制限を設けたい場合は「クライアントIPの保持」にチェックを入れてください！有効化するとEICエンドポイントは、クライアントIPのアドレスを保持する様になるため、インバウンドルールにて、特定のクライアントIPを許可する設定が可能になります。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/fc3ce98b8c984a5e99710d62f1ccba67/image.png" alt=""></li></ul></li></ul>上記設定で「エンドポイントを作成」を押せばEICエンドポイントの作成が完了します。

2. EICエンドポイントを作成

EC2側のセキュリティグループ（インバウンドルール）を設定します。特定のIPアドレスのみSSH（ポート22）を許可するように設定します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/881712727d084c2191a3b814429a8651/image.png" alt="">

3. セキュリティグループの設定

設定手順

<ul><li>該当のインスタンスを選択</li><li>「接続」をクリック</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c9c0ef7255904e958898ba1fc1eca7a7/image.png" alt=""></li><li>EC2 Instance Connectのタブから「EC2 Instance Connect エンドポイントを使用して接続する」を選択して接続。</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/13ea4512818f47b091fa26ce08b67c4a/image.png" alt=""></li><li>じゃーん</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e71ebaa55786477b985f668037713cc4/image.png" alt=""></li></ul>

マネコンから

インスタンスIDがわかっていればローカル端末から接続することも可能です。<pre><code>$ aws ec2-instance-connect ssh --instance-id i-0e5e0f3e85568e95e --connection-type eice</code></pre> じゃーん<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/216afa2a8d4e46608aaaf3f4c715f1ed/image.png" alt="">

ローカルからCLIで接続

接続してみた

AWSの運用コストに関してシビアなプロジェクトであれば、少しでも運用コストは下げたいところ。今回のEC2 Instance Connectが一つの選択肢になれば幸いです。

終わりに

EC2 Instance Connectでコスト削減！プライベートサブネットのEC2に接続してみたよ

<a href="https://github.com/zricethezav/gitleaks" target="_blank" rel="noopener noreferrer">Gitleaks</a>は、機密情報をハードコードすることを防ぐ静的解析ツールです。つまり、クレデンシャルなどの情報がソースコード上にあった場合、「そんな大切な情報載せてええんか！？」って叱ってくれます。例えば、gitleaks detect -vとコマンドを打つと、検出された機密情報が表示されます。 以下は直打ちしたCognitoのClient IDが入っていた場合です。<pre><code> $ gitleaks detect -v

 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

Finding: clientId: 'XXXXXXXXXXXXXXXXXX',
Secret: XXXXXXXXXXXXXXXXXX
RuleID: generic-api-key
Entropy: 4.209867
File: nuxt.config.ts
Line: 12
Commit: e9d73...
Author: daichiccchi
Email: daichi.aoki@example.com
Date: 2024-05-07T06:21:24Z
Fingerprint: e9d73d2236826a222ef27386b9ce7aa2cd6a1821:nuxt.config.ts:generic-api-key:12

8:11AM INF scan completed in 541ms
8:11AM WRN leaks found: 1</code></pre>

そもそもgitleaksって何ぞや

今回はCloud9(Amazon Linux 2)にインストールしていきます。<pre><code># 1.ダウンロード
$ curl -OL https://github.com/zricethezav/gitleaks/releases/download/v8.13.0/gitleaks_8.13.0_linux_x64.tar.gz

# 2.解凍
$ tar -zxvf gitleaks_8.13.0_linux_x64.tar.gz 
LICENSE
README.md
gitleaks
$ ls
gitleaks gitleaks_8.13.0_linux_x64.tar.gz LICENSE README.md

# 3.実行権限付与
$ chmod +x gitleaks

# 4.パスの通っているディレクトリに移動
$ sudo mv gitleaks /usr/local/bin/

# 5.動作確認（バージョンが表示されればOK）
$ gitleaks version
8.13.0

</code></pre>

gitleaksのインストール手順

今回はhuskyというライブラリを使用しました。<pre><code>$ mkdir project-dir
$ cd project-dir
$ git init
$ npm init -y
# huskyをインストール
$ npx husky-init &amp;&amp; npm install</code></pre>ここまでコマンドを実行すると、project-dir直下に<code>.husky/pre-commit</code>ファイルが作成されます。このファイルに記述したコマンドがgit commitの際に実行されます。<code>.husky/pre-commit</code>ファイルを下記のように修正して、コミット時に機密情報を検出するようにします。 （ちなみに<code>--staged</code> オプションで<code>git add</code> 済みのファイルを検出の対象としています。）<pre><code>#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

gitleaks protect --staged // 追記</code></pre> 動作確認試しに機密情報を載せた状態でコミットしてみます。コミット時にgitleaksコマンドが実行されており、「そんな情報載せたコードのコミットなんて許しまへんで」と、しっかり怒られました。コミットもされていません。<pre><code>$ git commit -m 'test'

 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

Finding: clientId: 'XXXXXXXXXXXXXXXXXX',
Secret: XXXXXXXXXXXXXXXXXX
RuleID: generic-api-key
Entropy: 4.209867
File: nuxt.config.ts
Line: 12
Commit: e9d73...
Author: daichiccchi
Email: daichi.aoki@example.com
Date: 2024-05-07T06:21:24Z
Fingerprint: e9d73d2236826a222ef27386b9ce7aa2cd6a1821:nuxt.config.ts:generic-api-key:12

8:11AM INF scan completed in 541ms
8:11AM WRN leaks found: 1
husky - pre-commit hook exited with code 1 (error)</code></pre>

git commit時にハードコーディングがないかをチェックする方法

こちらはGithubActionsを使ってワークフローに組み込んでいきます。 ワークフローを記述するファイルを作成<code>.github/workflows/ci-gitleaks.yml</code>をリポジトリに置きます。以下のようにファイルを編集します。<pre><code>name: CI-gitleaks
on:
 push:　// 1.
jobs:
 asciidoctor_job:
 runs-on: self-hosted
 name: Scan secrets using gitleaks
 steps:
 - name: Check out code
 uses: actions/checkout@v3 // 2.
 - name: gitleaks
 run: |
 gitleaks detect -v --redact // 3.</code></pre>こちらの内容は<ol><li>プッシュしたときに</li><li>リポジトリを引っ張ってきて</li><li>gitleaksコマンドで検出するよ</li></ol>というものです。 動作確認次は機密情報がソースコードに無い状態でgitleaksが動くことを確認します。まずはコミット<pre><code>$ git add .
$ git commit -m 'テスト'
 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

8:32AM INF scan completed in 605ms
8:32AM INF no leaks found</code></pre> 次にプッシュします。<pre><code>$ git push origin feature/gitleaks</code></pre>無事にプッシュ後、GithubActionsのワークフロー上でgitleaksコマンドが実行されていることが確認できました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3b5d669f11af4381b632eb136a3ae6c0/Untitled.png" alt="">

git push時にハードコーディングがないかをチェックする方法

<ul><li>gitleaksとは、機密情報をハードコードすることを防ぐ静的解析ツールである。</li><li><code>husky</code>というライブラリを使用することで、コミット時のハードコードを自動検出することができる。</li><li>GithubActionsのワークフローに組み込むことで、プッシュ時のハードコードを自動検出することができる。</li></ul> 何事もダブルチェックが大事ですね。

まとめ

機密情報の漏洩を防ごう！～gitleaksの運用方法～

Githubのmainブランチが更新されたら自動デプロイできるようにする具体的には下記の手順を自動で行えるようにします。<ol><li>Githubのmainブランチを変更</li><li>GithubActionsが作動し、S3にファイルをアップロード</li><li>Lambda関数が発火し、CloudFrontのキャッシュを削除する</li></ol> 図にするとこんな感じです<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4ed975a03ea9499b80ce3901f3f296a0/image.png" alt="">

今回やりたいこと

まずは事前準備として、GithubActionsからCLIでS3のバケットにアクセスするための権限を持っているIAMユーザーを作成します。 1.ユーザー名は分かりやすく「GithubActions」に設定します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/41297af906ad4982b5bf3bc0106e7fbf/image.png" alt="">2.S3へのアクセスを付与します。　「ポリシーを直接アタッチする」を選択し、<a style="color:inherit" href="https://us-east-1.console.aws.amazon.com/iam/home?region=ap-northeast-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAmazonS3FullAccess" target="_blank" rel="noopener noreferrer">AmazonS3FullAccess</a>を追加<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ae26824587ee44f3baab32c4af9855c0/image.png" alt="">3.S3にアクセスするためのキーを取得します。　IAMユーザー作成後、「セキュリティ認証情報」&gt;「アクセスキーを作成」　ユースケースの選択画面では「AWS の外部で実行されるアプリケーション」を選択　　→アクセスキー、シークレットアクセスキーが発行されるのでどっかにコピーしておく 4.Githubのリポジトリにアクセスキーとシークレットアクセスキーを環境変数として設定　Githubのリポジトリの「Settings」タブのRepository secretsから登録できます。　<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c17fc1aad29e49078742db771c34c053/image.png" alt=""> これにて事前準備は完了です。

GithubActionsからS3へアクセス可能にしよう

次にGithub 側の設定です。mainブランチに変更があった際にS3へファイルをアップロードする処理を書いていきます。 導入の仕方は以下の公式ドキュメントを参照してください<a href="https://docs.github.com/ja/actions/quickstart" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/quickstart</a> <code>.github/workflows</code>&nbsp;ディレクトリ配下に<code>ci.yml</code>を作成します。<pre><code>name: Build and Deploy to S3


on:
 # mainブランチへのプッシュをトリガーにする
 push:
 branches:
 - main


jobs:
 build-and-deploy:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@main # リポジトリをチェックアウト 


 - name: Install Dependencies
 run: npm install
 # ビルドしてdistディレクトリ以下のファイルを更新
 - name: Build
 run: npm run build 


 - name: Deploy # S3にデプロイ 
 env:
 # IAMユーザーに作成したアクセスキー
 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 run: | # S3のバケットにデプロイ
 aws s3 sync --region ap-northeast-1 ./dist s3://nuxt-app-20240218 --delete
 aws s3 cp --recursive --region ap-northeast-1 ./dist s3://nuxt-app-20240218</code></pre> <code>git push origin main</code>コマンドを実行。無事、処理が完了したみたいです。S3にもアップロードされていることを確認できました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/fb8c75b3b0ef4f6188ff72a3e70b4449/image.png" alt="">

ワークフローの作成

①GithubActionsを使った自動デプロイ

Python3.9を使って、関数を1から作成していきます。関数名は「delete-cache-cloudfront」としておきます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/483aacf31399478bbf243fd36e7dd4dc/image.png" alt="">

Lambda関数の作成

Lambda関数からCloudFrontにアクセス権限を付与する必要があります。以下の手順で設定<ul><li>作成したLambda関数の設定タブの「アクセス権限」から、実行ロールのリンクをクリック</li><li>IAMロールの画面に飛ばされるので「許可の追加」から「ポリシーのアタッチ」をクリック</li><li>CloudFrontで検索すると<a href="https://us-east-1.console.aws.amazon.com/iam/home#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FCloudFrontFullAccess" target="_blank" rel="noopener noreferrer">CloudFrontFullAccess</a>が出てくるので選択して許可を追加</li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/31079a3315a541cfb3ee0f30a8fbd4cf/image.png" alt="">

アクセス権限の付与

関数の概要の「トリガーを追加」をクリック。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/60f918dfe8b54bfc89b4a825ea6d0a74/image.png" alt="">以下の内容で設定し、追加を押下<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/5fc8cf095a8d49fabc0b5ff1062ad358/image.png" alt="">

トリガーの作成

Lambdaを使ったキャッシュクリア

まずは変更前の状態を確認。CloudFrontのディストリビューションのドメインにアクセス<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/94d565f35cae494c947b8821b5721e85/image.png" alt="">CloudFrontのキャッシュ削除履歴最終履歴は2024年3月5日 15:03:11<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/86a73a40087b42c9a2431affcdc9a9e8/image.png" alt="">今回はタイトルバーの「MyApp」の文字列を「YOKU」に書き換えます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b490c4d0335544b0a7b3358f3f96ccd2/image.png" alt=""> 変更をコミットして<code>git push origin main</code>を実行！ キャッシュ削除することなく、きちんと変更が反映されていました(^ ^)<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e484fe389dcb454ea7db9ffb168bb6bb/image.png" alt=""> ちなみにCloudFrontのコンソール画面のキャッシュ削除履歴も2024年3月5日 15:13:07に更新されています。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/a513f0e6d4384d809ca378d45f96102c/image.png" alt="">

動作確認！

実務でアプリを運用していくことを想定して、デプロイを仕組み化することでヒューマンエラーを防いでいきたいと思いました。

最後に

mainブランチにマージ→S3にデプロイ→CloudFrontのキャッシュ削除まで自動化してみた

<ul><li>この記事に書くこと<ul><li>S3にNuxt.jsのファイルをデプロイする方法</li><li>CloudFrontのディストリビューション作成、設定方法</li></ul></li><li>この記事に書かないこと<ul><li>S3, CloudFrontについての概要、基礎知識</li></ul></li></ul>

バケット名　→今回は<code>nuxt-app-20240218</code>というバケット名で作成。オブジェクト所有者　→「ACL有効」に設定　※ACLを無効にすると、バケットのオブジェクトの公開設定ができなくなる。　　今回は静的Webホスティングとして公開するため、有効に設定デフォルトの暗号化　→無効に設定。　作成完了。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/450a1c9ed1834015ad239dd259c44395/image.png" alt=""> 作成したバケットを静的webホスティング用に設定していく。上記のバケット詳細の画面の下の方に「静的webホスティング」のセクションがあるのでそこから編集。　→静的webホスティングを有効に設定

S3バケットを新規作成～静的webホスティング設定

distディレクトリとはNuxtのプロジェクトをビルドした際に生成されるファイル群。.vue形式で記述したファイルが、htmlで作られた Web サイト用のファイルに変換されます。※distディレクトリごとアップロードしてしまうと、Webページにアクセスした際にindex.htmlがなく403となってしまうので注意！ 無事アップデート完了。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/08bc12b91b11486ea8e4a6b08cb11690/image.png?w=500&amp;h=401" alt="">

S3にNuxtのファイル(distディレクトリ配下)をアップロード

次に、https通信を実現するためにSSL証明書を発行していきます。主な手順としては以下の通りです。<ol><li>ドメインを購入（今回はお名前ドットコムを利用）</li><li>Route53でホストゾーンの設定</li><li>ACMを使ってパブリック証明書をリクエスト<ol><li>注意：CloudFrontで利用するためにはリージョンをバージニア北部に設定してリクエストを行う必要がある</li></ol></li><li>Route53でDNSレコードを作成（CNAMEタイプ）</li></ol> 詳細な手順は以下の記事を参考にしましたので参照ください。<a href="https://dev.classmethod.jp/articles/route53-domain-onamae/" target="_blank" rel="noopener noreferrer">https://dev.classmethod.jp/articles/route53-domain-onamae/</a>

SSL証明書を発行

事前準備

Origin domain　→作成したS3バケット名を入力<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/f9d071a6d5e144d8bed17d90abeb78ec/image.png" alt=""> オリジンへのアクセス制限<ul><li>　OAIを作成<ul><li>OAIとは？</li><li>→CloudFront内に存在する仮想的なユーザーみたいなもの。このユーザーの権限を使ってS3へのアクセス制限を行うことができる。</li><li>今回はこのOAI（CloudFront）経由でのみS3にアクセスできるようにする。</li></ul></li><li>バケットポリシーを設計する必要があるので「はい、バケットポリシーを自動で更新します」を選択 <ul><li>CloudFront側で設定したポリシーがS3側でも自動で適用される</li></ul></li></ul>　　　<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/9fede0a4dced46e7809fcd55f063e6d1/image.png" alt=""> オリジンシールドの適用　→オリジンの負荷を最小限に抑え、可用性を向上させてくれる<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ee9157e4ae4742e5bf27555bcbea9fe9/image.png" alt=""> ビューワーの設定<ul><li>Redirect HTTP to HTTPS<ul><li>httpでアクセスした際に自動でhttpsにリダイレクトしてくれる</li></ul></li><li>今回はWebサイトの閲覧が目的なのでGET, HEADメソッドのみ</li><li>今回はWebサイトの公開が目的なのでNoに設定 （yesにするとキーペアを作成する）</li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/5750c900110a48b1a3b9d1691cc3508d/image.png" alt="">https通信を実現させるための設定<ul><li>代替ドメイン名に取得したドメイン名を入力</li><li>SSL証明書はACMで発行した証明書を選択</li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3e37326d675244b5ac614b7c6e180f47/image.png" alt=""> ディストリビューション作成完了！<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4f0e0bf736524bb6895b15225969fa16/image.png" alt="">

作成時の設定

CloudFront ディストリビューションを新規で作成

<ol><li>Route53で作成したホストゾーンから、「レコードを作成」を選択</li><li>エイリアスを有効にして、「トラフィックのルーティング先」をCloudFrontに設定すると自動でディストリビューションが表示される</li></ol><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/7e2e41d044b64baea572f4cdfa26d080/image.png" alt="">

ドメインとの関連付け

S3＞バケット＞バケット名＞バケットポリシーを編集<ul><li>①があらかじめS3に設定したバケットポリシー。（誰でもアクセスできる状態）</li><li>②がディストリビューション作成時に作成したバケットポリシー （OAIを新規作成して、そのCloudFrontからでしかアクセスできない）<ul><li>①のバケットポリシーを削除</li></ul></li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/73ae18372d9e463a9b413d58e5e14bfc/image.png" alt=""> この設定により、変更前はS3のオブジェクトURIへ直接アクセスしてページを閲覧できていましたが、変更後はForbiddenで閲覧できなくなりました

S3でOAIがうまく機能しているかを確認

レコード名を貼り付けてアクセス<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/67061f93b9a246e09a69a9e0b2adfd4c/image.png" alt="">無事、アクセスすることができました。（今はドメインの更新をしていないのでディストリビューション名のドメインからアクセスしてます。）<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4c109960d1af4826b6a6f7ef052c1343/image.png" alt="">

CloudFrontからアクセス！

CloudFrontを経由してアクセスしてみよう

今回S3にフロントエンドのプロジェクトをデプロイしてCloudFrontで配信する構成をしてみました。 思ったのは、リリースのたびにS3にアップロードして、キャッシュを削除しないといけないので少し面倒だということです。 次回はデプロイの一連のワークフローのパイプラインを作っていきたいと思います。

BuildersIO produced by YOKU

だいち

だいちが執筆した記事

EC2 Instance Connectでコスト削減！プライベートサブネットのEC2に接続してみたよ

機密情報の漏洩を防ごう！～gitleaksの運用方法～

mainブランチにマージ→S3にデプロイ→CloudFrontのキャッシュ削除まで自動化してみた

Nuxt.jsをS3にデプロイしてCloudFront経由でアクセスする

【Go言語】go mod tidy, go generateでエラーが発生した時の対処法

Nuxt.jsをS3にデプロイしてCloudFront経由でアクセスする

AWS CodeCommitからSSH接続でgit cloneする

【Go言語】go mod tidy, go generateでエラーが発生した時の対処法

Nuxt.jsをS3にデプロイしてCloudFront経由でアクセスする

AWS CodeCommitからSSH接続でgit cloneする