AWS ソリューションアーキテクト アソシエイト コスト最適化の設計 問題

正解は Requester Pays を有効にし、認証付きのリクエストで取得してもらう構成です。S3 では通常、保管とデータ転送の料金はバケットの所有者が払いますが、Requester Pays を有効にしたバケットでは、リクエストとダウンロードの料金を取得する側のアカウントが払います。匿名のアクセスはできなくなり、すべてのリクエストに認証が要りますが、共同研究先はアカウントを持つので問題ありません。CloudFront 経由にしても、配信の料金を払うのはディストリビューションを持つ研究機関なので要件に合いません。S3 Glacier Deep Archive は保管の料金を下げますが、復元とデータ転送の料金は所有者側に残るので要件に合いません。S3 Transfer Acceleration は転送を速くする機能で、その料金はバケットの所有者にかかるので要件に合いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/RequesterPaysBuckets.html

正解は計測値を日ごとに大きなファイルへまとめてからアーカイブへ移す方法です。S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive へ移したオブジェクトには、1 件ごとに名前と索引のための管理用の容量が足され、その分も課金されます。また移すときは 1 件ごとに移行のリクエストの料金がかかるため、文書は小さいオブジェクトを少数の大きなオブジェクトにまとめることを勧めています。小さいまま S3 Glacier Deep Archive へ移す方法は、数十億件分の管理用の容量と移行のリクエストの料金がかさむうえ、1⁠2⁠8 KB 未満のオブジェクトは既定では移行されないので要件に合いません。S3 Standard-⁠IA は 1⁠2⁠8 KB 未満のオブジェクトも 1⁠2⁠8 KB として課金するので要件に合いません。S3 Intelligent-⁠Tiering は 1⁠2⁠8 KB 未満のオブジェクトを監視せず高頻度の階層に置いたままにするので要件に合いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-⁠transition-⁠general-⁠considerations.html

正解は Tape Gateway を置き、仮想テープを S3 Glacier Deep Archive にアーカイブする構成です。Tape Gateway はクラウドを裏に持つ仮想のテープの仕組みを提供し、既存のバックアップソフトウェアからはテープライブラリとして見えるので、テープを前提にした手順を変えずに使えます。アーカイブしたテープは S3 Glacier Flexible Retrieval か S3 Glacier Deep Archive に置かれ、長期の保管を低い費用で行えます。S3 File Gateway はファイル共有として見えるので、バックアップの宛先をテープから替える必要があり要件に合いません。DataSync で Amazon EFS へ複製する方法は、テープの手順が残るうえ、長期のアーカイブとしては保管の費用が高いので要件に合いません。Snowball Edge を毎月取り寄せる方法は、物理の運搬が残り、S3 Standard は長期の保管には高いので要件に合いません。出典 https://docs.aws.amazon.com/storagegateway/latest/tgw/WhatIsStorageGateway.html

正解は月ごとのスナップショットを EBS Snapshots Archive の階層へ移す方法です。EBS Snapshots Archive は、9⁠0 日以上保管し、めったに使わないスナップショットの保管費用を大きく下げるための階層です。移すと増分のスナップショットは完全なスナップショットに変わりますが、使うときは標準の階層へ戻してから通常のスナップショットと同じように扱えます。復元に時間がかかっても構わないという条件にも合います。古いものから削除する方法は、3 年間の保管の義務を守れないので要件に合いません。高速スナップショット復元は復元を速くする機能で、費用は下がらず増えるので要件に合いません。sc1 のボリュームとして残す方法は、保管の形がスナップショットでなくなるうえ、ボリュームの容量の全体に課金が続くので要件に合いません。出典 https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-⁠archive.html

正解は部署のプレフィックスごとに S3 Storage Class Analysis のフィルターを作る方法です。Storage Class Analysis は、バケットのデータへのアクセスの傾向を観察し、S3 Standard から S3 Standard-⁠IA へいつ移すとよいかを判断する材料を出します。フィルターはプレフィックスやタグで分けて作れ、フィルターごとに別の分析が得られるので、部署ごとにルールの日数を決められます。Cost Explorer は費用の推移を見るもので、オブジェクトがいつ読まれなくなるかは分からないので要件に合いません。一律で S3 Glacier Instant Retrieval へ移す方法は、傾向を調べる前に移してしまい、部署ごとのルールの日数を決める材料にならないので要件に合いません。AWS Budgets は費用が予算を超えたときに知らせるもので、アクセスの傾向は分からないので要件に合いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-⁠storage-⁠class.html

正解は NAT ゲートウェイを 1 つの AZ にだけ残し、全 AZ のルートを向ける構成です。NAT ゲートウェイは、使える状態にある時間ごとと、処理したデータの量に課金されます。3 台を 1 台にすれば時間あたりの料金は 3 分の 1 になります。ほかの AZ からの通信は AZ をまたぐデータ転送の料金がかかりますが、通信の量がわずかなので影響は小さく、AZ の障害で外へ出られなくなることも開発環境では許されています。NAT インスタンスに替える方法は、EC2 のパッチ当てや可用性の面倒を自分で見ることになり、運用の手間が増えるので要件に合いません。パブリックサブネットへ移す方法は、EC2 をプライベートサブネットに置くという条件に反するので要件に合いません。S3 のゲートウェイエンドポイントは S3 宛ての通信だけに効き、NAT ゲートウェイの台数は減らないので要件に合いません。出典 https://docs.aws.amazon.com/vpc/latest/userguide/nat-⁠gateway-⁠pricing.html

正解は 2 つの VPC のあいだに VPC ピアリング接続を作る構成です。VPC ピアリング接続は作るだけでは料金がかからず、同じ AZ の中に収まるデータ転送は無料です。AZ やリージョンをまたぐ転送には料金がかかりますが、この会社は送る側と受ける側を同じ AZ に置いています。VPC が 2 つだけで増やす予定もないので、多数の VPC をつなぐ仕組みは要りません。Transit Gateway は、アタッチメントごとの時間の料金に加え、送ったデータの量に応じた処理の料金がかかるので、毎日数 TB の通信では要件に合いません。Site-⁠to-⁠Site VPN は接続ごとの時間の料金がかかり、VPC どうしを直接つなぐ用途でもないので要件に合いません。インターネット経由にすると、パブリック IP を使った通信のデータ転送の料金がかかり、外へさらす経路も増えるので要件に合いません。出典 https://docs.aws.amazon.com/vpc/latest/peering/vpc-⁠peering-⁠pricing.html

正解は Site-⁠to-⁠Site VPN を作り、営業所のルーターと IPsec のトンネルでつなぐ構成です。Site-⁠to-⁠Site VPN は、VPC とオンプレミスのネットワークのあいだを、インターネット越しの IPsec で暗号化してつなぎます。1 つの接続には 2 本のトンネルが含まれ、専用の回線を引く工事が要らないので、すぐに使い始められ、量の少ない通信には固定の費用も抑えられます。Direct Connect の専用接続は、回線の手配に時間がかかり、使う量が少なくても接続の時間ごとの料金がかかるので要件に合いません。2 本引く方法は、さらに費用が増えるので要件に合いません。HTTP で直接使う方法は、通信が暗号化されず、社内システムを外へさらすことにもなるので要件に合いません。出典 https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html

正解は AWS Cost and Usage Report を作り、明細のファイルを S3 へ届けさせる方法です。Cost and Usage Report は、AWS の製品と使用タイプと操作の組み合わせごとに明細の行を持つ報告を作り、指定した S3 バケットへ少なくとも 1 日 1 回更新して届けます。Athena や Redshift で集計しやすい形で出す設定もできるので、自社の基準で集計したいという要件に合います。AWS Budgets は予算を超えたときなどに知らせるもので、明細のデータは届かないので要件に合いません。AWS Cost Explorer は費用の推移をグラフで見るための画面で、明細の行を S3 に受け取る用途ではないので要件に合いません。AWS Compute Optimizer はリソースのサイズを見直す推奨を出すもので、請求の明細は扱わないので要件に合いません。出典 https://docs.aws.amazon.com/cur/latest/userguide/what-⁠is-⁠cur.html

正解は使用量プランを作り、取引先ごとの API キーにスロットリングとクォータを設ける方法です。API Gateway の使用量プランは、API キーで呼び出し元を見分け、キーごとにリクエストの速さの上限と一定期間の回数の上限を設けられます。上限を超えた分は API Gateway で止まるので、Lambda と DynamoDB までリクエストが届かず、料金の膨らみを抑えられます。バックエンドのコードも変えずに済みます。Lambda の予約済み同時実行数を絞る方法は、取引先を区別せずに全体を絞るので、ほかの取引先にも影響が出て要件に合いません。DynamoDB をオンデマンドに替える方法は、急なリクエストをそのまま受けるので、料金はむしろ増えて要件に合いません。CloudFront で応答をキャッシュする方法は、取引先ごとの上限を設けられず、決済の応答を長く使い回すこともできないので要件に合いません。出典 https://docs.aws.amazon.com/apigateway/latest/developerguide/api-⁠gateway-⁠api-⁠usage-⁠plans.html

正解は休止 (hibernate) させ、使うときに起動してメモリの内容から再開する方法です。休止すると、インスタンスのメモリの内容が EBS のルートボリュームに保存され、起動するときにメモリの内容が読み戻されます。休止して停止している間はインスタンスの使用料はかからず、かかるのはメモリの内容の分も含めた EBS の保管の料金だけです。起動に時間のかかるアプリを温めたまま止めておく用途に向いています。停止させる方法は、料金は止まりますが、起動のたびに 4⁠0 分の読み込みが要るので、数分で再開する要件に合いません。常時起動のまま Reserved Instance を買う方法は、使わない時間のインスタンスの料金を払い続けるので要件に合いません。Spot Instance は中断されるとメモリの内容が失われ、読み込み直しが要るので要件に合いません。出典 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernate.html

正解はメモリ最適化 (R 系) の、必要なメモリを満たすより小さいサイズに替える方法です。メモリ最適化のインスタンスは、大きなデータをメモリの上で処理する用途に向けて作られ、vCPU の数に対してメモリの量が多い構成です。このアプリは CPU をほとんど使わずメモリだけを使い切っているので、vCPU を減らしてメモリを保てるメモリ最適化の小さいサイズにすれば、使わない CPU に払う分を減らせます。コンピューティング最適化をさらに大きくする方法は、使わない CPU が増えて費用が上がるので要件に合いません。ストレージ最適化は高速なローカルストレージに向けたもので、この使い方の不釣り合いを直さないので要件に合いません。コンピューティング最適化のまま世代を替える方法は、CPU とメモリの比は変わらず、大きいサイズのままになるので要件に合いません。出典 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-⁠optimized-⁠instances.html

正解は Application Load Balancer を 1 台にまとめ、パスのルールで各ターゲットへ振り分ける構成です。Application Load Balancer は動いている時間ごとに課金され、さらに使った処理の量に応じた料金がかかります。8 台を 1 台にまとめれば、時間あたりの料金は 8 台分から 1 台分になります。リスナーのルールでは URL のパスのパターンを条件にでき、パスごとに別のターゲットグループへ振り分けられるので、各サービスの中身は変えずに済みます。Network Load Balancer に替えても、サービスごとに置けば台数分の時間の料金は残り、パスで振り分けることもできないので要件に合いません。Gateway Load Balancer は仮想のアプライアンスへ通信を流すためのもので、この用途にも料金の削減にも合いません。Elastic IP で直接公開する方法は、ロードバランサー経由だけで公開するという方針に反するので要件に合いません。出典 https://aws.amazon.com/elasticloadbalancing/pricing/

正解は開発とステージングの DB を Single-⁠AZ の配置に変える方法です。Multi-⁠AZ の DB インスタンスの配置では、RDS が別の AZ に同期のスタンバイを自動で用意して保ちます。スタンバイは読み取りに使えず、障害に備えるためだけに動いているので、AZ の障害で止まってもよい環境では払う理由が薄い部分です。Single-⁠AZ にすればスタンバイの分がなくなり、エンジンとインスタンスクラスはそのままで費用を下げられます。リードレプリカを足す方法は、インスタンスが増えて費用が上がるので要件に合いません。Multi-⁠AZ の DB クラスターは読み取りもできるスタンバイを 2 台持つ構成で、費用は下がらないので要件に合いません。Aurora のグローバルデータベースはリージョンをまたぐ構成で、エンジンも替わり、費用も増えるので要件に合いません。出典 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html

正解は Aurora Serverless v2 にし、最小容量を 0 ACU にして自動で一時停止させる構成です。DB クラスターの最小容量を 0 ACU にすると、指定した時間のあいだ利用者の接続がなければ容量を 0 まで下げて自動で一時停止し、接続の要求が来ると自動で再開します。一時停止している間はインスタンスの容量の料金がかからないので、使われない時間が長い試験用の DB に向いています。再開には少し時間がかかりますが、最初の接続が待たされてよいという条件に合います。最も小さいプロビジョンドのインスタンスは、使っていない時間も起動している限り料金がかかるので要件に合いません。Reserved Instance は常に動かす前提の割引で、使わない時間の料金をなくせないので要件に合いません。Multi-⁠AZ の配置はスタンバイの分が増え、使わない時間も料金がかかるので要件に合いません。出典 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-⁠serverless-⁠v2-⁠auto-⁠pause.html

正解はプロビジョンドのキャパシティモードに替え、Auto Scaling で日々の波に合わせる方法です。プロビジョンドのモードは、1 秒あたりの読み書きの量を先に決めて、その容量に時間ごとに課金されます。文書は、量が安定していて伸び方が予測でき、必要な容量を確かに見積もれる場合に向くとしています。Auto Scaling を使えば、実際の量に合わせて容量が自動で上下するので、夜間の使わない容量に払い続けることも避けられます。グローバルテーブルで別のリージョンへ複製する方法は、複製の分の費用が増えるので要件に合いません。DAX は読み取りをキャッシュする仕組みで、書き込みは減らず、DAX のクラスターの費用も増えるので要件に合いません。Aurora へ移す方法は、アプリを SQL に合わせて作り直す必要があり、改修をしない条件に反するので要件に合いません。出典 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-⁠mode.html

正解は項目に有効期限の属性を持たせ、DynamoDB の TTL で期限切れを自動で削除させる方法です。TTL は項目ごとに有効期限の時刻を持たせる仕組みで、期限を過ぎた項目は、たいてい数日のうちに DynamoDB が自動で削除します。この削除は書き込みの容量を使わないので、削除のための費用がかかりません。バッチ用のサーバーも要らなくなります。Lambda に移す方法は、サーバーは要らなくなりますが、走査と削除で読み書きの容量を使い続けるので要件に合いません。S3 へ書き出してから消す方法は、書き出しの費用が増え、削除の容量も使うので要件に合いません。ElastiCache へ移す方法は、アプリの改修とキャッシュのノードの費用が要るうえ、夜間のバッチも残るので要件に合いません。出典 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html

正解は CTAS のクエリでログを Parquet の列指向の形式に変換し、変換後を問い合わせる方法です。Athena のクエリの料金は、クエリが読み取ったデータの量で決まります。CSV は 1 行ずつ全部の列を読むので、数列しか使わなくてもファイル全体を読みます。Parquet のような列指向の形式なら、クエリに要る列だけを読めるので、読み取る量が減って料金が下がります。変換は Athena の CTAS で行え、結果も変わりません。S3 Standard-⁠IA に替える方法は、読み取る量は変わらず、取り出しの料金も加わるので要件に合いません。EC2 で集計する方法は、サーバーの費用と手間が増え、Athena の料金を下げる話にもならないので要件に合いません。1 つの大きなファイルにまとめる方法は、CSV のままでは読む列を絞れず、読み取る量が変わらないので要件に合いません。出典 https://aws.amazon.com/athena/pricing/

正解は AWS SCT でスキーマを Aurora PostgreSQL 向けに変換し、AWS DMS でデータを移す方法です。AWS SCT は、あるデータベースのエンジンのスキーマを別のエンジン向けに変換する道具で、Oracle から Aurora PostgreSQL への変換にも対応しています。自動で変換できない部分は、手で直すための案内を出します。データは AWS DMS で移し、移行のあいだも変更を同期し続けられるので、切り替えの停止を短くできます。Aurora PostgreSQL には Oracle のライセンスが要りません。RDS for Oracle は管理は楽になりますが、Oracle のライセンスの費用は料金に含まれて残るので要件に合いません。EC2 のまま Reserved Instance を買う方法は、ライセンスの費用が残り、管理された DB にもならないので要件に合いません。Athena は分析用のクエリのサービスで、通販の業務の読み書きを担うリレーショナルデータベースの代わりにならないので要件に合いません。出典 https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html

正解は EventBridge Scheduler で Fargate のタスクを毎日起動し、終われば止まるようにする構成です。EventBridge Scheduler は、cron や rate の式で決めた時刻に Amazon ECS のタスクを起動できます。Fargate で動かせば、サーバーを管理せずに、タスクが動いている間の計算の資源だけに料金を払うことになります。コンテナにまとめた処理をそのまま動かせる点も合います。Lambda は 1 回の呼び出しの実行時間の上限が通常 1⁠5 分で、2 時間の処理は動かせないので要件に合いません。Reserved Instance は単価を下げますが、処理のない 2⁠2 時間も料金を払い続け、サーバーの管理も残るので要件に合いません。Auto Scaling グループで最小 1 台にする方法は、常に 1 台が動き続けるので、動いている間だけ払う要件に合いません。出典 https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tasks-⁠scheduled-⁠eventbridge-⁠scheduler.html