Store-Backedインスタンスは揮発性のためインスタンス停止時にはデータが削除される。Scaling)高可用性、高パフォーマンスの面で重要。単一障害点をどうやって無くすかというプラクティス、EC2を複数台にしてELBをその前段に置きがち。大事なこと、ELBはAWSのマネージドサービスなのでAWS内で十分冗長化されており単一障害点にはなり得ない。基本的にALBの方が後発な分、安価で機能も優れている。NLBはHTTP(S)以外のプロトコル通信での負荷分散に用いる。Scalingはスケールアウトに数分かかるため、スパイク的なアクセスは対応不可です。単一障害点を作らない意味で、作られるインスタンスは複数のAZに配置するべき。コスト最適化の大事な話インスタンスの課金形態が時間性なので、利用時間を課金が発生する時間未満に収めることができれば安く済む。AutoScalingの終了ポリシーを制するものはコスト最適化を制するスケールインの際の終了ポリシーは開発者が定義できるが、デフォルトの終了ポリシーの動作は以下の通り。終了するオンデマンドまたはスポットインスタンスの配分戦略に残りのインスタンスが合うように、終了するインスタンスを決定する。グループにのみ適用される。どのインスタンスが最も古い起動テンプレートまたは起動設定を使用しているかを判断する。上記のすべての基準を適用した後で、終了する保護されていないインスタンスが複数ある場合は、どのインスタンスが次の課金時間に最も近いかを判断する。次の課金時間に最も近い保護されていないインスタンスが複数ある場合、これらのインスタンスのいずれかをランダムに終了する。この配分戦略もしっかり抑えておきたい。AutoScalingの細かい挙動は結構問われるイメージ。リザーブドインスタンスはAutoScalingの対象外であることオンデマンドとスポットを混合したAutoScalingを設定できることあらかじめスケジュール設定されたAutoScalingも設定できることも重要な点です。スケジュールされたAutoScalingも設定できるので、例えば、夜間はほとんどアクセスが無いが、始業時間になるとアクセスが増える業務系のアプリケーションでもAutoScalingを活用することでコスト最適化できる。開発者がカスタマイズできる終了ポリシーは以下の通り。OldestInstanceグループ内の最も古いインスタンスを削除します。NewestInstanceグループ内の最も新しいインスタンスを削除します。OldestLaunchConfiguration最も古い起動設定のインスタンスを削除します。ClosestToNextInstanceHour次の課金時間に最も近いインスタンスを削除します。コスト最適化Defaultデフォルトの終了のポリシーに従って、インスタンスを終了します。OldestLaunchTemplate最も古い起動テンプレートを使用するインスタンスを終了します。配分戦略に合わせます。チェックポイントOldestInstanceも一見コスト最適化しそうだが、古いからと言って、次の課金時間に最も近いとは限らないのがポイント。1番古いインスタンスが直前に課金時間の閾値を超えてしまったケースなどがそれ。size)に0を指定できる。Lambdaは、サーバーレスアーキテクチャの中核を担う存在で、疎結合で高可用性に富んだアーキテクチャを導入できる。ここでは試験対策(主にコスト最適化)として料金体系について以下2点がLambdaに対して課金される項目。コールドHDDで、弱い方が安いです。価格とパフォーマンスのバランスが取れたSSDボリュームブートボリュームやインタラクティブで低レイテンシーのアプリケーション向けスループット最適化HDD高いスループットを必要とするアクセス頻度の高いワークロード向け低コストビッグデータ、データウェアハウス、ログ処理向けコールドHDDアクセス頻度の低いワークロード向け極めて低コストアクセス頻度の少ないコールドデータ向けまた、EBSはデータボリューム、ブートボリューム、およびスナップショットがシームレスに暗号化される。Glacier)イレブンナイン(99.999999999%)の堅牢性を誇るAWSの有名なストレージサービスAWSのマネージドサービスのため単一障害点にはなり得ない(※他にもELBやSQSなど、マネージドサービスと呼ばれるものはAWS内部で冗長化されているため単一障害点にはなり得ない)S3のデータはリージョンに配置されるので、同一リージョン間で同じパケット名は付けらない(はず)。https://aws.amazon.com/jp/s3/storage-classes/ちなみに、2018年にGlacierがS3の一部となりました。Archiveで良かったり。「即座ではない」ならGlacierが視野に入るはず。S3の整合性についてS3は結果整合性方式を採用しているため、同時にPUTとGETのアクセスなどをするとたまに整合性が合わない結果になることがある。Associateの範疇外だが、この結果整合性に対しての操作は開発者が開発しているアプリケーションでケアする必要がある。データ整合性モデル小ネタS3はオブジェクトのキー(name)の先頭からインデックスをかけるためその昔、S3のパフォーマンス向上テクニックとして、「ランダムなハッシュ値4桁を頭につける」ってのがあったのですが、現在は日付順の名前を使用できるようになったそうなので、不要なテクニックになったようです。最新のS3のパフォーマンス最適化に関する情報については、パフォーマンスガイドラインパフォーマンス設計パターンをウォッチしておくと良さそうですRedshift厳密には、ストレージサービスというよりは、DWH(データウェアハウス)と呼ばれるようなデータ分析するためのデータのため場所、データレイクに用いるサービスです。Web系のアプリケーションエンジニアは普段業務などでRedshiftを使わない人が多いんじゃないかと思いますが、そこそこ問われるイメージ。Redshiftは、フルマネージドサービスでデータウェアハウスやデータレイクにあるペタバイト規模の構造化データと半構造化データを、標準的なSQLを使用してクエリすることができます。JSONなどの半構造化データも扱えるのがポイント。キーワードは「列指向型データベース」Redshiftの最大の特徴でもあり、よく選択肢に絡んでくる印象。これによりデータの持ち方が異なるRDSにはできない手法でのデータ分析を高速化できる。SAAでよく問われるのは間違いなくAuroraについてだと思う。(AWSが独自開発したこともあり、推していきたいのかな)ここは特にAuroraに特化したことについてまず、AuroraはMySQLとPostgreSQLとの互換性があり、MySQLの最大5倍、PostgreSQLの最大3倍高速パフォーマンスの問題であればだいたいAuroraに置き換える選択肢が入ってきそうまた、S3への継続的なバックアップ、3つのAZ間でのレプリケーションにより、優れたパフォーマンスと可用性を発揮することも抑えておきたいAuroraはフェイルオーバー時間についても明記されており、普通30秒未満で完了するようですDynamoDB非リレーショナルデータベース(NoSQL)で問われやすいのはこちらもAWS独自のサービスであるDynamoDBだと思う。お仏壇に置きたいお菓子は「チーズアーモンド」です。upLoginユーザーは見つかりませんでした。