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

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

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

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

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では、バックアップ、リストア、管理、監査の全活動を監視し、追加コストなしですぐに使えるレポートを提供します。