先日AWS SysOPs Administratorに合格しまして、その際感じた試験で重要なポイントを記事にできたらと思いました。
RDS Proxy
RDS Proxy は、Amazon Relational Database Service (RDS) 向けのマネージドサービスで、主に以下のような役割を果たします。
- データベース接続の管理と最適化
コネクションプール: RDS Proxyはコネクションプーリングを提供します。これにより、アプリケーションがデータベース接続を頻繁に開閉する際のオーバーヘッドが減少し、より効率的にデータベースにアクセスできるようになります。特に、サーバーレスアーキテクチャや短命な接続が多い環境（例: AWS Lambda）で有効です。
コネクションの再利用: 複数のクライアントからのリクエストを、少ないデータベース接続にマッピングし、リソースの使用効率を向上させます。これにより、RDSインスタンスが大量の同時接続を効率よく処理でき、パフォーマンスが向上します。
Auto Scaling
Auto Scalingの主な働き
動的スケーリング：
アプリケーションの負荷（例えば、CPU使用率やリクエスト数などのメトリクス）が変化した際に、リアルタイムでリソースを自動的に増減します。これにより、トラフィックが急増してもスムーズに対応でき、逆にトラフィックが少ない時はリソースを減らしてコストを削減できます。
スケールアップ（増加）：負荷が高まると新しいEC2インスタンスやコンテナを自動で追加します。
スケールダウン（減少）：負荷が低下すると不要なリソースを削減し、コストを抑えます。
スケジュールベースのスケーリング：
あらかじめ指定したスケジュールに従ってリソースを増減させる方法です。例えば、特定の時間帯や特定の日にトラフィックが増えることが予測できる場合、前もってスケールアップやスケールダウンのアクションを設定しておくことができます。これにより、リソースの確保を事前に行い、トラフィック急増時の遅延を防止できます。
スケールアップ・スケールダウン/スケールイン・スケールアウト
スケールイン・スケールアウト
スケールアップ・スケールダウン
スケールアウト: 複数のインスタンスを増やして処理能力を拡大。
スケールイン: 不要なインスタンスを削減してコストを節約。
スケールアップ: 既存のリソースの性能を強化。
スケールダウン: 既存のリソースの性能を削減してコスト削減。
状況に応じてこれらのスケーリング手法を組み合わせることで、効率的なインフラ管理が可能です。
フォールトレラント
フォールトトレラント (Fault Tolerant) とは、システムやコンピュータ、ネットワークなどのインフラが、一部の障害や故障が発生しても機能を維持し続ける能力を指します。簡単に言えば、システムが故障や障害に対して耐性があり、問題が発生しても全体が停止することなく動作を続けられるという概念です。
キャッシング
キャッシング (caching) は、よく使われるデータやコンテンツを一時的に高速なストレージ（メモリなど）に保存し、データの取得や提供をより高速に行うための技術です。キャッシングを利用することで、データベースや外部API、ファイルストレージなどのバックエンドリソースへのアクセス頻度を減らし、アプリケーションのパフォーマンス向上や、リソースの効率的な利用が可能になります。
バックトラック/ポイントインタイムリカバリ
Amazon RDS（Relational Database Service）では、データベースの復旧を支援するために、バックトラック（Backtrack）とポイントインタイムリカバリ（Point-in-Time Recovery）という2つの異なる機能があります。それぞれの機能について説明します。
- バックトラック (Backtrack)
バックトラックは、Amazon RDSのデータベースインスタンスに対する操作で、特定の時点までデータベースを「巻き戻す」機能です。これにより、間違ってデータを削除したり変更してしまった場合に、短期間の過去に簡単に戻すことができます。
主な特徴と使い方:
対象となるデータベースエンジン: バックトラックは、Amazon RDS for MySQLおよびAmazon RDS for MariaDBで使用できます。
期間の設定: バックトラックの有効期限は最大35日です。ユーザーは、インスタンスのバックトラックウィンドウを設定し、その期間内であれば任意の過去の時点に戻すことができます。
操作方法: バックトラックを有効にすると、データベースの変更履歴が保存され、特定の時間点に対する「リセット」を実行することができます。これにより、データの誤削除や誤操作を迅速に修正できます。
注意点: バックトラックは、操作を遡るために使用するものであり、全体的なバックアップやリカバリの代替ではありません。また、バックトラックのデータはストレージに保存されるため、追加のコストが発生する場合があります。
2. ポイントインタイムリカバリ (Point-in-Time Recovery)
ポイントインタイムリカバリは、Amazon RDSのデータベースを特定の時点に戻すための機能です。これにより、データベースが壊れた場合や、特定の時点にデータを復元したい場合に、データベースをその時点まで復元することができます。
-
バックトラック: 既存のデータベースインスタンスに対して操作を行うため、新しいクラスターやインスタンスの作成は不要です。短期間の間に行われた変更の履歴を使用して、データベースを指定した時点に戻す機能です。
-
ポイントインタイムリカバリ: データベースを特定の時点に復元するため、新しいクラスターやインスタンスが作成されます。元のインスタンスの状態に影響を与えることなく、新たに作成されたインスタンスで復元操作を行います。
パケットACL
パケットACL (Access Control List) とは、ネットワークにおけるアクセス制御のためのリストで、特定のネットワークトラフィックに対して許可または拒否のルールを設定するために使用されます。パケットACLは、主にネットワーク機器（ルーターやファイアウォールなど）でトラフィックの制御に利用され、セキュリティやネットワーク管理の役割を果たします。
主な特徴と機能
トラフィックの制御:
許可と拒否: ACLでは、ネットワークトラフィックに対して「許可」または「拒否」のルールを設定できます。これにより、特定のIPアドレスやポート番号に基づいて、通信の通過を制御します。
フィルタリング: パケットACLを使用して、特定のトラフィックのみを許可し、他のトラフィックを拒否することで、ネットワークのセキュリティを強化します。
ルールの適用順序:
ACLのルールは、通常、上から下へと順番に適用されます。最初に一致するルールが適用され、その後のルールは無視されることが一般的です。
トラフィックの種類:
インバウンドおよびアウトバウンド: ACLは、ネットワークインターフェースに対してインバウンド（受信）とアウトバウンド（送信）トラフィックの制御ができます。
レイヤー3およびレイヤー4: IPアドレス（レイヤー3）やポート番号（レイヤー4）に基づいてトラフィックを制御します。
適用先:
ルーターやスイッチ: ネットワークルーターやスイッチでACLを設定して、トラフィックの流れを制御します。
ファイアウォール: ファイアウォールでACLを使用して、外部からの不正アクセスを防ぐためのセキュリティルールを設定します。
AWSにおけるパケットACL
AWSでは、**Network ACL (NACL)**という形で、VPC内のネットワークトラフィックに対するアクセス制御を実施できます。
Network ACL (NACL):
VPC内での使用: VPC内でサブネット単位でトラフィックを制御します。
ルールの適用順序: NACLでは、ルールは番号順に適用され、最初に一致するルールがトラフィックに対して適用されます。
インバウンドおよびアウトバウンド: NACLは、サブネットへのインバウンドトラフィックとアウトバウンドトラフィックの両方を制御できます。
例
例えば、あるサーバーが特定のポート（例：HTTPポート80）を通じてのアクセスを許可し、その他のポートへのアクセスを拒否したい場合、以下のようなACLルールを設定できます。
許可ルール: ソースIPアドレス 0.0.0.0/0（全てのIP）からのポート80へのアクセスを許可。
拒否ルール: ソースIPアドレス 0.0.0.0/0（全てのIP）からの他のポートへのアクセスを拒否。
まとめ
パケットACL (Access Control List) は、ネットワークトラフィックに対してアクセス制御ルールを設定するためのリストで、許可または拒否のルールを基にトラフィックを制御します。
AWS Network ACL (NACL) では、VPC内のトラフィックをインバウンドおよびアウトバウンドで制御するために使用されます。
パケットACLはネットワークセキュリティを強化し、ネットワークの管理を効率的に行うための重要なツールです。
AWS Compute Optimizer
AWS Compute Optimizer は、AWSが提供するサービスで、Amazon EC2 インスタンスのパフォーマンスとコストの最適化を支援します。Compute Optimizerは、実行中のリソースの使用状況を分析し、推奨されるインスタンスタイプやサイズを提供することで、コスト効率を最大化し、パフォーマンスを向上させることを目的としています。
主な機能と特徴
インスタンスタイプの推奨
Compute Optimizerは、EC2インスタンスの使用状況データを分析し、より適切なインスタンスタイプやサイズを推奨します。これにより、現在のリソースが適切に活用されているかを確認し、無駄なコストを削減できます。
コスト効率の向上
リソースの使用状況に基づいて、コスト削減のための最適なインスタンスサイズを提案します。これにより、過剰なリソースを持っている場合や、逆に不足している場合に対応できます。
パフォーマンスの最適化
インスタンスのパフォーマンスに関するデータを基に、最適なインスタンスタイプやサイズを推奨し、アプリケーションのパフォーマンスを向上させる支援をします。
推奨レポート
Compute Optimizerは、定期的なレポートや推奨を提供し、インスタンスのパフォーマンスとコストの状況を把握できます。これにより、リソースの変更や調整を行う際の意思決定をサポートします。
サポートされるリソース
Compute Optimizerは、Amazon EC2インスタンスだけでなく、AWS Lambda関数やAuto Scalingグループのリソースの最適化もサポートしています。
使用方法
サービスの有効化
AWS Management ConsoleからCompute Optimizerサービスを有効化します。これにより、使用状況データの収集が開始され、分析結果が提供されます。
分析データの収集
Compute Optimizerは、過去のパフォーマンスデータやリソースの使用状況を分析し、推奨事項を生成します。データはAWS CloudWatchなどのメトリクスデータを基に収集されます。
推奨事項の確認
AWS Management ConsoleでCompute Optimizerのダッシュボードにアクセスし、推奨されたインスタンスタイプやサイズ、コスト削減の提案などを確認します。
リソースの調整
推奨されたインスタンスタイプやサイズに基づいて、EC2インスタンスやその他のリソースの変更を行います。これにより、パフォーマンスやコスト効率を最適化します。
まとめ
AWS Compute Optimizer は、Amazon EC2インスタンスなどのリソースのパフォーマンスとコストを最適化するためのツールです。
主な機能: インスタンスタイプの推奨、コスト効率の向上、パフォーマンスの最適化、推奨レポートの提供。
使用方法: サービスの有効化、データの収集、推奨事項の確認、リソースの調整。
Compute Optimizerを使用することで、AWSリソースの最適化を効率的に行い、コスト削減とパフォーマンス向上を実現することができます。
EFSマウントターゲット
Amazon Elastic File System (EFS) の マウントターゲット は、EFSファイルシステムに対するネットワーク接続のエンドポイントを提供するリソースです。EFSマウントターゲットは、VPC内の各サブネットに配置され、EC2インスタンスや他のAWSリソースがEFSファイルシステムにアクセスするためのエンドポイントとして機能します。
EFSマウントターゲットの概要
定義: マウントターゲットは、EFSファイルシステムに対してVPC内のサブネットに配置されるネットワークインターフェースです。これにより、EC2インスタンスや他のAWSリソースがファイルシステムに接続できるようになります。
機能: マウントターゲットは、ファイルシステムのデータを共有するためのネットワーク接続を提供し、EFSファイルシステムへのI/O要求を処理します。
１つのアベイラビリティゾーンに１つ設置できる。同一アベイラビリティゾーンのEC2インスタンスは、このマウントターゲットを使用する。
Trusted Adviser
AWS Trusted Advisor は、AWS 上でのアプリケーションやリソースの運用に関するベストプラクティスをチェックし、推奨事項を提供するサービスです。主にコスト最適化、パフォーマンス、セキュリティ、信頼性、運用効率といった観点で、ユーザーの AWS 環境を分析し、改善提案を行います。
NLB
AWS Network Load Balancer (NLB) と Application Load Balancer (ALB) は、それぞれ異なる用途に適したロードバランサーです。NLBが持つ静的IPアドレスとALBのトラフィック性能を比較する際のポイントを以下に示します。
Network Load Balancer (NLB)
静的IPアドレス: NLBは、リスナーに対して1つまたは複数の静的IPアドレスを提供することができます。これにより、NLBに対するクライアントからの接続先IPが固定され、IPアドレスの変更がないため、DNSのキャッシュやIPアドレスの変更による影響を避けられます。
性能:
スケーラビリティ: NLBは、レイヤー4（TCP/UDP）で動作し、非常に高いスループットと低レイテンシーを提供します。数百万のリクエスト/秒を処理できるスケーラビリティがあります。
トラフィックの取り扱い: NLBは、TCPおよびUDPトラフィックを効率的に処理し、高パフォーマンスなネットワークトラフィックの処理に適しています。ヘルスチェックやセッションのスティッキーセッション機能はサポートしていませんが、非常に高いスループットを提供します。
Application Load Balancer (ALB)
性能:
スケーラビリティ: ALBは、レイヤー7（HTTP/HTTPS）で動作し、アプリケーションレベルのリクエストに基づいてトラフィックをルーティングします。ALBも高いスケーラビリティを持ち、数百万のリクエスト/秒を処理できますが、NLBほどの低レイテンシーは提供しません。
トラフィックの取り扱い: ALBは、HTTP/HTTPSトラフィックを効率的に処理し、URLパスやホストベースのルーティング、リクエストのヘッダーに基づくルーティングなど、高度なルーティング機能を提供します。ALBは、リクエストのレベルでのパフォーマンスと管理機能が豊富です。
比較
スループットとレイテンシー:
NLBは、レイヤー4で動作し、非常に高いスループットと低レイテンシーを提供します。特に、ネットワークトラフィックや低レイテンシーが重要なシナリオに適しています。
ALBは、レイヤー7で動作し、より複雑なアプリケーションロジックに対応しますが、NLBほどの低レイテンシーは提供しない場合があります。ALBは、高度なルーティング機能が必要な場合に適しています。
静的IPアドレス:
NLBは、静的IPアドレスを提供するため、クライアントのネットワーク設定がシンプルになり、IPアドレスが固定されます。これは、IPアドレスの変更に依存するアプリケーションに対して便利です。
ALBは、静的IPアドレスを提供せず、DNS名を使用します。これにより、DNSのキャッシュやリダイレクトの影響を受けることがあります。
機能と管理:
NLBは、シンプルなネットワークレベルのトラフィック管理に特化しており、アプリケーションレベルの詳細なルーティング機能はありません。
ALBは、アプリケーションレベルのルーティング、ヘルスチェック、SSL/TLS終了、セッションスティッキーセッションなど、豊富な機能を提供します。
まとめ
Network Load Balancer (NLB) は、静的IPアドレスを持ち、非常に高いスループットと低レイテンシーを提供します。ネットワークレベルでのトラフィック処理が重要なシナリオに適しています。
Application Load Balancer (ALB) は、アプリケーションレベルの高度なルーティング機能を提供し、HTTP/HTTPSトラフィックの処理に適していますが、NLBほどの低レイテンシーは提供しません。
用途に応じて、どちらのロードバランサーが適切かを選択することが重要です。
InsufficientCapacityError
特定のアベイラビリティゾーンにおけるインスタンスの容量不足。
対応方法はすでに作成されたEC2インスタンスのインスタンスタイプを下げる。
または異なるアベイラビリティゾーンでEC2を起動する。
InstanceLimitExceeded
アカウントに設定されたEC2インスタンスの上限を超えた場合に発生するエラー。
対応方法はすでに作成されたEC2インスタンスのインスタンスタイプを下げる。
またはサービスクォーターの引き上げをAWSに申請する。
Auto Scalingターゲット追跡スケーリングポリシー
ターゲット値を超えないようにスケーリングする機能。
CloudWatchで設定可能。
CloudFront/TTL
CloudFront の TTL（Time to Live）とは、キャッシュされたオブジェクトがエッジロケーションに保持される時間を指定する設定です。TTL の値を設定することで、CloudFront がキャッシュに保持しているオブジェクトをどれだけの期間再利用するかを決定できます。
NAT Gatewayのプロトコル
AWSのNAT Gatewayは、インターネットや他のAWSサービスへのアウトバウンドトラフィックをサポートするために使用され、主に以下の2つのプロトコルをサポートしています：
TCP (Transmission Control Protocol):
NAT Gateway は、TCP プロトコルを使用するトラフィックをサポートします。TCP は、信頼性が高く、データ転送の順序やエラーチェックを提供するため、ウェブサイトの閲覧やデータベースの通信などに広く利用されています。
UDP (User Datagram Protocol):
NAT Gateway は、UDP プロトコルもサポートします。UDP は、TCP と異なり信頼性の保証がなく、データの再送や順序の維持を行いませんが、低遅延のアプリケーションには適しています。DNS ルックアップやストリーミングサービスなどでよく使用されます。
カスタマーゲートウェイリソース
カスタマーゲートウェイ（Customer Gateway）リソースは、AWSのVPC（Virtual Private Cloud）とオンプレミスのデータセンターや別のネットワークとの間でVPN接続を確立する際に使用するリソースです。カスタマーゲートウェイは、ユーザー側（オンプレミスや外部ネットワーク）のエッジデバイス（ルーターやファイアウォール）を表し、これによりAWS側と安全に接続を行うことができます。
AWS Organizations
AWS Organizationsは、複数のAWSアカウントを一元的に管理・運用するためのサービスです。組織内で異なるアカウントをまとめ、アクセス管理や課金、ポリシーの適用を効率化できる機能を提供します。
AWS Auroraとその他RDS仕様の違い
- データベースエンジン
Amazon Aurora:
Amazon Auroraは、MySQLおよびPostgreSQLと互換性のあるクラウド向けに最適化されたデータベースエンジンです。
Aurora MySQLとAurora PostgreSQLのバージョンがありますが、これらは完全なMySQLやPostgreSQLのリプレースではなく、クラウドに特化した高性能なバージョンです。
RDS標準エンジン:
RDSでは、以下のデータベースエンジンが利用可能です。
- MySQL
- PostgreSQL
- MariaDB
- Oracle Database
- SQL Server
- パフォーマンス
Aurora:
Auroraは、クラウドに最適化された設計により、通常のRDS MySQLやPostgreSQLの約5倍（MySQL互換）、**3倍（PostgreSQL互換）**のパフォーマンスを提供します。
Auroraのストレージは分散されており、データのコピーが複数のアベイラビリティゾーンにまたがって自動的に保存され、ストレージ層の自動スケーリングも行います。
他のRDSエンジン:
MySQLやPostgreSQLのRDSエンジンは、オンプレミス版と同じ機能を持つ標準的なデータベースエンジンであり、単一のインスタンスに依存することが多く、Auroraほどのパフォーマンスは期待できません。
3. 可用性と耐障害性
Aurora:
Auroraでは、データが自動的に6つのコピーに分散され、3つの異なるアベイラビリティゾーン（AZ）に保存されます。
ストレージ層は自己修復機能を持ち、1つのAZで障害が発生しても、他のAZから自動的にデータを復旧します。
Auroraのリーダーインスタンスとリードレプリカは、フェイルオーバー時間が非常に短く（30秒以内）、高い可用性を持ちます。
他のRDSエンジン:
他のRDSエンジンでは、マルチAZ配置を設定することで、データベースインスタンスのバックアップやフェイルオーバーを提供できます。ただし、Auroraほどの自動復旧機能や耐障害性には劣ります。
フェイルオーバー時間もAuroraに比べて長く、場合によっては1分以上かかることがあります。
プレイスメントグループ
AWSのプレイスメントグループ (Placement Group) とは、Amazon EC2インスタンスの配置戦略を制御するために使用される機能で、特定のニーズに応じてインスタンスを最適な方法で配置することができます。これにより、インスタンス間のネットワークパフォーマンスや可用性を向上させることができます。
プレイスメントグループには、次の3種類の戦略があります。
- クラスター配置 (Cluster Placement Group)
概要: インスタンスを物理的に近接したサーバー上に配置することで、低レイテンシーで高スループットのネットワーク接続を実現する配置方式です。
ユースケース: 高パフォーマンスコンピューティング (HPC) アプリケーションやビッグデータ処理など、インスタンス間のネットワーク遅延が非常に小さいことが求められるシナリオで使用されます。
メリット:
インスタンス間の通信において、非常に低いレイテンシーが実現。
インスタンス間のネットワークスループットが最大化される。
制約:
同じAZ（アベイラビリティゾーン）内にのみインスタンスを配置可能。
インスタンスの起動が失敗する場合もある（十分なリソースが利用できない場合）。 - パーティション配置 (Partition Placement Group)
概要: インスタンスを複数のパーティションに分けて配置し、各パーティションが異なる物理ハードウェア上で動作するようにする方式です。これにより、パーティション間で障害の影響を最小化することができます。
ユースケース: データベースや大規模な分散システム、特に耐障害性が求められる環境で利用されます。たとえば、Hadoopクラスタなどのビッグデータアプリケーションに適しています。
メリット:
物理ハードウェアの障害が他のパーティションに影響を与えないため、可用性が高まる。
高可用性を維持しながら、クラスタの配置によるパフォーマンスを確保できる。
制約:
パーティション数に制限がある（リージョンによって異なるが、通常は最大7つ）。 - 分散配置 (Spread Placement Group)
概要: 各インスタンスを異なる物理ハードウェア上に配置することで、インスタンス間の障害を分散させ、耐障害性を高める方式です。インスタンス間で同時に障害が発生するリスクを最小化します。
ユースケース: ミッションクリティカルなアプリケーションや、複数のインスタンスが同時に停止すると大きな影響を受けるシステムに適しています。
メリット:
各インスタンスが異なる物理ホスト上に配置されるため、1つのホストの障害が他のインスタンスに影響しない。
インスタンス間の耐障害性が非常に高い。
制約:
1つのAZにつき最大7インスタンスまでしか配置できないため、大規模なデプロイには不向き。
CloudWatch Logs Insight
Amazon CloudWatch Logs Insight は、Amazon CloudWatchの一部として提供されるログデータの分析ツールです。これを使うことで、Amazon CloudWatch Logsに保存されているログデータをクエリ言語を使用して効率的に検索・分析でき、システムのパフォーマンスや問題のトラブルシューティングを迅速に行うことができます。
AWS Macie
Amazon Macie は、AWS上のデータセキュリティとデータプライバシーを保護するためのサービスです。主に機械学習を活用して、機密データ（例：個人情報（PII）や金融データなど）を自動的に検出、分類、保護することができます。Amazon S3バケット内のデータを中心に分析を行い、データ漏洩や不適切なアクセスを防ぐためのツールを提供します。
Systems Managerのcron/Lambda定期実行
AWS Systems Manager と AWS Lambda を使った定期実行の方法には、さまざまなシナリオがあります。主に、AWSのサービスである EventBridge（旧CloudWatch Events） を使ったCronジョブの設定を通じて、定期的に実行することが可能です。
-
AWS Systems Manager の定期実行
AWS Systems Manager には、EC2インスタンスやオンプレミスのサーバーに対して Run Command や Automation のような運用タスクを定期的に実行できる機能があります。これを EventBridge を用いて定期的にトリガーすることで、自動的にジョブをスケジュールできます。 -
AWS Lambda の定期実行
AWS Lambdaは、コードをサーバーレスで実行するためのサービスで、AWSのリソースを定期的に操作する場合にも使用されます。EventBridgeを使って、Lambda関数をCronジョブのようにスケジュール実行することができます。
AWS Service Catalogの使い方
AWS Service Catalog は、組織が標準化されたITサービスのカタログを作成、管理、配布できるサービスです。これにより、組織は承認された製品（例：仮想マシン、サーバー、データベース、ソフトウェア）をユーザーに提供し、管理およびコスト制御をしやすくします。主にIT管理者やデベロッパーが利用し、企業や組織内で使用するAWSリソースを効率的に管理するために利用されます。
AWS Service Catalog の使い方を以下のステップに沿って説明します。これは、AWS マネジメントコンソールからの設定方法を基本としており、組織がリソースを効率的に管理するための手順です。
- AWS Service Catalog の準備
AWS マネジメントコンソールにサインインします。
Service Catalog のダッシュボードに移動します。 - ポートフォリオを作成する
ポートフォリオは、製品（プロビジョニング可能なリソース）の集合体です。まず、ポートフォリオを作成します。
手順:①
Service Catalog コンソール で、「ポートフォリオを作成」をクリックします。
ポートフォリオに名前を付けます（例: "Web開発ポートフォリオ"）。
「説明」にポートフォリオの用途や詳細な情報を入力します。
「提供者名」は管理者名やチーム名を入力します（例: "IT 管理チーム"）。
必要に応じてタグを追加します。タグを使用すると、リソースを後で追跡したり、管理しやすくなります。
作成 をクリックします。
これで、新しいポートフォリオが作成されました。
- 製品を作成する
製品は、プロビジョニング可能な AWS リソースのテンプレートです。CloudFormation テンプレートを使って作成します。
手順:②
ポートフォリオ内で、「製品を追加」または「製品を作成」をクリックします。
製品の詳細を入力します:
製品名: (例: "EC2 Webサーバー")
製品ID: 製品を識別するための一意のIDを入力します。
バージョン: この製品のバージョン（例: "v1.0"）。
説明: 製品の機能や用途を説明します。
製品を作成するには、CloudFormation テンプレート をアップロードします。CloudFormation テンプレートは、AWS リソース（例: EC2、S3、RDSなど）の設定を YAML または JSON で記述したファイルです。
作成 をクリックすると、製品がポートフォリオに追加されます。
4. 製品バージョンを管理する
製品にはバージョン管理が可能です。これは、製品に新しい機能や設定を追加する際に役立ちます。
手順:③
ポートフォリオ内で、管理したい製品を選択し、「バージョンを追加」をクリックします。
新しいバージョンのテンプレートをアップロードし、バージョン番号（例: "v1.1"）を入力します。
追加 をクリックすると、製品に新しいバージョンが適用されます。
5. アクセス権の設定
ポートフォリオを利用できるユーザーやグループのアクセス権を設定します。IAM ロールを使用して、特定のユーザーやグループに製品へのアクセスを付与します。
手順:④
ポートフォリオ画面で「アクセス権を付与」をクリックします。
IAM ユーザー、グループ、またはロール を選択して、アクセス権を付与します。
追加 をクリックして、アクセス権の設定を確定します。
これで、指定したユーザーやグループがポートフォリオ内の製品を使用できるようになります。
- 制約の設定
製品の利用条件や制限を設けるために、制約（Constraints）を設定します。これにより、ユーザーが製品をどのようにプロビジョニングできるかを制御します。
手順:⑤
ポートフォリオ内で、対象製品を選択し、「制約を追加」をクリックします。
制約の種類を選択します（例: 起動制約、タグ制約 など）。
起動制約: 製品をどのIAMロールを使用して起動するかを制御。
タグ制約: リソースに対してどのタグを付けるべきか、付けてはいけないかを制御。
制約を設定し、「追加」をクリックします。
7. ユーザーが製品をプロビジョニングする
ユーザーは指定されたポートフォリオ内から製品を選び、リソースをプロビジョニング（作成・起動）します。
手順:⑥
AWS マネジメントコンソール にログインし、「Service Catalog」にアクセスします。
自分がアクセス権を持つポートフォリオと製品を確認します。
必要な製品を選択し、「プロビジョニング」をクリックします。
製品のバージョンを選択し、必要なパラメータ（例: インスタンスタイプ、ストレージサイズなど）を入力します。
プロビジョニング をクリックすると、指定されたリソースが作成されます。
8. プロビジョニング済み製品の管理
ユーザーがプロビジョニングした製品（リソース）は、プロビジョニング済み製品として一覧で表示され、進捗やリソースの状態を確認したり、不要なものを削除（終了）することができます。
手順:⑦
Service Catalog のコンソールで「プロビジョニング済み製品」を選択します。
現在利用中のリソースの状態（アクティブ、削除済みなど）を確認できます。
必要に応じて製品を選び、「削除」をクリックして、リソースを終了します。
9. コスト管理とモニタリング
AWS Service Catalog では、リソースの利用状況をコスト面で管理するための仕組みが提供されています。タグを使用したコストの追跡や、CloudWatch を使ってモニタリングを行い、各製品がどれだけのリソースを消費しているか確認できます。
Cloudfrontのビューワープロトコルポリシー
CloudFrontのビューワープロトコルポリシー（Viewer Protocol Policy）は、Amazon CloudFront がエンドユーザー（ビューワー）と接続する際に使用するプロトコル（HTTPまたはHTTPS）を指定する設定です。このポリシーを設定することで、CloudFrontディストリビューションがどのプロトコルを使用してユーザーのリクエストを受け入れるかを制御できます。
CloudFrontは、ウェブサイトやアプリケーションのコンテンツ（画像、HTMLページ、CSSファイル、JavaScriptなど）をキャッシュして高速に配信するコンテンツ配信ネットワーク（CDN）で、この「ビューワープロトコルポリシー」は、CloudFrontがユーザーからのリクエストを処理する際のセキュリティレベルを決定します。
ビューワープロトコルポリシーのオプション
以下の3つのプロトコルポリシーが選択できます。
HTTPおよびHTTPS (HTTP and HTTPS):
エンドユーザーがHTTPまたはHTTPSのいずれかを使用してリクエストを送信できるようにします。
この設定では、CloudFrontはどちらのプロトコルでもリクエストを受け付けます。つまり、ユーザーがHTTPでアクセスしても、HTTPSでアクセスしてもコンテンツが提供されます。
利点: HTTPSをサポートしていないユーザーもアクセス可能。
デメリット: HTTPはセキュリティ的に脆弱で、暗号化されていないデータが送信される可能性があります。
リダイレクトHTTPからHTTPS (Redirect HTTP to HTTPS):
エンドユーザーがHTTPでリクエストを送信した場合、自動的にHTTPSにリダイレクトされます。
これにより、すべてのリクエストがHTTPSにより安全に処理されます。
利点: セキュリティが強化され、暗号化された通信が強制されます。
デメリット: HTTPSにリダイレクトするため、ユーザーに追加のリダイレクト時間がかかる場合がありますが、現代のブラウザではほとんど影響はありません。
HTTPSのみ (HTTPS Only):
CloudFrontはHTTPSリクエストのみを受け付け、HTTPリクエストを拒否します。ユーザーがHTTPでアクセスしようとすると、アクセスがブロックされます。
利点: セキュリティが最高レベルに達し、すべてのデータが暗号化されて送受信されます。
デメリット: HTTPSをサポートしていない古いブラウザやクライアントがアクセスできなくなる可能性があります。
ビューワープロトコルポリシーの使用例
例えば、eコマースサイトなどの機密情報を扱うウェブサイトでは、HTTPSによる通信の暗号化が必須です。このような場合、「リダイレクトHTTPからHTTPS」または「HTTPSのみ」のポリシーを設定することで、すべてのユーザーリクエストが安全に処理されます。
逆に、静的なウェブサイトや特定の環境では、HTTPおよびHTTPSの両方をサポートする場合もありますが、セキュリティ上のリスクを考慮して、HTTPSの使用が推奨されます。
CloudFrontのキャッシュヒット率
CloudFrontのキャッシュヒット率とは、Amazon CloudFrontがキャッシュに保存しているコンテンツに対してエンドユーザーのリクエストに応答できた割合を示す指標です。簡単に言うと、エンドユーザーがリクエストしたコンテンツがCloudFrontのエッジロケーションにすでにキャッシュされていて、それがキャッシュから直接提供された回数の割合です。キャッシュヒット率が高ければ高いほど、CloudFrontは効率的にコンテンツを配信できているということを意味します。
- キャッシュヒットとキャッシュミス
キャッシュヒット：ユーザーがCloudFront経由でリクエストしたコンテンツが、エッジサーバー（エッジロケーション）にキャッシュされている場合、リクエストに対する応答はエッジサーバーから提供されます。これを「キャッシュヒット」と呼びます。
キャッシュミス：逆に、ユーザーがリクエストしたコンテンツがエッジサーバーにキャッシュされていない場合、CloudFrontはオリジンサーバー（S3バケット、EC2インスタンス、API Gatewayなど）に問い合わせ、オリジンから直接コンテンツを取得します。これが「キャッシュミス」です。
- キャッシュヒット率の計算
キャッシュヒット率は、キャッシュされたリクエストの数（キャッシュヒット）を、全リクエストの数で割ったものです。
キャッシュヒット率（％） = (キャッシュヒット数 / 総リクエスト数) * 100
高いキャッシュヒット率：エッジロケーションで多くのリクエストがキャッシュから提供されていることを意味し、オリジンへのリクエストが少なくなります。
低いキャッシュヒット率：キャッシュされていないコンテンツへのリクエストが多いため、CloudFrontは頻繁にオリジンに問い合わせてコンテンツを取得しなければならないことを示します。
3. キャッシュヒット率を高めるメリット
パフォーマンスの向上：キャッシュからコンテンツを提供する場合、オリジンにリクエストを送る必要がないため、エンドユーザーに対する応答速度が速くなります。
コスト削減：オリジンサーバーに対するリクエストが減ることで、オリジンの負荷が軽減され、オリジンに対するトラフィックに伴うデータ転送料金も削減されます。
スケーラビリティ：より多くのコンテンツがエッジサーバーで提供されるため、オリジン側のリソースを節約できます。
4. キャッシュヒット率を向上させる方法
キャッシュヒット率を向上させるには、いくつかの工夫が必要です。
(1) キャッシュ可能なコンテンツの最適化
キャッシュ可能なコンテンツの特定：静的コンテンツ（画像、CSS、JavaScript、動画など）は長期間キャッシュするのが理想的です。
キャッシュヘッダーの設定：オリジンサーバーで適切なCache-ControlやExpiresヘッダーを設定し、コンテンツのキャッシュ期間（TTL: Time To Live）を指定します。長いTTLを設定すると、そのコンテンツがエッジロケーションに長くキャッシュされ、再度オリジンに問い合わせる回数が減ります。
(2) キャッシュキーの最適化
キャッシュキーは、CloudFrontがコンテンツをキャッシュするために使用する一意の識別子です。デフォルトでは、CloudFrontはURL、クエリ文字列、ヘッダー情報、Cookieなどを基にキャッシュキーを作成しますが、これを最適化することでキャッシュヒット率を向上できます。
不要なクエリ文字列やヘッダーの除外：不必要なクエリ文字列やヘッダーをキャッシュキーから除外すると、キャッシュヒット率が向上します。
キャッシュポリシーのカスタマイズ：特定のリクエストに対してどの部分をキャッシュキーとして使用するかを決定するために、キャッシュポリシーをカスタマイズします。
(3) オリジンシールドの有効化
CloudFrontには「オリジンシールド」という機能があり、キャッシュミスが発生した際に、最も近いエッジロケーションではなく、特定のリージョンのエッジロケーションにキャッシュを問い合わせるように設定できます。これにより、オリジンへの直接的なリクエスト数が減り、間接的にキャッシュヒット率が改善されます。
(4) ホットコンテンツの分析
頻繁にリクエストされるコンテンツ（ホットコンテンツ）を特定し、それらのキャッシュを優先的に長期間保持することで、キャッシュヒット率を上げることができます。
- キャッシュヒット率のモニタリング方法
CloudFrontのキャッシュヒット率は、AWSマネジメントコンソールやCloudWatchで簡単にモニタリングできます。
(1) AWSマネジメントコンソールでの確認
AWSマネジメントコンソールにログイン。
CloudFrontのディストリビューションを選択し、ダッシュボードにアクセス。
メトリクスやレポートの「Cache Hit Ratio（キャッシュヒット率）」セクションで、ヒット率の推移を確認できます。
(2) CloudWatchでのモニタリング
CloudFrontは、Amazon CloudWatchと統合しており、キャッシュヒットやキャッシュミスなどのメトリクスを監視できます。
- CacheHitCount: キャッシュヒット数
- CacheMissCount: キャッシュミス数
- CacheHitRate: キャッシュヒット率（パーセンテージ）
CloudFrontのレスポンスヘッダーポリシー
CloudFrontのレスポンスヘッダーポリシーは、Amazon CloudFrontがエンドユーザー（ビューワー）に返すレスポンスに含めるHTTPヘッダーを制御するための設定機能です。これにより、セキュリティ強化、キャッシュ制御、コンテンツタイプの指定などのためにカスタマイズされたHTTPレスポンスヘッダーをエンドユーザーに返すことができます。
従来、これらのヘッダーはオリジンサーバーで設定する必要がありましたが、レスポンスヘッダーポリシーを使うことで、CloudFrontがヘッダーを直接追加・変更できるため、オリジンの負荷を軽減しつつ、より柔軟なレスポンスヘッダーの管理が可能になります。
- レスポンスヘッダーポリシーで制御できるヘッダーの種類
CloudFrontのレスポンスヘッダーポリシーでは、主に以下の種類のHTTPレスポンスヘッダーを管理できます。
(1) セキュリティヘッダー
セキュリティ強化のために、以下のようなHTTPセキュリティヘッダーを追加できます。
Strict-Transport-Security (HSTS): HTTPS経由でのみサイトにアクセスさせるためのヘッダー。これにより、エンドユーザーのブラウザは指定された期間、HTTPからHTTPSへのアクセスを強制されます。
Content-Security-Policy (CSP): ブラウザが許可されるコンテンツの種類（スクリプト、画像、スタイルシートなど）を指定し、クロスサイトスクリプティング（XSS）攻撃を防ぎます。
X-Frame-Options: サイトがiframeに埋め込まれることを制御し、クリックジャッキング攻撃を防止します。
X-Content-Type-Options: ブラウザに対し、コンテンツのMIMEタイプを検証する際に厳密に設定通りに処理させるヘッダー。誤ったMIMEタイプに基づく攻撃を防ぎます。
(2) キャッシュ制御ヘッダー
コンテンツのキャッシュポリシーを指定するために使用されます。これにより、エッジサーバーやブラウザのキャッシュ動作を管理します。
Cache-Control: コンテンツをキャッシュするかどうか、キャッシュ期間、プライベートキャッシュ（ユーザーごと）かパブリックキャッシュ（全体に対して）かなどを制御します。
Expires: コンテンツが期限切れとなる日時を指定し、それ以降のリクエストに対しては再度オリジンから取得されるようにします。
(3) カスタムヘッダー
レスポンスにカスタムヘッダーを追加することで、特定のアプリケーション要件を満たすために独自のメタ情報をエンドユーザーに提供することができます。
- レスポンスヘッダーポリシーの利用方法
レスポンスヘッダーポリシーを使うことで、CloudFrontがキャッシュからコンテンツを提供する際や、オリジンサーバーからのレスポンスをエンドユーザーに返す際に、自動的に適切なレスポンスヘッダーが追加されるようになります。以下の手順で設定できます。
(1) AWS Management Consoleでレスポンスヘッダーポリシーを作成・適用する手順
AWS Management Consoleにログインし、CloudFrontのサービスに移動します。
左側のナビゲーションメニューから「Policies」（ポリシー）を選択し、「Response headers policies」（レスポンスヘッダーポリシー）をクリックします。
「Create response headers policy」（レスポンスヘッダーポリシーを作成）を選択します。
ポリシー名と説明を入力し、追加または変更したいヘッダーを選択・設定します。セキュリティ、キャッシュ、カスタムヘッダーなどを自由に追加できます。
作成したポリシーを保存します。
(2) CloudFrontディストリビューションにポリシーを適用
CloudFrontのディストリビューションの「Behaviors」（ビヘイビア）セクションに移動します。
適用したいビヘイビアを選択し、「Edit」（編集）をクリックします。
「Response headers policy」の項目で、作成したレスポンスヘッダーポリシーを選択します。
変更を保存し、CloudFrontの設定を更新します。
3. レスポンスヘッダーポリシーのユースケース
CloudFrontのレスポンスヘッダーポリシーは、以下のようなユースケースで特に有効です。
(1) セキュリティの強化
HSTS（Strict-Transport-Security）ヘッダーを使って、ユーザーが必ずHTTPS経由で接続するように強制できます。
Content-Security-Policyを使って、クロスサイトスクリプティング攻撃やデータインジェクションを防ぐことができます。
(2) ブラウザキャッシュの制御
Cache-Control ヘッダーを使って、エンドユーザーのブラウザにどのようにキャッシュしてもらうかを制御できます。静的なコンテンツであれば、長めのキャッシュを設定することで、ユーザー体験を向上させ、オリジンへの負荷を減らします。
(3) クリックジャッキング対策
X-Frame-Options ヘッダーを設定して、悪意のあるサイトがiframeを使用して、ユーザーに対して不正な操作を行う「クリックジャッキング」攻撃を防ぐことができます。
(4) パフォーマンス最適化
必要なHTTPヘッダーを適切に制御することで、ブラウザキャッシュやエッジキャッシュを効率的に利用でき、レスポンス時間が改善され、パフォーマンスが向上します。
(5) カスタムヘッダーの追加
独自のカスタムヘッダーを追加することで、特定のクライアントやブラウザに対してカスタマイズされたレスポンスを提供したり、アプリケーションに必要なメタ情報を送信することができます。
4. 事前定義済みのレスポンスヘッダーポリシー
CloudFrontは、よく使われるヘッダー設定に基づいた事前定義済みのレスポンスヘッダーポリシーを提供しています。これにより、ユーザーは一般的な設定を簡単に利用できます。
SecurityHeadersPolicy: 各種セキュリティヘッダー（HSTS、CSP、X-Frame-Optionsなど）が含まれているポリシー。
CachingOptimized: キャッシュ最適化のためのヘッダー（Cache-Control、Expiresなど）が設定されたポリシー。
EBS高速スナップショット
EBS高速スナップショット（Fast Snapshot Restore, FSR） は、Amazon Elastic Block Store（EBS）のスナップショットをより速く、効率的に復元できる機能です。この機能を使うと、EBSスナップショットから新しいEBSボリュームを即座に高パフォーマンスで作成・アタッチでき、初期化遅延を大幅に削減できます。
AWS Config
AWS Config は、AWS リソースの設定変更を追跡し、コンプライアンスを監視するためのツールです。AWS Config を使うことで、リソースの構成履歴を保存・追跡し、設定変更やポリシー違反が発生した際に迅速に対応できます。
主な手順:
AWS Config の設定とリソースの監視を開始する。
設定履歴を確認し、リソースの構成変更を追跡する。
ルールを設定して、リソースがコンプライアンスに準拠しているか確認する。
通知機能を設定し、重要なイベントを監視する。
これによって、セキュリティやコンプライアンスの要件を満たしつつ、AWS リソースを効率的に管理することが可能になります。
AWS Security Hub
AWS Security Hub は、AWS 内でのセキュリティベストプラクティスの適用状況を可視化し、AWS環境全体のセキュリティコンプライアンスを監視・管理できるサービスです。複数のセキュリティサービスやサードパーティツールからのフィードを統合して、セキュリティインシデントを一元管理します。
AWS Security Hub の使い方
- AWS Security Hub の有効化
まず、AWS Security Hub を有効化する必要があります。
AWS マネジメントコンソールにログイン:
AWS コンソールにログインします。
Security Hub のサービスに移動:
サービスリストから Security Hub を検索して選択します。
Security Hub の有効化:
Security Hub の最初の画面で「Security Hub を有効化」ボタンをクリックします。
Security Hub を初めて有効化する際、デフォルトでいくつかのセキュリティ標準が適用されます（例: AWS Foundational Security Best Practices や CIS AWS Foundations Benchmark）。これらの標準に基づいて環境をモニタリングすることができます。
2. セキュリティ標準の設定
AWS Security Hub は、いくつかのセキュリティベンチマークに基づいたルールセットで環境のセキュリティ状態を評価します。
主なセキュリティ標準:
AWS Foundational Security Best Practices: AWS のベストプラクティスに基づいたチェック項目を提供します。
CIS AWS Foundations Benchmark: Center for Internet Security (CIS) による AWS のセキュリティガイドラインに基づいた標準です。
セキュリティ標準を設定・カスタマイズする手順:
Security Hub のメインダッシュボードで「セキュリティ標準」タブを開きます。
有効にする標準のリストから、評価したいセキュリティ標準を選択します。デフォルトで「AWS Foundational Security Best Practices」や「CIS AWS Foundations Benchmark」が有効になっている場合があります。
他のセキュリティ標準を有効化する場合は、「有効化」ボタンをクリックします。
有効化すると、Security Hub は環境をスキャンし、これらの標準に基づいた推奨事項を生成します。
3. 推奨事項の確認
Security Hub は、セキュリティ標準に基づいてリソースの状態を評価し、改善のための推奨事項を提供します。
ダッシュボードを確認:
Security Hub のホーム画面には、環境全体のセキュリティ状態がグラフや数値で表示されます。セキュリティ標準ごとのコンプライアンススコアを確認でき、リソースが推奨事項に準拠しているかどうかを把握できます。
推奨事項を確認する:
左側メニューから「推奨事項」を選択します。
Security Hub による診断結果（Findings）が表示され、各リソースについての推奨事項が確認できます。
推奨事項には、「リソースがパブリックアクセスを許可している」「S3 バケットが暗号化されていない」など、具体的なセキュリティリスクが含まれます。
各推奨事項をクリックすると、詳細が表示され、対応策や推奨されるアクションが確認できます。
優先度付け:
推奨事項には、それぞれ重大度（Critical, High, Medium, Low）が付与されています。
重大度が高いものから対応を進めることが推奨されます。
4. セキュリティの統合
AWS Security Hub は、他の AWS セキュリティサービス（GuardDuty、Amazon Macie、Inspector）やサードパーティのセキュリティツールと連携できます。これにより、異なるサービスやツールからのセキュリティフィードを一元的に管理できます。
例: AWS GuardDuty との連携
GuardDuty の有効化:
AWS コンソールで GuardDuty を有効化していない場合、まず GuardDuty を有効にします（Security Hub ダッシュボードからもリンクがあります）。
Security Hub にフィードを統合:
GuardDuty で検出されたセキュリティインシデント（例えば、不審な EC2 インスタンスの動作や異常なトラフィック）が Security Hub に統合されます。
Security Hub の推奨事項やインシデント管理の一部として GuardDuty のアラートが表示され、これを基にインシデント対応を行うことができます。
5. セキュリティインシデントの対応
AWS Security Hub は、検出した問題に対して適切な対応を行うための情報を提供します。
推奨事項を確認:
セキュリティ標準に準拠していないリソースが特定されたら、各推奨事項をクリックし、詳細な推奨アクションを確認します。たとえば、S3 バケットの公開アクセスを制限する、EC2 インスタンスのセキュリティグループを修正するなどの具体的な手順が表示されます。
対応アクションの実施:
推奨事項に基づいて、必要な修正を AWS マネジメントコンソールや AWS CLI などを使って実行します。
例えば、未暗号化の S3 バケットが検出された場合、そのバケットにサーバーサイド暗号化を設定します。
自動対応の設定（オプション）:
AWS Security Hub は、AWS Lambda などを使って自動対応を設定することも可能です。異常が検出された場合に、自動で修正アクションを実行するように設定することで、即座に問題を解決することができます。
6. 組織全体での Security Hub 管理
AWS Organizations を使用している場合、複数アカウントにまたがる AWS 環境全体のセキュリティ状態を一元管理できます。
マスターアカウントを使用:
AWS Organizations のマスターアカウントを使用して、全アカウントに対して Security Hub を有効化し、一括で監視できます。
メンバーアカウントの設定:
各 AWS アカウントはメンバーアカウントとして登録され、Security Hub のデータをマスターアカウントから一元的に確認できます。
AWS KMS
AWS Key Management Service (KMS) は、データの暗号化と復号化を安全に管理するためのサービスです。KMS は、鍵の作成、管理、使用を行い、AWS 内の多くのサービスと統合されており、機密データの保護に役立ちます。
以下では、AWS KMS の基本的な使い方について説明します。
AWS KMS の使い方
- KMS キーの作成
まず、暗号化に使う鍵（キー）を作成する必要があります。AWS KMS では主に 2 種類のキーが利用できます。
顧客管理キー (CMK): ユーザーが作成・管理する鍵。
AWS 管理キー: AWS サービスが自動的に管理する鍵。
通常は、カスタマイズ性が高い顧客管理キー (CMK) を使用します。
キーの作成手順:
AWS マネジメントコンソールにログインし、「KMS」を検索して選択します。
「キーを作成」ボタンをクリックします。
キータイプの選択:
対称暗号鍵: 一般的な暗号化と復号化に使う鍵。
非対称暗号鍵: 公開鍵と秘密鍵を使った暗号化（RSA 鍵など）。
多くのケースでは、対称暗号鍵を選択します。
権限の設定:
キーポリシーを設定し、どのユーザーやサービスがこのキーを使用できるかを指定します。
キーの作成者にすべての権限を付与するか、特定の AWS IAM ロールやユーザーにアクセス権を付与するか選択します。
キーのラベルと説明を設定し、必要に応じてタグを追加します。
キーの確認と作成:
設定を確認して「キーを作成」ボタンをクリックすると、新しい顧客管理キー (CMK) が作成されます。
2. KMS キーを使用した暗号化
AWS KMS で作成したキーを使用して、データの暗号化と復号化ができます。KMS を利用した暗号化方法は、直接データを暗号化する場合や、他の AWS サービスと統合して自動的に暗号化する場合があります。
例 1: KMS API を使用してデータを暗号化
KMS の API を使用してデータを暗号化する方法です。
AWS SDK か AWS CLI を使用して、データを KMS キーで暗号化できます。
CLI での暗号化:
aws kms encrypt \
--key-id <キーのARN> \
--plaintext fileb://<暗号化したいファイルのパス> \
--output text \
--query CiphertextBlob \
--region <リージョン名> \
--profile <プロファイル名> > encrypted_file.txt
このコマンドは、ファイルを KMS に渡し、暗号化されたバイナリデータ（Base64 形式）を出力します。
例 2: AWS サービスとの統合による暗号化
多くの AWS サービス（S3, EBS, RDS など）は、KMS と統合されており、これらのサービスに保存されたデータを簡単に暗号化できます。
Amazon S3 のサーバーサイド暗号化:
S3 バケットに保存するデータを KMS を使って自動的に暗号化する設定が可能です。
S3 バケットのプロパティ画面で「デフォルトの暗号化」を選択し、「AWS KMS キーを使用」を選択して、使用する CMK を指定します。
Amazon EBS の暗号化:
新しく作成する EBS ボリュームやスナップショットを KMS キーで暗号化する設定ができます。
EBS ボリューム作成画面で「暗号化」オプションを有効にし、KMS キーを選択します。
Amazon RDS の暗号化:
RDS インスタンスを作成する際に、KMS キーを使用してデータを暗号化できます。
RDS インスタンス作成画面で、「暗号化」オプションを有効にし、KMS キーを選択します。
3. KMS キーを使用した復号化
暗号化したデータを復号化するには、KMS キーを使用して復号化操作を行います。以下は AWS CLI での復号化の例です。
aws kms decrypt \
--ciphertext-blob fileb://<暗号化されたファイルのパス> \
--output text \
--query Plaintext \
--region <リージョン名> \
--profile <プロファイル名> > decrypted_file.txt
これで、元のデータが復号化されて復元されます。
- KMS キーの管理
AWS KMS では、作成したキーの管理が重要です。不要になったキーを削除する、またはアクセス権限を更新する必要がある場合があります。
キーの無効化と削除:
キーの無効化: キーを削除する代わりに、一時的に無効化できます。無効化されたキーは暗号化・復号化に使用できなくなりますが、後で再度有効化することができます。
キーの削除: 必要がなくなったキーを削除する場合は、削除保留期間（最大 30 日間）を設定できます。この期間中に削除をキャンセルすることが可能です。
削除手順:
KMS コンソールで該当のキーを選択し、「削除」をクリックします。
保留期間を設定し、「削除スケジュールを設定」します。
キーポリシーの管理:
KMS キーの使用や管理権限は、キーポリシーによって制御されます。
キーポリシーは、JSON フォーマットで書かれたポリシー文書です。必要に応じて、ポリシーを更新し、アクセス権限を調整します。
キーローテーション:
KMS は自動的なキーのローテーション機能をサポートしています。
1 年ごとに新しいバージョンのキーを作成し、古いバージョンのキーも引き続きデータの復号化に使用可能です。
キーの自動ローテーションを有効化するには、KMS コンソールから該当するキーの「自動ローテーション」オプションを有効にします。
5. ログと監査
KMS は、重要なセキュリティ機能であるため、監査やログの取得が重要です。
AWS CloudTrail と統合:
KMS のすべての操作（暗号化・復号化、キーの作成、削除など）は、CloudTrail に記録されます。CloudTrail を使って、誰がいつどのような操作を行ったかを監視できます。
これにより、KMS を使用したデータアクセスやキー管理の操作を追跡することが可能です。
AWS Control Tower
AWS Control Towerは、複数のAWSアカウントや組織全体を管理し、ガバナンスやセキュリティを強化するための管理ツールです。Control Towerを使用することで、複数のアカウントを簡単に作成・管理し、セキュリティベストプラクティスや運用上のポリシーを一貫して適用できます。
以下では、AWS Control Towerの基本的な使い方について説明します。
AWS Control Towerの主な機能
Landing Zoneのセットアップ:
マルチアカウント環境を管理するための初期設定を提供。Landing Zoneはベストプラクティスに基づいて設計された環境です。
アカウントの作成と管理:
オーガニゼーションユニット（OU）ごとに複数のアカウントを作成。
ガードレール:
セキュリティやコンプライアンスに基づくルールを自動的に適用。
AWS Organizationsとの統合:
複数のAWSアカウントの管理を一元化。
AWS Control Towerの使い方
- Landing Zoneのセットアップ
まず、Control Towerを有効化するために「Landing Zone」を設定します。Landing Zoneは、セキュリティやガバナンスを維持しながら、複数のAWSアカウントを統合管理するための基盤です。
手順:
AWS Management Console にログインし、「Control Tower」を検索して選択します。
「Set up Landing Zone」ボタンをクリックしてセットアップを開始します。
リージョンの選択: AWS Control Towerがサポートしているリージョンを選択します。
Account Factory の設定:
Control Towerが複数のアカウントを作成・管理するために使用する、アカウント管理機能です。
マネジメントアカウント（旧称：ルートアカウント）とログアーカイブアカウント、および監査アカウントが自動的に作成されます。
ベースラインのセキュリティ設定:
AWS Control Towerが提供するベストプラクティスに基づいたセキュリティ設定を選択できます。
ガードレールの適用:
AWS Control Towerでは、あらかじめ用意された**ガードレール（Guardrails）**を適用できます。これらはセキュリティポリシーやコンプライアンス要件に基づいたルールで、アカウント全体に自動的に適用されます。
ガードレールには、次の 2 種類があります:
必須ガードレール: すべてのアカウントに強制的に適用される。
オプションガードレール: 必要に応じて選択して適用可能。
2. アカウントの作成と管理
Landing Zoneをセットアップした後、AWS Control Towerから新しいアカウントを作成し、AWS Organizationsを通じてこれらのアカウントを管理します。
手順:
Account Factory にアクセス。
AWS Control TowerのAccount Factory機能を使用して新しいアカウントを作成できます。
アカウント作成の設定:
各アカウントは指定された「オーガニゼーションユニット（OU）」内で作成されます。OUは、部門やプロジェクトごとにアカウントを整理するためのものです。
ガードレールの適用:
新しいアカウントには、自動的にControl Towerで設定されたガードレールが適用されます。
3. ガードレール（Guardrails）の適用と管理
ガードレールは、セキュリティとコンプライアンスを維持するための重要なルールセットです。これにより、アカウントの設定や使用がAWSのベストプラクティスに従って行われることが保証されます。
ガードレールの管理:
Control Towerのコンソールから、「ガードレール」セクションに移動します。
既存のガードレールを有効または無効にしたり、新しいガードレールを追加できます。
ガードレールの適用状況や違反状態は、ダッシュボードでモニタリングできます。
4. ダッシュボードでのモニタリング
AWS Control Towerは、ダッシュボードを提供し、アカウントやガードレールの状況を一目で確認できるようにします。
アカウントのステータス: 各アカウントの状態（例：準拠、非準拠）をリアルタイムで確認できます。
ガードレールの違反レポート: ガードレール違反が発生した場合、その詳細情報を確認し、必要な対策を講じることができます。
S3マルチパートアップロード
S3のマルチパートアップロード（Multipart Upload）とは、Amazon S3（Simple Storage Service）に大きなファイルを効率的にアップロードするための機能です。大容量のファイルを小さな部分（パーツ）に分割して並列にアップロードし、アップロードの効率化や信頼性を向上させる仕組みです。
この機能により、特に大容量ファイルを扱う際に、速度や安定性が大きく改善され、失敗した場合の再試行が簡単になります。
マルチパートアップロードの主な特徴
並列処理: ファイルを複数の「パーツ」に分割し、各パーツを並行してアップロードすることができるため、アップロード時間が短縮されます。
信頼性の向上: 各パーツが独立してアップロードされるため、ネットワークの問題などで一部が失敗しても、失敗したパーツだけを再アップロードすればよいです。全体をやり直す必要がありません。
再開可能: アップロードが途中で中断した場合でも、途中から再開することが可能です。
大容量ファイル対応: 特に大容量ファイル（5GB以上）のアップロードに最適で、5GB以上のファイルはマルチパートアップロードを使用することが推奨されます。ファイルの最大サイズは5TBです。
マルチパートアップロードの流れ
アップロードの開始: アップロードしたいファイルのマルチパートアップロードリクエストをS3に送信します。これにより、S3はアップロードIDを返します。このアップロードIDを使用して、ファイルのパーツをS3に送信していきます。
パーツのアップロード:
ファイルを複数のパーツ（最大10,000パーツ）に分割し、それぞれのパーツを並行してアップロードします。
各パーツは最小でも5MBのサイズが必要です（ただし、最後のパーツは5MB未満でも可能）。
アップロードの完了: すべてのパーツがアップロードされた後、Complete Multipart Upload リクエストを送信し、S3に対してアップロードの完了を通知します。S3はパーツを統合し、1つのオブジェクトとしてストレージに保存します。
中断・再開: アップロードが途中で中断した場合、すでにアップロードされたパーツはS3に保存されており、残りのパーツのみを再開できます。
キャンセル（オプション）: アップロードをキャンセルする場合はAbort Multipart Uploadリクエストを送信し、S3はすでにアップロードされたパーツを削除します。
マルチパートアップロードを利用するメリット
大容量ファイルの効率的なアップロード: 特に大容量ファイル（数GB〜数TB）を扱う場合、ネットワークの問題で1回の大きなリクエストが失敗するリスクがあるため、マルチパートアップロードによるパーツごとのアップロードが効率的です。
再アップロードの軽減: アップロード中にエラーが発生しても、失敗したパーツのみ再アップロードすればよいので、帯域の無駄を抑えます。
高速アップロード: パーツを並行してアップロードすることで、複数のネットワーク接続を活用し、高速なアップロードが可能になります。
Route53インバウンドリゾルバーエンドポイント
なんだか強そうな名前ですね。
#### Elastic Beanstalkの展開ポリシー
-
All at Once
すべてのインスタンスを同時に更新する。 -
Immutable
新しいサーバーグループを作成し、新しいバージョンをデプロイする。
フルキャパシティを維持。 -
Rebuild
アプリケーションと関連するリソース完全位削除し、再度結成する。 -
Rolling
インスタンスを少しずつ更新する。 -
Rolling with additional batch
追加のインスタンスを使用してローリング更新を行う。
フルキャパシティを維持。
CloudWatch Syntheticsカナリア
CloudWatch Synthetics カナリア (Canary) は、Amazon CloudWatch の機能の一部で、ユーザーがエンドポイントや API を継続的にモニタリングするためのツールです。名前の通り、"カナリア" はシステムの健全性を確認するために定期的に実行されるシミュレーションテスト (synthetic monitoring) を指します。
主な特徴は以下の通りです:
APIやウェブサイトのモニタリング: Canaries は、ウェブサイト、API、RESTエンドポイント、またはカスタムアプリケーションの動作を定期的にテストし、可用性やパフォーマンスを監視します。
問題の検出: Canaries は、HTTP ステータスコードの異常、レスポンス時間の増加、エンドポイントのエラーなど、サービスの問題を早期に検出するのに役立ちます。
ユーザーエクスペリエンスの監視: 実際のユーザーがウェブサイトやアプリケーションを使用した場合と同じように、Canaries を使用して定期的にページロードやフォーム送信などのシナリオをシミュレートできます。
カスタムスクリプト: Canaries は、カスタム Node.js スクリプトを使って、詳細な検証や複雑な操作を自動化できます。
CloudWatchと統合: 実行結果は CloudWatch メトリクスに直接送られ、アラームを設定して異常をすぐに通知できます。また、ログは CloudWatch Logs に保存され、分析やトラブルシューティングに使用可能です。