AWS 認定ソリューションアーキテクト – プロフェッショナル 合格への道#14

#はじめに
![SAAver2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/321923/034470a5-f22c-515a-0b44-22aee40c6d18.png)
#学び
##Lambda関数のスロットリングについて
Lambda 関数が失敗する場合のトラブルシューティングを教えてください。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/lambda-troubleshoot-function-failures/

* アクセス許可の問題
    * CloudTrail は、AWS アカウントの API コールをイベントとしてキャプチャします。Lambda 関数の呼び出しに失敗した場合、Lambda の CloudTrail ログエントリを確認
* コードの問題
    * Lambda 関数の失敗の詳細については、CloudWatch で Lambda ログを確認
    * X-Ray
        * Lambda 関数でダウンストリーム AWS リソース、マイクロサービス、データベース、HTTP ウェブ API を使用している場合は、X-Ray を使用して問題のトラブルシューティングを行います。
    * 依存関係
        * Lambda 関数のデプロイパッケージに依存関係が含まれている場合は、コードが正常にインポートできることを確認
        * または、Lambda Layers を使用して、デプロイパッケージの外部で依存関係を追加できます。
* ネットワークの問題
    * Lambda 関数が Amazon Virtual Private Cloud (Amazon VPC) に接続されている場合は、すべてが正しく設定されていることを確認します。詳細については、VPC 内のリソースにアクセスできるように Lambda 関数を設定
    * Amazon VPC 対応の Lambda 関数がインターネットを呼び出す必要がある場合は、必ずインターネットアクセスを許可
* スロットリング
    * Lambda 関数を呼び出すリクエストが、同時実行数の制限よりも速く到着した場合、リクエストは 429 スロットリングエラーで失敗します。
* API 500 および 502 エラーを呼び出す
    * https://aws.amazon.com/jp/premiumsupport/knowledge-center/lambda-troubleshoot-invoke-error-502-500/


### AWS Lambda 関数スケーリング
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-scaling.html

> 初めて関数を呼び出すと、AWS Lambda により、関数のインスタンスが作成され、イベントを処理するためのハンドラーメソッドが実行されます。関数はレスポンスを返すときに、アクティブなまま待機した上で追加のイベントを処理します。最初のイベントの処理中に関数を再度呼び出すと、Lambda は別のインスタンスを初期化し、関数は 2 つのイベントを同時に処理します。さらにイベントが入ってくると、Lambda は使用可能なインスタンスにそれらを送信し、必要に応じて新しいインスタンスを作成します。リクエストの数が減ると、Lambda は他の関数のスケーリングキャパシティを解放するため、使われていないインスタンスを停止します。

##　ElasticCashのキャッシュミスが発生した際RDSからのみデータを取得したい時は遅延読み込み
## SQS　ポーリングについて
Amazon SQS ロングポーリングを理解する
https://qiita.com/taka_22/items/718ec340a710bbf5e3d0

> SQSはリクエスト課金なので、出来るだけリクエスト数を少なくした方が良い。つまり、ロングポーリングタイムアウト秒を最大に設定することで、リクエスト回数を減らし、コストを抑えることが出来る。

AWS LambdaのSQSへの自前ポーリングをやめてSQSイベントソーストリガーに変更した
https://www.yamamanx.com/aws-lambda_sqs_evetn_source/

##　API GatewayのLambda オーソライザーから後続のLambdaにデータを引き渡す
https://dev.classmethod.jp/articles/lambda-authorizer/

## デプロイ戦略おさらい
AWS Elastic Beanstalk とは
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/Welcome.html

> Elastic Beanstalk は、Go、Java、.NET、Node.js、PHP、Python、Ruby で開発されたアプリケーションをサポート

### Elastic Beanstalk 概念
* アプリケーション
    * Elastic Beanstalk アプリケーションは、Elastic Beanstalk コンポーネントの論理コレクションであり、環境、バージョン、環境設定などを含みます。
* アプリケーションバージョン
    * ウェブアプリケーションのデプロイ可能コードの特定のラベル付きイテレーションのこと
        * デプロイ可能コードが含まれている Amazon Simple Storage Service（Amazon S3）オブジェクトを指します。
* 環境
    * 環境は、アプリケーションバージョンを実行する AWS リソースのコレクションです。各環境が実行するのは一度に 1 つのアプリケーションバージョンだけですが、同じアプリケーションバージョンや複数の異なるアプリケーションバージョンを多数の環境で同時に実行できます。環境を作成するときは、指定したアプリケーションバージョンを実行するために必要なリソースを Elastic Beanstalk がプロビジョニングします。
* 環境枠
    * Elastic Beanstalk 環境を起動したら、まず環境枠を選択します。環境枠は環境で実行するアプリケーションのタイプを指定し、それをサポートするために Elastic Beanstalk でプロビジョニングするリソースを決定します。HTTP リクエストを処理するアプリケーションは、ウェブサーバー環境枠で実行されます。Amazon Simple Queue Service (Amazon SQS) キューからタスクを引き出す環境は、ワーカー環境枠で実行されます。
* 環境設定
    * 環境設定は、環境とその環境に関連付けられているリソースの動作を定義するパラメータと設定のコレクションを識別します。環境の設定を更新すると、変更の種類に応じて、Elastic Beanstalk は自動的に既存のリソースに変更を適用するか、既存のリソースを削除して新しいリソースをデプロイします。
* 保存された設定
    * 保存された設定 は、一意の環境設定を作成するための開始点として使用できるテンプレートです。設定を作成するか、保存された設定を変更し、Elastic Beanstalk コンソール、EB CLI、AWS CLI、または API を使用して環境に適用できます。API および AWS CLIは、保存された設定を 設定テンプレートとして参照します。
* プラットフォーム
    * プラットフォームは、オペレーティングシステム、プログラミング言語ランタイム、ウェブサーバー、アプリケーションサーバー、および Elastic Beanstalk コンポーネントの組み合わせです。ウェブアプリケーションはプラットフォームを対象にして設計します。Elastic Beanstalk には、アプリケーションを構築できるさまざまなプラットフォームが用意されています。

### デプロイポリシーと設定
* [Rolling]  デプロイ
    * Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイするため、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になります。つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在します。
* [Immutable] デプロイ
    * 古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動
        * Elastic Beanstalk で環境のロードバランサーの背後に 2 つ目の (一時的な) Auto Scaling グループを作成し、新しいインスタンスを含有させます。これにより、Elastic Beanstalk は新しいグループ内の新規設定で単一のインスタンスを起動します。このインスタンスは、以前の設定を実行している元の Auto Scaling グループの全インスタンスと共にトラフィックを処理
        * 最初のインスタンスがヘルスチェックに合格すると、、Elastic Beanstalk は元の Auto Scalingグループで実行しているインスタンスの数に一致する新しい設定で、追加のインスタンスを起動します。新しいインスタンスがすべてヘルスチェックに合格した場合、Elastic Beanstalk はこれらのインスタンスを元の Auto Scalingグループに転送し、一時 Auto Scaling グループと古いインスタンスを削除

### Lambdaのベストプラクティス

Lambda関数固有のものは環境変数。各Lambda間で共有するものはシークレットパラメータへ

#saa2
##1 〇
キーと値のデータモデルを使用してメッセージを保管するアプリがあります。DBはマイクロ単位のレイテンシでメッセージを配信したい。

* Aurora Replicaを使用したAurora
    * なし。リードレプリカは基本的に可用性の向上
* DynamoDB Acceleratorを使用したDynamoDB
    * 正解。
* ElasticCash for Memcashedを使用したAurora
* ElasticCash for Memcashedを使用したNeptune
    * グラフデータベース

### Amazon DynamoDB とは
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Introduction.html
> 

#### インメモリアクセラレーションと DynamoDB Accelerator (DAX)
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/DAX.html

> Amazon DynamoDB はスケールとパフォーマンスのために設計されています。ほとんどの場合、DynamoDB 応答時間は1桁台のミリ秒単位で測定できます。ただし、マイクロ秒の応答時間を必要とする、一部のユースケースがあります。これらのユースケースでは DynamoDB Accelerator (DAX) が整合性データへのアクセス時に素早い対応を実現しています。

#### DAX コンポーネント
> DAX クラスターは 1 つ以上のノードで構成されています。各ノードはそれぞれ、自身の DAX キャッシングソフトウェアのインスタンスを実行します。ノードのうち 1 つがクラスターのプライマリノードとして機能します。他のノード (存在する場合) はリードレプリカとして動作します。アプリケーションは、DAX クラスターのエンドポイントを指定することで DAX にアクセスできます。DAX クライアントソフトウェアはクラスターエンドポイントと連携して、インテリジェントな負荷分散とルーティングを実行します。受信リクエストは、クラスター内のすべてのノードに均等に分散されます。

**読み取り**

* getiem
* batchgetitem
* scan
* query

**その他のオペレーション**
> DAX では、テーブルを管理する DynamoDB のオペレーション (CreateTable や UpdateTable など) を認識しません。アプリケーションがこのようなオペレーションを行う必要がある場合は、DAX を使用するのではなく、直接 DynamoDB にアクセスする必要があります

**リクエストレート制限**
> DAX に送信されるリクエストの数がノードの容量を超える場合、ThrottlingException を返すことによって、追加のリクエストを受け入れるレート DAX を制限します。DAX は、CPU 使用率を継続的に評価して、正常なクラスター状態を維持しながら処理できるリクエストの量を判断します。

### 制約
* リージョンとアベイラビリティーゾーン
    * ある AWS リージョンにある DAX クラスターは、同じリージョンにある DynamoDB テーブルとのみやり取りできます。したがって、適切なリージョンに DAX クラスターを起動することを確認してください。他のリージョンに DynamoDB テーブルがある場合は、そのリージョンにも DAX クラスターを起動する必要があります。
* セキュリティグループ
    * DAX クラスターは、Amazon Virtual Private Cloud (Amazon VPC) 環境で実行されます。この環境は、AWS アカウントに専用の仮想ネットワークであり、他の VPC からは独立しています。セキュリティグループは、VPC の仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドネットワークトラフィックをコントロールできます。
VPC でクラスターを起動する際に、着信ネットワークトラフィックを許可する進入ルールをセキュリティグループに追加します。進入ルールは、クラスターのプロトコル (TCP) とポート番号 (8111) を指定します。このルールをセキュリティグループに追加すると、VPC 内で実行されるアプリケーションが DAX クラスターにアクセスできます。
* クラスターエンドポイント
    * 基本的にはアプリからエンドポイントにアクセスが推奨。直接ノードにアクセスも可能だが非推奨
* サブネットグループ
    * DAX クラスターを作成する場合、キャッシュサブネットグループを指定する必要があります。DAX はそのサブネットグループを使用して、そのサブネット内でノードに関連付けるサブネットおよび IP アドレスを選択します。
* イベント
    * DAX は、ノードの追加の失敗、ノードの追加の成功、セキュリティグループの変更など、重要なイベントをクラスター内に記録します。主要イベントをモニタリングすることで、クラスターの現在の状態を知り、イベントに基づいて是正措置を取ることができます。AWS マネジメントコンソール、または DAX 管理 API の DescribeEvents アクションを使用して、これらのイベントにアクセスできます。
    * 特定の Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信するようにリクエストすることもできます。そうすれば、DAX クラスターでイベントが発生したことがすぐにわかります。
    * Amazon CloudWatch によるモニタリング
* DAX のアクセスコントロール
    * DAX の IAM サービスロール
        * DynamoDBのアクションを定義
    * DAX クラスターのアクセスを許可する IAM ポリシー
        * DAX クラスターを作成したら、ユーザーが DAX クラスターにアクセスできるように、IAM ユーザーにアクセス権限を付与する必要があります。
    * DAX 経由で DynamoDB にアクセスするが、DynamoDB に直接アクセスはしない設定ができる。

### Amazon Neptuneでグラフデータベース初体験！
https://qiita.com/dcm_hayashi/items/9b2536b6fbffa0118fad

##2　〇
EC2のスケールインイベント中にリクエストを処理するには？

* スティッキーセッションを有効
    * 不正解
    * 見ておくとよい記事
        * スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと
        * https://dev.classmethod.jp/articles/stateless_ec2/
* ALBでコネクションドローを有効
    * 正解
    * 【AWS】ELB(Elastic Load Balancing)まとめ
        * https://qiita.com/iron-breaker/items/54bf469a4c17d4350f3b#connection-draining
* Autoscalingのクールダウンを1500秒に設定
* インスタンスのターゲットグループの登録解除遅延タイムアウトを1500秒より長くする。

##3 3層アーキテクチャがある。最もセキュリティが高くHTTPSでweb層のリソースにアクセスさせるのはなにか

* apigatewayをvpcに接続。web.app.dbのプライベートサブネットを作成。
    * 不正解
* igwをアタッチ。webはpublic、そのほかはプライベートサブネット。
    * 正解
* pgwをアタッチ。webとappをパブリックサブネットへ配置。dbはプライベート
    * 不正解
* インターネットからすべての通信を許可するSGをwebサーバにアタッチ。apigatewayから通信を許可するSGをappにアタッチ。
    * 不正解。
* HTTPSを許可するSGをwebへ、webからhttpを許可するSGをapp、appからTCPを許可するSGをDBへ
    * 正解

これをよめ！
【読んでみた】Amazon VPCを保護するためのベストプラクティス #reinvent #NET309
https://dev.classmethod.jp/articles/reinvent2017-net309/

##4〇
インフラの管理コストなしでマイクロサービスを実行した。リクエストの増加量に従って短時間でスケーリングできることが求められる。

* EBのコンテナでサービスを実行
    * スケールアップは自動的に行われない
* apigatewayとLambdaで実行
    * 正解
* Autoscaling設定したEC2上で実行
* ECSを使用してコンテナ上で実行
    * 正解

### マイクロサービスの概要
https://aws.amazon.com/jp/microservices/


##5〇
1つの中央ソースから承認・認証・ユーザ管理を行えるものは？

* IAMロール
* IAMユーザ
* Cognitoユーザツール
    * ユーザープールの間違い
    * これだけだと認証しかできないのでは？
    * 正解
* MSAD
    * 

### Amazon Cognito とは
https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/what-is-amazon-cognito.html

> Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションの認証、許可、ユーザー管理をサポート

* ユーザープール
    * アプリユーザーのサインアップとサインインオプションを提供するユーザーディレクトリ
* ID プール
    * AWS の他のサービスに対するアクセスをユーザーに許可

#### 一般的な Amazon Cognito シナリオ
* ユーザープールによる認証
    * ユーザーがユーザープールを使用して認証できるようにすることができます。アプリユーザーは、ユーザープールを通じて直接サインインすることも、サードパーティーの ID プロバイダー (IdP) 通じて連携してサインインすることもできます。ユーザープールでは、Facebook、Google、Amazon、Apple を介したソーシャルサインイン、および OpenID Connect (OIDC) および SAML IdP から返されるトークンの処理のオーバーヘッドを管理
    * token払い出し

* ユーザープールを使用してサーバー側のリソースにアクセスする
    * ユーザープールへのサインインに成功すると、ウェブやモバイルアプリケーションに Amazon Cognito よりユーザープールトークンが送信されます。サーバー側のリソースへのアクセスを制御するには、これらのトークンを使用します。また、ユーザープールグループを作成してアクセス許可を管理したり、異なるタイプのユーザーを表したりすることもできます。グループを使用して、リソースをアクセス制御する方法の詳細については、「ユーザープールにグループを追加する」を参照
    * 払いだしたtokenでリソースへのアクセス
    * ユーザープールにドメインを設定すると、ホストされたウェブ UI が Amazon Cognito によってプロビジョニングされるため、アプリケーションにサインアップページとサインインページを追加できるようになります。この OAuth 2.0 認証基盤を使用すると、独自のリソースサーバーを作成して、ユーザーは、保護されたリソースにアクセスできるようになります。

* API Gateway および Lambda でユーザープールを使用してリソースにアクセスする
    * API Gateway を介して API にアクセスすることをユーザーに許可できます。API Gateway は、成功したユーザープール認証からトークンを検証し、Lambda 関数や独自の API などのリソースへのアクセスをユーザーに許可するためにトークンを使用します。
    * ユーザープール内のグループを使用して、グループメンバーシップを IAM ロールにマッピングすることによって、API Gateway を使用してアクセス権限を制御することができます。ユーザーがメンバーとなっているグループは、アプリのユーザーがサインインするとユーザープールより付与される ID トークンに含まれています。

* ユーザープールと ID プールを使用して AWS のサービスにアクセスする
    * ユーザープールの認証に成功すると、アプリケーションに Amazon Cognito よりユーザープールトークンが送信されます。
    * token払い出してidで認証情報と交換してアクセス
* サードパーティーを使用して認証を行い、ID プールを使用して AWS サービスにアクセスする
    * ID プールを使用することで、ユーザーは AWS のサービスにアクセスできます。ID プールには、サードパーティー ID プロバイダーによって認証されたユーザからの IdP トークンが必要です
    * トークン払い出しをサードパーティIDプロバイダに委任
* Amazon Cognito を使用した AWS AppSync リソースへのアクセス
    * tokenを上の機構で払い出してappsyncと連携

![Cognito.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/321923/759e5570-ac5a-f361-3883-495fda1a10c7.png)

### AWS再入門 AWS Directory Service 編
https://dev.classmethod.jp/articles/cm-advent-calendar-2015-aws-re-entering-directoryservice/

* AD Connector
    * 既存の AD ドメインを活用したいとき
    * AD ドメインのログイン情報で AWS の Management Console にシングルサインオン (SSO) する
    * EC2 Simple Systems Manager を利用して、AD ドメインに参加した状態で EC2 インスタンスを起動
* Simple AD
    * VPC 上にまったく新しいディレクトリを作成したいとき、Simple AD は手頃なソリューションです
    * AD Connectorと一緒
    * ドメインが変わる点だけ
* Microsoft AD
    * ドメインコントローラが AWS により維持される
    * 作成されるのは Active Directory 互換のドメインコントローラではなく Windows Server 2012 R2 で実行される AD ドメインサービス

### Amazon Cognito を使用した AWS AppSync リソースへのアクセス
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scale-based-on-demand.html

## 6
SQSコンシューマEC2の動的スケーリングについて

* ApproximateNumberofMessages メトリクスに基づいてautoscalingグループを設定する


> ポリシーがスケールインに異なる基準を使用する場合でも、最大容量を提供するポリシーを優先するというアプローチが適用されます。たとえば、3 つのインスタンスを終了するポリシーと、インスタンス数を 25% 減らすポリシーがあり、スケールイン時にグループに 8 つのインスタンスがあるとします。この場合、Amazon EC2 Auto Scaling は、グループに最大数のインスタンスを提供するポリシーを優先させます。その結果、Auto Scaling グループは 2 つのインスタンスを終了します (8 の 25% = 2)。その目的は、Amazon EC2 Auto Scaling がインスタンスを削除しすぎないようにすることです。

### Amazon SQS のスケーリングの設定
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-using-sqs-queue.html

## 7
EC2インスタンス間のデータコスト削減ソリューション

* インスタンスをapp meshにリンクする
* インスタンスをスプレッドプレイスメントグループに配置
    * 正解
    * 同一AZは無料で通信できます。
* プライベートIPアドレスで通信する
* AZ間にDXを敷設する

### スプレッドプレイスメントグループ
![supureddo .PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/321923/7fdadaef-90e3-d2ae-fe13-b0459e2d30af.png)

同じRZの複数AZにも分散できる。

### AWSの通信で料金がかかる箇所をまとめてみた
http://blog.serverworks.co.jp/tech/2020/02/05/post-78668/

> 同じ アベイラビリティーゾーン内の Amazon EC2、Amazon RDS、Amazon Redshift、Amazon ElastiCache インスタンスと Elastic Network Interfaces 間のデータ転送は無料です。

##8
IOTデータがキューに書き込まれます。しかし、一部のデータレコードが複数回受信および処理される。重複レコードが処理されないためにはどうするべきか


* data steamにながす
    * 不正解
    * レコードを削除する概念がないため
* firehoseに流す
* snsに流す
* fifoキューに流す
    * 正解。
    * 配信は厳密に一回


### Amazon Kinesis StreamsとAmazon Kinesis Firehoseは何が違うのか
https://dev.classmethod.jp/articles/difference-between-kinesis-streams-and-kinesis-firehose/

> Kinesis Streamsの最大の特徴は「レイテンシの速さ」です。Kinesis Firehoseがデータロードまで60秒を見ているのに対しKinesis Streamsはsub-1、つまり1秒以下でのデータロードにて設計されています。
Kinesis Streamsの使いドコロとしては「次々に上がってくるデータの内容をリアルタイムに加工、表示させたい」というニーズに対応させるのが良いでしょう。LambdaやEC2でStreamsのレコードを拾えるのもすぐに加工してダッシュボード等に表示しやすくするためです。


> Kinesis Firehoseの特徴としては「Zero Administration(ゼロ管理)」というのが挙げられます。Kinesis Streamsとは違い、EC2からポーリングしたりLambdaのコードを書く必要は一切ありません。設定を行うだけでS3やRedshiftにデータがそのまま流れます。
S3やRedshiftに大量のデータを溜める目的は何か。それはズバリ「分析用途」です。各種BIツールでデータをわかりやすく表示し、様々なクエリをかけて多様な切り口からデータを分析するためにRedshiftのようなDWHは存在します。 分析するのにデータがputされてから処理するまでのスピードはそれほど求められません。逆に求められるのは大量のデータを効率よく格納する圧縮技術やいかにセキュアにデータを保持するか、という暗号化技術です。 FirehoseはGZIPやSNAPPYといった圧縮アルゴリズムが使えますし、KMSを使った暗号化も可能になっています。

![神の図.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/321923/192e1217-6cdc-f5d8-0111-1eab66f177d5.png)

##9
既存ADと統合できる共有ファイルシステムは？


### Amazon FSx for Windows File Server により組織の自己管理型 Active Directory で直接ファイルシステムを使用できるようになりました
https://aws.amazon.com/jp/about-aws/whats-new/2019/06/amazon-fsx-for-windows-file-server-now-enables-you-to-use-file-systems-directly-with-your-organizations-self-managed-active-directory/

### AWS再入門 Amazon Elastic File System編
> Amazon Elastic File System（以下、Amazon EFS）は、シンプルで、スケラーブル、伸縮自在なフルマネージドな共有ストレージサービスです。Amazon EC2やオンプレミスリソースから使用できます。NFSバージョン4.0または4.1使用して、VPC上に作成したAmazon EFSファイルシステムをマウントし、共通データの読み書きを可能にします。 なお、執筆時点（2019/07/25）において、Amazon EFSでWindowsはサポートされておりませんので、ご注意ください。

### AWS DataSync
> AWS DataSync は、オンプレミスストレージと Amazon EFS の間でデータを迅速かつ簡単に移動することができるオンラインのデータ転送サービスです。DataSync では、専用のプロトコルを使用して、オープンソースツールと比べて最大 10 倍の速度で、インターネットまたは AWS Direct Connect 経由で、迅速かつ安全に転送することができます。DataSync を使用すると、ワンタイムデータ移行、タイムリーなクラウド分析のためのオンプレミスデータの転送、データの保護と復元のための AWS へのレプリケーションの自動化を行うことができます。