Amazon EMRとは?料金・最新版7.13とサポート終了時期をわかりやすく解説
Amazon EMR(AWS EMR、正式にはElastic MapReduce)は、Apache SparkやHive、Trino、Icebergといったオープンソースのビッグデータ基盤を、AWSがクラスタ管理ごと引き受けて提供するサービスです。自前でHadoopクラスタを構築・運用する代わりに、リリースラベル(emr-7.13.0 など)を1つ指定するだけで、検証済みの組み合わせが揃ったクラスタが立ち上がります。ここでは、EMRの役割と3つのデプロイ形態、料金の積み上がり方、2026年7月時点の最新リリースであるEMR 7.13.0の内容、そして見落としやすいサポート期限(2026年8月1日から旧リリースがEnd of Supportに入ります)までを、AWS公式ドキュメントの記載に沿って整理します。
まとめ
- Amazon EMRは、Spark・Hive・Trino・HBase等のOSSをAWSがパッケージ化して提供するビッグデータ実行基盤。リリースラベル(例:
emr-7.13.0)でOS・JDK・OSSのバージョン一式が決まる。 - デプロイ形態はEMR on EC2/EMR on EKS/EMR Serverlessの3つ。常時稼働のクラスタが要らないバッチなら、まずEMR Serverlessから検討するのが早い。
- 最新は EMR 7.13.0(2026年4月21日リリース)。Spark 3.5.6-amzn-2/Hadoop 3.4.2/Iceberg 1.10.0を同梱し、PySparkの既定PythonがPython 3.11になった。
- EMR 7.9〜7.12には、3時間を超えるステップ/アプリケーションのログがS3に上がらない不具合がある。公式の対処は「7.13へ上げること」。長時間バッチを運用しているなら更新の優先度は高い。
- サポートはリリース日から標準サポート24か月 → End of Support(EoS)12か月 → End of Life。2024年7月25日のポリシー発表時点で存在していた旧リリースへのブリッジサポートは2026年7月31日で終了し、8月1日からEoSに入る。
- 料金は「EMRの料金+EC2(またはEKS/Serverless)の料金」の積み上げで、EMR on EC2は秒単位課金・1分の最小課金。コスト削減はスポットインスタンスとオートスケーリングの効果が最も大きい。
Amazon EMRの正体:Elastic MapReduceの略と、AWSが引き受ける範囲
EMRは Elastic MapReduce の略で、名前のとおりHadoop MapReduce時代に生まれたサービスです。ただし現在の中心はMapReduceではなくApache Sparkで、EMR 7.13.0の同梱アプリケーションを見ても、Spark 3.5.6-amzn-2、Hive 3.1.3-amzn-22、Trino 479-amzn-1、HBase 2.6.4-amzn-0、Iceberg 1.10.0-amzn-1、Flink 1.20.0-amzn-7 と、分散処理・SQLエンジン・オープンテーブルフォーマットが一式まとまっています。
リリースが束ねる3つの層
AWSはEMRリリースを「ランタイム環境/コアエンジン/エクストラ」の3層で定義しています。ランタイム環境はAMIやコンテナイメージに含まれるOS(EMR 7.xではAmazon Linux 2023)と言語ランタイム(Amazon Corretto JDK)、コアエンジンはHiveやIcebergといったOSS本体、エクストラはPigやmariadb-connector-javaのような補助ライブラリです。この区分はサポート範囲に直結し、エクストラに分類されるコンポーネントの不具合はAWSの修正対象外になります。
利用者が指定するのはリリースラベル1つだけで、クラスタ内の全ノードは同じAmazon Linuxバージョンに揃えられます。バージョンの組み合わせ検証をAWS側に寄せられる点が、自前Hadoopとの最大の違いです。
EMRが向く処理・向かない処理
EMRが力を発揮するのは、S3上の大量データに対してSparkやHiveでバッチ処理・ETL・機械学習前処理を回す用途です。逆に、BIツールから短いSQLを高頻度で投げる用途にEMRを使うのは筋が悪い。その用途はAmazon Redshiftとは?特徴・料金・使い方とアーキテクチャを実務目線で解説で扱っているRedshiftや、S3に直接クエリを投げるAmazon Athena(アテナ)とは?仕組み・使い方・料金・クエリの書き方とRedshiftとの違いを解説のAthenaのほうが、運用も費用も軽く済みます。EMRは「OSSの分散処理エンジンを自分でチューニングしたい」場合の選択肢です。
EMR on EC2/EMR on EKS/EMR Serverlessの選び方
同じEMRリリースを、3つの実行基盤(デプロイモデル)のどれで動かすかを選べます。
| デプロイ形態 | 実行基盤 | 向く場面 | 注意点 |
|---|---|---|---|
| EMR on EC2 | EC2クラスタ(YARN) | 長時間稼働・HBase・細かいチューニング | クラスタ管理とアイドル時間の費用 |
| EMR on EKS | EKS上のコンテナ | 既にK8sで基盤を統一している | EKSクラスタ費用(0.10 USD/時)が別途 |
| EMR Serverless | マネージドワーカー | 断続的なSparkバッチ・ETL | クラスタ単位の細かい制御はできない |
判断基準はシンプルで、クラスタを常時起動しておく理由(HBaseの常駐、対話的なNotebook、独自デーモン)が無いなら、EMR Serverlessが第一候補です。EMR 7.12以降のEMR Serverlessでは「サーバーレスストレージ」が導入され、Sparkのシャッフルなどの中間データ用にローカルディスクを事前確保する必要がなくなりました。中間データを保持するためにワーカーを起動し続ける必要がなくなり、アイドルワーカーを即座に解放できます。この中間データの保存に対する追加課金はありません。
リリース体系と最新版:EMR 7.13.0(2026年4月21日)
EMRはセマンティックバージョニング(<major>.<minor>.<patch>)を採用し、マイナーリリースは最低でも90日に1回のペースで出ます。2026年7月時点の最新はEMR 7.13.0(初回リリース日:2026年4月21日)で、7.12.0(2025年11月21日)はすでに最新ではありません。
7.xと6.xの違い(互換性に効く変更)
メジャーリリースは後方互換を持ちません。7.xはAmazon Linux 2023とAmazon Corretto 17(JDK 17)が既定、6.xはAmazon Linux 2とCorretto 8が既定です。6.xから7.xへ上げる際に最も詰まるのはJDK 8前提のUDFや依存ライブラリで、ここはリリースノートを読むより先に、自分たちのJARの依存関係を洗い出すほうが早く終わります。クラスタ内で複数のJavaランタイムを混在させることはできず、アプリごとにJVMを分けることもできません。
7.10〜7.13の主要コンポーネント一覧
| コンポーネント | emr-7.13.0 | emr-7.12.0 | emr-7.11.0 | emr-7.10.0 |
|---|---|---|---|---|
| Spark | 3.5.6-amzn-2 | 3.5.6-amzn-1 | 3.5.6-amzn-0 | 3.5.5-amzn-1 |
| Hadoop | 3.4.2-amzn-0 | 3.4.1-amzn-4 | 3.4.1-amzn-3 | 3.4.1-amzn-2 |
| Hive | 3.1.3-amzn-22 | 3.1.3-amzn-21 | 3.1.3-amzn-20 | 3.1.3-amzn-19 |
| Iceberg | 1.10.0-amzn-1 | 1.10.0-amzn-0 | 1.9.1-amzn-0 | 1.8.1-amzn-0 |
| Trino | 479-amzn-1 | 476-amzn-1 | 475-amzn-0 | 470-amzn-0 |
| HBase | 2.6.4-amzn-0 | 2.6.2-amzn-3 | 2.6.2-amzn-2 | 2.6.2-amzn-1 |
| Hudi | 1.0.2-amzn-2 | 1.0.2-amzn-1 | 1.0.2-amzn-0 | 0.15.0-amzn-7 |
| Python | 3.9, 3.11 | 3.9, 3.11 | 3.9, 3.11 | 3.9, 3.11 |
7.13.0で入った変更のうち、実務に効くのは次の2点です。1つはPySparkとSparkワークロードの既定Pythonが3.11になったこと(Spark以外のアプリは引き続き3.9が既定で、両方が同梱されます)。もう1つはIcebergの設定プロパティ spark.sql.catalog.spark_catalog.route-non-iceberg-drop-to-session-catalog の追加で、true にすると SparkSessionCatalog 配下の非Iceberg管理テーブルに対する DROP TABLE がメタデータとS3上の実データの両方を削除します。既定値は false で、意図せずデータが消えないようになっています。
7.12.0で追加された機能(Iceberg・Lake Formation周り)
7.12.0では、EMR Serverlessのサーバーレスストレージのほか、Iceberg 1.10へのアップグレード、Icebergマテリアライズドビューの作成・管理、Lake Formationのポリシーに基づくHudiのフルテーブルアクセス(FTA)、Hive・Iceberg・Delta LakeテーブルへのDDL/DML操作に対するSparkネイティブの細粒度アクセス制御(FGAC)、そしてLake Formation有効クラスタでのSparkジョブの監査コンテキストがCloudTrailログに残る機能が追加されています。Hudi FTAで書き込む場合は hoodie.storage.class=org.apache.spark.sql.hudi.storage.HoodieCredentialedHadoopStorage の指定が必須で、既定設定でのみ動作します(Merge-On-Readテーブルのクラスタリングは非対応)。
ただしEMRとAthenaを併用しているなら、Icebergまわりの既知の制約を先に確認してください。AWS公式のKnown issuesには双方向の問題が挙がっています。EMR Sparkが作成したIcebergテーブルタイプV3は、Athena SQLが GENERIC_INTERNAL_ERROR: Cannot read unsupported version 3 で読めません。逆に、Athenaで作成したIcebergテーブルへEMR Sparkから書き込むと、write.object-storage.path が非推奨である旨のエラーで失敗します。Icebergそのものの仕組みはApache Icebergの概要と基本的な定義で整理しています。
いま選ぶべきリリースは7.13.0:7.9〜7.12のログ欠落は放置しない
EMR 7.9から7.12までのリリースには、ステップまたはアプリケーションの実行が3時間を超えると、ステップログやコンテナログがS3にアップロードされないという不具合があります。AWS公式のリリースノートに記載された対処は「Amazon EMR 7.13にアップグレードして解決してください」の一文だけで、回避構成は案内されていません。
影響が出るのは、夜間の長時間バッチや大規模な再集計ジョブです。ジョブが落ちたときにログが残っていないという最悪のタイミングで露見するため、「動いているから触らない」という判断は、この4リリースに限っては割に合いません。7.13.0のリリースノートには「このリリースに既知の問題はありません」と書かれています。
ただし「マイナーリリース1つ分だから安全」と考えるのは危険です。7.12から7.13で、SparkとHiveとIcebergはamznパッチの繰り上がり(Spark 3.5.6-amzn-1→-2 など)にとどまりますが、Hadoopは3.4.1→3.4.2、HBaseは2.6.2→2.6.4、Trinoは476→479、Phoenixは5.2.1→5.3.0とコミュニティ版が上がります。AWSはマイナーリリースを「後方互換性のないリリース」と定義しているため、検証工程は省けません。
逆に、7.13へ即座に上げるべきでない場面もあります。PySparkの既定Pythonが3.11に変わるため、Python 3.9固有の依存を持つジョブは、7.13へ上げる前に依存関係の解決を先に済ませる必要があります。ここを飛ばして本番から上げると、ログの不具合を直しにいってジョブ自体を落とすことになります。
サポート期限:標準サポート24か月と、2026年8月1日から始まるEoS
EMRのサポートポリシーは、リリース日を起点に次の3段階で進みます。標準サポートは3つのデプロイ形態すべてで、EMRが提供される全リージョンに追加費用なしで適用されます。
| フェーズ | 期間 | 状態 |
|---|---|---|
| 標準サポート | リリース日から24か月 | ケース起票可・修正提供 |
| End of Support(EoS) | 標準サポート終了後12か月 | 起票不可・修正なし/コンソール非表示・API利用可 |
| End of Life(EoL) | EoS終了後 | 実行は可能/API・SDKから削除の可能性 |
EoSに入ってもクラスタが止まるわけではありません。コンソールの選択肢から消えるだけで、APIとAWS CLIからは引き続き起動でき、稼働中のジョブも走り続けます。止まるのはサポートケースの起票と、セキュリティパッチの提供です。
ここで2026年後半に効いてくるのがブリッジサポートの期限です。AWSは2024年7月25日にこのポリシーを発表し、2022年7月24日以前にリリースされたバージョンをEnd of Supportに指定しましたが、移行猶予として発表時点の旧リリースにブリッジサポート(標準サポート相当)を提供していました。この期限は2026年7月31日まで延長されており、2026年8月1日からEoS、2027年8月1日からEoLという扱いになります。古いEMR 5.x/6.xを塩漬けにしている環境は、この日付を境にサポートケースが起票できなくなります。
個別リリースの期限も確認しておくと、7.12.0は標準サポートが2027年11月21日まで、7.13.0は2028年4月21日までです。標準サポートは「最新に追随していれば自動的に効く」ものではなく、リリース日からのカウントである点に注意してください。既存クラスタが自動で最新版に更新されることはありません。
料金の積み上がり方と、効き目の大きいコスト削減策
EMRの料金でつまずくのは、EMRの利用料は単独では発生せず、基盤の料金に上乗せされる点です。EMR on EC2なら「EMRの料金+EC2インスタンス料金+EBS料金」で、課金は秒単位・最小1分。EMR on EKSでは、EKS側のインフラ費用(EKSクラスタ自体は0.10 USD/時)に加えて、EMRの上乗せ分がPodの消費したvCPU・メモリに対して秒単位で課金されます。
EMR Serverlessは考え方が変わり、ワーカーが消費したvCPU時間・メモリ時間・エフェメラルストレージへの課金になります。ワーカーは1〜16 vCPU、メモリ2GB〜120GBの範囲で構成でき、エフェメラルストレージは標準の20GBまでは追加課金がありません(7.12以降のサーバーレスストレージが扱うシャッフル等の中間データとは別枠で、こちらはストレージ課金自体が発生しません)。
コスト削減の効き目が大きい順に並べると、(1) スポットインスタンスの利用(最大90%の割引)、(2) オートスケーリングによるアイドル時間の削減、(3) リザーブドインスタンスやSavings Plansでのベースライン確保です。インスタンス単価はリージョンとインスタンスタイプで変わるため、具体的な金額はAWSの料金ページで最新の値を確認してください。なお、Sparkジョブが数分で終わるようなワークロードでは、クラスタの起動時間そのものが費用の大半を占めることがあります。この場合はEMRを使うより、AthenaやGlueに寄せたほうが安く済みます。
S3・データカタログとの連携(EMRFSとLake Formation)
EMRのデータはHDFSではなくS3に置くのが基本形です。EMR on EC2で s3:// スキームにアクセスする際に働くのがEMRFS(Amazon S3向けのHadoopコネクタ)で、EMR 7.13.0でも emrfs 2.74.0 がコンポーネントとして同梱されています。設定は emrfs-site という設定分類で変更でき、変更するとHDFS/YARNの各サービスとHiveServer2などが再起動されます。
メタデータ側は、Glue Data Catalogをメタストアとして共有するのが一般的です。テーブル単位・列単位のアクセス制御を効かせたい場合はLake Formationと組み合わせ、EMR 7.12以降であればSparkからのDDL/DML操作にも細粒度アクセス制御が効きます。ETLのオーケストレーション自体をEMRの外に出したいなら、AWS Glueとは?機能・料金・使い方とWorkflowsの仕組みまで徹底解説で扱っているGlue Workflowsが選択肢になります。
Glue・Redshift・Athenaとの使い分け
「EMRとGlueの違い」「EMRとRedshiftの違い」は検索でも頻出しますが、比較軸は「誰がSparkの面倒を見るか」と「データをどこに置くか」の2つで整理できます。
| サービス | 実体 | 主な用途 | EMRとの分岐点 |
|---|---|---|---|
| Amazon EMR | OSS分散処理クラスタ | 大規模バッチ・ETL・ML前処理 | エンジンやバージョンを自分で選びたい |
| AWS Glue | サーバーレスETL | 定型ETL・カタログ管理 | Sparkの設定を触らず運用したい |
| Amazon Athena | S3への対話型SQL | アドホック分析 | クラスタを持たずSQLだけ投げたい |
| Amazon Redshift | データウェアハウス | BI・定型レポート | 低レイテンシのSQLを高頻度で投げる |
実務では排他選択にはならず、S3をデータレイクとしてEMRで加工し、Glue Data Catalogでメタデータを共有し、分析はAthenaやRedshiftから、という構成に落ち着くことが多いです。DWHとデータレイクの役割分担そのものに迷っている段階なら、データウェアハウス(DWH)とは?仕組み・製品比較・選び方をわかりやすく解説を先に読むと判断が早くなります。
よくある質問
EMRは何の略ですか?
Elastic MapReduce(エラスティック・マップリデュース)の略です。名前の由来はHadoop MapReduceですが、現在の主役はApache Sparkで、Hive・Trino・HBase・Flink・Iceberg・Hudiなど幅広いOSSが同梱されています。
Amazon EMRの最新バージョンはどれですか?
2026年7月時点の最新はEMR 7.13.0で、初回リリース日は2026年4月21日です。リリースラベルは emr-7.13.0 の形式で指定します。AWSの説明によれば、新リリースは初回リリース日を起点に数日かけて各リージョンへ順次提供されるため、この期間はリージョンによって最新版がまだ選べないことがあります。
EMRのサポート終了はいつですか?
各リリースはリリース日から24か月が標準サポート、その後12か月がEnd of Support、以降がEnd of Lifeです。2024年7月25日のポリシー発表時点で存在していた旧リリースへのブリッジサポートは2026年7月31日で終了し、2026年8月1日からEnd of Supportに入ります。EoSに入るとサポートケースを起票できなくなりますが、既存クラスタの実行が止められるわけではありません。
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が合います。
EMRに入っているSparkのバージョンはどれですか?
EMR 7.13.0はSpark 3.5.6-amzn-2、7.12.0は3.5.6-amzn-1、7.10.0は3.5.5-amzn-1です。-amzn- の後ろはAWSによる修正の版数で、コミュニティ版のSpark 3.5.6にAWSの修正が適用されていることを示します。7.13.0以降、PySparkの既定PythonはPython 3.11です。