cocone engineering

こんにちは。インフラ室のNです。

ココネではサーバーのインフラ環境に AWS を使用しており、 AWS Resource Access Manager (RAM) により VPC サブネットを AWS Organizations 内にある他のアカウントに共有し、そこに EC2 インスタンスなどを起動するというような使い方をしています。
サブネットの共有は、同じ Organizations のアカウントに対してしか共有できない制限があります。では共有している状態で Organizations から離脱したら、これらのリソースはどうなってしまうか試してみました。

最初に結論

共有先のアカウント上で当該サブネットが見えなくなり、リソースを操作する処理の中で Elastic Network Interface (ENI) を作成しようとする挙動は失敗します。現状で動いているものには即座に影響は出ませんが、時間が経つにつれ影響が出る可能性があります。AWS側で自動的に ENI を削除または再作成などすることがあるので、そうなった場合に影響が出ると思います。

各サービスの影響

※すべてのサービス、すべての操作を確認したわけではないので参考程度にとらえていただければと思います。

EC2

すでに起動しているインスタンスには影響がほぼなく、停止や再起動、タイプ変更などは問題なくできました。オートスケーリングでのキャパシティ増加は、インスタンスが新規に起動、 ENI も新規に作成されるためできません。

ELB

通常では ALB の IP アドレスが変わると ENI も変わるので、おそらく動作しなくなると思いましたが、検証中は対象の ALB の IP アドレスが変わらず、この挙動が確認できませんでした。もしかしたら IP アドレスを変えられなくなって、同じものを維持し続けるのかもしれません。

ECS

タスク定義の更新などの後、サービスのデプロイを行うとコンテナ実行環境に付与されている ENI が再作成されるため、デプロイは行うことができません。これは EC2 と Fargate どちらを使っている場合でも同じです。

Lambda

関数が非アクティブになるなどで、 Lambda が使用する ENI が削除されてしまっている場合は ENI を作成できないため、関数の実行が失敗になります。

RDS

DBインスタンスの再起動やフェイルオーバーは可能ですが、インスタンスのタイプ変更やリーダー追加は行うことができません。

ElastiCache

Redis のクラスターで試しました。シャードやノードを増やしたり、ノードのタイプ変更を行うことができません。

最後に

EC2 インスタンスへの影響は軽微でしたが、フルマネージドのサービスでは既存リソースの変更処理でも可用性を持たせるために ENI を作成して付け直すなど色々してくれているので、いくつかの処理はうまく動作しませんでした(とはいえ普段の運用ではこんな状況を起こすことはないので、あまり気にはしないのですが)。

今回検証していないサービスでも共有サブネットを使えるものがありますのでそれらの操作も何らかの影響があると思います。