MENU

AWS App Runner 終了｜ECS Express Mode への移行手順と RDS Custom 対応

Cloud & Server
  • URLをコピーしました！
目次

はじめに

クラウドインフラの選定において、マネージドサービスの利便性は強力ですが、同時にサービスのライフサイクル管理（終了や移行）への対応も避けられません。

2026 年 3 月 31 日、AWS は公式ドキュメント「AWS Lifecycle Changes」を通じて、9 サービスの新規受付停止および 4 サービスの提供終了計画を発表しました。 対象には AWS App Runner、RDS Custom for Oracle、AWS Audit Manager、AWS CloudTrail Lake などが含まれています。

特に AWS App Runner は 2026 年 4 月 30 日から新規受付停止（メンテナンスモード移行）、Amazon RDS Custom for Oracle は 2027 年 3 月 31 日に提供終了というスケジュールで、利用中または導入検討中の環境では早急な設計判断が求められます。

参考: AWS What’s New「AWS Service Availability Updates」
https://aws.amazon.com/about-aws/whats-new/2026/03/aws-service-availability/

本記事では、今回の発表の全容を整理した上で、インフラエンジニアがとるべき代替アーキテクチャへの移行戦略と、具体的な移行手順について解説します。

この記事でわかること
  • 2026 年 3 月 31 日発表の AWS サービス終了計画の全体像
  • AWS App Runner の概要と、公式推奨の移行先「Amazon ECS Express Mode」への移行手順
  • Amazon RDS Custom for Oracle の概要と、EC2 / RDS for Oracle / Aurora PostgreSQL への移行手順
  • 移行プロジェクトの進め方と CI/CD パイプライン刷新のポイント

2026 年 3 月 31 日発表: 対象サービス一覧

今回の発表で対象となったサービスは、新規受付停止（メンテナンスモード移行）と提供終了の 2 カテゴリに分類されます。

新規受付停止（Maintenance 移行）

サービス新規受付停止日
AWS App Runner2026 年 4 月 30 日
AWS Audit Manager2026 年 4 月 30 日
AWS Glue for Ray2026 年 4 月 30 日
AWS IoT FleetWise2026 年 4 月 30 日
Amazon Application Recovery Controller（Readiness check 機能）2026 年 4 月 30 日
Amazon Comprehend（Topic modeling / Event detection / prompt safety classification 機能）2026 年 4 月 30 日
Amazon Rekognition（Streaming Video Analysis 機能）2026 年 4 月 30 日
Amazon SNS（Message Data Protection 機能）2026 年 4 月 30 日
AWS CloudTrail Lake2026 年 5 月 31 日

提供終了（Sunset → Full Shutdown）

サービス終了日備考
Amazon RDS Custom for Oracle2027 年 3 月 31 日—
Amazon WorkMail2027 年 3 月 31 日2026 年 4 月 30 日より新規受付停止
Amazon WorkSpaces Thin Client2027 年 3 月 31 日2026 年 4 月 20 日より新規受付停止
AWS Service Management Connector2027 年 3 月 31 日—

参考: AWS What’s New「AWS Service Availability Updates」

https://aws.amazon.com/about-aws/whats-new/2026/03/aws-service-availability/

本記事ではこの中でも特に影響の大きい AWS App Runner と Amazon RDS Custom for Oracle に絞って、概要と移行戦略を掘り下げます。

AWS App Runner の概要

App Runner とは

AWS App Runner は、コンテナ化された Web アプリケーションや API を、インフラを意識することなく素早くデプロイできるフルマネージドサービスです。2021 年に正式リリースされ、以下の特徴により少人数開発チームや MVP 開発での採用が進みました。

ソースコードまたはコンテナイメージからの自動デプロイ

GitHub リポジトリや Amazon ECR を指定するだけで、ビルドからデプロイまで自動化

自動スケーリング

トラフィックに応じたスケールアウト / スケールインを自動実行

HTTPS エンドポイントの自動提供

証明書管理不要で HTTPS アクセスが可能

アイドル時の自動ポーズ

トラフィックのない時間帯はリソースをポーズし、コストを抑制

App Runner が抽象化していた要素

App Runner の裏側では、実際には ECS と Fargate が動作していますが、利用者から見ると以下の要素が完全に隠蔽されていました。

  • VPC・サブネット・セキュリティグループの設計
  • Application Load Balancer（ALB）のプロビジョニング
  • ターゲットグループとヘルスチェックの構成
  • SSL/TLS 証明書の発行と管理
  • コンテナイメージのビルドと ECR へのプッシュ
  • オートスケーリングポリシーの設定

App Runner の「シンプルさ」は、これらの要素を意識せずに済む点に集約されていました。移行先を検討する際は、どの抽象化を維持したいかを軸に判断することを推奨します。

今回のアナウンス内容（詳細）

  • 2026 年 4 月 30 日から新規受付停止（Maintenance ステータスに移行）
  • 既存ユーザーはそのまま利用継続可能（新規リソース作成も可能）
  • 新機能追加は停止されるが、セキュリティアップデートは継続提供
  • AWS 公式推奨の移行先は Amazon ECS Express Mode

参考: AWS 公式ドキュメント「AWS App Runner availability change」
“After careful consideration, we decided to close AWS App Runner to new customers starting April 30, 2026. Existing AWS App Runner customers can continue to use the service as normal, including creating new resources and services.”
（慎重な検討の結果、2026 年 4 月 30 日より AWS App Runner の新規顧客への提供を終了することを決定しました。既存の AWS App Runner のお客様は、新しいリソースやサービスの作成を含めて、通常どおりサービスを継続してご利用いただけます。）
https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html

App Runner からの代替アーキテクチャ検討

移行先の最有力候補: Amazon ECS Express Mode

App Runner の新規受付停止に伴い、AWS 公式が明確に推奨している移行先は、2025 年 11 月に発表された Amazon ECS Express Mode です。AWS 公式ドキュメントでも以下のように案内されています。

参考: AWS 公式ドキュメント「AWS App Runner availability change」
“We recommend that customers explore Amazon Elastic Container Service (Amazon ECS) Express Mode when migrating from AWS App Runner. Amazon ECS Express Mode preserves App Runner’s operating simplicity while providing access to the broader Amazon ECS feature set.”
（AWS App Runner から移行するお客様には、Amazon ECS Express Mode のご検討を推奨します。Amazon ECS Express Mode は、App Runner の運用のシンプルさを維持しつつ、より広範な Amazon ECS の機能セットへのアクセスを提供します。）
https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html

ECS Express Mode とは

ECS Express Mode は、コンテナイメージと最低限の IAM ロールを指定するだけで、AWS 側が ECS サービス（Fargate）・Application Load Balancer（ALB）・HTTPS 証明書・オートスケーリング・CloudWatch 監視までを自動的に構築・設定する機能です。

作成された各サービスには AWS 提供のドメイン名が自動で割り当てられるため、追加設定なしで HTTPS エンドポイントにアクセスできます。すべてのリソースは利用者の AWS アカウント内に作成されるため、必要に応じて直接カスタマイズ可能な点も大きな特徴です。

参考: AWS What’s New「Announcing Amazon ECS Express Mode」
“Today, AWS announces Amazon Elastic Container Service (Amazon ECS) Express Mode, a new feature that empowers developers to rapidly launch containerized applications, including web applications and APIs. ECS Express Mode makes it easy to orchestrate and manage the cloud architecture for your application, while maintaining full control over your infrastructure resources.”
（本日、AWS は Amazon ECS Express Mode を発表します。Web アプリケーションや API を含むコンテナ化アプリケーションを迅速に起動できる新機能です。インフラリソースの完全な制御を維持しつつ、アプリケーションのクラウドアーキテクチャの調整と管理を容易にします。）
https://aws.amazon.com/about-aws/whats-new/2025/11/announcing-amazon-ecs-express-mode

App Runner / ECS Express Mode / ECS on Fargate の位置づけ

3 つのサービスは「マネージドの深さ」が異なるだけで、裏側では同じ AWS Fargate 基盤上で動作します。シンプルに整理すると以下のようになります。

AWS App Runner

Fargate 上に最もマネージド度合いの高いラッパーを被せたもの。ソースコードから自動ビルド可能

ECS Express Mode

Fargate をベースに「ALB・証明書・オートスケーリング・監視」までを自動化したもの。App Runner のシンプルさを保ちつつ、リソースは利用者のアカウント内に可視化される

ECS on Fargate（標準）

Fargate の素の機能。タスク定義・ALB・セキュリティグループ等を自前で設計する必要があるが、自由度は最も高い

App Runner ユーザーの多くにとって、運用のシンプルさを維持したまま移行できる ECS Express Mode が第一候補となります。より細かい制御が必要なケースでは、標準の ECS on Fargate への移行を検討することを推奨します。

App Runner / ECS Express Mode / ECS on Fargate 比較表

3 つのサービスの主要な違いを整理します。

項目AWS App RunnerAmazon ECS Express ModeECS on Fargate（標準）
新規受付2026/4/30 停止可能可能
サーバー管理不要不要不要
ALB・証明書の構築自動（非可視）自動（アカウント内に可視化）手動
オートスケーリング自動自動手動設定
VPC 設計の自由度限定的利用者制御（アカウント内）完全制御
ソース直接デプロイ可能不可（イメージ必須）不可
デプロイ戦略自動デフォルト 5% カナリア（固定）ローリング / ブルーグリーン 選択可
WebSocket 対応限定的◯◯
アイドル時の自動ポーズ◯（課金停止可能）×（常時課金）×（常時課金）
典型的な用途MVP・プロトタイプシンプルな本番 Web アプリ複雑な本番ワークロード

選定の目安

App Runner ユーザーで「運用のシンプルさを維持したい」場合

ECS Express Mode

ネットワーク要件・デプロイ戦略に細かい制御が必要な場合

ECS on Fargate（標準）

低トラフィックでアイドル時コストを抑えたい場合

コスト試算の上で、他のサーバーレスオプション（Lambda 等）も含めて検討

移行によるメリットと運用上の留意点

ECS Express Mode への移行のメリット
  • App Runner の運用シンプルさを維持しつつ、すべてのリソースが利用者の AWS アカウント内に可視化されるため、障害時のトラブルシューティングが容易になります。
  • ALB、オートスケーリング、CloudWatch 監視が自動構築されるため、App Runner の主要機能は概ねカバーされます。
  • WebSocket・HTTP/2 等、App Runner では対応が限定的だったプロトコルにも対応します
  • 標準の ECS へのステップアップが容易で、将来的により細かい制御が必要になった場合も同じアカウント内で拡張できます。
標準の ECS on Fargate への移行のメリット
  • ネットワーク設計（VPC のサブネットやセキュリティグループ）やスケーリング戦略に対して細かな制御が可能になります
  • よりセキュアな閉域網での運用や、複雑なエンタープライズ要件への対応が容易になります
運用上の留意点

App Runner が透過的に提供していた「ソースコードからの自動ビルド機構」は、ECS Express Mode および標準の ECS では提供されません。そのため、GitHub Actions や AWS CodePipeline などを使った CI/CD パイプラインの自前構築が必要になります。

また App Runner は低トラフィック時にリソースを自動的にポーズしてアイドル状態にする機能がありますが、ECS Express Mode および標準の ECS on Fargate では Fargate タスクが常時稼働するため、アイドル時も課金が発生します。低トラフィックのワークロードでは、移行後のコストが増加する可能性があるため事前の試算を推奨します。

CloudFormation や AWS CDK のサンプル構成は公式 GitHub リポジトリ等で公開されているため、これらを起点に IaC（Infrastructure as Code）による構成管理を導入することが現実的です。

App Runner から ECS Express Mode への移行手順

移行は大まかに以下の 5 ステップで進めます。

STEP

既存リソースの棚卸し

移行前に以下を確認します。

  • App Runner サービスの設定値（環境変数、シークレット、ポート番号、ヘルスチェック設定等）
  • カスタムドメインと証明書の設定状況
  • 連携している外部サービス（RDS、ElastiCache、Secrets Manager 等）のネットワーク設定
  • 現在のトラフィック量とピーク時の Fargate タスク数
STEP

コンテナイメージの準備

App Runner でソースコードからの自動ビルドを利用していた場合、ECS Express Mode ではコンテナイメージの事前ビルドが必要になります。

  • Dockerfile の整備（マルチステージビルドによる軽量化を推奨）
  • Amazon ECR へのイメージプッシュ
  • イメージの脆弱性スキャン（ECR の Image Scanning または Trivy 等）
STEP

IAM ロールの作成

ECS Express Mode で必要な IAM ロールは 2 種類です。

  • タスク実行ロール（Task Execution Role）： ECR からのイメージ取得、CloudWatch Logs への書き込み等
  • インフラストラクチャロール（Infrastructure Role）： ECS Express Mode が ALB・証明書・オートスケーリング等を構築するために使用
STEP

ECS Express Mode サービスの作成

マネジメントコンソールまたは AWS CLI / IaC ツール（CloudFormation / Terraform）から作成します。必須の指定は以下のみです。

  • コンテナイメージ URI（ECR のイメージ）
  • タスク実行ロール・インフラストラクチャロール
  • リソース設定（CPU・メモリ）

作成後、AWS 提供のドメイン名が自動で割り当てられ、HTTPS エンドポイントが即座に利用可能になります。カスタムドメインを使う場合は、Route 53 で CNAME レコードを設定します。

参考: AWS 公式ドキュメント「AWS App Runner availability change」（移行ガイド）
https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html

STEP

トラフィック切替と旧環境の削除

段階的な切替を推奨します。

  1. DNS の TTL を短縮（切替前日までに 60 秒程度まで下げておく）
  2. Route 53 の加重ルーティングで段階的切替（10% → 30% → 50% → 100%）
  3. 新環境での動作確認（アクセスログ、エラー率、レイテンシの監視）
  4. 旧 App Runner サービスの削除（監視期間を設けた後）

CI/CD パイプラインの再構築

App Runner のソース自動デプロイがなくなるため、GitHub Actions や AWS CodePipeline で以下のフローを構築することを推奨します。

ソースコード変更
  → ビルド（マルチステージ Dockerfile）
  → Trivy 等による脆弱性スキャン
  → ECR へのイメージプッシュ
  → ECS Express Mode サービスの更新（新イメージへの切替）

関連記事: 【DevSecOps】Trivy 関連サプライチェーン攻撃 | litellm バックドアの脅威と対策

インフラ運用者目線での移行プロジェクトの進め方

AWS のライフサイクル段階と猶予期間

AWS のサービス終了は、公式に Maintenance（メンテナンスモード）→ Sunset（サンセット）→ Full Shutdown（完全停止） という 3 段階で管理されます。

  • Maintenance： 新規受付停止。既存ユーザーは利用継続可能。新機能追加なし、セキュリティアップデートは継続
  • Sunset： 他サービスへの移行を計画すべき段階。サポート終了日が発表される
  • Full Shutdown： 機能が完全停止し、サポートも終了

今回の発表では、App Runner は 2026 年 4 月 30 日から Maintenance に移行し、RDS Custom for Oracle は 2027 年 3 月 31 日に Full Shutdown となります。既存の App Runner ユーザーはメンテナンスモード後も利用継続可能なため、慌てた移行は不要です。一方、RDS Custom for Oracle は 公式告知から終了までの猶予期間が約 12 ヶ月となるため、計画的な対応が必要です。

現行リソースの棚卸しと現実的なタイムラインの策定

インフラ管理者が最初に行うべきは、現行環境の棚卸しです。「どのシステムが、どのレベルで依存しているか」を確認し、事業への影響度が高い順に移行の優先順位をつけます。

特に RDS Custom for Oracle のようなデータベース層の移行は、アプリケーション側の改修やデータ移行（DMS の活用など）を伴うため、最低でも半年から 1 年規模のバッファを持たせた現実的なタイムラインの策定を推奨します。App Runner については、既存ユーザーは引き続き利用可能なため、移行の緊急度は RDS Custom for Oracle ほど高くないものの、新機能追加が停止することを踏まえた長期計画が必要です。

コンテナ設計の最適化と CI/CD パイプラインの再構築

ECS Express Mode や標準の ECS へ移行するフェーズは、単なる環境の「引っ越し」ではなく、アーキテクチャ全体を最適化する機会です。

App Runner のソース直接デプロイ機能は ECS Express Mode では提供されないため、このタイミングで GitHub Actions や AWS CodePipeline を用いた本格的な CI/CD パイプラインの構築を推奨します。典型的な構成例は以下の通りです。

  1. ビルド： マルチステージビルドによるイメージ軽量化（ベースに Alpine や distroless を採用）
  2. 脆弱性スキャン： Trivy 等によるコンテナイメージの脆弱性スキャンを自動化
  3. イメージプッシュ： Amazon ECR へのイメージ登録
  4. デプロイ： ECS Express Mode または ECS サービスへのデプロイ

アーキテクチャ刷新のタイミングで CI/CD パイプラインを構築する際は、コンテナイメージの脆弱性をビルド時に自動検知する仕組みを組み込むことで、セキュリティレベルの向上につながります。

Amazon RDS Custom for Oracle の概要

RDS Custom for Oracle とは

Amazon RDS Custom for Oracle は、Amazon RDS のマネージドサービス性を保ちつつ、OS レベルへのアクセスとデータベースのカスタマイズを可能にした特殊なサービスです。2021 年にリリースされ、以下のような要件を持つユーザーに採用されてきました。

  • OS レベルでの管理者アクセスが必要（SSH ログイン、OS カーネルパラメータの変更等）
  • Oracle データベースへのカスタムパッチ適用が必要
  • SYS / SYSTEM 等の特権アカウントへのフルアクセスが必要
  • ERP パッケージ（Oracle E-Business Suite 等）のように、個別パッチが前提のソフトウェア

標準の RDS for Oracle では上記の要件を満たせないため、従来は「EC2 上に Oracle をホストして自前で管理するしかなかった」ユーザー層に向けた中間的な選択肢として位置づけられていました。

標準の RDS for Oracle との違い

項目RDS for OracleRDS Custom for Oracle
OS アクセス（SSH）×◯
特権アカウント（SYS / SYSTEM）×◯
カスタムパッチ適用×◯
自動バックアップ◯◯（一部制限あり）
Multi-AZ◯◯（後から追加された機能）
管理負荷低中（責任共有モデル）

今回のアナウンス内容

  • 2027 年 3 月 31 日をもって提供終了（Full Shutdown）
  • Sunset ステータスのため、他サービスへの移行計画を進める必要がある
  • 公式ドキュメントに移行先候補と手順が整理されている

参考: AWS 公式ドキュメント「RDS Custom for Oracle end of support」
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html

なお、本発表は Amazon RDS Custom for Oracle のみが対象であり、Amazon RDS Custom for SQL Server は今回の発表対象外です。

RDS Custom for Oracle からの移行先比較

移行先として現実的な候補は以下の 3 つです。

項目EC2 OracleRDS for OracleAurora PostgreSQL
OS アクセス◯（フル制御）××
特権アカウント◯×◯（PG 側）
カスタムパッチ◯×対象外（PG ベース）
DB エンジンOracle 継続Oracle 継続PostgreSQL に変更
管理負荷高（自前管理）低低
ライセンスBYOLBYOL / ライセンス込み不要（OSS）
ライセンスコスト継続発生継続発生削減可能
移行難易度低（ファイル直接コピー可）中（DMS 推奨）高（SCT + DMS）
アプリ改修不要基本不要必要（SQL 互換性対応）

選定の目安

OS アクセスやカスタムパッチが不可欠な場合

EC2 Oracle（リホスト）

マネージドのメリットを享受しつつ Oracle を継続したい場合

RDS for Oracle（リプラットフォーム）

Oracle ライセンスコストの削減を目指す場合

Aurora PostgreSQL（リアーキテクチャ）

AWS 移行戦略の一般的な考え方では、まず リホストまたはリプラットフォームでクラウド化し、次のフェーズでリアーキテクチャに進む段階的移行が現実的とされます。

RDS Custom for Oracle からの具体的な移行手順

パターン

EC2 Oracle へのリホスト

この方式の独自メリット： RDS Custom for Oracle は インスタンス内部に SSH でアクセス可能なため、データファイル・制御ファイル・アーカイブログを直接コピーして EC2 に移行できます。他の移行方式と比べて、アプリ改修が発生しないため最も移行難易度が低くなります。

主な移行ステップ

  1. EC2 インスタンスに Oracle Database をインストール（既存と同じバージョン・パッチレベル）
  2. RDS Custom for Oracle のインスタンスに SSH でログインし、データファイル等を取得
  3. RMAN（Recovery Manager）によるバックアップ取得と EC2 への復元
  4. Oracle Data Guard を構成してスタンバイデータベースとして同期
  5. カットオーバー時にスイッチオーバーを実行

留意点

  • Oracle のライセンス（BYOL）を EC2 上で継続利用できるかをライセンス契約で確認
  • EC2 の vCPU とコアファクターによってはライセンス課金額が変わる可能性
  • 自動バックアップ・Multi-AZ 等のマネージド機能は自前で構築
パターン

Amazon RDS for Oracle へのリプラットフォーム

この方式のメリット： マネージドサービスのメリット（自動バックアップ・Multi-AZ・パッチ適用）を享受できます。管理負荷が下がる一方、OS アクセスや特権アカウントは失われます。

主な移行ステップ

  1. RDS for Oracle のインスタンスを作成（既存と同等のスペック）
  2. AWS Database Migration Service（DMS）を使ったレプリケーションの構成
  3. 初期フルロード + CDC（Change Data Capture）による継続レプリケーション
  4. カットオーバー時に DMS タスクを停止し、アプリケーションの接続先を切替

留意点

  • カスタムパッチが適用されている場合、RDS for Oracle で提供されるパッチレベルと合致するか事前確認が必要
  • SYS / SYSTEM スキーマに依存する処理がある場合、アプリケーション側の改修が必要
  • RDS for Oracle のバージョンサポート期間（19c の Extended Support 期間等）との整合性を確認
パターン

Amazon Aurora PostgreSQL へのリアーキテクチャ

この方式のメリット： Oracle ライセンスコストの削減が最大のメリットです。一方、アプリケーション側の SQL 改修やストアドプロシージャの書き換えが必要となり、移行難易度は最も高くなります。

主な移行ステップ

  1. AWS Schema Conversion Tool（SCT） でスキーマを PostgreSQL 互換に変換
  2. アプリケーション側の SQL・ストアドプロシージャの改修（Oracle 固有構文の書き換え）
  3. Aurora PostgreSQL インスタンスの作成
  4. DMS によるデータ移行（初期ロード + CDC）
  5. 十分な検証期間を経てカットオーバー

留意点

  • Oracle PL/SQL → PostgreSQL PL/pgSQL への書き換え工数が想定以上に大きくなる場合がある
  • ANSI 準拠でない Oracle 固有の SQL（CONNECT BY、階層問合せ等）は書き換えが必要
  • 十分な並行稼働期間と性能検証期間の確保が必要

参考: AWS 公式ドキュメント「RDS Custom for Oracle end of support」
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html

移行前に押さえておきたい制約事項

ECS Express Mode の制約

App Runner から ECS Express Mode への移行時、App Runner で提供されていた機能の一部は利用できない点に注意が必要です。

  • ソースコード直接デプロイ機能なし： コンテナイメージの事前ビルドが前提
  • デプロイ戦略はデフォルトで 5% カナリアデプロイに固定： 現時点ではブルー/グリーンやローリングへの変更は不可
  • アイドル時の自動ポーズ機能なし： Fargate タスクは常時稼働するため、低トラフィック時もコストが発生
  • 一部の App Runner 固有機能（自動プライベートサービス連携等）は非互換

RDS for Oracle への移行時の制約

RDS Custom for Oracle から標準の RDS for Oracle へ移行する場合、RDS Custom を選んだ理由そのものが制約となるケースが多いです。

  • OS レベルの SSH アクセス不可
  • カスタムパッチ適用不可（AWS が提供するパッチレベルのみ）
  • SYS / SYSTEM 等の特権アカウントへのフルアクセス不可
  • Oracle 固有のユーティリティ（RMAN 等）の一部機能に制限

RDS Custom for Oracle 採用時にこれらの機能が不可欠だった場合、EC2 Oracle への移行を優先的に検討することを推奨します。

Aurora PostgreSQL への移行時の制約

  • Oracle 固有構文（CONNECT BY、MERGE 文の一部構文、階層問合せ等）は書き換え必須
  • PL/SQL と PL/pgSQL の差異（例外処理、パッケージの概念、コレクション型等）
  • Oracle 固有データ型（NUMBER、VARCHAR2 等）の扱い（SCT が自動変換するが要確認）
  • サードパーティツール（Oracle Enterprise Manager 等）は利用不可

移行プロジェクト全体の留意点

  • DMS のフルロードは本番環境のディスク IO に影響を与える可能性があるため、計画的な実施が必要
  • 本番切替後の切戻しシナリオを事前に設計しておく（特に Aurora PostgreSQL への移行時）
  • ライセンス契約の確認（特に Oracle BYOL を継続利用する場合）

まとめ

  • 2026 年 3 月 31 日発表の AWS ライフサイクル変更により、9 サービスが新規受付停止、4 サービスが提供終了となる。
  • AWS App Runner は 2026 年 4 月 30 日にメンテナンスモード移行。AWS 公式推奨の移行先は Amazon ECS Express Mode
  • ECS Express Mode は App Runner のシンプルさを維持しつつ、リソースが AWS アカウント内に可視化される。WebSocket 等にも対応
  • Amazon RDS Custom for Oracle は 2027 年 3 月 31 日に提供終了。主な移行先は EC2 Oracle / RDS for Oracle / Aurora PostgreSQL
  • RDS Custom は OS アクセス可能なため、EC2 へのリホストはファイル直接コピーで移行難易度が低い。
  • 移行はアーキテクチャ刷新の機会と捉え、IaC と CI/CD パイプラインを再構築することを推奨する。

以上、最後までお読みいただきありがとうございました。

Cloud & Server
AWS
よかったらシェアしてね！
  • URLをコピーしました！

この記事を書いた人

とものアバター とも

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ（ネットワーク・サーバ・クラウド・セキュリティ）の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus（取得から20年以上）／ VCAP-DCA ／ Azure Solutions Architect Expert

▶ 運営者プロフィール（詳細）

目次