Amazon Web Services ブログ

私はよく Amazon のイノベーション文化についてプレゼンテーションを行いますが、Amazon の創設者 Jeff Bezos の意義深い引用を取り上げたスライドから始めることが多くあります。 お客様にお会いして、私たちがお客様の創造性や夢の追及をどのように支援できているかについて知るのは楽しいものです。今年に入って、Coca-Cola Company の Patrick と歓談し、AWS Step Functions や他の AWS のサービスを使用して Coke.com の Vending Pass プログラムをサポートした方法を教えてもらいました。このプログラムでは、Coca-Cola Vending Pass を使用したモバイル支払いをサポートしている自動販売機で製品を購入することで、ドリンクがプレゼントされます。参加者が NFC 対応電話をスワイプすると Apple Pay または Android Pay で購入が完了し、自動販売機で個人が識別されてクレジットを獲得できます。このクレジットを貯めることで、将来自販機で無料で購入できます。 スワイプ後、SNS トピックと AWS Lambda 関数の組み合わせにより既存のバックエンドコードに対する 1 組の呼び出しが開始され、販売ポイントがカウントされて参加者の記録が更新されます。残念ながらバックエンドコードは反応が鈍く多少のタイミング依存性があり、更新が行われず Vending Pass 利用者が混乱する可能性がありました。この問題に対する初期のソリューションは非常にシンプルでした。Lambda コードを変更して 2 つの呼び出しの間に 90 秒間のディレイを含めたのです。これにより問題は解決しましたが、処理時間がかかるのはいいことではありませんでした (Lambda 関数の使用料金は 100 ms 間隔のリクエスト所要時間に基づいています)。 ソリューションの費用対効果を向上させるため、チームは AWS […]

本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。 Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見することがあります。これは問題になっているコードの変更を探すことを困難にし、不必要なストレージ料金も引き起こします。以前は、レポジトリをクリーンアップするには、手動で古いイメージを削除するのに時間を費やしたり、スクリプトを書いて実行する必要がありました。 今日からライフサイクルポリシーを使うことで、古いコンテナイメージを自動的に削除するためのいくつかのルールを定義することが可能になりました。ルールが実行された時に影響を受けるコンテナイメージを実際にプレビューで確認することも可能です。これによって、レポジトリはより組織化され問題になっているコードのリビジョンを簡単に見つけられ、そしてストレージコストも抑えられます。 それでは、ライフサイクルポリシーがどのように動くかを見てみましょう。 基本的なルール コンテナを使ってコードをデプロイすることの最も大きい利点の1つは、素早く簡単に過去のバージョンにロールバックできるということです。これにより、リスクを抑えてデプロイすることが可能になります。なぜならば、もし何かおかしかったら、過去のコンテナのバージョンに戻して、失敗したデプロイ以前の状態でアプリケーションを動作させることが簡単にできるからです。多くの人は、数個前のバージョンにロールバックするということはおそらくしないでしょう。もしこういった状況であれば、1つのシンプルなライフサイクルルールとしては、最新の30イメージを保持するというものが考えられます。 最新の30イメージ ECRレジストリの中から、Dry-Run Lifecycle Rules, Addを選択します。 Image Statusには、Untaggedを選択します。 Match criteriaでは、Count TypeにImage Count More Thanを入力します。 Count Numberには30を入力します。 Rule actionにはexpireを選択します。 Saveを選択します。どのイメージがクリーンアップされるかを見るには、Save and dry-run rulesを選択します。 もちろん、数による保持ではなく、コンプライアンスの理由で期限によっていくつかのイメージを保持したいチームも存在します。そういった場合には、90日以前のイメージをクリーンアップするという選択もできます。 最新90日分 先程作成したルールを選択し、Editを選びます。パラメータを変更して、タグがついていないイメージを90日だけ保持する様に変更します: Match criteriaでは、Count TypeにSince Image Pushedを入力します。 Count Numberには90を入力します。 Count Unitにはdaysを選択します。 タグ もちろん90日というのは任意の時間に設定できますが、ある特定の種類のイメージだけもっと長い期間保持するようなポリシーが必要なこともあります。そういった場合で、でも大掃除は続けたいというときには、タグがつけられたイメージだけ削除するというのを検討することも可能です。 こちらのルールのリストは、タグが無いもの、development、staging、そしてproductionなイメージへのルールの例をまとめてみたものです: タグのないイメージは90日以前を削除 developmentタグのついたイメージは90日以前を削除 stagingタグのついたイメージは180日以前を削除 productionタグのついたイメージは1年以前を削除 ご覧頂いた通り、新しいAmazon ECRのライフサイクルポリシーは強力で、必要なイメージだけを保持するのが簡単になり、もう必要のないイメージをクリーンアップしてくれます。この機能は本日よりAmazon […]

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。 もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。 TLS? SSL? SNI? SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。 TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。 SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。 フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。 ALBの証明書スマートセレクション ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択し、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。 ALBでSNIを利用する ここではウェブサイトの例として、VimIsBetterThanEmacs.comとVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。 最初に、コンソールから私のロードバランサを選択し、listenerタブに行き、”view/edit cerfiticates”を選択します。 次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。 これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。 aws elbv2 add-listener-certificates –listener-arn <listener-arn> –certificates CertificateArn=<cert-arn> 知っておくべきこと ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。 […]

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー11月の配信についてご案内させて頂きます。初めてご紹介するNLB (Network Load Balancer) を中心としたELBのセッションをはじめ、今月も様々なテーマを取り扱います。 また今年もAWS re:Inventの開催期間中に現地からの生中継で最新アップデートをお伝えする回を予定しておりますので、こちらもぜひご登録いただければと思います。                   11月の開催予定 サービスカット 11/1(水) 18:00-19:00 Amazon EMR 11/15(水) 18:00-19:00 ELB Update – Network Load Balancer(NLB)と関連サービス 11/22(水) 18:00-19:00 AWS WAF – OWASP Top10脆弱性緩和策 – ソリューションカット 11/9(木) 12:00-13:00 Amazon Pinpoint で始めるモバイルアプリのグロースハック  ※ 通常の開催曜日と異なりますのでご注意ください 11/21(火) 12:00-13:00 AWS上の位置情報 12/1(金) 12:00-13:00 AWS […]

つい先日までのLumberyardとは違います。もし、しばらく離れられていたなら新しいLumberyardを見ていただく良い機会です。 新たなビジュアルスクリプティングとアニメーションツールが実装された Lumberyard 1.11を こちら からダウンロードできます。 これまでの19ヶ月で オリジナルのコードベースの60%を入れ替えており、3,300以上の改善と、500個の無料アセットを追加し、皆さんゲームプロジェクトでご利用いただけるようになりましが、今回のリリースはエンジンと皆さんの制作体験上とても重要なターニングポイントになります。なぜなら… 新アニメーションシステムとしてEMotion FXが導入され、CryAnimation (GeppettoとMannequin)と置き換えられました。エンジニア不在でも、ブレンドツリー、ステートマシン、ブレンドスペース、モーションツリー等の機能を使って10分程触っていただくだけで高品質なアニメーションを制作できます。EMotion FX はこれまでにEAやUbisoftのようなスタジオで10年以上に渡って利用されてきていましたが、今回Lumberyardの永続的なパートとなり、強力かつ扱い易いソリューションをアーティストの皆さんに提供できることになました。(1.11の新たなサンプル中に我々のキャラクターRinがありますのでお試しください。サンプルへのアクセス方法は こちら) Script Canvasが、これまでのFlow Graphと置き換えられ、新たなビジュアルスクリプティングソリューションになりました。Script CanvasでLuaやC++と同様にゲーム内の挙動をオーサリングできるソリューションとなります。これにより、必要とされるエンジニアがいない場合でもEMotion FXで作成されたクールなアニメーションをScript Canvasで即座にキャラクターの挙動を制作できるということになります。プログラミング経験に乏しくても、Script Canvasのノードインターフェースで、品質の高いゲームプレイ体験を創り出していただけるようになります。Script Canvasで皆さんの創り出されるものを楽しみにしています。(Script Canvasの開始方法やチュートリアルは こちら の最新ドキュメントをご参照ください) さらに新たに、将来を見据え CryEntity コンバートツールを用意し、CryEntityを新たなComponent Entityフォーマットにコンバートできるようにしました。これにより、将来Lumberyardの新たな上システムの利点を享受し安定した土台の上にゲームを構築できるようになります。まだまだ沢山の作業がありますが、素晴らしい開発コミュニティの皆さんと共に進化と成長を続け育てていくことはとてもエキサイティングなことです。 (コンバートツールのご利用は こちらのチュートリアルをご参照ください)   EMotion FX   Script Canvas 400以上の追加アップデート 今回のリリースには沢山の更新がありますので詳しくは こちら をご参照ください。 新たに3つのCloud Gemが加わり、ゲーム中のプレイヤーの状態を簡単に観測したり、 Amazon Polly を活用したSpeech Gemでテキストを読ませたり、Amazon Lex による音声認識をゲームプレイで活用したりできるようになりました。 新規プロジェクトのスタート地点として、新たに2つのプロジェクトテンプレートが加わり、デフォルトのテンプレートはGem群を有効にしてシンプルなレベルからのスタートとして、空のテンプレートは最低限の素の状態のテンプレートとなります。 新たなGetting Started Guide（初心者ガイド）により、以前よりもさらに素早くLumberyardを始めていただけるようになりました – 迷路脱出ゲームをお友達と簡単にシェアできてしまいます。ドキュメントは […]

AWS Schema Conversion Tool (AWS SCT)とAWS Database Migration Service (AWS DMS) はコマーシャルデータベースからAmazon RDSの様々なデータベースエンジンへの移行を簡単に行えるようにするツールです。 AWS SCTはプロプライエタリなデータベースをオープンソースデータベースへ移行する際に手助けを行います。移行元のデータベーススキーマや多くのカスタムコードを移行先のデータベースに適した形へ変換を行います。ツールが変換を行うカスタムコードには、ビュー、ストアード・プロシージャー、ストアード・ファンクションを含みます。一方、自動的に変換が出来ないものとしては、手動で変換が行いやすいように該当箇所を抽出します。AWS DMSはダウンタイムを最小限に抑えながら、簡単・安全にデータを移行することを可能にします。 データベースエンジンを変更することは大変な作業ですが、Amazon Auroraのようなスケーラブルでコスト効率がいいフルマネージドサービスの恩恵を受けやすくなる利点があり、移行を行う価値があります。AWS SCTとAWS DMSを用いることで、単一のデータベースからオープンソースへの移行を評価し、計画を行うことが容易になります。 AWT SCTアセスメントレポートを生成し、これらのツールを使用することで、データベースを移行することが、どのくらい簡単であるかということがおわかりになると思います。 以下のブログやビデオは、オープンソースデータベースへ移行するための情報の一例です。 How to Migrate Your Oracle Database to PostgreSQL How to Migrate Your Oracle Database to Amazon Aurora Migrate from SQL Server or Oracle into Amazon Aurora using AWS DMS もし、数百・数千のデータベースを持っていた場合は 評価レポートを作成し、1つ、2つ、またはさらに10のデータベースをオープンソースデータベースへ移行することは、簡単なプロセスです。 おそらく、どのアプリケーションが利用しているデータベースを最初に移動するか判断するための材料は十分お持ちだと思います。 […]

ユーザーの質問に対する回答を持っていますが、ユーザーが質問をして適切な回答を得る良い方法が必要です。多くの場合、ユーザーはヘルプデスクに電話するか、サポートフォーラムに投稿しますが、ストレスが高まり、組織にとってコストがかかります。チャットボットがあれば、顧客にとって便利でしょう。興味深いことに、最近の調査は、ユーザーの 44% が人間と話すよりもチャットボットと話すことを望んでいます。 この投稿では、QnABot (「キューアンドエーボット」と発音) と呼ばれるサンプルソリューションについて説明します。 QnABot は、Amazon Lex と Amazon Alexa を使用して、「質疑応答」のための便利なインターフェイスを提供します。これにより、ユーザーは質問をして関連する回答をすばやく得ることができるようになります。 Amazon Lex を使用すると、音声とテキストチャットアクセスの両方を既存のアプリケーションに統合できます。Amazon Alexa を使用すると、Amazon Echo または Alexa Voice Service 対応デバイスを自宅や職場で使用しているユーザーに、ハンズフリー音声インターフェイスを提供できます。QnABot は両方の長所を最大限に活用しています。 QnABot は、Amazon Elasticsearch Service (Amazon ES) を使用して質問と回答を検索可能にします。ユーザーが質問をすると、Amazon ES の強力な全文検索エンジンが背後で使用され、その質問に最も合った回答が検索されます。 以下のセクションでは、次のことを行う方法について説明します。 QnABot を AWS アカウントにデプロイする。このブログでは、お客様が既に AWS を利用していることを前提としています。アカウントをまだ作成していない場合は、AWS ホームページの [Create an AWS Account] を選択してください。 コンテンツデザイナー UI を使用して、質問と回答を QnABot に挿入する。 ウェブクライアント UI で音声またはチャットを使用して質問をする。 […]

AWSでSAP Partner Solutions Architectを務めるSabari Radhkrishnanによる記事です。   Amazon Web Services(AWS)とSUSEは、SUSE Linux Enterprise Server(SLES)を共同のSAP顧客に提供できるよう、長年に渡って協力してきました。AWSが2012年にSAP HANA Oneを含むSAPワークロードのプラットフォームとして初めて認定されてから、お客様はAWS上でSAPアプリケーションを実行するためにSLESオペレーティングシステムを使用してきました。AWSが2014年にSAP HANAのインスタンスとして認定されてからは、お客様はAWS上のSAP HANAの展開にもSLESを使い始めました。2015年に、SUSEの独自のサブスクリプションプログラムを通じて、SLES for SAPがAWS上で利用可能になりました。2016年には、SLES for SAPをオンデマンドイメージとしてAWS Marketplaceから利用できるようになり、既存および新規のお客様がミッションクリティカルなSAPワークロードをより簡単に始められるようになっています。 共同のSAP顧客に最高の体験を提供するための継続的な取り組みの一環として、2017年第4四半期にAWSのオファリングとしてSLES for SAPがAWS Marketplaceから利用できるようになることを本日発表します。これは、約7年前にSLESを提供開始して以来、AWSとSUSEによる2つ目の共同リストになります。SAP HANAのようなインメモリ・ワークロード用に特別に設計されたX1およびX1eインスタンスの提供により、開発、テストおよび本番環境のSAPワークロードをAWS上で稼働するお客様が増えています。 新しいSLES for SAPは、AWSとSUSEの共同サポートが受けられ、競争力のある価格で提供されるため、AWS上でSAPワークロードをより簡単に実行できるようになります。AWSとSUSEは、AWS上のSAPワークロード向けのOSを最適化し、強化するために協力し続けます。 SLES for SAPには、HAE(High Availability Extension)が含まれているため、SAP HANAインスタンスをアベイラビリティゾーンをまたがってシームレスにフェールオーバーできます。このソフトウェアには、ページキャッシュ管理やSAPワークロード用に最適化されたカーネル設定といった様々な拡張機能も含まれています。さらに、SLES for SAPイメージは長期サービスパックサポートに対応しているため、お客様は最新から2つ前のサービスパックを最大18ヶ月間使用することができます。SLES for SAPを使用する利点の詳細は​​、SUSE Webサイトを参照してください。 お客様は、AWS Quick Start for SAP HANAを使用して、SAP HANAワークロード用のSLES for SAPを簡単に始めることができます。このクイックスタートは、AWS、SAP、そしてSUSEのベストプラクティスに従って、SAP HANAの導入に必要なインフラストラクチャの構築と設定を1時間以内で行うのに役立ちます。 お客様は、引き続きSUSEのBYOS(bring-your-own-subscription)プログラムを活用することで、既存のサブスクリプションを使用してAWS上でSAPワークロードを実行することができます。詳細は、 http://aws.amazon.com/suseを参照してください。SAP on AWSの詳細については、http://aws.amazon.com/sapをご覧ください。 この発表の詳細については、SUSE […]

過去にも触れましたが、AWS ブログチームは皆さんが膨大な情報に圧倒されることなく、できる限り多くの AWS リリースや公開した内容について把握して頂けるように努めています。バランスを上手く取るため、定期的に新しい情報を皆さんにお届けし、こちらのリストも片付けるようにしています。今日ご紹介するのは次の通りです。 S3 オブジェクトのクロスリージョンレプリケーションをモニタリング スポットフリーインスタンスのタグ 12 のサービスとの PCI DSS コンプライアンス WorkDocs の HIPAA 利用資格 VPC サイズ変更 AppStream 2.0 グラフィックデザインインスタンス ServiceNow の AMS コネクタアプリ クラウド内の Regtech 新しく改訂されたクイックスタート では、早速始めましょう。 S3 オブジェクトのクロスリージョンレプリケーションをモニタリング S3 クロスリージョンレプリケーションについては数年前に説明しました。その時には、ソースバケットでバージョニングを有効にし、指定するリージョンとバケットを選択するだけでした。手動でレプリケーションのステータスを確認したり、ソースとデスティネーションバケットのインベントリ (毎日または毎週) を作成することができます。 クロスリージョンレプリケーション監視 (略名: CRR Monitor) ソリューションは、リージョンに渡るオブジェクトのレプリケーションステータスを確認し、ほぼリアルタイムでメトリクスやエラー通知を提供します。 詳細については「CRR Monitor の導入ガイド (CRR Monitor Implementation Guide)」と「CRR Monitor を導入するための AWS CloudFormation テンプレート (AWS CloudFormation template […]

EC2 スポットインスタンスは EC2 のコンピューティング容量をオンデマンドレートの 90% オフまで許可することができます。特定のサイズのインスタンス数をリクエストできるようにしてから、スポットフリートと自動スケーリングスポットフリートをサポートすることでスポットインスタンスをより便利そして柔軟にし、ユーザーが希望するレベルのコンピューティング容量を維持できるようにしました。 EC2 ユーザーはこれまでも EBS ボリュームをアタッチした状態を維持しながら実行中のインスタンスを停止させることができ、インスタンスの実行が再開すると停止した所から自動的に始めるアプリケーションの使用を可能にしていました。 スポットワークロードの停止と再開 そして本日、こうした 2 つの重要な機能を組み合わせ、容量が利用不可能になった場合または入札価格以下になった場合にインスタンスを停止 (終了する代わりに) することで、スポット入札やスポットフリートをセットアップできるようにしました。停止状態のインスタンスにアタッチしている EBS ボリュームは EBS-backed ルートボリュームと同様にそのまま維持されます。キャパシティが利用可能になるとインスタンスが開始し、アプリケーションのプロビジョニングや EBS ボリュームのセットアップ、データのダウンロード、ネットワークドメインへの参加などに時間を費やす必要なく引き続き実行することができます。 AWS をご利用されている多くのお客様がアプリケーションを強化してチェックポイントの作成と活用を行い、EC2 プロセスでの開始/停止の機能を利用することで耐障害性を向上させています。そうしたお客様はこのようなアプリケーションをスポットインスタンスで実行できるようになり、平均 70%-90% の節約を実現できます。 インスタンスが停止している間、EBS 最適化、ユーザーデータ、Ramdisk ID、Delete on Termination の属性を変更することができます。停止状態にあるスポットインスタンスはコンピューティング時間に対して料金を請求することはありませんが、アタッチ済みの EBS ボリュームの容量には通常料金が適用されます。 スポット入札またはスポットフリートの作成や停止/開始の使用を特定する方法については次をご覧ください。 主要事項 この機能はスポットインスタンスが利用可能なすべての AWS リージョンで今すぐご利用いただけます。これは新しい EC2 インスタンスと EBS ボリュームの秒単位による請求で上手く機能するように設計されており、スポットインスタンスが提供する以上のコスト節約の方法としても可能性があります。 EBS ボリュームは常に特定のアベイラビリティーゾーン (AZ) 内にあります。そのため、スポットとスポットフリートは特定の AZ が常にその AZ で再起動するようにリクエストします。 幅広く様々なインスタンスタイプが含まれている可能性のあるスポットフリートとこの機能を組み合わせる場合はご注意ください。フリートの構成は時間が経過するに連れて変更することもあるので、アカウントの IP アドレスや […]