Faqs

EC2サービスは、おそらくAWSでのクラウドの旅で最初に選ぶものの1つでしょう。60以上のインスタンスタイプがあり、最適なものを選ぶのは至難の業です。まずは、インスタンスの目的を考えてみてください。それを元に、以下の表を見て最適なタイプを絞り込むことができます。

ライトサイジングとは、性能要件を満たした上で、最も安価なオプションを選択することであることを忘れないでください。経験則では、長期間にわたってインスタンスのリソース使用率が80%になるようにすることです。

技術は止まらず、CPUメーカーはほぼ毎年、より高性能で消費電力の少ないCPUを発表し、AWSもそれを実装しているので、必ず定期的にインスタンスタイプ表に戻ってくることです。例えば、10台のインスタンスをc4.xlargeからc5.xlargeに変更するだけで、年間約2,500ドルの節約になり、同時に各インスタンスに多くのRAM（16 -> 20GB）と約5％の性能向上を実現します。

このヒントは、AWS Compute Optimizerを確認することです。このツールは、このタイプの変更をアドバイスすることができます。

通常、AWSユーザーはEC2インスタンスを新規にセットアップする際に、EBSストレージ（つまりディスク）に注目することになります。それらのディスクは、インスタンスにアタッチしたり、インスタンスからデタッチしたり、データ保護のケースでスナップショットしたりすることができます。インスタンスが停止しても、データはディスク上に残り、どこにも行きません。

もう1つ、検討する価値のあるオプションがある。EC2インスタンスストアを経由してローカルディスクを使用します。これらのディスクの大きな違いは、対応するインスタンスが停止されると、ディスクがクリーニングされることです。ユーザーはインスタンスの使用料のみを支払っているため、「無料」です。

貴重なデータにローカルディスクを使いたくないのは理解できるが、キャッシュやログなどの一時的なデータにはぴったりなケースもあります。また、下敷きのストレージは高速なSSD、あるいはNVMeなので、十分なパフォーマンスがありますので安心ください。EC2インスタンスストアを利用することで、EBSの消費量も少なくなり、月々の請求額も小さくなります。

スポットインスタンスのコンセプトは、パブリックマーケットと比較するとよく理解できます。価格は、利用可能な未使用のAWS EC2容量の供給と需要に基づいて変動します。AWSユーザーはそこに行き、希望する価格を入札することができす。もし需要がそれほどなければ、市場は一時的に低い価格で売ることに同意し、結果として通常価格の3倍から6倍の値下げをすることになります。

では、何が問題なのか？需要が高まる瞬間には、必要な資源を受け取れないかもしれない。価格がその希望する上限を超えると、プロビジョニングされたインスタンスは短期間で自動的に終了してしまいます。もちろん、重要なデータをこのような変動にさらしたいと思う人はいないでしょう。しかし、このモデルがうまく機能するケースも多くあります。ロードバランサーの背後にあるメディアレンダリング、ビッグデータ、分析、Webサービスなども、この機能の最初の候補の1つになるはずです。

例えば、ここにノースバージニア地域のスポットインスタンスの価格履歴があります。過去3ヶ月間のt2.largeインスタンスの需要と価格設定が示されています。

上の表からわかることは：

●実質的な価格はオンデマンドの3分の1程度になる可能性がある
●6つのAZはすべて、平等ではないものの、余裕のあるキャパシティを持っている
●価格が安定しないので、最低料金で入札しない

この技術をアクティブなCloudWatchとAuto Scalingで補完すれば、2分間の終了アラートを受信した時点で、システムは負荷をリバランスし、オンデマンドインスタンスに切り替わることができます。

AWSのネットワークは独自の論文に値するものですが、物事をシンプルに保つために、あまり深入りせず、とにかくここでいくつかの重要なヒントに触れておくべきだと思います。

オンプレミスサイトとAWSの間で大量のトラフィックがやり取りされる場合、Direct Connection機能を使えば、より安定したネットワーク体験、帯域スループットの向上、接続の安全性を確保することができます。

静的コンテンツ（画像、動画、音楽など）は、S3とCloudFrontの組み合わせでより良く、より安価に配信することができます。世界の様々な地域にある素晴らしいエッジサーバーのセットで、エンドユーザーはより近い場所にあるサービスキャッシュから来るデータを得ることができます。

異なるAWSサービス間のトラフィックフローを分析する。VPCからS3のような他のサービスへのトラフィックがエンドポイントを経由するようにVPCエンドポイントを構成することで、インターネットや公共ネットワークをバイパスし、より安全で安価な接続を実現します。

可用性ゾーン間のトラフィックについても、別の費用がかかるので、忘れないようにしましょう。フォールトトレランス・アーキテクチャを再考してください。すべてのサービスに必要でない場合もありますし、他の技術で実現できる場合もあります。

AWSのサービスの価格は、データセンターが置かれている物理的な場所に依存することに気づくのは簡単です。これは当たり前のように聞こえるかもしれませんが、理にかなっている場合は価格の安いリージョンにリソースを移行してください。

現在の価格を計算して、小さな例を紹介しましょう。ヨーロッパでt3.2xlargeインスタンスを10台、それぞれ150GB SSD gp2のディスク容量で稼働させる必要があるとします。ドイツ・フランクフルトのデータセンターを選択した場合、AWSのコンピュート利用料金は0.5312ドル/時間、一方スウェーデン・ストックホルムのデータセンターでは0.4928ドル/時間となる。さらに、ストレージコストとして1GB/月あたり$0.119 vs $0.1045を加え、1年間運用します。この差は、同じサービスであれば、24*365*10*$0.0384+$0.0145*1,500GB*12m = $3,364 + $261 = $3,625 の年間コストダウンに相当し、単に安い地域を選択したことになるのである。

これは、価格の高い地域をすべて、一度に捨てなければならないということなのでしょうか？そうとは限りません。先ほども言ったように、意味があるときにやればいいのです。アジアで事業を展開し、ユーザーに最も低いレイテンシーを提供しようとする場合、アプリケーションを米国に移動させる理由はないでしょう。ただし、負荷の低いサービスや静的なコンテンツについては、米国に移すことも可能です（詳しくは後述します）。もうひとつ注意しなければならないのは、個人情報の取り扱いです。GDPR（一般データ保護規則）やCCPAのような世界的な規制が障害となる可能性があります。

パブリッククラウドの柔軟性、CAPEXからOPEXへの移行が言われていますが、請求書を減らすAWSの機能であるRI（Reserved Instances）や節約プランなどは、皮肉にもCAPEXに戻るように見えてしまうものです。しかし、実際に50%以上の割引が得られるのですから、誰もが「導入のベストプラクティス」リストに挙げるべきでしょう。
まずは、EC2インスタンスの時間単価の割引とオプションの容量予約を提供するRIを検討することから始めましょう。1年または3年のコミットメントと引き換えに、インスタンスコストの割引を受けることができます。オンデマンドインスタンスは、無制限の柔軟性を持ってワークロードをプロビジョニングすることを好む人にとって良い選択肢となる。しかし、負荷が予測可能なワークロード（Webサービスなど）を常時稼働させる場合は、RIの方がはるかに優れています。

節約のまとめ。
• 予約時間が長いほど、割引率がアップします。
• 前払い金額が多いほど割引率が高くなる（ただし、前払い金0円も可能）
• 標準クラスはコンバーチブルより安い（ただし、インスタンスタイプは作成後に変更できない）

コンバーチブルインスタンスは、サイズダウンやAWS Marketplaceでの販売ができないため、注意が必要です。最小のインスタンスから始め、必要に応じてアップグレードすることで、最大36ヶ月間の月々の支払いを約束させられることを避けることができます。

Azure のデータを保護するためには、Azure を意識した最新のバックアップソリューションを使用することが重要です。主にオンプレミス用に設計されたレガシーバックアップツールは、Azureデータの一部を保護できるかもしれませんが、すべてのデータを保護することはできない可能性があります。例えば、サーバーレスデータベース内にデータがある場合、レガシーバックアップアプリケーションでは、おそらくそのデータをバックアップすることはできないでしょう。

レガシーバックアップツールでは、バックアップデータを保存するためのオプションが制限されている場合があります。例えば、特定のワークロードをクラウド上で実行することを意識的に決定した場合、そのワークロードのバックアップを構内に保存することは意味をなさないかもしれません。しかし、レガシーバックアップツールの中には、クラウドベースのバックアップターゲットを使用するオプションがないものもあります。

Microsoftパートナーのクライムが提供するAzure対応ソリューション

バックアップの自動化には、さまざまな形態があります。例えば、特定の時刻にバックアップを実行するようにスケジュールを組むといった簡単なものです。しかし、最新のバックアップソフトウェアでは、バックアップのスケジューリング以外の自動化も可能です。これまでITプロフェッショナルは、バックアップを作成するだけでなく、バックアップに関連する様々なタスクに対処しなければなりませんでした。しかし、今日ではこれらのタスクの多くを自動化することができます。例えば、バックアップのライフサイクル管理やバックアップのテストを自動化することができます。

Azureのバックアップストレージのオプションを評価するとき、必然的にストレージ階層を選択する必要があります。利用可能な階層は、コスト、可用性、およびパフォーマンスに関してかなり異なっています。パフォーマンスの高いストレージ層は、一般的にコストが高くなります。

バックアップの保存期間によっては、ギガバイトあたりのコストが最も低い階層が、必ずしも全体のコストを低く抑えられるとは限らないことに留意する必要があります。これは、Cool Tier の最低データ保存期間が 30 日間であるのに対し、Archive Tier の最低保存期間が 180 日間であるためです。つまり、これらの階層にデータを保存する場合、実際にはそれほど長期間バックアップを保持する必要がない場合でも、少なくとも最低期間データを保存するために費用を支払うことになります。

バックアップを保護するために組織ができる最も重要なことの1つは、バックアップをオンラインで維持しないことです。ランサムウェアの亜種は、特にバックアップサーバーをターゲットに設計されているため、被害者は身代金を支払う以外に選択肢がありません。以前は、テープは、空隙のあるバックアップを作成したい組織にとって、最適なメカニズムでした。バックアップが作成されると、テープはテープドライブから取り外されるだけでよかったのです。しかし、クラウドバックアップの場合、テープという選択肢はありません。Azureのアーカイブ層はオフラインに保たれ、レイテンシは2時間です。また、クラウドストレージへのアクセスは、多要素認証を使用したアカウントに限定することもできます。これにより、犯罪者が漏れたパスワードや総当たりパスワード攻撃でバックアップにアクセスすることを防ぐことができます。

クラウドバックアップの設置場所は重要です。ハイブリッド/マルチクラウドのサポートに関するビジネス要件は増加傾向にあり、特定のクラウドベンダーの選択と離脱の両方に関して、柔軟性が重視されています。

そのため、共通のコントロールペインとポータブルなバックアップフォーマットが可能なバックアップソリューションが必要とされています。これにより、異なるプラットフォーム間でデータを移動することが容易になります（オンプレミスからクラウドへ。クラウドからオンプレミスへ、クラウドから別のクラウドへ）、プラットフォームのロックインを回避することができます。

現在、多くの企業が複数のバックアップ製品を使用しています。オンプレミスのリソースを保護するために1つのバックアップツールを使用し、Azureにあるリソースを保護するために別のツールを使用している場合があります。可能であれば、バックアップ操作を1つのバックアップツールに統合するのがベストです。これにより、バックアップのサイロ化を解消し、クラウドと自社データセンター間でシームレスにデータを移動させることができます。同時に、単一のバックアップソリューションを使用することで、バックアップオペレーションを大幅に簡素化し、ライセンスコストを削減し、組織のデータ保護戦略におけるギャップの可能性を低減することができます。

災害がどのような規模で発生し、どのようなシステムに影響が及ぶかを予測することは不可能です。そのため、バックアップソリューションでは、データを異なるシステムやクラウドにリストアできることを確認することが重要です。また、精度の高いリストアが可能であることも重要です。例えば、仮想マシンの場合、仮想マシン全体をリストアできる必要がありますが、仮想マシン内の1つのファイルも同様に簡単にリストアできる必要があります。

AWSのネットワークは独自のものですが、物事をシンプルに保つために、あまり深入りせず、とにかくここでいくつかの重要なヒントに触れます。

１）オンプレミスサイトとAWSの間で大量のトラフィックがやり取りされる場合、Direct Connection機能を使えば、より安定したネットワーク体験、帯域スループットの向上、接続の安全性を確保することができます。
２）静的コンテンツ（画像、動画、音楽など）は、S3とCloudFrontの組み合わせでより良く、より安価に配信することができます。世界の様々な地域にある素晴らしいエッジサーバーのセットで、エンドユーザーはより近い場所にあるサービスキャッシュから来るデータを得ることができます。
3)異なるAWSサービス間のトラフィックフローを分析する。VPCからS3のような他のサービスへのトラフィックがエンドポイントを経由するようにVPCエンドポイントを構成することで、インターネットや公共ネットワークをバイパスし、より安全で安価な接続を実現します。
4)可用性ゾーン間のトラフィックについても、別の費用がかかるので、忘れないようにしましょう。フォールトトレランス・アーキテクチャを再考してください。すべてのサービスに必要でない場合もありますし、他の技術で実現できる場合もあります。

組織内で複数の人がAWSを操作する必要がある場合、統合課金によって支払いが簡単になるだけでなく、ある閾値に達すると、S3などの消費リソースを割引くことができます。また、AWSのティアによっては、使用量が多いほど価格が下がったり、事前にインスタンスを購入することで割引が適用されたりするものもあります（上記のRIやSaving Plansのようなもの）。さらに、未使用のリソースは、ある子アカウントから別の子アカウントに再配布することができます。ここで先に述べたコスト最適化ツールを適用し、多数のアカウントを運用する際の組織の混乱を防いでください。

AWS Cost Explorerは、すべてのお金がどこに行くのかを可視化し、最も消費されるサービスに対応することが非常に簡単にできるため、あなたの頼りになるはずです。これは、実施された分析に基づいて、興味深いパターンを特定し、根本的な原因まで掘り下げることができます。

コストエクスプローラー インスタンスタイプの消費を表示

AWS Compute Optimizerは、アカウント（またはマスター1つ下のすべてのアカウント）に対して収集され分析されたデータに基づいて、AWSリソースの最適化の機会の概要を提供します。

AWS Compute Optimizer：EC2インスタンスに対する推奨事項。

AWS Pricing Calculatorは40以上のAWSサービスに対するアカウント支出を見積もることができるツールです。しかし、時には他の競争戦略を決定するのに非常に役立つことがあります。例えば、オンデマンドEC2インスタンスからRIやSavings Planのオファリングに切り替える場合、各機能が提供する割引を確認することができる。表に値が追加されるたびに、結果的に計算が表示され、実際のサービスを選択するのに役立ちます。

アイドル状態のリソースは、AWSの請求書の大きなコスト要因になり得ます。未使用のインスタンスやデータベースをアイドル状態にしておくことは、使用されていないものに対して料金を発生させることを意味します。例えば、平日の日中しかアクセスしない開発環境がある場合、24時間365日稼働させないことが最良の選択です。夜間に停止し、翌朝と週明けに起動する（ヒント：Auto Instance Schedulerを参照）ことで、コストをほぼ半分に抑えることができます。また、Amazon CloudWatchのアラームを有効にして、指定期間以上アイドル状態だったインスタンスを自動的に停止または終了させるのも良い戦略です。

Amazon CloudWatch diagram

S3のマルチパートアップロード機能は、デフォルトで有効になっており、大きなオブジェクトを論理的な部分に分割して並行してアップロードすることで、アップロードを高速化します。問題は、これらのアップロードが何らかの理由で終わらない場合です。アップロードが完了しないデータはバケットに表示されず、自動的に削除されることもないので、毎月の請求額が大きくなる場合を除いては、特に気にする必要はないでしょう。これを防ぐには、「バケット管理」の設定で、新しいライフサイクルルールを作成し、「不完全なマルチパートのアップロードをクリーンアップする」オプションを有効にしてください。

ライフサイクルポリシーといえば、AWS S3を使って運用する際には必ず必要なものです。とはいえ、ライフサイクルポリシーを実装するには、インフラ上で有効にする前に、ある程度の学習とドキュメントを読むことが必要です。

ポリシーは、使用パターンが明確に定義されたオブジェクトに対するルールの組み合わせなので、以下のことが可能です。

●ライフサイクル・ルールを使用して、オブジェクトをそのライフタイムを通じて管理する。
●階層型ストレージへの移行を自動化し、コスト削減を図る
●保管の必要性やサービスレベルアグリーメント（SLA）に基づき、オブジェクトを失効させる。

これは、適切に設定すれば非常に強力なツールです。S3ストレージクラスの違いを学び、より組織のニーズに合うようにライフサイクル・ルールに慣れることです。

ライフサイクルルールの作成

AWSは、パフォーマンス、可用性、耐久性の要件を満たすように設計された複数のストレージ階層を、異なる価格で提供しています。提供されるストレージサービスは、大きく3つに分類されます。オブジェクトストレージ、ブロックストレージ、ファイルストレージです。Amazonが提供するオブジェクトストレージ、Simple Storage Service（S3）は、3つのストレージカテゴリの中で最もコスト効率が高いです。Amazon S3内では、さらに先のストレージクラス間でデータを簡単に移動させ、アクセス頻度と価格のバランスを取りながら、ストレージコストを最適化することができます。すべてのストレージタイプで利用シーンが異なり、その価格設定も様々です。

AWS S3ストレージクラス部分比較

ここでの賢い方法は、タスクの種類、オブジェクトの性質、アクセス頻度に応じて、それらを組み合わせることです。目的のS3バケットをクリックし、「管理」→「分析」を選択し、「ストレージクラス分析」を追加すると、アクセスパターンを確認するのに便利です。One Zone-IAやS3 Glacierへの移行を推奨するものではありませんが、データをより深く可視化することができます。

S3 バケット・ストレージ・クラス分析

新規者についてもしっかり検討しましょう。S3 Intelligent Tiering。少額の追加料金で、アマゾンは自動的にアクセスデータのパターンを検出し、オブジェクトの人気度に応じて、標準的なアクセスと不定期なアクセスの2つの層の間でそれらを移動させます。人気のないオブジェクト（連続30日間アクセスされていないもの）は、アクセス頻度の低い階層に移動され、要求があれば後で戻されます。この仕組みでは検索料がかからないため、オブジェクトは永遠に行き来することができます。実際のシナリオでは、20%の節約になります。このような監視のための費用を支払うことで、理論上は部分的に低くなりますが、それでも見逃すにはあまりに魅力的だからです。S3 APIまたはCLIを使用してストレージクラス “INTELLIGENT_TIERING “を指定するか、ライフサイクルルールを設定することでこの技術を有効にすることができます。

しかし、これはすべてに有効なわけではないです。128KB未満のオブジェクトは、インフリークエントアクセス層に移行されることがないため、フリークエントアクセス層の通常料金で課金されることになります。また、30日未満のオブジェクトは、最低30日間課金されるため、この方法は使えません。

バックアップソリューションが複雑でなければないほど、必要なときに動作する可能性が高くなります。複雑すぎるバックアップソリューションは、ヒューマンエラー、誤った設定、パッチのリリースに伴う互換性の問題が発生しやすくなります。そのため、シンプルな管理インターフェイスを持つだけでなく、エージェントを必要とせず、実際のデータ保護プロセスを簡素化するソリューションを探すとよいでしょう。つまり、管理者が新しいワークロードごとに手動でエージェントを展開したり、自動化スクリプトを書いたりする必要がなく、あらゆる規模の環境に対して拡張できるソリューションを探すということです。

クラウドサービスプロバイダーは当初から、コストのかかるオンプレミスでのIT運用に代わる安価な選択肢として、パブリッククラウドを販売してきました。しかし、実際には、Azureやその他のクラウド環境での運用は、オンプレミスでのワークロードの維持と同じくらいコストがかかることがよくあります。

Azureのデータをバックアップする場合、IT担当者がコストを抑制するために留意すべき点がいくつかあります。まず、効果的なデータライフサイクル管理ポリシーを持つことが必要です。このようなポリシーは、バックアップされるデータの量やバックアップ自体のサイズを制限するのに役立ちます。第二に、構内や他のクラウド環境に存在するバックアップターゲットの使用には注意が必要です。マイクロソフトは、Azureクラウドからデータを取り出す際にデータ取り出し手数料を契約者に請求しており、この手数料は大きなデータセットではかなり高額になる可能性があります。

クラウドでのコスト管理の複雑さを考えると、バックアップベンダーはクラウドでのデータ移動のニュアンスを意識したバックアップコスト計算とデータ管理ツールを内蔵していることが重要です。

Azureのバックアップ戦略を策定する最初のステップは、実際にバックアップする必要があるのは何なのかを把握することです。つまり、データがAzureクラウド内のどこに存在し、そのデータを保護するために何が必要かを決定することです。Azureのデータは、仮想マシンやAzure SQLのようなマネージドサービスなど、さまざまな場所に存在する可能性があります。また、データが複数のリージョンに分散している可能性もあります。

パブリッククラウドの柔軟性とCAPEXからOPEXへの移行について紹介しますが、請求書を減らすAWSの機能であるリザーブドインスタンス（RI）と節約プランのいくつかは、皮肉にもCAPEXに戻るように見えます。しかし、実際に50%以上の割引が得られるのですから、誰もが「導入のベストプラクティス」リストに挙げるべきものでしょう。

RIは、EC2インスタンスの時間単位の割引料金とオプションの容量予約を提供するもので、まずRIを検討することから始めます。1年または3年のコミットメントと引き換えに、インスタンスコストの割引を受けることができます。オンデマンドインスタンスは、無制限の柔軟性でワークロードをプロビジョニングしたい人には良い選択肢です。しかし、負荷が予測可能なワークロード（Webサービスなど）を常時稼働させる場合は、RIの方がはるかに優れています。

AWSのコスト最適化モデルを最大限に活用するために適切な計画を立てるヒントなどを特集しています。

https://www.climb.co.jp/faq/faq-category/aws-cost

Azure バックアップのための実践的なヒントとチェックリスト集です。

https://www.climb.co.jp/faq/faq-category/Azure-backup

EC2サービスは、おそらくAWSでのクラウドの旅で最初に選ぶものの1つだろう。60以上のインスタンスタイプがあり、最適なものを選ぶのは至難の業です。まずは、インスタンスの目的を考えてみてください。それを元に、以下のリストを見て最適なタイプを絞り込むことができます。

使用ケース |汎用機、計算、ストレージ、ネットワークでバランスが取れている必要がある
例 | Apache、NGINX、Kubernetes、Docker、VDI、開発環境など。
好ましいインスタンスタイプ｜T3

使用ケース |高性能CPUの恩恵を受けるコンピュートバインドアプリケーション
例 | 高性能ウェブサーバー、拡張性の高いマルチプレイヤーゲーム、動画エンコーディングなど
好ましいインスタンスタイプ｜C4、C5

使用ケース |大容量のデータセットをメモリ上で処理するアプリケーション
例 | 高性能データベース（SAP HANAなど）、ビッグデータ処理エンジン（Apache SparkやPrestoなど）、ハイパフォーマンス・コンピューティング（HPC）など
好ましいインスタンスタイプ｜X1およびR5

使用ケース |浮動小数点数の計算、集中的なグラフィックス処理、またはデータのパターンマッチング
例 | 機械学習/深層学習アプリケーション、計算金融、音声認識、自律走行車、または創薬
好ましいインスタンスタイプ｜G4、F1、P3

使用ケース |大量のシーケンシャルリード/ライト操作、または大規模なデータセットの処理
例 | NoSQLデータベース（例：Cassandra、MongoDB、Redis）、スケールアウト・トランザクション・データベース、データウェアハウス
好ましいインスタンスタイプ｜D2とi3

ライトサイジングとは、性能要件を満たした上で、最も安価なオプションを選択することであることを忘れないでください。経験則では、長期間にわたってインスタンスのリソース使用率が80%になるようにすることです。

AWSスナップショットとは、EC2インスタンスやEBSボリュームなどのリソースのイメージコピーで、AWSアカウント内のオブジェクトストレージに保存される。フルまたはベースラインスナップショットは、保護されたリソースの単一時点からの同一コピーである。最初のスナップショットが作成されると、それ以降の増分スナップショットには、最後のスナップショットが取得された後に変更されたすべてのブロックが含まれるようになります。

AWSスナップショットは完全なコピーであるため、破損または削除されたリソースを復元するために使用することができ、一般的にプライマリコピーが破損した場合、ITが最初に検索するものです。例えば、EC2インスタンスやEBSボリュームが破損しても、スナップショットには影響しないので、チームは簡単に復旧することができます。

これは、AWSスナップショットがバックアップのための理想的なデータソースであることを意味します 。 それは、異なるシステムに格納されているデータの独立したコピーを提供します。そらは、AWSで損傷したリソースを回復するための最も簡単で迅速な方法であり、シンプルでスピーディな災害復旧のための素晴らしいリソースを示しています。

<<続き>>

https://www.climb.co.jp/faq/faq-category/aws-snapshot

クライムAWSソリューション群

効果的なバックアップとリカバリのシステムは、バックアップの古典的な3-2-1ルールに従っています – データのコピーを少なくとも3つ、少なくとも2つの異なるタイプのメディアに保存し、そのうち1つはオフサイトに保存します。

2つの異なるストレージシステムにデータを保存することは、プライマリシステムがダウンした場合にコピーが破損しないようにするためのリスク管理戦術です。このため、常に別のバックアップシステムを持ち、プライマリとバックアップの両方に同じストレージを使用しないようにします。スナップショットを作成した時点で、データのコピーを別のシステムに保存していることになるので、このルールの一部はAWSスナップショットを使用して簡単に遵守することができます。

少なくとも1つのバックアップコピーをオフサイトに保存することが、厄介な部分です。AWSスナップショットを別のリージョンにコピーすることは可能ですが、自動化するのは難しく、コストもかかります。あるリージョンから別のリージョンにデータをコピーすると、イグレスチャージが発生し、コストのかかる不要なコピーが作成されます。また、この概念をすべてのAWSアカウントに一貫して適用し、一元的な管理とレポーティングを維持することは困難です。

単一のAWSアカウントと比較的少数のリソースを持つユーザーにとって、バックアップの自動化と一貫したポリシーの適用は簡単なプロセスです。しかし、複数の地域に多数のAWSアカウントを持つユーザーにとって、バックアップを監視しながらすべてのアカウントで一貫したデータ保護を実施することは、非常に困難でコストがかかる可能性があります。Kubernetesのようなアプリケーションでは、ITチームはより洗練されたデータ保護メカニズムを必要とし、スナップショットだけに頼っていては復旧目標を達成できないかもしれないので、問題はさらに複雑になります。

さらに、すべてのバックアップが異なる地域の異なるアカウントにコピーされることを保証する問題もあります。地域間で何千ものバックアップを移行するのは非常に高価であり、一般的なエグレス・チャージよりは低いものの、AWSは地域間のデータコピーに課金することになります。最後に、AWSのスナップショットはストレージ効率が良いが、長期間保存するとかなりコストがかかる可能性があります。

誤り：このような考えは、いくつかのソリューションの可視性の欠如によって助長されている。ローカルサーバーにデータを保存するのとは異なり、ローカルレベルで障害が発生しても、クラウドベースのデータで問題が発生することはありません。軍用レベルの暗号化と、大規模で安全なデータ保存のために特別に設計されたサーバーを提供するバックアップおよびアーカイブソリューションを見つけましょう。

誤り：Microsoft 365は、削除したメールとファイルをごみ箱に最大90日間保存するだけです。Google Workspaceは、エンドユーザーのDriveファイルとメールを30日後にゴミ箱とスパムフォルダに削除します。どちらのソリューション/プロバイダも、ユーザーエラー、データ破損、ランサムウェアの脅威が発生した場合のデータの完全な復元を保証するものではありません。マイクロソフトでは、サードパーティによるデータのバックアップをとっておくことを推奨しています（マイクロソフト サービス契約セクション6b）。

1. 誤って削除した場合

ユーザを削除すると、その意図の有無にかかわらず、その削除はビジネスアカウントとメールボックスの削除とともにネットワーク全体に複製されます。Microsoft 365 に含まれるネイティブのごみ箱とバージョン履歴では、データ損失の保護に限界があります。バックアップからの単純なリカバリは、Microsoft 365がデータを永久に削除した後、あるいは保持期間が過ぎた後に大きな問題に変わる可能性があります。

2. 保持ポリシーのギャップと混乱

保持ポリシーを含め、継続的に進化するポリシーは、管理はおろか、対応することも困難です。Microsoft 365のバックアップと保持ポリシーは限定的であり、状況に応じたデータ損失しか管理できず、包括的なバックアップソリューションとして意図されていいません。

3. 内部セキュリティの脅威

一般的にセキュリティの脅威というと、ハッカーやウイルスを思い浮かべます。しかし、企業は内部からの脅威を経験しており、それは想像以上に頻繁に起こっています。企業は、意図的であれ無意識であれ、自社の従業員による脅威の犠牲になっています。ファイルや連絡先へのアクセスはすぐに変更されるため、最も信頼してインストールしたファイルから目を離すことは困難です。マイクロソフトは、通常のユーザと、退職前に会社の重要なデータを削除しようとする解雇された従業員との違いを知る術がありません。さらに、ユーザは感染したファイルをダウンロードしたり、信頼できると思っていたサイトに誤ってユーザ名やパスワードを流出させたりすることで、知らず知らずのうちに深刻な脅威を作り出しています。

4. 外部からのセキュリティ脅威

ランサムウェアのようなマルウェアやウイルスは、世界中の企業に多大な損害を与えている。企業の評判だけでなく、社内データや顧客データのプライバシーやセキュリティも危険にさらされています。外部からの脅威は、電子メールや添付ファイルを通して忍び込む可能性があり、特に感染したメッセージが非常に説得力があるように見える場合、どのような点に注意すべきかをユーザに教育するだけでは必ずしも十分ではありません。定期的なバックアップは、感染していないデータの別コピーを確保し、データの復旧をより確実かつ簡単にするのに役立ちます。

5. 法的およびコンプライアンス要件

法的措置が取られる中で、不意に電子メールやファイル、その他の種類のデータを復元する必要が生じることがあります。マイクロソフトはいくつかのセーフティネット（訴訟ホールドとリテンション）を組み込んでいますが、これらはユーザ企業を法的トラブルから守る強固なバックアップソリューションではありません。法的要件、コンプライアンス要件、アクセス規制は業界や国によって異なり、罰金、罰則、法的紛争はどの企業も遭遇したくないものです。

株式会社クライムではMicrosoft 365ユーザのデータを保護を手助けする多くのソリューションを提供しています。

誤り: 適切なソリューションであれば、1シートあたり月額数ドルで無停止のデータ保護が可能です。データ漏洩による企業の損害は平均461万ドル（前年比10％増）であり、データ・セキュリティを確保するために必要な費用を大幅に上回っています。

誤り：この考え方は、特定のバックアップシステム/ソリューションが、ソフトウェアを動作させる前提として、管理者がエージェントをダウンロードしてインストールする必要があることに起因しています。しかし、あるプロバイダーはより簡単でユーザーフレンドリーなシステムを持っています。これらのプロバイダーは、顧客が独自のバックアップ自動化システムを素早くセットアップすることを可能にし、ワンクリック復元オプションと相まって、バックアップとアーカイブを可能な限り手間のかからないものにします。

誤り:規制対象外の企業は、データのバックアップとアーカイブに価値を見出しています。以下はその使用例です：

●監査では、少なくとも 6 年前にさかのぼる完全かつ正確なデータ記録の提出が求められることが多い (IRS、SEC など)。

●訴訟や規制当局の調査により、Microsoft 365/Google Workspaceのデータを改ざんや削除できないように法的保留が必要になる場合がある。

●アーカイブシステムにある高速ユニバーサル検索ツールを使用すると、ワンクリックでソリューション全体の検索クエリを高速化できます。

誤り：データ漏洩により、企業（北米） は平均461万ドルを失っている。包括的なバックアップ・アーカイビング・ソリューションにかかる月々数ドルと比較すれば、バックアップ・アーカイビングがいかに不可欠であるかがわかるだろう。多くの企業（まだ存続している企業もあれば、廃業した企業もある）が、このことを痛感している。

誤り：むしろ、下記のこれらが真実です：

市場に出回っているソリューションの多くは、UXデザインが貧弱で、使い勝手が悪い。

これらのソリューションの多くは、エージェントとしてダウンロードしなければ動作しない。

バックアップとアーカイブは別物であり、ほとんどのベンダーは一緒に提供していない。

多くのソリューションはモジュールとして販売されており、非常にコストがかかる。

バックアップとアーカイブのソリューションのうち、保存やアーカイブされたデータに基づく洞察や分析を提供するものはごく少数である。

さらに、ほとんどのソリューションは、カレンダーやタスクなど、すべてをバックアップしているわけではない。

誤り：データを人質に取らないソリューションもあります。重要なアドバイス：適切なソリューションを選択する際には、他のソリューションやサービスに移行する際にデータを取り戻すための費用が発生するかどうかをプロバイダーに確認してください。

誤り：それは非効率な場合だけです。洗練されたバックアップ・アーカイブソリューションは、最近更新または追加されたファイルを優先的にバックアップし、プロセス全体を高速化します。これにより、プロセスが迅速化され、データが完全に安全にバックアップされます。

誤り：ほとんどのソリューションでできることは限られていますが、バックアップやアーカイブ以上の機能を持つツールもあります。次のような高度な機能を提供するソリューションもあります：

●eDiscoveryとジャーナリングオプション
●高速検索機能
●保存およびアーカイブされたデータからのビジネス洞察と分析

クラウドバックアップについて迷いがありましたらクライムまでお問合せください。

• クロスクラウド戦略の導入： 複数のクラウドプロバイダーを活用することで、ベンダーロックインを回避し、異なるプラットフォームやインフラにリスクを分散することで耐障害性を高める。
• フェイルオーバープロセスの自動化： 自動化ツールを使用して、フェイルオーバープロセスを迅速かつシームレスに行い、ディザスタリカバリイベント中の人的介入を最小限に抑え、エラーの可能性を低減する。
• 頻繁なDR訓練の実施： 定期的な災害復旧訓練を計画、実施し、計画の有効性をテストし、弱点を特定します。関係者全員が参加し、万全の態勢を整える。
• データ重複排除の最適化 高度なデータ重複排除技術を使用して、バックアップに必要なストレージ量を削減し、プロセスをより効率的でコスト効果の高いものにする。
• 明確なRTOとRPO指標を確立する： 復旧時間目標（RTO）と復旧時点目標（RPO）を明確に定義し、文書化することで、ディザスタリカバリ戦略が事業継続の目標に合致するように。

• バックアップの暗号化を維持 データ保護を確実にし、ランサムウェアやサイバーセキュリティの問題によるリスクを軽減するために、暗号化されたリソースのクロスリージョンバックアップを作成します。
• バックアップネットワークをセグメント化する： バックアップシステムをメインネットワークから分離します。専用のVLANを使用し、バックアップが運用システムと同じネットワークセグメントからアクセスできないように。
• バックアップの完全性を定期的に検証する： バックアップの定期的なチェックと検証を行い、データが破損していないこと、必要なときに正常にリストアできることを確認します。
• ローリングバックアップ戦略を採用する： ローリングバックアップスケジュールを実施し、複数のバージョンのデータを異なる時間枠で保持する。これにより、ランサムウェア感染前の時点に復元することができます。
• エンドポイントプロテクションを使用してバックアップエージェントを保護する： バックアップ・エージェントを実行するすべてのデバイスとサーバーが、ランサムウェアのエントリ・ポイントにならないように、堅牢なエンドポイント保護機能を備えていることを確認します。

• バックアップ検証の自動化： 非本番環境へのリストアプロセスを自動化することで、バックアップを定期的にテストします。これにより、バックアップが有効であり、問題なくリストアできることを保証します。
• イミュータブル・ストレージの活用： 重要なバックアップをイミュータブル・ストレージに保存することで、ランサムウェアから保護し、指定された保存期間内にバックアップを変更または削除できないようにします。
• クロスサブスクリプション・バックアップの導入： セキュリティを強化するために、サブスクリプションレベルの問題や侵害から保護するために、バックアップのコピーを別のAzureサブスクリプションに保存することを検討します。
• バックアップ操作にプライベートエンドポイントを使用する： プライベートエンドポイントを構成して、バックアップとリストア操作がパブリックインターネットではなく、安全なプライベート接続を介して行われるようにし、セキュリティを強化します。
• バックアップデータの暗号化： 使用中のデータには透過的データ暗号化（TDE）を、保存されているバックアップデータには暗号化（at rest）を使用して、すべてのバックアップが暗号化されていることを確認し、セキュリティとコンプライアンスを強化します。

• 一貫性を保つために、Azure Resource Manager（ARM）テンプレートを使用します： インフラストラクチャのデプロイメント用にARMテンプレートを作成し、維持します。これにより、ディザスタリカバリ時に重要な一貫性のある反復可能なデプロイメントプロセスが保証されます。
• コンプライアンスのためのAzure Policyの実装： Azure Policy を使用して、ディザスタリカバリの構成とコンプライアンス要件を実施し、検証します。これにより、デプロイされたすべてのリソースがディザスタリカバリの標準に準拠していることを確認できます。
• Azure Private Linkを活用したセキュアな接続性： Azure Private Linkを活用して、オンプレミスのネットワークをAzureサービスにプライベート接続することで、攻撃対象領域を減らし、フェイルオーバーおよびリカバリプロセス中の安全なデータ転送を実現します。
• Azure DevOpsによるフェイルオーバーテストの自動化：Azure DevOpsを使用して、ディザスタリカバリのテストをCI/CDパイプラインに統合します。フェイルオーバーテストを自動化することで、手動による介入なしにディザスタリカバリプランを定期的に検証できます。
• マルチテナント管理のためのAzure Lighthouseの導入： マネージドサービスプロバイダーや大企業の場合、Azure Lighthouseを使用して、複数のAzureテナントを1枚のガラスから管理し、ディザスタリカバリシナリオ中の監視と制御を改善します。

• Azure Site RecoveryとCRRの併用：CRRとAzure Site Recovery（ASR）を組み合わせることで、仮想マシン（VM）のレプリケーション、フェイルオーバー、リカバリを自動化できます。ASRは、ディザスタリカバリプロセス全体をオーケストレーションすることができ、より包括的なソリューションを提供します。
• アラートでレプリケーションの健全性を監視 Azure Monitorでカスタムアラートを設定して、CRRプロセスの健全性とステータスを追跡します。このプロアクティブな監視により、あらゆる問題が迅速に検出、対処され、データの一貫性と可用性が維持されます。
• マルチクラウド戦略の導入による耐障害性の強化： Azure内だけでなく、異なるクラウドプロバイダー間で重要なデータを複製することで、ディザスタリカバリ戦略を強化します。N2WSのようなツールは、クロスクラウドレプリケーションを可能にし、クラウドプロバイダー固有の障害に対するフェイルセーフを提供します。
• レプリケートされたデータをエンドツーエンドで暗号化する： レプリケーションプロセス中、静止時と転送時の両方でデータが暗号化されていることを確認します。暗号化キーの管理とアクセスにはAzure Key Vaultを使用し、ディザスタリカバリ計画にさらなるセキュリティ層を追加します。
• レプリケーションとフェイルオーバーを定期的にテストする： Azure AutomationとASRを使用して、ディザスタリカバリ訓練を自動化します。定期的なテストにより、レプリケーションとフェイルオーバープロセスの信頼性と効率性を確保し、運用に影響が出る前に潜在的な問題を浮き彫りにすることができます。

• ストレージ階層を活用してレプリケーションコストを最適化： Azureのストレージ階層（ホット、クール、アーカイブ）をASR内で戦略的に活用する。たとえば、アクセス頻度の低いVMにはクールストレージを使用し、ディザスタリカバリ機能を維持しながらストレージコストを最適化する。
• リカバリプランによるワークロードの優先順位付け： 重要なVMとサービスのフェイルオーバーを優先する詳細なリカバリプランを作成します。この優先順位付けにより、災害時に最も重要なアプリケーションを可能な限り迅速に利用できるようになります。
• 分離された環境でフェイルオーバーを定期的にテストする： 分離された環境で、無停止のフェイルオーバーテストを定期的に実施する。このような訓練により、稼働中のサービスに影響を与えることなく災害復旧計画を検証し、復旧プロセスが意図したとおりに機能することを確認できます。
• レプリケーションにタグベースの自動化を活用する： プロダクション」や「クリティカル」などのタグに基づいて、VM のレプリケーションを自動化します。これにより、特定のタグに一致する新しいVMにASRレプリケーション設定を自動的に適用し、手作業による介入なしにVMを確実に保護することができます。
• マルチクラウド戦略との統合による耐障害性の強化： N2WSなどのツールを使用してASRをクロスクラウド機能と統合することにより、ディザスタリカバリ戦略を拡張します。これにより、異なるクラウド環境間でのリカバリが可能になり、クラウド固有の障害から保護されるため、回復力がさらに高まります。

• マルチクラウドDR戦略の採用： ディザスタリカバリのワークロードをクラウドプロバイダーに分散することで、ベンダーロックインを回避し、各プロバイダーのコスト効率を活用します。これにより、耐障害性が向上し、価格設定の柔軟性も高まります。
• 迅速なフェイルオーバーのためのリカバリシナリオの実装： N2WSを使用して、わずか数クリックでフェイルオーバーを自動化し、オーケストレーションします。これにより、ダウンタイムを最小限に抑え、複雑な手動リカバリプロセスの必要性を低減し、最終的に運用コストを削減します。
• 自動化されたDRテストを活用して、コストのかかるエラーを回避します： 自動DRテストツールを使用して、ディザスタリカバリ計画を定期的にテストします。これにより、多額の費用をかけずに復旧プロセスを検証し、運用を中断することなく万全の準備を整えることができます。
• イミュータブルバックアップでDRバックアップにさらなるセキュリティ層を追加します： イミュータブル・バックアップは、データの改ざんや削除を確実に防止するため、余分なコストをかけずにさらなる安全策を提供します。
• クロスリージョンDRとクロスアカウントDRで耐障害性を強化します： N2WSのクロスリージョンバックアップとクロスアカウントバックアップ機能を利用して、地域の停電から保護し、データセキュリティを向上させます。

• クロスクラウド戦略の導入： 複数のクラウドプロバイダーを活用することで、ベンダーロックインを回避し、異なるプラットフォームやインフラにリスクを分散することで耐障害性を高める。
• フェイルオーバープロセスの自動化： 自動化ツールを使用して、フェイルオーバープロセスを迅速かつシームレスに行い、ディザスタリカバリイベント中の人的介入を最小限に抑え、エラーの可能性を低減する。
• 頻繁なDR訓練の実施： 定期的な災害復旧訓練を計画、実施し、計画の有効性をテストし、弱点を特定します。関係者全員が参加し、万全の態勢を整える。
• データ重複排除の最適化 高度なデータ重複排除技術を使用して、バックアップに必要なストレージ量を削減し、プロセスをより効率的でコスト効果の高いものにする。
• 明確なRTOとRPO指標を確立する： 復旧時間目標（RTO）と復旧時点目標（RPO）を明確に定義し、文書化することで、ディザスタリカバリ戦略が事業継続の目標に合致するようにする。

N2WSは、DR戦略の有効性を高めながら、ディザスタリカバリのコストを大幅に削減します：

• 複数のリージョン、アカウント、クラウドにまたがるDRを自動化します： 自動化されたクロスリージョン、クロスアカウント、クロスクラウド機能により、ディザスタリカバリを簡素化し、安全性を確保します。
• DRテストと訓練の実行と自動化： ゼロコストで自動化されたDRドライランにより、ディザスタリカバリのテストを簡単に実施し、万全の準備を整えることができます。
• リカバリシナリオによるフェイルオーバーのオーケストレーション： ワンクリックで複数のリソースのフェイルオーバーを管理し、復旧作業を効率化します。
• 暗号化リソースのサポート： 暗号化されたリソースのクロスリージョンおよびクロスアカウントDRを実現し、セキュリティのレイヤーを追加します。
• カスタムDR生成によるコスト削減 N2WSのカスタムDR生成オプションにより、ディザスタリカバリコストを削減します。
• イミュータブルバックアップでセキュリティを強化 DRバックアップを不変性で保護し、データの整合性を確保します。
• 頻繁なバックアップ 最短60秒間隔でバックアップを取得し、RPOを最小化します。
• ほぼゼロのRTOを達成： 重要なシステムを数秒で復旧し、業務への影響を最小限に抑えます。
• フェイルオーバーとフェイルバックの自動化 リカバリプロセスを自動化することで、ダウンタイムを短縮し、一貫した信頼性の高い結果を保証します。
• 完全に機能するDRバックアップのリストア： すべてのVPCとネットワーク設定をそのままにバックアップをリストアし、シームレスなリカバリを実現します。

• リージョン間レプリケーションを活用: クロスリージョンレプリケーション(CRR)を実装して、AWSのリージョン間でオブジェクトを自動的にコピーします。 これにより、地理的に離れた場所にデータを保存することで災害復旧能力が強化されるだけでなく、データ保存要件への準拠も支援します。
• N2WSで簡単に自動化: N2WSは、複雑なコーディングや手動での介入を必要とせずに、S3バックアップを自動化するシンプルで使いやすい方法を提供します。 これにより、効率が向上し、S3データの保護が確実に維持されます。
• インテリジェント・ティアリングでコストを最適化:S3インテリジェント・ティアリング・ストレージクラスを利用して、アクセスパターンの変化に応じて、2つのアクセス層(頻繁なアクセスと頻繁ではないアクセス)間でデータを自動的に移動させます。これにより、パフォーマンスへの影響やオーバーヘッドなしにストレージコストを最適化できます。
• セキュリティを強化するMFA Delete:バージョン管理機能付きのS3バケットで多要素認証(MFA)による削除を有効にすることで、セキュリティをさらに強化できます。オブジェクトのバージョンを恒久的に削除する操作にはMFAが必要となり、削除を防止します。
• AWS S3 Storage Lensでストレージを分析:S3ストレージの使用状況とアクティビティの傾向を可視化できます。このツールは、コストの最適化、データ保護のベストプラクティスの強化、パフォーマンスの向上に役立つ洞察と推奨事項を提供します。

• ストレージ階層化を動的に活用：静的なライフサイクルポリシーにとどまらず、使用パターンを自動的に分析し、動的に階層間でデータを移動するツールを使用して、パフォーマンスとコストの両方をリアルタイムで最適化することを検討してください。
• スポットフリートで高可用性を実現：スポットインスタンスはコスト削減に役立ちますが、最も安価な利用可能なスポットインスタンスを自動的に選択し、再バランスする「スポットフリート」を作成することで、コスト効率と稼働時間を確保することができます。
• カスタム価格モデルの交渉：大手クラウドプロバイダーは、大量に利用する企業向けにカスタム価格帯を提供しています。既定の料金に妥協することなく、利用量や特定のサービス要件に基づく割引を交渉しましょう。
• クラウドネイティブなコスト最適化ツールの活用：ネイティブなコスト管理ソリューションに加えて、CloudHealthやCloudabilityのようなクラウドネイティブなサードパーティプラットフォームは、より深い洞察、クロスクラウド分析、自動化されたガバナンスを提供し、競争優位性をもたらします。
• サービス固有のコスト最適化フレームワークを利用する：各クラウドプロバイダーには、それぞれに秘められた効率化があります。例えば、AWS Compute OptimizerやAzure Cost Managementの推奨事項は、特定のサービスのコスト削減に重点を置いています。手動監査と併用して、これらのサービスを活用し、支出を最適化しましょう。
• 続きはこちらまで

●ハイブリッドストレージ戦略で取得コストを最適化：S3 GlacierをS3 StandardまたはS3 Intelligent-Tieringと組み合わせます。 頻繁にアクセスされるデータはStandard/Intelligent-Tieringに残し、長期にわたってアクセス頻度の低いデータをGlacierに移行します。 これにより、より重要なデータへの迅速なアクセスを確保しながら、ストレージコストを大幅に最適化できます。

●S3 Object Lock を活用して変更不可のバックアップを作成：S3 Object Lock を Glacier と組み合わせて使用することで、変更不可のバックアップを作成できます。これにより、重要なバックアップに WORM（Write Once Read Many）モデルを適用することで、誤って削除されたりランサムウェア攻撃を受けたりした場合でも、お客様のデータを確実に保護することができます。

●大きなファイルにはマルチパートアップロードを使用： 大きなアーカイブには、Glacierのマルチパートアップロード機能を使用します。 アップロードの効率が向上するだけでなく、管理しやすい小さな部分に分割してファイルをアップロードすることで、アップロードの失敗リスクを低減し、データの整合性を確保できます。

●DRには地域間レプリケーションを実装： 地域間レプリケーションを設定して、AWSの1つのリージョンから別のリージョンにデータを自動的に複製します。これは、地域的な障害が発生した場合に、重要なデータのコピーが常に別の地理的場所で利用可能であることを保証するため、災害復旧に不可欠です。

●異なるデータセットごとのカスタム取得プラン：異なるデータセットのビジネス上の重要度に基づいて、カスタム取得プランを定義します。例えば、優先度の高いデータについては迅速な取得、重要度は低いがサイズの大きいデータセットについては一括取得などです。これにより、コストのバランスを調整し、重要な情報が迅速に利用可能であることを保証します。

●詳細はこちらまで

●コスト管理にスナップショットのライフサイクルポリシーを活用：より古いスナップショットを低コストのストレージ層に移行することで、リカバリ性を損なうことなくコストを削減できます。

●代替案としてアプリケーション認識型レプリケーションを検討する：バックアップが大きなオーバーヘッドをもたらすようなシナリオでは、重要なワークロードをリアルタイムで同期し、一貫性を保証するアプリケーション認識型レプリケーションソリューションを評価します。

●バックアップ用にリードレプリカを実装する：データベースの場合、リードレプリカを作成し、そのレプリカに対してアプリケーション一貫性のあるバックアップを実行することを検討します。これにより、バックアップ中のプライマリデータベースのパフォーマンスへの影響を回避できます。

●テスト環境でバックアップをテストする：サンドボックス環境を使用して、本番環境のワークロードに影響を与えることなく、アプリケーション整合性のあるバックアップをテストします。自動化ツールを使用すると、障害をシミュレートし、リカバリ時間を検証することができます。

●変更不可ストレージでリカバリを強化する：Azureで変更不可のバックアップを設定することで、誤って削除したりランサムウェアの被害に遭うことを防ぎます。アプリケーション整合性と組み合わせることで、悪意のあるデータ損失や誤操作によるデータ損失の両方のシナリオにおいて、リカバリの整合性を確保することができます。

●アーカイブ前にデータの分類を優先：すべてのスナップショットが同じように重要であるわけではありません。 コンプライアンスやDRなどの重要なスナップショットと、より長い検索時間を許容できるスナップショットを区別するために、堅牢なデータ分類ポリシーを導入します。

●アーカイブからの取得に関するSLAをDR計画に統合：GlacierまたはDeep Archiveにスナップショットをアーカイブした場合、取得に数分から数時間かかる場合があります。 災害復旧（DR）計画では、こうした取得SLAを考慮して、予期せぬ遅延を回避する必要があります。

●S3 Object Lockを使用して保持の徹底を自動化：S3 Object Lockを使用して重要なスナップショットの不変性を徹底し、早期の削除を防止して、規制へのコンプライアンスを確保します。 また、誤ってまたは悪意を持って削除されることも防ぎます。

●重要アーカイブスナップショットには、クロスリージョンレプリケーションを活用：スナップショットをアーカイブする前に、クロスリージョンレプリケーション（CRR）を有効にします。これにより、リージョンがダウンした場合でも、アーカイブされたデータは別のリージョンで利用可能になります。

●AWS Cost Explorer を使用して定期的にコスト監査を実施する：S3 GlacierとDeep Archiveはコスト削減をもたらしますが、これらは長期間にわたって気づかぬうちに蓄積される可能性があります。AWS Cost Explorerを使用して定期的にアーカイブコストを監査し、スナップショットのライフサイクルポリシーが最適化されていることを確認してください。

サーバ仮想化の基本要素である、1台のホスト上に存在するすべてのVMは、物理サーバのリソースを共有し、1つのハイパーバイザによって管理されていることを忘れてはいけません。もし、これら全てのVMが同時にバックアップジョブを開始したらどうなるのでしょうか？ハイパーバイザーやホストサーバのリソースに負担がかかり、遅延が発生したり、最悪の場合バックアップが失敗したりする可能性があります。

ここでスナップショットの威力が発揮されます。スナップショットはVMのある時点のコピーを取得し、フルバックアップと比較してはるかに迅速な処理が可能です。スナップショット自体はバックアップではありませんが、イメージベースバックアップの重要な構成要素です。VMスナップショットがバックアップと同等でない主な理由は、VMから独立して保存できないからです。このため、スナップショットの取得頻度によっては、VMのストレージ容量が急速に増大し、パフォーマンスに影響を与える可能性があります。このため、取得するスナップショットの数量を認識することが重要です。

• スナップショットのライフサイクルポリシーを活用してコスト管理：復旧性を損なうことなくコストを削減するために、古いスナップショットを低コストのストレージ階層に移行します。
• 代替案としてアプリケーション認識型レプリケーションを検討：バックアップが大きなオーバーヘッドをもたらすようなシナリオでは、重要なワークロードをリアルタイムで同期し、一貫性を保証するアプリケーション認識型レプリケーションソリューションを評価します。
• バックアップ用にリードレプリカを実装：データベースの場合、リードレプリカを作成し、そのレプリカに対してアプリケーション一貫性のあるバックアップを実行することを検討します。これにより、バックアップ中のプライマリデータベースのパフォーマンスへの影響を回避できます。
• テスト環境でバックアップをテスト：サンドボックス環境を使用して、本番環境のワークロードに影響を与えることなく、アプリケーション整合性のあるバックアップをテストします。自動化ツールを使用して障害をシミュレートし、リカバリ時間を検証できます。
• 不変ストレージでリカバリを強化：Azureで不変バックアップを設定することで、誤って削除されたりランサムウェアの被害に遭うことを防ぎます。アプリケーション整合性と組み合わせることで、悪意のあるデータ損失や誤って削除された場合の両方のシナリオで、リカバリの整合性を確保できます。

• Managed Identity を使用してバックアップを自動化： スクリプトに認証情報を埋め込む代わりに、Azure の Managed Identity を使用してストレージアカウントへの安全なアクセス権限を付与し、エクスポート/インポート操作を自動化します。
• バックアップと復元のパフォーマンスを監視：Azure Monitor を使用してバックアップ/復元操作のパフォーマンスを追跡し、障害や異常に長い操作時間に対するアラートを設定します。
• 地理的冗長ストレージを賢く使用：RA-GRS は耐久性に優れていますが、パフォーマンスとコストを最適化するには、ゾーン冗長ストレージ（ZRS）やローカル冗長ストレージ（LRS）を使用する方が適しているセキュリティの高いシナリオもあります。
• 機密データベースのバックアップ暗号化を有効にする：透過的データ暗号化（TDE）でデータベースのバックアップを暗号化します。さらにセキュリティを強化するには、Azure Key Vaultに格納された顧客管理キー（CMK）を使用します。
• 重要なバックアップに不変ストレージを組み込む：誤って削除されたりランサムウェアから保護するための長期的なバックアップ。これにより、バックアップが保持期間中に改ざんされないことが保証されます。

Microsoft Teamsのバックアップに関する3つ目のベストプラクティスは、作業に適したツールを使用していることを確認することです。Microsoft 365のエコシステムの中には、保持ポリシーや、バックアップの実行を支援する機能などがあります。

保持ポリシーと訴訟ホールドは擬似的なバックアップとして機能することができます。しかし、これらのツールは、データ保護ではなく、コンプライアンス目的のために存在します。そのため、Microsoft Teamsのデータを適切に保護することはできません。

データ保持ポリシーと訴訟ホールドは、データの保護方法に関して矛盾やカバーギャップを生じさせる可能性があります。Microsoft Teamsのすべてのデータを確実に保護する唯一の方法とは、以下のとおりです。Microsoft 365を保護するために特別に設計された専用のバックアップアプリケーションを使用することで、ビジネス要件と法的義務に一致した方法で保護することができます。

Microsoft Teamsのバックアップに関する最良の方法は、Microsoft Teams（およびその他のMicrosoft 365アプリ）を実際にバックアップしていることを確認することです。

Microsoftは、Teamsとその他のMicrosoft 365アプリケーションに責任共有モデルを採用しています。この責任共有モデルは、基本的に Microsoft 365 アプリケーションと基盤となるインフラストラクチャを健全に保つ責任は Microsoft にあるが、Microsoft 365 の加入者は以下の責任を負うというものです。自分のデータを安全に保護する責任があります。このデータ保護責任には、データのバックアップを確認することも含まれます。

Office 365は、非常に多くの異なるMicrosoft 365コンポーネントを活用しているため、バックアップが最も困難なアプリケーションです。Exchange OnlineやSharePoint Onlineなどのアプリケーションとは異なり、Teamsは、すべてのデータを1つの場所に保存していません。その代わり、Microsoft Teamsのデータは異なるMicrosoft 365アプリケーションを使用されています。Microsoft 365のバックアップアプリケーションであれば、Teamsのデータをバックアップできるはずですが、アプリケーションがMicrosoft Teamsをサポートするように特別に設計されていない限り、復元プロセスが非常に困難になる可能性があります。

MicrosoftはTeamsのバックアップのためのAPIを提供していますが、このAPIは最近リリースされたばかりです。そのため現時点では、すべてのバックアップベンダーがTeamsバックアップAPIを製品に組み込んでいるわけではありません。

いずれは主要ななバックアップソリューションがMicrosoft Teamsをネイティブにサポートするようになると思われますが、当面はバックアップ製品に現在そのようなサポートを含んでいるかどうかを確認することが重要です。

ベストプラクティスその4は、バックアップにハイブリッドなアプローチを取ることです。Microsoft 365とオンプレミスのMicrosoft Office アプリケーションを別々にバックアップするのではなく、両方の環境を同時に保護できる1つのバックアップアプリケーションを使用するのがよいでしょう。

なぜなら、バックアップを復元するということは、何か悪いことが起こったということだからです。どのような事象がデータ復旧の必要性の引き金になるかを予測するのは難しいため、バックアップアプリケーションは最大限の柔軟性を持たせることが非常に重要なのです。バックアップにハイブリッドアプローチを採用することで、この柔軟性を強化することができます。例えば、オンプレミスのメールボックスをMicrosoft 365クラウドに、またはその逆に復元することができるようなことが可能です。

ベストプラクティスの5番目は、サービスレベルアグリーメント（SLA）をバックアップ計画の最前線に置いておくことです。具体的には、適切なRPO（Recovery Point Objective）とSLA（Service Level Agreement）を検討する必要があります。Microsoft Teams環境のRTO(Recovery Time Objective)です。RPOは、バックアップを作成する頻度を決定し、それによって、バックアップの間に失われる可能性のあるデータの最大量を決定します。RTOは、バックアップを復元するのにかかる時間の長さに関するものです。

この2つの指標は、組織の能力に直結するため、非常に重要です。災害からの迅速かつ完全な復旧組織においてRTOとRPOは恣意的な値ではなく、組織のビジネス上の要求と、その要求を反映したものであるべきです。

Microsoft 365 には以前から eDiscovery 機能があり、召喚状に応じて Microsoft 365 のエコシステムの中から特定のデータを探し出すことができます。しかし、ネイティブeDiscoveryの機能もありますが、ディスカバリプロセスではバックアップソフトを使った方が効果的な場合が多いのです。

バックアップアプリケーションに優れた検索インターフェースがあれば、組織は召喚状で要求されるデータをバックアップで検索することができます。これは、ネイティブのeDiscovery機能を使用するよりも迅速かつ簡単であるだけでなく、次のような機能も備えています。

検索結果に表示された文書をリムーバブルドライブに復元し、相手方の弁護士に提供できるようにします。

最後のベストプラクティスは、バックアップアプリケーションに関しては、使いやすさが重要であるということです。バックアップアプリケーションの中には、設定や使い方があまりにも複雑だという評判のものもあります。この問題は、複雑であればあるほどヒューマンエラーが発生する可能性が高くなることです。もし組織が直感的で使いやすいバックアップアプリケーションを選択すれば、バックアップやリカバリの失敗を高確率的に減らすことができます。

使用するバックアップソリューションで、オンプレミスかクラウドベースかにかかわらず、データをバックアップできることが重要です。使用するストレージを自由に選択できることで、パフォーマンス、回復力、コストなどの要件に最も適したストレージ階層を選択することができます。また、イミュータブル（Immutable）ストレージのような機能を利用することもできます。

Microsoft Teams Backupのベストプラクティスとして、よく見落とされるのがバックアップソリューションは、きめ細かなリカバリ機能を備えているかです。チーム全体（または複数のチーム）をリストアできることは重要ですが、チーム内のファイルやチャットをリストアできることも同様に重要です。

ユーザーが誤ってチームを削除した場合、多くの場合、そのチームを復元するにはPowerShell を使用して、Azure AD Recycle Binから関連する Azure Active Directory グループを復元します。
しかし、残念ながら、Teamsのネイティブ復旧は、無益な作業となります。Microsoft は削除されたチームを復元することを許可しますが、Microsoft 365 のネイティブ ツールを使用して個々のチームを復元することはできません。

もう一つのベストプラクティスは、Microsoft Teamsのデータをランサムウェアから確実に保護することです。一般的に考えられているのとは異なり、Microsoft 365に保存されているデータは、次のような方法で暗号化することができます。
ランサムウェア多くの人が個人所有のデバイスからリモートで仕事をするようになったことが、大きく影響し、ランサムウェアに感染するリスクを高めます。

ランサムウェアに感染した場合、組織のデータを復旧させるためには、通常、身代金を支払うか、バックアップを復元するかのどちらかの選択肢しかありません。身代金の支払いには高額な費用がかかる傾向があり、身代金を支払っても、実際にデータが復号化される保証はありません。たとえデータが復号化されたとしても、身代金を支払うと攻撃者が増長し、データを再暗号化し、さらに金銭を要求してくる可能性があります。バックアップを復元する方がはるかに良い選択です。バックアップは、ランサムウェアに関連するデータ損失に対する最善の防御策です。

● Veeam Backup for Microsoft Office 365

Veeam Backup for Microsoft Office 365は、Microsoft Office 365環境の包括的なバックアップを提供します。Exchange Online、SharePoint Online、OneDrive for Business, Microsoft Teamsのバックアップが可能です。

●Druva inSync（ドルーバ インシンク）

エンドポイントデバイスおよびクラウドアプリ向けのクラウドネイティブなデータ保護サービスです。社内のあらゆるエンドユーザーデータを自動的にバックアップし、データの復元、ランサムウェア/ 情報漏洩対策、データの可視化や分析など、さまざまなデータ保護機能を提供します。

補足ブログ

10の注意事項　（プラス１）

https://www.climb.co.jp/faq/faq-category/ms-teams-backup

包括的な要件収集

多くの企業では、ビジネスプロセスや、ビジネスプロセスによってどのようにテクノロジーが推進されるのかについて、詳細な文書がない場合があります。このステップは、通常、計画の中で最も時間のかかる部分です。各ビジネスプロセスがどのように機能し、技術リソースとどのように相互作用するかを正確に把握することは、リソースをクラウドに移行することに意味があるのか、またどのような影響があるのかを判断するために非常に重要です。

コンピュート資源、ディスクスペース、ネットワークのニーズなどの技術的要件だけでなく、コンプライアンスや規制に関する考慮事項、リソースの可用性、他のビジネス・ワークフローとの統合も考慮する必要があります。

コストの見積

技術的なニーズとビジネスプロセスのニーズについて包括的な資料が揃ったら、ワークロードの移行、あるいはクラウドでのワークロードの再実装に関連するコストとメリットを検討し始めることができます。従来のコンピュートやストレージのニーズ以外にも、さまざまな考慮事項があります。

– バックアップのコスト、ポータビリティ、スペース
– リソースの初期転送と継続的なニーズに対応するための帯域幅
– ロードバランサー、アプリケーションゲートウェイ、スケール関連機能
– Azure AD（プレミアムの場合）およびOffice 365ユーザーのライセンスコスト
– Microsoft SQLやMicrosoft WindowsなどのVMライセンス
– 開発環境リソース
– 継続的インテグレーション/継続的デプロイメント（CI/CD）コスト

オンプレミスで購入したハードウェアの保守契約費用を除けば、ほとんどのクラウドリソースには定期的な使用費用が発生します。従来の資本支出モデルと比較すると、クラウドサービスの運用コストは複数年に渡って分散される可能性があります。短期間の利用であれば比較的リーズナブルですが、慎重に管理しないとコストオーバーにつながる可能性があります。

制約と予算のしきい値

多くの企業では、IT予算が無制限にあるわけではありません。Azureはリソースのデプロイを容易にし、それに応じて予算オーバーも容易にします。しかしAzureは「自分のペースで学べるAzure Cost Management tools」によって、クラウドのコストを計画し、コントロールすることも簡単にできます。

また、予算というと実際の金額が思い浮かぶかもしれませんが、それだけが予算ではありません。利用可能なリソースでチームを最大限に活用するために、人的資本の予算も重要です。

– 各ビジネスユニットの予算と、それが具体的なリソースにどのように関わってくるかを検討
– どの時点で、誰に、どのようなアクションを起こすべきか、予算に関する警告を行うべきかを決定する
– 拡張性のあるリソースは、無秩序な成長とコストを避けるために制約を設ける必要がある

Azureの異なるサービスやオファリングは、コストと機能価値を比較した場合、同等とは限りません。このため、利用可能な機能と関連するコストの両方を戦略的に検討し、組織にとって最も価値のあるものを選択することが重要です。

共有資産の利用可能性

類似のワークロードは、共有リソースを活用する上で魅力的なターゲットとなります。セキュリティ、セグメンテーション、パフォーマンスなどの理由で専用インスタンスを必要としないリソースは、共有のコンピュート、ストレージ、アプリケーションインスタンスを使用することでコストを削減することができます。このような基準に合致するワークロードを特定することで、統合によって使用するリソースを節約することができます。

仮想マシンの共有による統合だけが、コスト削減の手段ではありません。コンテナベースのデプロイメントを検討する場合、Azure Kubernetes Serviceのような専用の管理プラットフォームを利用すると、配置と利用を最適化でき、投資を最大限に生かすことができる場合があります。

ガバナンス戦略

IT担当に与えられた柔軟性により、クラウドは瞬く間に戦場と化す可能性があります。事前に適切なガバナンスプランと戦略を導入することで、制約のない広がりを制御すると同時に、イノベーションのための自由とコスト管理を可能にします。Azureポリシーによって、組織はIT担当者が利用できるリソースの種類、サイズ、機能を制御することができます。さらに、リソースのタグ付けを利用することで、これらのリソースをグループ化し、さまざまなチーム、リソースタイプ、プロジェクトに関連付け、レポートを作成してコストを管理することができます。すべてのリソースにタグ付けできるわけではなく、タグは継承されないため、適切なタグ付け戦略を確実に実行することが重要です。

ここでは、Azureでコストをコントロールしながら、利用可能なすべてのサービスと機能を最大限に活用するための4つのステップについて説明します。新たにクラウドを導入する企業も、以前からクラウドファーストのアプローチを取っている企業も、適切な計画、展開、監視、最適化によって、Azureの活用を成功させることができます。

https://www.climb.co.jp/faq/faq-category/azure-cost

適切な計画が立てば、次のステップは必要なリソースの配備です。クラウドへの完全移行に重点を置いている場合でも、単に小規模から始める場合でも、価格と柔軟性について考慮することで、将来的に大きな違いが生まれます。計算機、ディスク、データベースには、コストを大幅に削減できるさまざまなオプションが用意されています。

コンピュート・リソース

クラウドベースの仮想マシンは、最も一般的に使用されるクラウドリソースの1つであり、多くのITプロフェッショナルが最初に検討するものの1つであると思われます。仮想マシンをデプロイする必要がある場合、Azureはいくつかのコスト削減策を提供しています。

– 予約済み仮想マシンインスタンス : 指定されたリソースの年数を事前に購入することで、企業はより低いコストで利用することができます。
– スポット価格 : 特定のマシンが常に存在する必要はありません。そのような場合は、スポット価格を使用して、未使用のコンピューティング容量を大幅な割引価格で購入することができます。アプリケーションは潜在的なシャットダウンに強いことが必要ですが、その場合は大幅なコスト削減を実現できます。
– Dev-Test Pricing – 堅牢な開発およびテスト環境を持つ組織では、これらのマシンは通常短命で使用率が低いため、これらの環境の割引料金を利用することでコストを抑えることができます。

また、コンテナやPlatforms as a Service（PaaS）は、その柔軟性と使いやすさから非常に人気が出てきています。Azure Kubernetes Service (AKS) は、コンテナのオーケストレーションに最適です。ワークロードをコンテナに移行することで、企業はリソースをより緊密にまとめ、最新のマイクロサービス・アーキテクチャを活用することでコスト削減を実現することができます。App Services などの PaaS は、Web サーバーの従来の管理負担を軽減するものです。既存のWebサイトをApp Servicesに移行することで、従来のVMを使用する必要がなくなり、管理時間やコストそのものを削減できる可能性があります。

Azureストレージ層の活用

クラウド環境のコンピューティング能力を支えるのは、大容量のデータを保存する必要性です。そのため、必要なストレージの種類を適切に計画することに時間をかければ、コストを削減することができます。このことは、組織のデータストレージのニーズが高まり、特定の種類のデータが特定のストレージ層に最適であることが判明した場合に特に顕著になります。

Azure Storageのいくつかの機能は、データの安全な転送と保存のための魅力的なオプションになります。プライベートエンドポイントを使用すると、クライアントがプライベートリンクを介してストレージデータに安全にアクセスできるようにすることができます。これにより、公共のインターネットからの露出を制限し、ストレージへのアクセスの制御を強化することができます。

Azureストレージの価格

Azureで利用できるストレージにはいくつかの種類がありますが、一般的に多くのニーズを満たすのは、マネージドディスクとブロブの2種類です。
マネージドディスクは、従来のストレージメディアで、物理サーバーにインストールされた追加のハードディスクに相当します。この拡張可能なディスクには、いくつかの異なる階層があります。どのようなディスク速度を必要とするかによって、いくつかの層から選択することができます。

– プレミアムSSD
– スタンダードSSD
– スタンダードHDD
– ウルトラディスク

ディスクの速度について語るとき、一般的には1秒間に行われる入出力操作の数であるIOPSを意味します。管理対象ディスクの階層によって保証されるIOPSが異なるため、アプリケーションのパフォーマンスに直接影響を与えることができます。P30より小さいプレミアムSSDサイズでは、バースト可能なIOPSと帯域幅を提供し、VMの起動時間とアプリケーションのパフォーマンスを大幅に向上させることができます。このタイプのバーストは、VMレベルおよびディスクレベルで独立して利用可能です。一方を有効にすれば、もう一方は必要ありません。どちらも、1日を通して使用するIOPSクレジットのバケットを蓄積して使用します。このバケットを使い切ると、パフォーマンスは基本ディスク・タイプのものに戻り、使用前に再度蓄積する必要があるため、アプリケーションやVMのパフォーマンスに悪影響を与える可能性があります。

Azure Blob は、保存すべきデータが大量にある場合に、より理にかなっていると言えるかもしれません。このデータは、常にアクセスする必要がない場合もあれば、複数のリソースで簡単に共有する必要がある場合もあります。バックアップは、Blobストレージの典型的な使用例である。このタイプのストレージは、AWS S3タイプのオブジェクトおよびメタデータストレージファイルシステムに相当する。Blobストレージにはいくつかの階層があり、価格とアクセス速度に影響します。

– プレミアム
– ホット
– クール
– アーカイブ

Azure Blobストレージのコストは、月間の1日あたりの平均保存データ量（ギガバイト（GB）単位）で決定されます。例えば、月の前半に20GBのストレージを使用し、後半は全く使用しなかった場合、平均10GBの使用量に対して請求されます。クール層とアーカイブ層から45日後に削除する場合、135日分（180日から45日を引いた日数）の早期削除料が課金されますので、計画的に利用ください。

ファイルストレージとブロックブロブストレージの両方について、冗長性に関するオプションがあります。ローカル冗長ストレージ（LRS）と地理的冗長ストレージ（GRS）のどちらを選ぶかは、コストに大きく影響し、2倍から3倍のコストになることもあります。GRSは保護とアップタイムを向上させますが、コストは高くなります。レプリケーションの設定はいつでも変更可能ですが、LRSから他のタイプのレプリケーションに移行する際には、イグレス帯域幅の料金が発生します。

また、Blobストレージのアプリケーション・プログラミング・インターフェース（API）のコストも考慮しなければなりません。読み取り、書き込み、リスト、作成の各操作には、1万トランザクションあたりのコストがかかる。オブジェクト操作の量が多い場合、これは計画上予想外のコストとなる可能性がある。Blobストレージが、大きな単一オブジェクトでアクセス頻度の低いデータにのみ使用されている場合、APIコストは無視できると思われます。

Cool層とArchive層からそれぞれ30日、180日未満でデータを取り出す場合、追加料金が発生する可能性があることに留意してください。これらのストレージは、より長期的で安価なストレージであることを意図しています。

SQLエラスティックプール

SQLサーバーはすぐに高価になります。本番データベース1つにつき1台のサーバーという従来のモデルでは、特にライセンス要件によって、コストが爆発的に上昇する可能性があります。SQL Elastic Poolsは、データベース間でコンピュートとストレージのリソースを共有し、プロビジョニングされたすべてのリソースを効率的に使用するもので、コストを劇的に削減できる拡張性のあるソリューションです。

リソースの使用量を制限することで、データベースがリソースを乱用して他のデータベースに悪影響を与えないように、さらに最適化し制限することができます。プールの価格は、設定されたリソースの量に基づき、データベースの数とは無関係に決定されます。このタイプのセットアップは、データベースごとに1台のサーバーを使用するアプローチではなく、顧客のデータベースをホスティングする場合にも最適です。

例として、30人のお客様がいて、それぞれがデータベース・インスタンスを持っているとします。最も安価な5 DTUプランを約4.8971ドル/月で購入すると、顧客データベースを格納するためのコストは結局約147ドルになります。Elastic Poolsに移行すると、50 DTUプランを73ドルで購入でき、最大100個のデータベースを扱えるようになります。また、個々のデータベースが使用するリソースを制限することで、プール全体への悪影響を抑制することができます。

Azure Functionsによるサーバーレス

多くの組織が新しい「サーバーレス」能力を活用しています。インフラを管理することなくコードやアプリケーションを実行できるため、迅速な導入と開発につながります。Azure Functionsは、C#、Java、JavaScript、Python、PowerShellでコードを記述し、オンデマンドまたはスケジュールに従ってコードを実行する機能を提供します。
使用量に応じた課金モデルを採用しているため、コードの実行に費やした時間に対してのみ料金を支払う必要があります。400,000GB/s（メモリ使用量に基づくギガバイト秒）と100万回の実行が無料であるため、消費プランでは最小限のコストで始める方法が提供されています。

バックアップソリューションの最適化

ストレージ層についてのセクションで述べたように、バックアップにBlobストレージを使用すると、特にCool層とArchive層を使用する場合、コストを削減することができます。このタイプのストレージは通常、障害発生時に迅速にリストアする必要があるフルVMスナップショットには使用されません。Microsoft Azureは、各VMに適切なスナップショットが取得されるように支援するバックアップサービスを提供している。これは、VMごとの固定コストと消費されたストレージのコストに基づいています。

どのようなビジネス環境においても必要不可欠なバックアップのコストを軽減するために、Veeam Backup for Microsoft Azureのようなサードパーティ・ソリューションを使用することで、多数のVMのバックアップや、データを長期間保持する必要がある場合のコストを節約することができます。例えば、VeeamはAzure用に構築されたクラウドネイティブバックアッププロセスにより、10台のVMを無料で提供しています。ビルトインのコスト計算機により、作成するバックアップ・ポリシーにどれだけのコストがかかるかを実装前に積極的に確認することも可能です。

さらに、Veeamはクラウドに依存しないファイル形式を使用しているため、データのポータビリティを実現します。このバックアップ・プロセスの明白でない利点は、Veeamを活用してオンプレミスのマシン・バックアップを自動的にクラウドに移動することができることです。オンプレミスサイトが突然アクセス不能になった場合、データポータビリティとクラウドネイティブソリューションにより、Veeamバックアップを活用して、以前に作成したバックアップを経由して環境を迅速に起動することができます。

コンテナのバックアップの必要性については、その刹那的な性質からあまり考えないかもしれませんが、Kubernetesクラスタにはステートフルなコンテナと関連する設定やメタデータが存在することがよくあります。すべてのコンポーネントをまとめて包括的にバックアップし、環境全体を迅速に復元できるようにすることは困難です。例えばVeeamのKasten K10は、Kubernetesクラスターのあらゆる側面をバックアップする機能を提供します。さらに、適切なポリシーとリソースのディスカバリーを定義することで、適切なガバナンスを確保し、リソースの取りこぼしがないようにします。

環境が正常に稼働している間に、組織はすべてのリソースが監視され、計上されていることを確認し、コストの傾向を特定する必要があります。Azureは、リソースのコストを表示し、レポートするためのいくつかの異なるソリューションを提供しています。

Azureコスト管理ダッシュボードに注目する

結局のところ、リソースをどこでどのように使っているか、そしてその関連コストを本当に理解する唯一の方法は、ダッシュボードを使用して、最もお金がかかっている場所を可視化することなのです。Azureコスト管理は、お客様の組織とそのリソースの使用パターンを包括的に見ることができます。これには、Azureのサービスごとのコストと、サードパーティのMarketplace製品ごとのコストの両方が含まれます。
Azure内には非常に多くのコスト計算方法があるため、予約やAzure Hybrid Benefitの割引を考慮したコスト計算ソリューションがあれば、使用中のリソースに関してスマートな意思決定ができるようになります。

Azure Cost Management dashboard

また、データをCSVで他の会計システムや予算管理システムに簡単にエクスポートすることができます。ただしアドバイザーの推奨、予算管理、コスト超過を防止・予測するためのコスト警告機能が組み込まれているため、その必要はありません。

法規制とコンプライアンスの監視

コスト管理と同様に重要なのが、規制やコンプライアンスに関する管理です。
があります。Azure Security Centerには、ISO 27001、PCI DSS 3.2.1、Azure CIS 1.1.0、HIPAA HITRUSTなどの規格への準拠を確認および評価するための規制遵守ダッシュボードが含まれています。

重要な規制基準への準拠を積極的に監視することで、適切なセキュリティが確保されます。また、将来の監査において、コストのかかる頭痛の種やコンプライアンス作業を軽減することができます。

マイクロソフト・チュートリアル:規制に対するコンプライアンスの向上

環境とコストの最適化多くのクラウド環境は流動的であるため、環境のニーズ、パフォーマンス、利用状況を継続的に評価することが重要です。拡張の機会が特定されたら、さらなる対策を講じることができます。使用されているリソースの種類によっては、異なるクラスのリソースやPaaSへの移行が必要となる場合があります。

大規模な環境では、多くのワークロードが使用されていることがよくあります。多くのVMが存在するため、リソースの統合や廃棄の機会があるかどうかを判断するのは難しい場合があります。あまり使用されていないサービスを発見するのに役立つツールの1つが、モニター・サービスです。仮想マシンのインサイトセクションを利用すれば、VMの使用率に関する集計データを見つけ、最も多くのリソースを使用しているVMや最も使用していないVMを発見することができます。

適切なモニタリング戦略があれば、VMのサイズを変更するなどのさらなる措置を講じることができるかもしれませんし、従来は仮想マシン上に置かれていた特定のアプリケーションをコンテナ化して、さらにコストを削減する必要があることが分かるかもしれません。

同様に、ストレージアカウントの節約を見つけるために、「Monitor Storage Accounts Insights」セクションは、指定された期間におけるトランザクション量と使用容量を分析し、節約の機会を明らかにします。このツールは、どのアカウントが不要になり、どのアカウントを統合できるかを特定するのに役立ちます。

リソースを管理する上で見落とされがちなのが、効果的なタグ付けの方法です。使用中のリソースに適切なタグを付けることで、廃棄の対象となるリソースを容易に特定することができます。さらに、タグ付けを行うことで、リソースのライフサイクルを管理するためのレポートを作成することができます。

復旧シナリオ : AWS環境でのデータ保護の構成管理ツール「 N2WS 」では、災害やAWSの停止が発生したときに実行できるシナリオを作成することができます。これにより、最も重要なリソースを重要度の高い順に復旧させ、RTO/RPOを最小化することができます。この機能のドライラン機能により、テストを実施し、これらの復旧を実行するための準備がすべて整っていることを確認することができます。

クロスリージョン/アカウントディザスターリカバリー ：N2WSは、最も包括的なクロスアカウント/リージョンを提供し、ボタンをクリックするだけで全環境をリカバリーすることができます。AWS Backupのバージョンは非常に基本的で、実行が複雑です。

スケジュール ：AWS Backupでは、バックアップのスケジュールを1/12/24時間ごとに設定するよう制限されています。N2WSではそのような制限はなく、バックアップは1分ごとにスケジュールすることができます。

ファイルレベルリカバリー  ： AWS Backupは、Amazon EFSのファイルレベルリカバリーのみをサポートしています。N2WSは、EFS、EC2、S3に対してファイルレベルのリカバリを実行できます（暗号化されたボリュームに対しても）。

Start/Stop Servers (Resource Source Control) : N2WSのこの機能は、EC2インスタンスのアクティブ化と非アクティブ化のスケジュールを設定することが可能である。例えば、非生産用のインスタンスを月曜日から金曜日の午前9時に開始し、午後5時に停止するようにスケジュールすることができる。これにより、お客様はAWSのコストを数千ドル削減することができます。N2WSのお客様であるGett様は、この機能により年間60,000ドルのコスト削減を実現しています。

RDS MySQL & PostgresSQL (S3) : N2WSは、これらのRDSカテゴリをS3に保存することができ、より安価でコールド・ストレージを使用することにより、ストレージコストを大幅に節約することができます。AWS Backupにはこの機能はありません。

自動化 :  N2WSによる自動化のおかげで、お客様は他の重要なトピックにエネルギーを集中させることができ、N2WSにバックアップの世話をさせることができるようになります。つまり、一度必要なポリシーとスケジュールを作成すれば、あとはツールがバックグラウンドでバックアップを行い、何か問題が発生したり、注意が必要な場合はアラートが表示されるのです。N2WSは、保存ポリシーに応じて、S3、Deep Archive、Glacierなどのコールドストレージへの保存を自動化することも可能です。これにより、AWSのコストを大幅に削減することができます。

カスタマーサポート : N2WSは、24時間365日のプレミアムサポートを提供し、必要なときにはサポートします。AWSのサポートは別途費用がかかります。

レポートログとモニタリング : AWSでは、レポートログとモニタリングは別料金で、設定が必要です。N2WSでは、バックアップ、リストア、管理、監査の全活動を監視し、追加コストなしですぐに使えるレポートを提供します。