# インフラエンジニアの仕事内容について解説
インフラエンジニアの仕事内容について書いております。

インフラエンジニアがどういった業務に携わっているのかについて何か学びになればと思います。

### 目次

---

- インフラエンジニアとは (復習)
- インフラ基盤を構築する必要性
- インフラエンジニアの仕事の流れ
- インフラエンジニアのキャリアパス

### 内容

---

### インフラエンジニアとは

**インフラエンジニア**とは、主に**サーバー**というコンピュータや**ネットワーク機器**などを適切に設計・配置して**インフラ基盤**を構築し、それらが正常に動くよう管理していく仕事のことを指します。

例えばTwitterやLINEなど、私たちが普段当たり前のように利用しているアプリケーションも、先に説明したインフラ基盤がインフラエンジニアによって適切に管理されているおかげです。つまり、インフラエンジニアは様々なITに関わるサービスを提供する上で一番の基盤を築き、それを守る縁の下の力持ちのような存在と言えます。

インフラエンジニアに関する詳しい説明は、下記リンクの記事を参考にしてください。

https://envader.plus/article/2

### インフラ基盤を構築する必要性

なぜインフラエンジニアはインフラ基盤を作るのでしょうか。そもそもインフラ基盤はどのような用途に使用されているのでしょうか。この問いを理解することで、インフラエンジニアという仕事の意義と大切さについて理解することができます。

まず、インフラ基盤は主に以下の用途で使用されます。

・企業内の情報システム

・アプリケーションやシステムなどのサービス提供

・人工知能や統計分析

また、昨今では**DX化**が進んできており、ますます**デジタルデータ**という存在の大切さが顕著になっています。デジタルデータは主に企業や団体の管理するサーバーに保管されます。デジタルデータやそれを保管するサーバーを適切に管理し、うまく活用するにはきちんとしたインフラ基盤が必要となります。つまり、インフラ基盤を適切に管理するための人材が求められているわけです。以上の理由からインフラエンジニアはインフラ基盤を作り管理することが大切な仕事となっています。

### インフラエンジニアの仕事の流れ

インフラエンジニアがインフラ基盤を頼まれた場合には、以下の手順で仕事を進めていきます。

1. **設計**
2. **構築**
3. **運用・保守**

まず、**設計**工程ではインフラ基盤をどのように使うのかを定義します。この作業を**要件定義**と言います。要件定義はインフラ基盤が欲しいクライアント側(顧客)と何度も打ち合わせを重ねることで、クライアント側の望みを正確に言語化します。この作業には技術的な作業はあまり関係しませんが、先に説明した全工程の中で一番大事なものとなります。というのも、要件定義の段階でクライアント側の要望を間違って解釈してしまった場合、そのまま構築を始めてしまうと進捗が進めば進むほど、人件費などの関係上後戻りが難しくなります。

要件定義が終わったあとは、実際に**設計書**を作成します。具体的には、どのようなネットワーク機器や技術が必要なのかといった技術的な話も含まれます。設計書は要件定義で決めた内容を参考にして行います。

次に、**構築**工程ではインフラ基盤を実際に組み立てます。この作業を**環境構築**と言います。環境構築は設計書をもとに、実際にネットワーク機器の設置からサーバーの設定、ソフトウェアの導入などを行います。インフラ基盤の構築自体はこの作業で終わりで、あとは正常にインフラ基盤が動くかどうか**テスト**作業に入り、成功したら無事クライアント側に引き渡されます。

最後に、**運用・保守**工程では構築したインフラ基盤が維持できるよう管理します。インフラエンジニアの仕事は、インフラ基盤を構築して終わりではありません。構築したインフラ基盤は必ずしも永久にきちんと動くとは限りません。必ず不具合や障害などのトラブルが発生します。ですが、インフラ基盤が止まってしまったら、クライアント側が行いたい作業や提供したいサービスが正常に機能しなくなってしまいます。そこから出てしまう損失は、場合によっては非常に大きなものとなってしまう可能性もあります。したがって、インフラエンジニアがインフラ基盤を定期的に管理し、インフラ基盤の状態を監視する必要があります。それが運用・保守工程で行う作業です。

### インフラエンジニアのキャリアパス

現在、日本国内でIT人材は不足していると言われています。そのため、インフラエンジニアは仕事の経験がない業界未経験の人でも積極的に採用している企業が多いです。また、業界未経験の場合は研修期間を設けられ、平均で約2~3ヶ月企業の研修を受けてから実際に働くケースがほとんどです。

しかし、**未経験から良いキャリアを積むにはそれなりの期間と能力**を要します。したがって、きつい仕事をこなしつつ、**自分でも学習を重ねる**ほどのマインドを持った人がインフラエンジニアに向いていると言えます。逆に、与えられた仕事だけをこなすのに精一杯で自分で学習を積み重ねることのできない人は「やめとけ」と言われてしまうほどこの業界には適していないことになります。インフラエンジニアになるならば、それなりの覚悟を持つことをお勧めします。

インフラエンジニアには**上流工程**と**下流工程**というものが存在します。上流工程と下流工程は、先ほど説明したインフラエンジニアが働く工程を大まかに2つに区切ったものです。インフラエンジニアの仕事は設計から始まり、構築、運用・保守と決まった流れで進んでいきます。それを**川の流れ**のイメージで表し、言語化したものが上流(工程)と下流(工程)です。

まず、**下流工程**は主に**構築**や**運用・保守**を担当するエンジニアのことを指します。業界未経験の場合は下流工程の中でも最も下に位置する運用・保守を担当することになります。運用・保守で実務経験をして実績を積みつつ、自分でも学習を進めることで構築工程を任されるようになります。

次に、**上流工程**は主に設計の担当するエンジニアのことを指します。インフラエンジニアとしての経験量が多いと任されることが多くなる工程です。上流工程は直接クライアント側(顧客)とコミュニケーションを取る機会が増えるため、技術的な能力だけではなくヒアリング能力やコミュニケーション能力も必要とされます。そのため、上流工程に属するエンジニアは下流工程よりも単価がかなり高くなります。

インフラエンジニアとしての経験を積んだら、上流工程の他にも**プロジェクトマネージャー**という役職を目指すこともできます。プロジェクトマネージャーはインフラ基盤を作るといったひとつのプロジェクト全体を統括し、全体を上手く進めていくようサポートします。上流工程はあくまで設計工程などを担当するのに対し、プロジェクトマネージャーは上流工程だけではなく、下流工程も視野に入れて行動する必要があります。

### まとめ

---

以下は、インフラエンジニアの仕事についてまとめた結果です。

- DX化が進む今、それを支えるインフラ基盤を作ることのできる人材が必要とされている。
- インフラエンジニアの仕事の流れは**設計**、**構築**、**運用**・**保守**であり、それらは**上流工程**と**下流工程**という言葉で分けられている。
- 業界未経験の人は運用・保守から携わることになり、**仕事をこなしつつ自分でも学習**を進めて実績を積むことで、より上の構築や設計などのキャリアが目指せる。

### 宣伝

---

弊社では、インフラ学習サイトEnvader（エンベーダー）とITスクール（RareTECH）を運営しています。また、企業研修やシステム開発なども行っていますので興味がある方はHPよりご連絡下さい。

https://envader.plus/

https://raretech.site/

https://var.co.jp/

こちらはEnvaderの記事になります。

インフラエンジニアの仕事内容について解説

# インフラエンジニアに必要な資格（AWS）
Amazon Web Services 認定資格について共有します。

Amazon Web Services (以下: AWS)とは、通販サイトとして有名なAmazonが提供しているクラウドサービスのことです。

クラウドやAWS認定資格について何か学びになればと思います。

### 目次

---

- クラウドとは
- AWSとは
- AWSの認定資格

### 内容

---

### クラウドとは

そもそも**クラウド**とは、外部からサーバーといったコンピュータ資源などを借りることで、それらを自分で用意することなく使用することができるものです。クラウドという言葉の由来には、自分の使っているものがどこにあるのか、どういう形をしているのかがまるで雲のようにハッキリと分からないことにあります。クラウドを使うことによる主な利点は以下の2つです。

1.　コンピュータなどを自分で購入する必要がなく、それを配置する場所も必要ないこと。

2.　必要な時に、必要なだけ使うことができる。

まず、1つ目の利点について説明します。

企業がシステムやアプリケーションなどのサービスを提供する場合、従来は自分でコンピュータを購入してそれをどこかに置く必要がありました。そのような用途で使われるコンピュータを**サーバー**と言います。また、サーバーを配置するために存在している施設を**データセンター**と言います。データセンターには人間の身長と同じくらいのコンピュータが何台も置かれています。

これらを動かすためには多くの電気を消費します。また、それらを置くために存在するデータセンターを維持するためには、土地代や改装費などの維持費もかかります。つまり、自分でデータセンターを構えて大量のサーバーを維持するには、莫大なお金がかかります。

そこで、**クラウドサービス**というものが登場します。クラウドを使うことで、外部の企業が用意しているコンピュータ資源を借りて、そこでシステムやアプリケーションなどのサービスを提供することができます。つまり、コンピュータ資源を借りるということは、自分でコンピュータを用意する必要がなく、それを配置するデータセンターなどの施設も必要ないということです。

次に、2つ目の利点について説明します。

クラウドのほとんどは**従量課金制**で使用料金が発生します。従量課金制とは、使った分だけお金が発生する仕組みのことです。また、コンピュータ資源などを使わなくなった場合には手数料などのお金がかかることなく、簡単に利用を止めることができます。つまり、必要な時に、必要なだけコンピュータ資源を借りることができます。

以上2つの利点から、クラウドを使うことによりコンピュータ資源の購入費用や維持費用を削減することができ、更にコンピュータ資源の使用量を増やしたり減らしたりしたい場合、すぐにそれを実行できます。したがって、クラウドサービスは現在、様々な企業や団体に使用されています。

### AWSとは

Amazon Web Services (AWS)とは、通販サイトとして有名なAmazonが提供しているクラウドサービスのことです。AWSには現在200を超える種類のサービスが存在しており、サーバーだけではなく管理不要のデータベースやアプリケーションを動かす基盤など、様々な用途に応じて最適なサービスを使うことができます。通常なら普段から定期的に管理が必要とされるサーバーやデータベースといったコンピュータ資源も、AWSの**サーバレス**や**マネージドサービス**を使えば管理の一部または全てをやる必要がなくなります。

マネージドサービスの例を1つ挙げます。例えば**リレーショナルデータベース**という、データを保管するために使用するサーバーがあります。そのサーバーでは定期的に管理者の手によって維持するためのメンテナンス作業をする必要がありました。しかし、**RDS**というリレーショナルデータベースのマネージドサービスを使うことにより、本来必要だったメンテナンス作業を自動化することができます。

これらのサービスを組み合わせることにより、効率的にアプリケーションなどのサービスを提供できるようになります。しかし、多くの種類が存在するサービスを適切に組み合わせて使用するには、それなりの知識と経験が必要となります。

### AWSの認定資格

AWSのサービスを適切に組み合わせて利用するには、AWSに関する知識と経験が必要となります。そしてそのようなスキルはクラウドを利用する企業において必要とされるものです。そこで、**AWS認定資格**を取得すれば、AWSのスキルを証明することができます。

AWSには全部で**11種類**の認定資格が用意されています。

認定資格の難易度は全部で4種類に分かれています。

| 難易度 | 必要な能力 |
| --- | --- |
| 基礎コース | AWSを用いた経験が6ヶ月ほどを想定。基本的な使い方の理解が必要。 |
| アソシエイト | AWSを用いた実務経験が1年レベル。問題解決能力が必要。 |
| プロフェッショナル | AWSを用いた実務経験が2年レベル。設計・運用・トラブルシューティングと言った包括的な経験と知識が必要。 |
| 専門知識 | 各専門分野に関する実務経験。専門分野に関する深い知識と経験が必要。 |

認定資格のうちアソシエイトとプロフェッショナルレベルでは、設計に関するアーキテクト分野、開発者に必要な能力に関するデベロッパー分野、管理者に必要な運用分野の3つに分類されます。また、専門知識レベルでは全部で5つの分野が用意されています。

| 難易度 | 資格名 | 分野 |
| --- | --- | --- |
| 基礎コース | Cloud Practitionaer | AWSの基礎全体 |
| アソシエイト | Solutions Architect Associate | アーキテクト |
|  | Developer Associate | デベロッパー |
|  | SysOps Administrator Associate | 運用 |
| プロフェッショナル | Solutions Architect Professional | アーキテクト |
|  | DevOps Engineer Profesional | デベロッパー・運用 |
| 専門知識 | Advanced networking | ネットワーク |
|  | Data Analytics | データ分析 |
|  | Database | データベース |
|  | Machine Learning | 機械学習 |
|  | Security | セキュリティ |

それぞれの資格の詳しい試験範囲は、下記AWS公式サイトの各試験の詳細から試験ガイドをご覧ください。

https://aws.amazon.com/jp/certification/exams/?nc2=sb_ce_exm

### まとめ

---

以下は、クラウドとAWSについてまとめた結果です。

- クラウドを使用することによる利点は2つある。
    
    1.　コンピュータなどを自分で購入する必要がなく、それを配置する場所も必要ないこと。
    
    2.　必要な時に、必要なだけ使うことができる。
    
- Amazon Web Services(AWS)というクラウドサービスでは200種類以上のサービスを提供しており、それらを上手く組み合わせることで効率的に自分のアプリケーションなどのサービスを提供することが可能になる。
- AWSを自分で考えて適切に使う能力が求められており、それを証明できるのがAWS認定資格である。

### 宣伝

---

弊社では、インフラ学習サイトEnvader（エンベーダー）とITスクール（RareTECH）を運営しています。また、企業研修やシステム開発なども行っていますので興味がある方はHPよりご連絡下さい。

https://raretech.site/

https://var.co.jp/

インフラエンジニアに必要な資格（awsについて）

# Kali Linuxとは
Linuxディストリビューションには様々な種類が存在します。

その中でもサイバーセキュリティに特化したKali Linuxについて解説します。Kali Linuxについて学ぶことで、セキュリティに興味を持つきっかけになればと思います。

## Kali Linuxとは

Kali Linuxは、「カーリーリナックス」と呼び、DebianベースのオープンソースLinuxディストリビューションの一つです。サイバーセキュリティに特化したLinuxで、ペネトレーションテスト、コンピュータフォレンジック、リバースエンジニアリングなどのセキュリティに関する数多くのツールがサポートされています。

Kali Linuxを使いセキュリティチェックをすることで、自社サイトの脆弱性を把握することができます。ただしKali Linuxはセルフセキュリティチェックするには非常に便利ですが、他社サイトに使用するとサイバー攻撃とみなされ違法行為になる可能性があるため、使い方には注意が必要です。

## Kali Linuxの特徴

- サイバーセキュリティに関する多くのツールを使うことができる
    
    Kali Linuxでは600を超えるツールを使用することができます。
    
- 幅広いデバイスに対応
    
    Kali Linuxは幅広いデバイスをサポートしています。様々なハードウェア上で動作し、多くのUSBやワイヤレスデバイスとの互換性があります。
    

## 代表的なツール

以下は、代表的なツールです。これら以外にも様々なツールがサポートされているので、目的に応じて[Kali Linux公式ドキュメント](https://www.kali.org/get-kali/)を確認してください。

![kali linuxのツール](https://storage.googleapis.com/envader-article-images/kali-tools.png)

### ポートスキャン

ポートスキャンとは、対象となるIPアドレスの各ポートの稼働状況を調査する手法です。各ポートへ通信し、応答内容から解放されているポートや稼働中のサービスの情報を確認することができます。

### ペネトレーションテスト

ペネトレーションテストは、侵入テストのことです。実際に対象のシステムに対して、攻撃者が実行するような手法を用いて侵入します。システムのセキュリティ耐性や、攻撃を受けた際のリスクを把握するために行われます。

### DoS攻撃

対象となるWEBサイトやサーバーに対して、大量のアクセスを送る攻撃です。アクセスが集中することにより、対象のWEBサイトへのアクセス困難、サーバーをダウンさせるなど、対象物が正常に動作しないようにすることが目的で行われます。

### SQLインジェクション

SQLインジェクションはWEBアプリケーションの脆弱性を利用して、データベースを不正に操作する攻撃のことです。WEBアプリケーションの検索ボックスや入力フォームなどに、不正なSQL文を記入することで実行されます。

これによってデータベースに登録された情報の改ざんや漏洩の被害を受けます。

### デジタルフォレンジック

デジタルフォレンジックとは、サイバー攻撃を受けた機器のデータを解析、分析することです。再発防止、被害の原因特定、訴訟の準備などの目的で行われます。

## Kali Linuxのインストール方法

Kali Linuxは以下の方法でインストールすることができます。

1. PCへ直接Kali ISOのインストール
2. 仮想環境(VirtualBox、VMware)へKali ISOのインストール
3. コンテナ(Docker)へのインストール
4. クラウド(Amazon AWS、Microsoft Azure)を利用したインストール
5. USBへのKali ISOのダウンロード

今回は上記の内のDockerとAWSへのインストールについて解説します。

## Dockerへのインストール

### Kali Linuxコンテナの作成

以下のコマンドでKali Linuxのイメージをpullすることができます。

```bash
$ docker pull kalilinux/kali-rolling
```

取得したイメージからコンテナ作成

```bash
$ docker run -itd kalilinux/kali-rolling
```

上記コマンドでKali Linuxのコンテナを作成することができました。現状では、まだツールのインストールはされていません。ツールをインストールするためにコンテナの中に入ります。

```bash
$ docker exec -it <コンテナID> bash
```

ツールのインストールの前に、以下のコマンドを実行しておきましょう。

```bash
# apt update
```

あとは目的に応じて、必要なツールをインストールするだけです。Kali LinuxではNmap、Metasploit Frameworkなど個々でツールをインストールすることも可能ですが、メタパッケージと呼ばれる目的に応じたツールをパッケージ化したものも提供されています。

これにより個々に`apt install git`とインストールする必要はなく、`apt install <メタパッケージ名>`で複数のパッケージや依存関係のあるライブラリなどをまとめてインストールすることができます。

**主なメタパッケージ**

- **kali-linux-headless**
    
    gitやvimなどの基本的な機能を主にインストールするパッケージです。公式でも推奨されているため、インストールしておくことをお勧めします。
    
- **kali-tools-passwords**
    
    kali Linuxが提供する全てのパスワードクラッキングツールをインストールすることができます。
    
- **kali-tools-database**
    
    データベースのセキュリティチェックに関するツールをインストールすることができます。sqlmapなどが含まれています。
    
- **kali-tools-top10**
    
    kali Linuxが提供するツールの中で、重要とされる10個のツールをインストールすることができます。aircrack-ng、sqlmap、wiresharkなどが含まれています。
    

### メタパッケージのインストール

それでは、kali-linux-headlessを作成したコンテナにインストールします。以下のコマンドを実行します。

```bash
# apt -y install kali-linux-headless　　  
```

上記コマンドを入力後、数分間でインストールが完了します。ここまでで基本的なKali Linuxの設定は完了しました。必要に応じて、ツールやメタパッケージをインストールして下さい。

## AWSへのインストール

AWSのEC2へのKali Linuxのインストールについて解説します。通常のEC2インスタンス作成の手順と基本的には同じように進めていきますが、AMIの選択の部分が通常とは異なります。今回はKali LinuxのEC2へのインストールの解説のため、VPC、サブネットなどの作成、設定は割愛します。またAWSでのKali Linuxの使用は若干の料金が発生することにも注意してください。

### EC2の作成

EC2の以下の画面に進み、**インスタンスの作成**をクリックします。

![kali Linuxのインストール-1](https://storage.googleapis.com/envader-article-images/kali-ec2-1.png)

「インスタンスを起動ページ」のアプリケーションおよびosイメージの検索欄にKali Linuxと入力します。

![kali Linuxのインストール-2](https://storage.googleapis.com/envader-article-images/kali-ec2-2.png)

Kali Linuxを選択します。

![kali Linuxのインストール-3](https://storage.googleapis.com/envader-article-images/kali-ec2-3.png)

続行をクリックします。

![kali Linuxのインストール-4](https://storage.googleapis.com/envader-article-images/kali-ec2-4.png)

以下のようにAMIが反映されます。あとは通常通りEC2の作成を行ってください。

![kali Linuxのインストール-5](https://storage.googleapis.com/envader-article-images/kali-ec2-5.png)

最終的に以下のように表示されると、Kaliインスタンスの作成完了です。

![kali Linuxのインストール-6](https://storage.googleapis.com/envader-article-images/kali-ec2-6.png)

### インスタンスへのSSH接続

Kaliインスタンスへの接続は通常のEC2インスタンスへの接続と若干異なるので注意が必要です。通常EC2インスタンスに接続する際、`ssh -i <キーペア> ec2-user@<パブリックIPアドレス>`と入力しますが、これではKaliインスタンスに接続することはできません。ユーザー名をec2-userからkaliに変更するとKaliインスタンスに接続することができます。

```jsx
ssh -i <キーペア> kali@<パブリックIPアドレス>
```

以下のように表示されると、接続成功です。

```jsx
┏━(Message from Kali developers)
┃
┃ This is a cloud installation of Kali Linux. Learn more about
┃ the specificities of the various cloud images:
┃ ⇒ https://www.kali.org/docs/troubleshooting/common-cloud-setup/
┃
┗━(Run: “touch ~/.hushlogin” to hide this message)
┌──(kali㉿kali)-[~]
└─$
```

AWSを使用したKaliインスタンスには、Dockerと異なり多くのツールが既にインストールされています。ただし、インストールされていないツールもあるため使用する際には目的のツールがインストールされているか確認する必要があります。

## Nmapを使ってポートスキャン

DockerとAWSのEC2へのKali Linuxのインストールが完了しました。ここでは、DockerにインストールしたKali LinuxでNmapを使用して、簡単なポートスキャンを実行します。冒頭でも説明しましたが、Nmapでポートスキャンする対象は必ず、自身の管理下にあるIPアドレスに対して行ってください。

### Nmapのインストール

DockerへのKali Linuxのインストールの項目で、初期設定としてインストールしたkali-linux-headlessの中にNmapも含まれています。kali-linux-headlessのインストールをせずに、Nmapを単体でインストールしたい場合は以下のコマンドを実行してください。

```jsx
# apt install nmap
```

### Nmapの実行

実際にKaliコンテナからホストPC(127.0.0.1)に対してポートスキャンしてみましょう。

通常Nmapのコマンドは、`nmap <対象のIPアドレス>`でポートスキャンを実行します。コンテナの中からホストPCへのポートスキャンの際に、nmap 127.0.0.1とするとホストPCではなくコンテナ自身を指してしまうため今回は以下のコマンドを実行します。これでホストPCに対してポートスキャンを行うことができます。

```jsx
# nmap host.docker.internal
```

### 実行結果

以下のような実行結果を得ることができました。使用されているポートとサービスの一覧が表示され、PostgreSQLなどのサービスが動いていることがわかります。今回は、簡単なポートスキャンだけですが、Kali Linuxに含まれているツールを使用することで様々なセキュリティチェックを行うことができます。

```jsx
Starting Nmap 7.93 ( https://nmap.org ) at 2022-10-19 09:34 UTC
Nmap scan report for host.docker.internal (192.168.65.2)
Host is up (0.00069s latency).
Not shown: 993 closed tcp ports (reset)
PORT      STATE SERVICE
88/tcp    open  kerberos-sec
5432/tcp  open  postgresql
5555/tcp  open  freeciv
5900/tcp  open  vnc
8000/tcp  open  http-alt
49152/tcp open  unknown
49161/tcp open  unknown
```

## まとめ

- Kali Linuxは「カーリーリナックス」と呼び、サイバーセキュリティに特化したDebianベースのLinuxディストリビューションです。
- 600以上のツールと、目的ごとにツールをまとめてインストールできるメタパッケージが提供されています。
- ツールの使用は、自身の管理下にあるサイトやサーバーに対して行ってください。他社サイトに使用するとサイバー攻撃とみなされ違法行為になる可能性があります。

こちらでは、Kali Linuxとそのインストール方法について解説します。

Kali Linux とは？

# 【わかりやすく解説】可用性とは？

こちらの記事では、「可用性」について解説します。

可用性は、「**システムが安定的に稼働し続けられる能力**」のことを指します。どんなに信頼性の高いシステムにも**絶対に落ちない**というシステムは存在しません。安定的にシステムを稼働するためにも、万が一障害などが発生した場合のことを考慮しておかなければなりません。

2018年に日本政府が公開した[政府情報システムにおけるクラウドサービスの利用に係る基本方針](https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf)に可用性が取り上げられるなど、年々重要視されている「可用性」について分かりやすく説明していきます。

## 可用性の概要

可用性は、**Availability**（アベイラビリティー）の訳語です。可用性は、「可用性が高い、低い」という表現の仕方します。可用性が高い事を指して、**高可用性**（HA: **H**igh **A**vailability）と表す用語も使われています。

また、可用性は稼働率（%）で表す事ができます。例えば、あるシステムが10時間稼働した時に、「実稼働が6時間・稼働停止時間が4時間」だったとしたら、稼働率は60％と表す事ができます。

### システムの評価指標

**可用性はシステムやソフトウェアの品質を評価する際の評価指標の1つです**。システムの評価指標には可用性と似た用語も存在しており、同じような意味で捉えているケースも見受けられますので、一度整理しておきましょう。

| 評価指標の用語 | 評価指標の訳語 | 用語の説明 |
| --- | --- | --- |
| Reliability | 信頼性 | 故障しにくいこと |
| Availability | 可用性 | 使える時に使えること |
| Serviceability | 保守性 | すぐに復旧できること |
| Integrity | 完全性 | 破壊・改竄無く正確であること |
| Security | 機密性 | 不正アクセスされないこと |

システムの評価指標には**RAS**、および**RASIS**と呼ばれるものがあります。上述した表の、上から3つの評価指標の頭文字を並べたものがRASで、上から5つ全てを並べたものがRASISです。特に**RASの信頼性、可用性、保守性はシステムの評価指標で最重要視されています**ので、この3つを混同しないようにしましょう。

初めてRASをシステムの評価指標に導入したのは[IBM](https://ja.wikipedia.org/wiki/IBM)という世界最大規模のIT企業です。IBMは1970年6月に大型コンピュータの「System/370シリーズ」を発表し、この機種において新たなRASの考え方を採用し、商品としての新たな価値を訴えました。

その後、RASにISの要素を追加する形でシステムの評価指標が拡張されました。そのため、RASの3つの要素の重要度が一番高くなっており、RASISは日本独自で広まった用語であると考えられています。（参照: [IT用語辞典 RASIS](https://e-words.jp/w/RASIS.html#:~:text=%E3%80%8Crasis%E3%80%8D%E3%81%AF%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%A5%E5%A4%96%E3%81%AE%E8%B3%87%E6%96%99%E3%81%AB%E3%81%AF%E8%A8%98%E8%BC%89%E3%81%8B%E3%82%99%E6%A5%B5%E3%82%81%E3%81%A6%E4%B9%8F%E3%81%97%E3%81%8F%E3%80%81%E6%AC%A7%E7%B1%B3%E5%9C%8F%E3%81%A6%E3%82%99%E3%81%AF%E3%81%9D%E3%81%AE%E5%BE%8C%E3%82%82(%E7%8F%BE%E5%9C%A8%E3%82%82)%E5%B0%82%E3%82%89ras%E3%81%AE%E7%94%A8%E8%AA%9E%E3%81%8B%E3%82%99%E7%94%A8%E3%81%84%E3%82%89%E3%82%8C%E3%81%A6%E3%81%8A%E3%82%8A%E3%80%81rasis%E3%81%AF%E6%97%A5%E6%9C%AC%E3%81%A6%E3%82%99%E7%8B%AC%E8%87%AA%E3%81%AB%E6%8B%A1%E5%BC%B5%E3%81%95%E3%82%8C%E3%81%A6%E5%BA%83%E3%81%BE%E3%81%A3%E3%81%9F%E7%94%A8%E8%AA%9E%E3%81%A6%E3%82%99%E3%81%82%E3%82%8B%E3%81%A8%E8%80%83%E3%81%88%E3%82%89%E3%82%8C%E3%82%8B%E3%80%82)）

### 障害からの復旧

障害はいつ起こるか分かりません。だからこそ障害が起きた後のこと、つまり復旧に関して考える必要があります。障害復旧においてはRPO、RTOという概念があります。

![RPO・RTO.png](https://storage.googleapis.com/envader-article-images/availability-RPORTO.png)

- RPO（**R**ecovery **P**oint **O**bjective）

RPOは「目標復旧時点」という意味で、**障害が発生した際にシステムを過去のどの地点まで復元するかを定めた目標値のこと**です。

RPOを小さく（短く）すればするほど、障害時に喪失するデータを少なくすることができます。例えば、RPOを10秒とすると障害発生の10秒前までのデータを復旧できることを意味し、RPOを1日とすると障害発生の1日前までのデータを復旧できることを意味します。

前者は秒単位の頻度でバックアップを取得し続ける必要があるという事を意味し、これだけの高頻度でバックアップを行うことによるコストは大変大きくなってしまうでしょう。

対して後者は、バックアップの頻度は1日1回で良いことになり、バックアップにかかるコストは小さく出来ますが、障害発生時から最大で過去24時間分のデータを喪失する可能性があるということでもあります。

リアルタイムに更新され続けるデータと、1日1回しか更新されないデータとでは求められるPROは異なってきます。アプリケーションのデータ更新頻度やバックアップにかかるコストの双方を考慮してRPOを決定する必要があります。

- RTO（**R**ecovery **T**ime **O**bjective）

RTOは「目標復旧時間」という意味で、**システムの復旧までにかかる時間の目標値のこと**です。RTOを小さく（短く）すればするほど、システムを短時間で復旧できることを意味します。しかし、RTOを小さくするためには単純にデータのバックアップを取得しておくだけでなく、システム全体を冗長化して待機しておくなどのダウンタイムを短くするための別の工夫も必要となります。

RPOとRTOをどこまで小さくするべきかは、対象システムの経過時間による影響を考慮して、慎重に決定する必要があります。どちらの数値も小さいに越した事はありませんがコストを度外視して最小値を目指すのではなく、それぞれのビジネス規模に合わせた最適値を検討する必要があります。

### 可用性はどうやって高めるのか

システムの運用において可用性を高める方法は以下の2点です。

- より可用性の高いシステムへリプレイスすること
- 同じシステムを障害発生時の予備として別途用意しておくこと

前者の場合、耐障害性システムなどの導入を行い高可用性を求めるほどに大きな投資が必要になります。また、リプレイス自体の手間や現在使用している資産（システム）が無駄になってしまうなどの問題があります。

後者は**冗長化**と呼ばれ、可用性を高める方法としてよく使われます。冗長化の例としては、まず運用システムとは別に待機システムを用意し、両者を同期しておきます。もし障害が発生した場合に切り替えるだけで100％に近い高可用性を実現できます。（切り替えにともなうダウンタイムを考慮しない場合）つまり、あらゆるシステムにおいて障害が発生する可能性がある以上、冗長化で高可用性を担保するアプローチは基本中の基本と言って良いでしょう。

## サーバの可用性

Webサーバはアクセス状況の変化の影響を受けやすく、複雑なプログラムが動作する事からトラブルが発生しやすいです。また、インターネットに直接接続されているため攻撃のターゲットとなりやすい、といった性質もあります。サービスの可用性を高めるためには、まずはサービス提供の土台となるサーバの冗長化が必要です。サーバの可用性を以下の3つに分けて説明していきます。

- **オンプレミス**の可用性
- **仮想サーバ**の可用性
- **クラウドサービス**の可用性

### オンプレミスの可用性

- サーバが物理である点

まずはこの点から考えなくてはいけません。サーバがハードウェアである以上、故障は避けることができません。なので故障が発生する前提で故障時にもサービス全体に影響しないようにシステム設計をすることが物理サーバでの可用性を高くする基本となります。そのためには止まってしまうとサービスが利用できなくなる「SPoF（**S**ingle **P**oint **O**f **F**ailure: 単一障害点）」を無くす、あるいは少なくすることが重要になります。

- ハードウェアや回線などの予備を用意する

上記と同様の観点からではありますが、オンプレミスでは、物理的に存在するハードウェアや回線を冗長化して障害時に切り替えるという運用を行います。予備のハードウェアや回線を用意しておき、障害発生時に正常な回線に経路を切り替えることで障害による影響を最小限に抑えられます。

サーバを切り替える方法には、以下の3種類の方法があります。

- 障害時に運用系から待機系に自動的に切り替える「**ホットスタンバイ**」
- 待機系サーバは停止状態で用意しておき、障害発生時に待機系を起動してから切り替える「**コールドスタンバイ**」
- 常に複数台稼働させておき、**ロードバランサー**を用いて分散処理させる方法

ロードバランサーは、ロード（負荷）、バランサー（平衡・バランスを取るもの）といった意味があり、**負荷分散装置**のことを指します。主にWebシステムに対してかかる負荷を複数のサーバへ分散させて、処理バランスを調整するために用いられます。

複数のサーバを用意することで仮に1つのサーバがダウンしても残ったサーバでサービスの継続が可能です。この冗長化を実現するためには、複数のサーバそれぞれに対する負荷やサーバダウンに対応して処理を効率的にバランスよく割り振る必要があります。その役割を担えるのがロードバランサーであり、ロードバランサーを導入することで安定したサービス提供を維持することができます。

![オンプレミス.png](https://storage.googleapis.com/envader-article-images/availability-%E3%82%AA%E3%83%B3%E3%83%95%E3%82%9A%E3%83%AC%E3%83%9F%E3%82%B9.png)

### 仮想サーバの可用性

仮想サーバは、1台の物理サーバ上で複数のOSを動かすことで、仮想的に複数のサーバとして運用する方法です。使用する基盤はあくまでも物理サーバなので、仮想サーバを動かす物理サーバに対しての冗長化はオンプレミスと同じです。

オンプレミスとの違いとして、仮想サーバを起動させる物理サーバ自体を遠隔地かつ複数拠点に置くことが可能という点です。そうすることで災害時や事故でひとつの地点に深刻なハードウェア障害が起きた時にも安心です。仮想サーバごと別のハードウェアに移行し、マイグレーションを行うことですぐに業務を再開することができます。ですので仮想サーバで運用することは、国の定める事業継続計画（BCP）の対策にも有効と言えます。

![仮想サーバ.jpeg](https://storage.googleapis.com/envader-article-images/availability-%E4%BB%AE%E6%83%B3%E3%82%B5%E3%83%BC%E3%83%8F%E3%82%99.jpeg)

### クラウドサービスの可用性

クラウドサービスは、導入時の初期費用を抑えられることもあり、手軽に導入することが可能です。そのため、開発者の利用や企業のシステムをオンプレミスからクラウドへ移行するなどで利用されることは少なくありません。

クラウドベンダーを利用する利点は、インフラストラクチャー（システム基盤）部分をクラウドベンダー側で管理・提供してくれるので、ユーザはそれ以外に注力できるという点です。しかし、ユーザが可用性に対して気にしなくていいという話ではありません。

- クラウドの提供する3種類のサービス形態

クラウドベンダーはサービスを利用する利用者のニーズに合わせて**IaaS**、**PaaS**、**SaaS**という3つのサービスモデルを提供しています。代表的なサービス（ここではAWSのサービスを取り上げる）や、可用性の確保の難易度の違いを以下に挙げます。ユーザは利用するサービスモデルによって、可用性に対する対策範囲が変わりますで注意が必要です。

|  | IaaS | PaaS | SaaS |
| --- | --- | --- | --- |
| 正式名称 | Infrastructure as a Service | Platform as a Service | Software as a Service |
| 読み方 | アイアース・イアース | パース | サース |
| 提供するサービス | ハードウェア | 仮想マシン プラットフォーム | ソフトウェア一式 | 各種サービス |
| 自由度 | 高い | 中間 | 低い |
| 代表的なサービス（AWSの一例） | EC2 | Elastic Beanstalk|  Amazon WorkSpaces |
| 可用性の確保の難易度 | 難しい | 中間 | 簡単 |

## まとめ

今回は「可用性」について解説しました。

可用性は普段はなかなか耳にするもの機会がないかもしれませんが、サービス提供の根幹を支える大切な概念です。どんなに素晴らしいサービスがあっても、利用者が利用したい時に使えなかったらその価値を提供することができません。

安定したサービスを提供するためにも可用性をしっかり理解し、サービスの開発を行っていきましょう。

可用性について解説しました。システムにおける可用性とは一体何なのか？初心者でもわかるように解説しております。

【わかりやすく解説】可用性とは？

# 【初心者入門】AWS Rekognitionでできること

## Amazon Rekognitionとは

こちらの記事では「Amazon Rekognition」について解説します。

Amazon Rekognitionとは、2016 年に開始されたクラウドベースのソフトウェアコンピュータービジョンプラットフォームサービスです。読み方は「リコグニション」で、識別、認識(英語だとrecognition)という意味です。数多く提供されているAWSのサービスの一つであり、深層学習を利用して画像と動画(ストリーミングを含む)を分析するAIクラウドサービスがこのAmazon Rekognitionにあたります。

通常画像やビデオの分析には、そのための機能やインフラを構築する必要があります。AWSが提供しているAmazon Rekognitionを利用することで、環境構築にかかる手間や費用を抑えつつ、素早くアプリケーションに画像や動画の分析機能を追加することが可能になります。

例えば、画像やビデオを検索し、その中に含まれているものやシーンを検出したり、顔認証を使ってユーザー認証したり、人物が個人用保護具を着用しているかなどの安全確認などに使用したり、ユースケースは多岐に渡ります。

## 顔認識とは

画像や動画の中から顔を検出したり、それが誰なのかを判別したりする機能のことです。AI(人工知能)の技術とビッグデータと呼ばれる膨大な情報により実現されています。

## Amazon Rekognitionの特徴

- 人の顔以外も識別可能
    
    Amazon Rekognitionでは上に挙げている顔認識以外にも、物体や概念(イベントや風景)、どんなものを身につけているかなど、様々なことを検出できます。カスタムラベル機能を使えば、新たなデータを学習させることができ、その結果を使って検出、認識させることが可能です。
    
- 専門知識が不要
    
    機械学習には統計学の知識が必要です。精度の高い解析を行うためには微分積分や線形代数、確率分布などの数学的な知識も必要とされます。Amazon Rekognitionはそういった高度な知識がなくても扱えるようなサービスになっています。
    
- 低コスト
    
    一般的に画像解析を行うには、カメラ、センサー、解析ソフトなどが必要です。これらの機材を導入するのは安くはなく、数百万かかる場合などもあります。Amazon Rekognitionは分析する画像の枚数、または動画の分数、また顔認識に保存するデータにのみコストが発生するのでコストを抑えて導入することができます。
    

## Amazon Rekognitionの料金体系

Amazon Rekognition では使用する機能によって、料金体系が決まっています。

- **画像分析**
    
    API を使用して1枚画像を分析するたびに料金が発生します。顔検索を使う場合、Amazon Rekognitionが一致を検索するための顔メタデータのリポジトリを保存する必要があり、このストレージ料金が月ごとに課金される仕組みになっています。
    
- **動画分析**
    
    APIで実行されたビデオ分析に対して、1分ごとに料金が発生します。顔検索を使う場合はイメージ分析と同様に、検索するためのデータを保存しておくストレージ料金が月ごとに課金されます。1 か月未満の料金は日割りで計算されます。
    
- **カスタムラベル**
    
    Rekognition カスタムラベルを使用する場合は、トレーニングが必要なので、トレーニングと認識処理のそれぞれについて課金されます。トレーニング時間は、データセットの画像枚数やラベル数などの要素によって変わります。
    

## Amazon Rekognitionの種類

Rekognitionには、画像を分析する用のAPIと、動画を分析するための2つのAPIが存在しています。

| 種類 | 内容 |
| --- | --- |
| Amazon Rekognition Image | 画像の解析を行うAPI |
| Amazon Rekognition Video | 動画の解析を行うAPI |

## Rekognitionで解析できること

| 種類 | 内容 |
| --- | --- |
| Labels(物体/ アクティビティの検出) | 物体（花や車など）や概念（結婚式などのイベントや風景）の検出 |
| カスタムラベル | ユーザーが画像データを準備して学習させることができ、その結果を利用してデフォルトで準備されていない画像を認識させることが可能 |
| 顔 | 人間の顔を検出 |
| 人物の動線 | 人間がどこをどう動いたかを追跡 |
| 個人用保護具 (PPE) | 人間が身につけている保護具（マスクやヘルメットなど）を検出 |
| 有名人 | 有名人の検出 |
| テキストの検出 | テキストの検出 |
| 不適切または不快なコンテンツ | 不適切なコンテンツ（暴力的なものなど）の検出 |

これらの種類を要件に合わせて活用していきましょう。

## 実際に使ってみよう

### 顔分析機能

こちらの画像を使って顔分析の機能を使用します。

![woman-1274056_1280.jpg](https://storage.googleapis.com/envader-article-images/reko-1.jpg)

1. コンソール内の画像アップロードエリアから上の画像をアップロードする。
    
    ![rekognition1.png](https://storage.googleapis.com/envader-article-images/reko-2.png)
    
2. 結果が表示される。（以下がその結果）
    
    ![スクリーンショット 2022-11-22 午後7.31.38.png](https://storage.googleapis.com/envader-article-images/reko-3.png)
    

結果で分析されている項目の一部

| 顔である | 99.9% |
| --- | --- |
| 女性であるか | 99.9% |
| 年齢はどれぐらいか | 21-29歳 |

### 顔比較機能

次は顔比較の機能を使ってみます。比較のためにこちらの2枚の写真を使用します。

![boy-717151_640.jpg](https://storage.googleapis.com/envader-article-images/reko-4.jpg)

![family-6475821_640.jpg](https://storage.googleapis.com/envader-article-images/reko-5.jpg)

1. コンソール内で2枚の写真をアップロードする
    
    ![rekognitionーcomparison.png](https://storage.googleapis.com/envader-article-images/reko-6.png)
    
2. 2枚の写真を比較した結果が出力される
    
    ![スクリーンショット 2022-11-22 午後7.45.38.png](https://storage.googleapis.com/envader-article-images/reko-7.png)
    

比較した結果、1枚目の男の子は2枚目の家族の写真の誰とも一致しないという結果になりました。

## まとめ

以上、Amazon Rekognitionについての紹介でした。

Amazon Rekognitionは、AWSの画像、動画分析サービスで、機械学習の専門知識がなくても使用できるように作られています。AWSであらかじめ準備されているトレーニング済みのAIを使用した分析を行なったり、またカスタムラベル機能を使用することでAIに新たな認識対象を学習させ、特定の商品やロゴなどの画像認識などを行うことも可能です。

Amazon Rekognition を用いることで手軽に画像や動画の分析を始められます。チャンスがあれば積極的に取り入れていきましょう。

こちらの記事では、AWSのRekognitionというサービスについて解説します。

【初心者入門】AWS Rekognitionでできること

# 【AWS】オブジェクトストレージAmazon S3の特徴とユースケース

Amazon S3とはAWS（**A**mazon **W**eb **S**ervice、以下AWS）が提供するサービスで、**S**imple **S**torage **S**erviceの3つのSからS3と呼ばれます。

S3はデータを格納・管理できるクラウド型のオブジェクトストレージサービスです。ファイル単位でのオブジェクトの出し入れができ、用途が自由・柔軟なデータ保存が可能で、例えるならGoogleドライブやiCloudのような用途ができます。

## S3の主な特徴

S3のさまざまな機能・できることを次に紹介します。

### **バージョン管理**

S3にはバージョニング機能があります。これはバケットのバージョン管理を設定すると「更新」「削除」といった操作のたびにバージョンが記録され、いつでもロールバックできる機能です。この機能のおかげで誤ってファイルを削除してしまった場合でも復元を行う事が可能です。

### 高いデータ耐久性

S3でオブジェクトを保存すると3つ以上のAZ（アベイラビリティーゾーン）間で複製、保存されます。この各AZは物理的に何マイルも離おり、火災や洪水などの災害が発生してもデータが守られる仕組みになっています。これにより99.999999999%（イレブンナイン）の耐久性が実現されています。

### 容量無制限のストレージ

S3には保存出来るデータ容量に上限がなく、無制限に使用する事が出来ます。使っているストレージの空き容量を気にする必要がなく、容量不足によるデータ整理を行う煩わしさから解放されます。使用の際はAWSのコンソール上でバケット（bucket）というデータを保存する入れ物を作成する事でデータの保存を行う事ができます。ただし、1つのバケットに保存出来るオブジェクト（ファイル）数は無制限ですが、1つのオブジェクトについては5TBまでという制限があるため注意が必要です。

### 低コストで使用可能

S3には初期費用がなく、保存されたデータ容量やデータ転送量により料金が決まる従量性から、必要最低限の料金で使用する事が可能です。頻繁に使用を行わないデータなどはデータアクセス頻度の低い用途に設計された低コストのストレージクラスを使用する事で更にコストを抑える事が可能です。また、データへのアクセスパターンに基づき、自動で低コストのストレージクラスへ移動するように**ライフサイクルポリシー**を設定する事も可能です。

## S3でできること3選

主な特徴を知ったところで、実際にAmazon S3を使ったユースケースを3つご紹介致します。

### 1.ストレージとしての使用

こちらはシンプルにストレージとしての活用です。
AmazonS3は容量無制限のため、使用中に容量不足によるデータ整理やストレージ増設などの心配がありません。また料金設定も使用した分だけ発生する従量課金制のため、様様なニーズに合わせて適切なコストで運用することができます。

主な使用用途は、オンプレミスで管理しているデータのバックアップとして使用したり、普段はあまり使用する機会のない企業の証跡書類など長期間保存を想定したアーカイブとして使用されます。

![https://storage.googleapis.com/envader-article-images/s3_usecase/01.png](https://storage.googleapis.com/envader-article-images/s3_usecase/01.png)

### 2.静的ウェブホスティング

Amazon S3には静的ウェブサイトのホスティング機能が備わっています。静的ウェブサイトとはリクエストに対してhtmlファイルや画像ファイル等の内容をそのままレスポンスとして返すサイトです。対して動的ウェブサイトは、リクエストに対してサーバーサイド側で処理が行われ、その結果をレスポンスとして返すサイトのことを指します。端的にいうとページを表示するためにログイン処理などが必要な場合は動的なサイトと言えます。

主な使用用途は、社内向けに公開するような静的サイトがあります。

![https://storage.googleapis.com/envader-article-images/s3_usecase/02.png](https://storage.googleapis.com/envader-article-images/s3_usecase/02.png)

### 3.イベント通知機能による他サービスとの連携

Amazon S3にはイベント通知機能があり、バケットで特定のイベントが発生した際に通知を行なってくれます。

例えば、バケット内に新しく画像をアップロードした場合はObjectCreatedというイベントが通知され、そのイベントをトリガーにAmazon Lambdaを実行しサムネイル画像を作成する事ができます。その他にもイベントをトリガーにAmazon SNS経由でSlackやメールに通知をしたりすることも可能です。

![https://storage.googleapis.com/envader-article-images/s3_usecase/03.png](https://storage.googleapis.com/envader-article-images/s3_usecase/03.png)

## ストレージクラスの種類

S3では様様な用途に合わせたストレージクラスが用意されており、保存期間やアクセス頻度に応じてクラスを選択する事でコストの最適化が行えます。

| 種類 | 用途 | データ取り出し費用 |
| --- | --- | --- |
| S3標準 | アクセス頻度が高い場合の汎用ストレージ。 | なし |
| S3 標準 – IA | アクセス頻度は低いがすぐにデータを取り出す場合のストレージ。保存されるAZは三箇所 | あり |
| S3 1 ゾーン – IA | アクセス頻度は低いがすぐにデータを取り出す場合のストレージ。保存されるAZは一箇所 | あり |
| S3 Intelligent-Tiering | アクセス頻度が不明、または変動する場合のストレージ。アクセス頻度によって自動的に費用対効果の高いクラスへ移動を行ってくれる。 | なし |
| S3 Glacier Instant Retrieval | データのアーカイブ用ストレージ。データ取得はミリ秒レベルで可能。 | あり |
| S3 Glacier Deep Archive | S3で最も安価なストレージ。1年に1〜2回しかアクセスしないようなデータ保存を想定されている。 | あり |

## 使用料金

S3の使用料金は基本使用量なしの従量課金性です。料金は6つの要素により決まります。

| 要素 | 説明 |
| --- | --- |
| ストレージ | バケットにオブジェクト（ファイル）を保存するための料金。容量や期間、ストレージクラスによって異なる。 |
| リクエストとデータ取り出し | バケットとオブジェクトに対するリクエストにかかる料金 |
| データ転送 | S3に出入りするすべての帯域幅にかかる料金 ※同じAWSリージョン内のS3バケット間で転送される場合など一部例外もあり |
| 管理と分析 | バケットで有効になっているストレージ管理機能と分析機能（ストレージクラス分析等）の料金 |
| レプリケーション | バケット間でオブジェクトを自動的にコピー出来るレプリケーションにかかる料金 |
| S3 Object Lambda | AWS Lambda関数を使用して、S3へのGETリクエストにプログラムコードを追加して、データを変更および処理できる機能を使う場合の料金 |

正確な料金を知りたい場合は、[AWS公式サイト](https://aws.amazon.com/jp/s3/pricing/)より料金の見積もり依頼を行う事が出来ます。

## まとめ

Amazon S3とはAWSが提供する、データを格納・管理できるクラウド型のオブジェクトストレージサービスです。

容量が無制限かつ高い可用性を実現しており、企業の規模や業種にかかわらず、世界中の多くの企業がデータの保存・活用にS3を利用しています。料金に関してもクライアントの使用用途に合わせた様様なストレージクラスが用意されており、使用した分だけ課金される従量課金制な点も魅力といえるでしょう。新規でAWSアカウントを作成した場合は1年間の無料枠が用意されているので、実際に使用してみて最適なストレージクラスを選択する事も可能です。

この記事では、実際にAmazon S3を使ったユースケースを3つご紹介致します。

【AWS】オブジェクトストレージAmazon S3の特徴とユースケース

# 【AWS】Amazon S3のストレージクラスの使い分けと選択のポイント

Amazon S3はデータを格納・管理できるクラウド型のオブジェクトストレージサービスです。

ファイル単位でのオブジェクトの出し入れができ、主にデータバックアップおよび復元、アーカイブやWebで使う静的なファイルをS3に置いて配信するなどさまざまなことに利用できます。用途に合わせた6つのストレージクラスが用意されており、保存期間やアクセス頻度に応じてクラスを選択する事でコストの最適化が行えます。

今回は各ストレージクラスの特徴などを解説します。

## なぜストレージクラスがあるのか？

端的に言うとデータ保管のコストを安くするためです。

保存するデータの用途や保存期間が異なります。例えば監査ログなどの年に一回使うか使わないかのデータはすぐに取り出せなくてもいいということもあります。そのようなデータはユーザーの立場からすると保管費用が安いほうが助かります。S3のストレージクラスはこのようなコストを安くするニーズに対応できます。

## ストレージクラスの種類

Amazon S3には様様な使用用途に合わせた6つのストレージクラスが用意されており、それぞれ機能や料金に違いがあるため詳しく説明を行います。

※料金は当記事作成時のものであり、変動する可能性があるため利用時は公式サイトにて確認をお願い致します。

### Amazon S3 Standard

アクセス頻度の高いデータ向けに高い耐久性、可用性、パフォーマンスを提供する汎用性の高いストレージクラスです。主な特徴としては3つのAZ*間で管理され99.999999999%（イレブンナイン）の耐久性を誇る事や低レイテンシーかつ高スループットなパフォーマンスが特徴です。

| 説明 | 料金 | データ取り出し料金 |
| --- | --- | --- |
| 50TBまで/月 | 0.025USD/GB | なし |
| 50TB以上450TB未満/月 | 0.024USD/GB | なし |
| 500TB以上/月 | 0.023USD/GB | なし |
- AZ（アベイラビリティーゾーン）とは1つのリージョン内の物理的に分離されたロケーションのことを表します。各リージョンで最小3つのAZで運用されており、各AZは物理的に何マイルも離れています。そのため、火災や洪水などでどれか1つのAZが被害にあっても分離された別のAZによりデータが保護されます。

### Amazon S3 Standard – IA

IA（**I**nfrequent **A**ccess）は低頻度アクセスという意味です。このストレージクラスの保管料金はStandardより安いですがデータを取り出す際に料金がかかります。S3 Standardと同じ機能を使用しつつ、データへのアクセス頻度が低い場合に適しています。

| 説明 | 料金 | データ取り出し料金 |
| --- | --- | --- |
| すべてのストレージ/月 | 0.0138USD/GB | 0.01USD |

### Amazon S3 One Zone – IA

S3 One Zone IAはよりコストを安くするソリューションです。最低3つのAZにデータを保存する他のS3ストレージクラスとは異なり、S3 One Zone - IAは単一のAZのみにデータを保存します。料金が安くなるかわりに冗長性が低下するため、コストと安全性がトレードオフになっています。

| 説明 | 料金 | データ取り出し料金 |
| --- | --- | --- |
| すべてのストレージ/月 | 0.011USD/GB | 0.01USD |

### Amazon S3 Intelligent-Tiering

S3 Intelligent-Tieringはクライアントのアクセス頻度に基づき「高頻度アクセス階層」「低頻度アクセス階層」「アーカイブインスタントアクセス階層」より、自動的にコスト効率の高いストレージ階層を選択してくれます。実際に使用を行なってみるまでアクセス頻度が分からない場合や、使用月によりアクセス頻度が変動する方に適したストレージクラスと言えます。

| 説明 | 料金 | データ取り出し料金 |
| --- | --- | --- |
| モニタリングおよびオートメーション、すべてのストレージ/月 (オブジェクト > 128 KB) | オブジェクト 1,000 件あたり 0.0025USD | なし |
| 高頻度アクセスティア、50 TBまで/月 | 0.025USD/GB | なし |
| 高頻度アクセスティア、50TB以上450TB未満/月 | 0.024USD/GB | なし |
| 高頻度アクセスティア、500TB以上/月 | 0.023USD/GB | なし |
| 低頻度アクセスティア、すべてのストレージ/月 | 0.0138USD/GB | なし |
| アーカイブインスタントアクセスティア、すべてのストレージ/月 | 0.005USD/GB | 0.033USD* |

※アーカイブアクセスティアで迅速な取り出しを行う場合のみ発生します。

### Amazon S3 Glacier Flexible Retrieval（旧 S3 Glacier）

データの取り出しに数分〜数時間かかってしまうため、すぐにアクセスする必要のない長期のデータアーカイブ向けのストレージクラスです。そのため料金設定が他と比べて低く設定をされています。ただし、データの取り出し費用は高くなるので頻繁に取り出さない運用が必要となります。

| 説明 | 料金 |
| --- | --- |
| すべてのストレージ/月 | 0.0045USD/GB |

S3 Glacier Flexible Retrievalではデータの取り出しスピードや条件により発生する料金が異なります。

| 条件 | データ取り出し料金 |
| --- | --- |
| 迅速なスピード | 0.033USD |
| 標準なスピード | 0.011USD |
| 大容量のデータ | なし |
| プロビジョニングされたキャパシティーユニット | ユニットあたり 110.00USD |

### Amazon S3 Glacier Deep Archive

S3のストレージクラスの中で最も低コストのストレージクラスであり、1年のうち1~2回しかアクセスされないようなデータを対象とした長期保存やデジタル保存を想定したストレージクラスです。データの取り出しに12時間以上かかるなどの制約があります。

| 説明 | 料金 |
| --- | --- |
| すべてのストレージ/月 | 0.002USD/GB |

S3 Glacier Deep Archiveではデータの取り出しスピードやデータ量により発生する料金が異なります。

| 説明 | データ取り出し料金 |
| --- | --- |
| 標準スピード | 0.022USD |
| 大容量のデータ | 0.005USD |

その他にも1000回毎のリクエスト料金やデータ転送料金など別途発生する料金があるため、詳しくは[AWS公式サイト](https://aws.amazon.com/jp/s3/pricing/?nc=sn&loc=4)をご覧ください。

## ストレージクラス別活用方法

以上の機能に基づいた各ストレージクラス別のユースケースは次のとおりです。

## Amazon S3 Standardの用途

アクセス頻度の高いデータ向けのストレージクラスであり、コンテンツ配信やAmazon Athenaを使用したビッグデータ分析などに利用できます。

### ユースケース

- 利用する目的でのデータ保管
- S3のバケットにHTMLファイルやCSSなどの静的ファイルを保存し、静的ウェブサイトホスティングを有効化すると静的ウェブサイトとして公開することも可能です。

## Amazon S3 Standard – IAの用途

基本的な機能はS3 Standardと同じですが、あまりデータへのアクセスを行わない場合はIAを選択することでStandardよりコストを抑えられます。ただしStandardと異なりデータの取り出し費用が別途発生するため、アクセスが多くなると逆にコストがかかることもあるため注意が必要です。

### ユースケース

あまりアクセスしないデータ保管、必要に応じてすぐにデータを取り出したい場合などに使用されます。

- データのバックアップ
- 災害対策ファイルのデータストア

## Amazon S3 One Zone – IAの用途

このストレージクラスはS3 Standard – IAと同じく、S3 Standardと同じ機能でありながらアクセス頻度が低い方向けのストレージクラスです。S3 Standard – IAとの違いは、通常保存されるAZが最低3つの所、S3 One Zone – IAでは単一のAZのみにデータが保存されます。そのため災害発生時などはデータが失われてしまう恐れがありますが、使用用途によってはS3 One Zone – IAを選択することでS3 Standard – IAより約20%コストの削減を行うことができます。

### ユースケース

- 容易に再作成可能なデータのセカンダリバックアップ
- オンプレミスデータのバックアップ

## Amazon S3 Intelligent-Tieringの用途

S3 Intelligent-Tieringはアクセスパターンが変化する際、4つのアクセスティア間でオブジェクトを移動して自動でコスト削減を行なってくれる唯一のストレージクラスです。アクセス頻度が不透明な場合や、使用用途によりアクセス頻度が変動してしまう場合におすすめです。

### ユースケース

アクセスパターンが予測できないコンテンツの配信などに使用するとその月のアクセス頻度によって自動的に適したアクセスティアに移動し、コストの最適化を行ってくれます。

## Amazon S3 Glacier Flexible Retrieval（旧 S3 Glacier）の用途

このストレージクラスはデータをあまり取り出す機会のない、アーカイブ向けのストレージクラスです。データの取得に1分〜12時間かかるため、すぐにアクセスする必要はないが長期的に大量のデータを保管したい場合に適しています。

### ユースケース

- 企業で保管している膨大なデータのバックアップ
- 災害対策のデータ保管用途
- 保存目的のログファイル

## Amazon S3 Glacier Deep Archiveの用途

このストレージクラスはS3 Glacier Flexible Retrievalよりも更に深いアーカイブデータ向けストレージです。ストレージ利用料金だけだとStandardと比較し、約96%低く設定されていますが、データの取り出し費用は低頻度アクセスのIAよりも高く設定されているため基本的に取り出さずに保管する用途に適しています。特徴として規制規定遵守要件を満たすため、7~10年以上データセットを保管する顧客のために設計がされており、金融サービスやヘルスケアなどの規制が厳しい業界が対象となっています。

### ユースケース

- 病院など規制要件を満たすために、患者の記録を何十年も保持する必要のあるデータ保管
- 会社の証跡書類など保管を目的としたデータの保存

## ストレージクラス選択時のポイント

ストレージクラスを選択する場合に重要となってくるのが**アクセス頻度**と**データの重要度**と**データ取り出しまでの許容時間**です。

まずはS3をどのような用途で使用したいかを明確にし、適したストレージクラスを割り出す参考としてフローチャートをお使いください。

![https://storage.googleapis.com/envader-article-images/s3_strage_class/01.png](https://storage.googleapis.com/envader-article-images/s3_strage_class/01.png)

## まとめ

Amazon S3には様様な使用用途に合わせた6つのストレージクラスが用意されており、目的に適したストレージクラスを選択する事により、コストの削減を行えます。ただしデータの取り出しに別途料金が発生したり、アクセス頻度によっても選択すべきストレージクラスが異なるため、誤ったクラスを選択してしまうと却ってコスト増加に繋がってしまう恐れがあるので注意が必要です。ストレージクラス選択時は使用用途を明確にし、最適なクラス選択を行えるようにするのがポイントとなります。前述のフローチャートを活用してください。

AWSアカウントを新規作成した方には1年間、S3 Standardを5GBまで利用できる無料枠があるので実際に使用してみると良いでしょう。

S3には様様な使用用途に合わせた6つのストレージクラスが用意されており、それぞれ機能や料金に違いがあるため詳しく説明を行います。

【AWS】Amazon S3のストレージクラスの使い分けと選択のポイント

# 【AWS】リレーショナルデータベースAmazon RDSの利点

## AWS RDSとは

Amazon RDS（**R**elational **D**atabase **S**ervice）とは、AWS（**A**mazon **W**eb **S**ervices）で使用できるリレーショナルデータベースサービスのことです。セットアップ、スケーリングなど保守・運用をAWS側が機能として提供しています。データベースはシステムにおいて可用性・耐障害性・高セキュリティが求められる非常に重要な要素ですが、開発者にとってその構築や運用、管理は容易ではありません。そんなデータベースの管理に必要な機能をAWSは提供しています。

## 特徴・利点

RDSには以下のような特徴があります。

- 構築、管理が簡単
- 可用性・耐久性
- 高速化・パフォーマンスの向上
- スケーラビリティ
- コスト効率の高さ
- セキュリティ

### 構築、管理が簡単

従来のオンプレミス環境でデータベースを構築しようとすると場所や機材の選定・確保やセキュリティの構築など莫大なコストがかかります。RDSを利用することで、MySQLやOracleといったDBエンジンの選択や保存容量などの必要な設定を行うだけで数分でデータベースを起動することができます。

### 可用性・耐久性

マルチAZ構成を選択することで**マスター（プライマリ）DB**と**スレーブ（セカンダリ）DB**が作成されます。スレーブDBとはマスターDBのバックアップのようなもので、マスターDBの変更を即座に反映（**同期レプリケーション**）することができます。万が一障害が起きた時はスレーブDBがマスターDBに昇格する**フェイルオーバー**を自動で行ってくれる機能がRDSにはあり、データベースの稼働を継続させることができます。また、スナップショットやトランザクションログの自動バックアップ機能もあります。このようにRDSは可用性・耐久性に優れています。

![RDS-01.png](https://storage.googleapis.com/envader-article-images/aws_rds/RDS-01.png)

### 高速化・パフォーマンスの向上

RDSは**リードレプリカ**を作成できます。**リードレプリカ**とは読み取り専用のデータベースのことです。マスターからレプリケーションされた読み取り専用DBを用意することで、大量に読み込みが行われるサービスにおいて負荷を軽減し、パフォーマンスを高めることができます。

![RDS-02.png](https://storage.googleapis.com/envader-article-images/aws_rds/RDS-02.png)

### スケーラビリティ

RDSは必要に応じてストレージを選ぶことができますが、もしも保存容量が足りなくなった際にはインスタンスタイプを変更するだけで簡単にスケールアップすることができます。また空き容量が少なくなってくると自動で増やしてくれるオートスケーリングを設定することもできます。

### コスト効率の高さ

RDSの料金体系は、使用した分だけ料金が発生する従量課金制です。さらに初期費用は無料で、使わなくなったデータベースは削除することで料金は発生しません。一年または三年で契約することで大幅な割引を受けられるリザーブドインスタンスという制度もあります。またデータベースの停止・起動が可能で常にデータベースを実行する必要がないため、開発・テスト用途でのデータベース使用もより経済的に行うことができます。サービスに最適な料金体系を選択できるコスト効率の高さはRDSの特徴です。

### 高いセキュリティ

RDSではアクセス制御や暗号化機能により指定されたユーザーのみがDBにアクセスできるようにすることが可能で、高セキュリティを実現しています。

## 料金の仕組み

RDSの料金体系は**インスタンスの起動時間**、**保存データ容量**、**データ転送量**に応じて決まります。起動時間料金はインスタンスタイプ・DBエンジンにより異なります。オートスケーリングを設定している場合はスケールアップにより料金が上がるため注意が必要です。保存しているデータ容量にかかる料金もストレージの種類・DBエンジンにより異なります。例えばMySQLの場合は以下のようになります。（※2022/12現在）インスタンスタイプの変更、AZ配置により時間料金が変動、ストレージタイプにより1GBあたりの料金が変動、さらにDBエンジンによっても料金が異なります。

|  | 料金 | タイプ |
| --- | --- | --- |
| 起動時間ごとの料金 | 1時間あたり0.208USD | db.t3.medium、マルチAZ |
| 保存データ容量ごとの料金 | 1ヶ月あたり0.276USD/GB | 汎用SSDストレージ、マルチAZ |

こちらの料金は定期的に変更されます。各DBエンジンの正確な料金は[AmazonRDSの公式サイト](https://aws.amazon.com/jp/rds/pricing/)にて確認してみましょう。

また、すでにOracleやSQL Serverなどの商用データベースを使用している場合はBYOL（**B**ring **Y**our **O**wn **L**icense）という自前のライセンスを持ち込むことができるプランも利用することができます。

## 種類

RDSで選ぶことができるデータベースエンジンは以下の通りです。

- Oracle
- MySQL
- MariaDB
- SQL Server
- PostgreSQL
- Amazon Aurora

### Oracle

Oracleはフルマネージド型のDBエンジンです。セットアップから運用、スケーリングまでRDSが管理できます。ライセンス込みもしくはBYOLRDSで実行可能です。RDSでは以下のバージョンに対応しています。（2022/12現在）

- Oracle Database 21c (21.0.0.0)
- Oracle Database 19c (19.0.0.0)
- Oracle Database 12c Release 2 (12.2.0.1)（サポート終了のため非推奨）
- Oracle Database 12c Release 1 (12.1.0.2)（サポート終了のため非推奨）

### MySQL

MySQLは世界で最も人気のあるオープンソースのDBエンジンです。操作がシンプルで開発規模の大小問わず幅広い場面で使用されています。RDSでは以下のバージョンに対応しています。（2022/12現在）

- MySQL 8.0
- MySQL 5.7

### MariaDB

MariaDBはMySQL5.5から派生したDBエンジンです。MySQLとの互換性の高さはもちろん、MySQLにはない新機能の追加や改善が行われているという特徴があります。RDSでは以下のバージョンに対応しています。（2022/12現在）

- MariaDB 10.6
- MariaDB 10.5
- MariaDB 10.4
- MariaDB 10.3（サポート終了予定のため非推奨）
- MariaDB 10.2（サポート終了のため非推奨）

### SQL Server

SQL Serverはフルマネージド型のDBエンジンです。Microsoft社開発でWindowsとの相性が良く、Windows環境でよく使われています。RDSでは以下のバージョンに対応しています（2022/12現在）

- SQL Server 2019 CU16 15.0.4236.7
- SQL Server 2017 CU30 14.0.3451.2
- SQL Server 2016 SP3 GDR 13.0.6419.1
- SQL Server 2014 SP3 CU4 12.0.6439.10

### PostgreSQL

PostgreSQLはMySQLに次いで人気の高いオープンソースのDBエンジンで、オブジェクト指向が取り入れられたオブジェクトリレーショナルデータベースです。RDSでは以下のバージョンに対応しています。（2022/12現在）

- PostgreSQL 14
- PostgreSQL 13
- PostgreSQL 12
- PostgreSQL 11
- PostgreSQL 10（サポート終了予定のため非推奨）

### Amazon Aurora

Amazon AuroraはAmazonが開発・提供するMySQLおよびPostgreSQLと互換性のあるRDS向け独自のDBエンジンです。標準的なMySQLに比べて**5倍**、標準的なPostgreSQLに比べて**3倍**の処理能力があります。また、リードレプリカを最大15個設置することができます。MySQLやPostgreSQLのリレーショナルデータベースとしての一貫性を持ちながら、リードレプリカ等クラウド向けに最適化された特徴があります。

### 無料枠

RDSには無料利用枠があります。**AWSのアカウントを新規で作成した日から12ヶ月間**、以下の条件で無料でRDSを利用することができます。

- MySQL、MariaDB、PostgreSQLの場合： Single-AZ db.t2.micro、db.t3.micro、db.t4g.micro インスタンスで750 時間/月
- SQL Server Express Editionの場合： Single-AZ db.t2.micro インスタンスで750 時間/月
- 20 GB の汎用 (SSD) DB ストレージ
- 20GBのスナップショットと自動バックアップ

## RDS proxy

**Amazon RDS Proxy**とは、RDS向けの高可用性フルマネージド型データベースプロキシです。プロキシとは「代理」という意味があり、RDS proxyはアプリケーションとRDSの中間に配置されてデータベースへの接続を効率化してくれます。特徴の一つとして、コネクションプールを確立・管理することで既存の接続を利用することができ、多数の同時接続による負荷の軽減を実現しています。またフェイルオーバー高速化によりデータベース障害に対する回復力と安全性が高くなっています。RDS proxyが対応しているDBエンジンはMySQL、PostgreSQL、SQL Serverです。

![RDS-03.png](https://storage.googleapis.com/envader-article-images/aws_rds/RDS-03.png)

## まとめ

Amazon RDSはデータベースの運用負荷を軽減できるサービスです。RDSを利用することでデータベース管理の負担は大幅に減ります。データベースエンジンの種類ごとの特徴を押さえ、またサービス・目的に応じたインスタンスタイプやストレージタイプ、オプションを選択することも必要です。マルチAZ構成、リードレプリカなどによる障害対策、性能対策を講じることも重要になってきます。AWSが提供する機能の内容や仕組みをしっかり押さえて最適なアーキテクチャを検討できるといいでしょう。

AWS（Amazon Web Services）で使用できるリレーショナルデータベースサービスのことです。

【AWS】リレーショナルデータベースAmazon RDSの利点

# 【徹底解説】サーバーレスサービスLambdaとは

Lambdaとはサーバーレスサービスです。サーバーレスとはサーバーを自身で管理する必要がなくなるということです。サーバーを管理するのはサーバーレスを提供しているクラウドサービスです。こちらの記事で詳しくサーバーレスについて解説していますのでご参照ください。

https://envader.plus/article/36

今回はサーバーレスサービス（FaaS）の一種Lambdaについて解説します。

## Lambdaとは

冒頭で記述した通りLambdaとはサーバレスサービスの一種です。具体的にLambdaは、プログラムを実行する環境を提供しているサービスです。サーバーなどの管理はAWSが管理するので利用者はプログラムだけに注力して開発することができます。

![https://storage.googleapis.com/envader-article-images/aws_lambda/01.png](https://storage.googleapis.com/envader-article-images/aws_lambda/01.png)

### なぜLambdaか？

Amazon EC2との違いはEC2は仮想サーバーで利用者はミドルウェアやアプリケーションサーバーなどのインストールしなければいけません。Amazon EC2はサーバーを利用している時間単位で課金計算されます。

その点、AWS Lambdaはプログラムを実行できる環境を提供しているのでソフトウェアのインストールを利用者が行う必要がありません。課金対象はプログラムを実行している時間で計算されます。

## Lambdaのメリット

- 保守、運用、管理の負担がない
- 従量課金制
- 自動スケーリング
- 様々なトリガーがある
- サポート言語が豊富
- カスタムランタイム

### 保守、運用、管理の負担がない

Lambdaは実行環境がAWSによって用意されるため、OSやフレームワークなどの保守は必要としません。サーバやミドルウェアの管理を自分ですることなく、サーバの運用もAWS側が負担するので保守、運用に手間がかかりません。

### 従量課金制

AWSは基本従量課金制でLambdaはリクエストがあった時間だけが課金対象となるため稼働中はずっとコストが生じるEC2インスタンスでの運用に比べて、無駄のないコスト運用ができます。

### 自動スケーリング

自動スケーリングは、負荷に応じてリソースを自動的に追加および削除できる機能です。 Lambdaでもリクエストに応じて自動でスケーリングします。リクエスト数に上限はありません。

### 様々なトリガーがある

Lambda関数の作成には追加料金はかかりません。また実行トリガーとなる関数も豊富なので様々な改善や障害に素早く対応できます。

![https://storage.googleapis.com/envader-article-images/aws_lambda/02.png](https://storage.googleapis.com/envader-article-images/aws_lambda/02.png)

### サポート言語が豊富

選択できるサポート言語も豊富にあります。一般的に使用されているプログラミング言語Java,Ruby,Pythonなど選択できます。サポートされていない言語も次で説明するカスタムランタイムという機能で使用可能になります。

![https://storage.googleapis.com/envader-article-images/aws_lambda/03.png](https://storage.googleapis.com/envader-article-images/aws_lambda/03.png)

### カスタムランタイム

AWS LambdaでいうカスタムランタイムとはLambdaでサポートされていない言語、すなわちどのプログラミング言語でも実装することができるということです。ランタイムは関数が呼び出されたときに Lambda 関数のハンドラメソッドを実行するプログラムです。関数のセットアップコードの実行、環境変数からのハンドラ名の読み取りLambda ランタイム API からの呼び出しイベントの読み取りを行います。そしてイベントデータを関数ハンドラに渡し、ハンドラからのレスポンスを Lambda に戻します。

AWS Lambdaでサポートされているランタイムと非推奨とされているランタイムを紹介します。（2022年12月現在）

| サポートランタイム | 非推奨ランタイム |
| --- | --- |
| Python 3.9 | Python 3.6 |
| Python 3.8 | Python 2.7 |
| Python 3.7 | .NET Core 2.1 |
| Ruby 2.7 | Ruby 2.5 |
| Node.js 16 | Node.js 10 |
| Node.js 14 | Node.js 8.10 |
| Node.js 12 | Node.js 4.3 |
| .NET Core 3.1 | Node.js 6.10 |
| .NET 6 | .NET Core 1.0 |
| .NET 5 | .NET Core 2.0 |
| Java 11 | Node.js 4.3 Edge |
| Java 8 | Node.js 0.10 |
| Go 1.x |  |

## Lambdaデメリット

- 実行時間上限が15分
- 同時実行数、実行時間の制限
- エラー解析が複雑
- Labda単体で使用できない

### 実行時間上限が15分（900秒）

Lambdaの実行時間は15分以内です。そのため、15分以上の時間がかかる処理を実行することができません。処理時間が15分以上にならないよう処理を分割して並列化する処理設計が必要です。とはいえ、並列化すると次に説明する**同時実行数**の制限に引っかかる可能性があるのでこの点も考慮しながら対応しなければなりません。

### 同時実行数、実行時間の制限

同時実行数とは1秒間に同時に実行することができる関数の上限のことです。例えば、Lambdaの場合、実行に10秒かかる関数が毎秒1件ずつ起動される場合は、最大の同時実行数が10となります。Lambdaでは上限値は同一アカウントの同一リージョン内で1,000までとなっています。上限に達すると、それ以上の関数の呼び出しは制限されます。

### エラー解析が複雑

ランタイムの大部分がLambda内部に隠蔽されているため、問題が発生した時の解析が難しくなります。

### Lambda単体で使用できない

Lambda関数を実行するには、他のサービスリソースで処理を起動させるきっかけとなるトリガーを設定する必要があります。

他のサービスリソース例

- Event Bridge

  AWSリソースの状態変化への対応に役立ちます。例えば、Lambda 関数を自動的に呼び出しEC2インスタンスの状態を記録することができます。

- Amazon S3 （Amazon **S**imple **S**torage **S**ervice）

  オブジェクトに関する詳細を含むイベントで関数を呼び出します。なのでオブジェクトを作成または削除するときに、イベントを Lambda 関数に送信できます。

- Amazon DynamoDB

  Lambda 関数を使用して、Amazon DynamoDBのレコードを処理します。DynamoDB テーブルが更新されるたびに追加の作業を実行することができます。

## サーバレスであるLambdaが解決する問題・課題

ITシステムのアジリティを向上させやすくなりコスト面、開発時間を踏まえて、新開発のチャレンジをしやすくなります。また自動でスケールされため、冗長化の考慮、対応などは最小限で済むようになります。なんといっても、サーバーの構築や運用、保守にかかる手間が不要となりサーバーダウンによる障害対応などが軽減されるので開発全体の負担が軽減になります。

### まとめ

今回はサーバーレスサービスであるLambdaについて紹介しました。Lambdaは、EC2インスタンスのような仮想サーバーを必要としません。プログラム実行環境は、AWSによって用意されます。そのため、サーバーの保守・運用をする必要がありません。また豊富なトリガーやサポート言語が用意されています。必要に応じてEC2インスタンスとLambdaをうまく利用して、より安くより良い方法で開発を進めていきましょう。

Lambdaは、プログラムを実行する環境を提供しているサービスです。

【徹底解説】サーバーレスサービスLambdaとは

# 【AWS】リージョンとAZについての詳しい解説

この記事では、クラウドサービスについてやデータセンターについての知識がある前提として、AWSにおける「リージョン」と「AZ」についての解説をしていきます。

## リージョンとは

英語では「地域」「範囲」などの意味で、クラウドサービスで利用するデータセンターの所在地のことを指します。データセンターが集まって置かれているエリアというイメージです。日本では、東京、大阪に存在します。

### リージョンの特徴

- リージョンごとに利用できるサービスが異なる
    
    世界中にあるリージョンごとに、利用できるAWSのサービスが異なります。同じ国内のリージョンでも利用できるサービスが異なるため、利用したいサービスが決まっている場合は、該当のサービスが利用できるリージョンを選びましょう。
    
- 障害発生時のリスク分散になる
    
    世界各国に複数のリージョンが設けられている理由の一つに、障害発生時にリスクを分散するという点があります。各リージョンは完全に分離され、他のリージョンに影響が及ばないよう設計されているため、障害が発生した場合、障害発生場所のリージョン以外には影響はありません。そのため、AWSサービスを安定して受けられます。
    
- リージョン間のデータ転送が可能
    
    各リージョンは完全に分離されるように設計されており、リージョンが独立しているのですが、AWSではリージョン間のAMIコピーやデータ転送が可能です。ただし、データ転送する際は別途料金が発生します。
    
- 利用できるリージョンが異なる
    
    アカウントにより、利用できるリージョンが決まります。AWSでは複数のリージョンを提供するため、要件に合った場所でAmazon EC2インスタンスを起動できます。例えば、ヨーロッパの顧客に近づけるため、または法的要件を満たすために、ヨーロッパでインスタンスを起動することができます。
    

## AZとは

アベイラビリティーゾーン（**A**vailability **Z**one）といい、1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている 1 つ以上のデータセンターのことです。たとえば東京リージョンには4つのAZがありますが、これらは「互いにすべて100km（60マイル）以内」「それぞれほかのAZから物理的に意味のある距離（数キロメートル）離れた場所」に配置されています。そのため、故障や不具合が起きた場合や、ネットワーク障害が発生した場合においても、別のAZに影響を与えることはありません。AZ外の影響を受けることなく、安定的に稼働を続けることが可能になります。また、AZは大きく分けて「シングルAZ」と「マルチAZ」の2種類が存在します。2022/12/21現在では、全世界の 30 の地域内にある 96 のAZが存在し、オーストラリア、カナダ、イスラエル、ニュージーランド、およびタイに 15 のAZと 5 か所の AWS リージョンを追加する計画が発表されています。

### シングルAZとは

1つのAZだけ使用してシステムを構築する仕組みを指します。

### マルチAZとは

システム構築において2つ以上のAZを用いる仕組みです。一般的にパブリッククラウドのサービスでは、マルチAZを推奨しているケースがよく見られます。

### シングルAZとマルチAZの違い

- 冗長化の可否
    
    シングルAZ構成では、稼働しているAZが停止した場合、その影響でシステム全体が停止してしまう可能性があります。障害が発生したときのリスクは高いといえるでしょう。
    
    対してマルチAZ構成は、複数のAZをまたいだシステムの冗長化を実現できます。例えば、本番用と予備用という2つのAZを作った場合、本番用AZが停止しても予備用AZに系統を切り替えられるため、システムを滞りなく稼働させることができます。
    
- 構成の複雑さ
    
    シングルAZは1つのAZだけで稼働させる分、サーバーやネットワークの構成が比較的シンプルです。一方、マルチAZは複数のAZを稼働させるので、場合によっては構成が複雑になってしまうかもしれません。
    
    また、マルチAZでシステムを構築した場合、通信速度やコストに悪影響が出てしまう可能性もあります。
    

## リージョンとAZの違い

AZもリージョンと同様に独立していますが、AZは互いに高速な通信線によって接続されており、この点がリージョンとは異なっています。また、同じリージョン内であればAZをまたいでデータを複製したり、別のAZのリソースを参照したりすることができるので、リージョンと比べてシームレスにデータやリソースを連携させることができる点もリージョンと異なっています。

![https://storage.googleapis.com/envader-article-images/aws_region_az/01.png](https://storage.googleapis.com/envader-article-images/aws_region_az/01.png)

障害への耐性については、複数のAZにリソースを配置することでもシステムの可用性を高めることができますが、リージョン全体へ影響する部分に障害が発生した場合にはそのリージョンに属する全てのAZに影響が及ぶ恐れがあります。耐障害性の観点では、同一リージョンの複数のAZでシステムを構成するよりも、複数リージョンでシステムを構成する方が、より高いと言えます。複数のAZと複数のリージョンのどちらか、もしくは、両方でシステムを構成するべきかについては、構築しようとするシステムのビジネス運営における重要性に応じて決定します。

## リージョンとAZの一覧

AWSが提供する**E**lastic **C**omputing **C**loud(EC2)のドキュメントでは、AWSアカウントで提供されるリージョンのリストが公開されています(2022/12/21現在)。また、リージョンごとのアベイラビリティーゾーンの数とマッピングは、AWS アカウント間で異なる場合があります。アカウントで使用可能なアベイラビリティーゾーンのリストを取得するには、Amazon EC2コンソールまたはコマンドラインインターフェイスで確認できます。

- 北米
    
    北米の AWS クラウドでは、7つの地理的リージョンに25 のアベイラビリティーゾーンがあります。
    
    | リージョン名 | AZ数 |
    | --- | --- |
    | バージニア北部 | 6 |
    | オハイオ | 3 |
    | 北カリフォルニア | 3 |
    | オレゴン | 4 |
    | 米国東部 | 3 |
    | 米国西部 | 3 |
    | 米国中部 | 3 |
- 南米
    
    南米の AWS クラウドでは、1つの地理的リージョンで3つのAZがあります。
    
    | リージョン名 | AZ数 |
    | --- | --- |
    | サンパウロ | 3 |
- 欧州、中東、アフリカ
    
    欧州、中東、アフリカの AWS クラウドでは、11つの地理的リージョンに 33 のAZがあります。
    
    | リージョン名 | AZ数 |
    | --- | --- |
    | バーレーン | 3 |
    | フランクフルト | 3 |
    | ロンドン | 3 |
    | パリ | 3 |
    | ストックホルム | 3 |
    | ミラノ | 3 |
    | チューリッヒ | 3 |
    | スペイン | 3 |
    | バーレーン | 3 |
    | アラブ首長国連邦 | 3 |
    | ケープタウン | 3 |
- アジアパシフィック（中国含む）
    
    アジアパシフィック （中国含む） の AWS クラウドには、11つの地理的リージョンに 35 のアベイラビリティーゾーンがあります。
    
    | リージョン名 | AZ数 |
    | --- | --- |
    | 香港特別自治区 | 3 |
    | ムンバイ | 3 |
    | ソウル | 4 |
    | シンガポール | 3 |
    | シドニー | 3 |
    | 東京 | 4 |
    | 大阪 | 3 |
    | 北京 | 3 |
    | 寧夏 | 3 |
    | ジャカルタ | 3 |
    | ハイデラバード | 3 |

## まとめ

AWSにおけるリージョンとAZについて解説してきました。2022/12/21現在では総リージョン数30、総AZ数92とかなりの数がありますが、まだ15のAZと5か所のAWS リージョンの増加が予定されています。AWSを使用するにあたって必要な基礎知識であると思いますので、少しでも理解を深めていただければと思います。

この記事では、クラウドサービスについてやデータセンターについての知識がある前提として、AWSにおける「リージョン」と「AZ」についての解説をしていきます。

【AWS】リージョンとAZについての詳しい解説

# 【図解あり】Amazon S3バージョニング機能を用いる理由

Amazon S3にはバージョニングという機能があります。このバージョニング機能はバケット内のオブジェクトの複数のバージョンを 1 つのバケットに保持し、誤って削除または上書きしてしまった場合でもオブジェクトの復元を行える機能です。バージョニング機能の有効化を行うと、バケット内の一部ではなくすべてのオブジェクトを対象にバージョンの作成が行われます。

## バージョニング機能を使う目的

バージョニング機能を用いない場合、データの上書きや削除などの人的ミスやアプリケーション側の不具合が発生した場合にデータを保護する事ができません。主な対策として作業のたびにクライアント自身でバックアップを作成する方法がありますが、作業のたびに行うのは大変手間であり、バックアップのためのストレージ容量の確保や管理なども必要でした。

Amazon S3のバージョニング機能を用いることでクライアント側は特別な操作を行うことなく、自動的にシステム側でバージョンの作成を行なってくれるため（マネージドサービス）、ストレージ容量の心配や手動によるバージョン管理の手間を省くことができます。

## バージョニング機能の特徴

バージョニング機能の主な特徴や仕組みを解説していきます。

バージョニング機能はデフォルトでは**Unversioned**（以下、無効）に設定されており、バージョニング機能は一度**Versioning-enabled**（以下、有効）にすると無効にすることはできませんが、**Versioning-suspended**（以下、停止）を行うことができます。また、バージョニング機能を有効にすることで、復元だけでなくオブジェクトの取得にバージョンを指定して行う事ができます。

例えば、画像データなどで加工を終えたあとに加工前の画像データが必要になった場合などにアップロードしたバージョンを遡り取得を行う事ができます。

### バージョニング機能が無効な場合

バージョニング機能が無効な場合、全てのオブジェクトは**現行**のバージョンとして扱われます。この場合バージョンIDは**null**となります。バージョニング機能が無効な状態でオブジェクトを削除するとデータは完全に削除されてしまいます。

![https://storage.googleapis.com/envader-article-images/s3_versioning/01.png](https://storage.googleapis.com/envader-article-images/s3_versioning/01.png)

### バージョニング機能が有効な場合

バージョニング機能を有効にすると**現行**のバージョンだけでなく、**過去**のバージョンも保持され各オブジェクトは1つの現行バージョンと0個以上の過去のバージョンを持つことになります。過去のバージョンが作成される主なケースとして同一名称のオブジェクトがputされた時や現行のオブジェクトが削除された時に作成されます。

![https://storage.googleapis.com/envader-article-images/s3_versioning/02.png](https://storage.googleapis.com/envader-article-images/s3_versioning/02.png)

## バージョニング機能の使い方

バージョニング機能の使い方として**バージョンの復元**と**削除マーカー**について説明します。

### バージョンの復元

過去のバージョンを復元したい場合は復元したいバージョンのコピーを行う方法と現行のバージョンを削除する方法があります。

復元したいバージョンのコピーを行った場合は現行のバージョンが繰り下げ式に過去のバージョンとなり、新しくコピーされたバージョンが現行のバージョンとなります。コピーしたバージョンへは新たなバージョンIDが付与され、コピー元のバージョンはそのまま維持されるため、同じ内容のデータを持つバージョンが二つ存在する事になります。現行のバージョンを削除する方法だと繰り上げ式に過去のバージョンが繰り上がり、現行のバージョンとなります。

![https://storage.googleapis.com/envader-article-images/s3_versioning/03.png](https://storage.googleapis.com/envader-article-images/s3_versioning/03.png)

### 削除マーカーによる論理削除

バージョニング機能を有効にしているバケットでオブジェクトの削除を行なってもオブジェクトは削除されず、代わりにAmazon S3により削除マーカーが挿入されます。この削除マーカーはオブジェクトが削除されたかのような論理削除を行います。この論理削除は物理削除とは異なり、完全にデータの削除が行われた訳ではないため削除マーカーを削除することで過去のバージョンの復元を行えます。この削除マーカーを削除する場合は**バージョンIDの指定**が必要で、指定をせずにオブジェクトの削除を行うと新たな削除マーカーが挿入されます。また、注意点として現行のバージョンが削除マーカーの場合は**コピーによる復元**を行えません。

![https://storage.googleapis.com/envader-article-images/s3_versioning/04.png](https://storage.googleapis.com/envader-article-images/s3_versioning/04.png)

## まとめ

バージョニング機能とはバケット内のオブジェクトに対して複数のバージョンを保持することにより、誤ってデータの削除や上書きを行った場合でもデータの復元ができる機能です。

これまではクライアント側でバックアップを取ったりといったデータ保護のための対策を講じないといけなかったことが、バージョニング機能を用いることで簡単に行うことができます。また、データの復元だけでなく任意のバージョンを取得することも可能になるため、変更前のデータの取り出しを行うことも簡単にできます。

Amazon S3を使用する際にデフォルトではバージョニング機能は無効となっているため、この機会に是非有効に設定し、バージョニング管理を行なってみましょう。

バージョニング機能はバケット内のオブジェクトの複数のバージョンを 1 つのバケットに保持し、誤って削除または上書きしてしまった場合でもオブジェクトの復元を行える機能です。

【図解あり】Amazon S3バージョニング機能を用いる理由

# 【AWS】Amazon S3イベント通知の活用法

Amazon S3（以降、S3）にはイベントを通知してくれる機能が備わっており、S3バケットで特定のイベントが発生したときにAWSの他のサービスに通知することが出来ます。SNSのトピック・SQSのキュー・Lambda関数に送信することが可能で、それを元にさまざまな処理を行うことができます。

AWSのチュートリアルなどで例としてよく挙げられるのがS3にアップロードされた画像ファイルをのサムネイル画像を作成する処理です。この例だと、**ObjectCreate**というイベントが発生した際に通知され、その通知をトリガーに**Lambda関数**を呼び出して実行しています。

## 何のためのイベント通知？

サービスの自動化を目的としています。画像やファイルのアップロードや変更をトリガーに別の処理を実行することで実現可能です。

### イベント通知の種類

現在S3では次のイベントの通知を行うことができます。

- New object created events
- Object removal events
- Restore object events
- Reduced Redundancy Storage (RRS) object lost events
- Replication events
- S3 Lifecycle expiration events
- S3 Lifecycle transition events
- S3 Intelligent-Tiering automatic archival events
- Object tagging events
- Object ACL PUT events

### イベントの通知先

現在Amazon S3ではAmazon **S**imple **N**otification **S**ervice (以降、SNS) Amazon **S**imple **Q**ueue **S**ervice(以降、SQS) AWS Lambda（以降、Lambda）の3つのサービスへイベントを通知することができます。

## Amazon SNSを活用

バケットへのオブジェクトアップロードや削除など、なんらかのイベントが発生した際にログなどの通知を受け取りたい場合があります。SNSを用いることでそれらの通知をメールやコミュニケーションツールなどに送信することができます。

### Amazon SNSとは

Amazon SNSとは、モバイルプッシュ通知やSMS送信など様々なメディアに対応したフルマネージド型メッセージングサービスです。SNSでは以下の形式に対応しています。

- HTTP
- HTTPS
- Email
- Email (JSON)
- Amazon SQS

### SNSのユースケース

バケット内にオブジェクトを作成した際に**Object created**イベントが発生します。そのイベントをトリガーにSNSへ通知を行い、SNSからメールやSlackなどのコミュニケーションツールへ送信を行うことができます。

![https://storage.googleapis.com/envader-article-images/s3_event_triger/01.png](https://storage.googleapis.com/envader-article-images/s3_event_triger/01.png)

## Amazon SQSを活用

SQSについてお話をする前に、まずはメッセージキューイングについて説明を行います。

メッセージキューイングとは、異なるシステム間でデータを送受信する際に直接データを渡すのではなく一度第三者のシステムに預けることで、送信側も受信側も好きなタイミングで送受信処理をおこなうことができるようにする方式のことを言います。

通常システム間でのメッセージングは同期的に行われます。しかし同期的なメッセージングでは受信側の状態に問題があった場合、送信側のシステムが処理できないまま停止（スタック）してしまいます。ですがこのメッセージキューイングを用いることで送信側は受信側の状態に左右されずにメッセージを送信し、元の作業に戻ることができるため、システムの可用性を高めることができます。

![https://storage.googleapis.com/envader-article-images/s3_event_triger/02.png](https://storage.googleapis.com/envader-article-images/s3_event_triger/02.png)

### Amazon SQSとは

SQSとはフルマネージド型のメッセージキューイングサービスです。
SQSには**標準キュー**と**FIFOキュー**の2種類のサービスが存在し、両者の主な違いは次のとおりです。

| 機能 | 標準キュー | FIFOキュー |
| --- | --- | --- |
| メッセージの順序 | 送信されたときと異なる順序で配信されることがある | 送信または受信された順序が厳密に保持される |
| 配信回数 | 少なくとも 1 回は確実に配信されるが、重複することがある | 正確な 1 回の配信が行われ、重複することはない |
| TPS | 1秒あたり無制限 | 1秒あたり300 |

### SQSのユースケース

アプリケーション間の連携に用いられ、疎結合を実現できます。

通常システム間を直接繋ぐ同期的な連携の場合、受信側で問題が発生した場合は送信者側の機能もスタックしてしまいます。ですが、SQSを間に挟むことで受信者側に問題が発生しても送信者側の機能はそのまま維持され、送信されたメッセージはキューに留まるため問題が解消された場合は処理を再開することができます。

### Amazon SNSとAmazon SQSの違い

SNSは受信者の状態に関わらずメッセージを送信するプッシュ式で、SQSは受信者側がSQSをポーリングし、キューがあれば取得を行います。

![https://storage.googleapis.com/envader-article-images/s3_event_triger/03.png](https://storage.googleapis.com/envader-article-images/s3_event_triger/03.png)

## Lambdaを活用

Lambdaは単体で使用することはできず、その他のサービスと連携し、Lambdaを呼び出すことで処理を行えます。

まずはLambda 関数を設定します。関数を設定するにはLambda コンソールやLambda APIなどを使用して関数のコードを作成し、デプロイパッケージを使用してコードをアップロードします。
その後連携しているサービスによるイベントをトリガーに、Lambda が関数を呼び出し処理を行います。

### Lambdaのユースケース

S3バケット内にログなどのHTMLファイルをアップロードすると**ObjectCreate**イベントが発生します。そのイベントをトリガーにLambdaが呼び出され、あらかじめ設定をしておいたLambda 関数を基にログを見やすい文へ修正し、別のS3バケットへ戻すといった使い方ができます。

### AWS Lambdaとは

AWS Lambda（以降、Lambda）とは、サーバレスコンピューティングサービスです。

利用者はサーバーやOSなどのインフラ管理が不要で、プログラムコードを準備しLambdaにアップロードするだけでプログラムの実行が行えます。主な特徴にオートスケーリング機能などがあります。この機能はアクセス数や負荷に応じて自動的に利用するサーバーの数を増減します。これによって、ユーザーはサーバを意識することなくプログラムを実行することができます。

現在Lambdaは次の言語に対応しています。

- Java
- Go
- PowerShell
- Node.js
- Closes#
- Python
- Ruby

また、Custom Runtimeを使用する事で次の言語を使用することもできます。

- Erlang
- Elixir
- COBOL
- N|Solid
- PHP
- Closes++

その他のユースケースとして冒頭で少し触れたようにS3とLambdaを連携するとS3への動作をトリガーにLambdaを呼び出し、あらかじめLambdaにコーディングしていた処理を行うことができます。

例えば写真共有アプリケーションを例にするとユーザーがアプリケーションを使用し、写真をアップロードします。その写真をアプリケーションがS3のバケット内に格納し、**ObjectCreate**イベントが発生したのをトリガーに、Lambdaを呼び出します。呼び出されたLambdaはコードを基に画像のサムネイルを自動作成し、別のバケットへ格納するといったことができます。

![https://storage.googleapis.com/envader-article-images/s3_event_triger/04.png](https://storage.googleapis.com/envader-article-images/s3_event_triger/04.png)

## まとめ

イベント通知とはS3バケットで特定のイベントが発生した通知を元に他のAWSサービスと連携することを指します。

S3を単体でストレージとして使用するだけでなく、このイベントトリガーを上手く活用する事でその他のサービスと連携を行い、通知を受け取ったりオブジェクトの加工や処理を行うことができます。利便性の向上や作業の効率化、コストの最適化をおこなうことができるため積極的にイベントトリガーを使用していきましょう。

S3バケットで特定のイベントが発生したときにAWSの他のサービスに通知することが出来ます。

【AWS】Amazon S3イベント通知の活用法

# 【AWS】Amazon S3で静的ホスティングする理由

Amazon S3（以降、S3）にはS3バケット内にputされたHTMLなどのオブジェクトを用いて、サーバレスでWebページをホスティングして公開する機能が備わっています。

今回はS3の注目機能である静的ホスティングについて、導入する理由や主な使用用途について解説を行います。

## なぜS3で静的Webサイトをホスティング？

理由は、極めて低コストだからです。

企業HPや広告ランディングページは動的な要素は必ずしも必要はなく、静的なファイルを表示できればよいのであまり高機能なWebサーバーを必要としません。ReactでビルドしたSPAなども静的なものでS3での静的ホスティングが適しています。これらは静的ホスティング機能を有効化するだけで簡単に実現できます。

### 本当に安い

一番の理由として料金の安さがあります。料金は従量課金制のため容量・リクエスト数・データ転送量によって異なりますが、デフォルトで選択されるS3 Standardの場合は以下になります。

| 説明 | 料金 |
| --- | --- |
| ストレージ利用料 （最初の 50 TB/月） | 0.025USD/GB |
| 1000リクエスト（GETの場合） | 0.00037USD |
| インターネットへのデータ転送（最初の 10 TB/月） | 0.114USD/GB |

月間PV数が1万程度のサイトを例にすると

- データ容量：1GB = 0.025USD
- リクエスト数：15 × 10,000PV ÷ 1,000 × 0.00037USD =0.0555USD
- データ転送量：2MB × 10,000PV = 20GB（20GB × 0.114USD）= 2.28USD

合計：0.025USD + 0.0555USD + 2.28USD = 2.3605USD

月間1万PV数だとひと月あたり2.3605USDで日本円で約317円でWebサイトを公開することができます。
※解説時のレートのため変動する場合があります。

### 高い可用性

S3は3つ以上のアベイラビリティーゾーン（以降、AZ）で保護されています。

このAZとは1つのリージョン内での物理的に分離されたロケーションを表しており、クライアントがアップロードしたデータは3つのAZに分けて保存がされます。そのため火災や洪水などの災害発生時に1つのAZがダウンしても残りのAZでデータが保護され、高可用性を実現します。

これにより静的Webサイトをホスティングした場合もサーバダウンなどによりサイトが停止してしまう可能性が極めて低く、安定した配信を行えます。

### サーバレスによる手軽さ

通常自社サーバを用いてWebサイトを作成する場合はサーバの構築や運用に莫大なコストや人的労力が必要になります。

一時的にアクセス数が増加した場合はサーバダウンしてしまう恐れや、アクセス数が継続的に増える場合はサーバ増設などコストも発生します。ですが、Amazon S3を用いることでこれらのサーバ管理を全てAWSへ任せることができ、利用者は手軽にWebサイトを運用することが可能になります。

## 静的Webサイトと動的Webサイトの違い

そもそもAmazon S3でホスティングが行える静的Webサイトとは何か、動的Webサイトとどう違うのかについて解説を行います。

### 静的Webサイトとは

静的WebサイトとはHTMLファイルなどで作成された、誰がいつどこでアクセスしても毎回同じものが表示されるWebページのことです。ユーザーの要求に対してWebサーバが要求されたデータをそのままブラウザに送信を行って表示します。そのためサーバ側での処理の必要がなく、ページ表示までのスピードが速いため、ユーザーの離脱などが抑えられます。

![https://storage.googleapis.com/envader-article-images/s3_static_hosting/01.png](https://storage.googleapis.com/envader-article-images/s3_static_hosting/01.png)

### 動的Webサイトとは

動的Webサイトとはアクセスしたときの状況に応じて異なる内容が表示されるWebページのことです。会員制のサイトやショッピングサイトなど、使う人によって違うページが表示されるサイトは動的Webサイトと言えます。

例えば、検索エンジンではユーザーの検索ワードを基にWebサーバが検索処理を実行し、HTMLファイルを作成します。その後Webブラウザに送信することでユーザーの入力した検索ワードに対して最新の検索結果情報を提供することができます。

![https://storage.googleapis.com/envader-article-images/s3_static_hosting/02.png](https://storage.googleapis.com/envader-article-images/s3_static_hosting/02.png)

## 主なユースケース

Amazon S3を用いた静的Webサイトとして以下のような使い方ができます。

### 企業HP

自社を紹介するHPなど、アクセスするユーザーに対して同じ内容のページを表示したい場合に適しています。企業HPなど長期的に利用をする場合にAmazon S3を使用することでコストを抑えて運用が行えます。

### 社内向けサイト

こちらは一般公開するのではなく、社内Wikiや通達など社内の従業員向けにサイトを公開したい場合に使えます。一般公開する場合と違い、急激なアクセス数の増加なども少ないため低価格で運用が行えます。

### ランディングページ（LP）

商品やサービスなどを紹介するランディングページでは高い可用性が求められます。ユーザーがアクセスをしてきた際にページが表示されなかったり、急激なアクセス数の増加によりサーバがダウンしてしまうとお客様を獲得するチャンスを失います。ですがAmazon S3では99.99%のオブジェクトの可用性が提供されているため、高可用性を求められるランディングページなどに向いています。

### SPAの配信

SPA（**S**ingle **P**age **A**pplication）は単一のページで構成されるWebアプリケーションです。動的なデータはAPIサーバーから取得するため、Reactなどで開発したSPAは静的ファイルを配信するだけで済みます。代表的な例だとGoogleMapやSlackのWebページなどはSPAが採用されています。

## まとめ

静的Webサイトをホスティングする際に、自社サーバを使用するとサーバの構築から管理まで多くの費用と時間がかかり、レンタルサーバを利用する場合にはコストを抑えた運用が難しくなります。

しかし、Amazon S3を用いる事で**可用性の高い**静的Webサイトを**手軽**に尚且つ**コストを抑えて**作成することができます。長期的に運用を行う企業のHPや高可用性が求められるランディングページなどを作成する場合には是非Amazon S3を用いてホスティングしてみましょう。

今回はS3の注目機能である静的ホスティングについて、導入する理由や主な使用用途について解説を行います。

【AWS】Amazon S3で静的ホスティングする理由

# AWS初心者がまず理解すべきVPCを徹底解説

## VPCとは

![00.jpg](https://storage.googleapis.com/envader-article-images/vpc/00.jpg)

Amazon **V**irtual **P**rivate **C**loud（Amazon VPC）は、アマゾンがAWS上で提供している機能の1つで、AWS上に作成できる仮想ネットワークです。このネットワーク空間に、任意のIPアドレスを設定することが可能で、パブリックやプライベートとしてネットワークを分離したり、仮想サーバーを外部のインターネットに接続して、Webサーバーとして機能させたりできます。加えて、ネットワーク環境を活用するための、ルーターやゲートウェイといったネットワーク機器もAmazon VPCの中で仮想化し利用できます。また、Amazon VPCは、1つのリージョンの中に作成し、複数のアベイラビリティゾーン（AZ）に展開します。

## VPCを構成する要素

一般的なIPネットワークを構築するには、サブネット、ルートテーブル、IPの指定、固定IPといった機能と、ルーター、ゲートウェイといった機器が必要です。Amazon VPCには、これらに対応するコンポーネントが用意されていて、コンソール上で組み合わせることで目的のネットワーク環境を構築することができます。各コンポーネントを紹介します。

### Subnet（サブネット）

IPネットワークを構築するにはIPアドレスが必要ですが、サブネットはVPC内にIPアドレスの範囲を設定できる機能です。1つのVPC内に複数のサブネットを設定できます。仮想サーバーなどのコンピューティングリソースは、このサブネットの中に設置します。また、サブネットには２種類あり、インターネットに接続が出来る・出来ないかで呼び名が変わります。

- パブリックサブネット：インターネットに接続できるサブネット
- プライベートサブネット：インターネットに接続できないサブネット

この二つの呼び方はVPCを学ぶ上で良く出てくるので、覚えておくと便利です。

### IGW（インターネットゲートウェイ）

サブネット内にある仮想サーバーなどのリソースを、インターネットと通信できるようにする機能です。VPCを設定すると、デフォルトで含まれていて、VPCにアタッチして利用します。

### Route Table（ルートテーブル）

ルートテーブルは、ネットワークトラフィックの経路を判断する際に使用される、ルートと呼ばれる一連のルールで、例えばインターネットを介してVPCに入ってくるデータが、どのような経路で仮想サーバーに到達するかの経路を示します。VPC内部にルートテーブルを用意し、サブネットごとに使うルートテーブルを指定します。

### Elastic IP（静的IPアドレス）

Amazon EC2にて作成した仮想サーバーをインターネットと接続するには、インターネットからアクセスできるパブリックなIPアドレスが必要です。IPアドレスには、システムを再起動するたびに変更されるものと、永続的に同じIPアドレスを使える、静的IPアドレスがあります。ファイアウォールやアクセス制限のためにIPアドレスを固定したい場合は、静的IPアドレスを使います。IPアドレスには、IPv4とIPv6という２種がありますが、現在はIPv4のみに対応しています。

### NATゲートウェイ

VPC内のサブネットで、インターネットと接続しないリソースは、通常プライベートサブネット内に設定します。しかし時にはソフトウェアの更新などで一時的にVPC内からインターネットに送信したい場合があります。その際には、プライベートサブネットからインターネットに接続できるNATゲートウェイを使うと便利です。NATゲートウェイでは、VPCからインターネットに送信できますが、逆はできないので安心です。NATゲートウェイは、プライベートIPアドレスをパブリックIPアドレスに変換できる機能を有します。

### Endpoints for S3（VPCエンドポイント）

サブネット内のインスタンスから他のAWSサービスに接続したいときに使用します。例えば、プライベートサブネット内のEC2からS3やDynamoDBに接続したい時にエンドポイントを使用します。外部のインターネットを経由しなくても接続出来るため、高いセキュリティで接続することが可能です。

## VPCのセキュリティ・監視

AWSではセキュリティやコンプライアンスに関して、AWSとユーザーが責任を負う部分を明確にして、両者で責任を負う「責任共有モデル」という考え方を導入しています。Amazon VPCに関しても同様で、AWS側で対応するセキュリティについては、Amazon EC2インスタンスやサブネットへのファイアウォール機能や、NATゲートウェイなどVPCのコンポーネントの監視や問題発生時のレポート機能などがあります。

### 責任共有モデルとは

AWSにおいて構築されるシステムのセキュリティとコンプライアンスについては、AWSとユーザーの両者がその責任を負うという考え方です。AWSは、AWSのクラウドサービスを実行する、ハードウェア、ソフトウェア、ネットワーキングといったインフラストラクチャの保護について責任を負います。ユーザーの責任は、選択したAWSサービスによって異なります。Amazon EC2を選択した場合は、ゲストOS、インスタンスにインストールしたソフトウェア、ファイアウォールの構成などがユーザーの責任になります。

### セキュリティグループ

セキュリティグループとは、VPC内でのAmazon EC2インスタンスに入出力するデータのトラフィックを管理することができる機能です。セキュリティグループにおいて、入力と出力の管理ルールは個別に設定できます。ルールは許可のみサポートされています。インスタンスには最大５つのセキュリティグループを割り当てられ、インスタンスごとに異なるものを割り当てることもできます。インスタンス起動時にセキュリティグループを設定しないと、VPCのデフォルトのセキュリティグループが自動的に割り当てられます。

### ネットワークアクセスコントロールリスト（ネットワークACL）

ネットワークACLとはセキュリティに関連した機能で、VPC内のサブネットに入出力するデータのトラフィックを管理することができる機能（オプションレイヤー）です。ネットワークACLにおいて、入力と出力の管理ルールは個別に設定できます。ルールは許可と拒否がサポートされています。明示的にネットワークACLを設定しないと、VPCのデフォルトのネットワークACLが関連づけられます。

### VPCフローログ

VPCフローログとは、VPCのデータトラフィックを監視する機能です。VPC内のネットワークインターフェイスとの間のIP トラフィックに関する情報をキャプチャできます。VPCフローログを取るには、ログを作成したいリソース、キャプチャするトラフィックの種類（許可、拒否、もしくはすべてのトラフィック）、フローログデータを発行する送信先（Amazon CloudWatch LogsまたはAmazon S3）を設定します。VPCフローログを参照すると、セキュリティグループのルールの制限が厳しすぎないか、適切かなどの判断が容易になります。

### Amazon VPC トラフィックミラーリング

Amazon VPC トラフィックミラーリングとは、Amazon VPC内のAmazon EC2インスタンスからのネットワークトラフィックを複製し、そのトラフィックをセキュリティおよび監視アプライアンスに転送できる機能です。これによってコンテンツ検査、脅威の監視、トラブルシューティングといった作業が容易になります。

### Amazon CloudWatch によるNATゲートウェイのモニタリング

Amazon CloudWatchを利用すると、NATゲートウェイを監視することができ、収集した情報からリアルタイムに近い読み取り可能なメトリクスを得ることができます。メトリクスは「NATゲートウェイ経由の同時アクティブTCP接続の合計数（0なら接続がないと判断可能）」「NATゲートウェイによって受信された送信先からのバイト数（データ損失の可能性を判断可能）」など14種あります。

### Amazon VPC IP Address Manager

Amazon VPC IP Address Managerは、大規模なネットワークでも、簡単にIPアドレスの整理、割り当て、モニタリング、監査を行える機能です。単一の運用ダッシュボードから、組織のアカウント、Amazon VPC、AWSリージョンにまたがってIPアドレスの割り当てを管理できます。従来スプレッドシートで行っていたIP管理の負荷を大幅に低減できます。

リージョンについてはこちらの記事で詳しく説明しています。

[https://envader.plus/article/61](https://envader.plus/article/61)

## VPCの料金について

Amazon VPCを作成し使用することは無料です。ただし、NATゲートウェイなど、オプションのVPC機能を利用した場合、量ベースで課金されます。東京リージョンでの各オプション料金を紹介します。

### NATゲートウェイ

NATゲートウェイを利用した場合、データトラフィックが送信か受信かにかかわらず、データ量で課金されます。処理データ1GBあたり0.062USDです。また接続していた時間に関しても課金されます。1時間あたりのNATゲートウェイ利用料金は0.062USDです。1時間未満は1時間分になります。

### トラフィックミラーリング

ネットワークの分析に使えるトラフィックミラーリングも有料です。トラフィックミラーリングが有効になっているEC2インスタンスのElastic Network Interfaceに対して1時間ごとに、0.018USDが課金されます。1時間未満は1時間分になります。

### IP Address Manager

**IP** **A**ddress **M**anager（IPAM）の利用も有料です。IPAMで管理するアクティブなIPアドレスごとに、1時間単位で、0.00027USD課金されます。例えば、1000個のIPアドレスを1ヶ月利用すると、1000 x 30日 x 25時間 x 0.00027USD＝194.4USDになります。

## VPCの設定例

Amazon VPCを構築してAmazon EC2インスタンスを設置し外部のインターネットと接続するといった流れを、VPC環境のイメージ図を添えて紹介します。Amazon EC2インスタンスを設置した場合、Amazon EC2インスタンス上にデータベースを構築した場合、NATゲートウェイを使った場合などのAmazon VPC環境を紹介します。

### Amazon EC2インスタンスの設置

Amazon EC2インスタンスを設置する場合は、

1. リージョンを指定
2. その中でVPCを作成
3. サブネットを作成するAZを指定
4. パブリックサブネットの設定
5. インターネットゲートウェイをVPCにアタッチする
6. ルートテーブルを作成する
7. ECインスタンスを設置

という流れで実行します。

イメージ図は、以下のようになります。

![vpc-ec2.png](https://storage.googleapis.com/envader-article-images/vpc/vpc-ec2.png)

### データベースの設置

Amazon EC2インスタンスで利用するデータベースを設置します。

1. リージョンを指定
2. その中でVPCを作成
3. サブネットを作成するAZを指定
4. パブリックサブネットの設定
5. インターネットゲートウェイをVPCにアタッチする
6. ルートテーブルを作成する
7. ECインスタンスを設置
8. プライベートサブネットの設置
9. データベースの設置

という8と9の手順が加わります。

プライベートサブネット内のデータベースはパブリックサブネット内のEC2インスタンスとデータのやり取りは行いますが、インターネットとは接続されていません。

イメージ図は、以下のようになります。

![vpc-detabase.png](https://storage.googleapis.com/envader-article-images/vpc/vpc-detabase.png)

### NATゲートウェイを利用

プライベートサブネット内に設置されたAmazon EC2上のデータベースは、本来インターネットと接続されていませんが、何らかの理由や任意のタイミングでインターネットとデータをやり取りしたい場合、NATゲートウェイを利用します。その場合は

1. NATゲートウェイをパブリックサブネット内に設置
2. NATゲートウェイとインターネットゲートウェイを接続

という手順を踏みます。

イメージ図は、以下のようになります。

![vpc-nat.png](https://storage.googleapis.com/envader-article-images/vpc/vpc-nat.png)

## VPCの設定方法

VPCウィザードというVPCの初期設定を簡単に設定出来る機能を使って、パブリックサブネットとプライベートサブネットを作成していきます。

### 1.VPC設定画面へ移動

AWSコンソールにログインしたら、左上の検索窓を選択。

検索窓にVPCと入力したら、候補に出て来た「VPC」をクリック。

![VPC1.png](https://storage.googleapis.com/envader-article-images/vpc/VPC1.png)

### 2.VPCウィザードを起動

VPCダッシュボードに移動したら、左上の「VPCを作成」をクリック。

![VPC2.png](https://storage.googleapis.com/envader-article-images/vpc/VPC2.png)

### 3.VPCウィザードでの設定

1. 今回はパブリックサブネットとプライベートサブネットを作成するので、「VPCなど」を選択
2. 任意の名前を入力
3. マルチAZ配置にするかどうかを設定
4. 任意のアベイラビリティゾーンを選択
5. 任意のパブリックサブネットの数を選択
6. 任意のプライベートサブネット数を選択
7. 任意のパブリックサブネットCIDRブロックを設定
8. 任意のプライベートサブネットCIDRブロックを設定
9. NATゲートウェイを設置する際はここで設定します。
10. VPCエンドポイントを設置する際はここでS3ゲートウェイを設定します。
11. 各設定が完了したら、VPCを作成をクリック

![vpc-setting3.png](https://storage.googleapis.com/envader-article-images/vpc/vpc-setting3.png)

![vpc-setting4.png](https://storage.googleapis.com/envader-article-images/vpc/vpc-setting4.png)

### 4.VPCウィザードでの設定完了

すべて成功になれば作成完了です。

![VPC5.png](https://storage.googleapis.com/envader-article-images/vpc/VPC5.png)

## まとめ

AWS VPCについて解説しました。VPCはインターネットとの接続を管理する事が出来るとても大事なAWSサービスです。AWSを触ったことがないという方は、言葉だけで覚えようとしてもなかなか理解するのは難しいので、簡単な構成で良いので実際にVPCを構築してみてはいかがでしょうか。

アマゾンがAWS上で提供している機能の1つで、AWS上に作成できる仮想ネットワークです。

AWS初心者がまず理解すべきVPCを徹底解説

# 【AWS】徹底解説EC2 利用するメリットや作成方法について

この記事では、クラウドサービス、データセンター等の基本的な知識がある前提でAWSを利用する際によく聞く「EC２」に関して機能やメリットなどを解説します。

## Amazon EC2とは

Amazon EC2は、**A**mazon **E**lastic **C**ompute **C**loud(EC2)の略称で、Amazonが提供する「仮想サーバサービス」です。利用者は数分でサーバを作成でき、作成後のマシンスペック変更や削除も簡単に実行できます。たとえば、サーバ上で稼働しているアプリケーションが高負荷となりCPUやメモリが不足した場合は、インスタンスタイプを変更することでスペックの増強が可能です。またデータ量が多くなってディスク容量が不足になった場合もすぐに拡張が可能です。従量課金であり、EC2はサーバが起動している時間に対して利用料が発生します。使用しない場合は停止しておくことで利用料を削減できます。時間あたりの単価はインスタンスタイプにより異なります。高スペックなインスタンスタイプほど高料金となりますので、あまりリソースを使用していないサーバがあれば、スペックの低いインスタンスタイプに変更することで利用料を削減できます。サーバを停止していた場合も、データを保存しているEBS（Amazon Elastic Block Store ：EC2におけるストレージの役割）に対しては料金が発生するため注意しましょう。なお、リザーブドインスタンスやSavings Plansについては、利用者が事前に決定したキャパシティ（使用時間やマシンスペック）に対して利用料を支払います。

## EC2を利用するメリット

### 1. 構築時間が短縮できる

EC2上でインスタンスを立ち上げる時間は数分あれば十分です。一方でサーバーを購入する場合は、購入してから受け取って利用できるまでに時間がかかります。

### 2. 冗長化が簡単にできる

ネットワークを仮想ネットワークとして構築するサービスが提供されており、インスタンスと組み合わせることによって、簡単かつ短時間でサーバーの冗長化が可能です。ローカルの場合はサーバーの設定だけではなく、ネットワークの設計も必要になります。

### 3. 柔軟にスペックの変更が出来る

データベースサーバーを長年運用しているとデータは増え続けていくので、データの保持には増設が必須となります。EC2では、画面上でハードディスクやメモリの増設を簡単に行うことが出来ます。

## EC2インスタンスとは

AWS上で稼働する仮想サーバのことを指し、仮想サーバを数える際の単位としても使われます。AWSでは仮想サーバのCPUやメモリなどの組み合わせがインスタンスタイプとして定義されています。必要なスペックに応じたインスタンスタイプを選択し、OS、ストレージ容量などを決定してインスタンスを作成します。また、インスタンスの負荷状況に応じて自動的にインスタンスをスケールアウト（台数増）／イン（台数減）することが可能なオートスケーリングなど、用途に合わせた柔軟な運用が可能です。

### インスタンスタイプ

サーバのスペック（CPU、メモリ）は、インスタンスタイプを選択することにより決定します。インスタンスタイプのネーミングは以下のようになっています。

![ec2-0.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-0.png)

- インスタンスファミリー
    
    メモリ重視やCPU重視など、特徴ごとにファミリーがあります。主要なものとして以下のようなものがあります。
    
    | 種類 | 特徴 | ファミリー |
    | --- | --- | --- |
    | 汎用 | バランスが取れている | T、M、A、Mac |
    | コンピューティング最適化 | 計算パフォーマンスが高い | C |
    | メモリ最適化 | メモリ量が多くて高速 | R、X、z |
    | 高速コンピューティング | CPUが搭載されている | P、G、F、Inf |
    | ストレージ最適化 | ストレージアクセスが速い | I、D、H |
    
    ファミリー詳細
    
    - T：CPUバースト可能
    - M：様々な場面で利用できる
    - A：Armプロセッサ搭載
    - Mac：Apple Mac mini搭載
    - C：計算パフォーマンスが高い
    - R：メモリ最適化
    - X：最大メモリ量が大きい
    - z：高周波なコア搭載
    - P：汎用GPU搭載
    - G：グラフィックスに最適化
    - F：FPGAカスタマイズ可能
    - Inf：機械学習推論に最適化
    - I：NVMe SSD搭載でI/O性能高い
    - D：最大48TBのHDD搭載
    - H：高ディスクスループット
    
    コンピューティング最適化ではvCPUの数がおおくなっており、メモリ最適化ではメモリ搭載量がおおくなっています。その間のバランスを取ったファミリーがM系やT系です。T系インスタンスについてはベースラインと呼ばれる決められたCPU使用率が定義されており、それを超えて利用が可能です。ただし一定量を超えるとベースライン以下の性能になるか、追加課金が発生するため、本番環境など常時使用が見込まれる環境はM系のインスタンスを選択した方が良いでしょう。
    
- インスタンス世代
    
    世代は比較的わかりやすい概念かと思いますが、数が大きいほど新しい世代です。世代の新しいほうが高性能かつコスト効率も良いため、可能な限り最新世代のインスタンスを選択することが推奨されます。
    
- 追加機能
    
    追加機能には色々と種類があり、追加機能文字が存在しないインスタンスタイプもあります。
    
    - a：AMDのCPUを搭載
    - b：EBSパフォーマンスが高い
    - d：インスタンスストア（内蔵ストレージ）を追加
    - e：CPUやメモリ搭載量が異なる
    - g：AWS Gravitonプロセッサ（Arm ベースのプロセッサ）搭載
    - n：ネットワーク強化
    - z：高周波なコア搭載
- インスタンスサイズ
    
    CPU、メモリ、ネットワーク帯域がサイズにより変わり、「nano」「micro」「medium」「small」「large」「xlarge」「2xlarge」のようにサイズが大きくなっていきます。当然サイズの大きいほうが高スペックとなりますが、料金も高額となるため選択には注意が必要です。最初は小さいサイズを選択しておき、性能テストなどで必要なサイズを後から決定するほうが最適なサイズを選びやすいです。
    
- 現在利用可能なインスタンスタイプ
    
    
    | 特徴 | インスタンスタイプ |
    | --- | --- |
    | 汎用 | M5、M5a、M5ad、M5d、M5dn、M5n、M5zn、Ｍ6a、Ｍ6g、Ｍ6gd、M6i、M6id、T3、T3a、T4g |
    | コンピューティング最適化 | C5、C5a、C5ad、C5d、C5n、C6a、 C6g、 C6gd、C6gn、 C6i、C6id 、Hpc6a |
    | メモリ最適化 | R5、R5a、R5ad、R5b、R5d、R5dn、R5n、R6a、 R6g,R6gd、 R6i、R6id、u-3tb1.56xlarge、u-6tb1.56xlarge、u-6tb1.112xlarge、u-9tb1.112xlarge、u-12tb1.112xlarge、 X2gd、 X2idn、X2iedn、X2iezn、z1d |
    | ストレージ最適化 | D3、D3en、I3en、I4i 、Im4gn 、Is4gen |
    | 高速コンピューティング | DL1、 G4、G4ad、G5、G5g、 Inf1、 p3dn.24xlarge、P4 、VT1 |
    
    ベアメタルインスタンス（GPUベースのもの）
    
    | 特徴 | インスタンスタイプ |
    | --- | --- |
    | 汎用 | m5.metal、m5d.metal、m5dn.metal、m5n.metal、m5zn.metal、m6a.metal、m6g.metal、 m6gd.metal、 m6i.metal、m6id.metal |
    | コンピューティング最適化 | c5.metal、 c5d.metal、c5n.metal、c6a.metal、 c6g.metal、 c6gd.metal、 c6i.metal、c6id.metal |
    | メモリ最適化 | r5.metal、r5b.metal、r5d.metal、r5dn.metal、r5n.metal、r6a.metal、 r6g.metal、 r6gd.metal、 r6i.metal、r6id.metal、u-6tb1.metal、u-9tb1.metal、u-12tb1.metal、u-18tb1.metal、u-24tb1.metal、 x2gd.metal、 x2idn.metal、x2iedn.metal、x2iezn.metal、z1d.metal |
    | ストレージ最適化 | i3.metal、i3en.metal、i4i.metal |
    | 高速コンピューティング | g4dn.metal、g5g.metal |

## マシンイメージ（AMI）

使用できるOSとしては、下記のようなものがあります。

- Amazon Linux
- CentOS
- Red Hat Enterprise Linux
- Windows Server

AMIは誰でも公開できるものなので、インスタンス起動時にAMIを選択する際は信頼できる提供元のものを使うことが推奨されます。

## EC2の関連サービス

EC2には大きく分けて5つの関連サービスが用意されています。これらを使うことで、より複雑なインフラ構築が可能になります。

### イメージ（AMI）

サーバーのイメージを保管しておくところです。しばらく使わないけれど、以前構築したサーバーのイメージを取っておきたい場合などに利用します。

### EBS（Elastic Block Store）

サーバー上に保存したデータを保管しておくサービスで、外付けハードディスクのようなイメージです。EBSはAWS EC2で作成したインスタンスを停止させる場合に使います。インスタンスはハードディスクのような保存媒体が存在しないため、EBSを使ってデータ保存環境を用意する必要があるのです。

### ネットワーク＆セキュリティ

文字通り仮想ネットワークの構築やセキュリティグループIDに割り振る権限などをコントロールします。AWS EC2ネットワーク＆セキュリティの使い方ですが、Elastic IPという固定IPを作成するサービスを使うことが多いです。通常、EC2インスタンスは固定IPを持たないため、インスタンスを再起動するとIPアドレスが変わってしまいます。そのためサーバーとして利用するためには、Elastic IPにより固定IPを設定する必要があります。

### ロードバランシング

ロードバランサを設定するサービスです。ロードバランサとは、複数のサーバーに適切にアクセス負荷が分散されるようにする仕組みのことです。

### Auto Scaling

Auto ScalingはAWS EC2のインスタンス数を、自動的に増減させることができるサービスです。CPU使用率、アクセス負荷によるトラフィック量の増大に応じて、自動的にインスタンス数を増やすことができます。また、不要になったインスタンスは自動的に削除されるので、必要以上にインスタンスが増えることはありません。

## Amazon EC2の料金

AWSの利用料は「使った分だけ払う・従量課金」が基本で、Amazon EC2も同様です。初期費用もありませんし、無償Linuxは秒単位、Windowsなら1時間単位で支払い料金が変わります。料金は、以下の4つの要素で決まります。

- インスタンスの使用料
- EBSの費用
- 通信費用
- オプションの費用

EC2インスタンスを停止すればインスタンス使用料はかかりませんが、Amazon EBSの費用は発生するなど、利用状況に応じて費用の発生状況は異なります。そのためAWSでは、月ごとの請求金額の確認機能、一定金額を超えたらアラートが出る機能、必要なスペックを入れると利用料を見積もってくれるサービスなどが用意されています。また、EC2の料金体系は大きく3つに分かれます。

- オンデマンドインスタンス
    
    サーバが稼働している時間の料金が発生する料金体系です。使わない時間は料金が発生しないので、固定費の削減につながります。先に料金を支払う必要はなく、あくまでも使った分だけ料金が発生する仕組みです。短時間使用したい場合におすすめの料金体系といえます。
    
- リザーブドインスタンス
    
    あらかじめ使用するキャパシティを予約する料金体系です。長期の契約になりますが、その分オンデマンドインスタンスより大幅な割引価格で使用することができます。使用量が多い場合や長期間稼働しないといけない場合はリザーブドインスタンスがおすすめです。
    
- スポットインスタンス
    
    スポットインスタンスは、先に挙げたものよりも特殊な料金体系です。AWS上にすでに存在し放置されているインスタンスを格安利用料で使う方式です。通常はインスタンスを利用する場合、自分で設定したインスタンスを稼働させるのですが、スポットインスタンスの場合は他人のインスタンスを利用します。
    

## EC2の作成手順

EC2の作成の前に以下を作成しておく必要があります。

- VPC
- サブネット
- ルートテーブル
- インターネットゲートウェイ
- セキュリティグループ

VPCについてはこちらの記事で詳しく解説しています。

https://envader.plus/article/76

### 1. EC2コンソールへ移動

AWSコンソールにログインしたら、左上の検索窓を選択。

検索窓にEC2と入力したら、候補に出て来た「EC2」をクリック。

![ec2-1.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-1.png)

### 2. EC2インスタンスの管理画面へ移動

左側の「インスタンス」をクリック。

![ec2-2.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-2.png)

### 3. EC2インスタンスを作成する

EC2インスタンスの管理画面の右上の「インスタンスを起動」をクリック。

![ec2-3.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-3.png)

### 4. EC2インスタンスの設定

EC2インスタンスを以下のように設定していきます。

1. 名前：任意の名前
2. アプリケーションおよびOSイメージ：任意のOSとAMIを選択
3. インスタンスタイプ：任意のインスタンスタイプを選択
4. キーペアの作成
    1. キーペア名：任意の名前
    2. キーペアのタイプ：RSA
    3. プライベートキーファイル形式：.pem
    4. 「キーペアを作成」をクリック
    
    ![ec2-5.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-5.png)
    
5. VPC：2-1で作成したVPC
    
    サブネット：2-1で作成したサブネット
    
    パブリックIPの自動割り当て：有効化
    
    ファイアウォール（セキュリティグループ）：既存のセキュリティグループ
    
    共通のセキュリティグループ：作成したセキュリティグループ
    
6. ストレージ：ディフォルトのまま
7. 「インスタンスを起動」をクリック

![ec2-4.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-4.png)

![ec2-6.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-6.png)

![ec2-7.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-7.png)

### 5. EC2インスタンスの作成完了

これでEC2インスタンスの作成が完了です。

![ec2-8.png](https://storage.googleapis.com/envader-article-images/amazon-ec2/ec2-8.png)

## まとめ

AWSの代表的サービスであるEC2について基礎的な内容を解説しました。EC2を用いれば、容易に仮想サーバの立ち上げが可能ですが、EC2を作成するには、VPC、サブネット、ルートテーブル、インターネットゲートウェイ、セキュリティグループの作成が事前に必要でした。EC2はAWSの中でも非常によく使われるサービスであるので、この機会に無料枠を使ってEC2を作成してみてはいかがでしょうか。

この記事では、クラウドサービス、データセンター等の基本的な知識がある前提でAWSを利用する際によく聞く「EC２」に関して機能やメリットなどを解説します。

【AWS】徹底解説EC2 利用するメリットや作成方法について

# Amazon CodeWhispererの特徴とは？VSCodeへの導入方法と合わせて解説

2023年4月13日、Amazon版のGitHub Copilotと呼べる**Amazon CodeWhisperer**(**コードウィスパラー**)が正式に発表されました。様々なIDE(統合開発環境)を利用して開発することが可能なAmazon CodeWhispererですが、今回はVSCodeへの導入方法と、CodeWhispererの使い方について解説します。

GitHub Copilotについては、別の記事にて解説しています。

[https://envader.plus/article/138](https://envader.plus/article/138)

今回の記事は、**2023年4月時点**での内容となるため、時期によっては料金等の変更がある可能性があります。詳細は[公式ページ](https://aws.amazon.com/jp/codewhisperer/)を参照してください。

## Amazon CodeWhispererとは

Amazon CodeWhispererとは、オープンソースリポジトリやAmazon内部のリポジトリ、APIドキュメントなどから収集した数十億行のソースコードを機械学習させ、自動でコードを生成および提案してくれるサービスです。

> Get more done faster
CodeWhisperer is trained on billions of lines of code and can generate code suggestions ranging from snippets to full functions in real time based on your comments and existing code. Bypass time-consuming coding tasks and accelerate building with unfamiliar APIs.

Amazon CodeWhisperer公式ページより引用

以下は翻訳した文章です。

「より速く、より多くのことを成し遂げる
CodeWhispererは、数十億行のコードで訓練され、あなたのコメントと既存のコードに基づいて、スニペットから完全な関数までのコード提案をリアルタイムで生成することができます。時間のかかるコーディング作業を回避し、馴染みのないAPIを使ったビルドを加速させます。」

公式ページの冒頭で説明されている通り、開発者は自分の実現したい内容のコメントか、ソースコードの一部を書くだけでAIがその続きのソースコードを提案してくれるというとても魅力的なサービスとなっております。

### 個人であれば無料で利用できる

気になる料金体系は、無料で利用できる個人開発用のIndividual版と、組織レベルでの利用方法を管理したい方向けのProfessional版があります。2023年4月現在、Professional版は1ユーザーあたり1ヶ月19$(**日本円で約2542円**)で利用が可能です。

## CodeWhispererのサポートランタイム

2023年4月の時点で発表されいている利用可能な言語は以下になります。

| Python | TypeScript | Rust | Kotlin | シェルスクリプト |
| --- | --- | --- | --- | --- |
| Java | C# | PHP | C | SQL |
| JavaScript | Go | Ruby | C++ | Scala |

IDE(統合開発環境)については、VS CodeやJetBrains社が提供するIntelliJ IDEAやPyCharmなどに加え、AWS Cloud9やAWS Lambdaコンソールでも利用可能です。

## セキュリティスキャン機能

> Enhance code security
Scan your code to detect hard-to-find vulnerabilities, and get code suggestions to remediate them immediately. Align to best practices for tackling security vulnerabilities, such as those outlined by Open Worldwide Application Security Project (OWASP), or those that don't meet crypto library best practices and other similar security best practices.

Amazon CodeWhisperer公式ページより引用

以下は翻訳した文章です

「コードセキュリティの強化
コードをスキャンして見つけにくい脆弱性を検出し、すぐに修正するためのコード提案を受けることができます。Open Worldwide Application Security Project（OWASP）が概説するような、セキュリティ脆弱性に取り組むためのベストプラクティスに合わせるか、暗号ライブラリのベストプラクティスやその他の同様のセキュリティベストプラクティスに合わせないか。」

ソースコードを提案してくれるのはもちろん、コードをスキャンして脆弱性を検出し、さらにはそのコードを改善するための提案まで行ってくれる機能まで備えています。

また、オープンソースのコードと似たコードになっている場合にはフラグを立て、警告する機能も備えているため、オープンソースのコードを気付かないままコピーしていた、といったケースを防ぐこともできます。

## VS Codeへの導入方法

ここからVS Codeへの導入方法を解説します。すでにAWSアカウントを持っている前提で進めます。

```bash
# 今回実施した環境
MacOS Ventura 13.2
VS Code 1.77.3
```

### 拡張機能 AWS Toolkit for Visual Studio Codeをインストール

VS Codeを開いたら、以下の画像のように拡張機能をクリックし、AWS Toolkitをインストールします。

![Amazon_CodeWhisperer-1.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-1.png)

インストールが完了したら、左側のサイドバーにawsのアイコンが表示されるのでクリック。CodeWhispererのタブを開き、AWS Builder IDを作成するためUse a personal〜を選択します。

![Amazon_CodeWhisperer-2.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-2.png)

AWS Builder IDとは、開発者一人一人に紐づく個人プロファイルで、Amazon CodeWhispererやAmazon CodeCatalystなどを利用する際に必要になるIDになります。詳細は以下より確認することができます。

[Sign in with AWS Builder ID](https://docs.aws.amazon.com/ja_jp/signin/latest/userguide/sign-in-aws_builder_id.html)

次に、以下の画面が表示されるので印の部分をクリックします。クリックすると、request:の右側にあるコードがコピーされます。

![Amazon_CodeWhisperer-3.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-3.png)

以下の画面へ遷移するので、先ほどコピーしたコードを貼り付け、Nextをクリック。

![Amazon_CodeWhisperer-4.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-4.png)

次の画面より、メールアドレスを入力して次へ進みます。

![Amazon_CodeWhisperer-5.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-5.png)

AWS Builder IDで使用する名前をYour nameへ入力して次へ進みます。

![Amazon_CodeWhisperer-17](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-17.png)

認証コードが登録したメールアドレスへ送信されるので、内容を確認して認証コードを入力します。

![Amazon_CodeWhisperer-7.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-7.png)

新しいパスワードを作成して、AWS Builder IDを作成します。

![Amazon_CodeWhisperer-8.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-8.png)

VS CodeのデータへAWS Toolkitがアクセスして良いか聞かれるので、Allowを選択します。

![Amazon_CodeWhisperer-9.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-9.png)

以下の画面が表示されれば設定完了です。万が一上の画面が表示されなかった場合には、最初からやり直してみましょう。

![Amazon_CodeWhisperer-10.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-10.png)

ここまで完了したら、VS Codeへ戻りAmazon CodeWhispererを試してみます。

## Amazon CodeWhispererを使ってみる

実際にVS Codeを使用してAmazon CodeWhispererを体験します。今回は実験用のディレクトリを作成し、ファイルを作成して実行しました。

### 基本的な操作

VS Codeを使用する場合、基本的な操作は以下の通りです。

| 挙動 | キー操作 |
| --- | --- |
| コードを提案させる | mac (option + c), windows (Alt + c) |
| 別の候補を出力する | 矢印キー(左 or 右) |
| 提案されたコードを採用する | Tabキー |

コメントを日本語か英語で書くだけで、CodeWhispererが自動的に補完をしてソースコードの候補を表示してくれます。自動的に候補を表示するのを待ちたくない場合には、macでは**option + c**、windowsでは**Alt + c**を押すことで意図的に候補を表示させることが可能です。

### Pythonでfizz buzzを実行するプログラムを書いてもらう

Pythonでfizzbuzzを出力するプログラムを書いてもらいます。今回は簡単なプログラムだったため、提案されたものをそのまま実行するだけで問題なく動作しました。

以下のようにコメントを入力します。関数のdefを入力した段階でoption + cを入力すると、候補を出力してくれます。

![Amazon_CodeWhisperer-18.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-18.png)

この状態でoption + cを入力する。

![Amazon_CodeWhisperer-12.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-12.png)

このままTabキーを押すことで、この候補を採用することができます。本当にTabキーを押していくだけでどんどん提案されていくため、コードを書く必要が最小限になります。

![Amazon_CodeWhisperer-13.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-13.png)

以下のようなソースコードが完成しました。

![Amazon_CodeWhisperer-14.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-14.png)

実行できるか確かめてみます。

![Amazon_CodeWhisperer-15.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-15.png)

きちんと動くことが確認できました。私が行ったことは、1行目のコメントを入力したのみです。そのあとは、Tabキーを押すだけしか行わず、このようなソースコードが完成しました。

### コピーの抑止機能(Reference Log)

Amazon CodeWhispererは、ソースコードを提案するだけではなく、提案したコードがオープンソースのコードを事実上コピーしていないかを確認してくれる機能があります。この機能により、自動で提案してくれるソースコードがうっかりコピーしているものだった、ということを防ぐことができます。

VS Codeでは、以下のターミナルにあるREFERENCE LOGの所から確認することが可能です。

![Amazon_CodeWhisperer-16.png](https://storage.googleapis.com/envader-article-images/code-whisperer/Amazon_CodeWhisperer-16.png)

## まとめ

Amazon CodeWhispererは、Amazonが開発し、機械学習により自動でコードを生成および提案してくれるサービスです。候補を表示するまでに若干のタイムラグはあるものの、コメントを入力するだけでソースコードを提案してくれる便利さは目を見張るものがあります。

Amazon CodeWhispererのwhispererとは、ささやく人、修飾語を伴うと心が通じ合える人といった意味があるようです。コメントを通してAIと心を通わせながらソースコードを完成させることができる、そんな意味合いに感じました。

今回はfizzbuzzという簡単なプログラムを作成しましたが、実際の業務でもAmazon CodeWhispererを活用すれば業務の効率化を図ることができることは間違いないでしょう。コメントを書くだけでソースコードを提案してくれるとは、本当にすごい時代に突入したのではないでしょうか？

Amazon CodeWhispererとは、オープンソースリポジトリやAmazon内部のリポジトリ、APIドキュメントなどから収集した数十億行のソースコードを機械学習させ、自動でコードを生成および提案してくれるサービスです。

Amazon CodeWhispererの特徴とは？VSCodeへの導入方法と合わせて解説

# 【AWS SAA】AWS実務未経験での合格体験記。学習方法や受験方法の違いによる注意点もご紹介

![01.jpg](https://storage.googleapis.com/envader-article-images/aws-saa/01.jpg)

**AWS SAA**(**AWS** Certified **S**olutions **A**rchitect - **A**ssociate)****は、****SAPやDVAなど複数あるAWS認定資格のうちの一つです。こちらの記事では、AWS実務未経験でもSAA試験に合格するために行った学習方法やマインドの持ち方、受験した際の失敗談などをご紹介します。

## AWS SAA(AWS Certified Solutions Architect - Associate)とは

AWS Solutions Architect - Associate(以降SAA)は、AWSの認定資格のうち**中級のアソシエイトレベル**に該当する資格になります。AWS認定資格はレベル別に、ベーシック(初級)・アソシエイト(中級)・プロフェッショナル(上級)の3つに分けることができ、SAAはこの中のアソシエイト(中級)に分類されます。

ソリューションアーキテクトとは、日本語に直訳すると「問題解決のための仕組みを設計する人」となり、アーキテクチャの設計原則に基づき具体的なシステムの構成・構築・提案をしていく役割があります。SAAはこのソリューションアーキテクトとして、中級の知識があることが求められるとともに、試験に合格すればその能力があることを証明する資格になります。

### 2023年4月現在、バージョンはSAA-C03

SAA試験にはバージョンがあり、現在のバージョンは**SAA-C03**です。2022年8月30日よりSAA-C02よりC03へ変更になりました。バージョンが違うことによって、出題されるサービスの内容や比率が違ってきます。書籍や資料によっては、新しいバージョンに対応していない可能性があるため、注意が必要です。

### 受験費用について

受験費用は、認定試験の種類によって異なります。SAAの場合には**税込16,500円**となっています。[バウチャーチケット購入センター](https://voucherticket.jp/ticketlist/)というサイトでチケットを購入すると、チケットを購入する際に割引を受けられるためお得です。SAAの場合は2023年5月現在、約5%の割引が適用されるため**税込16,500円→15,675円**で受験することが可能です。

割引チケットを使用して試験の予約をする際には、先にチケットを購入しバウチャーチケット番号を取得。その後、バウチャーチケット番号を使用して試験の予約をするようにしましょう。

また、**AWS公式でも時期によってはキャンペーンが実施され、受験費用の割引などの恩恵が受けられる場合もある**ため予約する際には確認すると良いでしょう。バウチャーチケットを利用するか、AWS公式のキャンペーンを利用するかは良く検討する必要がありそうです。

## この資格を取得するメリット

![02.jpg](https://storage.googleapis.com/envader-article-images/aws-saa/02.jpg)

私が受験した際にメリットと感じた事をご紹介します。

### たくさんあるAWSサービスのアーキテクチャを知ることができる

試験問題を通してアーキテクトとしての考え方を知ることができます。

例えば、S3バケットにデータを保存する際に、保存したデータにアクセスされるパターンが不規則だったとします。この場合に、S3でより運用するコストが低いストレージにはどのような種類があるのか？など、試験問題を通してソリューションアーキテクトとして必要な知識を得ることができます。

### 第三者に知識があることを証明できる

資格を取得することによって、自分以外の第三者に知識があることを証明できます。資格を持っていれば、実際に業務をこなせるかは別としても、自分以外の人に資格相応の知識を有していることを証明することができます。資格を持っていない方でも、資格以上の知識を有している方はたくさんいるかも知れませんが、その証明として資格を持っておくのはメリットになるでしょう。

### 問題を通して新しい発見だらけなので、試験は難しいが知る楽しさがある

先述したS3バケットのストレージの選択方法のように、試験問題を通して複数のサービスを組み合わせ、課題を解決していくにはどのようにするべきなのかを知ることができます。

初めは全く聞いたこともないようなサービスの名前が出てくることがほとんどでした。それでも問題を解いていくうちに、このパターンであればこの組み合わせで進めていく方法があるのか！という発見の連続がありました。色々なパターンの問題が出題されるため、間違えて落ち込むこともありましたが、新しい発見が続くことは非常に楽しい体験でした。

## 学習期間および時間

![03.jpg](https://storage.googleapis.com/envader-article-images/aws-saa/03.jpg)

学習期間については約1.5ヶ月で合格することができました。仕事の休憩時間にスマホで問題を解いたり、定時で仕事を終えた時には地元の生涯学習センターなど無料で利用できる施設を使って学習していました。1日平均1.5時間で約70時間前後、学習に時間を費やした計算になります。

## 学習方法について

私が学習を進めていく上で実践した内容を、マインドの持ち方なども含めてご紹介します。本来ならば問題を解いていくのと同時に実際にAWSに触れてみて、理解していくのが一番ベストな学習方法だと思います。

### ガンガン問題を解く

私は最初から問題集をひたすら解きました。まずは書籍から、とも思ったのですが、お世話になっている方からもガンガン問題を解きましょう！とのアドバイスをいただいたのもあり、この方法を選択しました。

書籍を読む、ハンズオンをしながら理解する。これは非常に大切なことだと思いますが、試験合格を最優先にする場合にはひたすら問題を解くのも悪くないと思います。

YouTubeの動画の中でも、**実務経験がある方でも試験問題を解かないと合格するのは難しい**と言われていました。試験範囲もかなり広いため、仮に実務経験が豊富な方でも出題される全てを理解している訳ではない、ということでしょう。

こう考えると、ガンガン問題を解き、間違えながら理解していくこの方法が一番効果があったと思います。

### マインドの持ち方

**問題を読んで正解が分からなくても落ち込まない。間違えても気にしない。**

これが私の中では一番重要でした。私はハートが弱い方なので、問題を解き始めた当初は初めて聞くサービス名が多すぎて、正直何を言っているのか分かりませんでした。こんなことで受かるのか？と不安になったことを覚えています。

結果、同じ問題を繰り返し解くことでやがて正解率も上がっていき、問題の内容も理解できるようになっていったため、いちいち落ち込まず淡々と進めることが大切だったなと感じています。

### YouTubeを利用する

SAA試験対策の問題はYouTubeにもたくさん動画があるため、こちらを利用しました。CloudTechさんが運営されているチャンネルでは、問題の後に解説されている動画もあるため内容を理解するのに非常に役に立ちました。

この時にも聞いたことのないサービスや問題があり、初めは正解することができませんでしたが、落ち込まないマインドでなんとか乗り越えたことを覚えています。

### 書籍を読んで理解する

ひたすら間違えながらも問題を解く。そうして分からなかったサービス名や特徴について、書籍を読んで調べることで理解が深まります。

繰り返し問題を解いていくことで、ある程度自分が理解できていないポイントが見えてきます。そのタイミングで書籍を利用して内容を確認する。こうすることで、サービスに対しての理解も深まり、問題がどのような意味だったのかを理解することができるようになりました。

### 毎日問題を解き続ける

気持ちを切らさないように、5分、10分だけでも必ず毎日問題を解き続けることを意識していました。1日でも問題を解かない日があると忘れてしまいそうで不安だったのもあり、どんなに忙しく疲れていても必ず問題を解くことは意識しました。

正直なところ、1問だけしか取り組めない日もありました。そんな日は1問だけでも良くやった！と自分のことを褒めてあげるようにしましょう。

## 筆者が利用したサービス

YouTubeなどで無料で学習することは可能ですが、それだけでは合格する自信が持てなかったため、有料サービスを利用しました。利用した有料サービスは以下のサービスです。

### Cloud Tech

[https://kws-cloud-tech.com/](https://kws-cloud-tech.com/)

AWS系YouTuberのくろかわこうへい氏が運営されているサービスです。YouTubeでも試験対策動画をアップされており、分かりやすい解説だったためとてもお世話になったサービスです。無料でも利用することが可能ですが、有料会員になることで最新バージョンのSAA-C03に対応した最新の問題を解くことができます。

ただ問題を解いていくだけではなく、問題に対してテキストでの解説や解説動画もあるため、間違えても次に活かすことができる仕組みになっている点が良かったです。

### Tech Stock

[https://techstock.jp/](https://techstock.jp/)

こちらのサービスは、7問単位で出題されていくスタイルで、ちょっとした隙間時間を利用して学習するのに非常に適したサービスです。私は仕事の休憩時間を利用して問題を解くようにしていました。

すでに資格を取得されている先輩から、最低でも3周は問題を解くように！とのアドバイスをいただいたため、試験日前日までに3周ほど周回し問題を解きました。こちらも問題を解くと解説のテキストが表示されるため、なぜ間違えたのかを確認しながら進められる点が良かったです。

## 受験方法の違いや注意点

![04.jpg](https://storage.googleapis.com/envader-article-images/aws-saa/04.jpg)

試験を受験するには、**試験センターへ出向いて受験する**方法と、**OnVUEというサービスを利用して自宅で受験する**という2つの方法があります。日本ではNational Computer Systems Japan K.K. (ナショナル・コンピュータ・システムズ・ジャパン株式会社)が運営しているPearson VUEというサービスを利用します。後述しますが、私が初めて受験する際にはOnVUEを利用してオンラインで受験しました。その際、試験の途中で謎のフリーズが発生してしまい、その日の受験は最後まで受けることができませんでした。

### 試験センターへ出向いて受験

試験センターへ足を運び、センター内で受験する方法です。受験センター内に設置されているPCを使用して受験するため、私が受験した際には持参するものは身分を証明するもの2つのみで、そのほかは必要ありませんでした。

交通費や移動時間はかかりますが、システムエラーなどの影響を受けることはないため、確実に受験したい方はこちらの方法がおすすめです。

### OnVUEを利用して自宅で受験

OnVUEとは、2019年より立ち上げられたオンラインで試験が受けられるサービスです。こちらのメリットはなんといってもSAAなどの認定試験を自宅で受けられることです。試験センターへ足を運ぶ手間や交通費などを気にしなくて良いことが最大のメリットだと思います。

受験する際には、試験を受ける部屋の片付けや部屋の全体像を映したり、身分証明書をスマホで撮影してオンライン試験監督へ提出したりする手間が発生します。私はこれが手間に感じてしまいました。そのため、慣れていないうちは試験開始時間より早めにログインし、手続き等を進める必要があります。余裕を持った行動を意識した方が、よりスムーズに受験することができるでしょう。

## OnVUEで受験した際の失敗談と対応策

先述したように、私が初めて受験した際にはOnVUEを利用してオンラインで受験しました。受験中、20門くらいを解いた後に画面がフリーズしてしまい、先に進めず途中で試験が終了してしまうというトラブルが発生。原因が自身のPCのスペックの問題だったのか、ネットワークの問題だったのか、Pearson VUE側の問題なのかは最終的に分かりませんでした。

調べてみると、同様のトラブルに見舞われている方もいるため、オンラインで受験する際にはこういったトラブルが発生するかも知れないことを頭に入れておく必要があります。

また、こう言ったトラブルに見舞われてしまった場合には、運営側にすぐに連絡をしましょう。そうすることで、サービスバウチャーと呼ばれる割引サービスが受けられます。私はこのサービスバウチャーを利用し、再度受験する際の費用を全額免除していただきました。

## 試験合格の通知について

![05.jpg](https://storage.googleapis.com/envader-article-images/aws-saa/05.jpg)

合格の通知については、メールで通知されます。通知されるまでにかかる日数は試験終了後5営業日以内と[公式](https://aws.amazon.com/jp/certification/policies/after-testing/)で案内されています。様々なケースがあるかも知れませんが、私の場合は受験当日の夜にメールで合格を知らせるバッジがメールで送られてきました。この時点ではスコアは確認できませんでしたが、後日再度メールが届き、スコアを確認することができました。

万が一試験に合格できなかった場合には、14日間は再受験することができないということも頭に入れておく必要があります。時期によっては再受験費用が半額になることもあるため、情報をチェックしておくと良いでしょう。

## まとめ

**AWS SAA**(**AWS** Certified **S**olutions **A**rchitect - **A**ssociate)を受験することで、AWSのサービスについての様々な発見や理解ができることは間違いありません。学習する際には、合格を目的にすることはもちろん、知らなかったことを知る喜びや楽しさを感じながら学習を進められたら最高だと思います。

こちらの記事では、AWS実務未経験でもSAA試験に合格するために行った学習方法やマインドの持ち方、受験した際の失敗談などをご紹介します。

【AWS SAA】AWS実務未経験での合格体験記 学習方法や受験方法の違いによる注意点もご紹介

Terraformとは、インフラストラクチャを管理するためのオープンソースのツールです。こちらの記事では、Terraformを使用してAWSのEC2を作成し、ssh接続するまでの流れをご紹介します。

【実践】TerraformのinstallからAWS EC2の作成〜ssh接続までを実践してみた

# セッションマネージャーを使用して、キーペアなしでEC2インスタンスへアクセスしてみた

こちらの記事では、AWS Systems Managerの一部の機能であるSession Managerを利用して、EC2インスタンスへキーペアなしでアクセスするまでの方法を解説します。

## どうしてセッションマネージャーでEC2アクセスするのか？

Session Managerを使用することで、セキュリティグループのSSH接続用の22番ポートの開放が必要なくなり、アクセス履歴をCloud Trailへ保存できるようになるなどのメリットがあり、セキュリティ面においてより堅牢に運用することが可能です。

AWSが公開しているEC2インスタンスにアクセスするベストプラクティスとしても、Session Managerについて触れられています。

[AWS公式](https://repost.aws/ja/knowledge-center/ec2-ssh-best-practices)

## AWS Systems Managerとは

AWS Systems Managerとは、EC2を中心とするAWS環境の運用や、オンプレミス環境の運用を効率化する機能が多数提供されているサービスになります。このサービスを上手に使いこなすことで、日々必要とされる維持、運用作業を効率化することができます。

AWS Systems Managerは略称として「SSM」と表記されることがあります。これには理由があり、AWS Systems Managerとなる以前のサービス名がAmazon Simple Systems Manager(SSM)、Amazon EC2 Systems Manager(SSM)となっていたため、その名残りであると言われています。

[AWS Systems Managerの特徴](https://aws.amazon.com/jp/systems-manager/features/?pg=ln&sec=hs)

## Session Manager

![SSM-arch-1.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-arch-1.png)

Session Managerは、AWS Systems Managerが提供する機能のうちの一つで、Webブラウザ(マネジメントコンソール)やAWS CLIからインスタンスへのコマンド操作を実現する機能になります。

Session Managerを使用することで、Amazon EC2インスタンスの他、エッジデバイス、オンプレミスサーバー、仮想マシン (VM)を管理することができます。

Session Managerの公式ドキュメントには、以下のように記載されています。

> Session Managerは安全かつ監査可能なノード管理を実現し、インバウンドポートを開いたり、踏み台ホストを維持したり、SSHキーの管理をしたりする必要はありません。
> 

[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager.html)より引用

インバウンドポートを開く、つまりSSH接続するための設定で必要なセキュリティグループでの22番ポート解放や、SSH接続をする際に必要なキーペアの作成が不要になるとの説明が書かれています。

今回の記事では実際にこの設定を試してみて、本当に22番ポートの解放、キーペアの作成が必要無いのかを検証していきます。

## Session Managerを使用する際に必要なこと

Session Managerを使用してEC2インスタンスへアクセスするには、以下の3つの条件が必要になります。

- EC2インスタンスにSSMエージェントがインストールされていること
- EC2インスタンス用のIAMロールを作成すること
- EC2インスタンスに作成したIAMロールをアタッチすること

この3つの条件をEC2インスタンスに設定することで、EC2インスタンスは**マネージドノード**と呼ばれるSSMで管理できる状態になります。

### EC2インスタンスにSSMエージェントがインストールされていること

SSMエージェントとは、AWSリージョンごとに存在するSSMのリージョンエンドポイントと呼ばれる場所へ定期的な問い合わせ(ポーリング)を実行する、AWSが提供するミドルウェアです。このSSMエージェントがポーリングを行うことで、SSMエージェントがSSMからのコマンド実行などの指示を受け付けます。

通常、問い合わせ先となるSSMのリージョンエンドポイント(Systems Manager APIなど)はインターネット上に存在するため、EC2インスタンスにInternet Gatewayを経由したアウトバウンド通信を許可しておく必要があります。

![SSM-arch-2.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-arch-2.png)

例外としてVPCエンドポイントと呼ばれる機能を使うことで、インターネットを経由せずにVPC内のリソースとVPC外のリソースを接続することも可能です。

![SSM-arch-3.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-arch-3.png)

## SSMエージェントのインストールの必要性

SSMエージェントに関しては、今回使用するAmazon Linux2にはプリインストールされているためインストールの必要はありません。2023年6月現在の公式ドキュメントでは、以下のAMIにはプリインストールされています。

これ以外のAMIを使用する場合には、SSMエージェントをインスタンスへインストールする必要があるので注意が必要です。

- 2017 年 9 月以降の Amazon Linux Base AMI
- Amazon Linux 2
- Amazon Linux 2 ECS に最適化されたベース AMIs
- Amazon Linux 2023 (AL2023)
- Amazon EKS 最適化 Amazon Linux AMIs
- macOS 10.14.x (Mojave)、10.15.x (Catalina)、11.x (Big Sur)
- SUSE Linux Enterprise Server(SLES) 12 と 15
- Ubuntu Server 16.04、18.04、および 20.04
- 2016 年 11 月以降に公開された Windows Server 2008-2012 R2 AMIs
- Windows Server 2016、2019、および 2022

### EC2インスタンス用のIAMロールを作成する

EC2インスタンスがSSMと通信するためには、**AmazonSSMManagedInstanceCoreというポリシーをアタッチした**IAMロールを作成し、IAMロールをEC2へアタッチする必要があります。

## Session Managerを使用してEC2へアクセス

ここからは、EC2インスタンスをキーペアを作成せずに起動し、マネジメントコンソールからSSMを利用してインスタンスへ接続できるのかを試してみます。

### キーペアを作成せずにEC2インスタンスを作成する

マネジメントコンソールより、EC2ダッシュボードへ移動します。

![SSM-1.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-1.png)

インスタンスを起動を選択します。

![SSM-2.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-2.png)

名前とタグはテスト用でssm-ec2としました。

AMIはAmazon Linux2を使用します。

![SSM-3.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-3.png)

キーペアは「なしで続行」を選択します。これにより、キーペアを使用してのEC2インスタンスへのログインは不可能です。

そして、セキュリティグループの設定で、「SSHトラフィックを許可する」のチェックを外し、22番ポートを解放しないように設定します。

ここまでの設定が完了した後、インスタンスを作成します。

![SSM-4.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-4.png)

インスタンスの状態が「実行中」になればEC2の起動完了です。

![SSM-5.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-5.png)

### IAMロールの作成

続いて、Session ManagerでEC2へアクセスするために必要なIAMロールを作成します。

IAMのダッシュボードへ遷移します。

![SSM-6.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-6.png)

ダッシュボードの左側、ナビゲーションよりロールを選択します。

![SSM-ss1.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-ss1.png)

画像の「ロールを作成」をクリックします。

![SSM-ss2.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-ss2.png)

「信頼されたエンティティタイプはAWSのサービスを、ユースケースはEC2を選択し次へ進みます。

![SSM-9.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-9.png)

許可ポリシーの検索窓へ「ssmmanaged」と入力しエンターを押すと、**AmazonSSMManagedInstanceCore**が表示されるため、チェックを入れて次へ進みます。

![SSM-10.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-10.png)

任意の名前でロール名を入力します。

![SSM-11.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-11.png)

下へスクロールし、許可ポリシーに**AmazonSSMManagedInstanceCore**が追加されていることを確認し、ロールを作成します。

![SSM-12.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-12.png)

画面上部に以下の画面が表示されればIAMロールの作成完了です。

![SSM-13.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-13.png)

### EC2インスタンスにIAMロールをアタッチする

作成したIAMロールをEC2インスタンスへアタッチします。

EC2インスタンス画面より作成したインスタンスを選択し、アクションタブより「セキュリティ」を選択し、「IAMロールを変更」をクリックします。

![SSM-14.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-14.png)

「IAMロールを選択」をクリックすると、先ほど作成したロールが表示されるため選択し、「IAMロールの更新」をクリックします。

![SSM-15.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-15.png)

インスタンスの詳細タブより、IAMロールがアタッチされたことが確認できればアタッチ完了です。

![SSM-16.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-16.png)

### Session ManagerでEC2へアクセスしてみる

作成したインスタンスをチェックした状態で、「接続」をクリックします。

![SSM-17.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-17.png)

セッションマネージャーを選択し、「接続」をクリックします。

この時、「接続」ボタンがクリックできない場合は、若干時間を置いてリロードする必要があります。

![SSM-18.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-18.png)

接続が完了すると、ブラウザの別タブでターミナルが開きます。通常のSSH接続であればec2-userでログインしますが、Session ManagerでEC2に接続した場合にはssm-userで接続していることに注意しましょう。

![SSM-19.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-19.png)

この場合、接続後のカレントディレクトリは/usr/binになっています。

![SSM-20.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-20.png)

これで、セキュリティグループの22番ポートを解放することなく、キーペアを使用せずにEC2インスタンスへ接続することができました。

![SSM-アーキテクチャ図-1.png](https://storage.googleapis.com/envader-article-images/ec2-instance/SSM-%25E3%2582%25A2%25E3%2583%25BC%25E3%2582%25AD%25E3%2583%2586%25E3%2582%25AF%25E3%2583%2581%25E3%2583%25A3%25E5%259B%25B3-1%201.png)

## まとめ

今回は、AWS Systems Managerの一部の機能であるSession Managerを利用して、EC2インスタンスへキーペアなしでアクセスするまでの方法を解説しました。

Session Managerを使用してEC2インスタンスへ接続するための条件として、

- EC2インスタンスにSSMエージェントがインストールされていること
- EC2インスタンス用のIAMロールを作成すること
- EC2インスタンスに作成したIAMロールをアタッチすること

この3つの条件があることを忘れずに、より堅牢な運用を目指していきましょう。

こちらの記事では、AWS Systems Managerの一部の機能であるSession Managerを利用して、EC2インスタンスへキーペアなしでアクセスするまでの方法を解説します。

セッションマネージャーを使用して、キーペアなしでEC2インスタンスへアクセスしてみた

# ECSの基本を理解する(クラスター、サービス、タスク定義、タスク)

こちらの記事では、AWSのコンテナオーケストレーションサービスであるECS(Amazon ****E****lastic ****C****ontainer ****S****ervice)の基本、クラスター、サービス、タスク定義、タスクについて解説します。

## ECS(Amazon ****E****lastic ****C****ontainer ****S****ervice)とは

**[Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)**

Amazon ****E****lastic ****C****ontainer ****S****erviceは、AWSが提供するフルマネージドのコンテナオーケストレーションサービスです。ECSを利用することで、Dockerコンテナのスケーリング、実行、停止、管理をより簡単に行うことができます。

ECSでは、「EC2」「Fargate」、AWS外のオンプレミス環境で実行されるコンテナ環境をECSで簡単に管理できる****[Amazon ECS Anywhere](https://aws.amazon.com/jp/ecs/anywhere/)の**3つの起動タイプをコンテナ実行環境としてサポートしています。

### コンテナオーケストレーション

コンテナオーケストレーションは、複数のコンテナを自動で管理するためのプロセスやツールのことを指します。主な機能として、コンテナのデプロイメント（配置）、スケーリング（拡張・縮小）、ネットワーキング、ロードバランシングなどがあります。

そして、コンテナオーケストレーションを実現するために使用するのがコンテナオーケストレーションツールです。ECSをはじめ、代表的なコンテナオーケストレーションツールにはKubernetesやDocker Swarmなどが挙げられます。これらは**オーケストレータ**(**コントロールプレーン)**とも呼ばれます。

これらのツールを使うことで、管理者は複数のコンテナホストに対して一つ一つ手動でコマンドを実行する必要がなくなり、より効率的にコンテナを運用、管理することが可能になります。

逆に言えば、コンテナオーケストレーションツールを使用しないと複数のコンテナホストを手動で管理することになり、複数あるコンテナに対して一つずつコマンドを実行する必要が出てくるため、非効率かつオペレーションミスにもつながってしまいます

## ECSを利用するメリットとは？

ECSはAWSが提供するフルマネージドのコンテナオーケストレーションサービスです。CodeBuildやCodePipeline、Systems Manager Parameter Storeといった様々なAWSのサービスとの連携はマネージドサービスが実行してくれるため、ECSは非常に扱いやすいサービスとされています。

また、ECSはリージョン内の複数のAZ(アベイラビリティーゾーン)をまたいでコンテナを実行することができるため、より可用性の高い運用が可能です。

このように、AWSの各サービスとの連携を簡単に実現しながら、複数のコンテナを高い可用性を保って実行できるのはECSの魅力の一つと言えます。

## ECSの主な構成要素

ECSを利用する上で基本となる構成要素として、「クラスター」、「サービス」、「タスク定義」、「タスク」の4つがあります。これらの要素はECSを利用する際に必要な設定項目になるため、図を利用しながら解説していきます。

### クラスター

![ECS-1.png](https://storage.googleapis.com/envader-article-images/amazon-ecs/ECS-1.png)

[AWS公式](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/clusters.html)

クラスターとは、後述する「サービス」と「タスク」を実行する基盤のことです。図で示すと赤枠の部分に相当します。

実際にクラスターを作成する際には、以下の項目を設定していきます。

- クラスター名
- どのVPCとサブネットを使用するのか？
- 利用するインフラの種類(Fargate、EC2インスタンス、オンプレミスの仮想マシンまたはサーバー)

尚、設定項目については**新しいコンソールと旧コンソールで違いがある**ため、実際に触れる際には注意が必要です。

### サービス

![ECS-2.png](https://storage.googleapis.com/envader-article-images/amazon-ecs/ECS-2.png)

[AWS公式](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)

サービスとは、クラスター内で実行するタスク(コンテナ群)を管理する役割を持っています。

サービスでは、どのタスク定義を使用して、どのECSクラスターを使用するのか？などを決めることができます。

そして、起動タイプとしてEC2を選択しコンテナを仮想サーバー上で動作させるのか、Fargateを選択してコンテナをサーバーレスで動作させるのかを設定することができます。

また、どのくらいのタスク数が必要なのか？を定義することができるため、必要なタスクの数を3とした場合、起動後は3つのタスク数を自動で維持、管理してくれます。これにより、万が一障害が発生してサービスが停止してしまった場合にも、指定したタスクを自動で再作成してくれるという利点があります。

### タスク定義

![ECS-3.png](https://storage.googleapis.com/envader-article-images/amazon-ecs/ECS-3.png)

[AWS公式](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)

タスク定義とは、どのようなコンテナを作成するのか？を定義したものです。タスク定義は一度作成すると設定内容を変更することはできないため、変更したい場合は新しいタスク定義を別で作成するか、リビジョンと呼ばれるバージョン単位で内容を上書きする必要があります。

実際の設定項目の一部は以下のとおりです。

| 設定要素 | 内容 |
| --- | --- |
| ファミリー名 | タスク定義の名前 |
| コンテナ名 | 起動するコンテナ名 |
| イメージURI | 使用するコンテナイメージのURI |
| ポートマッピングでのポート番号 | 使用したいポート番号の指定 |
| 環境変数の設定 | 環境変数の内容を設定 |
| ボリューム名 | コンテナへアタッチするボリューム |
| 実行ロールの設定 | タスクがAWSサービスにAPIリクエストを行うために使用できるIAM ロール。 |
| ネットワークモードの設定 | default、bridge、Host、awsvpc、None |

このタスク定義で設定した内容をもとにして、タスクと呼ばれるコンテナ群は作成されます。

また、ポートマッピングで使用するポートマッピングのポート番号を指定しなかった場合、動的にポート番号が割り当てられます。

### タスク

![ECS-4.png](https://storage.googleapis.com/envader-article-images/amazon-ecs/ECS-4.png)

タスクとは、先述したタスク定義をもとにして起動したコンテナの集まりのことです。

一つのタスク内では複数のコンテナを起動することもできます。例えばNginxなどのWebサーバーと、Gunicornなどのアプリケーションサーバーを一つのタスク内で実行する、といったことも可能です。

タスクのどれかが障害などで停止したりした場合には、サービスで設定した必要なタスク数をもとに自動的に新しいタスクが起動します。これにより、サービス内の希望するタスク数を維持することができます。

## まとめ

こちらの記事では、ECSにおける基本的な要素、(クラスター、サービス、タスク定義、タスク)について解説しました。

- クラスターは「サービス」と「タスク」を実行する基盤のこと
- サービスは、クラスター内で実行するタスク(コンテナ群)を管理する役割を持っている
- タスク定義とは、どのようなコンテナを作成するのか？を定義したもの
- タスクとは、タスク定義をもとにして起動したコンテナの集まりのこと

それぞれの要素について図を見ながらイメージしていただき、ECSの基本的な4つの要素について少しでも理解に繋がれば幸いです。

Amazon Elastic Container Serviceは、AWSが提供するフルマネージドのコンテナオーケストレーションサービスです。ECSを利用することで、Dockerコンテナのスケーリング、実行、停止、管理をより簡単に行うことができます。

ECSの基本を理解する(クラスター、サービス、タスク定義、タスク)

# クラウド系エンジニア初学者が目指すべきAWSアソシエイト3冠

AWSは世界最大のユーザー数を誇るクラウドサービスです。そんなAWSは自社サービスの公式資格として、認定精度を提供しています。

中でもエンジニア初学者の方が取得を目指したいのが、AWS認定のアソシエイトレベルです。

アソシエイトレベルは、基礎レベルをクリアした中級者的な立ち位置であり、難易度も中程度と少しだけ高く設定されています。3つある資格を全て取得すれば、見事「3冠」と名乗ってもよいでしょう。

今回はエンジニア初学者の方に向けて、AWSアソシエイト3冠を目指す方法を解説します。ぜひ参考にしてください。

## AWS認定資格アソシエイト3冠で目指す資格

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image6.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image6.jpg)

画像引用：[AWS公式サイト](https://aws.amazon.com/jp/)

AWS認定資格アソシエイトは、3つの資格を提供しています。3冠を目指す場合、まずはどんな資格があるのかを知っておきましょう。

それぞれ勉強する範囲が異なるので、以下で詳しく解説します。

- SAA（AWS Solution Architect Associate）
- DVA（AWS Developer Associate）
- SOA（AWS Sysops Administrator）

### SAA（AWS Solution Architect Associate）

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image7.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image7.jpg)

画像引用：[AWS Solution Architect Associate公式サイト](https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/)

AWS Solution Architect Associateは、通称「SAA」と呼ばれる資格です。コーディングの深い実務経験は必要なく、基本的なプログラミングの概念に精通しているかどうかを問われます。

AWS認定資格アソシエイトの包括的な内容を含んでいます。システム全体のアーキテクチャを設計するための技能を問われるため、最初に受けておくと良いでしょう。他の試験でも活用できる内容が多くあります。

まずはSAAの取得を目指し、合格後に他の試験に挑戦してみてください。

| 試験時間 | 130分 |
| --- | --- |
| 料金 | $150 |
| 問題数 | 65問 |
| 出題形式 | 複数選択または複数応答 |
| 受験方法 | Pearson VUEテストセンター
オンライン（監督付き） |

＊認定試験に合格すると次の試験に使える半額バウチャーが発行されます。AWSCLFから受験すると半額の75＄で受験することができます。また、再受験無料キャンペーンなどもありますのでタイミングを合わせるて受験するのもおすすめです。

### DVA（AWS Developer Associate）

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image5.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image5.jpg)

画像引用：[AWS Developer Associate公式サイト](https://aws.amazon.com/jp/certification/certified-developer-associate/)

AWS Developer Associateは、通称「DVA」と呼ばれる資格です。AWSを使った開発者向けの資格となっています。取得することで、以下の能力を証明可能です。

- AWSのコアサービスの使用
- 基本的なAWSアーキテクチャのベストプラクティスに関する知識と理解
- AWSを使用したクラウドベースのアプリケーションの開発・デプロイ・デバックの習熟度

AWSサービスを実際にアプリケーションに組み込んで、システム実装するための技能が問われます。

SAAを先に習得しておくと理解が早まるとしたのは、このためです。クラウドベースのアプリケーションに関しての知識・スキルを身につけたい場合は、先にこちらを受けると良いでしょう。

| 試験時間 | 130分 |
| --- | --- |
| 料金 | $150 |
| 問題数 | 65問 |
| 出題形式 | 複数選択または複数応答 |
| 受験方法 | Pearson VUEテストセンター
オンライン（監督付き） |

### SOA（AWS SysOps Administrator）

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image4.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image4.jpg)

画像引用：[AWS SysOps Administrator公式サイト](https://aws.amazon.com/jp/certification/certified-sysops-admin-associate/)

AWS SysOps Administratorは、通称「SOA」と呼ばれる資格です。AWSの中でもインフラ環境に特化しています。取得することで、以下の能力を証明できます。

- AWS上のワークロードのデプロイ、管理、オペレーション
- セキュリティコントロールとコンプライアンス要件の実装
- AWSマネジメントコンソールの使用
- AWSコマンドラインインターフェイスの使用
- AWS Well-Architected Framework、 AWS のネットワークとセキュリティサービスへの理解度

どれも本番稼働後に必要となる運用管理技能です。インフラ環境に力を入れたい方は、SOAに挑戦すると良いでしょう。

また、SOAではラボ試験も提供されていましたが、2023年3月28日以降、一時的に停止されています。難しいと定評があったラボ試験がないため、従来より少しだけ難易度が下がっています。受けるなら今がオススメです。

| 試験時間 | 130分 |
| --- | --- |
| 料金 | $150 |
| 問題数 | 65問 |
| 出題形式 | 複数選択または複数応答 |
| 受験方法 | Pearson VUEテストセンター
オンライン（監督付き） |

## エンジニア初学者がAWS認定資格アソシエイト3冠を目指すメリットは大きい

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image2.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image2.jpg)

AWS認定資格アソシエイトの3冠を目指すのは、エンジニア初学者にとってメリットの大きいロードマップです。世界的シェアを誇るAWSに関する知識・スキルが一通り身につくので、キャリアアップに役立ってくれます。

また、それぞれがサービス設計・運用・開発者とターゲットが違うため、3つを所得することで総合力がある証明にもなります。

試験には重複している内容も多く、1度の勉強で他の分野まで補完できる点も魅力です。

エンジニア初学者が目指すのであれば、非常に魅力的な資格と言えます。

## エンジニア初学者にオススメのAWS認定資格アソシエイト3冠への学習法

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image10.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image10.jpg)

AWS認定資格アソシエイトの3冠を目指す際、気になるのが学習法です。それぞれ難易度は中程度なので、難しい勉強が必要なわけではありません。経験者であれば1ヶ月もあれば合格ラインに達するでしょう。

ここからは、試験別にオススメの学習法を紹介します。ぜひ参考にしてください。

### AWS-SAA

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image3.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image3.jpg)

SAAは、最初に受けておきたい試験です。DVAやSOAの内容も含まれているため、最初に勉強していると3冠が楽になります。

基本的な勉強方法は他の資格試験と同じです。以下の流れで行うと良いでしょう。

1. 参考書を読み込む
2. 問題集を解く
3. AWSの無料利用枠を活用する
4. AWS公式のサンプル問題集を解く
5. AWS公式の模擬試験を解く

AWSが公式で試験素材を発信してくれているので、活用してください。より本番に近い形で学習できます。

### AWS-DVA

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image9.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image9.jpg)

SAAを取得したら、DVAを目指しましょう。DVAはとにかく実践が大切です。開発者向けの資格なので、手を動かして学ぶ方が身につきます。

大きな学習の流れは変わりませんが、以下のようにすると進めると良いでしょう。

1. DVAに関する動画を繰り返し視聴する
2. 参考書を読み込む
3. Webの問題集を解く
4. AWSの無料利用枠を活用する
5. AWS公式のサンプル問題集を解く
6. AWS公式の模擬試験を解く

開発環境は常に変化しているため、紙の本よりもWebがオススメです。どうしても情報が古くなってしまうため、最新の問題についていけない可能性があります。

DVAはWebを中心に学習すると効果的です。

### AWS-SOA

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image11.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image11.jpg)

SOAは、SAA取得後に目指しましょう。できればDVAを取得してからの最後の資格として挑戦することをオススメします。アソシエイトレベルの中で最も難易度が高いためです。

大まかな流れは他の試験と変わりません。以下のように進めると良いでしょう。

1. SOAに関する動画を繰り返し視聴する
2. 参考書を読み込む
3. Webの問題集を解く
4. AWSの無料利用枠を活用する
5. AWS公式のサンプル問題集を解く
6. AWS公式の模擬試験を解く

ラボ試験では、実機操作が必要です。そのためにも手を動かして慣れておくことをオススメします。2023年7月現在においてラボ試験は停止されていますが、いつ復活するかわかりません。

万全の状態で挑戦できるようにしておきましょう。

## エンジニア初学者がAWS認定資格アソシエイト3冠に必要な勉強時間

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image8.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image8.jpg)

エンジニア初学者の方がAWSアソシエイトの3冠を目指す場合、気になるのが勉強時間です。果たしてどれだけ勉強すればいいのかは、気になるポイントですよね。

基礎的なSAAから受けると仮定した場合、以下の勉強時間ならば合格ラインに到達できます。

- SAA：3ヶ月
- DVA：2ヶ月
- SOA：2ヶ月

SAAは3ヶ月ほどかかりますが、他の資格は2ヶ月ほどあれば合格できるでしょう。ただし、それぞれの受験期間が空くと、より時間がかかります。

SAA・DVA・SOAは互いに関連している資格なので、連続して挑戦するほど勉強時間が少なくて済みます。「鉄は熱い内に打て」と同じ理屈です。

初学者の方は、一気に3冠を目指す意気込みで挑戦すると良いでしょう。

## エンジニア初学者はAWS認定資格アソシエイト3冠を目指そう

![https://storage.googleapis.com/envader-article-images/aws-triple-crown/image1.jpg](https://storage.googleapis.com/envader-article-images/aws-triple-crown/image1.jpg)

AWS認定資格アソシエイトは、Amazonが提供する世界トップシェアを誇るAWSに関する中級レベルの資格です。SAA・DVA・SOAの3つを取得することを3冠と言います。

学習の際は、動画や参考書でインプットしながら問題集を解くという定番の方法を取りましょう。初学者の方であっても3ヶ月ほどの勉強時間で取得できるため、それほど難しくもありません。

AWSに関する総合的な能力がある証明として、非常に有用です。ぜひ挑戦してみてくださいね。

アソシエイトレベルは、基礎レベルをクリアした中級者的な立ち位置であり、難易度も中程度と少しだけ高く設定されています。3つある資格を全て取得すれば、見事「3冠」と名乗ってもよいでしょう。

クラウド系エンジニア初学者が目指すべきAWSアソシエイト3冠

# Terraformのinput変数の基本的な定義方法 Variableとは

![出典: **HashiCorp Brand** [https://www.hashicorp.com/brand](https://www.hashicorp.com/brand)](https://storage.googleapis.com/envader-article-images/terraform-input-variable/Terraform_PrimaryLogo_ColorWhite_RGB.png)

出典: **HashiCorp Brand** [https://www.hashicorp.com/brand](https://www.hashicorp.com/brand)

こちらの記事では、Terraformにおけるinput変数、Variableについて解説します。Terraformとは、IaC(Infrastructure as Code)を実現するための構成管理ツールの一つです。

Terraformの変数にはinput、local、outputの3つの種類があります。今回はこの3つの変数のうちの一つ、input変数の基本的な定義方法を解説していきます。

IaCについては以下の記事で解説しています。

[https://envader.plus/article/136](https://envader.plus/article/136)

Terraformを実際に触ってみたい方は、以下の記事でハンズオンを解説しています。

[https://envader.plus/article/162](https://envader.plus/article/162)

## input変数とは？

Terraformのinput変数とは、外部ファイル(異なる.tfファイルなど)から値を入力するために使用する変数です。この変数を定義することで、各リソースなどに設定する値を直接書くことを防ぐことができ、再利用性を高めた運用ができるというメリットがあります。

[公式ドキュメント](https://developer.hashicorp.com/terraform/language/values/variables)でも表現されているように、input変数は関数定義の引数のようなものと言えます。

input変数はプロジェクトのルートディレクトリ(親モジュール)で定義すると、CLI、環境変数、.tfvarsファイルやデフォルト値を使って値を設定することができます。ルートディレクトリの下の階層(子モジュール)でinput変数を定義する場合には、呼び出し元(子モジュールを使う側)のモジュールブロックで値を渡す必要があります。

### input変数の定義

Terraformでinput変数を定義するには、variableブロックを使用して変数を定義します。

```bash
variable "region" {
  description = "The region where resources should be created"
  type        = string
  default     = "ap-northeast-1"
}

variable "subnet_ids" {
  description = "List of subnet IDs to deploy resources into"
  type        = list(string)
  default     = []
}
```

variableの後のダブルクウォートで囲まれている部分が変数名になり、input変数を参照する場合にはこの変数名を使用します。この変数名は同じモジュール内の変数の中で一意(一つだけ)にする必要があります。

また、変数名には予約されているsource、version、providers、count、for_each、lifecycle、depends_on、locals以外を使用するようにしなければならないため注意が必要です。

## input変数の引数(設定値)

![001.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/001.jpg)

input変数を定義する際、引数として変数名の後のカッコの中に設定値を記述することができます。以下に公式を元に解説します。

### defaut

変数宣言にデフォルト値を設定することで、ユーザーがその変数を明示的に記述しなかった場合には設定したデフォルト値が使用されます。input変数で定義した変数にはCLIや環境変数、.tfvarsファイルなどで値を渡す必要がありますが、この値を渡す作業が省略された場合にはデフォルト値が適用されるということです。

また、仕様としてデフォルト値には変数を設定することはできません。

```bash
variable "region" {
  default     = "ap-northeast-1"
}

# 変数はデフォルト値に設定できない
variable "region" {
  default     = var.region_name
}
```

### type

変数の値の型を指定することができます。こちらはオプションのため省略することが可能で、省略した場合はどんな型の値でも渡すことが可能です。ただし、型を指定することで開発者にとっての注意喚起や、想定していた型とは違う値を渡した場合にはエラーを返してくれるため、公式では指定することが推奨されています。

どのような型が存在するのかは後述します。

```bash
# 文字列型の例
variable "region" {
   type        = string
 }
```

### description

input変数の説明を記述することができます。説明を簡潔に記述しておくことで、共同で開発していく場合にも変数がどのような役割を持っているのかなどを共有することができます。

```bash
variable "region" {
  description = "The region where resources should be created"
 }
```

### validation

validationを設定することで、変数の値が設定した条件に合っているかどうか検証することが可能になります。

conditionでは真偽値を返す必要があり、falseになった場合にはerror_messageで設定したメッセージを返します。

```bash
variable "environment" {
  description = "Deployment environment"
  type        = string

  validation {
    condition     = contains(["prod", "staging", "dev"], var.environment)
    error_message = "The environment must be 'prod', 'staging', or 'dev'."
  }
}
```

以下にエラー表示の例を示します。

```bash
# environment変数へstgという値を設定した例
# error_messageで設定した値が出力されている

Error: Invalid value for variable
│
│   on variables.tf line 5:
│    5: variable "environment" {
│     ├────────────────
│     │ var.environment is "stg"
│
│ The environment must be 'prod', 'staging', or 'dev'.
│
│ This was checked by the validation rule at variables.tf:8,3-13.
```

### sensitive

sensitiveをtrueに設定することで、terraform planやapplyを実行した際に設定した値を画面に出力されるのを防ぐことができます。この設定は、主に機密情報を含む可能性がある場合に使用されます。

DBのパスワードを想定した変数があった場合、sensitiveをtrueにしておくことで、planやapply実行時に値が出力されることを防ぎます。

```bash
variable "db_password" {
  description = "The password for the database"
  type        = string
  sensitive   = true
}
```

ただし、公式にもあるとおり画面には出力されないものの、.tfstateファイル(Terraformによって管理されているインフラストラクチャの現在の状態を保存し、追跡するためのファイル)には平文で保存されるため、必ずしも安全とは限りません。

参照リンク: [Sensitive Data in State](https://developer.hashicorp.com/terraform/language/state/sensitive-data)

### nullable

nullableは変数にnull値を許可するかどうかを制御するものです。nullable = falseを設定すると、その変数がnullになることを防ぐことができます。デフォルトではtrueに設定されているため、変数の値としてnullを渡しても有効な値として扱われます。

```bash
variable "password" {
  type     = string
  nullable = false
}
```

参照リンク: [Terraform Arguments](https://developer.hashicorp.com/terraform/language/values/variables#arguments)

## input変数の型(Primitive Types)

![002.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/002.jpg)

ここからは、Terraformを利用する上で一番の基本となる型を見ていきます。プリミティブ型と呼ばれる型が基本となり、文字列型、数値型、真偽値型の3つに分類されます。

### string

string型は最も基本的なもので、変数の値には文字列を渡すことができます。表現を変えると、この変数には文字列の値を受け取ることをTerraformに伝えているとも言えます。

値を渡す際にはダブルクウォートで文字列を囲む必要があります。

```bash
# デフォルト値としてt3.microを渡す場合
variable "instance_type" {
  description = "The type of instance to start."
  type        = string
  default     = "t3.micro"
}
```

### number

number型では15のような整数値、1.234などの少数も受け取ることができます。

```bash
variable "max_instances" {
  description = "The maximum number of instances to launch."
  type        = number
  default     = 5
}
```

### bool

bool型では、trueまたはfalseの値を受け取ることができます。

```bash
variable "enable_logging" {
  description = "Enable or disable logging."
  type        = bool
  default     = true
}
```

公式ではプリミティブ型の場合、受け取った値が自動的に適切な型へ変換される可能性があることを説明しています。bool型で指定した場合にも、場合によって文字列型へ変換される場合などです。

参照リンク: [Terraform Conversion of Primitive Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#conversion-of-primitive-types)

少しわかりにくいため、以下に例を示します。例では数値型と真偽値型の変数を定義しています。

```bash
variable "example_number" {
  description = "An example number."
  type        = number
  default     = 15
}

variable "example_bool" {
  description = "An example boolean."
  type        = bool
  default     = true
}
```

次に、S3バケットのタグを指定する場面を例に示します。

```bash
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  acl    = "private"

  tags = {
    number_as_string = var.example_number → 15が"15"へ変換される
    bool_as_string   = var.example_bool   → trueが"true"へ変換される
  }
}
```

この例では、S3バケットのタグに数値型とbool型の変数を指定しています。しかし、S3のタグの値は文字列型でなければならないため、ここで自動的に変数のデフォルトで指定した15やtrueの値が文字列型へ変換されます。

また、自動的に変換される条件として値が有効な文字列や数値を含んでいる必要があります。

```bash
# 文字列が数値を表さない場合は変換されない
"abc"
"123abc"

# 文字列が真偽値を表さない場合も変換されない
"yes"
"no"
"1"
```

参照リンク: [Terraform Primitive Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#primitive-types)

## ****Collection Types(コレクション型)****

![003.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/003.jpg)

コレクション型は、複合型という複数の値を一つの変数に格納することができる型の種類の一つになります。複合型にはコレクション型の他に、Structural Types(構造型)が存在します。

以下にコレクション型のlist、map、setについて解説します。

### list

listでは、格納される値が同じ型の配列を受け取ることができます。list(受け取りたい型)とすることで、受け取りたい型の配列を指定できます。

```bash
# 文字列の配列を受け取りたい場合
variable "example_list" {
  type    = list(string)
  default = ["apple", "banana", "cherry"]
}

# 数値の配列を受け取りたい場合
variable "example_list" {
  type    = list(number)
  default = [1, 2, 3]
}

# 以下は数値と文字列が混同しているためエラーになる
variable "example_list" {
  type    = list(number)
  default = [1, "two", 3]
}
```

### map

mapはキーと値で構成された配列です。map(受け取りたい型)とすることで作成することができます。

キーはユニークな値(他と重複しない)である必要があり、通常キーと値はダブルクウォートで囲む必要があります。

```bash
variable "example_map" {
  type = map(string)
  default = {
    "key1" = "value1"
    "key2" = "value2"
  }
}
```

ただし、キーが数字で始まらない場合には、ダブルクウォートを省略することも可能です。

```bash
variable "example_map" {
  type = map(string)
  default = {
    key1 = "value1"  # OK: キーが数字で始まっていない
    key2 = "value2"  # OK: キーが数字で始まっていない
  }
}
```

### set

listと似ていますが、setは値にアクセスする際にindexで参照することができません。また、値が重複していてはいけないということ、要素の型は同じでなければならないという条件があります。

```bash
# setの正しい例
variable "example_set" {
  type    = set(string)
  default = ["apple", "banana", "cherry"]
}

# 値が重複しているためエラーになる
variable "example_set" {
  type    = set(string)
  default = ["apple", "apple", "cherry"]
}

# エラー：文字列と数値が混在
variable "example_set" {
  type    = set(string)
  default = ["apple", 123, "cherry"]
}
```

setはTerraformでループ処理を行う際のfor_eachで使用する場面が出てきます。

参照リンク: [The for_each Meta-Argument](https://developer.hashicorp.com/terraform/language/meta-arguments/for_each)

コレクション型(list、map、set)に関しては、**要素の型はすべて同じでなければならない**という点に注意が必要です。

参照リンク: [Terraform Collection Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#collection-types)

## ****Structural Types(構造型)****

![004.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-variable/004.jpg)

構造型（structural types）はコレクション型とは違い、異なる型を持つ複数の要素を1つの値としてまとめることができます。構造型には、object型とtuple型の2つがあります。

### object

object型では、一つ一つの要素に対して<キー = 型>と記述し、型を指定することができます。これにより、stringとnumberなど異なる型を一つの変数内で扱うことができるようになります

```bash
variable "employee" {
  type = object({
    name   = string
    age    = number
    active = bool
  })
  default = {
    name   = "John Doe"
    age    = 32
    active = true
  }
}
```

### tuple

tupleは、異なる型の値を一定の順序で格納するためのデータ型です。

```bash
variable "person_info" {
  type = tuple([string, number, bool])
  default = ["Alice", 30, true]
}
```

tupleの値は順序が重要とされており、型と要素の順番が異なる場合にはエラーが発生するため注意が必要になります。

```bash
variable "sample_tuple" {
  type = tuple([string, number, bool])
  default = [30, "Alice", true] // 順序が変わったため、型の定義と合わなくなってしまいエラーになります
}
```

参照リンク: [Terraform Structural Types](https://developer.hashicorp.com/terraform/language/expressions/type-constraints#structural-types)

## まとめ

この記事では、Terraformにおけるinput変数(Variable)の定義方法について解説しました。

コレクション型では要素の型は同じでなければいけないこと、構造型では異なる要素の型を定義すすることができることなど、それぞれの型に応じて違いがあることを理解して変数を定義する必要があります。

今回の記事がTerraformを学ぶ方の一助になれば幸いです。

こちらの記事では、Terraformにおけるinput変数、Variableについて解説します。Terraformとは、IaC(Infrastructure as Code)を実現するための構成管理ツールの一つです。

Terraformのinput変数の基本的な定義方法 Variableとは

# 【IaC】Terraformで定義したinput変数への値の渡し方について解説

こちらの記事では、Terraformで定義したinput変数への値の渡し方について解説します。Terraformとは、IaC(Infrastructure as Code)を実現するための構成管理ツールの一つです。Terraformの変数にはinput、local、outputの3つの種類があります。今回はこの3つの変数のうちの一つ、input変数への値の渡し方について解説していきます。

Terraformのinput変数の定義方法については以下の記事をご覧ください。

[https://envader.plus/article/190](https://envader.plus/article/190)

また、IaCについては以下の記事で解説しています。

[https://envader.plus/article/136](https://envader.plus/article/136)

## input変数を使うメリットとは？

Terraformにおいて、input変数は設定ファイルを再利用して異なる環境や条件でインフラストラクチャを管理する際に非常に便利です。input変数を使用すると、設定ファイルの中で変数を定義しそれらの値を後で変更できるため、コードの柔軟性と再利用性が向上します。

## コードの柔軟性と再利用性とは？

input変数を使用することでコードの柔軟性と再利用性が向上すると述べました。これを具体的にコマンドラインで値を渡す例を用いて解説します。

企業やプロジェクトでは通常、開発環境、ステージング環境、本番環境など、異なる環境で同じインフラストラクチャが必要になります。しかし、コスト面やその他の観点からこれらの環境間で全く同じ環境を必要とするわけではなく、少しだけ変更したい場合があります。例えば、開発環境ではインスタンスを小さいサイズ、本番環境ではインスタンスサイズを大きくしたい、といった場合です。

ここで、Terraformのinput変数を使うと、同じコードを異なる環境で利用することが非常に簡単になります。以下の変数を定義していた場合を例に説明します。

```bash
# プロジェクトの環境を定義
variable "environment" {
  description = "Deployment environment"
}

# インスタンスサイズを定義
variable "instance_size" {
  description = "EC2 instance size"
}
```

先述した変数定義をもとに開発環境を構築する場合、コマンドラインから値を渡す際には以下のようになります。

```bash
terraform plan -var 'environment=dev' -var 'instance_size=t2.micro'
```

一方、本番環境ではインスタンスサイズを大きくしたいため、以下のように値を渡します。

```bash
terraform plan -var 'environment=prod' -var 'instance_size=m5.large'
```

このように開発環境と本番環境で渡す値を変更するだけで、インスタンスサイズを変更することができるため再利用性を高めることができます。また、ソースコードを直接編集することなく変更を行うことができるため、柔軟性があるとも言えるでしょう。

開発環境や本番環境については、以下の記事にて解説しています。

[https://envader.plus/article/134](https://envader.plus/article/134)

## input変数へ値を渡す方法

![001.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-value/001.jpg)

input変数へ値を渡すには、コマンドライン、.tfvarsファイル、環境変数の3つから渡すことができます。

Terraformのinput変数は、variableブロックを使用しその変数の型や説明を記述することができます。ただ、この段階では変数を定義しているだけのため、変数の値は別途渡してあげる必要があります。(デフォルト値を設定している場合を除く)

### 変数の定義

今回は以下の変数を定義し、その変数に対して値を渡していきます。

```bash
variable "vpc_cidr" {
  description = "The CIDR block for the VPC"
  type        = string
}

variable "subnet_cidrs" {
  description = "The CIDR block for the subnet"
  type        = list(string)
}
```

## コマンドラインから値を渡す

コマンドラインで変数の値を渡すには、terraform planコマンドやterraform applyコマンドを実行する際に-varオプションを使用します。

```bash
terraform plan -var="変数名=渡したい値"

terraform plan -var="vpc_cidr=10.0.0.0/16"
```

vpc_cidrとsubnet_cidrs変数に同時に値を渡したい場合には、-varオプションを複数指定します。

```bash
terraform plan -var="vpc_cidr=10.0.0.0/16" -var='subnet_cidrs=["10.0.1.0/24","10.0.2.0/24"]'
```

Windowsのコマンドプロンプトでは扱いが若干違うため注意が必要です。

[Input Variables on the Command Line](https://developer.hashicorp.com/terraform/cli/commands/plan#input-variables-on-the-command-line).

また、-var-fileオプションを使用することで、terraform.tfvarsなど別のファイルに変数を定義し、そのファイルを指定することができます。

```bash
terraform plan -var-file="terraform.tfvars"
```

## 変数定義ファイルから値を渡す

![002.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-value/002.jpg)

.tfvarsファイル、.tfvars.jsonファイルを作成することで、変数の値を渡すことができます。

Terraformでは、.tfvars、.tfvars.jsonファイルが存在している場合、自動的にそのファイルを読み込む設定になっています。作成したファイルの中に変数名と値を記述することで、その値を渡すことができます。

```bash
# .terraform.tfvars
vpc_cidr = "10.0.0.0/16"

subnet_cidrs = [ "10.0.1.0/24", "10.0.2.0/24" ]
```

tfvars.jsonファイルを作成する場合、記述方法はjson形式にする必要があるため注意が必要です。

```bash
# terraform.tfvars.json
{
  "vpc_cidr": "10.0.0.0/16",
  "subnet_cidrs": ["10.0.1.0/24","10.0.2.0/24"]
}
```

## 環境変数を設定する

環境変数を設定して値を渡すこともできます。

```bash
export TF_VAR_変数名='渡したい値'

export TF_VAR_vpc_cidr='10.0.0.0/16'

# listで値を渡す場合
export TF_VAR_subnet_cidrs='["10.0.1.0/24","10.0.2.0/24"]'
```

環境変数へ値を設定すると、.tfvarsファイルや-varオプションを使用せずに値を渡すことができます。環境変数の値を文字列として渡す場合には、シングルクウォートで囲むことで値を渡すことが可能です。

ただ、リストやマップ、オブジェクト型などの値を渡すには記述方法が複雑になり、エスケープ処理などを考慮する必要が出てきます。そのため公式では変数の型が複雑な場合、コマンドラインや環境変数ではなく、.tfvarsファイルなどの変数定義ファイルから値を渡すことが推奨されています。

[Complex-typed Values](https://developer.hashicorp.com/terraform/language/values/variables#complex-typed-values)

実際に環境変数を設定する場面としては、認証情報やデータベースのパスワードなどの機密情報を扱う場面が挙げられます。

```bash
export AWS_ACCESS_KEY_ID='XXXXXXXXXXXXX'
export AWS_SECRET_ACCESS_KEY='XXXXXXXXXXXXXX'
```

## 変数が読み込まれる順番

![003.jpg](https://storage.googleapis.com/envader-article-images/terraform-input-value/003.jpg)

Terraformでは、変数が読み込まれる際には順番があります。これは、変数定義ファイルの.tfvarsファイルとコマンドラインや環境変数で同じ変数に値を渡した時に適用される順番があるということです。

![input-variable-1.png](https://storage.googleapis.com/envader-article-images/terraform-input-value/input-variable-1.png)

図のように初めに環境変数が読み込まれ、その後に.tfvarsファイル、.tfvars.jsonファイルと進みます。コマンドラインから値を渡す場合には、その値が環境変数や.tfvarsファイルの値を上書きし、優先的に使用されます。

## input変数の参照方法

それぞれinput変数へ値を渡す方法を紹介しました。最後にinput変数への参照方法を解説します。渡した値を参照するには、var.vpc_cidrのように記述し値を参照します。

```bash
# VPCのCIDRブロックを設定する例
resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr
}
```

このように記述することで、input変数へvpc_cidrとして10.0.0.0/16の値を渡していた場合、VPCには10.0.0.0/16のCIDRブロックが適用されます。

## まとめ

今回はinput変数への値の渡し方について解説しました。

input変数へ値を渡す方法としては以下の3つの方法があります。

- コマンドラインから値を渡す
- .tfvarsファイル、.tfvars.jsonファイルなどの変数定義ファイルから値を渡す
- 環境変数を設定する

それぞれの方法についても理解しておくことはもちろん、変数の読み込まれる順番についてもしっかりと理解し運用を行っていきましょう。

Terraformの変数にはinput、local、outputの3つの種類があります。今回はこの3つの変数のうちの一つ、input変数への値の渡し方について解説していきます。

【IaC】Terraformで定義したinput変数への値の渡し方について解説

# tfstateファイルについての基礎 コアやプロバイダ、tfstateファイルの役割について理解しよう

Terraformのtfstateファイルは、Terraformによって管理されるインフラリソースの実際の状態をJSON形式で保存したファイルです。このファイルには現状のリソースの状態が保存されています。Terraformは`terraform apply`が実行されるたびにこのファイルを参照・更新し、構築したいインフラの状態と現在のインフラの状態との差分を判断します。

この記事では、Terraformの基本的な構成要素であるコア、プロバイダついて解説し、tfstateファイルの役割や注意点について解説します。

## Terraformの主要な構成要素

![tfstate-1.png](https://storage.googleapis.com/envader-article-images/terraform-tfstate-file/tfstate-1.png)

はじめにTerraformを利用する際に理解しておくべき2つの構成要素を解説します。tfstateファイルが作成される際に大きく関わってくるのが、次に紹介するTerraformコアとTerraformプロバイダです。

[Perform CRUD operations with providers](https://developer.hashicorp.com/terraform/tutorials/providers/provider-use)

### コア

![tfstate-2.png](https://storage.googleapis.com/envader-article-images/terraform-tfstate-file/tfstate-2.png)

Terraformを実行する上で重要な役割を担っているのがコアです。このコアが、構築したいリソースの設定が書かれた拡張子が.tfのファイル（**以降tfファイル**）の読み取りや、tfstateファイルに現在のリソースの状態を書き込む動作を行います。

また、後述する「プロバイダ」へ、読み込んだ設定でリソースを作成、変更、削除を行うよう依頼するのもコアの役割です。

例えば、`terraform apply`コマンドを実行した場合に、コアがプロバイダへリソースの作成、変更、削除を実行するように依頼し、プロバイダがその依頼をもとに環境を構築します。その際にコアがクラウド上のリソース情報を読み取り、tfstateファイルへ状態を書き込みます。

このように、Terraformコアはtfファイルを読み込むことでどのようなリソースを構築するのかを理解し、プロバイダを利用してどんな操作をするのかを判断する役割を担っています。

`terraform apply`コマンドなどの詳細については、以下の記事で解説しています。

[https://envader.plus/article/162](https://envader.plus/article/162)

また、Terraformのinput変数については以下のリンク記事をご覧ください。

[https://envader.plus/article/190](https://envader.plus/article/190)

### プロバイダ

![tfstate-3.png](https://storage.googleapis.com/envader-article-images/terraform-tfstate-file/tfstate-3.png)

プロバイダは先述したコアと実際に構築したいサービスなどとの架け橋のような役割を果たします。Terraformがサポートするクラウドサービスやそのほかのサービスとの間で、APIを利用して具体的な操作を行うのがプロバイダです。

例えば、AWSのEC2インスタンスを作成する場合、コアから依頼を受けた内容をもとに具体的なリソースの変更を行うのはAWSプロバイダが行っています。

また、プロバイダにはバージョンがあり定期的に更新されます。プロバイダのバージョンが更新されることで、新しいサービスやリソースをTerraformで利用できるようになります。

プロバイダは開発する環境へインストールする必要がありますが、`terraform init`コマンドを実行することで自動的にインストールされます。

[Providers](https://developer.hashicorp.com/terraform/language/providers)

## tfstateファイルとは？

tfstateファイルは、クラウド上に構築されたリソースの**現在の状態**を記録したファイルで、JSON形式で記述されています。

`terraform apply`コマンドを実行すると、デフォルトではterraform.tfstateというファイルがコマンドを実行したディレクトリへ作成されます。

Terraformは、あるべき姿を記述したtfファイルと、リソースの現状を記録したtfstateファイルの情報をもとに二つのファイルの差分を計算し、新しくリソースを作成、更新、または削除するのかを判断します。

tfstateファイルはTerraformの動作の中心的な部分であり、Terraformが何を行うべきか、またどのリソースがどの状態にあるかを知るための主要な情報源といって良いでしょう。

[State](https://developer.hashicorp.com/terraform/language/state)

### tfstateファイルのキーとその説明

tfstateファイルはJSON形式で記述されていると先述しました。サンプルで以下のようなtfstateファイルを作成しました。

```json
{
  "version": 4,
  "terraform_version": "1.4.6",
  "serial": 15,
  "lineage": "b024f1a9-cd64-4f9d-9a30-8a63f3b2e812",
  "outputs": {
    "vpc_id": {
      "value": "vpc-a1b2c3d4",
      "type": "string"
    }
  },
  "resources": [
    {
      "module": "module.root",
      "mode": "managed",
      "type": "aws_instance",
      "name": "example_instance",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "i-0123456789abcdef0",
            "ami": "ami-0c55b159cbfafe1f0",
            "instance_type": "t2.micro",
            "tags": {
              "Name": "ExampleInstance"
            },
            "availability_zone": "ap-northeast-1a"
          }
        }
      ]
    }
  ],
  "depends_on": [
    "aws_security_group.example"
  ],
  "initialized": true
}
```

それぞれの主要なキーと内容は次の表のとおりです。

| キー | 説明 |
| --- | --- |
| version | tfstateファイルのフォーマットバージョンを示す。 |
| terraform_version | tfstateファイルを作成または更新した際のTerraformのバージョン。 |
| serial | tfstateファイルの更新回数を示す。 |
| lineage | tfstateファイルの一意の識別子。UUID |
| outputs | Terraformコードで定義された出力変数の現在の値を示す。 |
| resources | 定義されたリソースに関する情報の配列。 |
| depends_on | リソースまたはモジュール間の依存関係を示す。 |
| initialized | プロジェクトが初期化されているかどうかを示すブール値。 |

## tfstateファイルが必要な理由

tfstateファイルはTerraformのtfファイルと、クラウド上の実際のリソースとの間での仲介役を果たします。例を挙げると、tfファイルで「aws_instance.main」と記述してサーバーを構築すると、実際のクラウド上には「i-abcd1234」のような一意のIDを持つインスタンスが作成されます。このようなコードと実際のリソースとの対応関係を記録しておくのがtfstateファイルの役目です。

![tfstate-4.png](https://storage.googleapis.com/envader-article-images/terraform-tfstate-file/tfstate-4.png)

特に、クラウド上に複数のサーバーが既に存在する状況では、tfファイルで定義した「aws_instance.main」が実際にはどのサーバーに該当するのかを判別するのは難しいものです。しかし、tfstateファイルには「aws_instance.main」が「i-abcd1234」というIDを持つサーバーであることが記されているため、これによりtfファイルとクラウドのサーバーとの紐づけが容易になります。

![tfstate-5.png](https://storage.googleapis.com/envader-article-images/terraform-tfstate-file/tfstate-5.png)

## tfstateファイルの管理方法

tfstateファイルを管理する方法には、ローカルで管理する方法と、AWS S3やAzure Blob Storage、Terraform Cloudなどのリモートバックエンドのサービスを利用する方法の二通りがあります。

ローカルで管理する際の注意点として、PCが壊れてしまうとtfstateファイルも失われてしまうことや、チーム開発でTerraformを利用する場合には複数人で同じtfstateファイルを共有することが難しいなどが挙げられます。

### チーム開発時にローカルでtfstateファイルを共有するのが難しい理由

複数人でローカルにあるtfstateファイルを共有する状況を考えた場合、まず最新のtfstateファイルを全員で共有することが難しいことが挙げられます。tfstateファイルは、管理されているインフラの現在の状態を詳細に反映しているため、一度でも更新が行われるとその内容は古いものとなり、他のメンバーが持つtfstateファイルの情報との間でずれが生じます。

![tfstate-6.png](https://storage.googleapis.com/envader-article-images/terraform-tfstate-file/tfstate-6.png)

このずれが生じると、問題が生じるリスクが増大します。例えば、Aさんがtfstateファイルを更新した直後に、Bさんが古いtfstateファイルを基に変更を行った場合、Aさんの変更内容が上書きされるか、最悪の場合、不整合が発生してインフラに影響を及ぼす可能性があります。

さらに、tfstateファイルには様々なクラウドリソースの情報や機密情報が含まれることもあるため、これを適切に管理しつつ共有することも一つの課題となります。万が一、セキュリティの観点から不適切な方法で共有されてしまうと、外部に情報が漏れるリスクも生まれます。

そして、tfstateファイルの変更履歴を追うことは、どの開発者がいつどのような変更を加えたかを明確にする上で非常に重要です。しかし、通常のファイル共有手段を用いると、この履歴の追跡が難しくなります。

これらの点を考慮すると、tfstateファイルをチームで効果的に共有するためには、リモートバックエンドのような専用のツールやサービスの導入が不可欠となります。これにより、同期の問題や情報漏洩に対するセキュリティの課題を解決し、チーム全体でのインフラの管理をスムーズに行うことができるようになります。

### tfstateファイルは手動での更新は推奨されていない

TerraformのtfstateファイルはJSON形式で保存されていますが、これを直接編集することは推奨されていません。理由は、TerraformがCLIを介して安全かつ正確にtfstateの変更を行うための特別なコマンドを提供しているからです。このコマンドがあるおかげで、tfファイルの内容が変更された場合でも、CLIを利用すれば問題なくtfstateファイルの内容を作成、更新、削除することができます。

また、Terraformはtfファイルのコード上で定義した設定と実際のクラウド上のリソースとの間で、1対1の明確な関連性を持つことを前提として動作します。具体的には、Terraformがクラウド上に新しいリソースを作成すると、その情報がtfstateファイルに追加されます。逆に、リソースを削除すると、その情報がtfstateファイルからも取り除かれます。

このような仕組みがうまく機能するためには、tfstateファイルが正確かつ最新であることが極めて重要です。しかし、tfstateファイルを手動で編集する、あるいはTerraformが提供する以外の方法で変更してしまうと、この1対1の関係が狂ってしまう可能性があります。その結果、Terraformは意図しない動作をするかもしれません。そうなった場合、ユーザー自身が問題の原因を特定し、修正する作業が必要となるでしょう。

以上の理由から、Terraformのtfstateを安全に保つためにはtfstateファイルを直接編集するのではなく、CLIのコマンドを活用することが推奨されています。

[Inspection and Modification](https://developer.hashicorp.com/terraform/language/state#inspection-and-modification)

## tfstateファイルをリモートで管理する方法

tfstateファイルの管理をより安全かつ効率的に行うためには、リモートでtfstateファイルを管理します。公式では後述するTerraform Cloudの利用が推奨されています。

[Terraform state](https://developer.hashicorp.com/terraform/language/state)

リモートでの管理は特にチームでの開発において、tfstateファイルを安全に共有し、適切なバージョン管理を行うのに役立ちます。

### **リモートバックエンドの利用**

![tfstate-7.png](https://storage.googleapis.com/envader-article-images/terraform-tfstate-file/tfstate-7.png)

Terraformの「リモートバックエンド」という機能は、tfstateファイルをリモートで安全に保管するための仕組みを提供します。この機能を活用すると、tfstateファイルをクラウドストレージサービス、例えば[Amazon S3](https://aws.amazon.com/jp/s3/)や[Azure Blob Storage](https://azure.microsoft.com/ja-jp/products/storage/blobs)に保存できるようになります。このリモートの保管方法のメリットは、ローカルのPCに問題が発生してもtfstateファイルの紛失リスクが大幅に低減することです。さらに、チーム内でのtfstateの共有が容易になり、同時に変更が行われることによる競合を防ぐロック機能や、過去のバージョンに戻すことができるバージョン管理、そしてtfstateファイルのセキュアな暗号化といったメリットを享受することができます。

### **Terraform Cloudを活用する**

[Terraform Cloud](https://developer.hashicorp.com/terraform/cloud-docs)はHashiCorp社が提供するクラウドサービスで、Terraformの状態管理や実行をクラウド上で行うことができます。特にtfstateファイルの管理においては、自動的なバージョン管理や変更履歴の追跡、アクセス制御などの機能が提供されます。これにより、チームメンバー間でのtfstateファイルの共有や同期が非常に簡単になります。

さらに、Terraform Cloudを使用することでTerraformのプランや適用の操作を中央で一元管理できるため、インフラの変更をより安全に、かつ迅速に行うことができます。

## まとめ

こちらの記事では、Terraformのtfstateファイルの基本について解説しました。

tfstateファイルがあることで、tfファイルに記述したリソースと実際のクラウド上に作成したリソースとを紐づけることが可能になります。そのtfstateファイルは「リモートバックエンド」を活用して複数人で共有することが可能です。

どのようなリモートバックエンドを利用するのかはユースケースに応じて検討する必要があります。

また、コアやプロバイダがどのような役割を担っているのかもしっかりと押さえておきたいところです。

この記事では、Terraformの基本的な構成要素であるコア、プロバイダついて解説し、tfstateファイルの役割や注意点について解説します。

tfstateファイルについての基礎 コアやプロバイダ、tfstateファイルの役割について理解しよう

こちらの記事では、Terraformの組み込み関数についての基本的な構文と使用例について解説します。

Terraformの組み込み関数とは？elementやlookupなどの基本構文と使用例を学ぶ

# TerraformでAWS RDS/Auroraの時限起動を設定し、コストを削減

![https://storage.googleapis.com/envader-article-images/eventbridge-scheduler/002.png](https://storage.googleapis.com/envader-article-images/eventbridge-scheduler/002.png)

## この記事の目的

この記事では、AWSのデータベースサービスであるRDSとAuroraについて簡単に触れた後、なぜコスト削減が大事なのか、そしてそのためにどうやってTerraformを使うのかを紹介していきます。

### AWS RDS/Auroraって何？

簡単に言うと、AWSの中でデータベースを動かすためのサービスです。Auroraはその中でも特に高速で、MySQLやPostgreSQLと互換性があります。

### コスト削減って大事？

結論から言うと、めちゃくちゃ大事です。データベースを24時間稼働させるのはコストがかかるし、実はそんなにずっと動かしておく必要はないんです。そこで、無駄な時間にデータベースを止めてコストを減らす方法を考えました。

### Terraformって何するの？

Terraformは、クラウドの設定をコードで書いて管理するツール。このツールを使えば、データベースの時限起動などの設定を簡単にできます。下記の記事で大体のことがわかります。この記事では、Terraformの導入が済んでいる前提でコードを紹介していきます。

https://envader.plus/article/136

## AWS RDS/Auroraのコスト構造

AWS RDSとAuroraのコストはいくつかの要素に分かれています。それぞれの要素を理解することで、無駄なコストを削減するヒントを見つけることができます。

### 時間単位の課金について

AWS RDSとAuroraは、インスタンスを起動している時間に応じて課金されます。つまり、インスタンスが動いている時間だけ料金がかかります。夜間や休日など、利用者が少ない時間帯にインスタンスを停止することでコストを節約することができます。ただし、Aurora v2のクラスターは、現在のところ停止する機能が提供されていないため、この点には注意が必要です。

### ストレージやデータ転送のコスト

データベースのストレージサイズやI/O、データのバックアップにもコストがかかります。また、データベースと他のサービスやアプリケーションとの間でのデータ転送量にも料金が発生します。不要なデータの削除や、転送量の最適化を行うことで、こちらのコストも削減できます。

### どの部分でコスト削減が可能か

#### 時限起動

前述の通り、利用者が少ない時間帯にデータベースを停止することで、時間単位の課金を節約。ただし、Aurora v2のクラスターは停止ができない点を考慮する必要があります。

#### データ管理

古いデータや不要なデータを定期的に削除することで、ストレージコストを削減。

#### 最適なインスタンスタイプの選択

使用するデータベースのワークロードに合わせて、最もコストパフォーマンスの良いインスタンスタイプを選択することで、無駄なコストを避けることができます。

この記事ではタイトルの通りインスタンスの時限起動をTerraformを使用して実現します。

## Terraformで作成するメリット

![https://storage.googleapis.com/envader-article-images/eventbridge-scheduler/001.png](https://storage.googleapis.com/envader-article-images/eventbridge-scheduler/001.png)

Terraformはクラウドインフラストラクチャのプロビジョニングと管理のためのツールとして、多くのエンジニアから支持を受けています。それにはいくつかの明確なメリットがあります。

### 1. コードベースの管理

TerraformはInfrastructure as Code (IaC) のアプローチを採用しています。これにより、インフラの構成をコードとして明示的に記述できるため、再現性とトレーサビリティが高まります。

### 2. プラットフォーム非依存

TerraformはAWSだけでなく、多くのクラウドプロバイダーやサービスに対応しています。これにより、複数のクラウド環境での構成を一貫して管理することができます。

### 3. 状態の管理

Terraformはインフラの状態を管理する機能を持っています。これにより、現在のインフラの状態とコードで記述された状態との差分を簡単に確認でき、意図しない変更を防ぐことができます。

この他にもメリットはありますが、リソースをコードで管理するにあたり上記のメリットだけでも十分であることがわかります。

## Terraformのコード

### variables.tf

次の変数をvariables.tfに記述し準備します。

```bash
aurora_schedule_target {}
rds_schedule_target {}
```

### terraform.tfvars

次の変数をterraform.tfvarsに記述します。

```bash
aurora_schedule_target = {
    aurora-instance = ["cron(00 08 ? * MON-FRI *)", "cron(00 20 ? * MON-FRI *)"],
}

rds_chedule_target = {
    rds-instance = ["cron(00 08 ? * MON-FRI *)", "cron(00 20 ? * MON-FRI *)"],
}
```

#### 定義

aurora-instance: Aurora インスタンスの ARN
rds-instance: RDS インスタンスの ARN

#### スケジュール

cron(00 08 ? * MON-FRI *): 月曜日から金曜日の午前 8 時に起動
cron(00 20 ? * MON-FRI *)：月曜日から金曜日の午後 8 時に停止

#### 説明

Aurora インスタンスと RDS インスタンスの両方を、月曜日から金曜日の午前 8 時に起動して、午後 8 時に停止するように設定しています。

## Auroraインスタンスの停止と起動

イベントブリッジのスケジューラ機能を使用します。

aurora-scheduler.tf

```bash
# ==============================
# = Aurora Auto Scheduler
# ==============================

# スケジュールに基づいてAuroraクラスターを起動する設定
resource "aws_scheduler_schedule" "aurora-start" {
  for_each    = var.aurora_schedule_target              # 起動スケジュールのターゲット情報
  name        = "${each.key}-scheduled-start"           # スケジュールの名前
  description = "Scheduled start action for Aurora ${each.key}"  # スケジュールの説明
  group_name  = "default"                               # スケジュールのグループ名

  flexible_time_window {
    mode = "OFF"  # フレックスタイムウィンドウは使用しない
  }

  schedule_expression          = each.value.0          # 起動するスケジュールの式
  schedule_expression_timezone = "Asia/Tokyo"          # タイムゾーンの指定

  # スケジュールのターゲット情報
  target {
    arn      = "arn:aws:scheduler:::aws-sdk:rds:startDBCluster"  # RDSのクラスターを起動する操作のARN
    role_arn = data.aws_iam_role.scheduler_role.arn              # スケジュール操作のIAMロールのARN

    input = jsonencode({
      DbClusterIdentifier = "${each.key}"  # 起動するクラスターの識別子
    })

    # リトライポリシーの設定
    retry_policy {
      maximum_event_age_in_seconds = 600   # リトライする最大のイベントの経過時間：10分
      maximum_retry_attempts       = 10    # リトライの最大回数
    }
  }
}

# スケジュールに基づいてAuroraクラスターを停止する設定
resource "aws_scheduler_schedule" "aurora-stop" {
  for_each    = var.aurora_schedule_target              # 停止スケジュールのターゲット情報
  name        = "${each.key}-scheduled-stop"            # スケジュールの名前
  ddescription = "Scheduled stop action for Aurora ${each.key}"  # スケジュールの説明
  group_name  = "default"                               # スケジュールのグループ名

  flexible_time_window {
    mode = "OFF"  # フレックスタイムウィンドウは使用しない
  }

  schedule_expression          = each.value.1          # 停止するスケジュールのcron式
  schedule_expression_timezone = "Asia/Tokyo"          # タイムゾーンの指定

  # スケジュールのターゲット情報
  target {
    arn      = "arn:aws:scheduler:::aws-sdk:rds:stopDBCluster"   # RDSのクラスターを停止する操作のARN
    role_arn = data.aws_iam_role.scheduler_role.arn              # スケジュール操作のIAMロールのARN

    input = jsonencode({
      DbClusterIdentifier = "${each.key}"  # 停止するクラスターの識別子
    })

    # リトライポリシーの設定
    retry_policy {
      maximum_event_age_in_seconds = 600   # リトライする最大のイベントの経過時間：10分
      maximum_retry_attempts       = 10    # リトライの最大回数
    }
  }
}
```

## RDSインスタンスの停止と起動

こちらもイベントブリッジのスケジューラ機能を使用します。

rds-scheduler.tf

```bash
# ==============================
# = RDS Auto Scheduler
# ==============================

# スケジュールに基づいてRDSクラスターを起動する設定
resource "aws_scheduler_schedule" "rds-start" {
  for_each    = var.rds_schedule_target                 # 起動スケジュールのターゲット情報
  name        = "${each.key}-scheduled-start"           # スケジュールの名前
  description = "Scheduled start action for RDS ${each.key}"  # スケジュールの説明
  group_name  = "default"                               # スケジュールのグループ名

  flexible_time_window {
    mode = "OFF"  # フレックスタイムウィンドウは使用しない
  }

  schedule_expression          = each.value.0          # 起動するスケジュールの式
  schedule_expression_timezone = "Asia/Tokyo"          # タイムゾーンの指定

  # スケジュールのターゲット情報
  target {
    arn      = "arn:aws:scheduler:::aws-sdk:rds:startDBCluster"  # RDSのクラスターを起動する操作のARN
    role_arn = data.aws_iam_role.scheduler_role.arn              # スケジュール操作のIAMロールのARN

    input = jsonencode({
      DbClusterIdentifier = "${each.key}"  # 起動するクラスターの識別子
    })

    # リトライポリシーの設定
    retry_policy {
      maximum_event_age_in_seconds = 600   # リトライする最大のイベントの経過時間：10分
      maximum_retry_attempts       = 10    # リトライの最大回数
    }
  }
}

# スケジュールに基づいてRDSクラスターを停止する設定
resource "aws_scheduler_schedule" "rds-stop" {
  for_each    = var.rds_schedule_target                 # 停止スケジュールのターゲット情報
  name        = "${each.key}-scheduled-stop"            # スケジュールの名前
  ddescription = "Scheduled stop action for RDS ${each.key}"  # スケジュールの説明
  group_name  = "default"                               # スケジュールのグループ名

  flexible_time_window {
    mode = "OFF"  # フレックスタイムウィンドウは使用しない
  }

  schedule_expression          = each.value.1          # 停止するスケジュールのcron式
  schedule_expression_timezone = "Asia/Tokyo"          # タイムゾーンの指定

  # スケジュールのターゲット情報
  target {
    arn      = "arn:aws:scheduler:::aws-sdk:rds:stopDBCluster"   # RDSのクラスターを停止する操作のARN
    role_arn = data.aws_iam_role.scheduler_role.arn              # スケジュール操作のIAMロールのARN

    input = jsonencode({
      DbClusterIdentifier = "${each.key}"  # 停止するクラスターの識別子
    })

    # リトライポリシーの設定
    retry_policy {
      maximum_event_age_in_seconds = 600   # リトライする最大のイベントの経過時間：10分
      maximum_retry_attempts       = 10    # リトライの最大回数
    }
  }
}
```

これらのファイルを作成し、`terraform init`, `terraform plan` `terraform apply`することでRDSとAuroraの時限稼働が実現できます。

## インスタンスの時限稼働で得られるコスト削減効果

### 730時間使用

db.m5.large インスタンスのオンデマンド料金は、1時間あたり 0.235USD です。そのため、月に730時間使用する場合は、以下のようになります。

730 時間 * $0.235/時間 = $174.05

### 平日のみ使用

平日の朝8時から夜20時までしか起動しない場合は、以下のようになります。

平日のみ使用時間 = 24時間 * 5日 = 120時間
コスト = 120時間 * $0.235/時間 = $28.20

### コスト削減効果

平日の朝8時から夜20時までしか起動しないパターンでは、730時間使用する場合と比較して、以下のようになります。

コスト削減効果 = $174.05 - $46.52 = $127.53
つまり、平日の朝8時から夜20時までしか起動しないパターンでは、730時間使用する場合と比較して、約 73% のコスト削減効果が期待できます。

## まとめ

AWS RDS/Aurora の時限稼働は、EventBridgeのschedulerを使用することにより利用頻度の低いデータベースを平日の夜間や休日に停止することで、コスト削減を実現できます。

Terraform を使用してEbentBridgeを設定すると、以下のメリットがあります。

- 複数のインスタンスに対して一括で設定を変更できる
- インスタンスの追加や削除に合わせて、設定を自動的に更新できる
- 本番環境への適用は慎重に検討する必要がありますが、開発環境やステージング環境への導入は積極的に検討すると良いでしょう。

具体的には、以下のようになります。

- Terraform で時限起動を設定することで、複数のインスタンスに対して一括で設定を変更できるため、運用性が向上します。
- 時限起動を活用することで、平日の夜間や休日に停止することで、コスト削減を実現できます。
- 本番環境への適用は、データベースの可用性やパフォーマンスへの影響、運用体制の変更などの観点から慎重に検討する必要があります。


この記事では、AWSのデータベースサービスであるRDSとAuroraについて簡単に触れた後、なぜコスト削減が大事なのか、そしてそのためにどうやってTerraformを使うのかを紹介していきます。

TerraformでAWS RDS/Auroraの時限起動を設定し、コストを削減

# IAMエンティティを理解する ユーザー・グループ・ロールの基本

![https://storage.googleapis.com/envader-article-images/iam-entity-intro/001.png](https://storage.googleapis.com/envader-article-images/iam-entity-intro/001.png)

## この記事の目的

この記事は、AWSのIAMサービスの基本的な概念と使用方法を初心者の方に分かりやすく解説し、安全かつ効果的なAWSリソースの管理の第一歩としてIAMの重要性を理解してもらうことを目的としています。

### IAMとは何か？

IAM (Identity and Access Management) は、AWSのサービスの中で、ユーザーやアプリケーションがAWSリソースにどのようなアクセスを持つかを管理・制御するサービスです。

### なぜIAMが重要なのか？

AWSを使用する上で、誰がどのリソースにどのようなアクセスを持つかを明確に管理することは、セキュリティの観点から非常に重要です。IAMを適切に設定することで、不要なアクセスを制限し、リソースのセキュリティを向上させることができます。

### IAMエンティティを理解することの意義

IAMエンティティ、つまりユーザー、グループ、ロールなどの概念を理解することは、AWSのセキュリティ設定の基盤となります。これらのエンティティがどのように連携し、アクセス制御を実現するのかを把握することで、より適切なアクセス権限の設定や管理が可能となります。本記事を通じてIAMエンティティの基本的な知識を習得し、AWS環境でのセキュリティ対策を理解していきましょう。

## IAMエンティティの基本

エンティティとは実体を意味し、データベースやシステムにおいて、個別に識別可能な要素やオブジェクトを表す概念です。IAMエンティティは、AWSリソースへのアクセスを許可するAWSのIDとアクセス許可管理サービスです。IAMエンティティとは、AWSリソースへのアクセスを制御するためのものです。

### ユーザー

IAMユーザーは、AWSリソースにアクセスする個人やサービスです。ユーザーは、コンソールへのログイン認証情報やAPIのアクセスキーを持つことができ、これによってAWSのリソースへのアクセスが許可されます。

### グループの役割

IAMグループは、複数のIAMユーザーをまとめるためのコンテナです。グループ自体には認証情報は存在せず、主にアクセスポリシーの適用という形での役割があります。特定のアクセスポリシーをグループに割り当てることで、そのグループに所属する全ユーザーに同じ権限が一括で適用されるため、ユーザー管理が効率的に行えます。

### ロールの利点

IAMロールは、特定の状況やタスクでAWSリソースに一時的にアクセスする必要がある場合に使用される特別なエンティティです。例えば、EC2インスタンスがS3バケットにデータを保存する場合や、別のAWSアカウントのリソースにアクセスする場合など、ロールを使用して一時的なアクセス権限を付与することができます。ロールの主な利点は、永続的な認証情報を持たない点であり、必要な期間やタスクのみ権限を持つことができるため、セキュリティリスクを最小限に抑えることができます。

ロールとポリシーについて詳しくは次の記事で解説しています。

https://envader.plus/article/247

## IAMユーザーの作成と管理

![https://storage.googleapis.com/envader-article-images/iam-entity-intro/003.png](https://storage.googleapis.com/envader-article-images/iam-entity-intro/003.png)

### ユーザーの作成方法

AWSのIAMユーザーは、いくつかの方法で作成することができます。

#### AWSマネジメントコンソール

ブラウザベースのインターフェースを使用して、手動でユーザーを作成。簡単なステップに従って情報を入力し、ユーザーの作成と設定が可能です。

#### CLI (Command Line Interface)

コマンドラインを使用して、スクリプトや一連のコマンドでユーザーを迅速に作成。特に大量のユーザーを一度に作成する際などに便利です。

#### SDK

AWSの提供するソフトウェア開発キットを使用して、プログラム的にユーザーを作成。アプリケーションやシステムとの統合時に役立ちます。

### IaC(Infrastracture as Code)

CroudFomationやTerraformといったIaCツールのコードで作成します。一貫性と保守性が向上します。以下はサンプルコードです。
sample-iam-userというユーザーをsysytemパスに作成しPurpose（目的）タグを付与しています。

```bash
resource "aws_iam_user" "sample_user" {
  name = "sample-iam-user"
  path = "/system/"
  
  tags = {
    "Purpose" = "Sample IAM User Creation using Terraform"
  }
}
```

### アクセスキーの取り扱い

IAMユーザーがAWSサービスにプログラム的にアクセスする際には、アクセスキー (Access Key ID) とシークレットキー (Secret Access Key) が必要です。
重要性: アクセスキーとシークレットキーは、ユーザーの認証情報の一部として機能します。これらのキーを持っている者は、そのユーザーとしてAWSリソースにアクセスすることができるため、非常に慎重な取り扱いが求められます。

### 安全な管理・保管方法

#### キーは絶対に公開しない

公開場所やソースコードにキーを直接記載しないこと。

#### 定期的にキーのローテーションを行う

古いキーを無効にし、新しいキーを発行することで、セキュリティリスクを低減します。

#### 不要なキーは削除

使用していないキーは削除し、必要最低限のキーのみを保持することを心がける。

#### キーのアクセスを制限

キーの情報を必要とする者のみに共有し、それ以外の者からはアクセスできないようにする。

## IAMグループとアクセス制御

![https://storage.googleapis.com/envader-article-images/iam-entity-intro/002.png](https://storage.googleapis.com/envader-article-images/iam-entity-intro/002.png)

IAMのベストプラクティスとして、ポリシーはグループにアタッチし、ユーザーを該当するグループに所属させることが推奨されます。これにより一貫したアクセス権限の提供と効率的な権限管理が可能となり、セキュリティの向上も期待できます。

### グループの作成手順

1. AWSマネジメントコンソールにログイン後、IAMダッシュボードを開きます。
2. 左側のナビゲーションペインで「グループ」を選択し、「新しいグループの作成」をクリックします。
3. 必要な情報を入力し、ユーザーをグループに追加することができます。

### グループを利用したアクセス権限の設定

- グループの詳細ページから「ポリシーのアタッチ」をクリックします。
- 必要なポリシーを選択し、グループに割り当てることで、そのグループに所属するユーザーに指定のアクセス権限が適用されます。

### Terraformのサンプルコード（IAMユーザーをグループに追加）

以下は、Terraformを使用してIAMユーザーをIAMグループに追加するサンプルコードです。

```bash
# IAMユーザーを作成
resource "aws_iam_user" "sample_user" {
  name = "sample-iam-user"
}

# IAMグループを作成
resource "aws_iam_group" "sample_group" {
  name = "sample-iam-group"
}

# IAMグループにユーザーを追加
resource "aws_iam_group_membership" "sample_membership" {
  name = "sample-membership"

  # IAMユーザーの名前
  users = [
    aws_iam_user.sample_user.name
  ]

  # IAMグループの名前
  group = aws_iam_group.sample_group.name
}
```

このコードでは、まずIAMユーザー`sample-iam-user`とIAMグループ`sample-iam-group`が作成されます。次に、`aws_iam_group_membership`リソースを使用して、該当のユーザーをグループに追加します。

## まとめ

### IAMの基本を押さえる重要性

AWSを利用する際のセキュリティは非常に重要な要素です。IAMはその中心となるサービスであり、適切なアクセス制御を行うための基本的な知識は必須です。正確なユーザー管理やアクセス権限の設定を通じて、AWSリソースの安全性を確保することができます。

### 今後の学習のためのステップ
  
IAMの基本知識を習得した後は、更に応用的な知識や他のAWSサービスとの連携についての学習を進めることをおすすめします。以下の日本語のリソースを参考にしてください。

#### AWS公式ドキュメント

AWSの公式サイトには、IAMをはじめとする各サービスの詳細なドキュメントが提供されています。基本から応用まで幅広く学べるリソースです。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction.html

#### AWSブログ

AWSの公式ブログには、技術的なチュートリアルやユースケース、最新のアップデート情報などが掲載されています。IAMに関する記事も多数あり、実際の運用例などを学ぶことができます。

https://aws.amazon.com/jp/blogs/news/


本記事を通じてIAMエンティティの基本的な知識を習得し、AWS環境でのセキュリティ対策を理解していきましょう。

IAMエンティティを理解する ユーザー・グループ・ロールの基本

# IAMエンティティ応用　IAMロール・ポリシーについて解説

![https://storage.googleapis.com/envader-article-images/iam-entity-applied/001.png](https://storage.googleapis.com/envader-article-images/iam-entity-applied/001.png)

## 本記事の目的

AWSのセキュリティを強化するための主要なサービスであるIAM（Identity and Access Management）には、多くのエンティティと概念が存在します。これらのエンティティの中でも、特に重要な「ロール」と「ポリシー」について、詳細に解説していくことが本記事の目的です。

前回、IAMエンティティの基本についての記事を公開しました。その中でユーザーやグループなどIAMの基本的なエンティティや、それらがどのように連携して機能するのかについて触れました。IAMの奥深い部分をより良く理解するためには、ロールとポリシーの知識がとても役立ちます。今回はこの2つのトピックを詳しく解説していきたいと思います。

### 前回の記事の振り返り

前回の記事では、IAMの基本的なエンティティ、すなわちユーザー、グループ、ロールについて概要を紹介しました。ユーザーはAWSリソースへのアクセスを持つエンティティ、グループは複数のユーザーをまとめるためのエンティティ、ロールは一時的なアクセス権を付与するためのエンティティとして紹介しました。

前回の内容を未読の方や、再度確認したい方は、こちらのリンクから詳細な記事をご覧いただけます。

https://envader.plus/article/246

## IAMロールの深掘り

![https://storage.googleapis.com/envader-article-images/iam-entity-applied/003.png](https://storage.googleapis.com/envader-article-images/iam-entity-applied/003.png)

### IAMロールとは？

IAMロールは、特定のAWSサービスやユーザーが一時的にAWSリソースにアクセスするための中継的な役割を果たします。IAMロールはアクセス許可を持ち、それを一時的に他のエンティティに"貸し出す"ことができます。直接アクセスキーを持たないエンティティでも、ロールを介して特定のリソースにアクセスすることが可能となります。

### 代表的な使用例

#### EC2インスタンス

EC2インスタンスがS3バケットや他のAWSリソースにアクセスする際、直接アクセスキーを持つことなく、IAMロールをアタッチすることで必要な権限を得ることができます。

#### Lambda

Lambda関数がRDSやDynamoDBテーブルなどのデータベースにアクセスする必要がある場合、関数にIAMロールを関連付けることで安全にアクセスすることが可能となります。

### ロールのメリットとデメリット

![https://storage.googleapis.com/envader-article-images/iam-entity-applied/002.png](https://storage.googleapis.com/envader-article-images/iam-entity-applied/002.png)

#### メリット

- セキュリティの向上
    アクセスキーを直接持たないため、キーの漏洩リスクが低減します。
- 柔軟なアクセス管理
    ロールを介して一時的にアクセス権限を付与・変更することができるため、状況に応じた細やかなアクセス制御が可能です。

#### デメリット

- 設定の複雑さ
    IAMロールの設定や関連付け、ポリシーの適用など、初めての方には少々複雑に感じられるかもしれません。
- 適切なポリシーの選択が必要
    ロールに適切なアクセス権限を持つポリシーを関連付ける必要があり、誤った設定はセキュリティリスクとなる可能性があります。

## IAMポリシーの詳細

IAMポリシーは、AWSリソースへのアクセスを制御するためのドキュメントです。このセクションでは、IAMポリシーの種類やその構成、ベストプラクティスについて詳しく解説します。

### マネージドポリシーとインラインポリシーの違い

#### マネージドポリシー

AWSが提供する既存のポリシーであり、複数のIAMエンティティ（ユーザー、グループ、ロール）に再利用可能です。公開されているものや、ユーザーがカスタムで作成したものが含まれます。

#### インラインポリシー

ユーザーが特定のIAMエンティティに直接関連付けるためのカスタムポリシーです。このポリシーは、関連付けられたエンティティにのみ適用され、再利用はできません。

### JSON形式のポリシーの読み方と作成方法
IAMポリシーはJSON形式で記述されます。主要なキーには以下のようなものがあります。

- Effect：ポリシーが許可するか（"Allow"）、拒否するか（"Deny"）を指定します。
- Action：許可または拒否するアクションを指定します。例：s3:ListBucketやdynamodb:PutItemなど。
- Resource：アクションが適用されるリソースを指定します。例：特定のS3バケットやDynamoDBテーブルなど。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::example-bucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem"
      ],
      "Resource": "arn:aws:dynamodb:us-west-1:123456789012:table/example-table"
    }
  ]
}
```

上記のサンプルポリシーでは、example-bucketというS3バケットのリストを表示する権限と、example-tableというDynamoDBテーブルにアイテムを追加する権限が許可されています。

## ポリシーの書き方のベストプラクティス

### 最小権限の原則

必要最低限の権限のみを付与すること。これにより、不正なアクセスや誤操作のリスクを最小限に抑えることができます。

### 明確なリソースの指定

ポリシーでリソースを指定する際は、可能な限り具体的に指定すること。ワイルドカード（*）を使用する場合は注意が必要です。

## IAMロールとポリシーのTerraformによるサンプルコード

Terraformは、AWSなどのクラウドプロバイダのリソースをコード化し、安定した環境を効率的にデプロイするためのツールです。以下は、Terraformを使用してIAMロールとポリシーを作成するサンプルコードです。

### 1. IAMポリシーの作成

```bash
resource "aws_iam_policy" "example" {
  name        = "ExamplePolicy"
  description = "My example policy description"
  
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action   = ["s3:ListBucket"],
        Effect   = "Allow",
        Resource = "arn:aws:s3:::example-bucket"
      }
    ]
  })
}
```

上記のコードは、S3のexample-bucketバケットの内容をリストする権限を持つIAMポリシーを作成します。

### 2. IAMロールの作成

```bash
resource "aws_iam_role" "example" {
  name = "ExampleRole"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRole",
        Principal = {
          Service = "ec2.amazonaws.com"
        },
        Effect = "Allow",
        Sid    = ""
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "example-attach" {
  role       = aws_iam_role.example.name
  policy_arn = aws_iam_policy.example.arn
}
```

上記のコードは、EC2インスタンスがこのロールを引き受けることができるIAMロールを作成し、先に作成したIAMポリシーをそのロールにアタッチします。

これらのコードを適切な.tfファイル（例えばiam.tfなど）に配置し、`terraform init`および`terraform apply`を実行することで、IAMロールとポリシーをAWS上にデプロイできます。

## IAMのベストプラクティス

AWSのIAMを効果的に使用するためのベストプラクティスを以下にまとめます。

### 最小権限の原則

セキュリティの基本的な考え方として、ユーザーやサービスに必要最低限の権限のみを付与する「最小権限の原則」があります。これにより、誤操作や不正アクセスによる損失を最小限に抑えることができます。

### 実践方法

#### ポリシーの作成方法

- AWSが提供するマネージドポリシーを活用する
- 必要な権限を個別に定義してカスタムポリシーを作成する

#### ポリシーの管理方法

- ポリシーのレビューを行う
- ポリシーを定期的に更新する

### ルートユーザーの使用を避ける

AWSアカウントのルートユーザーは、AWSリソースに対する全ての権限を持っています。そのため、このユーザーの認証情報が漏洩すると、AWS環境に甚大なダメージが及ぶ可能性があります。

#### 理由

- セキュリティ上のリスク
    - ルートユーザーは制限なく全ての操作ができるため、不正アクセス時のリスクが極大
    - 誤操作の可能性
    - 意図しない変更や削除が容易

- ルートユーザーの認証情報を複数人で共有するリスク
    - 共有しているうちの1人の認証情報が漏洩すると、AWSアカウントに甚大なダメージが及ぶ可能性

### 定期的なアクセス権限の見直し

組織の変更やプロジェクトの進行に伴い、IAMユーザーやロールの必要な権限は変わる可能性があります。そのため、定期的にアクセス権限の見直しを行うことが重要です。

#### 重要性

- 不要な権限の削除によるセキュリティリスクの低減
    - 過去のプロジェクトや役割で付与された権限が現在も継続している場合、それを削除することでセキュリティリスクを低減
- 新しい権限の追加による作業効率の向上
    - 新しいプロジェクトやタスクのために新しい権限が必要になる場合があります。必要な権限を適切に追加することで、作業の効率を向上させることが可能

## まとめ

AWSのIAMは、クラウドリソースの管理とセキュリティの強化に不可欠です。この記事では、IAMロール、ポリシー、そしてTerraformを使った適切な設定方法について学びました。IAMの設定は複雑であり、継続的な更新が求められますが、正しく適用することで、AWSの使用経験が向上します。これらの知識を活用し、より安全で効率的なAWS環境を追求しましょう。


AWSのセキュリティを強化するための主要なサービスであるIAM（Identity and Access Management）には、多くのエンティティと概念が存在します。これらのエンティティの中でも、特に重要な「ロール」と「ポリシー」について、詳細に解説していくことが本記事の目的です。

IAMエンティティ応用　IAMロール・ポリシーについて解説

# TerraformとEventBridge Schedulerを活用したEC2インスタンスの時限起動によるコスト削減

![https://storage.googleapis.com/envader-article-images/ec2-scheduler/001.png](https://storage.googleapis.com/envader-article-images/ec2-scheduler/001.png)

## この記事の目的

AWSの仮想サーバーAmazon EC2は、多くの企業や個人がクラウド上でのアプリケーションホスティングの主要な選択肢として利用されています。しかし、開発環境やステージング環境など、24時間稼働する必要がないインスタンスが常に稼働していると、不必要なコストが発生します。特に大規模なプロジェクトや多数のインスタンスを運用している場合、これらの余分なコストは企業の負担となり得ます。これらの問題をIaCツールであるTeraformを使用し、EventBridgeのスケジューラーで簡単にコスト削減していきたいと思います。

### この記事で紹介すること

- Terraformを使用してEventBridge Schedulerの設定を自動化する方法
- EC2インスタンスを指定した時間帯だけ起動・停止するスケジュールの設定方法
- この方法を実装することで実際に得られるコスト削減効果の紹介

## TerraformとEventBridge Schedulerの基本

### Terraformとは

Terraformは、HashiCorp社が開発した「Infrastructure as Code (IaC)」ツールであり、クラウドリソースのプロビジョニングと管理を自動化するためのものです。Terraformを使用すると、様々なクラウドサービスのリソースを統一的な文法で定義し、宣言的にインフラの状態をコードで管理することができます。

こちらの記事でTerraformの導入方法や使用方法を解説しています。

https://envader.plus/article/162

### AWS EventBridge Schedulerとは

AWS EventBridge Schedulerは、AWSのサービスの一つで、定期的なスケジュールや特定のイベントに応じてAWSリソースを操作するためのサービスです。特定の時間や間隔での実行を定義することができる「Cron」や「Rate」式を使用して、様々なAWSサービスとの連携を実現します。

こちらの記事でRDSインスタンスを時限起動した方法を解説しています。

https://envader.plus/article/243

### どのようにコスト削減が期待できるのか

EventBridge Schedulerを使用することで、開発環境やステージング環境のEC2インスタンスを特定の時間帯だけ稼働させることができます。例えば、夜間や週末など、実際の作業が行われていない時間帯にインスタンスを自動的に停止することで、インスタンスの稼働時間を減少させることができます。結果、EC2の時間課金によるコストを大幅に削減することが期待できます。Terraformはこれら一連の設定をコードで管理するものです。

## 実装手順

### iam

まずはIamロールを準備します。

#### iam.tf

```bash
# EC2 Scheduler IAM Role
resource "aws_iam_role" "ec2_scheduler" {
  name = "ec2-scheduler-role"
  assume_role_policy = file("./resources/assume_policy.json")
}

resource "aws_iam_policy" "ec2_scheduler" {
  name = "ec2-scheduler-policy"
  policy = templatefile("./resources/ec2_scheduler_policy.json", {
    account_id = data.aws_caller_identity.current.id
  })
}

resource "aws_iam_role_policy_attachment" "ec2_scheduler" {
  role = aws_iam_role.ec2_scheduler.id
  policy_arn = aws_iam_policy.ec2_scheduler.arn
}
```

#### assume_policy.json

`resources`ディレクトリを作成し配下に作成します。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": ["scheduler.amazonaws.com"]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

#### ec2_scheduler_policy.json

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": [
        "arn:aws:ec2:*:${account-id}:instance/*",
      ]
    }
  ]
}
```

### 変数

いくつか変数を使用しているので、それらを指定します。

#### main.tf

これらを追加します。

```bash
# 現在のAWS IDを取得
data "aws_caller_identity" "current" {}
# 変数を指定
variable "ec2_scheduler_target" {}
```

#### terraform.tfvars

以下を追加。

```bash
# keyに対象インスタンスのIDを入力
ec2_scheduler_target = {
    "i-9999999999" = ["cron(0 8 ? * MON-FRI *)", "cron(0 20 ? * MON-FRI *)"]
}
```

### EventBridgeのコード

`aws_scheduler_schedule`リソースを使用して起動と停止をスケジュールします。

```hcl
# イベントブリッジによる自動停止
resource "aws_scheduler_schedule" "auto-stop" {
  for_each   = var.ec2_scheduler
  name       = "eventbridge-stop-scheduler"
  group_name = "default"

  flexible_time_window {
    mode = "OFF"
  }

  schedule_expression          = each.value.1
  schedule_expression_timezone = "Asia/Tokyo"

  target {
    arn      = "arn:aws:scheduler:::aws-sdk:ec2:stopInstances"
    role_arn = aws_iam_role.ec2_scheduler.arn
    input    = <<EOF
    {
        "InstanceIds": ["${each.key}"]
    }
    EOF
  }
}

# イベントブリッジによる自動開始
resource "aws_scheduler_schedule" "auto-start" {
  for_each   = var.ec2_scheduler
  name       = "eventbridge-start-scheduler"
  group_name = "default"

  flexible_time_window {
    mode = "OFF"
  }

  schedule_expression          = each.value.1
  schedule_expression_timezone = "Asia/Tokyo"

  target {
    arn      = "arn:aws:scheduler:::aws-sdk:ec2:startInstances"
    role_arn = aws_iam_role.ec2_scheduler.arn
    input    = <<EOF
    {
        "InstanceIds": ["${each.key}"]
    }
    EOF
  }
}
```

※targetのarnの`stopInstances`はキャメルケースにする必要があります。
※aws_scheduler_scheduleを使用するにはaws provider version 4.56.0以上が必要となります。

## コスト削減効果

![https://storage.googleapis.com/envader-article-images/ec2-scheduler/002.png](https://storage.googleapis.com/envader-article-images/ec2-scheduler/002.png)

### コストの試算

m5.largeインスタンスの平均的な料金を$0.096/時間と仮定します。
（この料金はAWSの公式サイトでの2023年10月時点の東京 (ap-northeast-1)リージョンのオンデマンド料金を基にしています。実際の料金はリージョンや契約内容により異なる場合がありますので、正確な料金はAWS公式サイトをご参照ください。）

https://aws.amazon.com/jp/ec2/pricing/on-demand/

#### 1ヶ月間24時間稼働した場合のコスト

$0.124 * 24 * 30 = $87.68（13,152円）

※1ドルを150円で計算

#### 平日の8時から20時のみ稼働した場合のコスト

1日の稼働時間は12時間となります。1ヶ月の平日は約22日ですので、

$0.124 * 12 * 22 = $33.08（4,962円）

したがって、

1ヶ月間24時間稼働した場合のコストは約$87.68
平日の8時から20時のみ稼働した場合のコストは約$33.08
この試算により、平日の8時から20時のみ稼働させる方法を採用することで、約$54.6日本円にして8,190円（63.36%）のコスト削減が期待できることがわかります。

## 注意点

定義の確認: Terraformの設定ファイルを適用する前に、terraform plan コマンドを使用して変更内容を確認しましょう。
IAMポリシー: 必要なIAMロールやポリシーが正しく設定されていることを確認してください。特にEventBridgeやEC2への適切なアクセス権限が必要です。
時刻設定: EventBridgeのスケジュール式が正しいタイムゾーンで設定されているか確認してください。

### トラブルシューティング

#### EC2インスタンスが起動しない

- EventBridgeのルールが正しく設定されているか確認してください。
- EventBridgeのターゲットが正しくEC2インスタンスを指しているか確認してください。
- CloudWatch LogsでEventBridgeのログを確認し、エラーメッセージをチェックしてください。

#### EC2インスタンスが予定よりも早く、または遅くシャットダウンされる

- スケジュール式が正しいか確認してください。
- 他のEventBridgeルールやLambda関数がEC2インスタンスに影響を及ぼしていないか確認してください。

#### Terraformがエラーを返す

- 最新の`terraform init` コマンドを実行してプラグインを更新してください。
- エラーメッセージを注意深く読み、指示に従って問題を解決してください。
- 必要に応じて、`terraform refresh` コマンドを使用して実際のリソースの状態を取得してください。

#### コストが予想以上にかかっている

- EC2インスタンスが予定外の時間に稼働していないか確認してください。
- AWS Cost Explorerを使用して、コストの詳細を確認し、高いコストの原因を特定してください。

## まとめ

### この記事の内容の再確認

- 本記事では、EC2インスタンスのコスト削減を目的として、TerraformとEventBridge Schedulerを使用した時限起動の実装方法を紹介しました。
- TerraformとEventBridge Schedulerの基本について触れ、実際にどのようなコスト削減が期待できるのかを詳しく解説しました。
- m5.largeインスタンスの24/7稼働と平日の8時から20時の運用パターンを比較し、約63.36%のコスト削減効果があることを確認しました。
- 実装時の注意点と、潜在的な問題やトラブルの対処法についても触れました。

AWSの無料枠で簡単に実現できますので、興味がある方はぜひ実践してみてください。


EC2インスタンスを指定した時間帯だけ起動・停止するスケジュールの設定方法などを説明しています。

TerraformとEventBridge Schedulerを活用したEC2インスタンスの時限起動によるコスト削減

今回は、異なるVPCにいるインスタンス間同士の通信を行える環境を構築します。VPCピアリングを用いて、インターネットを介さない安全な通信を実現する方法を学習します。

【Part 1/4】AWSの環境構築で学ぶトラブルシューティング【VPC Peering】

# 【Part 2/4】AWSの環境構築で学ぶトラブルシューティング【NAT Gateway】

## 本記事で学べること

本記事は「AWSの環境構築で学ぶトラブルシューティング」シリーズの第2回目となっています。

本シリーズは、実際に手を動かしながらWSの環境構築とその過程でトラブルが起こった場合の対処方法や問題の特定方法などを体系的に学べる内容になっています。また、トラブルシューティングのセクションでは、遭遇した問題の問題の特定方法や解決方法について解説します。

今回は、一般的なWeb3層アーキテクチャのDB層の環境を構築します。外部からのネットワークを遮断した安全な環境を作成する方法を学習します。

「AWSの環境構築で学ぶトラブルシューティング」シリーズはこちら

https://envader.plus/article/259

## 環境構築のゴール

本記事における、環境構築のゴールを以下の図にまとめました。**プライベートサブネットに配置したインスタンスでMySQLをインストールすること**がゴールです。

![nat-gateway-1.png](https://storage.googleapis.com/envader-article-images/aws-ts-2/nat-gateway-1.png)

## 環境構築

現時点の環境は、以下の図のようになっており、こちらに**追加する**形で環境を構築します。

![nat-gateway-2.png](https://storage.googleapis.com/envader-article-images/aws-ts-2/nat-gateway-2.png)

現時点までの環境構築に関しては、Part 1の以下の記事をご参照ください。

```sql
【Part 1】**AWSの環境構築で学ぶトラブルシューティング**【VPC Peering】 **の記事**
```

### キーペアの作成

DBは顧客情報などを含む様々な情報を扱いますので、外部からアクセスされないようにする必要があります。そのため、DBはプライベートサブネットに配置し、パブリックIPの割り当てを行わないようにします。

サーバーがパブリックIPを持っていない場合、通常ローカルからアクセスすることができません。しかし、インスタンスをDBとして設定するために、そのインスタンスにアクセスする必要があります。

ではどうするかというと、いくつか方法はありますが、今回は同VPC内のパブリックIPを持つインスタンスを介してパブリックIPを持たないインスタンスにアクセスする方法を取ります。パブリックIPを持たないインスタンスにアクセスするために利用されるもののことは**踏み台**と呼ばれます。

![nat-gateway-3.png](https://storage.googleapis.com/envader-article-images/aws-ts-2/nat-gateway-3.png)

踏み台のインスタンスからプライベートサブネットに配置するインスタンスに接続するためのSSHキーを作成します。

- SSHキーの作成
    
    踏み台となる`1-ec2-public`にSSH接続後、SSHキーを作成します。
    
    ```bash
    $ ssh-keygen -t ed25519
    
    ...
    The key's randomart image is:
    +--[ED25519 256]--+
    |            ...o=|
    |             . ==|
    |            + + X|
    |    .      + + O.|
    |   o E .S . * *o.|
    |  o . =  . + * o+|
    | o   +    + . .+ |
    |.    ..o+. .  o .|
    |      +==+     . |
    +----[SHA256]-----+
    ```
    
- 公開鍵の値をコピーする
    
    まず、作成した公開鍵の値をクリップボードにコピーします。
    
    ```bash
    $ ls ~/.ssh
    authorized_keys  id_ed25519  id_ed25519.pub
    
    $ cat ~/.ssh/id_ed25519.pub
    # 出力された値をコピー
    ```
    
- 公開鍵をインポートする
    
    AWSマネージメントコンソールから、キーペアセクションにいき、キーペアをインポートします。
    
    | 設定項目 | 入力/選択項目 |
    | --- | --- |
    | 名前 | networking-key |
    | キーペアファイル | id_ed25519.pubの値を貼り付ける |

### プライベートサブネットにインスタンスを作成

`networking-1-vpc`のプライベートサブネットに設置するインスタンスを作成します。このインスタンスがDBとして構築するインスタンスです。

| 設定項目 | 入力/選択項目 |
| --- | --- |
| 名前 | networking-1-ec2-private（任意） |
| AMI | Ubuntu Server 22.04 LTS |
| インスタンスタイプ | t2.micro |
| キーペア | networking-key |
| VPC | networking-1-vpc |
| サブネット | private1（privateのいずれかを任意） |
| パブリックIPの自動割り当て | 無効化 |
| セキュリティグループ | networking-1-sg |

### 使用する環境の情報

以後の説明で出てくる環境の情報を以下にまとめました。

| インスタンス名 | 呼称 | パブリックIPアドレス | プライベートIPアドレス |
| --- | --- | --- | --- |
| networking-1-ec2-public | 1-ec2-public | 3.113.16.83 | 10.0.14.48 |
| networking-1-ec2-private | 1-ec2-private | - | 10.0.132.166 |

以後の説明では、`networking-1-ec2-public`は`1-ec2-public`、`networking-1-ec2-private`は`1-ec2-private`と簡略化して呼称します。

## 作成したインスタンスにMySQLをインストールする

作成したインスタンスにMySQLをインストールします。手順として、踏み台からプライベートサブネットに配置したインスタンスにSSH接続してから、MySQLをインストールします。

- `1-ec2-public`から`1-ec2-private`にSSH接続する
    
    `1-ec2-public`にSSH接続している状態から以下のコマンドを叩きます。
    
    ```bash
    $ ssh ubuntu@10.0.132.166
    
    ...
    ubuntu@ip-10-0-132-166:~$
    
    # 1-ec2-privateにSSH接続できていることを確認する
    # `inet 10.0.132.166/20`から、1-ec2-privateに接続できていることが確認できます
    ubuntu@ip-10-0-132-166:~$ ip a
    
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
        link/ether 06:6d:41:36:f9:b9 brd ff:ff:ff:ff:ff:ff
        inet 10.0.132.166/20 metric 100 brd 10.0.143.255 scope global dynamic eth0
           valid_lft 3403sec preferred_lft 3403sec
        inet6 fe80::46d:41ff:fe36:f9b9/64 scope link
           valid_lft forever preferred_lft forever
    ```
    
- MySQLをインストールする
    
    まず、最新のMySQLをインストールするために、パッケージをアップデートします。
    
    ```bash
    ubuntu@ip-10-0-132-166:~$ sudo apt update
    
    ...
    W: Failed to fetch http://ap-northeast-1.ec2.archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Could not connect to ap-northeast-1.ec2.archive.ubuntu.com:80 (35.74.21.248), connection timed out Could not connect to ap-northeast-1.ec2.archive.ubuntu.com:80 (54.199.234.19), connection timed out Could not connect to ap-northeast-1.ec2.archive.ubuntu.com:80 (13.231.188.197), connection timed out Could not connect to ap-northeast-1.ec2.archive.ubuntu.com:80 (18.179.24.57), connection timed out Could not connect to ap-northeast-1.ec2.archive.ubuntu.com:80 (18.182.10.247), connection timed out Could not connect to ap-northeast-1.ec2.archive.ubuntu.com:80 (18.183.160.212), connection timed out
    ...
    ```
    
    `Failed…`と出力され、パッケージがアップデートできませんでした。
    

## トラブルシューティング

![nat-gateway-4.png](https://storage.googleapis.com/envader-article-images/aws-ts-2/nat-gateway-4.png)

`sudo apt update` コマンドを実行した際に接続できないというエラーメッセージが表示される場合、主に以下のような原因が考えられます。

1. リポジトリサーバーのダウン
2. ネットワーク接続の問題

この2つ以外にも問題がある場合も考えられますが、まず上記の2つの問題に的を絞り、順を追って確認し、問題を特定していきます。

### リポジトリサーバーのダウン

パッケージのアップデートが失敗したログで出力された`http://ap-northeast-1.ec2.archive.ubuntu.com/ubuntu/dists/jammy/InRelease`に対し、`1-ec2-public`から`ping`を送り、リポジトリサーバーがダウンしているかどうかを確認します。

- pingを送る
    
    `ping` コマンドはドメイン名またはIPアドレスに対して使用されますが、URL全体に対しては使用できません。したがって、`http://` とパス部分を取り除いて、ドメイン名のみを `ping` する必要があります。以下のように`ping`を実行します。
    
    ```bash
    $ ping -c 10 ap-northeast-1.ec2.archive.ubuntu.com
    
    PING ap-northeast-1.ec2.archive.ubuntu.com (18.179.24.57) 56(84) bytes of data.
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=1 ttl=63 time=1.75 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=2 ttl=63 time=1.83 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=3 ttl=63 time=1.82 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=4 ttl=63 time=1.82 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=5 ttl=63 time=1.85 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=6 ttl=63 time=1.76 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=7 ttl=63 time=1.81 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=8 ttl=63 time=1.88 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=9 ttl=63 time=1.85 ms
    64 bytes from ec2-18-179-24-57.ap-northeast-1.compute.amazonaws.com (18.179.24.57): icmp_seq=10 ttl=63 time=2.60 ms
    
    --- ap-northeast-1.ec2.archive.ubuntu.com ping statistics ---
    10 packets transmitted, 10 received, 0% packet loss, time 9012ms
    rtt min/avg/max/mdev = 1.745/1.897/2.601/0.237 ms
    ```
    
    `-c`オプションを使用するとpingを送る回数を指定できます。
    
    リポジトリサーバーへの`ping`は全て応答があり、パケットロスもありません。この結果から、リ**ポジトリサーバーがダウンしているわけではない**ことが確認できました。
    

### ネットワーク接続の問題

次に、ネットワーク接続の問題を確認します。`1-ec2-private`のネットワーク接続をテストするために、`8.8.8.8`というIPアドレスに対してpingを送ります。

`8.8.8.8`というIPアドレスはGoogleのパブリックIPアドレスで、世界中でアクセス可能な公開DNSサーバーのIPアドレスです。信頼性の高さや高速で応答すること、`8.8.8.8`という覚えやすい数字の並びであることから多くのユーザーと技術者がネットワークの問題を診断する際に`8.8.8.8`を使用しています。これが一種の非公式な標準となっています。そのため、`8.8.8.8`のIPアドレスは、ネットワークのテストやトラブルシューティングでよく使用されます。

- 1-ec2-privateから8.8.8.8に対してpingを送る
    
    `1-ec2-private`にSSH接続し、以下のコマンドを実行します。
    

```bash
ubuntu@ip-10-0-132-166:~$ ping -c 10 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9219ms
```

`ping`の結果、送った全ての`ping`の応答はなく、100％のパケットロスが発生しました。つまり、`1-ec2-private`のネットワーク接続に問題があると、問題を特定することができました。

### トラブルシューティングの結果

ここまでのトラブルシューティングで、以下の図のように問題のある箇所を特定することができました。`1-ec2-private`からリポジトリへの通信が上手く行っていない状態です。

![https://storage.googleapis.com/envader-article-images/aws-ts-2/mermaid-diagram-2023-11-21-200705.png](https://storage.googleapis.com/envader-article-images/aws-ts-2/mermaid-diagram-2023-11-21-200705.png)

実際の原因は、このセクションの最初に説明した通り、`1-ec2-private`がパブリックIPを持っていないことによるものです。そのため、`1-ec2-private`がインターネットに接続できるようにする必要があります。

### NAT Gateway

**NAT**（**N**etwork **A**ddress **T**ranslation）は、プライベートネットワークのIPアドレスを公開インターネットのIPアドレスに変換する技術です。NATに関しての詳細は、以下の記事をご参照ください。

[https://envader.plus/article/15](https://envader.plus/article/15)

- 問題点の整理
    
    現在の問題を整理します。プライベートサブネットに配置したインスタンスはDBサーバーとして運用したいのでMySQLなどをインストールしたいです。しかし、パブリックIPを持っていないのでインターネットを使用できません。
    
    しかし、パブリックIPを割り当てれば良いか、というとそうではありません。パブリックIPを割り当てるとそのインスタンスはインターネットから直接アクセスされ、情報が漏洩する恐れがあります。
    
    では、どうするかというと、今回はAWSのサービスのNAT Gatewayを使用します。
    
    NAT Gatewayの機能により、外部からはプライベートネットワーク内のインスタンスからのトラフィックはNAT GatewayのIPアドレスから来ているように見えます。これにより、内部リソースのプライベートIPアドレスは外部に公開されず、安全にインターネットと通信できるようになります。
    
- NAT Gatewayの作成
    
    ※NAT Gatewayの利用は1時間当たり0.045USD（1USD = 151.323 JPY）がかかります。**利用後は削除することをおすすめします**。
    
    | 設定項目 | 選択入力/選択項目 |
    | --- | --- |
    | 名前 | networking-1-natgw |
    | サブネット | networking-1-subnetのpublic1 |
    | 接続タイプ | パブリック |
    | ElasticIPの割り当て | クリックし、割り当てる |
- ルーティングの設定
    
    `1-ec2-private`に紐付いているサブネット情報から、ルートテーブルページにいき、ルートを追加します。
    
    | 設定項目 | 入力/選択項目 |
    | --- | --- |
    | 送信先 | 0.0.0.0/0 |
    | ターゲット | NAT ゲートウェイ → networking-1-natgw |
    
    既に設定されている以外のその他の通信はNAT Gateway宛に通信を送るようにします。
    

### MySQLのインストール

`1-ec2-private`からのインターネット接続の通信をNAT Gateway宛に送るように設定したので、再度`1-ec2-private`にMySQLのインストールを試します。

```bash
# 1-ec2-publicにSSH接続した状態です
$ ssh ubuntu@10.0.132.166

ubuntu@ip-10-0-132-166:~$ sudo apt update

...
Fetched 28.2 MB in 5s (5934 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
42 packages can be upgraded. Run 'apt list --upgradable' to see them.
```

パッケージのアップデートが問題なく完了しました。続いてMySQLをインストールします。

```bash
ubuntu@ip-10-0-132-166:~$ sudo apt install mysql-server -y

...

ubuntu@ip-10-0-132-166:~$ mysql --version
mysql  Ver 8.0.35-0ubuntu0.22.04.1 for Linux on x86_64 ((Ubuntu))
```

正常にインストールが完了した場合、MySQLのバージョンの情報が確認できます。

### 本記事の片付け

NAT Gatewayは放置すると料金がかかりますので、削除の手順についても解説します。また、プライベートサブネットに配置したインスタンスも削除します。削除する場合は、以下の手順に沿って行ってください。

- NAT Gatewayの削除
    1. `1-ec2-private`に紐付いているサブネット情報から、ルートテーブルページにいき、追加したルートを削除します。
    2. NAT Gatewayのページにいき、作成したNAT Gatewayを削除します。
    3. Elastic IPのページにいき、NAT Gatewayに割り当てしたElastic IPを解放します。解放しないと料金がかかりますのでご注意ください。
- networking-1-ec2-privateの削除
    
    EC2のページからインスタンスで`networking-1-ec2-private`を選び、インスタンスの状態 → 終了を選択します。終了とは削除のことです。
    

## まとめ

今回は前シリーズで学んだネットワーク通信コマンドを利用し、問題の特定を行うことができました。

`ping`はネットワークのトラブルシューティングにはよく使用します。また、記事中で紹介したGoogleの`8.8.8.8`のIPアドレスはネットワークに関するトラブルシューティングで利用する機会が多いです。`ping`と合わせて押さえておきましょう。

引き続き本シリーズを学習していただき、トラブルシューティングのレベルを上げていきましょう。

今回は、一般的なWeb3層アーキテクチャのDB層の環境を構築します。外部からのネットワークを遮断した安全な環境を作成する方法を学習します。

【Part 2/4】AWSの環境構築で学ぶトラブルシューティング【NAT Gateway】

# 【Part 3/4】AWSの環境構築で学ぶトラブルシューティング【Route53】

## 本記事で学べること

本記事は「AWSの環境構築で学ぶトラブルシューティング」シリーズの第3回目となっています。

本シリーズは、実際に手を動かしながらWSの環境構築とその過程でトラブルが起こった場合の対処方法や問題の特定方法などを体系的に学べる内容になっています。また、トラブルシューティングのセクションでは、遭遇した問題の問題の特定方法や解決方法について解説します。

今回は、Route53を使用し、特定のインスタンスにドメインでアクセスできるようにする環境を構築します。AWSのプライベートネットワークを介した安全な通信を利用する方法を学習します。

「AWSの環境構築で学ぶトラブルシューティング」シリーズはこちら

https://envader.plus/article/259

https://envader.plus/article/260

## 環境構築のゴール

本記事における、環境構築のゴールを以下の図にまとめました。**Webサーバーにドメインでアクセスできるようにすること**がゴールです。

![route-53-1.png](https://storage.googleapis.com/envader-article-images/aws-ts-3/route-53-1.png)

## 環境構築

現時点の環境は、以下の図のようになっており、こちらに**追加する**形で環境を構築します。

![route-53-2.png](https://storage.googleapis.com/envader-article-images/aws-ts-3/route-53-2.png)

現時点までの環境構築に関しては、Part 1の以下の記事をご参照ください。

https://envader.plus/article/259

### 使用する環境の情報

以後の説明で出てくる環境の情報を以下にまとめました。

| インスタンス名 | 呼称 | パブリックIPアドレス |
| --- | --- | --- |
| networking-1-ec2-public | 1-ec2 | 52.68.48.29 |
| networking-2-ec2-public | 2-ec2 | 18.182.65.169 |

以後の説明では、`networking-1-ec2-public`は`1-ec2`、`networking-2-ec2-public`は`2-ec2`と簡略化して呼称します。

### nginxのインストール

パブリックサブネットに配置したインスタンス（`2-ec2`）をWebサーバーとして構築します。Webサーバーのソフトウェアはnginxを使用します。

- nginxのインストール
    
    `2-ec2`にSSH接続し、以下のコマンドを実行します。
    
    ```bash
    $ sudo apt update
    $ sudo apt install nginx -y
    ```
    
    インストール後はインストールが問題なく行えているか確認しましょう。`http://18.182.65.169`（`2-ec2`のパブリックIP）にアクセスし、nginxのデフォルトのページが表示されればインストール完了です。
    

### Route 53

今回はRoute 53を使用し、`2-ec2`にドメインでアクセスできるようにします。

Route53は、AWSのDNSのサービスです。Route53では、インターネットで通用するパブリックなDNSの管理や、VPC内だけで通用するプライベートなDNSの管理ができます。

パブリックなDNSの設定をする場合はドメインの購入が必要ですので、今回は**VPC内だけで通用するプライベートなDNSを使用**します。

- ホストゾーンの設定
    
    ホストゾーンとは、**ドメイン名の問い合わせに対して、どういう回答をするのかという設定をまとめたもの**です。
    
    マネージメントコンソールで「Route 53」と検索し、ホストゾーンのセクションからホストゾーンの作成をクリックします。
    
    | 設定項目大枠 | 設定項目 | 入力/選択項目 |
    | --- | --- | --- |
    | ホストゾーン設定 | ドメイン名 | networking-1-vpc.domain |
    | ホストゾーン設定 | タイプ | プライベートホストゾーン |
    | ホストゾーンに関連付けるVPC | リージョン | 東京 |
    | ホストゾーンに関連付けるVPC | VPC ID | networking-1-vpc |
    
    作成が完了すると、`networking-1-vpc.domain`というホストゾーンが作成されます。このホストゾーンは`networking-1-vpc`内で通用するDNSのホストゾーンです。
    

### 2-ec2にドメインで通信できるかの確認

`2-ec2`に対し、ドメインでアクセスできるようになったかどうかを確認します。プライベートホストゾーンで設定したので、ブラウザからはアクセスできません。そのため、`1-ec2`にSSH接続し、`curl`コマンドを実行します。

`curl`コマンドは、様々な通信プロトコルでデータの送受信を行うことができます。また、`-v`オプションを付けて実行すると、HTTPレスポンスの情報も取得することができます。

```bash
$ curl -v http://networking-1-vpc.domain

* Could not resolve host: networking-1-vpc.domain
* Closing connection 0
curl: (6) Could not resolve host: networking-1-vpc.domain
```

`Could not resolve host: networking-1-vpc.domain`というエラーが起こりました。

## トラブルシューティング

![route-53-3.png](https://storage.googleapis.com/envader-article-images/aws-ts-3/route-53-3.png)

`Could not resolve host: networking-1-vpc.domain`というエラーは、`networking-1-vpc.domain`というホストの名前解決できなかったというエラーです。現状では以下の図のように、全ての名前解決が失敗している可能性があります。

![https://storage.googleapis.com/envader-article-images/aws-ts-3/mermaid-diagram-2023-11-21-200919.png](https://storage.googleapis.com/envader-article-images/aws-ts-3/mermaid-diagram-2023-11-21-200919.png)

そのため、**接続元の1-ec2が名前解決がどこまでできるか**、ということを調べていきます。

### 名前解決ができるかを調べるコマンド

DNSサーバーからの情報を取得することで名前解決のテストを行えるコマンドを以下の表にまとめました。

| コマンド | 説明 |
| --- | --- |
| dig <hostname> | DNSルックアップのためのコマンドで、nslookupよりも詳細な情報を提供します。DNSのトラブルシューティングに適しています。 |
| nslookup <hostname> | ドメイン名に対するIPアドレスをDNSサーバーに問い合わせます。DNSの問題を診断する際に有用です。 |
| host <hostname> | DNSルックアップを行い、ホスト名に対するIPアドレスやその他のDNSレコードを取得します。出力が比較的シンプルです。 |

今回は詳細な情報を得られる`dig`を実行して名前解決のテストを行います。

- `networking-1-vpc.domain`に`dig`を実行する
    
    `1-ec2`にSSH接続している状態で以下のコマンドを実行します。
    
    ```bash
    $ dig networking-1-vpc.domain
    
    ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> networking-1-vpc.domain
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5582
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 65494
    ;; QUESTION SECTION:
    ;networking-1-vpc.domain.	IN	A
    
    ;; AUTHORITY SECTION:
    networking-1-vpc.domain. 300	IN	SOA	ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
    
    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
    ;; WHEN: Sat Nov 04 08:39:15 UTC 2023
    ;; MSG SIZE  rcvd: 139
    ```
    
    `;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1`の行に注目してください。`ANSWER`が0と返されています。これは、名前解決ができていないことを意味します。
    
    試しにGoogleのドメインが名前解決できるか確認します。
    
    ```bash
    $ dig google.com
    
    ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> google.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26675
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 65494
    ;; QUESTION SECTION:
    ;google.com.			IN	A
    
    ;; ANSWER SECTION:
    google.com.		163	IN	A	142.250.196.142
    
    ;; Query time: 4 msec
    ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
    ;; WHEN: Sat Nov 04 08:41:47 UTC 2023
    ;; MSG SIZE  rcvd: 55
    ```
    
    `ANSWER`が1と返され、google.comのドメインのIPアドレスが返されており、名前解決ができていることが確認できます。その他、example.comなどのメジャーなドメインの名前解決を試してみてください。
    

### トラブルシューティングの結果

ここまでのトラブルシューティングで、以下の図のように問題のある箇所を狭めることができました。

![https://storage.googleapis.com/envader-article-images/aws-ts-3/mermaid-diagram-2023-11-21-201022.png](https://storage.googleapis.com/envader-article-images/aws-ts-3/mermaid-diagram-2023-11-21-201022.png)

つまり、名前解決自体は行えるが、`networking-1-vpc.domain`というホストだけが名前解決できないことが確認できました。

### Route 53の設定を確認する

マネージメントコンソールでRoute 53 → ホストゾーンセクションのページへ移動します。ホストゾーン名`networking-1-vpc.domain`の設定を確認します。

まず、ホストゾーンの詳細から、関連付けられたVPCのVPCIDが、`networking-1-vpc`であることを確認します。

次に、レコードの確認をします。現時点で登録されているレコードが以下になります。

![route-53-4.png](https://storage.googleapis.com/envader-article-images/aws-ts-3/route-53-4.png)

- レコードとは
    
    レコードとは、ドメイン名システム（DNS）の基本的な要素であり、インターネット上のあらゆるドメインに対して、そのドメインが何を指し示すのか、どのようにアクセスすれば良いのかを定義しています。今回触れるレコードに絞り、そのレコードのタイプを以下にまとめました。
    
    | レコードタイプ | 説明 |
    | --- | --- |
    | SOA | ドメインの権威情報を提供し、ネームサーバーの主要情報、ドメインの連絡先メールアドレス、データのリフレッシュレートなどを含みます。 |
    | NS | そのドメインのネームサーバー情報を指定します。 |
    | A | ドメイン名をIPv4アドレスに変換します。 |
    
    ここで重要なのがAレコードです。今回行いたいことは、`2-ec2`にドメインでアクセスできるようにすることです。ここまでの演習ではホストゾーンを作成しましたが、`2-ec2`のIPアドレスをドメインと紐づける作業をしていませんでした。
    
    例えるならば、ホストゾーンはアドレス帳です。アドレス帳だけ作成しても意味はありません。アドレス帳に名前と電話番号の情報を合わせて登録する必要があります。
    
- レコードの追加
    
    作成したホストゾーンにレコードを追加します。レコードの追加とは、IPアドレスとドメインを紐付ける作業です。レコードの作成をクリックします。
    
    | 設定項目 | 入力/選択項目 |
    | --- | --- |
    | レコード名 | 2-ec2-public |
    | 値 | 18.182.65.169（2-ec2のパブリックIP） |
    
    作成が完了するとAレコードとして登録されます。Aレコードは、ドメインとIPアドレス（正確にはIPv4のIPアドレス）の名前解決に使用されるレコードです。
    
    ※**作成したレコードの反映には時間がかかる場合があります**
    

### 名前解決の確認

作成したAレコードの`2-ec2-public.networking-1-vpc.domain`ができるか確認します。`1-ec2`にSSH接続し、以下のコマンドを実行します。

```bash
$ dig 2-ec2-public.networking-1-vpc.domain

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> 2-ec2-public.networking-1-vpc.domain
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60742
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;2-ec2-public.networking-1-vpc.domain. IN A

;; ANSWER SECTION:
2-ec2-public.networking-1-vpc.domain. 300 IN A	18.182.65.169

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Nov 05 10:50:43 UTC 2023
;; MSG SIZE  rcvd: 81
```

`dig`の結果、ANSWERが1と返されています。ANSWERセクションでは.`2-ec2-public.networking-1-vpc.domain`のIPアドレスは`18.182.65.169`となっており、正しく名前解決できているのか確認できました。

### 2-ec2にドメインで通信できるかの確認

`2-ec2`にドメインで通信できるか、`curl`コマンドを使用して確認します。

```bash
$ curl -v http://2-ec2-public.networking-1-vpc.domain

*   Trying 13.231.5.227:80...
* Connected to 2-ec2-public.networking-1-vpc.domain (18.182.65.169) port 80 (#0)
> GET / HTTP/1.1
> Host: 2-ec2-public.networking-1-vpc.domain
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Date: Sun, 05 Nov 2023 11:00:48 GMT
< Content-Type: text/html
< Content-Length: 612
< Last-Modified: Sat, 04 Nov 2023 06:32:28 GMT
< Connection: keep-alive
< ETag: "6545e57c-264"
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
* Connection #0 to host 2-ec2-public.networking-1-vpc.domain left intact
```

`curl`の結果、HTTPレスポンスで`200 OK`とnginxのデフォルトページのhtmlが返されました。問題なく`2-ec2`にドメインで通信できていることが確認できました。

## 本記事の片付け

Route 53の料金ですが、ホストゾーン、レコードともに重量課金ですが、ホストゾーンに関して、AWS公式には以下のように載っています。

> 作成後 12 時間以内に削除されたホストゾーンについては無料となっています
> 

不要な料金の発生を防ぐためにも、使用予定がなければ放置せずにレコードと合わせて削除することをおすすめします。Route 53で作成したホストゾーン、レコードの削除手順は以下を参考にしてください。

- レコードの削除
    
    手動で作成したレコードは手動で削除する必要があります。レコード名`2-ec2-public.networking-1-vpc.domain`を選択し、「レコードを削除」を選択します。
    
- ホストゾーンの削除
    
    「ゾーンを削除する」を選択し、削除するホストゾーンを確認し、「削除」と入力し、削除します。
    

## まとめ

今回はRoute 53の環境構築をしながらDNSに関して触れました。

トラブルシューティングの基本はエラーログを良く読むことです。エラーログにエラー内容が書いてあります。エラーがなぜ起こったのか、どうしたら良いのかはやはり知識や経験が必要になってきます。そのため、AWSのサービスを触れる際にはそのサービスが提供する基礎概念を理解することが重要です。

引き続き本シリーズを学習していただき、トラブルシューティングのレベルを上げていきましょう。

今回は、Route53を使用し、特定のインスタンスにドメインでアクセスできるようにする環境を構築します。AWSのプライベートネットワークを介した安全な通信を利用する方法を学習します。

【Part 3/4】AWSの環境構築で学ぶトラブルシューティング【Route53】

本シリーズは、実際に手を動かしながらWSの環境構築とその過程でトラブルが起こった場合の対処方法や問題の特定方法などを体系的に学べる内容になっています。また、トラブルシューティングのセクションでは、遭遇した問題の問題の特定方法や解決方法について解説します。

【Part 4/4】AWSの環境構築で学ぶトラブルシューティング【Cloud Formation】

この記事では、EKSの基本概念から始めて、実際に手を動かして学べるハンズオンまでをカバーします。初心者でもEKSを理解し、実際に使えるようになることを目指しています。

Amazon EKSで学ぶコンテナ管理

# AWS API Gateway入門 TerraformとPythonを使った簡単なハンズオン

![https://storage.googleapis.com/envader-article-images/aws-api-gateway/001.png](https://storage.googleapis.com/envader-article-images/aws-api-gateway/001.png)

## 記事の目的と対象読者

AWS APIゲートウェイは、AWSクラウドでAPIを構築およびデプロイするためのサービスです。本記事では、APIゲートウェイの基本概念とその利用方法を、初心者でもわかりやすく説明します。特に、Terraformを使用したインフラストラクチャーのコード化やPythonを用いたAPIの実装方法に焦点を当てます。

この記事は、AWSやAPIゲートウェイに関する基本的な知識があまりないエンジニア初心者の方、またはこれからAPIゲートウェイを使ってみたいと考えている開発者を対象としています。簡単なハンズオンを通じて、実際にAPIゲートウェイを使ったアプリケーションの開発プロセスを学ぶことができます。

## AWS APIゲートウェイとは何か？

APIゲートウェイは一言で言うとAPIの入口と出口を管理するサービスです。開発者がAPIを簡単に作成・公開・保守・管理・監視できるようにするフルマネージドサービスです。開発者はバックエンドサービスへのトラフィック管理・認証・アクセス制御・モニタリングなどを簡単に行うことができます。

![API Gatewayのアーキテクチャ図](https://storage.googleapis.com/envader-article-images/aws-api-gateway/New-API-GW-Diagram.c9fc9835d2a9aa00ef90d0ddc4c6402a2536de0d.png)

引用元[API Gateway のアーキテクチャ](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html)

### 基本概念の紹介

#### APIエンドポイント

APIのエンドポイントは、外部のユーザーやシステムがAPIにアクセスするためのURLです。AWS APIゲートウェイでは、これらのエンドポイントを作成し、管理することができます。

#### リソースとメソッド

APIゲートウェイ内で、リソースはAPIの特定の部分（例えば、ユーザー情報や商品データなど）を指します。各リソースには、HTTPメソッド（GET、POST、PUT、DELETEなど）が関連付けられており、特定の操作を行うことができます。

#### 統合タイプ

AWS APIゲートウェイでは、バックエンドサービス（例えば、Lambda関数、HTTPベースのバックエンドなど）へのリクエストの処理方法を定義するために、様々な統合タイプを提供しています。

### APIゲートウェイの利点

#### スケーラビリティ

AWS APIゲートウェイは自動的にスケーリングし、大量のトラフィックを処理する能力を備えています。

#### セキュリティ

AWSの強力なセキュリティ機能を利用して、APIを保護することができます。これには、APIキー、IAMロール、Cognitoユーザープールなどの認証メカニズムが含まれます。

#### モニタリングとログ

AWS CloudWatchと統合することで、APIの使用状況、パフォーマンスメトリクス、ログデータを簡単に監視し分析することができます。

#### 柔軟なデプロイオプション

ステージング環境やバージョン管理など、開発とデプロイメントのプロセスを効率的に管理できます。

## TerraformによるAWS環境のセットアップ

このセクションでは、Terraformを使用してAWS APIゲートウェイとその関連リソースをセットアップする方法について説明します。Terraformは、インフラストラクチャーをコードとして管理するためのオープンソースツールです。インフラの設定を自動化し、一貫性と再現性を向上させることができます。

IaCについてはこちらで解説しています。

https://envader.plus/article/136

### Terraformの基本

#### インフラストラクチャー・アズ・コード

Terraformを使用することで、インフラストラクチャーの設定をコードとして記述し、管理することができます。手動での環境設定の誤りを減らし、より効率的な開発プロセスを実現します。

Terraformやそのセットアップについてはこちらの記事で解説しています。

https://envader.plus/article/162

### APIゲートウェイ用のリソースをTerraformで構築

#### リソースの定義

APIゲートウェイを構築するために必要なリソース（例えば、REST API、リソース、メソッドなど）をTerraformファイルに定義します。

#### デプロイメントプロセス

Terraformを使用してリソースを定義した後、`terraform apply` コマンドを実行することで、AWSに対してこれらのリソースをデプロイします。

## Pythonを使ったAPIの作成とデプロイ

![https://storage.googleapis.com/envader-article-images/aws-api-gateway/002.png](https://storage.googleapis.com/envader-article-images/aws-api-gateway/002.png)

ここでは、Pythonを使用してAPIのバックエンドロジックを作成し、AWS APIゲートウェイと統合する方法を説明します。Pythonは、柔軟性と簡潔な構文のため、APIの開発に広く使用されています。

### PythonでのAPIロジックの記述

### APIロジックの基本

PythonでAPIのバックエンドロジックを作成するには、通常、FlaskやDjangoなどのウェブフレームワークを使用します。これらのフレームワークを使用すると、リクエストを受け取り、適切なレスポンスを返すエンドポイントを簡単に設定できます。

例えば、GETメソッドの場合は、以下のコードでリソースの情報を取得するエンドポイントを作成できます。

```python
from flask import request

def get_resource(name):
    # リソースの情報取得
    resource = get_resource_by_name(name)

    # レスポンスを返す
    return jsonify(resource)

@app.route("/resources/<name>", methods=["GET"])
def get_resource_endpoint(name):
    return get_resource(name)
```

このコードでは、`get_resource()`関数でリソースの情報を取得し、`jsonify()`関数でJSON形式のレスポンスを返しています。

### 開発環境の準備

Python開発環境をセットアップし、必要なライブラリ（例えば flask または django）をインストールします。

具体的には、以下の手順を実行します。

1. Pythonをインストールします。
2. 仮想環境を作成します。
3. 必要なライブラリをインストールします。

### APIゲートウェイとの統合

#### Lambda関数の作成

APIロジックをAWS Lambda関数としてデプロイします。これによりAPIゲートウェイからのリクエストを処理できるようになります。

例えば、以下のコードで、上記の`get_resource()`関数をLambda関数としてデプロイできます。

```python
import json

def get_resource(event, context):
    name = event["name"]
    resource = get_resource_by_name(name)
    return {"resource": resource}

lambda_handler = get_resource
```

このコードでは、`event`オブジェクトにリクエストの情報が、`context`オブジェクトにコンテキスト情報が含まれています。`get_resource()`関数でリソースの情報を取得し、`return`文でJSON形式のレスポンスを返しています。

#### APIゲートウェイとの統合

AWS APIゲートウェイを設定して、特定のエンドポイントをLambda関数に統合します。APIゲートウェイがリクエストを受け取った際に、それをLambda関数に転送し、処理させることができます。

具体的には、以下の手順を実行します。

1. APIゲートウェイの定義ファイルを作成します。
2. 定義ファイルで、Lambda関数を統合するエンドポイントを定義します。
3. APIゲートウェイをデプロイします。

### デプロイとテスト

#### デプロイプロセス

作成したLambda関数をAWSにデプロイし、APIゲートウェイと統合します。これには、AWS管理コンソールまたはAWS CLIを使用することができます。

#### APIのテスト

APIゲートウェイを通じてエンドポイントにリクエストを送信し、期待されるレスポンスが返ってくるかどうかをテストします。これには、Postmanやcurlなどのツールを使用できます。

## セキュリティとベストプラクティス

AWS APIゲートウェイを使用する際、セキュリティは極めて重要です。このセクションでは、APIゲートウェイのセキュリティ強化と、最適な運用方法について説明します。

### 認証と認可

#### APIキー

APIキーは、APIの使用を制御し、非公開のAPIにアクセスするためのシンプルな方法です。APIキーを使用することで、特定のユーザーまたはサービスがAPIを使用できるように制限します。

#### IAMロールとポリシー

AWSのIAM（Identity and Access Management）を使用して、APIへのアクセスを管理することができます。特定のユーザーやサービスに対して、細かいアクセス権を設定することができます。

#### Cognitoユーザープール

AWS Cognitoはユーザー認証と認可を管理するサービスで、APIへのアクセスをセキュアに制御するために使用されます。

### APIのセキュリティ対策

#### リクエストの検証

APIゲートウェイはリクエストの検証を行い、不正なリクエストや攻撃を防ぐことができます。これには、リクエストの形式やサイズの検証が含まれます。

#### クロスオリジンリソース共有（CORS）

CORSは、ウェブページが異なるオリジンのリソースにアクセスする際のセキュリティを提供します。APIゲートウェイでCORSを適切に設定することが重要です。

### パフォーマンスとコストの最適化

#### キャッシング

APIゲートウェイのレスポンスキャッシングを使用すると、バックエンドシステムへの負荷を減らし、レスポンス時間を短縮できます。

#### スロットリング

APIの使用率を制御するために、リクエストレートの制限（スロットリング）を設定することができます。過度のトラフィックによるシステムの過負荷を防ぐことができます。

## 実際の例をハンズオンで学ぶ

![https://storage.googleapis.com/envader-article-images/aws-api-gateway/003.png](https://storage.googleapis.com/envader-article-images/aws-api-gateway/003.png)

このハンズオンでは、PythonとTerraformを使用して、シンプルなHTTP APIをAWS APIゲートウェイで作成し、Lambda関数を統合するプロセスを実演します。

### 1. TerraformでAPIゲートウェイのセットアップ

#### Terraform設定ファイル (`api_gateway.tf`)

```hcl
provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_api_gateway_rest_api" "MyDemoAPI" {
  name        = "MyDemoAPI"
  description = "This is my API for demonstration purposes"
}

resource "aws_api_gateway_resource" "MyDemoResource" {
  rest_api_id = aws_api_gateway_rest_api.MyDemoAPI.id
  parent_id   = aws_api_gateway_rest_api.MyDemoAPI.root_resource_id
  path_part   = "mydemo"
}

resource "aws_api_gateway_method" "MyDemoMethod" {
  rest_api_id   = aws_api_gateway_rest_api.MyDemoAPI.id
  resource_id   = aws_api_gateway_resource.MyDemoResource.id
  http_method   = "GET"
  authorization = "NONE"
}

resource "aws_api_gateway_integration" "LambdaIntegration" {
  rest_api_id = aws_api_gateway_rest_api.MyDemoAPI.id
  resource_id = aws_api_gateway_resource.MyDemoResource.id
  http_method = aws_api_gateway_method.MyDemoMethod.http_method

  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.MyDemoLambda.invoke_arn
}
```

#### lambda.tf

Iamロール・ポリシーも指定していますが、適切なものに書き換えてください。

```hcl
data "archive_file" "sample_function" {
  type        = "zip"
  source_dir  = "lambda/sample_function" # Lambda関数のコードが含まれるディレクトリ
  output_path = "lambda/upload/sample_function.zip" # 出力されるZIPファイルのパス
}

resource "aws_lambda_function" "MyDemoLambda" {
  function_name = "MyDemoLambda"
  handler       = "lambda_function.lambda_handler" # Pythonファイルと関数名を指定
  runtime       = "python3.10" # ランタイムを指定

  # Lambda関数のコードを含むZIPファイルのパスを指定
  filename      = data.archive_file.sample_function.output_path # ZIPファイルのパス

  # Lambda関数に必要なIAMロールのARNを指定
  role          = aws_iam_role.lambda_exec.arn
}

resource "aws_iam_role" "lambda_exec" {
  name = "lambda_exec_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRole",
        Effect = "Allow",
        Principal = {
          Service = "lambda.amazonaws.com"
        },
      },
    ],
  })
}

# 必要に応じて、IAMポリシーを追加してLambda関数の権限を拡張
resource "aws_iam_role_policy" "lambda_policy" {
  name = "lambda_policy"
  role = aws_iam_role.lambda_exec.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ],
        Effect = "Allow",
        Resource = "arn:aws:logs:*:*:*"
      },
    ],
  })
}
```

### 2. PythonでLambda関数の作成

`lambda/sample_function`配下に`lambda_function.py`ファイルを作成してください。

#### Lambda関数 (`lambda_function.py`)

```python
import json

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }
```

### 3. デプロイとテスト

1. Terraformを使用してAPIゲートウェイとLambda関数をデプロイします。

   ```bash
   terraform init
   terraform apply
   ```

2. Postmanやcurlを使用して、作成したAPIエンドポイントにリクエストを送信し、レスポンスを確認します。

   ```bash
   curl https://<api-id>.execute-api.<region>.amazonaws.com/mydemo
   ```

## まとめ

この記事では、AWS APIゲートウェイの基本から、ハンズオンまでを一通り学びました。

学んだことの要約は、次のとおりです。

* AWS APIゲートウェイの基本概念とその利点
* Terraformを使用してインフラストラクチャをコード化する方法
* Pythonを用いてAPIのバックエンドロジックを実装する方法
* APIゲートウェイのセキュリティ対策とベストプラクティス
* ハンズオンを通じたAPIの作成とデプロイ

API開発はエンジニアへの第一歩となりますので、ハンズオンで学んだことを活かし自分オリジナルのAPIを作成してみましょう。


この記事は、AWSやAPIゲートウェイに関する基本的な知識があまりないエンジニア初心者の方、またはこれからAPIゲートウェイを使ってみたいと考えている開発者を対象としています。

AWS

すべての記事