前置き
たとえば、自社で開発したサービスプロダクトAが、コアドメインではなくなってきて、徐々に一般（汎用）ドメインになってきたという状況を想定してください。
リソース効率向上のためのシェア
この際に、「自社だけで保有するのはリソース効率的に勿体ない。」 という理由から、なるべく使っていない時には、他の企業にも一時利用のようにシェアするという再利用戦略を考えたいという状況があると思います。
この時には、コスト削減の観点から、インフラ基盤の運用スタイルをコンテナ運用からサーバーレスアーキテクチャにして、AWSにインフラ基盤運用を任せたとします。（これが自然なサーバーレスへの移行の動機）
クラウドに障害が起きた！
この時、仮にAWSに障害が起きてしまい、このサービスプロダクトAがダウンするようなリスクには、自社としてはどう対処すべきでしょうか？
SaaS型のビジネスモデルを考える上で、これは極めて重要なリスクシナリオなので、必須で考慮しなくてはなりません。
AWSのようなクラウドプロバイダーにインフラ運用を任せる（＝サーバーレス化する）ことは、「インフラ管理のリスク」を手放す代わりに、
「クラウドプロバイダーへの依存リスク」を受け入れる
ことを意味します。
そこで、AWS自体に障害が起きた場合、自社でできる対処法を考えてみましょう。
その障害の規模によって、以下の2つに分別されます。
1. 「一部」の障害（例：単一AZ障害）への対策
これは、AWSリージョン内の特定のアベイラビリティゾーン（データセンター群）で障害が起きるケースです。
対処法
AWSのベストプラクティスに従う（標準装備）
詳細
AWS Lambda, Amazon S3, DynamoDBといった主要なサーバーレスサービスは、
デフォルトで複数のアベイラビリティゾーン（マルチAZ）にまたがって冗長化
されています。
結果
1つのAZが停止しても、自動的に他の正常なAZで処理が継続されるため、自社（および顧客）は障害に気づくことすらなく、サービスは継続します。
これは、サーバーレスアーキテクチャを採用する最大のメリットの一つです。
2. 「リージョン全体」の障害（例：東京リージョン全滅）への対策
これが、ご質問の核心である「AWSに障害が起きてサービスがダウンする」という、最も深刻なリスクシナリオです。
この場合、対処法は 「技術的な対策」と「ビジネス的な対策」 の2つがあります。
技術的対策：マルチリージョン・アーキテクチャ
対処法
サービスプロダクトAを、AWSの別のリージョン（例：東京リージョンと大阪リージョン）の両方にデプロイしておきます。
仕組み
Amazon Route 53のようなDNSサービスを使い、両リージョンに対してヘルスチェック（死活監視）を行います。
もし東京リージョンがダウンしたら、Route 53がそれを検知し、自動的にすべてのトラフィックを正常な大阪リージョンへと振り向けます（フェイルオーバー）。
トレードオフ
・メリット
最高の可用性を実現できます。
・デメリット
構築・運用コスト（特にデータを2つのリージョン間で同期し続けるコスト）が劇的に増加します。
ビジネス的対策：SLA（サービスレベル契約）によるリスク管理
対処法
技術でリスクをゼロにするのではなく、契約でリスクを管理します。
仕組み
①. SLAの締結
サービスを利用する他社（顧客）と、「本サービスの可用性は99.9%を目標とします」といったSLA（サービスレベル契約）を結びます。
②. 免責事項の明記
その契約書に、
「ただし、AWSのリージョン障害など、当社のコントロールを超えた不可抗力による停止については、この限りではない」
といった、免責事項を必ず明記 します。
③. 返金ポリシー
あるいは、SLAを守れなかった（例：99.9%を達成できなかった）月は、利用料の10%を返金する、といったペナルティを定めます。
ここまでのまとめ：どう判断すべきか
以上のことから、以下の２軸で定性的に判断することが望ましいと言えます。
汎用ドメインである
そのサービスが止まっても、自社や顧客のビジネスが即座に致命的なダメージを受けるわけではありません（コアドメインではないため）。
リソース効率化が目的
そもそも、この戦略はコストを最適化するために始まっています。
以上の点を考慮すると、
莫大なコストをかけて「技術的対策（マルチリージョン）」を追求するよりも、
「ビジネス的対策（SLA）」を結び、コストとリスクのバランスを取る
方が、はるかに合理的であるケースが多いです。
自社の対処法としては、まず
「このサービスの停止は、顧客にとってどれくらいの損失に値するか？」
を評価し、その損失額がマルチリージョン化のコストを上回る場合にのみ、技術的対策に踏み切る、という経営判断が求められます。
補足 - インフラ運用業務へのECRS原則の適用
インフラ運用のような
「自社のコアな価値（コアドメイン）ではないが、必須のプロセス」を外部委託する（例：サーバーレス化する）
という経営判断は、まさしくビジネスアーキテクチャ全体に対してECRSを適用するというメカニズムそのものです。
ECRSのE（排除）とR（入れ替え）
・E (Eliminate - 排除)
自社の開発チームの業務プロセスから、
「サーバーのパッチ当て」「OSの監視」「Kubernetesのバージョンアップ」
といった、「差別化につながらない重労働」 を排除します。
・R (Rearrange - 入れ替え)
その排除した責務を、単になくすのではなく、「インフラ運用」の専門家であるAWSやGoogleといった外部のクラウドプロバイダーに担ってもらうように、責務の配置を入れ替えます。
ボトルネックとしてのインフラ運用
そして、その動機付けはまさに、費用対効果（ROI）のボトルネックです。
インフラ運用は、それ自体が利益を生む（リターン）ことはなく、コストだけがかかる典型的なコストセンターです。
ビジネスがスケールするにつれ、このコストセンターの維持・管理にかかる人件費や時間は増大し、企業全体の成長におけるボトルネックとなります。
🧑🍳 レストランのアナロジー
・レストラン（自社） のコアドメインは、「美味しい料理を作ること」です。
・しかし、レストランの運営には「皿洗いや床掃除（インフラ運用）」も必須です。
・もし、ミシュランシェフ（優秀な開発者）が、営業時間の大半を皿洗いに費やしていたら、明らかにこれは組織全体のボトルネックです。
ここでECRSの適用は以下のように作用します。
E (排除)
シェフの仕事から「皿洗い」を丸ごと排除します。
R (入れ替え)
ただし、「皿洗い」自体は、そのまま無くしたら食品衛生的にアウトです。
そこで、専門の清掃業者（クラウドプロバイダー）に、皿洗いと清掃を委託します。
結果
シェフは料理という本質的な価値（コアドメイン）に100%集中できるようになり、レストラン全体のパフォーマンスが向上します。
結論：メカニズムとしてのECRS
クラウド活用やサーバーレス化という技術的な選択が、単なる技術トレンドではなく、
「インフラ運用がボトルネック化したコストセンターになっている」
という経営課題を、ECRSというプロセス改善原則に則って解決しようとする、合理的な経営戦略・ビジネスアーキテクチャ上の判断です。