Amazon EMRとは？最新版7.14・Spark 4対応の8.1と東京の料金、サポート期限【2026年10月】

Amazon EMR（AWS EMR。Elastic MapReduceの略）は、Apache Spark・Hive・Trino・Icebergなどのオープンソースのビッグデータ基盤を、AWSがバージョンの組み合わせ検証ごと引き受けて提供するサービスです。リリースラベル（emr-7.14.0 など）を1つ指定すると、OS・JDK・各OSSの版が決まった実行環境が立ち上がります。2026年10月時点の最新は、7.x系が7.14.0（2026年9月8日）、Spark 4を載せた新系列「AWS runtime for Apache Spark」がemr-spark-8.1.0（同日・長期サポート版）です。この記事では、2つの系列の選び方、2026年8月に延長されたサポート期限、東京リージョンの単価と試算、CLIでのジョブ実行、Spark 3.5から4.1へ移すときに落ちる箇所を、AWS公式ドキュメントと価格APIの原表、ローカルでの実行結果をもとに整理します。

まとめ

• Amazon EMRは、Spark・Hive・Trino等のOSSをAWSが検証済みの組み合わせで配布する実行基盤。動かす場所はEMR on EC2／EMR on EKS／EMR Serverlessの3つから選ぶ。
• 最新は2系列。Hive・HBase・Trino・Flinkも使うなら7.x系の7.14.0（Spark 3.5.8）、Sparkだけで足りるならSpark 4.1.1のemr-spark-8.1.0（36か月の長期サポート）。
• 7.9〜7.12は、3時間を超えるステップのログがS3に上がらない不具合がある。7.13以降へ上げるのが公式の対処。
• 通常版は標準24か月→End of Support（EoS）12か月→End of Lifeが基本。LTS指定版は36か月のサポート後、EoS期間を挟まずEnd of Lifeへ移行する。旧リリースのブリッジサポートは2026年8月31日まで延長されたうえで終了し、5.35以前と6.5以前は9月1日からEoS。5.36・6.6〜6.15は2027年6月30日、7.0〜7.10は2027年8月31日まで延長された。
• EC2・EKSの料金は「EMRの上乗せ＋基盤料金」、Serverlessはワーカーのリソース使用量に対する課金。東京のm7g.xlargeはEC2が0.2108 USD／時、EMR分が0.0408 USD／時。EMR Serverlessはx86で1 vCPU時0.065728 USD、Gravitonはその8割。
• Spark 4（emr-spark-8.x）へ移すとANSIモードが既定でオンになり、3.5でNULLだった不正なCASTや0除算がエラーで止まる。移行前に try_cast などへの置き換えが要る。

以下、EMRの位置づけから順に、版の選び方・サポート期限・料金・手順の根拠を示します。

Amazon EMRとは：Elastic MapReduceの略と、AWSが引き受ける範囲

EMRは Elastic MapReduce の略で、Hadoop MapReduceをクラウドで動かすサービスとして始まりました（MapReduceそのものの仕組みはMapReduceの仕組みとワードカウントの具体例で扱っています）。現在の中心はApache Sparkで、7.14.0にはSpark 3.5.8-amzn-0、Hive 3.1.3-amzn-24、Trino 479-amzn-2、HBase 2.6.4-amzn-2、Iceberg 1.10.1-amzn-1、Flink 1.20.0-amzn-8が入っています（EMR 7.14.0のリリースページ）。-amzn- の後ろの数字は、AWSによる変更版を区別する0始まりの改訂番号で、修正の件数ではありません。

リリースが束ねる3つの層とサポート範囲

AWSはEMRリリースを「ランタイム環境」「コアエンジン」「エクストラ」の3層で定義しています。ランタイム環境はAmazon Linux 2023などのOSとAmazon Corretto JDK、コアエンジンはHiveやIcebergなどのOSS本体、エクストラはPigや mariadb-connector-java のような補助ソフトです。この区分はサポート範囲に直結し、エクストラの不具合はAWSの修正対象外です。またAWSはマイナーリリース（7.13→7.14など）を「後方互換性のないリリース」と定義しているので、マイナー版を1つ上げるときも検証環境で一度流すのが前提になります（Amazon EMR standard support）。

EMRが力を発揮するのは、S3上の大量データに対するSpark・Hiveのバッチ処理、ETL、機械学習の前処理です。BIツールから短いSQLを高頻度で投げる用途はRedshiftやAthenaのほうが向いており、使い分けは後半の比較表にまとめました。

EMR on EC2／EMR on EKS／EMR Serverlessの選び方

EMRには3つの実行基盤があり、利用可能なリリースとアプリケーションは形態ごとに確認します。7.x系のEMR Serverlessで選べる処理エンジンはSparkまたはHiveで、EC2版の全アプリケーションをそのまま使えるわけではありません。

判断はシンプルで、クラスタを常時起動しておく理由（HBaseの常駐、独自デーモン、YARNの細かい設定）が無いなら、EMR Serverlessが第一候補です。EMR on EKSは、すでにEKSでほかのワークロードを動かしていてノードを共有したい場合に限って選ぶのが筋です。EKSのクラスタ料金（標準サポート期間中は1クラスタ0.10 USD／時）とノードのEC2料金が別にかかるため、Sparkのためだけに新しくEKSを立てると割高になります。

EMR Serverlessで最初につまずく既定値

EMR Serverlessは、新規アカウントだとリージョンあたりの同時実行vCPUの既定クォータが16です（Endpoints and quotas for EMR Serverless）。4 vCPUのワーカーなら、ドライバー1つとエグゼキューター3つで上限に届きます。本番相当のデータでジョブを流す前に、Service Quotasで引き上げを申請しておかないと、ジョブは動くのに並列度が上がらず「Serverlessは遅い」という誤った結論になりがちです。ほかに押さえる既定値は次のとおりです（Understanding application behavior）。

• アプリケーションはジョブ投入で自動起動し、15分アイドルで自動停止する。事前初期化容量（initialCapacity）を設定すると、停止までの間もその分が課金される。
• ワーカーは1・2・4・8・16・32 vCPUから選ぶ。32 vCPUのメモリは60GB・120GB・244GBの3択で、Sparkのメモリ設定とオーバーヘッド（既定10%）の合計がこの値から8GB以内でないとジョブが拒否される。
• 標準の一時ストレージはワーカーごとに20〜200GBで、20GBを超える分に課金される。シャッフル最適化ストレージは別の選択肢で、最初の20GBも含めた設定容量全体が課金対象になる。

なお、7.12以降のEMR Serverlessには、シャッフルなどの中間データをAWS側で保持する「サーバーレスストレージ」があり、AWSはデータ処理コストを最大20%下げると説明しています。emr-spark-8.1.0では、このストレージでジョブあたりに扱える量が200GiBから1TiBへ引き上げられました（EMR Serverless emr-spark-8.1.0）。

最新リリース：7.x系は7.14.0、Spark 4はemr-spark-8.1.0

2026年5月から、EMRのリリースは2系列に分かれています。従来の7.x系（ラベルは emr-7.14.0）と、Spark 4を載せた「AWS runtime for Apache Spark」（ラベルは emr-spark-8.1.0）です。後者はEMR on EC2・EKS・Serverlessの3形態すべてで使えます。「EMR 8」と呼ばれるのはこの系列で、同梱アプリケーションはSpark・Iceberg・Delta・Hudi・Livy・JupyterEnterpriseGateway・CloudWatchエージェントに絞られています（emr-spark-8.1.0のリリースページ）。

7.14.0とemr-spark-8.1.0の違い

選び方は同梱アプリケーションで決まります。Hive・HBase・Trino・Flinkのどれかを同じクラスタで使うなら、選択肢は7.14.0だけです。Sparkだけのバッチなら、サポートが1年長く、Iceberg v3の地理空間型やナノ秒精度のタイムスタンプに対応したemr-spark-8.1.0を選べます。ただし8.1.0はScalaが2.13に上がるため、Scalaで書いたJARはそのままでは載りません。その手当ては後の章で扱います。

7.11〜7.14の主要コンポーネント

7.13.0ではPySparkの既定Pythonが3.11に変わりました（Spark以外のアプリケーションは3.9のまま）。7.14.0の変更で運用に効くのは、Trinoだけを選んで起動したクラスタではYARNとHDFSが起動しなくなった点です。Trinoの既定Javaも25になっています。Trinoクラスタの設計はTrinoの仕組みとPresto・Sparkとの違いを参照してください。7.14.0のリリースノートには「既知の問題なし」と書かれています。

AWS CLIによる利用可能リリースの確認

新しいリリースは初回リリース日から数日かけて各リージョンへ順に提供されるため、東京でまだ選べないことがあります。使えるラベルと同梱アプリケーションは、AWS CLIの次のコマンドで確認できます。

# 7.x系で選べるリリースラベルの一覧
aws emr list-release-labels --filters Prefix=emr-7 --region ap-northeast-1

# 特定ラベルの同梱アプリケーションと版
aws emr describe-release-label --release-label emr-7.14.0 --region ap-northeast-1

出力に東京で選べる版が並びます。コンソールの選択肢から消えた版（後述のEoS）も、APIとCLIからは指定できます。

7.9〜7.12を使っているなら：ログ欠落の不具合と更新先

EMR 7.9から7.12には、ステップまたはアプリケーションの実行が3時間を超えると、ステップログやコンテナログがS3にアップロードされないことがあるという不具合があります。7.12.0のリリースノートに記載された対処は「Amazon EMR 7.13にアップグレードして解決してください」の一文だけで、設定による回避策は示されていません（EMR 7.12.0のリリースページ）。夜間の長時間バッチが落ちたときにログが残っていない、という最悪のタイミングで露見するので、この4リリースに限っては「動いているから触らない」判断は割に合いません。

更新先は7.14.0です。7.13.0の既知の問題に残るのは yarn.nodemanager.log-dirs を512文字より長く設定するとS3へのログアップロードが失敗するという制約だけで、7.14.0のリリースノートは既知の問題なしとしています。7.12から7.14へ上げると、Spark 3.5.6→3.5.8、Hadoop 3.4.1→3.4.2、HBase 2.6.2→2.6.4、Trino 476→479、Phoenix 5.2.1→5.3.0とコミュニティ版が上がり、PySparkの既定Pythonも3.11になります。Python 3.9でしか動かない依存を持つジョブがあるなら、そこを先に片付けてから本番を上げてください。ログの不具合を直しにいってジョブ本体を落とすことになります。

Spark 3.5（7.x）からSpark 4（emr-spark-8.x）へ移すときに落ちる箇所

emr-spark-8.xへの移行では、まず次の3点を確認します。このほか、EMRFSの廃止によるS3Aへの移行、AWS SDK for Java v1からv2への変更、EC2のプライベートサブネットでのVPCエンドポイントとIAM権限の変更も確認対象です。AWSはコード変更を対話的に提案する「Apache Spark Upgrade Agent」をEMR on EC2とEMR Serverless向けに提供していますが、何が変わるかを先に知っておくと、その提案を採るかどうかの判断が速くなります。以下の挙動は、EMRと同じ版のPySpark 3.5.8（Scala 2.12.18）と4.1.1（Scala 2.13.17）を、Temurin 17のローカル環境で実行して確かめたものです。

ANSIモードの既定化による型変換・算術エラー

Spark 4.0から spark.sql.ansi.enabled が既定で true になりました（Spark SQL Migration Guide）。同じSQLを両方の版で流すと、結果は次のように分かれます。

from pyspark.sql import SparkSession

spark = SparkSession.builder.master("local[2]").getOrCreate()
for q in ["SELECT CAST('abc' AS INT)",      # 数値でない文字列のCAST
          "SELECT 2147483647 + 1",          # INTのオーバーフロー
          "SELECT 1 / 0",                   # 0除算
          "SELECT try_cast('abc' AS INT)"]: # 置き換え後
    try:
        print(q, "=", spark.sql(q).collect()[0][0])
    except Exception as e:
        print(q, "= ERROR", str(e).split("]")[0] + "]")

3.5では不正な行がNULLになって静かに集計から落ちていたジョブが、4.1では最初の不正値で止まります。CSVやJSONの取り込みで型変換をしているETLが最初に引っかかる箇所です。エラーメッセージ自身が try_cast・try_add・try_divide への置き換えを案内しており、これらは3.5でも動くので、7.x上で先に書き換えてから移すのが安全な順序です。spark.sql.ansi.enabled=false で旧挙動に戻すこともできますが、それはオーバーフローを黙って通す状態を4.xへ持ち込むことなので、一時しのぎに留めるべきです。

USING省略時のCREATE TABLEの既定形式変更

Spark 4.0からは、USING も STORED AS も書かない CREATE TABLE が、Hive形式ではなく spark.sql.sources.default（既定はParquet）で作られます。Hiveサポートを有効にした状態で CREATE TABLE t_plain (id INT) を実行し、DESCRIBE TABLE EXTENDED を見ると、3.5.8ではProviderが hive・入力形式が TextInputFormat、4.1.1ではProviderが parquet・入力形式が MapredParquetInputFormat でした。Glue Data CatalogをHiveメタストアとして共有し、HiveやAthenaから同じテーブルを読む構成では、テーブル定義を作るDDLに形式を明示しておかないと、作り直したテーブルだけ形式が変わります。

Scala 2.13・Pythonの版と、Serverlessの設定の効き方

Scala（またはJavaでScalaライブラリに依存するJAR）は、2.12向けのビルドを2.13向けに作り直す必要があります。依存ライブラリも _2.13 の成果物へ差し替えが要ります。PySparkはPython 3.11と3.13が同梱され、EMR Serverlessでは3.12も使えます。

EMR Serverlessでは、8.0.0と8.1.0の間でSpark設定の扱いが変わりました。8.0.0ではジョブやセッションに渡した設定がアプリケーション側の設定を丸ごと置き換えていましたが、8.1.0からは両方がマージされ、同じキーはジョブ側が優先されます。アプリケーション側に共通設定を置いている環境で8.0.0から8.1.0へ上げると、それまで効いていなかった設定が効き始めることがあります。

もう1点、emr-spark-8.1.0の既知の制約として、Icebergのネイティブなテーブル暗号化はHiveメタストアかIceberg RESTカタログでしか効きません。Glue Data Catalog（そのIceberg RESTエンドポイントを含む）とHadoopカタログでは設定が受け付けられるのに暗号化されず、データは平文で書かれます。Glueカタログを使う場合は、テーブルのS3の場所にSSE-KMSを設定してください。

サポート期限：標準24か月・EoS 12か月と、2026年8月の延長措置

通常版は、原則としてリリース日から24か月が標準サポート、その後12か月がEnd of Support（EoS）、以降がEnd of Life（EoL）です。延長サポート対象版とLTS指定版は別扱いで、LTS指定版は36か月のサポート後に直接EoLへ移ります。EoSに入ってもクラスタは止まりません。コンソールの選択肢から消えるだけで、APIとAWS CLIからは起動でき、稼働中のジョブも走り続けます。止まるのはサポートケースの起票と修正・パッチの提供です。EoLに入ると、AWSはセキュリティ上の理由でAPIやSDKからリリースを削除することがあります。

2026年は期限が2回動きました。2026年7月31日、旧リリース向けのブリッジサポートの期限が8月31日まで延長され、8月14日には移行中の利用者向けの延長サポートが追加されています（Amazon EMR standard supportのSupport policy change history）。その結果、サポート一覧（Support Lifecycle）の表では、版ごとの期限が次のようになっています。

ただし、各版のリリースページに載っている日付は、この一覧と食い違う箇所があります。7.11と7.12のEoL開始は一覧が2028年11月4日・11月22日、リリースページが11月3日・11月21日です。7.13の標準サポート終了は一覧が2028年4月20日、リリースページが4月21日です。emr-spark-8.0.0はリリースページが2028年5月20日にEoSを挟まずEoLとしている一方、一覧では5月21日からEoS、2029年5月21日からEoLです。期限の直前まで使う計画を立てるなら、早いほうの日付を前提にしてください。

延長サポートの中身は版で違います。5.36と6.6〜6.15が受けられるのは重大なセキュリティ修正のベストエフォート提供で、7.0〜7.10は標準サポートと同等です。AWSのページは、この延長を受けるにはAWSサポートに移行計画を添えてチケットを起票するよう案内しています。黙っていても延びるものではないので、6.x系を2027年まで使う予定があるなら、移行計画を書いて起票しておく必要があります。

長期サポート（LTS）は「AWS runtime for Apache Spark」の指定版だけが対象で、サポートが36か月続き、終わるとEoSを挟まずにEoLへ移ります。7.x系のサポート表にはLTSの指定がありません。数年単位で同じ版を固定したいSparkバッチなら、この点でもemr-spark-8.1.0に寄せる理由があります。

料金：東京リージョンの単価と試算

EMR on EC2とEMR on EKSでは基盤料金にEMR料金が上乗せされます。EMR Serverlessでは、ワーカーが使用するvCPU・メモリ・ストレージに課金され、基盤のEC2料金を別途支払う方式ではありません。EMR on EC2なら「EMRの料金＋EC2インスタンス料金＋EBS料金」で、課金は秒単位・最小1分です（Amazon EMRの料金）。東京リージョン（ap-northeast-1）の単価を、AWSが公開している価格データ（EMRはPrice List APIの2026年10月18日版、EC2は料金ページ用データの10月15日版）から抜き出すと次のとおりです。

試算すると、m7g.xlarge 3台（プライマリ1＋コア2）のEMR on EC2を2時間動かした場合、EC2分が0.2108×3×2＝1.2648 USD、EMR分が0.0408×3×2＝0.2448 USDで、計約1.51 USD（EBS別）です。同じ構成をm5.xlargeにすると約1.78 USDになり、Graviton（m7g）のほうが15%ほど安く済みます。EMR Serverlessで4 vCPU・16GBのワーカー4台分（16 vCPU・64GB）を30分使うと、x86で16×0.5×0.065728＋64×0.5×0.007189≒0.76 USD、Gravitonで≒0.60 USDです。Serverlessは事前初期化容量を設定しない限りアイドル時間に課金されないので、1日数回のバッチなら、クラスタを立てっぱなしにするEMR on EC2より安くなりやすい構造です。

EMR on EC2のコストを下げる手段で効き目が大きいのは、タスクノードへのスポットインスタンスの適用と、マネージドスケーリングによるアイドル時間の削減です。スポットはHDFSを持たないタスクノードに使うのが基本です。コアノードで使う場合は、HDFSの複製数や同時に中断されるノード数によって、データを失うおそれがあります。インスタンスフリートを使えば、1フリートに複数のインスタンスタイプを登録してスポットの確保率を上げられます（CLIやAPIで割り当て戦略を使う場合は最大30種類）。

EMRでSparkジョブを動かす手順（AWS CLI）

同じPySparkスクリプトを、EMR on EC2とEMR Serverlessの両方で動かす最小構成です。スクリプトは、ヘッダーに sale_date,store,amount を持つCSVを読み、金額を整数化して日付と店舗で集計し、Parquetで書き出します。不正な金額の行は売上合計だけでなく注文数からも除外する例です。Spark 3.5でも4.1でも同じ結果になるよう、ANSIモードで止まる CAST を避けています（ローカルのSpark 3.5.8と4.1.1で、不正な金額を1行含むCSVから2グループが書き出されることを確認済み）。AWS CLIのコマンドはAWSのCLIリファレンスの構文に沿った記述例で、バケット名・ロール名・アカウントIDは自分の環境に置き換えてください。

# daily_sales.py
import sys
from pyspark.sql import SparkSession, functions as F

src, dst = sys.argv[1], sys.argv[2]
spark = SparkSession.builder.appName("daily-sales").getOrCreate()

df = spark.read.option("header", True).csv(src)
out = (df.withColumn("amount", F.expr("try_cast(amount AS INT)"))
         .where(F.col("amount").isNotNull())
         .groupBy("sale_date", "store")
         .agg(F.sum("amount").alias("total"), F.count("*").alias("orders")))
out.write.mode("overwrite").partitionBy("sale_date").parquet(dst)
spark.stop()

EMR on EC2のクラスタ作成・ステップ実行・自動終了

初回だけ aws emr create-default-roles で既定のサービスロールを作っておきます。--auto-terminate を付けると、ステップがすべて終わった時点でクラスタが終了し、アイドル時間の課金が発生しません。--log-uri を付けないとステップのログがS3に残らないので、必ず指定します。

aws s3 cp daily_sales.py s3://example-bucket/code/

aws emr create-cluster \
  --name daily-sales \
  --release-label emr-7.14.0 \
  --applications Name=Spark \
  --instance-type m7g.xlarge --instance-count 3 \
  --use-default-roles \
  --log-uri s3://example-bucket/emr-logs/ \
  --steps 'Type=Spark,Name=daily-sales,ActionOnFailure=TERMINATE_CLUSTER,Args=[s3://example-bucket/code/daily_sales.py,s3://example-bucket/raw/sales/,s3://example-bucket/mart/daily_sales/]' \
  --auto-terminate \
  --region ap-northeast-1

EMR Serverlessのアプリケーション作成とジョブ投入

EMR Serverlessはアプリケーション（実行環境の器）を一度作り、そこへジョブを投入します。--architecture ARM64 でGravitonを選ぶと、前述の単価表のとおりvCPU単価が2割下がります。ジョブ実行ロールには、入力・出力のS3とGlue Data Catalogへの権限を付けておきます。

aws emr-serverless create-application \
  --type SPARK --release-label emr-spark-8.1.0 \
  --name daily-sales --architecture ARM64 \
  --region ap-northeast-1

aws emr-serverless start-job-run \
  --application-id <作成されたアプリケーションID> \
  --execution-role-arn arn:aws:iam::123456789012:role/EMRServerlessJobRole \
  --job-driver '{"sparkSubmit": {
      "entryPoint": "s3://example-bucket/code/daily_sales.py",
      "entryPointArguments": ["s3://example-bucket/raw/sales/", "s3://example-bucket/mart/daily_sales/"],
      "sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=14g"}}' \
  --region ap-northeast-1

エグゼキューターを4コア・14GBにしているのは、14GBに既定のオーバーヘッド10%を足した15.4GBが、4 vCPUワーカーのメモリ範囲（8〜30GB）に収まるからです。ジョブの依存関係やスケジュールまで管理したくなったら、Step FunctionsやAmazon MWAAから呼び出す構成に進みます（MWAAの環境設計はAmazon MWAAのAirflow 3.2対応とサーバーレス版の違いで扱っています）。

S3との接続：7.10以降の既定はS3A

EMRのデータはHDFSではなくS3に置くのが基本形です。S3への接続部分は、EMR 7.10.0から、s3://・s3n://・s3a:// のすべてでS3Aファイルシステムが既定になりました。EC2・EKS・Serverlessのすべてに適用されます（Migration Guide: EMRFS to S3A Filesystem）。それ以前の既定だったEMRFSも7.14.0にコンポーネントとして同梱されており（emrfs 2.75.0）、core-site.xml の fs.s3.impl と fs.s3n.impl に com.amazon.ws.emr.hadoop.fs.EmrFileSystem を指定すれば戻せます。ただしemr-spark-8.xではEMRFSそのものが提供されないため、この戻し方は7.x系でだけ使えます（emr-spark-8.0.0のリリースページ）。S3A側の設定が未定義で対応するEMRFSの設定だけがある場合は、EMRが設定を自動で対応づけます。

7.9以前から上げるときは、emrfs-site 分類で入れていたチューニングが効いているかを、S3Aの設定名で確かめ直してください。S3上のHBaseには、AWSがS3Aの読み取りポリシーの調整手順を別に出しています。

メタデータはGlue Data Catalogをメタストアとして共有するのが一般的です。テーブル・列単位のアクセス制御を効かせたい場合はAWS Lake Formationの権限管理と組み合わせます。emr-spark-8.1.0では、Spark設定を2行加えて機能を有効にすると、カタログを事前登録しなくても名前で参照でき、別アカウントのカタログやS3 Tablesのフェデレーテッドカタログを、Iceberg・Delta・Hudiの形式を自動判別して読めるようになりました。Icebergを使うなら、IcebergとParquetの関係も押さえておくと設計がぶれません。

Glue・Redshift・Athenaとの使い分け

比較軸は「誰がSparkの面倒を見るか」と「データをどこに置くか」の2つで整理できます。

実務では排他選択にはならず、S3上のデータをEMRで加工し、Glue Data Catalogでメタデータを共有し、分析はAthenaやRedshiftから行う構成が多くなります。GlueのETLジョブで済む規模ならEMRを持つ必要はありません（Glueでのジョブの組み方はAWS GlueでETLジョブを動かす手順）。EMRとAthenaを併用する場合は、EMR Sparkで作ったIcebergテーブルのV3をAthenaが GENERIC_INTERNAL_ERROR: Cannot read unsupported version 3 で読めないという既知の制約が、7.12.0のリリースノートに載っています。データ基盤全体の設計から相談したい場合は、データ分析基盤構築・MLOps構築支援で承っています。DWHとデータレイクの役割分担から整理したい段階なら、データウェアハウス（DWH）とは？仕組み・製品比較・選び方が出発点になります。

よくある質問

EMRは何の略ですか？

Elastic MapReduce（エラスティック・マップリデュース）の略です。名前の由来はHadoop MapReduceですが、現在の中心はApache Sparkで、Hive・Trino・HBase・Flink・Iceberg・Hudiなどが同梱されています。

Amazon EMRの最新バージョンはどれですか？

2026年10月時点で、7.x系の最新は7.14.0（2026年9月8日）です。Spark 4を使う新系列「AWS runtime for Apache Spark」の最新はemr-spark-8.1.0（同日・Spark 4.1.1）です。新リリースは初回リリース日から数日かけてリージョンへ順に提供されるので、東京で選べるかは aws emr list-release-labels で確認できます。

EMR 8はありますか？

「emr-8.x」というラベルはなく、Spark 4系は emr-spark-8.0.0（2026年5月21日）と emr-spark-8.1.0 という別系列のラベルで提供されています。同梱アプリケーションはSparkとIceberg・Delta・Hudiなどに限られ、Hive・HBase・Trino・Flinkは7.x系でしか使えません。JupyterHub・Zeppelin・Hueも8.xには含まれず、EMRFSも提供されない（S3への接続はS3Aのみ）ので、7.x系から移すときはこの3点も確認が要ります。

EMRのサポート終了（EOL）はいつですか？

通常版は原則として標準サポート24か月、その後のEnd of Supportが12か月で、以降がEnd of Lifeです。LTS指定版のemr-spark-8.1.0は例外で、2029年9月7日までサポートされ、翌9月8日に直接End of Lifeへ移ります。旧リリースのブリッジサポートは2026年8月31日に終わり、5.35以前と6.5以前は9月1日からEnd of Supportです。5.36と6.6〜6.15は2027年6月30日、7.0〜7.10は2027年8月31日まで延長サポートを受けられますが、AWSサポートへ移行計画を添えた起票が条件です。

AWS EMRとRedshiftの違いは何ですか？

EMRはS3上のデータをSparkやHiveで加工する分散処理基盤、Redshiftは集計済みのデータにSQLを高速に返すデータウェアハウスです。ETLや機械学習の前処理はEMR、BIツールからの定型レポートや低レイテンシのSQLはRedshift、と役割で分けます。両者は併用でき、EMRで加工した結果をRedshiftへロードする構成もよく使われます。

Amazon EMRとAWS Glueの違いは何ですか？

EMRはSparkやHiveの実行環境を自分で構成・チューニングできる基盤、GlueはSparkの実行環境をAWSに任せるサーバーレスETLです。エンジンの版やチューニングを細かく選びたいならEMR、実行基盤の管理負担を減らして定型ETLを回したいならGlueが合います。Glueでもジョブの監視や失敗時の対応は必要です。

関連記事

• AWS Glueとは？機能・料金・使い方とWorkflowsの仕組みまで徹底解説
• Amazon Redshift（レッドシフト）とは？RG・RA3・Serverlessの違いと東京の料金・使い方を解説
• Amazon Athena（アテナ）とは？使い方・クエリの書き方・料金・Redshiftとの違いを解説
• AWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計
• Trinoとは？分散SQLクエリエンジンの仕組みとPresto・Sparkとの違い【Trino 484対応】