【AWS SAP】よく間違える問題まとめ

# EBSスナップショットのリージョン間コピー
EBSスナップショットを運用上のオーバヘッドを可能な限り抑え、別のリージョンに保存させるAWSサービスは何か

:::note
Amazon Data Lifecycle Manager (Amazon DLM)
:::

:::note alert
AWS Backup
→ AWS Backupでも実現できるが、EBSに特化したバックアップサービス「Amazon DLM」を利用することが正解
> Amazon EBS スナップショットを別の AWS リージョンに手動でコピーするか、**Amazon データライフサイクルマネージャーを使用してコピープロセスを自動化することができます。**
[Amazon EBS スナップショットを別の AWS リージョンにコピーする方法を教えてください。](https://repost.aws/ja/knowledge-center/ebs-copy-snapshot-other-region)
:::

## DynamoDBのリージョン間コピー
既存の単一リージョンに配置しているDynamoDBを別のリージョンにデプロイし、DR対策を実施させるには


:::note
- 別のリージョンにDynamoDBを構成[※1]し、
- DynamoDB テーブルを**グローバルテーブル**に変換

[※1]
別リージョンに同名のテーブルを事前に作成すること
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746730/4c288699-1263-c94b-724e-e3b812d7ec92.png)
[DynamoDB グローバルテーブルを管理するためのベストプラクティスと要件](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/V2globaltables_reqs_bestpractices.html)

[補足]
**Aurora**の場合、**Aurora Global Database**を利用することでプライマリリージョンのデータをセカンダリリージョンにリアルタイムでレプリケート可能（レイテンシ約1秒）。
　ただし、セカンダリリージョンにDBインスタンスの構築は必須。
:::

:::note alert
AWS BackupでDynamoDBのクロスリージョンバックアップを設定することはリアルタイムではないため、不正解
:::

## AWS OrganizationsでSCP管理
AWS Organizationsで特定のタグ以外のリソース作成を防ぐには

:::note
1. **リソース作成に必要なタグを許可する**SCPを作成＆保存する（SCPはJSON形式、ポリシーエディタに保存）
2. 保存したSCPをOUまたはアカウントにアタッチ 
:::

:::note alert
SCPの内容として**必要なタグがある場合のみ許可させる**方法は非推奨。
:::

## 
VPC内のSaaSアプリケーションをインターネットを経由させずに社内VPCと接続する方法は

:::note
1. AWS PrivateLink VPCエンドポイント(インターフェース型)を作成
2. SaaSが提供するVPCエンドポイントサービスに接続
※必要に応じて、VPCエンドポイントにセキュリティグループをアタッチ  
:::

:::note alert
「AWS Site-to-Site VPN」はインターネットを経由するため不正解
:::

## DataSyncでオンプレデータ同期
毎日生成されるオンプレのWindowsサーバのデータをAWSに移行させる方法は

:::note
**DataSync**を利用して**Amazon FSx**と同期し、毎日のタスクをスケジュールする
:::

:::note alert
- **Amazon EFS**はLinuxベースのため**誤り**
- **AWS Storage Gateway**はハイブリット環境を構築する役割のため**誤り**
:::

## API Gatewayのキャッシュ
会社のアプリは10分毎に更新され、3秒以内に応答したい。大量のデータを取り扱っている。どのような設計が最適か。

:::note
OpenSearch + API Gateway（TTL 15分）
:::

:::note alert
Amazon Lambda@Edge関数はキャッシュ機能を持たないため、不正解
:::

## Kinesis Data Streams
### 1シャードあたり、何MB/秒のデータの読み取りをサポートしているか

:::note
2 MB /秒
:::

### 1シャードあたり、何レコード/秒の書き込みをサポートしているか
:::note
1,000レコード/秒 または 1MB/秒　※両方満たす必要あり
:::

#### 補足
| No | 項目                     | 上限値                              |
|----|--------------------------|-----------------------------------|
| 1  | 書き込みスループット       | 1MB/秒、または1,000レコード/秒      |
| 2  | 読み取りスループット       | 2MB/秒                              |
| 3  | 読み取りレイテンシ         | 最大 5 秒（デフォルトのレイテンシ） |

## Lambda関数とAuroraのパフォーマンス改善
API GatewayとLambda関数とAuroraのアーキテクチャがあります。Lambda関数はAuroraに多数接続することがボトルネックです。解決するには？

:::note
- **RDS Proxy** を使用して、Aurora データベースのリーダーエンドポイントへの接続プールを設定する
- Lambda 関数内のデータベース接続を開くためのコードを**イベントハンドラの外**に移動する
:::

## Lamdba関数のコスト削減
Amazon API Gateway、AWS Lambda、DynamoDB のアプリケーションがあります。Lambda関数はコストが増加しています。調査すると平均実行時間が5分でした。待ち時間のほとんどはオンプレ環境のMySQLサーバへの高いレイテンシーのネットワーク呼び出しになります。VPCへの接続はVPNが利用されています。コストを削減するにはどうすればよいですか？

:::note
- オンプレ環境のMySQLをAmazon RDS for MySQLに移行する
- API GatewayでAPIキャッシュを有効にし、Lamdba関数の呼び出し回数を減らす
- Lamdba関数のパフォーマンスを監視し、実行時間を維持しながらタイムアウトとメモリを低いものに調整する
- DynamoDB Auto Scalingを有効にする
:::

## Lambda関数の遅延
スマートメーターから送信されるデータの処理で、AWS Lambda関数の遅延（1～2分）やDynamoDBのスループット超過エラー（ProvisionedThroughputExceededException）およびTooManyRequestsExceptionが発生している。この問題を解決するための適切な方法は？

:::note
- DynamoDB テーブルへの書き込み容量の単位を増やす
- API Gateway から Amazon Kinesis Data Streams にデータをストリーミングし、データをバッチで処理する
:::

:::note alert
- Lambda 関数で使用できるメモリを増やす
→今回の原因はスマートメーターからの大量データが処理能力を超え、DynamoDBや複雑なデータ構造がボトルネックになっているため、Lambda関数のメモリを増やすことで解決には繋がらない。
- SQSキューにデータを収集し、Lambda関数をトリガとして各メッセージを処理する
→Lambda関数が原因ではないため、SQSを使用しても意味なし。
:::