Amazon Data Lifecycle Manager は、Amazon Elastic Block Store (EBS) スナップショットと EBS-backed Amazon マシンイメージ (AMI) 用の、自動化されたポリシーベースのライフサイクル管理ソリューションを提供します。データ保護のニーズに応じてカスタマイズできるユーザー定義のポリシーを使用して、ブロックストレージデータのポイントインタイムコピーの作成を自動化します。

Elastic Fabric Adapter (EFA) は、High Performance Computing (HPC) と機械学習アプリケーションを高速化するために Amazon EC2インスタンスにアタッチできるネットワークデバイスです。EFAでは、AWS クラウドが提供するスケーラビリティ、柔軟性、伸縮性により、オンプレミスHPC クラスターのアプリケーションパフォーマンスを実現できます。

EFA では、クラウドベースの HPC システムで従来使用されていたTCPトランスポートよりも低く、一貫性の高いレイテンシーを提供し、高いスループットが得られます。HPCと機械学習アプリケーションのスケーリングに不可欠なインスタンス間通信のパフォーマンスが向上します。既存の AWS ネットワークインフラストラクチャで動作するように最適化されており、アプリケーション要件に応じてスケーリングすることができます。

Auto ScalingグループのTerminateプロセスを一時停止することで、異常状態と判断されたインスタンスが自動的に終了されるのを防ぎます。これにより、問題の原因を調査するために必要なインスタンスを維持することができます。

また、Session Managerを使用してインスタンスにログインすることで、セキュアかつ効率的にインスタンスにアクセスできます。Session Managerは、SSHキーの管理や特定のポートの開放が不要であり、プライベートサブネット内のインスタンスにも直接アクセスできます。

EC2インスタンスの終了保護は、ユーザーによる誤ってインスタンスを終了するのを防ぐためのものであり、Auto Scalingがヘルスチェックで失敗したインスタンスを終了するのを防ぐことはできません。

ACMで発行された証明書は、ALBなどの特定のAWSサービスでのみ使用可能であり、EC2インスタンスに直接インストールすることはできません。これは、AWSのセキュリティポリシーによる制限であり、証明書の不正使用を防ぐためのものです。

ELBとEC2間でSSLを使用するにはサードパーティのSSL証明書を取得し、NLBとEC2インスタンスにインストールします。NLBをポート443でリッスンするように設定し、トラフィックをインスタンスのポート443に転送します。

複数のEC2インスタンスが同一のEBSボリュームに同時にアタッチできる高度な機能で、共有ストレージソリューションを実現します。
最大16個のEC2インスタンスまでサポートします。またEBSボリュームは単一のアベイラビリティーゾーンに制限されます。

EC2インスタンスへのSSH接続を簡素化し、一時的なSSH公開鍵を使用してセキュアな接続を提供するAWSのサービスです。接続時に一時的なSSHキーを生成し、インスタンスに送信するため、個別のキー管理が不要になります。
Amazon EC2 コンソール、AWS CLI、または独自のキーとSSHクライアントを使用して Linuxインスタンスに接続できます。

• SendSSHPublicKey: EC2 Instance Connectの一部として、一時的なSSH公開鍵をEC2インスタンスのメタデータに送信するためのAWS APIアクションです。

SendSSHPublicKeyというAPIを必ず経由するので、IAMでこのAPIを呼び出せるユーザがだれかという観点で権限管理が可能です。また、このAPIが呼び出されたことをトリガすることで、CloudTrail にもログを残せます。
sshd レベルで権限を管理していたものが IAM での管理に一元化できますし、同様に sshd レベルでログイン履歴を残していたものが、CloudTrail に一元化できます。

単一のアベイラビリティーゾーン内の既存の配置グループに新しいインスタンスを追加しようとしていますが、容量不足エラーが発生しました。 このエラーは、配置グループ内の新しいインスタンスを収容するのに十分な容量がアベイラビリティーゾーンにないことを示します。

この問題をトラブルシューティングするには、配置グループ内のすべてのインスタンスを停止して起動し、新しいインスタンスを再度起動してみることをお勧めします。 このアクションにより、インスタンスが効果的に再起動され、追加のインスタンスを収容するのに十分な容量を持つアベイラビリティーゾーン内の別の基盤となるハードウェアにインスタンスが移行される可能性があります。

通常の使用時は低いベースラインのCPUパフォーマンスを提供し、必要に応じて高いCPUパフォーマンスにバーストできる、コスト効率の高いEC2インスタンスタイプです。

Auroraプライマリインスタンスは、書き込み操作を担当する単一のインスタンスであり、Auto Scalingを直接適用することはできません。スケーラビリティを向上させるためには、読み取り操作を分散させるAuroraレプリカに対してAuto Scalingを設定する必要があります。

• スナップショットを使用して RDS for PostgreSQL DBインスタンスを移行する
  データは、RDS for PostgreSQL DB スナップショットから Aurora PostgreSQL DB クラスターに直接移行できます。
• Aurora リードレプリカを使用して RDS for PostgreSQL DB インスタンスを移行する

  RDS for PostgreSQL DB インスタンスの Aurora PostgreSQL リードレプリカを作成して、RDS for PostgreSQL DB インスタンスから移行することも可能です。RDS for PostgreSQL DB インスタンスと Aurora PostgreSQL リードレプリカの間の複製ラグがない状態であれば、レプリケーションを停止することができます。この時点で、Aurora リードレプリカを読み書き用のスタンドアロン Aurora PostgreSQL DB クラスターにすることができます。

• オンデマンドモードでは、DynamoDB テーブルへの読み取り・書き込みリクエストの数に応じて、自動でキャパシティを調整して応答します。予測不可能なトラフィックパターンや短期間のピークを吸収するのに適しています。
• プロビジョニングモードでは、事前に秒間の読み取り・書き込みリクエスト数を設定し、静的にキャパシティを割り当てておきます。 割り当て済みのキャパシティで応答できない場合はスロットリングエラーを返します。 割り当てたキャパシティは後から停止なく変更可能です。またAutoScaling 機能があり、読み取り・書き込みリクエスト数の最小値と最大値を設定しておくと、実際のリクエスト数に応じて設定した範囲内でキャパシティを調整します。そのため予測可能なトラフィックパターンに適しています。

ElastiCache for Redisクラスターにレプリケーショングループを実装し、Multi-AZ機能を有効化することで、セッション管理の高可用性が確保されます。

Babelfish機能は Microsoft SQL Server用に書かれたアプリケーションからのSQLクエリ処理をPostgreSQLへ変換しSQLクエリ処理してくれる、オープンソースサービスです。

Babelfish for Aurora PostgreSQL は、SQL Server クライアントからデータベース接続を受け入れる機能を使用して Aurora PostgreSQL DB クラスターを拡張します。Babelfishより、従来の移行に比べて少ないコード変更で、またデータベースドライバを変更せずに、元々SQL Server 用に構築されているアプリケーションを直接 Aurora PostgreSQL で利用できるようになります。

データベース（Memory DB）やキャッシュサービスなどで、1年または3年の期間で事前に容量を予約することで大幅な割引を受けられるオプションです。

フルマネージド型のファイルストレージサービスになります。
FSxにはファイルシステムのタイプが以下の2種類あります。

• Amazon FSx for Windows File Server
  ビジネス向けで、Active Directoryとの連携が可能
  SMBプロトコルを介してアクセス

  (EFSはNFSプロトコル)

• Amazon FSx for Lustre
  機械学習や動画処理など速度が必要な高性能ファイルシステム
  ミリ秒未満のレイテンシーや最大1秒あたり数百ギガバイトのスループットで処理が可能
  高性能コンピューティング向けに設計された、フルマネージドの並列分散ファイルシステムで、Amazon S3とシームレスに統合できます。

AWS Backupを使用して、ファイルシステムのポイントインタイムバックアップを作成します。バックアップを新しいFSx for Windows File Serverファイルシステムにリストアします。ストレージタイプとしてSSDを選択します。適切なスループット容量を選択します。バックアップと復元プロセスが完了したら、DNSエイリアスを適宜調整します。元のファイルシステムを削除します

AWSが提供する完全マネージド型のOpenZFSファイルシステムで、高性能、データ整合性、POSIXコンプライアンスを備え、複数のアベイラビリティゾーンにまたがる高可用性を実現します。

POSIX準拠のアクセス制御: UNIXライクなオペレーティングシステムで標準化されたファイルシステムのアクセス権限モデルで、ユーザー、グループ、その他に対する読み取り、書き込み、実行権限を細かく制御できます。

アクセスポイントは、バケットにアタッチされた名前付きのネットワークエンドポイントで、S3 オブジェクトのオペレーション (GetObject や PutObject など) を実行するために使用できます。各アクセスポイントには、そのアクセスポイントを介したすべてのリクエストに S3 が適用する個別のアクセス許可とネットワークコントロールがあります。各アクセスポイントは、基になるバケットにアタッチされたバケットポリシーと連動して機能するカスタマイズされたアクセスポイントポリシーを適用します。仮想プライベートクラウド (VPC) からのリクエストのみを受け付けるようにアクセスポイントを設定することで、プライベートネットワークへの Amazon S3 データアクセスを制限できます。また、アクセスポイントごとにカスタムのブロックパブリックアクセスを設定することもできます。

S3に対する複数のアクセス可否を1つのバケットポリシーで管理する場合、10、100とルールが増えていくとバケットポリシーへ追記するのに時間がかかり、管理が複雑になっていきます。

一方アクセスポイントを使用することで1つの接続可否は1つのアクセスポイントポリシーで管理することができます。

Amazon S3 マルチリージョンアクセスポイントを使用すると、複数の AWS リージョン にある S3 バケットからのリクエストをアプリケーションが実行するために使用できるグローバルエンドポイントを作成できます。
マルチリージョンアクセスポイントを使用して、単一のリージョンで使用するのと同じシンプルなアーキテクチャでマルチリージョンアプリケーションを構築し、世界中のどこでもこれらのアプリケーションを実行することができます。マルチリージョンのアクセスポイントは、輻輳したパブリックインターネット経由でリクエストを送信する代わりに、Amazon S3 へのインターネットベースのリクエストを高速化する組み込みのネットワーク耐障害性を実現します。
マルチリージョンアクセスポイントのグローバルエンドポイントに対して行われたアプリケーションリクエストは、AWS Global Accelerator を使用して、AWS グローバルネットワークを介して、アクティブなルーティングステータスを持つ最も近い S3 バケットに自動的にルーティングされます。

マルチリージョンアクセスポイントを作成するときは、そのマルチリージョンアクセスポイントを介して提供されるデータを保存するAWSリージョンのセットを指定します。S3 クロスリージョンレプリケーション (CRR) を使用して、それらのリージョンのバケット間でデータを同期します。
その後、マルチリージョンアクセスポイントグローバルエンドポイントを介してデータを要求または書き込みできます。Amazon S3 は、最も近い利用可能なリージョンからレプリケートされたデータセットへのリクエストを自動的に処理します。
マルチリージョンアクセスポイントは、AWS PrivateLink for Amazon S3を使用するアプリケーションを含め、VPCで実行されているアプリケーションとも互換性があります。

次のイメージは、アクティブ-アクティブ構成の Amazon S3 マルチリージョンアクセスポイントを図で示したものです。この図は、Amazon S3 リクエストが最も近いアクティブな AWS リージョン に自動的にルーティングされる様子を示しています。

次のイメージは、アクティブ/パッシブ構成のAmazon S3マルチリージョンアクセスポイントを図で示したものです。この図は、Amazon S3データアクセストラフィックを制御してアクティブ-パッシブのAWSリージョン間でフェイルオーバーする方法を示しています。（数分でフェイルオーバーが可能）

オンプレからS3を使用するイメージ

• ファイルゲートウェイ

  オンプレに保存しているファイルをS3のオブジェクトとして保存する。
  S3の1オブジェクト＝オンプレの1ファイル
  直近に使用されたデータはゲートウェイ上に保存するため、低遅延なアクセスが可能。

  NFSとSMBを使用可能。

  RefreshCache APIを呼び出すことで、更新した際にS3のコンテンツ変更をローカルキャッシュに反映させます。

• ボリュームゲートウェイ

  オンプレのディスクデータのスナップショットをS3に保存する。

  S3の1オブジェクト=1スナップショット

  iSCSIブロックプロトコルを使用し、ファイルレベルのストレージではなく、ブロックレベルのストレージを提供します。

  • キャッシュ型

    プライマリデータをS3に保存して、頻繁にアクセスされるデータはキャッシュしてローカルに保持する。そのため頻繁にアクセスされるデータへの低遅延アクセスが実現できる。

    アプリケーションがデータをリクエストすると、ゲートウェイはまずキャッシュストレージでそのデータを探し、なければS3に探しにいく。

  • 保管型(ストア型)

    メインデータはローカルに保存する一方で、そのデータを非同期にAWSにバックアップする。データがローカルにあるので、データ全体に対して低遅延でアクセスできる。EBSへのリストア（＝復元）も可能。

• テープゲートウェイ

  物理テープライブラリの代替として、ストレージゲートウェイを仮想テープライブラリとして使用する。
  バックアップソフトウェアを使用することでS3、Glacierにデータを退避することもできる。

Amazon S3とDynamoDBの2つのサービスに対応しており、プライベートサブネットからこれらのサービスに直接アクセスできるようにします。これにより、インターネットゲートウェイ、NAT デバイス、または VPN 接続を必要とせずに、VPC をサポートされているサービスに接続できます。

また、ゲートウェイエンドポイントはVPC内のルートテーブルを利用し、プライベートIPアドレスを使用しないため、VPC内のプライベートIPアドレスを消費しません。さらに、ゲートウェイエンドポイントの使用には追加料金がかかりません。

一方、インターフェイスVPCエンドポイントは、他のAWSサービスやVPC内のお客様所有のアプリケーションに接続するために使用されます。

複数のアカウントにわたるS3を全体的に分析し、最適化したり、管理したりするためのダッシュボードとメトリクスを提供します。S3 Storage Lensのデフォルトダッシュボードは全リージョンのS3バケットのメトリクスを一元化して追跡できるため、運用オーバーヘッドが少なくなります。

S3バケット間のデータレプリケーションを15分以内に完了することを99.99%保証し、レプリケーションのパフォーマンスを監視・管理するための高度な機能です。

より安価なのは S3サーバーログ です。監査の参考やアクセスログ分析のために、まず検討しましょう。

CloudTrail S3ログ のほうが情報量が多いです。分析したい情報が S3サーバーログにない場合は使いましょう。
監査ログとしてS3オブジェクトの完全なアクセスログが必要な場合はCloudTrail S3ログを推奨します。
本番環境で機密性の高い情報を保存しているS3バケットに対してはCloudTrail S3ログを推奨します。
CloudTrail S3ログ は CloudWatch Logs + アラーム も設定可能で、想定外のS3オブジェクトアクセスがあった場合の通知ができます。

参照

まず、AWS Backup Vault Lockをコンプライアンスモードで実装することで、バックアップデータに対する不正な変更や削除を防ぐことができます。このモードでは、一度設定すると管理者でさえもロック設定を変更できなくなり、バックアップの完全性が保証されます。

また、指定された非本番アカウントのAWS Backup vaultを使用してクロスアカウントバックアップを実装することで、本番環境アカウントとは別のアカウントにバックアップを保存できます。これにより、本番環境アカウントが侵害されても、バックアップデータは別のアカウントに安全に保管されているため、影響を受けにくくなります。

さらに、AWS Backup vaultの変更を制限するSCP（サービスコントロールポリシー）を追加することで、組織レベルでバックアップvaultへのアクセスや変更を厳密に制御できます。これにより、特権ユーザーを含むすべてのユーザーがバックアップデータに不正にアクセスしたり変更したりすることを防ぐことができます。

S3内で継続的に機密情報があるかの検出を機械学習によって行う。

• VPCエンドポイント
  VPCと他サービス間でプライベートな接続を提供するコンポーネント
  サービス利用側のVPC内で作成
• AWS PrivateLink
  プライベート接続を介したサービスを提供するためのサービス
  以下の2つがセットとなり、AWS PrivateLinkが提供されている。
  • VPCエンドポイント（サービス利用側のVPC内で作成）
  • VPCエンドポイントサービス（サービス提供側のVPC内で作成）

詳細リンク

DXとトランジットゲートウェイを接続するには、DXゲートウェイをトランジットゲートウェイに関連付けする。

トランジットゲートウェイは同一リージョン内の複数VPCでしか利用できない、複数リージョンの複数VPCの場合トランジットゲートウェイ+DXゲートウェイの併用が必要となる。

参照1

参照2

Transit Gateway同士のピアリング接続を行うためには、ピアリングアタッチメントが必要になります。 作成方法は、アタッチメントを作成する際にアタッチメントタイプを「Peering Connection」に指定し、接続したいTransit Gatewayを選択するだけとなります。これによって異なるリージョン間VPCでの通信も可能となります。

参照

図中の色のついた丸です。Transit Gatewayに紐づいており、Transit Gatewayと別のネットワークの接点を意味します。
"VPC", "VPN", "Direct Connect Gateway", "Peering(他のTransit Gateway)"用のAttachmentが作れます。 また、各AttachmentにはTransit Gateway Route Tableを紐づけることができます。
各アタッチメントに個別のルートテーブルを作成することで、VPCごとに異なるルーティング設定が可能になります。これにより、特定のVPC間のみの通信を許可したり他のVPCとの不要な通信を防ぐといった制御ができます。

• Client VPN

  Client VPNはインターネット回線を利用して接続します。名前の通りクライアントPCからOpen VPNベースのVPN接続を可能にしています。Site-to-Site VPNはルータの準備が必要ですが、こちらはツールをダウンロードするだけで接続できるため、安価に即日で接続が可能です。テレワークで自宅環境から会社のAWS環境に接続したい場合などに利用できます。

• Site to Site VPN

  Site-to-Site VPNはインターネット回線を利用して接続します。専用線と比較すると回線の安定性は劣ります。オンプレ環境側にルーターを設置してIPsec VPNによる暗号化を実現しています。価格の安さと接続の容易さからDirect Connectのバックアップ回線として利用される場合もあります。

• AWS Transit Gateway + AWS Site-to-Site VPN

  

  次の図に示すように、ユーザー側でVPN 接続の冗長性とフェイルオーバーを実装できるように複数のユーザーゲートウェイ接続のサポートと推奨もします。

  

  またAWS Site-to-Site VPN 接続でアクセラレーションを有効にすることもできます。高速 VPN 接続では、AWS Global Accelerator を使用して、ネットワークからカスタマーゲートウェイデバイスに最も近い AWS エッジロケーションにトラフィックをルーティングします。このオプションを使用すると、トラフィックがパブリックインターネット経由でルーティングされるときに発生する可能性のあるネットワークの中断を回避できます。アクセラレーションは、次の図に示すように、Transit Gateway にアタッチされた VPN 接続でのみサポートされます。

  

• AWS Direct Connect + AWS Site-to-Site VPN

  AWS Direct Connect パブリック VIFs は、ネットワークと AWS Site-to-Site VPN エンドポイントなどのパブリック AWS リソースとの間に専用のネットワーク接続を確立します。サービスへの接続を確立したら、対応する Amazon VPC 仮想プライベートゲートウェイへの IPsec 接続を作成できます。
  end-to-endで安全なIPsec 接続を帯域幅を増やすことで低レイテンシーで行い、インターネットベースの VPN 接続よりも一貫したネットワークエクスペリエンスを実現します。

  

• AWS Direct Connect ＋ AWS Transit Gateway + AWS Site-to-Site VPN
  • public VIF

    AWS Direct Connect パブリック VIFs を使用して、まずネットワークと AWS Site-to-Site VPN エンドポイントなどのパブリック AWS リソース間の専用ネットワーク接続を確立できます。この接続が確立されたら、Transit Gatewayへの IPsec 接続を作成できます。

    

  • transit VIF

    

BGP（Border Gateway Protocol）は代表的な経路制御プロトコルの一つ。ASN(AS番号)とは、AS（Autonomous System）に一意に振られる番号です。 ASとは、BGPという経路制御プロトコルの制御単位であり、ネットワークのカタマリです。

BGPでは、異なるASに所属するルーター同士がBGPピアというペアになって、経路情報を交換しあいます。 ルーターはお隣のBGPピアに経路情報を渡すとき、AS_PATHという属性の先頭に自分のAS番号を付与してから渡します。 ルーターが経路情報をBGPから受け取ったとき、このAS_PATHに自分のAS番号が含まれている場合、「あ、自分のASの情報だ。ならいらないね。」と判断して、その経路情報を破棄します。 （これにより経路情報のループを防いでいます）

• Resolver

  VPCを作成した際に自動的に作成されるリソースです。Route53 Resolverは名前解決をする際にネームサーバー(ドメイン名とIPが紐づけてるサーバー)に転送をしてくれます。
  VPC内での名前解決や、オンプレミスと接続して名前解決を行う際に使います。

  AWSとオンプレミスネットワーク間のDNS名前解決をシームレスに行う機能です。

  • DNSエンドポイント（下記のEndpointのこと）：Route 53リゾルバで作成されるVPCのエンドポイントの一つで、DNSリクエストをリゾルバルール(ホストゾーンやDNSサーバなど)にルーティングするためのものです。
  • 条件付き転送ルール：特定のドメインへのクエリを指定したDNSリゾルバにルーティングするための設定します。

  

  

• Hostzone

  名前解決を行うためのサービスでパブリックとプライベートがあります。

  • パブリックホストゾーン

    パブリックホストゾーンはインターネット上で使用されるDNSホストゾーンです。
    例えば皆さんがgoogleの検索ページを表示する際、「google.com」と検索しますね？
    googleのIPアドレスを入力する人はまずいないでしょう。

    同じように、AWS上のリソースにカスタムドメイン名を割り当てて、インターネット上で検索できるようにするのが、このパブリックホストゾーンです。

    

  • プライベートホストゾーン

    VPC内でユーザーが取得したDNS名での名前解決ができます。
    IPアドレスにユーザーのカスタムドメインを割り当てられるため、リソースの識別が容易になります。そのため、複数のVPC間での名前解決やオンプレミスとのハイブリッド環境で使用されます。このプライベートホストゾーンの名前解決はRoute53 Resolverを介して行われます。
    

    

• Endpoint

  Route53には二つのエンドポイントがあります。「インバウンドエンドポイント」と「アウトバウンドエンドポイント」です。これは主にオンプレミスとのハイブリッド環境で使用されます。

  • インバウンドエンドポイント

    オンプレミスからAWS内のDNSを使って名前解決するために使います。
    インバウンドエンドポイントを使うことで、オンプレミス環境からRoute53 プライベートホストゾーンを使って名前解決することができます。

    

    もちろんインバウンドエンドポイントを使わずに直接EC2に接続することもできます。
    しかし、これはEC2に自動的に割り当てられたパブリックエンドポイントにアクセスすることになります。このパブリックエンドポイントはEC2の停止で変更される可能性があるため、その都度オンプレミス側にエンドポイントを伝える必要があります。
    EIPを使うことで固定にすることも可能ですが、Route53 プライベートホストゾーンを使っているならインバウンドエンドポイントを使うのが便利です。

  • アウトバウンドエンドポイント

    オンプレミスで使用しているDNSサーバーを使って名前解決を行う際に使います。
    オンプレミスからの拡張などで、すでに配置されているDNSサーバーを使いたい際などに有効です。
    ちなみに、オンプレミスのDNSサーバーで名前解決をする際は、Route53 Resolverで名前解決はオンプレミスのDNSサーバーを使う、という設定をする必要があります。

    

同一アカウント内であれば複数のVPCで一つのプライベートホストゾーンで名前解決が可能です。
しかし、複数のアカウントでVPC内の名前解決をする場合はResource Access Manager (RAM)を使って、プライベートホストゾーンを共有する必要があります。

アカウントXのRoute 53プライベートホストゾーンとアカウントYの新しいVPCを関連付けることが必要です。これにより、アカウントY内のEC2インスタンスがアカウントXのプライベートホストゾーンに定義されたDNSレコードを解決できるようになります。
また、この関連付けを行うためには、適切な権限が必要です。アカウントXのプライベートホストゾーンとアカウントYの新しいVPCを関連付ける権限を作成することで、アカウント間での必要な操作が可能になります。

• クロスアカウントDNS解決: 異なるAWSアカウント間でプライベートDNSレコードを共有し、解決する高度な設定で、VPCピアリングやAWS Resource Access Manager (RAM) を使用して実現します。
• VPC関連付け: プライベートホストゾーンをVPCに関連付けるプロセスで、クロスアカウント設定では、適切な権限と明示的な関連付けが必要となります。
• クロスアカウント権限: 異なるAWSアカウント間でリソースやアクションを共有するための IAM ポリシーや役割の設定で、セキュリティを維持しながら柔軟な運用を可能にします。

複数値回答ルーティングポリシーは、複数のレコードの中からヘルスチェックでOKとなったレコードのみランダムにアクセスするようにルーティングするポリシーです。

カスタムDHCPオプションセットを使用すると、独自のDNSサーバー、ドメイン名などを使用して VPCをカスタマイズできるようになります。
またVPC内のEC2インスタンスにDHCP設定を提供できます。必要な数だけ追加のDHCP オプションセットを作成できます。DHCP オプションセットを複数のVPCに関連付けることはできますが、各VPCに関連付けることができるDHCPオプションセットは1つだけです。

セキュリティグループやネットワークACLの分析に使用されるツールで、意図しないネットワークアクセスにつながるネットワーク設定を特定したり、構築後にネットワーク構成が要件通りか確認する際に役立ちます。

注意: 実際のネットワークトラフィックやサーバー間の通信を分析するためのものではありません。

SSL/TLS証明書に複数のドメイン名を含めることができる機能で、単一の証明書で複数のサイトをセキュアに運用できます。ACMで発行したSSL証明書でもこの機能を利用することができます。

NLBは固定IPアドレスを提供できる唯一のAWSマネージドロードバランサーであり、これによりファイアウォールアプライアンスでのホワイトリスト登録が可能になります。固定IPアドレスは、オンプレミスネットワークからAWS環境へのトラフィックフローを一貫して許可するために不可欠です。

また、NLB用にALBタイプのターゲットグループを作成し、既存のALBを追加することで、ALBの高度な機能（HTTPSの終端、パスベースルーティングなど）を維持しつつ、固定IPアドレスの要件を満たすことができます。これにより、システムの既存の機能を変更することなく、セキュリティ要件を満たすことが可能になります。

さらに、複数のアベイラビリティゾーンにわたってNLBを設定することで、高可用性も確保されています。

NLBの作成をし、Network Mappingの中のVPCで、NLBを配置するVPCを選択する。

同じくNetwork Mappingの中のMappingsで、Availability Zoneを選択します。Availability Zoneのチェックボックスにチェックを入れると、SubnetとIPv4 settingsの設定が表示されるので、それぞれを設定します。このとき、IPv4 settingsは「Elastic IPの使用(Use an Elastic IP address)」を選択し、上記で設定したElastic IPを選択します。

NLBは各アベイラビリティゾーンのElastic IPアドレスと関連付けられ、複数のアベイラビリティゾーンにわたる高可用性と冗長性を提供します。

• OpenID Connect準拠のIDプロバイダー (IdPOIDC) を介してユーザーを認証します。
• Amazon、Facebook、GoogleなどのソーシャルIdPをAmazon Cognitoユーザープールを通じてユーザーを認証します。
• SAML、OpenID Connect (OIDC）またはOAuthなどAmazon Cognitoでサポートされているユーザープールを使用して、コーポレイトIDのユーザーを認証します。

ファイアウォール、侵入検知/防止、ディープパケットインスペクションなどの仮想アプライアンスをデプロイ、スケーリング、管理するのに利用できるLBです。VPC内へのすべての通信を透過的に（セキュリティ）アプライアンス経由にするなどで利用します。

サードパーティのセキュリティ製品などをAWS上で利用する場合、従来ではNLBを挟んだり、VPC PeeringやTransit Gatewayなどでネットワークをつないでルーティングしたり、NATして連携したりしていたところを、GWLBとGateway Load Balancer Endpoint(GWLBE)を利用することによりシンプルにスケール・可用性・サービス提供のしやすさを向上することが可能になります。

• L3(ネットワークレイヤー)で機能し、すべてのポートのすべてのパケットをリスナールールで指定されたターゲットグループに転送する（L3/L4なのでALBを直接繋ぐことなどはできない）
• ゲートウェイロードバランサーはゲートウェイロードバランサーエンドポイント(VPCエンドポイント)を利用し、VPCを超えてトラフィック分散を行う
• ゲートウェイロードバランサーは仮想アプライアンスと同じVPCにデプロイする
• ゲートウェイロードバランサーはリスナーとターゲットグループを利用して宛先と振り分けルールを定義する(ALBと同じ)

• リージョン

  直接リージョンにルーティングされます。同一リージョンの場合、エッジロケーションを経由しない分、レイテンシを削減できます。

  デフォルトのエンドポイントタイプです。

  自前の CloudFront と組み合わせることでエッジ最適化の構成にすることもできます。既に CloudFront を利用しているシステムの場合にこのような構成になります。

  自前の CloudFront を利用する場合は、API Gateway のエンドポイントをリージョンにしておきます。エッジ最適化を選択していると、自前の CloudFront から、AWS が管理する CloudFront を経由して、API Gateway にアクセスすることになり、不要なレイテンシが発生したり、HTTP ヘッダーが予期しない値となったりするので注意が必要です。CloudFront を経由すると一部のヘッダーを書き換えます。自前の CloudFront はこれを回避することができますが、AWS が管理する CloudFront は設定を行うことが出来ません。

  

• エッジ最適化

  CloudFront のエッジローケーションを経由して、最適なリージョンにルーティングされます。

  エッジロケーションからリージョンまでは AWS 内のネットワークが利用されるので高速です。エッジロケーションは AWS が管理します。

  

• プライベート

  VPC 内から AWS PrivateLink でのみアクセスできるエンドポイントです。

  

RESTful APIよりも軽量で高速なAPIを構築するためのAWSサービスで、WebhookやシンプルなAPIに適しています。

• 利用プラン: API Gatewayで、開発者または顧客に対して特定のリクエストのクォータとレート制限を設けることができます。これにより、APIの使用を管理できます。
• APIキー: API Gatewayで作成され、特定の顧客がAPIにアクセスするために利用します。

利用プラン、APIキーは共にAmazon API Gateway REST APIの機能で、Amazon API Gateway HTTP APIでは利用できません。

CloudFrontが複数のオリジンからコンテンツを取得するための設定の集まりです。

オリジングループ機能を利用することで、原則とフェールオーバーオリジンを指定できます。それにより、一つのオリジンが停止した場合に自動的に複数のオリジンの中から別のオリジンに切り替わる設定が可能になります。

さらに、CloudFrontディストリビューションのキャッシュ動作でオリジンフェールオーバーを設定することで、原則となるオリジンがダウンしてもフェールオーバーを素早く発生させることが可能です。これらの機能により、利用者が最小のダウンタイムでサービスを継続利用することが可能となります。

CloudFrontでリクエストとレスポンスの両方を操作できるコンピューティング機能です。ヘッダーやURLなど、HTTPトランザクションに対して独自のロジックを追加できます。

lambda@edgeはより複雑な処理を想定している。（CloudFront関数の方が軽量）

CloudFront Functions と Lambda@Edge の違い

CloudFrontはフィールドレベルで情報を暗号化する機能を提供します。これにより、公開鍵を使用してクライアント送信データを暗号化し、その機密情報を適切に扱うマイクロサービスでのみ情報を復号化できます。このメカニズムにより、エンドツーエンドのデータの安全性を確保できます。

また、公開鍵をCloudFrontディストリビューションにアップロードすることで、特定のマイクロサービスが秘密鍵を保持し、その鍵によってのみデータを復号化できるようになります。これがクライアントデータの安全性を高めます。

さらに、フィールドレベルの暗号化プロファイルと設定を作成してCloudFrontのキャッシュ動作に設定を追加することで、必要なフィールドのみを暗号化し、認証されたマイクロサービスだけがその情報を復号化できます。これにより、データのセキュリティとプライバシーの保護が強化されます。

スタックを更新する必要がある場合は、変更の実装前に実行中のリソースに与える影響を理解することで、安心してスタックを更新できます。
変更セットは、スタックに対して提案された変更が実行中のリソースにおよぼす影響を事前に確認できるようにします。これには、リソースのプロパティや属性に対する影響が含まれます。変更が重要なリソースを削除するか置き換えるかにかかわらず、AWS CloudFormation が変更を行うのはユーザーが変更セットの実行を決定したときのみであるため、提案された変更をそのまま続行するか、別の変更セットを作成して他の変更を検討するかはユーザーが決定できます。
変更セットは、CloudFormation コンソール、AWS CLI、または CloudFormation API を使用して作成および管理できます。

参照

S3内のオブジェクトを全て削除するLambda関数をカスタムリソースとして使用することで、CloudFormationのライフサイクル管理に組み込むことができます。これにより、スタックの削除プロセスの一部としてS3バケット内のファイルを自動的に削除することが可能になります。このカスタムリソースには、S3バケットのリソースを参照するDependsOn属性を設定します。

DependsOn属性を設定することで、S3バケットのリソースが完全に作成された後にのみこのカスタムリソースが実行されることを保証します。これにより、削除プロセスの順序が適切に管理され、エラーを防ぐことができます。（S3が作られて無いのにS3内のオブジェクトを削除するLambda関数の実行を防ぐ）

注意: DeleteというDeletionPolicy属性は、CloudFormationスタックの削除時にS3バケットを自動的に削除するよう指示しますが、バケット内にオブジェクトが存在する場合、依然として削除に失敗します。

CloudFormationテンプレート内のリソースに適用できる属性で、スタック削除時のリソースの扱いを制御し、意図しないデータ損失を防ぐことができます。この属性には「Retain」や「Snapshot」などの値を設定でき、「Retain」を指定すると、スタック削除時にもリソースが保持されます。

• スタックポリシー: CloudFormationスタックに適用される JSON ドキュメントで、スタック操作中に特定のリソースの更新や削除を制限することができます。

スタック セットのテンプレートには、カスタム名を持つ IAM ロールが含まれています。インスタンスを正常に作成するために、CAPABILITY_NAMED_IAMを指定する必要があります。このパラメータを指定しない場合、このアクションはInsufficientCapabilities エラーを返します。

• Customer Managed Key
• AWS managed key
• AWS owned key

https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt

AWS KMSはマスターキーと暗号化されたデータキーを管理する。

https://dev.classmethod.jp/articles/10minutes-kms/

• IAMによるユーザベースコントロール
• キーポリシーによるリソースベースコントロール
• 許可(Grants)によるリソースベースコントロール

  特定のIAMユーザやIAMロールなどにCMKの利用を許可することができる機能で、名前の通り、ホワイトリスト方式(拒否の明示ができない)。SDKやCLIで「許可」の作成を行うことで指定する。

  Copy

  aws kms create-grant \
    --key-id <key_id> \
    --grantee-principal arn:aws:iam::<account_id>:user/<user_name> \
    --operations Decrypt \
    --retring-principal arn:iam::<account_id>:role/<admin_role_name>

AWS Key Management Service (KMS) の機能で、複数のAWSリージョンで同一の暗号化キーを使用可能にし、クロスリージョンの暗号化操作を簡素化します。

KMSマルチリージョンカスタマーマネージドキーを作成し、各リージョンにレプリカキーを作成することで、暗号化キーの一貫性を保ちつつ、複数リージョンでの運用が可能になります。これにより、各リージョンで同じキーを使用してデータを暗号化・復号化できるため、リージョン間でのデータの移動や処理が容易になります。

また、既存のシークレットマネージャーのシークレットを他のリージョンに複製することで、各リージョンで必要な認証情報やAPIキーにアクセスできるようになります。複製された各シークレットに適切なKMSキー（この場合それぞれのリージョンでのKMSレプリカキー）を選択することで、セキュリティを維持しつつ、リージョン間で一貫した秘密情報の管理が可能になります。

https://dev.classmethod.jp/articles/difference-between-kinesis-streams-and-kinesis-firehose/

一つのデータストリームが複数の消費者にデータを同時に提供することで、スケーラビリティと性能を向上させる手法です。

参照

エラーが起こった時に再試行する際、次の試行までの間隔を徐々に増やす技術です。これにより、一時的に問題が発生している場合でも、その問題が解決するのを助けます。AWS SDK を使用するコンシューマーアプリケーションの場合、リクエストはデフォルトで再試行されます。

ログやマシンデータをリアルタイムに収集・分析するためのソフトウェアです。Kinesis Data Firehoseと連携してAWSのログデータを取り込むことができます。

• Amazon MQ

  既存サービスでMQを使っており、そこからAWSへ乗せ替えたい場合。
  ActiveMQ/RabbitMQいずれかのブローカーを選択してインスタンスを立ち上げる。
  そのため、キューを使っていない時間帯でもずっとインスタンス料金が課金される。
  使用状況によってはスケーリングの考慮やマルチAZによる冗長化も必要。

• SQS

  上記以外の場合(新規立ち上げなど)
  フルマネージドのメッセージキューサービス。Amazon MQと異なり、スケーリングの考慮や冗長化を考慮する必要が無くなる。
  また、従量課金による請求なので使用した分だけの料金になる。(インスタンス料金みたいなのは無い)
  Lambdaとの相性がとても良く、SQSにデータが溜まった時点でLambdaを実行するが簡単に実現できる。1件ずつではなくてある程度溜まった時点で実行もできる。

デッドレターキューに移行するまでのキューのコンシューマーでの最大実行回数。1だと1回失敗するとすぐにデッドレターキューに移る。

AWSのベストプラクティスに基づいて作成されたアカウントを展開していく仕組みになります。あくまで、Landing Zoneはサービスではなく仕組みです。多数のアカウントのセキュリティなどを一定に保つためのものです。

https://qiita.com/miyuki_samitani/items/bd969f900066fde83160

まず、AWS Configはリソースの設定履歴と設定変更を追跡するサービスであり、EC2のセキュリティグループのようなAWSリソースの設定変更を検出し、保存します。
したがって、エンジニアが行ったセキュリティグループ設定の変更を追跡するために最適です。
さらに、AWS Configは規定の設定に準拠していないリソースを特定するためのパワフルなツールであり、これによりコンプライアンス違反の変更を追跡することが可能になります。

AWS Config は 主に以下 2つの機能を持つサービスです。

• Record: 設定レコーダーによるリソースの継続的な記録
• Evaluate: Configルールによる構成情報の評価

根幹の機能が「設定レコーダー(Configuration Recorder)」です。

AWSリソースに関する「今どのような設定か」や「いつ、どのような更新がされたか」、「他のリソースとどう関連するか」を継続的に記録してくれます。

そして、その構成情報が「理想的な状態かどうか」を評価してくれるものが Configルールになります。評価の例としては「セキュリティグループでSSH全開放になっていないか」や「S3バケットがパブリック公開されていないか」などがあります。

クラウド(AWS)を使うメリットとして、良く挙げられるフレーズとして「アジリティとガバナンスの両立」があります。AWS Config は ガバナンスを引き上げるために必要不可欠なサービス となります。

Configアグリゲーターは複数アカウント・複数リージョンのConfigデータ(リソース構成情報や Configルールの評価結果)を集約してくれる、とても便利な機能です。特にマルチアカウント管理において役に立ちます。
Configアグリゲーターをざっくりと理解するにあたって、ソースアカウントとアグリゲーターアカウントは把握しておきたいです。
アグリゲーターアカウントは、そのままで「アグリゲーターを作成するアカウント(リージョン)」になります。ここに複数アカウント(複数リージョン)のConfigデータが集約されます。"集約先" になるアカウントです。
ソースアカウントが "集約元" になるAWSアカウント群になります。「個々のアカウントIDを明示的に指定する方法」と「AWS Organizationsの組織全体を指定する方法」の2つがあります。
ちなみに、Configアグリゲーター自体には料金はかかりません。それぞれのアカウントで使っているConfig記録やConfigルールにのみ料金がかかります。

メンバーアカウントを作成すると、AWS OrganizationsによってOrganizationAccountAccessRole という名前の AWS Identity and Management (IAM) ロールがアカウントに自動的に作成されます。このロールには、メンバーアカウントの完全な管理権限が含まれます。このロールのアクセス範囲には、管理アカウント内のすべてのプリンシパルが含まれます。

• 新しく作成されたメンバーアカウントは次の手順に従って OrganizationAccountAccessRole を引き受けます。管理アカウントに管理者権限を付与する IAM ユーザー認証情報を使用して、AWS マネジメントコンソールを開きます。次に、管理アカウントの IAM グループのメンバーに、ロールにアクセスするためのアクセス権限を付与します。メンバーアカウントのロールに切り替えます。
• 組織に参加する招待されたメンバーアカウントには、管理者ロール(OrganizationAccountAccessRole)が自動的に付与されることはありません。そのため OrganizationAccountAccessRole を手動で作成する必要があります。これにより、ロールはコピーされ、作成されたアカウントに自動的に設定されます。一貫性と覚えやすさの点から、手動で作成したロールには、同一の名前OrganizationAccountAccessRole を使用することをお勧めします。

参照

デフォルトのFullAWSAccess SCPを削除することが推奨されないません。

FullAWSAccess SCPは、組織内のアカウントに対してすべてのAWSサービスへのアクセスを許可する基本的なポリシーであり、これを削除すると予期せぬアクセス制限が発生する可能性があります。代わりに、ブラックリスト方式のポリシーを実装し、特定のサービスへのアクセスを制限することで、より柔軟かつ安全なアクセス管理を実現できます。

• タグポリシー

  AWS Organizationsで設定可能なポリシーの一つで、リソースのタグ付けに対するルールを強制できます。

• TagOption

  Service CatalogでCloudFormationスタックレベルでポートフォリオまたは製品にタグを紐づけできる機能です。TagOptionを使用すると、利用者が製品起動時のタグを指定することができます。
  タグ設定を管理するTagOptionライブラリでは、アカウントのリージョン内で、Key・Value の組合せが一意である必要があります。
  そのため、シングルスタック構成でTagOption をシンプルに実装した場合、本番・開発環境で各スタックの論理 ID を分けていたとしても、Key・Value の重複が発生します。

そのためタグポリシーとTagOption間でコンフリクトが起きる場合があります。

• タグポリシーでタグの適用のチェックがオンになっている場合、Service Catalogで製品を起動する際に非準拠のタグが原因を指定することで起動に失敗します。
• タグキーの大文字と小文字の区別のコンプライアンスを規定しない場合、デフォルトでタグキーはすべて小文字になります。

参照

AWS Control Towerで提供される、AWSリソースの利用に関するポリシーのことで、予防・検出のコントロールを提供します。
SCPは、AWSサービスへのアクセスを制御しますが、具体的なインスタンスタイプ（バースト可能なインスタンスなど）まで制御することはできません。

SCPはroot, OU, アカウントレベルでアタッチ可能

AWSリソースに適用されるユーザー定義のメタデータで、コストを詳細に分類・追跡するために使用され、請求書やレポートでフィルタリングや分析が可能になります。

注意: AWSが自動生成するタグは、リソースの基本的な属性（例：インスタンスタイプ、リージョン）を示すものであり、アプリケーションやチームといった特定のビジネスコンテキストを反映するものではありません。

Serverless版は勝手にやってくれる機能なので、これらはProvisioned版でのみ

• 同時実行スケーリング: クエリの同時実行数が増加した際に、自動的に追加の計算リソースを割り当てることで、パフォーマンスを維持する高度なスケーリング手法です。（デフォルトでは無効なので有効化が必要）
  予期せぬ使用量の急増に対して自動的に対応することができます。この機能により、クラスターは必要に応じて一時的な計算能力を追加し、複雑な読み取り操作を含むクエリの処理に対応することができます。
  また、この機能はCPUに高い負荷がかかる状況に特に効果的です。常に読み取りと書き込みのクエリに対応できる状態を維持することが可能となります。
  さらに、同時実行スケーリング機能は、使用量に応じて自動的にスケールアップとスケールダウンを行うため、手動での管理や監視が不要です。これにより、運用の効率化とコスト削減を同時に実現することができます。
• Elastic Resize: 月末月初や、夜間バッチなど予測可能な高負荷に対して一時的にクラスタをスケールアップするのがElastic Resize（伸縮自在なサイズ変更）。

• Athena
  新しく取得したデータの中身について検証
  障害時のログ調査
  大規模なデータに対しての低頻度のETL処理（1回につき２0分など）
• Redshift Spectrum
  S3上に保存されているデータに対してRedshiftと同様に分析を行うことができ、これまで連携していたBIツールの利用も既存のRedshift同様に使用できます。

  結合が含まれないような構造化および半構造化されたデータに対しての高速な処理
  大規模なデータに対してのETL処理
  常時稼働のRedshiftクラスターが必要

Elastic Map ReduceはApache Spark、Apache Hive、Presto などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションです。またストレージとしてHadoopも使用可能です。

AWSのリソース使用とコスト最適化についての推薦を提供するツールです。データインポートテンプレートを提供しており、CMDBエクスポートからのデータを使用可能です。

VM Import/Export を使用すると、仮想マシン (VM) イメージを既存の仮想化環境から Amazon EC2 にインポートし、それを元の環境にエクスポートすることができます。この方法を使うと、アプリケーションおよびワークロードを Amazon EC2 へ移行したり、VM イメージカタログを Amazon EC2 にコピーしたり、バックアップと災害対策のために VM イメージのリポジトリを作成したりすることができます。

オンプレミスの仮想マシンをAWSクラウドに自動的に移行するサービスで、大規模な移行を効率的に管理できます。VMware、Hyper-V、Azure上の仮想サーバをAMIとしてAWSに移行することができます。
AWS SMSは、増分レプリケーションを行うことができるため、初期の大規模データ転送後も、変更されたデータのみを効率的に同期できます。これにより、最終的なカットオーバー時のダウンタイムを最小限に抑えることができます。
あくまで、仮想マシンのサーバを移行することはできますが、物理サーバの移行はできません。また移行の計画段階や現在の環境の理解、コスト見積もりには直接関与しません。

物理インフラストラクチャ、VMware vSphere、Microsoft Hyper-V、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Virtual Private Cloud (Amazon VPC)、およびその他のクラウドから AWS にアプリケーションを移行できます。

• VMware vSphere: 企業のITインフラを仮想化するための総合的なプラットフォームです。 物理サーバ上で複数の仮想マシンを動作させ、それらを一元的に管理することで、リソースの最適化、運用コストの削減、高可用性を実現します。

仮想環境だけでなく物理環境に対応します。これはエージェントを移行元サーバにインストールするいわゆる「エージェント方式」を採用しているためです。また、ブロックレベルの継続的なデータレプリケーションを使用することでダウンタイムを最小限に抑えられます。

AWS は現在、移行には AWS MGNの利用を推奨していますが、これまでの AWS Server Migration Service (AWS SMS) や VM Import とは何が違うのでしょうか。

AWS SMS や VM Import も AWS が提供している仮想マシンの移行サービスです。対応している移行元は VMware ESXi、Microsoft Hyper-V、Microsoft Azure 上の仮想マシンとなります。これらの仮想マシンを AWS の AMI（Amazon マシンイメージ） として AWS へ簡単に移行させることができます。

以下はAWS MGNとの大きな違い

• 無期限で無料（データ保存用に Amazon S3 を使用するのと、移行後は Amazon EC2 として稼働するため、それらの AWS 利用料は通常通り発生します）
• 古いOSにも対応している
• 物理マシンには対応していない
• エージェントレス（移行元にエージェントをインストールしなくてよい）

特にエージェントレスは大きなポイントかもしれません。どうしてもシステムによっては「エージェントをインストールできない」ケースもあるかと思いますので、その際は AWS SMS や VM Import が選択肢として入ってきます。

では結局どの移行サービスを使えば良いのか？ ざっくり以下のように考えましょう。

1. AWS MGN が使える環境なら MGN
2. AWS MGN が使えない環境なら CloudEndure （OSが古い、MGN 未対応リージョン等）
3. エージェントがインストールできない環境なら AWS SMS
4. AWS SMSが利用できない環境なら VM Import （AWS SMSで必須となるVMware vCenter がない場合の選択肢）

VMware vSphere3.5以降の機能で、仮想環境上で稼働中のOSやユーザセッションを停止させることなく、複数の物理サーバ間で仮想マシンを移動させる機能です。
この機能により、システムを停止させる事なく物理サーバをメンテナンスすることが可能になります。

vMotionでの移行は次の3段階の処理で実行されます。

1. vMotion での移行が要求されると、vCenter Server は既存の仮想マシンが現在のホストで安定状態にあることを確認します。
2. 仮想マシンの状態情報 （メモリ、レジスタ、ネットワーク接続） がターゲット ホストにコピーされます。
3. 新しいホスト上で仮想マシンがアクティビティをレジュームします。※移行中にエラーが発生した場合、仮想マシンは元の状態および場所に戻されます。

組織のクラウド導入準備状況を評価し、移行戦略の策定を支援するAWSの無料ツールで、ビジネス、人材、プロセス、プラットフォーム、運用、セキュリティの各側面を分析します。

オンプレミスとAWSストレージサービス間、またはAWSストレージサービス間で大量のデータを高速かつ安全に転送・同期するマネージドサービスです。主にデータ移行やバックアップに適してます。（リアルタイムの編集ワークフローには適していません。）

毎日のスケジュールでデータを複製することで、オンプレミス環境とクラウド環境の両方でコンテンツを最新の状態に保つことができます。これにより、段階的な移行が可能となり、ビジネスの継続性を確保しながら、クラウドへの移行を進めることができます。
AWS DataSyncエージェントをオンプレミスのハイパーバイザー上の仮想マシンにデプロイすることで、オンプレミスの既存インフラストラクチャを活用しつつ、最小限の運用負荷でバックアップやデータ移行を実現できます。

注意: AWS Data Pipelineがビッグデータの処理や分析に特化したサービスであり、日々のファイル同期には適していません。Data Pipelineは複雑なデータ処理ワークフローの自動化に適していますが、大量のファイルを効率的に転送するための最適化された機能を持っていません。また、Data Pipelineはファイルシステム間の直接的な同期をサポートしてません。

手頃な料金のストレージ、最小限のコンピューティング、ポイントインタイムリカバリを使用して、オンプレミスおよびクラウドベースのアプリケーションを迅速かつ確実に復旧することで、ダウンタイムやデータ損失を最小限に抑えます。

Kubernetesが提供するフィーチャーで、Podの配置をさまざまなトポロジー間で均等にスプレッドすることを目指します。

トポロジースプレッド制約を使用することで、Podが均等に分散され、特定のノードやアベイラビリティゾーン（AZ）に過剰な負荷がかかるのを防ぎます。これにより、単一のノードやAZの障害がPodの大部分に影響を与えるリスクが低下します。
また、ワークロードが急増した場合でも、Podは複数のノードやAZに広がるため、ワークロードの急激な変動に対してもクラスターの安定性を維持できます。
このように、Amazon EKSのワークロードに対する回復力を最大化するためには、アベイラビリティゾーンに基づくトポロジースプレッド制約を使用することが効果的です。

• ECS auto scaling

  ECSサービスのタスク数を、設定したメトリクスに基づいて自動的に調整する機能で、トラフィックの変動に応じてアプリケーションの可用性と効率性を維持します。

• EKS
  • Karpenter(AWS managedではなく、サポートするKubernetesのスケーリング)

    Karpenter では、1 分以内にアプリケーション負荷の変化に応じて、適切なサイズのコンピューティングリソース (Amazon EC2 インスタンスなど) を起動します。KubernetesとAWS を統合することで、Karpenter は、ワークロードの要件を正確に満たすジャストインタイムコンピューティングリソースをプロビジョンできます。Karpenter は、クラスターワークロードの具体的な要件に基づいて、新しいコンピューティングリソースを自動的にプロビジョンします。これには、コンピューティング、ストレージ、高速化、スケジューリングの各要件が含まれます。

  • Cluster Autoscaler

    ポッドが失敗したり、他のノードに再スケジュールされた場合に、クラスター内のノード数を自動的に調整します。Cluster Autoscaler は Auto Scaling グループを使用します。

• EC2 起動タイプ
  • awsvpc: タスクには、独自の Elastic Network Interface (ENI) とプライマリプライベート IPv4 アドレスが割り当てられます。これにより、タスクに Amazon EC2 インスタンスと同じネットワークプロパティが与えられます。
    awsvpc ネットワークモードによりコンテナのセキュリティも強化されます。これは、セキュリティグループやネットワークモニタリングツールを、タスク内でより詳細なレベルで利用できるためです。VPC フローログなどの各種 Amazon EC2 ネットワーキング機能により、タスクが送受信するトラフィックをモニタリングできます。
  • host: Amazon ECS でサポートされている最も基本的なネットワークモードです。host モードでは、コンテナを稼働しているホストに直接関連付けられます。

    

    上の図に示したようなポート 3000 でリッスンする Express アプリケーションで Node.js コンテナを実行していると仮定します。host ネットワークモードを使用すると、コンテナは基盤となるホストの Amazon EC2 インスタンスの IP アドレスを使用してポート 3000 でトラフィックを受信します。このモードを使用しないことをお勧めします。

    このネットワークモードを使用することには重大な欠点があります。各ホストで 1 つのタスクを複数インスタンス化することはできません。これは、Amazon EC2 インスタンスの必要なポートにバインドできるのは最初のタスクだけだからです。また、host ネットワークモードを使用している場合、コンテナポートを再マップする方法はありません。例えば、アプリケーションが特定のポート番号でリッスンする必要がある場合、ポート番号を直接再マップすることはできません。代わりに、アプリケーション構成を変更してポートの競合を管理する必要があります。

    host ネットワークモードを使用する際には、セキュリティ上の問題もあります。このモードでは、コンテナがホストになりすますことができ、コンテナはホスト上のプライベートループバックネットワークサービスに接続できます。

  • bridge: 仮想ネットワークブリッジを使用してホストとコンテナのネットワーク間にレイヤーを作成します。これにより、ホストポートをコンテナポートに再マップするポートマッピングを作成できます。マッピングは静的または動的に実行することができます。

    

• Fargate 起動タイプ

  デフォルトでは、Fargate 上のすべての Amazon ECS タスクには、プライマリプライベート IP アドレスを備えた Elastic Network Interface (ENI) が提供されます。パブリックサブネットを使用する際には、オプションで、タスクの ENI にパブリック IP アドレスを割り当てることができます。
  各タスクにはそれぞれ独自の ENI が提供されるため、VPC フローログなどのネットワーキング機能を使用して、タスクとの間で送受信されるトラフィックをモニタリングできるようになります。
  （EC2 起動タイプのawsvpcネットワークモードとほとんど等しい）

共有ライブラリ、カスタムクラス、APIのLambda関数のコードをDockerイメージにデプロイします。Amazon Elastic Container Registry（Amazon ECR）にイメージをアップロードします。Dockerイメージをデプロイパッケージとして使用するように、APIのLambda関数を設定します

Lambda関数の同時実行数を事前に予約することで、関数の起動時間を短縮し、一定量の使用に対して割引を受けられる機能です。

あるルールに一致したリクエストの数をカウントしますが、リクエスト自体には影響を与えません。

初期設定時には、どのリクエストがブロックされるかを確認するために、「Count」に設定することが推奨されます。これにより正当なトラフィックがブロックされることを防ぎつつ、不審なトラフィックを確認することができます。

次に、AWS WAFのロギングを有効にすることで、ブロックするつもりのリクエストの詳細情報を取得することができます。そしてそのログを分析し、誤検出を避けるためにルールを修正します。

最後に、問題点が解決した後で、ルールのアクションを「Count」から「Block」に変更します。こうすることで、本番環境で不審なトラフィックをブロックするように切り替えることができます。これは段階的な導入を可能にし、正当なトラフィックに影響を与えるリスクを最小限に抑えることができます。

AWSが提供する事前設定されたセキュリティルールセットで、一般的なウェブ攻撃や脆弱性から保護するためにWAFで使用されます。

ECR, EC2の脆弱性診断を行うサービス

・自動検出と継続的なスキャンができる

手動でスケジュール設定を行う必要はないのが一つのメリットです。変更があった際には、自動的にリソースをスキャンしてくれます。
スキャン対象として識別された Amazon ECR に存在するすべてのAmazon EC2インスタンス、Lambda 関数、およびコンテナイメージが自動的に検出され、ソフトウェアの脆弱性や意図しないオープンネットワークパスがないかどうかのスキャンがすぐ行われます。
新しいCommon Vulnerabilities and Exposures（CVE、共通脆弱性識別子）が公開されたとき、または EC2 インスタンスへの新しいソフトウェアのインストール等、ワークロードに変更があったときに自動的かつ継続的にスキャンがされる仕組みです。

・SSMエージェントの利用

SSMエージェントを使って、Amazon EC2 インスタンスのソフトウェアのインベントリと設定を収集します。インベントリについては、脆弱性の評価に使われます。

・リスクスコアが可視化できる

CVE情報と紐づけたリスクスコアの算出ができます。調査結果に優先順位付けができるので、最も重要な調査結果と脆弱なリソースがハイライトで表示されます。

・詳細なモニタリングができる

ほぼリアルタイムのビューを見ることができます。Amazon Inspectorを使用するアカウント、Amazon EC2 インスタンス、Amazon ECR リポジトリ、Amazon Inspectorによってアクティブにスキャンされているコンテナイメージに関するメトリクスと詳細情報の確認を行うことができます。
さらに、アクティブに監視されていないリソースを強調表示し、どうやってInspectorを追加するかのガイダンスを提供します。

・他サービスと組み合わせて利用する

検出結果については、Amazon Inspectorコンソールに集約されます。他のセキュリティサービスであるAWS Security Hub と組み合わせて利用できます。
Amazon EventBridgeからAWSLambda 関数とAmazon Simple Notification Service (Amazon SNS）へ通知を行い、チケット発行などのワークフローが自動化されます。

AWS 環境内の AWS データソースとログを継続的にモニタリング、分析、処理する脅威検出サービスです。 GuardDuty は、悪意のある IP アドレスとドメインのリスト、ファイルハッシュ、機械学習 (ML) モデルなどの脅威インテリジェンスフィードを使用して、 AWS 環境内の疑わしいアクティビティや悪意のある可能性のあるアクティビティを特定します。

AWS アカウントでGuardDutyを有効にすると 、そのアカウントに関連付けられた基本的なデータソースを取り込み、GuardDutyを自動的に開始します。これらのデータソースにはAWS CloudTrail 管理イベント、VPCフローログ (Amazon EC2インスタンスから）、DNSログなどが含まれます。

IAMロール は、 特定のユーザーやアプリケーションに一時的な権限を与えるため、必要最小限の権限を付与できる。「最小権限の原則」を実現し、セキュリティを向上させる。
サービスロール は、信頼ポリシーが設定されており、必要なアクセス権のみを持つため、不要な権限を削減できる。

Amazon Aurora, RDSで利用可能な認証方式の一つで、IAMユーザーやロールを利用してデータベースに接続します。認証情報が漏洩した場合の影響を最小限に抑えることが可能です。

AWSリソースへのアクセスを分析するサービスです。EventBridgeルールのターゲットとしてSNSトピックを指定することで、パブリックアクセスがあった場合に警告することに利用できます
注意: AWS Configルールは定期的に評価されるため、公開された瞬間にアラートを送信することができません。

また、IAM Management Access Analyzerは、CloudTrailログに記録されたアクティビティを自動的に分析し、各サービスに必要な最小限の権限を持つIAMポリシーを生成することもできます。これにより、手動で各サービスの権限を分析する労力を大幅に削減できます。

• ID Provider（IAMとのフェデレーションで単一のスタンドアロンアカウント）
  • IAMは、OpenID ConnectベースのウェブIDフェデレーションとSAML2.0ベースのフェデレーションの2パターンをサポートします。
  • ユーザー ID を AWS の外で管理している場合、AWS アカウントに IAM ユーザーを作成する代わりに、IAM ID プロバイダー(IdP)を利用します。
  • IdP を使用するには、IAM ID プロバイダーエンティティを作成して、AWS アカウントと IdP の間に信頼関係を確立します。IAM は、OpenID Connect または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートします。
• AWS IAM Identity Center（旧SSO）
  • オンプレとのSAML認証連携によるシングルサインオンとMFA認証が可能になります。
  • AWS Organizations サービスを設定し、[すべての機能] を有効化する必要があります。
  • IAM Identity CenterとオンプレのActiveDirectoryとの連携に AD Connector（またはAWS DirectoryService for Microsoft ActiveDirectory）が必要です。

  

参照

公式ドキュメント

一時的なセキュリティ認証情報を取得するAWS Security Token ServiceのAPIで、フェデレーションユーザーがAWSリソースにアクセスするために使用されます。
このAPIコールには、SAMLプロバイダのARN、IAMロールのARN、およびIdPが発行するSAMLアサーションが必要であり、これらの要素が正しく設定されていることで、AWSリソースへのアクセスが可能になります。

• SAML 2.0フェデレーション: 異なる組織間でユーザー認証情報を安全に交換するためのオープンスタンダードで、シングルサインオン（SSO）を実現し、オンプレミスの認証情報でAWSリソースにアクセスできるようにします。
• SAMLアサーション: IdPが生成する、ユーザーの身元と属性を含むXML文書で、サービスプロバイダ（この場合AWS）に対してユーザーを認証するために使用されます。
• IAMロールの信頼ポリシー: IAMロールを誰が引き受けることができるかを定義するポリシーで、フェデレーションの場合、SAMLプロバイダをプリンシパルとして指定します。

フリートマネージャーは SSMの機能の一つでAWSまたはオンプレミスで実行されているノードをリモートで管理する。AWS マネジメントコンソールからサーバーフリート全体の正常性とパフォーマンスステータスを表示する。個々のノードからデータを収集し、コンソールから一般的なトラブルシューティングと管理タスクを実行します。
リモートデスクトッププロトコル (RDP) を使用したWindowsインスタンスへの接続、フォルダとファイルのコンテンツの表示、Windowsレジストリの管理、オペレーティングシステムのユーザー管理などが可能です。

AWS Systems Managerは、ハイブリッド環境（オンプレミスとクラウド）全体でのインフラストラクチャ管理を可能にする強力なツールです。
パッチマネージャー機能を活用することで、パッチの適用状況を一元的に管理し、必要に応じて自動的にパッチを適用することができます。これにより、すべてのサーバーのセキュリティ状態を常に最新に保つことが可能になります。

EC2インスタンス、エッジデバイス、オンプレミスサーバー、仮想マシン (VM) で実行される Amazonのソフトウェアです。SSM Agentをインストールし、使用すると、Systems Managerでこれらのリソースを更新、管理、設定できるようになります（パッチの更新など）。
SSM Agentは、AWS クラウドで Systems Managerサービスからのリクエストを処理し、リクエストで指定されたとおりに実行します。SSM Agent は、Amazon Message Gateway Service (ssmmessages) を使用して、Systems Manager サービスにステータスと実行情報を返します。

AWS が提供する AI を利用したコンタクトセンター

• Contact Control Panel (CCP): Amazon Connectのエージェントインターフェースで、カスタマイズ可能な機能を提供し、エージェントの効率を向上させるツールです。
• UpdateContactAttributes API: Amazon Connectのコンタクト属性をリアルタイムで更新できるAPI呼び出しで、動的なコンタクト管理を可能にします。
• コンタクトフロー: 顧客とのインタラクションを設計・管理するための視覚的なワークフローツールで、高度なカスタマイズが可能です。
• Contact Lens: 自然言語処理を使用して顧客とのやり取りを分析し、インサイトを提供する高度な分析ツールです。
• Amazon Q in Contact: 生成 AI アシスタントで、顧客の質問に対するレスポンスやアクションをエージェントに提案することで、より迅速な問題解決と顧客満足度の向上を実現します。
  お客様とのリアルタイムの会話と関連する企業コンテンツを使用して、お客様により良いサポートを提供するためにエージェントが何を言うべきか、どのようなアクションを取るべきかを自動的に推奨します。Amazon Q を使用することで、エージェントは自然言語を使用して接続されたナレッジソース全体を検索し、生成されたレスポンス、推奨アクション、および詳細情報へのリンクを受け取ることもできます。

AWSのマルチチャネルマーケティングおよびユーザエンゲージメントサービスで、ターゲットを絞ったプッシュ通知やアンケート配信などのカスタマイズされたコミュニケーションを可能にします。また顧客セグメントに合わせたカスタマイズメッセージを送ることもできます。

一方Amazon SNSはシステム間の通知やリアルタイムのイベント通知に使われます。即時性が重要なメッセージングに適しています。

SNSとの違い

MQTTおよび MQTT over WebSocket Secure (WSS) プロトコルを使用してメッセージを発行およびサブスクライブするデバイスとクライアント、およびHTTPSプロトコルを使用してメッセージを発行するデバイスとクライアントをサポートします。すべてのプロトコルは IPv4とIPv6をサポートしています。

AWS IoT Greengrassは、AWSが提供するサービスの1つで、AWS の「IoT プラットフォーム」(AWS IoT) の機能をエッジ(現場)にオフロードする仕組みです。
IoTシステムでは、さまざまなデバイスからクラウドにデータを吸い上げ、AIでデータを分析して、その結果に基づいてデバイスを制御します。そういったIoTシステムをクラウドの環境で構築できるよう、AWSでは、AWS IoTというサービスをもともと提供していました。
AWS IoTの機能をエッジ環境でも使えるようにしたプラットフォームがGreengrassです。クラウドでできることの一部または全部をエッジ環境で実行することで、負荷分散を図ることができます。

Greengrass の導入によって、IoT システム構築に必要なクラウドの機能が現場にもたらされ、デバイスから収集したデータをクラウドを介さずに現場で処理する「エッジコンピューティング環境」を構築できるようになります。

AWS IoT Coreにおいて、個々のIoTデバイスを表現する論理的なエンティティで、デバイスの属性や状態を管理します。（証明書のプロビジョニンングなど）

STARTTLSとは、インターネットを暗号化する技術SSL/TLSを利用し暗号化通信に切り替えをおこなう仕組みのことで、通信経路を暗号化する技術です。

メールは、電子メールを送信する際にSMTPというプロトコルを使って配信します。
SMTPでは通信内容が暗号化されず平文のままメールを送信しますが、STARTTLSを活用することで、送信メールサーバから受信側のメールサーバまでの通信を暗号化します。そのため、通信の途中でのメール本文の盗み見や改ざん、ハッキングなどを防ぐことができます。

ただし、注意しなくてはならないのは「受信側のメールサーバがSTARTTLSに対応していること」が条件であることです。受信側がSTARTTLSに対応している場合に、暗号化したメール送信が実現できますが、そうでない場合は平文で送られます。

Amazon SESのSMTPインターフェースを使用するために必要な特別な認証情報で、IAM認証情報とは異なります。

Amazon Managed Streaming for Apache Kafkaの略で、AWSが提供する完全マネージド型のApache Kafkaサービスであり、高可用性と拡張性を備えたインフラストラクチャを容易に構築・運用できます。

Apache Flink は、高可用性で正確なストリーミングアプリケーションを構築するためのオープンソースのフレームワークおよびエンジンです。Kinesis Data Analyticsライブラリを使用して、以下のサービスと統合可能

• S3
• Amazon Managed Streaming for Apache Kafka (Amazon MSK)
• Amazon OpenSearch Service
• Amazon DynamoDB
• Amazon Kinesis Data Streams
• Amazon Kinesis Data Firehose
• Amazon CloudWatch
• AWS Glue Schema Registry

参照

OpenSearach互換の分散検索・分析エンジンを提供するフルマネージドサービスで、大規模なログ分析やリアルタイムアプリケーションモニタリングに適しています。（最大3PBのストレージをアタッチ）

OpenSearch ServiceとOpenSearch Dashboardsの組み合わせは、ほぼリアルタイムでの物件情報の可視化とダッシュボード作成を可能にします。これは迅速なデータ分析と意思決定支援を実現します。
さらにOpenSearch Serviceは半構造化JSONデータと柔軟なスキーマをサポートしています。これにより、様々な形式のログデータを効率的に処理し、分析することができます。

• OpenSearch: ログ分析、リアルタイムアプリケーションモニタリング、クリックストリーム分析などのユースケース向けの検索および分析を行うエンジンで、オープンソースです。（OpenSearch ドキュメント）

Amazon OpenSearch Serviceの機能で、大量の分析可能データをコスト効率的に保存できることを可能にします。頻繁にアクセスされないデータを低コストで保存しつつ、必要に応じて迅速にクエリできるストレージ層です。高性能なホットストレージと低コストなコールドストレージの中間に位置し、コストと性能のバランスを取るのに適しています。
ただし、すべてのデータノードをUltraWarmノードに置き換えると、操作が遅くなる可能性があります。インデックスを作成し、分析するためにはホットノード（データノード）が必要です。

ChefやPuppetを使って運用を自動化する。

• AWS OpsWorks for Chef Automate
• AWS OpsWorks for Puppet Enterprise
• AWS OpsWorks Stack

参照

AWSが提供するクラウドベースのサービスで、サードパーティのデータプロバイダーとデータ消費者間で安全かつ効率的にデータを交換・共有するためのプラットフォームです。

• AWS Data Exchangeデータシェア: AWS Data Exchange上で作成される共有リソースで、データプロバイダーが特定のデータセットへのアクセスを管理し、サブスクライバーとデータを共有するための仕組みを提供します。
• サブスクリプション検証: AWS Data Exchangeにおいて、データプロバイダーがデータ製品へのアクセスを許可する前に、サブスクライバーの身元や資格を確認するプロセスです。

どちらもデスクトップ環境を提供するサービス。
デスクトップ環境を提供したければ WorkSpaces を採用、特定のアプリケーションの実行環境があれば十分、あるいは、WorkSpaces だと自由度が高すぎるので、特定のアプリケーションしか実行させたくない場合は AppStream 2.0 を採用といった使い方になります。
Amazon AppStream 2.0はAWSが提供するフルマネージドなアプリケーションストリーミングサービスで、デスクトップアプリケーションをブラウザを通じて安全にストリーミングできる機能を提供します。またAppStream 2.0ユーザープールという認証メカニズムで、ユーザー管理と認証を簡素化し、既存のIDプロバイダとの統合も可能にします。

• サーバー: リモート認証ダイヤルインユーザーサービス (RADIUS) サーバーが、オンプレミスまたはクラウドでセットアップされている。
• トラフィック: RADIUS サーバーの IP または TCP ポート 1812 から Microsoft Active Directory または AD Connector の AWS Directory Service へのインバウンドトラフィックを許可している。
• 共有シークレット: RADIUS サーバーのユーザーが AWS Managed Microsoft AD または AD Connector に接続できるように、共有シークレットコードを設定している。

AWS Compute Optimizer を使用すると、使用状況データに基づいて機械学習によって

• EC2インスタンスタイプ
• EBSボリューム
• AWS FargateのECSサービス
• Lambda 関数
• RDS DBインスタンス

の5種類の AWS リソースのオーバープロビジョニングとアンダープロビジョニングを回避できます。

Amazon EC2 以外の個々のサービス用にスケーラブルなリソースを自動的にスケーリングするソリューションを必要とするデベロッパーやシステム管理者向けのウェブ AWS サービスです。

ex). Dynamo DB, Aurora replica, ECS, Elastic Cache Redis …

AWS SAM（Serverless Application Model）は、サーバーレスアプリケーションのデプロイメントを簡素化し、バージョン管理とコード更新がうまく行えるようにします。AWS CodeDeploy時点で、新旧バージョン間のトラフィック移行を段階的に行うことができます。

徐々に新しいバージョンへのトラフィックを移行することで、大きなエラーが生じた場合でもユーザーへの影響を最小限に抑えられます。これは、エラーの早期発見に役立ち、ロールバックの時間も短縮します。

AWS Elastic Beanstalkはフルマネージド型のサービスであり、アプリケーションを容易にデプロイ、運用、スケールできます。CI/CDパイプラインとの統合により、短時間での頻繁なリリースが可能になります。

さらに重要なのは、ステージング環境と本番環境のURLを入れ替えることで、新たな変更をユーザーにすぐに提供しつつ、問題が発生した場合にはすぐにロールバックすることが可能となります。Elastic Beanstalkが管理している複数の環境間でURLを交換することで、ダウンタイムや影響を最小限に抑えつつ、変更のロールバックまたは普及を容易に行うことができます。

GraphQLベースのフルマネージドサービスで、リアルタイムデータ同期やオフライン機能を提供し、WebSocketを利用したリアルタイム更新が可能です。

AWS CodeArtifactはパッケージマネージャツール(Maven、Gradle、npm、Yarn、Twine、pip、NuGetなど)でダウンロードするパッケージを管理するサービスです。

参照

AWS のインフラストラクチャとサービスをオンプレミスで実行するサービス。

参照

ERPとは、Enterprise Resource Planning（企業資源計画）の略で、日本語では、統合基幹業務システム、基幹システムといいます。また、ERPパッケージ、ERPシステム、業務統合パッケージなど様々な呼び方もされています。

ERPは、企業の「会計業務」「人事業務」「生産業務」「物流業務」「販売業務」などの基幹となる業務を統合し、効率化、情報の一元化を図るためのシステムとして誕生しました。

ERPは、次の5つに分類されたシステムを統合し、ユーザーへ提供します。これらのシステムは、多くの企業で共通して利用され、企業運営に欠かせないものとなっています。

• 会計管理システム
• 販売管理システム
• 在庫購買管理システム
• 生産管理システム
• 人事給与管理システム

IPアドレス範囲の集合を管理するためのもの