AWS　SAA-C02対策　サービス使い方まとめ│コンパクトなデータ活用サイト

1 AWS認定ソリューションアーキテクトアソシエイトとは
2 EC2（必須知識）
- 2.1 EBS（ボリューム）
3 RDS（データベース）
4 S3（データベース）
5 Redshift（データベース）
6 DynamoDB（データベース）
7 Route53（DNSウェブサービス）
8 SQS（メッセージキューイングサービス）
9 CloudFront（高速コンテンツ配信ネットワークサービス）
10 ElastiCache（メインメモリキャッシュサービス）
11 まとめ

AWS認定ソリューションアーキテクトアソシエイトとは

ソリューションアーキテクトを日本語に直訳すると「問題解決のための仕組みを設計する人」です。

AWS認定ソリューションアーキテクトアソシエイト試験ではAWSのサービスを適切に選択し、可用性・拡張性・コスト等の対応できるシステム設計をする能力をはかる試験となります。

今回は試験に関係するサービスをまとめてみました！

EC2（必須知識）

アーキテクチャを考える際に必ず出るのがEC2です。

・別リージョンへのコピーする際はインスタンスのAMI作成し、構築できる

※EBSのスナップショットのみではEBS内のデータのみのため、インスタンスの設定などはコピーできない。

・ハイバネーション機能により、インスタンスを休止し、セットアップ状態で再開できる。

・インスタンスにタグを追加し、IAMポリシーでタグへのアクセス定義をし、アクセス制御。

・EC2インスタンス間の通信がうまくできない場合はセキュリティグループの通信許可がされているかを確認する。

リザーブドインスタンス	スポットインスタンス
常時稼働していて、長期間使用する場合、コスト削減できる 1年または3年契約のため、不要な場合にはマーケットプレイスで販売可能	途中でアプリケーションが中断してもよい場合、コスト最適化できる一時的なAutoScalingを使った拡張でも使用可能

EBS（ボリューム）

SSD	HDD
小さく煩雑な読み書き。 1GB~16TB(io1は4GB~16TB)。料金は単位あたりHDDの倍くらい。	大きなストリーミングデータ用。 500GB~16TB。単位当たりでは安い。

・EBSのボリュームタイプの選択で、小さい（サイズが100GB程度）場合gp2（汎用SSD）を利用したほうがコストを抑えられる。

・EC2とEBSを利用してDBを構築する場合、性能を考慮してEBSボリュームはプロビジョンドIOPS SSDにする。

・最も回復性が高く、1つのボリュームが故障してもすぐにデータ利用がしたい場合、RAID1構成で2つ以上のEBSボリューム間でミラーリングをとれば、回復性の高いデータ冗長構成にできる。

・EBSのポイントインタイムスナップショットでは、増分バックアップにより、初期スナップショットからの差分のみを取得するため、ストレージコストを最小限にできる。

・Data Lifecycle Managerを使用すると、EBSスナップショットをスケジュールし、保持ポリシーに従い古いスナップショットを削除できる。Data Lifecycle Managerはスナップショットの作成、保持、削除を自動化できる。

　

RDS（データベース）

RDSリードレプリカ（非同期レプリケーション）を利用することで以下の効果を期待できる。

　
・DBインスタンスの読み取り頻度の高いDBのワークロードを緩和することで、全体の読み込みスループットを向上させる。

・必要に応じてスタンドアロンDBに昇格させ、マスターDBのバックアップとして使用できる。
リードレプリカを使用して、マスターDBやスタンバイDBへ影響することなく、レポート生成をできる。

・データベース作成時にRDSの暗号化オプションを有効化することで、インスタンスとスナップショットを暗号化できる。暗号化には「データ保存時の暗号化」と「通信アクセスの暗号化」()がある。

・メモリ、CPU、ストレージの使用状況をモニタリングする。Amazon CloudWatchで通知するように設定し、システムのパフォーマンスと可用性を維持する。

・自動バックアップを有効にし、1 日のうちで書き込み IOPS が低くなる時間帯にバックアップが実行されるようにバックアップウィンドウを設定する。

読み取りリクエストの増加によるRDSインスタンスの負荷を抑えるには下記の方法などがある。

・RDSリードレプリカの作成、RDSインスタンスのタイプを高性能なものにする。

S3（データベース）

・S3は大量ストレージ容量、コスト効率、拡張性、耐久性に優れている。

・オンプレミスでストレージが不足した際に、AWS Storage Gatewayを利用し、低レイテンシアクセスでS3と接続できる。

・クロスオリジンリソース共有（CORS）は別のドメインにあるリソースとの通信の設定。これを利用し、クライアントのウェブアプリケーションから別ドメインにあるS3リソースに対するアクセスを選択的に許可できる。

・S3バケットのクロスリージョンレプリケーションにより、リージョン全体に及ぶ大規模災害に対して、データを保護できる。（基本的にはリージョン外コピーはしない。）

・S3の読み書きリクエスト性能の向上にはプレフィックスに日付順の名前を使用する。（以前のガイドラインではオブジェクトプレフィックスをランダム化し、各オブジェクト名の日付の前にハッシュキーをつける。）

・S3 API利用時のセキュリティ強化にはAPI認証情報を保存するのではなく、利用アプリケーションにIAMロールを割り当てる。

・S3バケットのオブジェクトを誤って削除しないように、MFA削除/バージョニング/IAMロールの有効化をすることができる。

S3の暗号化は以下がある

SSE-S3	SSE-KMS/SSE-C3
デフォルト暗号化設定可。	デフォルト暗号化設定可。証跡管理可能。

・S3のオブジェクトをライフサイクル全体にわたり、コスト効率よく保存するためには、S3バケットのライフサイクルポリシーを使用し、ファイルをGlacierに転送する。

・S3ストレージクラスの中で、即時に取り出せるが、煩雑なアクセスはなく、高可用性と費用対効果の高い要件を満たすのは標準-IA。1ゾーン-IAはさらに低コストだが、可用性の面で標準-IAに劣る。

・署名付きURLは通常AWSへのアクセスを許可しない場合に、期間限定的にアクセス許可をする際に利用する。

・標準-IAは低頻度アクセス用だが、すぐに読み込みが可能かつ安価なため、重要なデータの保存にも適している。

・S3バケットのイベント機能を利用することで、Lambda関数と連携が可能となる。(ex.S3バケットにファイルがアップロードされたらイベント通知が発行され、Lambda関数を呼び出し、DynamoDBへデータ書き込み等)

・読み/書きトラフィックに対して、アクセスパフォーマンスを最大化する際、以前はプレフィックスの文字列をランダムにするといった対策があったが、現在はデフォルトの設定のままで問題はない

・Glacierのデータ最低保持期間は90日間のため、30日だけの場合はコストパフォーマンスは悪い

Redshift（データベース）

・列指向データベースは水平スケーリングが可能なため、低コストの分散クラスターを使用し、スケールアウトできる。ペタバイトクラスの構造化データウェアハウスとしてビッグデータ分析処理に最適。

・Redshiftは暗号化されたSSL接続を使用して、スナップショットをS3に保存可能。EBS同様、増分スナップショットを自動作成し、このスナップショットからクラスターを復元可能。このバックアップは残ってしまうため、保持期間を指定または削除が推奨される。

・プライマリクラスターがダウンした場合、すぐに利用できるようにするにはクロスリージョンスナップショットを利用する。（自動的に他リージョンへコピーされるよう設定）

S3に蓄積したデータをRedshiftと連携し、VPCのプライベートサブネット内でのデータ利用に限定したいという要件がある場合、以下をする

・Redshift拡張VPCルーティングの設定する
・S3にVPCエンドポイントからアクセスする

DynamoDB（データベース）

・フルマネージドによる高い拡張性、データへの1桁ミリ秒のレイテンシー、マルチリージョン/マルチマスターの高い信頼性を実現するNoSQLDBはDynamoDB。

・DynamoDBは、データベースとして、JSONドキュメントの保存、インデックスの可用性、Auto Scalingが必要な場合にも適している。

・DynamoDBのテーブルは、パーティションキー全体でアクティビティが均一になるアプリケーション設計をする。テーブルはスキーマを持たないため、開発の自由度があがる。また水平にスケールが可能。

・DynamoDBでThlottlingExceptionとLimitExceedExceptionのエラーが返されたときは、アプリケーションでリクエストを再試行することで解決できる。

・DynamoDBでは結果整合性に基づく処理をするため、多くのトラフィックを処理可能だが、一方それらの読み込みを可能にするため、古いデータの読み込みが発生してしまう。

DynamoDBに一時的なアクセス集中がある場合、以下の手段により、対応が可能

・SQSメッセージからDynamoDBに書き込みをするように連携
・DynamoDBに対してAutoScalingを適用

Route53（DNSウェブサービス）

・ブルーグリーンデプロイメントは、稼働システムと準備システムで本番系のトラフィックを切り替える方法で、重み付けで段階的移行が可能になる加重ルーティングが適切。

・複数リソースにDNSクエリのレスポンスを分散して返答する場合は複数値回答ルーティングを利用し、正常なリソースの値のみを戻すことができる。

・Route53のヘルスチェックはインターネット経由でアクセスできるエンドポイントに使用可能なため、オンプレミスからクラウド環境へのDNSフェイルオーバーとして、利用可能。

・エイリアスレコードを利用すると、DNSクエリに対して、AWSサービスのエンドポイントのIPアドレスを直接返すため、レスポンスがはやくなる。自動フェールオーバーのルーティングではCNAMEを利用する。

・サーバーごとに性能の偏りがある場合は、加重ルーティングで性能ごとに分配して振り分けができる。

SQS（メッセージキューイングサービス）

・新たにメッセージング機能アプリケーションを構築する場合は、SQSの利用が推奨されるが、既存のアプリケーションのメッセージング機能を移行する場合はAmazon MQを利用することが推奨される。

・一時的なトラフィック増として、スパイクが発生する処理では、SQSにキューを蓄積し、後続する処理ノードが順次処理する冗長構成をとることで、スパイクを吸収できる。

・SQSのキューをEC2で処理する場合で、EC2のAutoScalingを使用するケースとして、キューのサイズに基づくAutoScalingのターゲット追跡スケーリングを設定し、CloudWatchで監視するとよい。

・デフォルトオプションでSQS作成時、メッセージ保持期間は4日間。（1分～14日までで設定可能。）もしこの保持期間が過ぎていれば、メッセージは削除される。

・優先度付きキュー＝優先度の高きキュー/低いキューを用意し、クライアント側ではジョブの優先度でどちらのキューに登録するかを決め、ワーカー側では優先度の高いキューから優先的に実施する。

・可視化タイムアウトが設定されている場合、有効期限内はほかのワーカーでの処理はされないが、期限を過ぎたら、別のワーカーへうつる。

CloudFront（高速コンテンツ配信ネットワークサービス）

・CloudFrontキャッシュに保持する時間はTTL値で制御が可能。期間を長くすると、その間はオリジンにファイルを取りに行かないため、パフォーマンス向上とオリジンの負荷軽減になる。

・CloudFrontにおいて、S3バケットのコンテンツに対して、アクセスを制限するためには、Origin Access Identity(OAI)を作成し、S3バケット内のオブジェクトへのアクセスをそのOAIのみに許可する。=まずCloudFrontの署名付きURLまたは署名付きCookieを作成し、S3バケットのファイルへのアクセスを制限する。次にOrigin Access Identity(OAI)という特別なCloudFrontユーザーを作成して配布に関連付け、CloudFrontがOAIを使用することで、直接URLを使用してもファイルにアクセスできなくなる

・http://example.com/index?language=en のようなHTTP領域区別の場合、クエリ文字列パラメーター値に基づき言語決定する構成とすることで、地域ごとに言語を変えたWEBサイトの構成が可能となる。