不用意にリソースを変更すると、すぐにライセンス違反が起きてしまい、追加課金される。気付かないまま長期間違反を続けると、後日ベンダーから巨額の請求をされることになる。それであれば、フルキャパシティーライセンスの方が、自由度が高くて良いということになるが、これはそもそも高額なので、コスト適正化の面ではジレンマだ。

　また、障害時に備えた仮想サーバの物理サーバ間移動の設計などによってもライセンス違反は起きがちだ。図3はデータベースソフトのライセンスの例だが、プロセッサライセンスで契約している場合だと、CPU数の少ない物理サーバから多い物理サーバに仮想サーバを移動させる設定では、ライセンス数が余計に必要になってしまう。気付かずにそのまま運用しているとライセンス違反となる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図3　仮想環境で起きがちなライセンス不足の例　※Xeonのコア係数の場合（出典：ウチダスペクトラム）

　これだけでも煩雑なようだが、製品によってはユーザータイプを分類して詳細な条件をつけるというように、複雑きわまりない条件で課金される場合もある。また使用場所（国や地域、使用場所限定など）、使用期間、使用目的なども制限されていることがあるので、十分に注意しなければならない。

コラム：Oracleのマルチコアプロセッサとクラウドに対するライセンスの考え方

　図3のOracleの場合はマルチコアプロセッサにそれぞれの製品別のコア係数（多くは0.5、SPA RC T3などは0.25、Itaniumなどは1.0）を組み入れた計算式（図中）によってライセンス数が導かれる。クラウドプラットフォームではAWS・EC2・S3・Azure上での使用を前提にしており、Standard Editionではインスタンスのサイズで価格が決まる。4バーチャルコア以下の場合は、1ソケットとしてカウントし、それより多くのバーチャルコアがある場合は、インスタンスのバーチャルコア数を4で割り、小数点以下を切り上げてカウントする。他にもNamed User Plusライセンスと言って使用するユーザー数によるライセンスもある（最小契約数の制限がある場合もあり）。