複数のCDIRブロックを一元管理することができる。

【各エンドポイントの比較】

【補足】

• VPCエンドポイント：サービスを「利用する側（コンシューマー）」の入り口
• エンドポイントサービス：サービスを「提供する側（プロバイダー）」の出口

●サービスエンドポイント
【VPC→AWSサービス】

※接続元
AWSの特定サービス（例：S3やDynamoDB）に対して、インターネットを経由せずにVPC内から直接プライベートにアクセスできるようにする仕組み。

●enable DNS Hostnames 属性
有効化しないと、サブネットで起動されたインスタンスはDNS名を取得できない。

●enable DNS Support 属性
VPCがAmazon提供のDNSサーバーを介したDNS解決策をサポートするか決定する設定値。デフォルトでは有効化。

●Traffic Mirroring
EC2 インスタンスのENIからネットワークトラフィックをコピーする機能。

●DHCPオプション
(DHCP:Dynamic Host Configuration Protocol)
TCP/IPネットワークのホストに設定情報を渡すための規格。サブネット内のアプリケーションは、必要に応じてDHCP サーバーと通信して、IPアドレス、または他のネットワーク構成情報 (DNS サーバーの IP アドレスや VPC 内のルーターの IP アドレスなど) を取得できる。

※TCP/IP ネットワーク上のすべてのデバイスには、ネットワークを介して通信するための IP アドレスが必要。
※DHCPは変更できないため、新しく作成して割り当てる必要がある
※以前は、ネットワーク内の各デバイスに IP アドレスを手動で割り当てる必要があった

◇性能補足

●ゴールデンイメージ
【最適なEC2のAMI】
下記のような特定のAWSリソースタイプにおいて、最適なEC2インスタンスの構成をAMIとしたもの。
※EC2インスタンス、RDS DBインスタンス、EBSボリューム……など

◇オプション

・垂直スケール時、インスタンスを停止する必要がある

・コストを最小化するためには、インスタンスを可能な限り多くのゾーンに分散する。

・Linux2はデフォルトでSystemManagerエージェントがプリインストールされている

• 停止保護
  インスタンスの停止および手動削除を防ぐ機能。

• unlimitedモード
  【バーストパフォーマンス】
  24 時間ごとのインスタンスの平均 CPU 使用率またはインスタンスの存続期間のいずれか短い方の時間で、インスタンスの平均 CPU 使用率がベースライン以下になった場合、1 時間ごとのインスタンス価格は自動的にすべての CPU 使用率スパイクをカバー。
  ピーク時以外のリソース使用率を抑えることができるため、ケースによってコスト最適化につながる。

• 送信元/送信先チェック
  ※デフォルトで有効化
  受信するすべてのトラフィックに関して、そのインスタンスが送信元なのか、あるいたは送信先であるのかを確認できる。ネットワークアドレス変換、ルーティング、ファイアウォールなどのサービスを実行するインスタンスでは本機能を無効にする必要がある。

●インスタンスメタデータ
インスタンスに関するデータで、実行中のインスタンスを設定または管理するために使用する。ホスト名、イベント、およびセキュリティグループなどのカテゴリに分けられる。

【インスタンスメタデータの取得】
インスタンスメタデータは実行中のインスタンスから取得できる。
EC2 コンソールまたは AWS CLI を使用する必要はない。

【インスタンスへのアクセス】

• SSH(セキュアシェル)キー(公開鍵/秘密鍵)
  EC2にログインするときに必要。インスタンスにアクセスキーを保存することはNG。
  
  インスタンスで動作するアプリケーションはAWSの他のサービスにアクセスするために認証情報が必要。

【インスタンスの再起動について】

一般的に「停止」→「起動」が的確な再起動となる。
意図しない再起動が発生した場合、データは残るが、終了（削除と同意）するとデータは消える。
※システムの可用性を高める場合、基本的には EC2 を複数構築してスペックは低めにすることが良い。
（高スペック 1 台よりメリットが得られます。全ダウンしにくい、料金が安い）

【自動復旧機能】

インスタンスをモニタリングするCloud Watch アラームによって、基盤ハードウェアの障害や、AWSによる修復を必要とする問題によりインスタンスが正常に機能しなくなった場合、自動的に対象のインスタンスを復旧させることができる。

復旧されたインスタンスは「インスタンスID」「プライベートIPアドレス」「ElasticIPアドレス」、すべてのメタデータを含めて、元のインスタンスと同じである。

※自動復旧

【問題のあるインスタンスを調査】
[ナビゲーションペイン]→[インスタンス:詳細ペイン]→ [Status Checks]→[System Status Checks] と [Instance Status Checks]

〇メトリクス

モニタリングできるメトリクスについて記載。

[参考公式サイト]

〇IPアドレス

• IPアドレスの後付け
  パブリックIPアドレスはインスタンスの作成時、「EC2のバブリックIPの自動割り当て」を有効にしないと割り当てられない。
  
  そのため、Elastic IPで後から指定しなくてはいけない。

〇ステータス

• ステータスチェック
  EC2におけるステータスのモニタリングを実行する。OSまたはミドルウェアからアプリケーション、AWS基盤側の問題などが検出されたか確認。
  ▲アプリケーションレベルの障害は検知できない
  
  【１分ごとに実行し、成功・失敗のステータスを更新】
  ・成功の場合：「OK」
  ・失敗の場合：「impaired」
  ※失敗の場合、インスタンスの[停止→起動]の実行で解消することがある。

〇インスタンスファミリー

[参考]

〇インスタンスの種類

• コンピューティング最適化インスタンス
  高いコンピューティングパフォーマンスが必要なワークロードに適しているが、コスト効果に優れているとは限らない。

• メモリ最適化インスタンス
  メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されている。

• リザーブドインスタンス
  (スタンダード / コンバーティブル)（数年間契約「１年間」「３年間」）
  
  ●スタンダード
  別のインスタンスファミリーに変更することができない。
  オンデマンドインスタンスと比較して、最大72％の割引を適用することができる。
  
  ●コンバーティブル
  作成時の価格と同等以上のインスタンスであれば、以下の設定（★）を途中で変更できる。
  その代わりスタンダードRIよりも少し高い。
  
  ★変更できる設定
  ・インスタンスファミリー
  ・OS,テナンシー (HWが共有か専有か)
  ・支払オプション (前払い、一部前払い、前払いなし)
  
  【RI割引について】
  割引を受けられるのは、RIを購入したアカウントのみ適用される。
  RIの割引共有を無効にするには、管理アカウントから実行できる。
  
  ※RIの更新は有効期限満了日に更新可能
  [参照元サイト]

• オンデマンドインスタンス
  【時間単位、秒単位】
  コンピューティング性能の料金を、長期契約なしで、時間または秒単位 (最低 60 秒) で支払うことができる。
  
  【オンデマンドキャパシティ予約】
  属性が一致する個別のインスタンスに対して、任意のタイミングや指定した時刻に終了するキャパシティが予約される。
  特定のAZで任意の所要時間だけ、利用したい指定インスタンスのコンピューティング能力を予約もできる。
  
  その際に、下記情報を選択すること。
  ・キャパシティーが予約されているアベイラビリティーゾーン
  ・キャパシティーを予約するインスタンスの数
  ・インスタンスタイプ、テナンシー、プラットフォーム/OS を含むインスタンスの属性

• スポットインスタンス
  AWSサーバ上に存在し、使われてないEC2インスタンスに値段をつけて入札価格が現在のスポット価格(長期でなく、1回ごとの取引で決定した市場価格)を上回っている限り、そのインスタンスを利用できる。
  処理途中で中断可能な計算処理を大規模かつ並列で実行する場合に使用できる。
  
  ※単独で実行されるかつ、停止した場合でも再実行で整合性を保証する
  
  ●スポットブロック
  【スポットインスタンス継続利用】
  スポットブロックが定義されたスポットインスタンスを中断することなく、選択した期間にわたって継続して利用できる。
  
  ・継続期間として 1 時間、2 時間、3 時間、4 時間、5 時間、または 6 時間を使用できる。
  ※支払い額はこの指定した継続期間によって決まる。
  
  ・バッチ処理、エンコードとレンダリング、モデリングと解析、継続的な統合など、完了までに一定の時間のかかるジョブに最適。
  
  ●スポットフリート
  【スポットインスタンスのセット】
  スポットインスタンスの集合体。リクエストで指定した容量ターゲットを満たすような「スポットインスタンス」と「オンデマンドインスタンス」数を起動する購入方式。ニーズに合うスポットキャパシティープールを選択して、フリートのターゲット容量を満たすまでスポットインスタンスを起動する。
  
  【起動の仕組み】
  スポットフリートは、ニーズに合ったスポットキャパシティ（空き容量）プールを選んで、フリートのターゲットキャパシティ（目標容量）を満たすまでスポットインスタンスを起動する。フリートのスポットインスタンスが削除された後に代替インスタンスを作成することによってターゲット容量が維持されるように設定されている。
  
  【リクエスト方法】
  インスタンスの終了後も保持されない「ワンタイムリクエスト」として送信できます。オンデマンドインスタンスのリクエストもスポットフリートのリクエストに含めることができる。
  
  
  【配分戦略】
  起動設定によって、スポットフリートがスポットインスタンスを起動できるすべてのスポットキャパシティプール (インスタンスタイプおよびアベイラビリティーゾーン) を決定する。
  
  インスタンスを起動する際、スポットフリートは指定された配分戦略を使用して、使用可能なすべてのプールから特定のプールを選択する。
  
  ●capacityOptimized
  スポットインスタンスのリクエストを行う際、最も余裕のあるインスタンスタイプに対してリクエストする。
  
  ●lowestPrice
  最も低い価格のインスタンスタイプに対してリクエストを行う。しかし、価格の低いインスタンスは需要が高いため、供給が追い付かない可能性がある。
  
  ●diversified
  さまざまなインスタンスタイプや可用性ゾーン間でスポットインスタンスのリクエストを分散させる。
  
  
  ●スポットインスタンスアドバイザ
  【中断軽減】
  中断する可能性が最も少ないプールを判断して、オンデマンド料金を削減できる。
  スポットインスタンスを選択する前に、ユーザーはアプリケーションの中断をどの程度許容できるか、およびコスト削減の目標を比較検討する必要がある。
  
  中断の頻度が低いほど、スポットインスタンスを利用できる時間は長くなる。
  
  【EC2インスタンス静止状態割引】
  アプリケーション中断できる場合に、費用効率を非常に高く抑えることができる。
  
  【リクエストのタイプ】
  リクエストとは、スポットインスタンスを使用するために、希望するインスタンス数、インスタンスタイプ、アベイラビリティーゾーンを決める必要がある。
  
  ●ワンタイムスポットインスタンスリクエスト
  下記の状態にならない限り、アクティブ状態を維持する。
  
  ・EC2 がスポットインスタンスを起動する
  ・リクエストの有効期限が切れる
  ・ユーザーがリクエストをキャンセルする
  
  利用できるキャパシティがない場合、スポットインスタンスは終了し、スポットインスタンスのリクエストは終了する。
  
  ●永続スポットインスタンスリクエスト
  リクエストが受理された後も、リクエストの有効期限が切れるかユーザーによりキャンセルされるまで、アクティブ状態を維持する。
  
  キャパシティを利用できない場合は、スポットインスタンスは中断。
  中断後に、キャパシティが再び利用可能になると、スポットインスタンスが開始 (停止している場合)、あるいは再開 (休止状態の場合) される。

〇ストレージ機能

• ブロックデバイスマッピング
  【ルートデバイスボリューム】
  インスタンス起動時に EBS ボリューム、またはインスタンスストアボリュームのどちらかのルートデバイスボリュームが関連付けられる。
  
  ●ルートボリューム
  OS領域に割り当てるもの。システムストレージを使用する。
  
  ◎EBS-backed インスタンス
  インスタンスを起動する際に、EBSが割り当てられる。
  
  ◎Instance store-Backed インスタンス（インスタンスストア）
  EC2インスタンスに内蔵されている無料の簡易ローカルストレージ。
  （※エフェメラルディスク）
  
  ・EC2の一時的なデータが保持され、EC2の停止・終了と共にクリアされる。
  ・スナップショット作成できない。
  ・物理ドライブに直接接続されているため、読み書き速度が早い。
  
  ※/dev/sda1はルートボリューム（ルート用に予約されたボリューム）
  
  
  【ストレージの変換について】
  Instance Store-Backed Linux AMI を EBS-backed Linux AMI に変換はできる。
  Instance Store-Backed Windows AMI を EBS-backed Windows AMIへの変換、および所有していないAMIの変換はできない。

〇起動設定

• EC2 フリート
  【起動するインスタンスグループ】
  起動するインスタンスの（オンデマンドやスポットなどの）種類、組み合わせを設定したグループ。
  
  設定次第でコスト最適化ができる。
  ※起動設定の代わりに起動テンプレートを利用してAuto Scalingを構成できる

• 起動テンプレート
  【設定の処理】
  インスタンスを起動するための設定情報を含む起動テンプレートを作成。
  AMIのID、インスタンスタイプ、キーペア、セキュリティグループなどEC2の起動に必要なパラメーターが含まれている。
  
  ※起動テンプレートにより起動パラメータを格納でき、インスタンスを起動するたびに指定する必要がなくなる。

• EC2Configサービス
  【タスク処理】
  EC2Config は設定ファイル群を使って操作を制御する。
  インスタンスの初回起動時に複数の初期起動タスクを実行し、その後、それらを無効にする。
  
  これらのタスクを再実行するには、ユーザーが明示的に有効化した後でインスタンスをシャットダウンするか、手動でSysprep を実行する必要がある。

• ユーザーデータ
  【パッケージの処理】
  インスタンス起動時に自動実行されるスクリプトのこと。起動時しか実行されない。
  アプリケーションのデプロイを自動化、インスタンス起動時に必要なソフトウェアをインストールしたり、アプリケーションをダウンロードして設定したり、サービスを起動したりする処理を記述できる。
  パッケージのアップデートやソフトウェアのインストールの際に有効。
  
  インスタンス起動時の一般的なタスクやプログラムはインスタンスにユーザーデータを渡すことで可能。
  EC2インスタンスの起動設定の一番下の方で記述し、ApacheをインストールしてWebサーバーにする、などの使い方をする。

• EC2 Image Builder
  【依存関係】
  アプリケーションとその依存関係のインストールを自動化し、定期更新を取り込むことが可能。
  
  【ディストリビューション設定】
  作成したイメージの配布方法を定義。新しいAMIがビルドされるたびに Autoscaling グループの起動テンプレートが自動的に最新のAMIを使用するように更新できる。
  
  【カスタムレシピ】
  特定の構成とインストール手順を定義し、それを元にEC2のAMIを作成できる。
  加え、本機能の一部として、AMI 作成プロセス中に自動的に脆弱性スキャンを実行できる。

※アプリケーションの依存関係
対象のアプリケーションが正しく動作するために必要なその他アプリケーションのリスト。

【例】
内部オブジェクトの内部アプリケーション詳細の表示方法 > アプリケーション > アプリケーション詳細ウィンドウ

〇トラブル・エラー

• Insufficient Instance Capacity
  インスタンスの容量不足
  
  【対策】
  ・数分間待ってから再リクエスト
  ・インスタンス数を減らして新しいリクエストを送信
  ・AZを指定しないでリクエストを送信
  
  …etc

• Instance Limit Exceeded
  インスタンス数の上限緩和リクエストが必要。

• インスタンス起動後、すぐに終了してしまう
  インスタンスがすぐに終了する理由を次のいくつか。
  
  ・EBS ボリュームの制限を超えた。
  ・EBS スナップショットが破損している。
  ・ルート EBS ボリュームは暗号化されていて、復号用の KMS キー にアクセスする権限がない。
  ・インスタンスを起動するために使用した Instance Store-Backed AMI で、必要な部分 (image.part.xx ファイル)。
  
  [引用サイト]

〇EC2関連機能

• EC2 Instance Connect
  EC2インスタンスへのSSHアクセスを簡素化し、セキュリティを強化する。接続ごとに一時的なSSHキーが生成され、インスタンスに自動的に送信される。(SSHポートをひらく必要がある)
  また本サービスの利用は、CloudTrailに記録される。
  

• ハイバネーション
  【停止しても継続できる】
  インスタンスが停止する前にメインメモリが保持する内容をハードディスクドライブに待避させ、次にコンピュータを起動させた際、作業途中から再開できるようにする機能。
  インスタンスがインターネットにアクセスするには、パブリックIPアドレスが必要となる。
  
  ※セキュリティグループを指定しないままインスタンスを起動するとデフォルトセキュリティグループが指定される

• Elastic Fabric Adapter (EFA)
  【インスタンスの高速NWデバイス】
  HPC（ハイパフォーマンスコンピューティング）と機械学習アプリケーションを高速化するために、EC2 インスタンスにアタッチできるネットワークデバイス。
  AWSで大規模な高レベルのノード間通信を必要とするアプリケーションを実行（数千のCPUまたはGPUに拡張）できる。
  既存の AWS ネットワークインフラストラクチャで動作するように最適化されており、アプリケーション要件に応じてスケーリングできる。
  
  ※AWS Batchと連携して、バッチコンピューティングワークロードを実行
  
  【以下をサポート】
  ・メッセージパッシングインターフェイス（MPI）を使用するHPCアプリケーション
  ・NVIDIA Collective Communications Library（NCCL）を使用する機械学習アプリケーション
  

〇属性

• SrcDestCheck属性
  送信元/送信先チェックをデフォルトで実行する。

• DisableAptermination属性
  偶発的な削除を防ぐことができる。インスタンスがコンソール、CLI、またはAPIを使用して終了できるか制御してくれる。

• テナンシー（テナント属性）
  EC2 インスタンスが物理ハードウェアに分散される方法を定義する。
  
  ●default：
  インスタンスは共有するハードウェアで実行される。
  ●dedicated：
  インスタンスはシングルテナントのハードウェアで実行される。
  ●host：
  インスタンスはDedicated Hostで実行される。

〇クラスター構成

単一AZ内のEC2インスタンス間の通信を広帯域幅・低レイテンシーに実行できる。

• クラスタープレイスメントグループ
  【単一AZ】
  単一のアベイラリティゾーン内のインスタンスを論理的にグループ化したもの。
  低いネットワークレイテンシー、高いネットワークスループット。
  インスタンス間のネットワーク遅延を最小限に抑える。

• パーティションプレイスメントグループ
  【単一AZ内】
  アプリケーションに関連するハードウェア障害の頻度を軽減させるために役に立つ。(障害が広がらない)
  パーティションという論理的なセグメントに分割する。

• スプレッドプレイスメントグループ
  それぞれの異なるハードウェアに配置されるインスタンスのグループ。
  少数の重要なインスタンスが互いに分離して保持される必要のアプリケーションに推奨。
  インスタンスが基本ハードウェアを共有するときに発生する可能性のある、同時障害のリスクを軽減できる。

〇サーバー占有率

• ベアメタル型インスタンス
  【物理へアクセス可能】
  サーバーのプロセッサーと(CPUや)メモリーに直接アクセス可能なインスタンス。
  
  通常のクラウドサーバーでは不可能な、ホストコンピューターのOSなど直接下層のハードウェアにアクセスが可能。また、仮想環境ではサポートされないレガシーのワークロード、そしてライセンス制限のあるティア1のビジネスクリティカルなアプリケーションを動かせる。

• Dedicated Instance
  【ハードウェア専有インスタンス】
  他のAWSアカウントから分離された物理サーバにインスタンスを起動することができる。
  別アカウントのEC2インスタンスが同じサーバ上で起動しないことを保証する。（同じアカウントでのインスタンス共有はある）
  
  【下記の場合に最適】
  ・ソフトウェアのライセンス等で物理サーバを専有したい場合
  ・コンプライアンスを重視する場合
  
  ※一般的にEC2インスタンスはAWS側で任意の物理サーバの上で起動されるため、物理サーバ上のインスタンスには別アカウントのインスタンスが存在する。

EC2 Dedicated Host
【完全個室】
（Dedicated Instance 上位版）
インスタンス容量を完全にお客様専用として占有利用できる物理サーバ。
別アカウントだけでなく、同アカウントのEC2インスタンスが同じサーバ上で起動できない。

・サーバーにバインドされた既存のソフトウェアライセンスを利用できるため、コンプライアンス要件を満たし、コストを削減。

※ライセンス条項の範囲で、ソケット単位、コア単位、または VM ソフトウェア単位の既存のライセンスを利用できる

一つ以上のコンテナをグループ化（集合体）し、共有の実行環境を提供するKubernetesの最小単位。

●レプリカセット（ReplicaSet）
Kubernetes（クラスター）内でアプリケーションのPod（コンテナを含むアプリケーションの最小デプロイ単位）を一定数維持する機能。

ECSを利用する際はコンテナイメージを ECRに配置することが必要。
コンテナイメージはHTTPS経由で転送され、保管時には自動的に暗号化される。

ECR（Elastic Container Registry）に保存されたコンテナイメージに対して実行できる

【スキャン対象と検出内容】

• OSレイヤーの脆弱性（基本スキャン・拡張スキャン）
• アプリケーションレイヤーの脆弱性（拡張スキャンのみ）

【スキャンのタイミング】

• イメージの登録時（基本スキャン）
• イメージのプッシュ時（拡張スキャン）
• 任意のタイミング（手動スキャン）

【スキャンタイプ】

【設定方法】
最初にホスト名をサーバーエンドポイントに関連付けてから、ユーザーを追加。
適切なアクセスレベルをプロビジョニングする。
これにより、ユーザーの転送リクエストが Transfer Family サーバーエンドポイントから直接提供される。

(1つのオリジンに対して）コンテンツデリバリーの設定や構成などの配布形態を意味する。CloudFrontディストリビューションではフェールオーバーオプションが提供される。プライベートIPアドレスはもっていない。

※セキュリティソフトウェアのパッチは静的ファイルであるため、本機能を利用してキャッシュできる

●地理的ディストリビューション
【制限 機能】
ある国(地域)からのアクセスに対して 403 (アクセス拒否) のレスポンスを返すことが可能。

●オリジンサーバ
コンテンツを配信する元となるサーバー。エッジロケーションに保存。
ターゲットグループを指定することはできない。

●カスタムヘッダー
オリジンに送信するリクエストにカスタムヘッダーを追加できる。
CloudFront がカスタムオリジンからファイルを取得するには、標準の HTTP (または HTTPS) リクエストを使用してCloudFront からファイルにアクセスできる必要がある。しかし、カスタムヘッダーを使用することで、コンテンツへのアクセスをさらに制限して、CloudFront を経由しないアクセスを防げる。

以下設定を変更する。

・ビューワープロトコルポリシー
【HTTP】
(CloudFront経由で)CloudFront エッジロケーションのコンテンツへのアクセスに使用するビューワーのプロトコルポリシー。ビューワーから CloudFront へのアクセス時に HTTPS の使用が求められるようにディストリビューションを設定。

・オリジンプロトコルポリシー
【プロトコル】
CloudFront がリクエストをオリジンに転送する際にビューワーと同じプロトコルの使用が求められるように、ディストリビューションを設定。

[参考]

（Allowed HTTP Methods）
CloudFront経由でコンテンツを操作する際にHTTP メソッドを指定。許可するHTTPメソッド多くの場合は[GET,HEAD]を設定。WEBDAVなどデータをアップする際などは[GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]CloudFront が処理してオリジンに転送する HTTP メソッドを指定する。

（Field Level Encryption）
フィールドレベル暗号化を使用した機密データの保護を実施したい場合に設定。
Allow HTTP Methodsを「GET,HEAD,OPTIONS,PUT,POST,PATCH,DELETE」を選択した場合に設定可能。

●フィールドレベルの暗号化
【特定のデータ保護】
セキュリティのレイヤーが追加され、システムの処理中に特定のデータに特定のアプリケーションのみがアクセスできるように、そのデータを保護できる。
ユーザーは機密情報をWebサーバーに安全にアップロードできる。

【併用：WAF】
WAF はウェブACL でディストリビューションに対して、ウェブリクエストの検査と管理ができる。
これによりセキュリティ性の高さを確保できる。
[参考サイト]