このガイドは、DockerとAWS SAMを使用してAWS LambdaにIronPDF for Javaをデプロイする手順を解説します。 IronPDFはネイティブChromeベースのレンダリングエンジンに依存しているため、標準的なZip展開されたLambda関数では実行できません。Dockerが唯一のサポートされている展開モデルです。 以下の手順では、必要なツールのインストール、pom.xml依存関係の設定、Lambdaハンドラの記述から、コンテナイメージのビルド、SAM CLIを使用したデプロイに至るまでの全工程を網羅しています。
クイックスタート: AWS LambdaにIronPDF for Javaをデプロイする
今日あなたのプロジェクトでIronPDFを無料トライアルで使用開始。
目次
必要な前提条件は何ですか? {#prerequisites}
開始する前に、以下のツールが開発機にインストールされていることを確認してください。各ツールは、ビルドおよび展開パイプラインにおいて特定の役割を果たします。
- IntelliJ IDEA — このガイドで使用するIDEです。jetbrains.com/ideaからダウンロード。
- AWS Toolkit for JetBrains — IntelliJ内にSAMプロジェクトウィザードとLambdaラン構成を提供します。 設定方法はAWS Toolkit for JetBrains ドキュメントページにあります。
- AWS SAM CLI — Dockerイメージをビルドし、Lambda関数をデプロイするコマンドラインツール。 インストールはSAM CLIインストールガイドに従ってください。
- Docker Desktop — Lambda関数がZipアーカイブではなくコンテナイメージとしてパッケージされるために必要です。Docker Community Editionをダウンロード。
AWSにデプロイする前にローカルで呼び出しテストを行うには、次もインストールしてください:
- Java 8 JDK — Oracle JDK 8ダウンロードページから入手可能。
- Apache Maven — Mavenインストールガイドに従ってください。
すべてのツールが揃ったら、IntelliJ IDEAを開き、File → New → Projectを通じて新しいプロジェクトを作成します。 プロジェクトウィザードでAWS Lambdaテンプレートを選択し、次のオプションを選びます:
- パッケージタイプ:
Image - 実行時:
java8またはjava11 - SAM Template:
Maven


Zipデプロイメントの代わりにDockerを使用するべき理由 {#why-docker}
AWS Lambdaは、Zipアーカイブとコンテナイメージの2つのデプロイメントパッケージタイプをサポートしています。 Zipデプロイメントは、AWSが実行環境全体を管理する軽量Java関数には適しています。 ただし、IronPDFにはネイティブバイナリ(ChromeベースのPDFレンダリングエンジン)が同梱されており、実行時にこれを抽出して実行する必要があります。ZIPデプロイメント用のLambda実行環境では、ファイルシステムへの書き込みが/tmpに制限されており、ZIPパッケージ層の制限により、大容量のネイティブバイナリの抽出ができません。
コンテナイメージデプロイメントを使用すると、これらの制約を取り除けます。 独自のDockerイメージを定義するとき、基本のオペレーティングシステム、インストールされたシステムパッケージ、およびディレクトリレイアウトを制御できます。 IronPDFのレンダリングエンジンは起動時に/tmpに抽出でき、必要なシステムライブラリはイメージにプリインストール可能です。また、コンテナのサイズ制限(10 GB)は、エンジン全体を収容するのに十分な大きさです。
具体的な手順は簡単です:template.yamlに設定し、Docker対応のベースイメージを使用してビルドします。 SAM CLIが残りの処理を行います。
Mavenの依存関係をどのように設定しますか? {#Maven-dependencies}
pom.xml ファイルには、標準の Lambda SDK 以外に、IronPDF Java ライブラリ、IronPDF Linux x64 レンダリングエンジン、および IronPDF エンジン内部で使用される gRPC トランスポートの 3 種類の追加依存関係が必要です。
pom.xml を開き、<dependencies> 内に以下の依存関係を追加してください:
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>2024.9.1</version>
</dependency>
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-linux-x64</artifactId>
<version>2024.9.1</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>2.0.3</version>
</dependency>
<dependency>
<groupId>io.perfmark</groupId>
<artifactId>perfmark-api</artifactId>
<version>0.26.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-okhttp</artifactId>
<version>1.50.2</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty-shaded</artifactId>
<version>1.50.2</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>2024.9.1</version>
</dependency>
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-linux-x64</artifactId>
<version>2024.9.1</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>2.0.3</version>
</dependency>
<dependency>
<groupId>io.perfmark</groupId>
<artifactId>perfmark-api</artifactId>
<version>0.26.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-okhttp</artifactId>
<version>1.50.2</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty-shaded</artifactId>
<version>1.50.2</version>
</dependency>
ironpdf-engine-linux-x64 アーティファクトには、64ビットLinux向けのコンパイル済みChromiumベースのレンダリングエンジンが同梱されています。 これにより、IronPDFはLambdaコンテナ内でHTMLをPDFにレンダリングできます。 これがなければ、レンダリング呼び出しはバイナリ不足エラーで失敗します。 gRPCの依存関係(perfmark-api)は、IronPDFがローカルのgRPCチャネルを介してレンダリングエンジンと通信するため、必須となります。 slf4j-simple 依存関係は、IronPDF の内部ログを CloudWatch で確認できるようにするための、最小限のロギング実装を提供します。
ironpdf および ironpdf-engine-linux-x64 のバージョン番号は常に一致させてください。バージョンを混在させると、起動に失敗します。 Maven CentralにおけるIronPDF for Javaで最新のバージョン文字列を確認してください。
Lambdaハンドラをどのように記述しますか? {#lambda-handler}
Lambdaハンドラクラスは APIGatewayProxyRequestEvent を受け取り、PDFを生成し、APIGatewayProxyResponseEvent を返します。 最初のレンダリング処理の前に、2つのIronPDF設定呼び出しを含める必要があります。作業ディレクトリを/tmpに設定すること、およびオプションでデバッグログを有効にすることです。
App.java の内容を以下に置き換えてください:
//:path=App.java
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import com.ironsoftware.ironpdf.PdfDocument;
import com.ironsoftware.ironpdf.Settings;
import java.nio.file.Paths;
import java.util.HashMap;
import java.util.Map;
public class App {
public APIGatewayProxyResponseEvent handleRequest(
final APIGatewayProxyRequestEvent input,
final Context context) {
APIGatewayProxyResponseEvent response = new APIGatewayProxyResponseEvent();
// IronPDF must write its engine binaries and temporary files to /tmp.
// This is the only writable path available in the Lambda execution environment.
Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"));
// Enable debug logging to CloudWatch during initial testing.
Settings.setDebug(true);
try {
context.getLogger().log("Starting PDF render");
// Render a PDF from a live URL. Replace with your own HTML or URL as needed.
PdfDocument pdf = PdfDocument.renderUrlAsPdf("https://www.google.com");
context.getLogger().log("PDF render complete");
// Save the rendered PDF to /tmp. Files in /tmp persist for the lifetime
// of the Lambda execution environment (warm instance).
pdf.saveAs("/tmp/output.pdf");
Map<String, String> headers = new HashMap<>();
headers.put("Content-Type", "application/json");
return response
.withStatusCode(200)
.withHeaders(headers)
.withBody("PDF generated successfully.");
} catch (Exception e) {
context.getLogger().log("PDF render failed: " + e.getMessage());
return response
.withStatusCode(500)
.withBody("{\"error\": \"" + e.getMessage() + "\"}");
}
}
}
//:path=App.java
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;
import com.ironsoftware.ironpdf.PdfDocument;
import com.ironsoftware.ironpdf.Settings;
import java.nio.file.Paths;
import java.util.HashMap;
import java.util.Map;
public class App {
public APIGatewayProxyResponseEvent handleRequest(
final APIGatewayProxyRequestEvent input,
final Context context) {
APIGatewayProxyResponseEvent response = new APIGatewayProxyResponseEvent();
// IronPDF must write its engine binaries and temporary files to /tmp.
// This is the only writable path available in the Lambda execution environment.
Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"));
// Enable debug logging to CloudWatch during initial testing.
Settings.setDebug(true);
try {
context.getLogger().log("Starting PDF render");
// Render a PDF from a live URL. Replace with your own HTML or URL as needed.
PdfDocument pdf = PdfDocument.renderUrlAsPdf("https://www.google.com");
context.getLogger().log("PDF render complete");
// Save the rendered PDF to /tmp. Files in /tmp persist for the lifetime
// of the Lambda execution environment (warm instance).
pdf.saveAs("/tmp/output.pdf");
Map<String, String> headers = new HashMap<>();
headers.put("Content-Type", "application/json");
return response
.withStatusCode(200)
.withHeaders(headers)
.withBody("PDF generated successfully.");
} catch (Exception e) {
context.getLogger().log("PDF render failed: " + e.getMessage());
return response
.withStatusCode(500)
.withBody("{\"error\": \"" + e.getMessage() + "\"}");
}
}
}
Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"))への呼び出しは必須です。 AWS Lambdaの実行環境は、関数コードを読み取り専用ディレクトリにマウントします。 IronPDFエンジンは、起動時にサポートファイルを抽出しソケットを作成しなければならず、これらには書き込みアクセスが必要です。 /tmp ディレクトリは、Lambda がファイル書き込みを許可する唯一の場所であるため、レンダリングを開始する前に IronPDF をそのディレクトリを指定する必要があります。 この設定を省略するとエンジンが起動せず、すべてのレンダリング呼び出しが例外を投げます。
pdf.saveAs("/tmp/output.pdf") 呼び出しは、レンダリングされたファイルを一時的な /tmp ファイルシステムに保存します。 Lambda関数がPDFをバイナリレスポンスとして返す必要がある場合、またはS3にアップロードする必要がある場合は、ディスクに書き込む代わりに、pdf.getBinaryData()を使用してバイト列を取得してください。 大規模なワークロードのためには、Amazon S3にアップロードし、署名付きURLを返すのが推奨されるパターンです。
SAMテンプレートをどのように設定しますか? {#sam-template}
template.yaml ファイルは、Lambda 関数のリソース割り当てを制御します。 IronPDFが正常に動作するかどうかに直接影響する設定は、EphemeralStorage.Sizeの3つです。
Globals セクションの template.yaml を次のように更新してください:
//:path=template.yaml
Globals:
Function:
Timeout: 400
MemorySize: 2048
EphemeralStorage:
Size: 1024
//:path=template.yaml
Globals:
Function:
Timeout: 400
MemorySize: 2048
EphemeralStorage:
Size: 1024
Timeoutは400秒に設定されています。 コールドスタート時、IronPDFはレンダリングエンジンを/tmpに抽出し、ローカルのChromiumプロセスを起動する必要があります。 この抽出は初回の呼び出しで30~60秒かかる可能性があります。 330秒未満のタイムアウトは、コールドスタートの呼び出しがタスクタイムアウトエラーで失敗する原因となります。 ウォーム呼び出しははるかに速く、通常単純なHTMLからPDFへの変換では5秒未満です。
MemorySizeは2048 MBに設定されています。 Chromiumレンダラーはメモリを大量に消費します。IronPDFのAWS Lambdaでの最低実行可能メモリは1024 MBですが、2048 MBに設定することで、複雑なページに対するメモリ不足のリスクを軽減し、レンダリング速度を大幅に向上させます。また、Lambdaはメモリに比例してCPU割り当てもスケールします。
EphemeralStorage.Sizeは1024 MBに設定されています。 Lambdaのデフォルトのメモリ割り当ては512 MBです。 IronPDFは、レンダリングエンジンのバイナリ、フォントキャッシュ、および一時的なレンダリングファイルを/tmpに書き込みます。 これらのアセットはコールドスタートで512 MBを超えることがあり、その結果エンジンの抽出が失敗します。 エフェメラルストレージを少なくとも1024 MBに設定することで、この失敗モードを防ぐことができます。
Dockerfileをどのように構築しますか? {#dockerfile}
Dockerfileはこのデプロイメントの心臓部です。 それはマルチステージビルドを行います:最初のステージではMavenビルドイメージを使用してJavaプロジェクトをコンパイルします; 2番目のステージでは、Amazon Linux 2を基にした最終Lambdaランタイムイメージを作成し、IronPDFのChromiumエンジンが必要とするシステムパッケージをインストールし、コンパイル済みの成果物をコピーします。
プロジェクトの Dockerfile を開き、その内容を以下のように置き換えてください:
//:path=Dockerfile
# Stage 1: Build the Maven project
FROM public.ecr.aws/sam/build-java8.al2:latest AS build-image
WORKDIR /task
COPY src/ src/
COPY pom.xml ./
RUN mvn -q clean install
RUN mvn dependency:copy-dependencies -DincludeScope=compile
# Stage 2: Create the Lambda runtime image
FROM public.ecr.aws/lambda/java:8.al2
# Update the package index and install system libraries required by Chromium.
# These packages provide font rendering, graphics, audio, GTK3, and input
# method support — all needed by the headless browser inside IronPDF.
RUN yum update -y && \
yum install -y \
pango.x86_64 \
libXcomposite.x86_64 \
libXcursor.x86_64 \
libXdamage.x86_64 \
libXext.x86_64 \
libXi.x86_64 \
libXtst.x86_64 \
cups-libs.x86_64 \
libXScrnSaver.x86_64 \
libXrandr.x86_64 \
GConf2.x86_64 \
alsa-lib.x86_64 \
atk.x86_64 \
gtk3.x86_64 \
ipa-gothic-fonts \
xorg-x11-fonts-100dpi \
xorg-x11-fonts-75dpi \
xorg-x11-utils \
xorg-x11-fonts-cyrillic \
xorg-x11-fonts-Type1 \
xorg-x11-fonts-misc \
glibc-devel.x86_64 \
at-spi2-atk.x86_64 \
mesa-libgbm.x86_64 \
libxkbcommon \
amazon-linux-extras && \
amazon-linux-extras install epel -y && \
yum install -y libgdiplus
# Ensure /tmp is writable by the Lambda execution user.
RUN chmod 777 /tmp/
# Copy the compiled classes and dependencies from the build stage.
COPY --from=build-image /task/target/classes /var/task/
COPY --from=build-image /task/target/dependency /var/task/lib
# Entry point: package.ClassName::methodName
CMD ["helloworld.App::handleRequest"]
両ステージのベース画像では、通常の java8 ではなく、java8.al2 タグを使用しています。 サフィックス .al2 は、IronPDF に必要な Amazon Linux 2 を示しています。 以前の java8 イメージは、オリジナルの Amazon Linux 1 上で動作します。この環境では、もはや更新が提供されていない yum リポジトリが使用されており、IronPDF が依存するいくつかのパッケージが欠落しています。 Java 8上でIronPDFを展開する際は、必ず .al2 画像を使用してください。
yum install ブロックは、Chromiumがページをレンダリングするために必要なX11、GTK3、Pango、およびフォント関連のライブラリをインストールします。 これらのパッケージのいずれかを省略すると、不完全なPDF出力があったり、レンダリングエンジンが共有ライブラリ不足エラーでクラッシュする可能性があります。 一部の IronPDF 描画操作で使用される GDI+ 互換性のため、libgdiplus パッケージが必要です。
CMD の記述は、実際のパッケージ名やクラス名が helloworld.App と異なる場合は、それらに合わせて更新してください。
Lambda関数をどのように構築してデプロイしますか? {#build-deploy}
Dockerfile、App.javaの設定が完了したら、プロジェクトのルートディレクトリから以下の2つのSAM CLIコマンドを実行してください。
ステップ1 — コンテナイメージをビルドします:
//:path=build.sh
sam build -u
//:path=build.sh
sam build -u
-u フラグは、SAMにDockerを使用するよう指示します("コンテナ使用"モード)。 SAMはマルチステージのDockerfileを実行し、Mavenプロジェクトをコンパイルして最終Lambdaイメージを生成します。 Dockerがベースイメージをプルする初回の実行では、このステップに数分かかる可能性があります。
ステップ2 — AWSにデプロイします:
//:path=deploy.sh
sam deploy --guided
//:path=deploy.sh
sam deploy --guided
--guided フラグを指定すると、スタック名、AWSリージョン、アーティファクト用のS3バケット、およびデプロイ前に変更セットを確認するかどうかを尋ねる対話型プロンプトが表示されます。 プロンプトに回答すると、SAMがコンテナイメージをAmazon ECRにプッシュし、template.yamlで定義されたLambda関数、API Gateway、およびIAMロールを作成します。
デプロイメントが完了すると、SAM CLIはAPIエンドポイントURLを出力します。 AWS Lambdaコンソールを開いて、デプロイされた関数を表示し、テスト呼び出しを実行し、IronPDFデバッグ出力のためにCloudWatchログを確認します。
初回実行時(コールドスタート)は、Lambdaの実行環境が起動し、IronPDFがレンダリングエンジンを/tmpに抽出するため、応答時間が60~120秒かかることが予想されます。 同じウォームインスタンスでの後続の呼び出しは数秒以内に戻ります。 本番ワークロードでコールドスタートの遅延が問題になる場合は、Lambda Provisioned Concurrencyを使用してインスタンスを温めた状態に保つことを検討してください。
また、開発マシンで Docker が実行されている場合、テストイベントのペイロードを指定して sam local invoke を実行することで、デプロイ前にローカルで機能をテストすることも可能です。
次のステップは何ですか? {#next-steps}
Lambda関数は現在デプロイされており、PDFのレンダリングを行っています。 以下のガイドは、IronPDFの導入が成功した後の一般的な次のステップをカバーしています。
- IronPDF for Java - スタートガイド - HTMLからPDF、URLからPDF、PDFへのスタンプを含むIronPDF Java API全体の概要。
- JavaでHTMLからPDFを生成する方法 - HTML文字列、ファイル、およびテンプレートをPDFにレンダリングします。
- JavaでPDFにヘッダーとフッターを適用する方法 - ページ番号、ロゴ、およびテキストヘッダーをLambdaで生成されたPDFに追加します。
- JavaでPDFに透かしを追加する方法 - PDF出力にテキストまたは画像の透かしをスタンプし、呼び出し元に戻す前に。
- IronPDFライセンス - 本番環境でのLambda展開のライセンスオプション、展開件数ライセンスなど。
IronPDF for Javaの無料トライアルを開始して、評価中に制限なくLambda関数でPDFを生成および編集します。 本番環境への展開の準備が整ったら、IronPDFライセンスオプションを表示し、サーバーレスワークロードに適したプランを見つけてください。
よくある質問
なぜAWS LambdaでIronPDFのZipデプロイメントが使えないのですか?
IronPDFはネイティブのChromiumベースのレンダリングエンジンを提供しており、実行時に抽出および実行される必要があります。Zipデプロイメントは書き込みアクセスが制限された管理されたランタイム環境で実行され、パッケージサイズも制限されます。コンテナイメージのデプロイメントは、ファイルシステム、インストールされたシステムライブラリ、および画像サイズに対する完全な制御を提供し、これがIronPDFに必要です。
なぜIronPDFエンジンの作業ディレクトリを/tmp/に設定する必要があるのですか?
Lambdaの実行環境では、関数コードディレクトリを読み取り専用としてマウントします。IronPDFはエンジンのバイナリ、ソケットファイル、および一時レンダリング資産を書き込み可能な場所に書き込む必要があります。Lambda関数で唯一書き込み可能なパスは/tmp/であるため、レンダリング操作を行う前にSettings.setIronPdfEngineWorkingDirectory(Paths.get('/tmp/'))を呼び出す必要があります。
Lambda関数には最小限のメモリがどれくらい必要ですか?
MemorySizeを少なくとも1024 MBに設定します。Chromiumレンダラーはメモリ集約型であり、メモリが少ない関数はメモリ不足のエラーに遭遇します。本番環境の作業負荷には2048 MBが推奨されます。これは、AWSがメモリに比例してCPUの割り当てをスケーリングするため、レンダリング時間が短縮されます。
なぜEphemeralStorageのサイズが1024 MBに設定されているのですか?
デフォルトのLambdaエフェメラルストレージの割り当ては512 MBです。コールドスタート時に、IronPDFはレンダリングエンジンのバイナリとフォントキャッシュを/tmp/に抽出します。これらの資産は512 MBを超えることがあり、抽出が失敗する原因となります。EphemeralStorageを1024 MBに設定することでこの故障を防ぎます。
java8ではなくjava8.al2ベースイメージを使用する理由は何ですか?
java8ベースイメージは、IronPDFに必要な複数のライブラリを欠いている古いパッケージレポジトリを持つ元のAmazon Linux 1で実行されます。java8.al2イメージは、X11、GTK3、およびChromiumレンダラーに必要なPangoライブラリのフルサポートを備えた、現在のパッケージを持つAmazon Linux 2を使用しています。
IronPDFに必要なLambdaのタイムアウトは?
タイムアウトは少なくとも330秒に設定してください。コールドスタートでは、IronPDFがレンダリングエンジンを展開し、Chromiumプロセスを起動する必要があり、これには30〜60秒かかることがあります。短いタイムアウトは、コールドスタートの呼び出しがタスクタイムアウトエラーで失敗する原因となります。ウォーム呼び出しは非常に速く、通常は数秒以内で完了します。
デプロイ前にローカルでLambda関数をテストできますか?
はい。開発マシンでDockerが動作している場合、テストイベントペイロードを使用してsam local invokeを実行します。SAMはコンテナーイメージをローカルで起動し、ハンドラ関数を呼び出して、AWSにデプロイすることなくPDF生成を確認できるようにします。
本番環境でIronPDFのコールドスタートレイテンシを減らす方法は?
AWS Lambdaプロビジョニング並行性を使用して、指定された数のインスタンスを初期化してリクエストに対応できるようにしておきます。これにより、予約容量に対する追加料金が発生することはあるものの、これらのインスタンスのコールドスタートを排除できます。
AWS Lambdaに必要なIronPDF Mavenアーティファクトはどれですか?
Java API用のironpdf、ネイティブレンダリングエンジン用のironpdf-engine-linux-x64、およびgRPCトランスポート依存関係のgrpc-okhttp、grpc-netty-shaded、perfmark-apiが必要です。ironpdfとironpdf-engine-linux-x64のバージョンは一致させる必要があります。
生成されたPDFをバイナリHTTPレスポンスとして返す方法は?
pdf.saveAs()を呼び出す代わりに、pdf.getBinaryData()で生のバイトを取得し、Base64エンコードしてください。API GatewayのレスポンスにisBase64Encoded: trueとContent-Type: application/pdfを設定します。大きなファイルの場合、Amazon S3にアップロードして事前署名済みURLを返すのがより実用的なアプローチです。


