750時間の無料AWS EC2サーバーt2.microインスタンスが1か月未満で85%を超えるのはなぜですか?


2

2019年2月21日と2019年3月14日の12か月間、750時間でAWS EC2サーバーt2.microインスタンスの使用を開始しました。

ここに画像の説明を入力してください


2019年2月21日から1つのインスタンスのみを開始し、今日まで中断することなく実行し続けています。これは、654時間ではなく、500時間程度です。ログイン後のAWSポータルのアカウントでも、次のインスタンスが表示されます。

ここに画像の説明を入力してください


次に何をすべきか、なぜそれが起こるのか教えてください。このトピックに関するすべてはここに書かれています。しかし、それは私の問題を明確にしません。私は複数のドメインでいくつかの同様の質問を見ましたが、問題は誰かが1つだけでなく複数のインスタンスを実行することだと言いました...しかし、私はまだ停止または中断していない1つだけがあることがはっきりとわかります...私は使用しませんAWSデータベースがありますが、AWSサーバーがあるフランクフルトに近いGoogle Cloud PSQL DB ...

たぶんこれは役に立ちます:

ここに画像の説明を入力してください


ここで興味深い文は次のとおりです。「最も一般的な制限のいくつかは、時間ごと、時間ごと、または要求(API操作とも呼ばれるサービスに送信する要求)によるものです。」私はそれを理解していない、おそらく愚かな質問-申し訳ありませんが、私のウェブ上でより多くのGET / POSTリクエストが発生するほど、時間が早くなりますか?または、より多くの端末SSLセッションインスタンスを使用するほど時間がかかりますか?

さらに、端末とサーバーに1日2回4時間接続し、Webページに0人の訪問者がいます。私は2つのポートを使用します。1つは本番用(nohup&およびscreenコマンドを使用して自分のサイトで永続的にスレッド化する)、もう1つは同時に開発用です。

AWSサポートに連絡しましたが、今のところ無料アカウントである限り、重大度は低であるため応答しません。私は3日残っていると思うし、支払わなければならない...なぜ、そしてなぜ3月の最初の日で時間の計算をリセットしなかったのか理解できないのですか?


その他の証拠:

ここに画像の説明を入力してください


そして、ここで答えたおかげで解決策が見つかりました、2つのインスタンスが実行されています、フランクフルトとオハイオ:

ここに画像の説明を入力してください


しかし、オハイオ州のインスタンスをシャットダウンした後、別のインスタンスが作成され、許可なく再び開始されました。

ここに画像の説明を入力してください


インスタンスを永続的に終了するには、自動スケーリングを無効にします。

ここに画像の説明を入力してください

回答:


5

これの唯一の考えられる原因は、実際には1つではなく2つのインスタンスが実行されていることです。コンソールの他のすべてのリージョンでEC2を確認し、他のインスタンスを見つけます。

時刻月の最初にリセットされ、このラインアイテムは使用量に依存しません-必要なトラフィックの量は、マシン時間の計算方法を変更しません。API要求は、マシン時間の計算方法を変更しません。以前は、インスタンスでのイベントの停止/開始(単純な再起動を除く、電源オフ/電源オンに類似)は、各イベントで1時間ずつ時間を膨張させましたが、これは数年前からありませんでした。

654÷2÷24 =月の最初から2つのインスタンスが13.625日実行されています。


わかりました、あなたは正しいです、私はフランクフルトとオハイオの2つのインスタンスを実行していますが、...これはAamazonの会社のある種のトリックですか?非常に辛抱強く詳細に...なぜ彼らはオハイオで私の許可なしにさらに別のインスタンスを開始したのですか?私が新しいことを利用して、支払いをさせるには?そうでなければ私はこれが私の更新質問を参照してください...起こることができる...私はオハイオ州のインスタンスを停止し、私の許可なし=新しいが作成された方法を理解していない
マレクBernád

4
Amazonがこのようなゲームをプレイすることは知られていない。サポート付きのダイアログを維持し、AWSが数ドルからあなたをいじめようとしていないと仮定します。このような予想外の請求を避けるのに役立つと期待しています。すべての地域が独立しているため、新しいユーザーが混乱することはよくあります。彼らがあなたの請求書を追加料金で梱包しようとした場合、彼らはあなたに正確にそれらの料金を避けるのを助けることを意図したメールを送らないでしょう。
マイケル-sqlbot

3
新しい問題の場合:-envインスタンス名と自動リスポーンは、これが環境の動作を維持するように設計されたElastic Beanstalkによって制御されるインスタンスであることを示唆しているため、自動スケーリング(iirc)を使用して死ぬマシンを自動的に置き換えます。Beantalk環境を起動した場合、間接的に、サービスにはこれを行う許可がありました。
マイケル-sqlbot

わかりましたが、登録中にElastic Beanstalkインスタンスが必要であることを確認できたことを理解していますか?しかし、なぜオハイオ州で新しいインスタンスを作成したのは、フランクフルトのインスタンスだけが必要だったからです...なぜElastic Beanstalkがフランクフルトのインスタンスの上にauto_scalingルールを作成しなかったのですか?
マレックベルナード

2
(1つのインスタンスの)独立したスケーリンググループがオハイオとフランクフルトに存在します。誤って作成された可能性があります。コンソールで簡単に切り替えられないか、間違った地域にAPIの例を使用します。サポートにより、ログに記録されたイベントを検索して、これがいつ発生したかを確認できます。
ジョンマホワルド
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.