S 3バケット暗号化によるKMSコストの低減

産業の維持の理由は、重要です

TLR

スケールで暗号化するとき、KMSの顧客管理されたキーは非常に高価でありえます.バケットキーを使用すると、コストを削減するKMSへの呼び出しを削減します.

バケットキーの実装は、1日あたり1500ドルからKMSリクエストにつき$ 300

私は、技術的な観点から他の人を助けるかもしれない物語を共有したいが、すべてが動いているからといって、すべての時間の既存のインフラストラクチャを改善し続ける理由がまだあるという考えを奨励することもできた.

You get an alert from your finance team. Last month's AWS bill had an unexpected spike in cost. You pull up cost explorer and immediately see the increase. When you dig in, you see a spike in the expenses to KMS. It crept up from the average of a few hundred to a few thousand dollars per day.

It's not the end of the world, but you need to figure it out. You'll investigate it when you have time between different projects.

A few days later, you get a message in Slack: "We're hitting our KMS limit in production."

If you've never looked, the default rate limit for symmetric cryptographic requests in KMS is 50,000 requests/second.

Your cost issue just became a production incident though.

事件自体はあまり重要ではありませんが、起こったことの発見は、ありました.

何が50000 KMSのリクエストを作っていた/秒？

KMSの監視は素晴らしいです.CloudWatchは、操作を分割しないので、ちょうどあなたの率を得ることができないkms:decrypt 呼び出し.The monitoring overview page of the KMS developer guide これについて簡単にヒントを示します.

AWS KMS API activity for data plane operations. These are cryptographic operations that use a KMS key, such as Decrypt, Encrypt, ReEncrypt, and GenerateDataKey.

それで、CloudWatchを見るとき、あなたはAを見ますCryptographicOperationsSymmetric メトリックアンダーAll > Usage > By AWS Resource .
幸いにも、我々はタイムフレームを持っていました:スパイクは、毎時、毎時、起こっていました.何もないアプリケーションでは、我々はCloudtrailログになって立っている.ログは、我々のデータウェアハウスである暗号化文脈で、我々のQuickSiteサービス役割からKMSへの異常な大量の要求を示しました.
それはしわを提示しました、我々は我々のSPICEデータセットの鮮度を維持するために必要でした、しかし、我々はオプションの方法であまり与えられませんでした.それで、チームはリフレッシュを広げることによって若干の緩和を実行することができました;我々はもうレート制限を打つ必要はありません.私たちはまだ何百万もの要求を見ていましたcurrent prices :

500,000,000 requests/day * $0.03 per 10,000/requests = $1,500 per day

バケットキー

2020年12月、アマゾンが導入S3 Bucket Keys . KMS(および関連費用)への要求を減らす方法として広告されます.
実装は簡単です.AWSでは、単純なチェックボックスです.

terraformでは、それを使用して同様に簡単ですaws_s3_bucket_server_side_encryption_configuration リソース

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.mybucket.bucket

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.mykey.arn
      sse_algorithm     = "aws:kms"
    }
    bucket_key_enabled = true
  }
}

上記の新しいオブジェクトの要求を解決しました.しかし、我々のデータウェアハウスの性質は、我々が全リフレッシュにセットされたデータ全体をフェッチしていたということでした、そして、バケツは古いキーで暗号化されたデータのテラバイトを含んでいました.この啓示は、我々がまだ何百万ものKMS要請を見ていたことを意味しました.AWSは、これを呼び出しますS3 Bucket Key documentation :

When you configure an S3 Bucket Key, objects that are already in the bucket do not use the S3 Bucket Key. To configure an S3 Bucket Key for existing objects, you can use a COPY operation

そこで、我々は数時間でデータを再暗号化するためにS 3バッチ操作を使用しました.効果はすぐに顕著だった.振り返ってみると、さらにはっきりしている.

結果

基本的に1行のコードの変更と簡単なバッチ操作で、我々は平均して、1日あたりの38 mリクエストに1日あたりの500メートルのリクエストから私たちのKMS要求を削減しました.この法案は同様の結果を示し、1日あたり1500ドルはKMSの要求で1日300ドルになった.

この物語は終わらない

製造事件は解決されました、会計は幸せです、しかし、物語は終わりません.
その物語は終わらない.
我々は継続的な改善のサイクルに住んでいます.
アマゾン、マイクロソフト、および他の産業が繰り返して、改善し続ける限り、それは彼らの知識を関連して、絶えず改善するために会社のエンジニアリングスタッフに落ちます.我々の実装と業界へのフィードバックは、次の大きなリリースフィード.
それは簡単な機能工場のモードには、そこにのみ新しいコードと機能を追跡する環境に入るに落ちるです.一歩を踏み出して、より大きな絵を時々考えることは不可欠です.どのように、あなたはそのCloudfront配布を作成したので、風景が変わりましたか?どのような新機能は、エンジニアリングの生産性と顧客の経験を改善するために活用することができますか?それは、これらの考えとアプローチでスタッフの残りを導くために、エンジニアリングリーダーシップに依存します.それは会社だけでなく、あなたも、あなたのエンジニア、他の人があなたの学習を共有する利益を得る.

参考文献

AWS S3 - Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys

Amazon S3 Bucket Keys reduce the costs of Server-Side Encryption with AWS Key Management Service (SSE-KMS)