インスタンスのネットワークインターフェースが1つのようですので何方でも大丈夫です。IPが関連付けられます。こっちはUTCなので、JSTの時差分の9時間ずれています。ntpdを普通に動かしただけでは大きなずれは補正されません。曖昧だったり明らかに誤っている記述が複数存在しており、意図や設定内容が文章に正しく反映されているか疑問があります。どれかに不明確な点があります。これらが明確になってないと、トンチンカンで無意味な「対策」になっていたり、考慮漏れによりわかりやすい大穴が残っていたりすることがままあります。したがって、安全かどうかの判断はできません。「極めて」という修飾が何を比較対象としているのかについても明確になっておらず、一般的に想定されるセキュリティレベルより遙かに高いことを意図しているとも考えられ、なおさら安易に判断できません。個の銅バッジ3awsのセキュリティグループにセキュリティグループを関連付けるとどうなりますか?セキュリティグループが設定されたインスタンスに対してアクセス制御ができます。設定したインスタンスからのSSH接続を許可します。別のツールを使うか作り込むかになると思います。トピックスをパブリッシュするスクリプトを定期的に動かせば実現できる気がします。個の銅バッジ3Route53にネームサーバーを移行後、GoDaddyで購入したOffice365のメールが受信できなくなりました。あるドメインに対するメールをどこのメールサーバーに配送するかは、そのネームサーバーからMXレコードで提供する情報です。GoDaddyのネームサーバーを利用していた時は必要なレコードを自動的に追加してくれていただけなので、ネームサーバーを変更したらそれらを自分で追加しなければいけませんし、さもなくばそのドメイン宛のメールの配送ができなくなります。そこで本来はOffice365の方で必要なレコードが調べられるはずですが、それが管理画面に出てこないということは、GoDaddy専用版だから表示していない、と考えるのが妥当ではないでしょうか。この部分がおかしいです。ダブルクオーテーションでくくってやらなくてもJSON.stringifyがうまくやってくれます。エスケープしたダブルクオーテーションを含めてしまうと、余計なものがついてしまい無効なtokenが生成されてしまいます。「AWSのマネージドサービスで」という前提で考えると無さそうです。デーモンプロセスとして動かすのが良い気がします。パケットを出そうとしているのだと思います。付けるといいと思います。なく、起動時に自動的で設定されるグローバルIPアドレス/パブリックIPアドレスを使ってもいいです。アドレスへのアクセスの制限にも例がある通りであり、質問文に記載された範囲では問題なさそうです。1点、質問文に記載されていない範囲で気になりました。キーと合わせて使用します。2001:DB8:1234:5678::/64)。個の銅バッジ3SSHで急にサーバ接続できなくなった。refused「正常に接続できるインスタンス」にアタッチしたということですが、「正常に接続できるインスタンス」に「問題のあるボリューム」をマウントしてみてください。マウントができれば、必要なファイルを「正常に接続できるインスタンス」にコピーできるので、それを使って「正常に接続できるインスタンス」の方で復旧できます。(マウントできれば、「問題のあるボリューム」のファイルを修復することも可能ですが、それよりも必要なものだけコピーした方が早いと思います。この不具合は、SSHサーバーに関連するファイルが壊れたためだと思います。インスタンスの方は立ち上がっていると思うので、AWS側のマシンの不具合とはいえないので、再起動等いろいろ試していますがそれでは復旧できないと思われます。