お疲れ様です。AWS 事業本部の平根です。 AWS 認定トレーニング「Advanced Architecting on AWS」を受講してきたので内容のご紹介や感想をお伝えしたいと思います。
AWS トレーニングとは
AWS トレーニングとは、AWS の利用方法の知識とスキルを身に付けるための公式教育プログラムです。
クラスメソッドのメンバーズプレミアムサービスにご加入いただいているお客様の場合は、
特別割引価格で受講いただけます!
提供トレーニングの詳細やお申込みは以下 URL をご参照ください。
今回は、トレーニングの中でも「Advanced Architecting on AWS」を受講しました。
トレーニングの概要
「Advanced Architecting on AWS」では、大規模な環境における以下のようなソリューションについて学びます。
- 複数 AWS アカウントの管理
- 複数ネットワークの接続
- アクセス制御や悪意のある攻撃からの保護
- アプリケーションやインフラストラクチャの効率的な構築
- 大量データの管理や保護、効率的なデータの活用
ハンズオンでは、上記に関連する AWS サービスの設定を体験できます。
私がトレーニングを受講した目的は以下の 2 点です
- 普段、大規模環境向けの設定に関わることがないため、トレーニングを通して知見を身につけたい
- AWS Certified Solutions Architect - Professional（SAP）認定を取得したい
以降、トレーニング内容のレポートになります。
トレーニングの内容
モジュール（講義）
Advanced Architecting on AWS は以下のモジュールで構成されています。
分量が非常に多いため、今回受講したトレーニングではモジュール 12 が省略されています。
また、学習するモジュールの順番が一部カスタマイズされていました。
- モジュール 1: アーキテクチャの確認
- モジュール 2: 単一アカウントから複数アカウントへ
- モジュール 3: ハイブリッド接続
- モジュール 4: 専用インフラストラクチャ
- モジュール 5: ネットワークを接続する
- モジュール 6: コンテナ
- モジュール 7: 継続的インテグレーション/継続的デリバリー (CI/CD)
- モジュール 8: 高可用性と DDoS
- モジュール 9: データの保護
- モジュール 10: 大規模データストア
- モジュール 11: ワークロードの移行
- モジュール 12: コストの最適化 ★省略
- モジュール 13: エッジのためのアーキテクチャ設計
ラボ（ハンズオン）
- ラボ 1 Amazon S3 VPC エンドポイントの通信を保 護する
- ラボ 2 Transit Gateway を設定する
- ラボ 3 AWS Fargate と Amazon ECS を使ってアプ リケーションをデプロイする
- ラボ 4 Lake Formation を使ってデータレイクを設定する
- ラボ 5 AWS DataSync と Storage Gateway を使用 してオンプレミスの NFS 共有を移行する
モジュール 1 アーキテクチャの確認
- アーキテクチャの基本確認
- VPC は複数リージョンにまたがることができない
- プライベートサブネットから S3 へアクセスする手法
- VPC エンドポイントを利用する
- ゲートウェイ型
- S3 と DynamoDB のみ対応
- VPC に対してゲートウェイを構築
- ルートの宛先はそのリージョンの S3 エンドポイント
- パブリック IP でアクセス
- 無料で利用可能
- インターフェース型
- サブネットに対して ENI を構築
- プライベート IP アドレスが紐づく
- サブネットへ構築されるので冗長構成の検討が必要
- 時間、転送量に課金
- オンプレミスからアクセス可能
- ゲートウェイ型
- VPC エンドポイントを利用する
ラボ 1 Amazon S3 VPC エンドポイントの通信を保 護する
プライベートサブネット内の EC2 インスタンスから S3 にアクセスするために利用する、VPC エンドポイントの設定方法について学習しました。 以下、ハンズオンで行った操作の概要です。
- AWS マネジメントコンソールと AWS Command Line Interface (AWS CLI) を使用して VPC エンドポイントを設定
- プライベートサブネットで VPC エンドポイントを使って Amazon S3 を操作
- VPC エンドポイントポリシーを作成してリソースへのアクセスを制限
モジュール 2 単一アカウントから複数アカウントへ
- マルチアカウント戦略
- 単一アカウントの利用の欠点
- 本番、開発、テスト環境など、用途の異なる環境が 1 アカウントに集約されてしまう
- 複数の役割を持つ人が一つのアカウントにアクセスすることになるので、管理が煩雑になる
- 権限の設定ミスで意図しない環境へ設定変更が行われるといった事故が起こりうる
- 複数アカウントの利用
- アカウントレベルで環境を分離し、権限管理を容易にする。
- ヒューマンエラーによる設定ミスを防止する
- マルチアカウントのユースケース
- ログ収集環境の分離
- アカウント侵害時に備え、ログを保存するためのアカウントを分ける
- ログを一元管理、管理を簡素化
- パブリッシングアカウント構造
- AWS Service アカウントなどを利用し、親アカウントから関連アカウントにリソースを共有
- リソースのデプロイを一元管理
- ログ収集環境の分離
- AWS Organization の活用
- ツリー構造でのアカウント管理
- 一括請求
- 管理アカウントで全てのアカウントの請求処理を実施可能
- アカウント管理の一元化
- SCP の作成によるポリシーの一括適用（OU 単位）
- SCP （サービスコントロールポリシー）
- IAM アクセス許可と SCP による許可で共通しているもののみが許可される
- SCP はアクセス許可を付与するのではなく、フィルターとして機能する
- SCP （サービスコントロールポリシー）
- マルチアカウントアクセスのシナリオ
- セキュリティ監査人用のアカウントを作成し、それぞれのアカウントのロールを引き受ける形でアクセスする
- 認証用のアカウントを作成し、クロスアカウントアクセスを利用して作業用のアカウントにスイッチロールする
- AWS IAM アイデンティティセンター
- Active Directory で認証完了したユーザーについて、複数のアカウントへもアクセス可能にする（SSO）。
- ログインポータルのようなイメージ
- Organization との連携、外部 ID プロバイダーが必要
- アクセス許可セットを作成してアクセス権利を定義可能
- AWS Control Tower
- ランディンゾーンを構成
- 管理対象のアカウントへ AWS のセキュリティのベストプラクティスに則った設定を強制する
- CloudTrail、AWS Config 等の設定
- Cloud Formation StackSets を使って設定される
- 管理対象のアカウントへ AWS のセキュリティのベストプラクティスに則った設定を強制する
- Control Tower でコントロールする要素の例
- IAM セキュリティ
- ルートユーザーに対して MFA を強制
- データセキュリティ
- S3 へのパブリックアクセスを禁止
- ネットワークセキュリティ
- RDP でのインターネットアクセスを許可しない
- 監査ログ
- CloudTrail と AWS Config を有効化
- モニタリング
- ClouTrail と CloudWatch の統合を有効化
- 暗号化
- EBS ボリュームの暗号化を強制
- ドリフト
- AWS Config のルール変更を禁止
- IAM セキュリティ
- Account Factory
- AWS Service Catalog を利用して、共通のリソースの設定を他のアカウント発行時に反映する
- IP、サブネット等のネットワーク設定など
- AWS Service Catalog を利用して、共通のリソースの設定を他のアカウント発行時に反映する
- ランディンゾーンを構成
- 単一アカウントの利用の欠点
モジュール 3 ハイブリッド接続
- Client VPN ソリューション
- クライアントベースの VPN サービス
- オンプレミスのリソースから AWS リソースへ安全にアクセス
- Site-to-Site VPN 接続のオプション
- オプション 1 仮想ゲートウェイに接続する
- オンプレミス側にカスタマーゲートウェイを構築
- AWS 側に仮想プライベートゲートウェイ（VGW）を構築
- オプション 2 EC2 インスタンスに接続する
- ソフトウェア VPN アプライアンスが実行されている VPC で Amazon EC2 インスタンスを使用し、リモートネットワークとの VPN 接続を確立
- オプション 3 Transit Gateway に接続する
- カスタマーゲートウェイを指定して VPN 接続を Transit Gateway にアタッチ
- Transit Gateway にアタッチされた全ての VPC に接続
- オプション 1 仮想ゲートウェイに接続する
- Site-to-Site VPN 接続の制限
- カスタマーゲートウェイ と VGW 間の VPN 接続自体はインターネット経由であるため、ネットワークパフォーマンスが低い場合がある
- IPv6 トラフィックがサポートされていない
- AWS Direct Connect（DX）
- サードパーティのデータセンターを利用する、専用線を介した接続
- ネットワークパフォーマンスが高い
- 利用形態
- 占有型
- Connection をユーザーへ提供
- 物理帯域（1 G、10 G）を占有
- 共有型
- Connection はパートナーが所有
- 物理帯域を他アカウントとシェア
- ホスト接続
- 帯域を指定して仮想的な回線を利用
- 占有型
- インターフェイス（VIF）の種類
- パブリック VIF
- パブリック IP アドレスを使って AWS のすべての パブリックサービスにアクセスするために使用する
- プライベート VIF
- プライベート IP アドレスを使って、直接または Direct Connect ゲートウェイ経由で Amazon VPC に接続するために使用する
- トランジット VIF
- Direct Connect ゲートウェイ経由で Transit Gateway に接続するために使用する
- パブリック VIF
- Direct Connect で VPC と接続する方法
- オプション 1 仮想ゲートウェイへのプライベート VIF
- プライベート IP アドレスを使用して VPC 内のリソースへのアクセスを提供
- オプション 2 Direct Connect ゲートウェイへのプライベート VIF
- すべての VPC で使用可能な単一の接続を作成する
- Direct Connect ゲートウェイ
- 1 つのプライベート VIF を用いたプライベート接続で様々なリージョン間での接続を実現可能
- オプション 3 Transit Gateway へのトランジット VIF
- Transit Gateway を利用する
- 同じリージョン内の複数の VPC または VPN に対する単一の接続を管理可能
- オプション 4 パブリック VIF 経由の VPN
- Direct Connect 専用ネットワーク接続を VPC の VPN と組み合わせる
- IPsec で暗号化されたプライベート接続を実現
- ネットワークコストが削減され、帯域幅のスループットが向上
- オプション 1 仮想ゲートウェイへのプライベート VIF
- オンプレミスーVPC 間接続の冗長構成
- VPN バックアップ回線と Direct Connect を組み合わせる
- 1 つのロケーションでそれぞれ異なるデバイスで終端する別々の接続を使用する
- DX に利用されているファイバーの切断またはデバイスの障害 による接続障害に対する耐障害性を確保
- Direct Connect ローケーション複数使った構成
- ファイバーの切断、デバイスの障害、ロケーション全体の障害による接続障害に対する耐障害性を確保
- 複数のロケーションでそれぞれ異なるデバイスで終端する別々の接続を使用する
- デバイスの障害、接続障害、ロケーション 全体の障害に対する耐障害性を確保
- Route 53 Resolver
- プライベートホストゾーン
- VPC 内で DNS 名を解決するのに利用、VPC の外部では機能しない
- Route 53 Resolver を利用して共有 VPC エンドポイント の名前解決を一元化
- プライベートゾーンを使用したハイブリッド名前解決
- オンプレミスから Route 53 ドメインに対してのリクエスト
- オンプレクライアントからの DNS クエリ→オンプレ DNS サーバー→Direct Connect →Route 53 リゾルバのインバウンドエンドポイント→Route 53 Resolver
- VPC 内の EC2 からオンプレミスへのリクエスト
- EC2 からのリクエスト→Route 53 リゾルバ→Route 53 リゾルバのアウトバウンドエンドポイント→DIrect Connect→オンプレ DNS サーバー
- オンプレミスから Route 53 ドメインに対してのリクエスト
- プライベートホストゾーン
モジュール 5 ネットワークを接続する
- VPC ピアリング
- 2 つの VPC 間のネットワークを接続する
- リージョン内、リージョン間で接続可能
- 異なるアカウント間の VPC で構成可能
- トランジット VPC
- Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでルーティングソフトウェアを実行している VPC
- 地理的に分散している複数の VPC や、個別の AWS アカウントで実行されている複数の VPC に対し、トランジット VPC を介して接続可能
- AWS Transit Gateway
- VPC とオンプレミスネットワークを相互接続するた めに使用できるネットワークトランジットハブ
- クラウドルーターとして機能し、ネットワークアーキ テクチャを簡素化
- トランジット VPC とは異なり、 Transit Gateway はマネージドサービス
- Transit Gateway のセットアップ
- Transit Gateway の作成
- アタッチメントの作成
- VPC、VPN 接続、Direct Connect ゲートウェイ、Transit Gateway ピアリング
- Transit Gateway テーブルの作成
- アタッチメントを Transit Gateway へアタッチ する
- AWS Resource Access Manager
- アカウント全体または AWS Organizations の組 織全体で Transit Gateway を共有して VPC をアタッチできる
- AWS PrivateLink
- イン ターフェイスエンドポイントの一種
- CIDR が重複している VPC 内のリソースへも接続可能
- ネットワーク的に接続するわけではなく、特定のリソースだけを公開するという形
- 通信は一方向
ラボ 2 Transit Gateway を設定する
Transit Gateway のセットアップ、異なるリージョンへのピアリング接続、など基本的な設定方法について学習しました。 以下、ハンズオンで行った操作の概要です。
- Transit Gateway の作成
- アタッチメントの作成
- ルートテーブルの作成
- VPC ルートテーブルの設定
- リモートリージョンの Transit Gateway へのピアリング接続
- Network Manager を利用したネットワークの可視化
モジュール 6 コンテナ
- コンテナとは
- アプリケーションを実行するための環境一式をパッケージ化したもの
- コンテナと仮想マシンの比較
- 仮想マシン
- OS やバイナリ、ライブラリが分離している
- コンテナ
- OS が共有
- 必要に応じてバイナリやライブラリも共有
- コンテナ同士は分離
- 仮想マシン
- EC2 上のコンテナ
- コンテナ ON VM の実行形態
- Docker とは
- コンテナ仮想化エンジン
- Docker のコンポーネント
- Docker ファイル
- Docker イメージ
- Docker CLI
- レジストリ、リポジトリ
- イメージの保存
- バージョン管理
- AWS でのコンテナホスティング
- AWS のコンテナサービス
- イメージレジストリ
- Amazon ECR（Elastic Container Registry）
- コンテナイメージを格納するレジストリサービス
- Amazon ECR（Elastic Container Registry）
- ホスティング
- Amazon EC2
- AWS Fargate
- 実行環境を作ってくれる
- 管理（オーケストレーション）
- Amazon ECS
- Amazon EKS
- イメージレジストリ
- AWS のコンテナサービス
- AWS Fargate
- Amazon ECS のコンピューティングエンジン
- サーバーの管理なしにコンテナを実行できる
- Amazon ECS
- スケーラブルかつ高性能なコンテナ管理システム
- マネージドプラットフォーム
- ECS の主要な 4 つの構成要素
- タスク定義
- コンテナの実行に必要な情報を定義
- クラスター
- サービスをまとめたもの
- サービス
- タスクの実行と維持
- タスク
- タスク定義に基づいて実行されたもの
- タスク定義
- コンテナの注意点
- ストレージは一時的
- 基本はステートレスコンテナとして利用する
- 必要な情報は外部ストレージサービスなどに保存
- ストレージは一時的
- Amazon EKS
- マネージド型 Kubernetes コントロールプレーン
ラボ 3 AWS Fargate と Amazon ECS を使ってアプ リケーションをデプロイする
アプリケーションを Docker コンテナイメージとして構築し、ECR にプッシュして, AWS Fargate でコンテナを実行する手法について学習しました。 以下、ハンズオンで行った操作の概要です。
- コンテナイメージを Amazon ECR リポジトリにアップロード
- コンテナをリポジトリから Amazon ECS Fargate クラスターにデプロイ
- Amazon ECS のサービスとタスクを作成
- Amazon ECS Fargate クラスターの Docker コンテナでウェブベースのアプリケーションをテスト
モジュール 13 エッジのためのアーキテクチャ設計
- Lambda のクォータ
- 最大実行時間 15 分
- 最大メモリ 10240 MB
- エッジサービス
- Amazon CloudFront
- Amazon Route 53
- AWS WAF, Shield
- Lambda@Edge
- エッジサービスを利用すれば効率的に、迅速に AWS ネットワークにアクセスできる
- AWS グローバルインフラストラクチャ
- Amazon CloudFront
- エッジキャッシュによりレイテンシーを短縮、セキュリティを強化
- キャッシュにより、オリジンサーバーへの負荷を軽減
- CloudFront のコンポーネント
- オリジン
- S3 バケット、EC2、ALB、カスタムオリジン
- ディストリビュージョン
- ドメイン名がわり振られる
- 独自 SSL 証明書を使用すると、独自のドメイン名 (www.example.com な ど) を使用可能
- ビヘイビア
- パスパターンの設定
- キャッシュの動作を設定
- 有効期限（TTL）の設定
- オリジン
- Lambda@Edge
- CloudFront から Lambda@Edge を使用してコードをトリガー
- カスタムコードをエッジに取り込み、コンテンツをカスタマイズ
- ユースケース
- User-agent ヘッダーの正規化
- HSTS セキュリティヘッダーの追加
- Cache-Contorol ヘッダーの強制
- トリガー
- ビューワーリクエスト
- リクエストされたオブジェクトが CloudFront キャッシュにあるかど うかを確認する前に関数が実行される
- ビューワーレスポンス
- リクエストされたファイルがビューワーに返される前に関数が実行される
- オリジンリクエスト
- CloudFront がリクエストをオリジンに転送したとき にのみ、関数が実行される
- オリジンレスポンス
- CloudFront がオリジンからのレスポンスを受け取っ た後、レスポンス内のオブジェクトをキャッシュする前に関数が実行される
- ビューワーリクエスト
- CloudFront Function
- CloudFront エッジロケーションで軽量な JavaScript コードを実行可能
- ユースケース
- キャッシュキー正規化
- ヘッダー操作
- ステータスコードの変更とボディ生成
- URL のリダイレクトまたはリライト
- CloudFront Function はキャッシュヒット時にも実行される
- Lambda＠Edge はオリジンリクエストが行われた時のみ実行される
- CloudFront Function とは実行される場所が異なるため
- Global Accelerator
- AWS Global Accelerator は、世界中のユーザーに提供するアプリケーショ ンの可用性とパフォーマンスを改善するネットワークサービス
- エニーキャスト IP を使用
- 全てのクライアントが同じ静的 IP を指し、最も近い POP（Point of Presence）に誘導される
- DNS の仕組みを使わない
モジュール 7 継続的インテグレーション/継続的デリバリー (CI/CD)
- CI/CD
- 一元化されたデプロイまでのステージ
- Infrastructure as code（IaC）
- Chef
- Pupet
- Ansible
- Terraform
- CloudFormation
- IaC ツールの種類
- 命令型
- 手順を順番に踏んで構築していく
- 原始的な処理を積み重ねていき、目的（ゴール）に向かう
- 宣言型
- ゴールの状態を定義
- インフラ全体を管理する仕組みの上に、定義を入力することで人間の介在なしで定義した状態を維持してくれる
- ツールの例
- CloudFormation
- IaC の参考記事
- 命令型
- Amazon CodeWhisperer
- AI コーディング支援
- AI セキュリティスキャン
- デプロイ戦略
- インプレース
- 既存のインスタンスでアプリケーションを更新
- ローリング
- 本番フリートの一部に更新を適用、段階的に更新
- イミュータブル
- 新規にインフラストラクチャで新バージョンのアプリを立ち上げる
- ブルー/グリーン
- 同じバックエンド（並列環境）を使用し、クローンやスワップにより切り替え
- データベースを使用しているシステムの場合は、新バージョンのアプリケーションとデータベースに互換性があるかを確認する必要がある
- インプレース
- AWS CloudFormation StackSets
- 1 回のオペレーションで複数のアカウントとリージョンにおいて スタックを作成、更新、削除できる
- 1 つの CloudFormation テンプレートを使用して、複数リージョンの AWS アカウントにスタックを作成
モジュール 8 高可用性と DDoS
- DDoS 攻撃
- 侵害されたホストのそれぞれが攻撃に参加し、標的を飽和状態にするような大量のリクエストを生成する
- 有効な緩和戦略
- 攻撃者に近いエッジロケーションで分散して防御する
- AWS Shield Standard
- 一般的な DDoS 攻撃から保護
- UDP リフレクション、SYN フラッド攻撃
- 追加料金なしで利用可能
- 一般的な DDoS 攻撃から保護
- AWS WAF
- WAF のメリット
- セットアップが容易
- 運用が容易
- ルールをカスタマイズ可能
- WAF を設定可能なAWS サービス
- CloudFront
- ALB
- API Gateway
- AWS AppSync
- Amazon Congnito user pools
- AWS WAF のルール
- 組み込みルール
- ユーザー独自で作成するカスタムルール
- マネージドルール
- 一般的なアプリケーションの脆弱性やその他の不要なトラフィックに対する 保護を提供するルール
- セキュリティベンダーが提供しているルールもある
- 組み込みルール
- AWS WAF の監視
- Cloud Watch でウェブリクエストとウェブ ACL および ルールをモニタリング可能
- アラーム、SNS 通知、E メールをトリガーして通知可能
- WAF のメリット
- AWS Shield Advanced
- 有料：月額 3000 USD
- AWS Firewall Manager
- アカウント、アプリケーション全体でルールを管理
- 組織のセキュリティコンプライアンスを確保
- 組織内のコンプライアンス違反インベントを修正
- AWS Firewall Manager の料金
- 100 USD/ポリシー/リージョン
- Shield Advanced を利用していれば無料
- AWS Network Firewall
- VPC 向けの高可用性ネットワークファイアウォール
- サブネット内に構築
- ACL よりも一元化されたより高度な制御が可能
- ドメイン名に対してフィルタリングが可能
モジュール 9 データの保護
- 暗号化の考え方
- 移動中のデータの暗号化
- ネットワーク暗号化
- 保管中のデータ
- ストレージの暗号化
- 使用中のデータ
- アプリケーションレベルの暗号化
- 移動中のデータの暗号化
- エンベロープ暗号化
- 暗号化に使用したキーをルートキーでさらに暗号化し、データを保護する
- AWS KMS
- AWS KMS と多層防御
- 復号キーへのアクセスとデータへのアクセスを分離する
- IAM ポリシー、バケットポリシー、キーポリシーを適切に設定
- 保管中のキーを保護する
- AWS KMS ソリューション
- 暗号化対象
- Amazon S3
- Secrets Manager
- Amazon EBS
- Athena
- Amazon RDS
- DynamoDB
- 暗号化対象
- AWS 管理のキー
- AWS KMS と統合されている AWS のサービスでユー ザーに代わって作成、管理、使用されるユーザーアカウント内の KMS キー
- カスタマー管理のキー
- ユーザーが作成、所有、管理する AWS アカウン トの KMS キー
- ユーザーが KMS キーを管理
- AWS KMS と多層防御
- S3 サーバー側の暗号化
- SSE-S3
- S3 マネージドキーを使用した、Amazon S3 のサーバー側暗号化
- SSE-KMS
- AWS KMS マネージドキーを使用した、Amazon S3 のサーバー側の暗号化
- バケットキー
- S3 から AWS KMS へのリクエストを減らすことができる
- SSE-C
- ユーザーが準備したキーを使用した、S3 サーバー側の暗号化
- ユーザーにてキーの管理が必要
- SSE-S3
- AWS CloudHSM
- 満たせる要件
- 自分のみが保有している専用の HSM に保存
- FIPS 140-2 レベル 3 に準拠する
- PKCS＃11、Java JCE、Microsoft CNG を使用するアプリケーションと統合
- 満たせる要件
- AWS Secrets Manager
- データベース認証情報、API キーなどを保存、 取得、ローテー ション、監査、 モニタリング可能
- Amazon RDS 認証情報のローテーション
- 組み込みのLambda関数を利用し、Secrets Manager を使用してデータベースの パスワードを自動的にローテーション可能
モジュール 10 大規模データストア
- 一元化されていないデータストアを使用することの課題
- データの冗長性が確認できない
- セキュリティホールの発生
- データの破損
- ユーザーの混乱
- Amazon S3 のデータ管理機能
- ストレージクラス
- Standard
- アクティブでアクセス頻度が高いデータ
- Standard IA
- まあり頻繁にアクセスされないデータ
- Gracier Instant Retrieval
- 高速の復元が必要になるアーカイブ済みデータ
- Gracier Flexible Retrieval
- 頻度は予測不能だが復元が必要になるデータ
- Glacier Deep Archive
- 復元される可能性が低いアーカイブデータ
- Intelligent-Tiering
- アクセスパターンが不明または変化するデータ
- アクセスパターンの変化に合わせてストレージコストを最適化
- Standard
- ストレージクラス分析
- アクセスパターンをモニタリングする
- データアクセス頻度の高いデータと低いデータを分類
- 分析結果に従ってストレージクラスの変更を検討する
- ストレージクラス
- S3 バッチオペレーション
- 1 回のリクエストで大量のオブジェクトを操作可能
- ユースケース
- 同じバケットへの大量オブジェクトコピー、暗号化設定
- アカウント間でオブジェクトを異なる場所へコピー
- S3 インベントリ
- 分析と監査のためにオブジェクトリストを定期的に生成
- 取得データ例
- ストレージクラス
- 作成日
- 暗号化ステータス
- S3 アクセスポイントソリューション
- 大規模なデータアクセスの管理を簡素化
- バケットポリシーの Condition 句でアクセスポイント経由のみ許可するように設定可能
- コンソールからもアクセスポイントを介して S3 にアクセス可能
- S3 Object Lambda
- ユーザーがデータを取得する際に、Lambdaでデータのマスキング処理などを行うことができる
- アクセスユーザーの役割ごとにデータのフォーマットを変える
- S3 アクセスポイントを必ず経由させる必要がある
- データウェアハウス
- 形式や構造を決めてデータを保存
- 事前定義されたスキーマ
- 構造化データ
- SQL 互換のみ
- 集約された詳細レベルのデータ
- 形式や構造を決めてデータを保存
- データレイク
- データを加工・整形せずに保存し、分析時に整形
- 事前定義されていないスキーマ
- 構造化/半構造化/非構造化データ
- 様々なツールで分析
- 制度のレベルが低いデータ
- データを加工・整形せずに保存し、分析時に整形
- AWS Glue
- データレイクに保存されたデータをクローラーが分類
- 保存されたデータをカタログ化する
- スキーマやテーブルが自動で定義される
- カタログ化されたデータを Athena 等で分析
- Amazon Athena
- S3 に保存されたデータや Glue でカタログ化されたデータを分析
- AWS Lake Formation
- データレイクを簡単に構築、保護、管理できるよ うにしてくれるフルマネージドサービス
- Lake Formation のブループリント
- データ管理のテンプレートで、データを データレイクに簡単に取り込むことができる
- データレイクのリソースに対してアクセス許可を設定可能（アクセスコントロール）
ラボ 4 Lake Formation を使ってデータレイクを設定する
Lake Formation, AWS Glue を利用したデータテーブル作成、Amazon Athena による分析の方法を学習しました。 以下、ハンズオンで行った操作の概要です。
- Lake Formation を利用したデータレイクとデータベースの作成
- AWS Glue を使用してたデータをクロールしてメタデータとテーブルの作成
- Athena を使用したデータのクエリ
- Lake Formation でのユーザー権限の管理
モジュール 4 専用インフラストラクチャ
- AWS Strage Gateway
- オンプレミスからクラウドへの低レイテンシーなアクセスを実現
- オンプレミスストレージをクラウドベースのファイル共有に移行する
- オンプレミスのバックアップをクラウドに保存可能
- 標準ストレージプロトコルを利用可能
- NFS、SMB、iSCSI、iSCSI-VTL
- VMware Cloud on AWS
- オンプレミスの VMware vSphere ベースの環境を、EC2 で実行されている AWS クラウド環境に移行して拡張し、 スケーラビリティと安全性の高いサービスを提供
- オンデマンドの VMware ソフトウェア定義データセンター（クラウドサービスとして提供）
- VPN リンクや Direct Connect リンクなどの 既存のハイブリッドリンクが必要
- VMware Cloud on AWS のユースケース
- クラウド移行
- データセンターの拡張
- 災害対策
- 新しいアプリケーションの構築
- AWS Outposts
- AWS Outposts AWS のインフラストラクチャ、サービス、API、ツールをオンプレミスの環境へ拡張できる
- 対応リソースは以下のドキュメントを参照
- AWS Local Zones
- AWS リージョンの拡張領域で、低レイテンシー環境を提供
- 特定のリージョンに紐づいた追加の AZ のようなイメージ
- ボタンひとつで有効化可能
- 無効化時は AWS サポート経由
- 基本的にマルチ AZ は利用できない
- ユースケース
- メディアコンテンツ制作のための環境
- リアルタイムのマルチプレイヤーゲームの環境
- 機械学習推論野環境
- AWS Wavelength
- ５G を利用するデバイス向けに超低レイテンシーの環境を提供
モジュール 11 ワークロードの移行
- 移行の目標設定
- コスト削減
- 移行によるインフラコストの削減
- 生産性の向上
- 耐障害性の獲得
- SLA の向上
- ビジネスの俊敏性の向上
- 新しい機能、アプリケーションの迅速にデプロイ可能な環境
- コスト削減
- 移行における 7 つの R
- Refactor（リファクタリング）
- アプリケーションをクラウドネイティブモードに再設計
- Replatform（リプラットフォーム）
- マネージドサービスへのデータベースの移行などのクラウド最適化
- Repurchase（再購入）
- 永久ライセンスから SaaS (Software-as-a-Service) モデルに 移行
- Rehost（リホスト）
- アプリケーションを変更せずに移行
- Relocate（再配置）
- アプリケーションを変更せずに vSphere ベースのアプリケーションを AWS に移行
- Retain（保持）
- 大規模なリファクタリングを必要とするビジネスクリティカルな アプリケーションを保持
- Retire（使用停止）
- 不要なアプリケーションの削除
- Refactor（リファクタリング）
- 移行ツール
- AWS Application Discovery Service
- オンプレミスサーバーに関する 使用状況と設定のデータを収集することで、AWS クラウドへの移行を計画
- AWS Application Migration Service （MGN）
- 高度に自動化されたリ フトアンドシフト (リホスト) ソリューション
- AWS DataSync
- オンプレミススト レージと Amazon S3、Amazon EFS、FSx for Windows File Server 間で大量のデータを簡単に移動
- Migration Hub
- リソースの検出、EC2 インスタンスの推奨事項、移行状況の追跡
- AWS Database Migration Service（DMS）
- データベースとデータウェアハウスを AWS に簡単かつ安全に移行・レプリケート
- 適したシチュエーション
- 十分な停止時間が取れない
- ソースターゲットが同一DBエンジンでない
- DB純正のレプリケーションが組めない
- AWS Schema Conversion Tool （SCT ）
- 移行するDB のスキーマを変更・最適化（スキーマの競合を避けるため）
- AWS Application Discovery Service
ラボ 5 AWS DataSync と Storage Gateway を使用 してオンプレミスの NFS 共有を移行する
AWS DataSync を利用してオンプレミスファイルサーバーのデータをコピーする方法、Storage Gateway を利用して NFS ファイル共有を設定する方法について学手しました。 以下、ハンズオンで行った操作の概要です。
- DataSync エージェントを EC2 インスタンスと してデプロイし、アクティブ化
- DataSync タスクを作成し、データを Linux ベースの NFS サーバーから S3 バケットにコピー
- Storage Gateway のファイルゲートウェイアプライアンスを EC2 インスタンスとしてデプ ロイ
- ファイルゲートウェイで NFS ファイル共有を作成する
- ファイルゲートウェイで NFS 共有に接続するように Linux ホストを設定
受講した感想
本コースでは、カウント管理や NW 構成シナリオ、データストアの作成・管理など、大規模環境で役立つサービス・ソリューションについて網羅的に学習できた点が良かったと思います。
日常的に大規模環境向けのサービスをあまり操作する機会がなかったため、受講前はそれらのサービスに関する理解が漠然としていました。
特に Transit Gateway などの大規模環境向け NW サービスは、日常で操作する機会が少ない上にドキュメントだけでは理解が追いつかず、設定のイメージが湧いていない状態でしたが、
ハンズオンを通して実際に複数リージョンを跨ぐ Transit Gateway の設定を行い、理解を深めることができました。
最後に
本トレーニングは、複数アカウントの管理や複数 NW の接続など、大規模環境な AWS 環境に関するサービスについて学習したい方におすすめとなっております。
また、AWS Certified Solutions Architect - Professional（SAP）認定取得に向けた知識の土台固めにも非常に有益なので、認定資格の取得を目指している方も受講をご検討ください！
以上、ヒラネでした。
13
