.png)
新しい VPC ca-central を作成しました。他の場所と同じ手順に従いました。
- 新しい VPC (これにより、広く開かれた ACL が作成されました)
- 3 つのサブネット(各アベイラビリティゾーンに 1 つずつ)、CIDR は適切に間隔を空けます
- ルーティングテーブル上のすべてのサブネット
- そのルーティングテーブルは0.0.0.0/0をインターネットゲートウェイにルーティングします
- インスタンスはポート22を受信用に開き、すべてのトラフィックを発信用にするsecGroupを使用します。
- すべてが適切にvpcに接続されている
そこで作成された T3 インスタンスに、ssh、スポット、オンデマンド経由で接続できません。当社の AIM の代わりに、Ubuntu 用のファクトリー AIM を使用しようとしましたが、同じ結果でした。どの試行もタイムアウトします。テストでは、secGroup のすべてのポートを許可しましたが、役に立ちませんでした。すべてを消去して最初から作成しましたが、役に立ちませんでした。
何を間違えたのか分かりません。まったく同じ設定が us-east-1 にあり、問題なく動作します。私が何を間違えているのか、誰か分かるでしょうか?
PS: インスタンスには、VPC に接続された VNIC 上の内部 IP にリンクされたパブリック IP があります。
編集: VPC の CloudFormation スクリプト:https://pastebin.com/VK3Cb6j8
編集: VPS は問題ありません。T2 インスタンスは動作しますが、T3 インスタンスは動作しません。
答え1
さて、カスタマー サポートと何度かやり取りした後、次の回答を得ました。
「お待ちいただきありがとうございます。社内チームと協力し、他のリージョンが完全に機能するようにしました。これで、SSH 経由でインスタンスにアクセスできるようになります。」
そして、今はうまくいっています。どうやら、管理画面からはアクセスできない、リージョンやインスタンス タイプを制限する隠し設定がいくつかあるようです。他の人もこの問題に遭遇した場合に備えて、この回答をここに残しておきます。残念ながら、開発者サポートに 1 か月分支払う必要があります。そうすれば、開発者サポートに連絡して、自分では解決できなかった明らかに開発者の問題であるものを調べてもらうことができます。CS サブスクリプションの払い戻しを依頼するつもりですが、期待はしていません。いずれにせよ、問題は L2 サポートによって解決されました。
編集: 彼らは、この問題を解決するためにカスタマー サポートに料金を支払う必要はないという私の主張を受け入れ、私に返金してくれました。最終的に、隠れた制限の変更を処理するのは彼らなので、アカウントと請求の問題でこの問題を提起することを勧めています。