インフラ脱却!AWS LambdaでPython製Web APIを動かす具体例とコツ
モダンなWebアプリケーションを開発したいけれど、サーバーのOSアップデートやセキュリティパッチの適用、アクセスの増減に応じたスケーリング作業に時間を奪われたくない…そう感じていませんか? アプリケーションのコードを書くことに集中したい開発者にとって、サーバー管理は悩みの種です。この記事では、そんな課題を解決する「サーバーレスアーキテクチャ」の基本から、AWS Lambda を使った具体的な API開発 の手順までをハンズオン形式で解説します。サーバーレスの世界へ、最初の一歩を踏み出しましょう。
サーバーレスとは?なぜ今、開発者に注目されているのか
「サーバーレス」と聞くと、「サーバーが不要になる技術」と誤解されがちですが、実際にはサーバーがどこにも存在しないわけではありません。サーバーレスとは、開発者がサーバーの存在を意識することなく、アプリケーションを構築・実行できるクラウドの設計思想を指します。物理サーバーや仮想マシン (AWSで言えばEC2など) のプロビジョニング、OSの管理、スケーリングといったインフラ管理を、すべてクラウドプロバイダー (AWSなど) に任せることができます。
このアーキテクチャの中核をなすのが FaaS (Function as a Service) です。FaaSは、特定のイベント (例えば、HTTPリクエストの受信やデータベースの更新) をトリガーとして、コードの断片である「関数」を実行するサービスです。リクエストがあるときだけコードが実行され、実行時間や回数に応じて課金されるため、リソースを無駄なく利用できます。
開発者がサーバーレスに注目する最大の理由は、ビジネスロジックの実装に集中できる点にあります。インフラ管理から解放されることで、プロダクトの価値向上に直結するコーディングにより多くの時間を費やせるようになるのです。また、トラフィックの増減に応じて自動でスケールしてくれるため、急なアクセス増にも柔軟に対応できる点も大きな魅力です。
AWS Lambdaで実現するサーバーレスAPIの基礎知識
AWSが提供するFaaSが AWS Lambda です。Lambdaは、Python, Node.js, Java, Goなど、多くのプログラミング言語に対応しており、アップロードされたコードをイベントに応じて実行してくれます。サーバーレスでWeb APIを構築する場合、このLambdaと Amazon API Gateway というサービスを組み合わせるのが一般的です。
それぞれの役割は以下のようになります。
-
Amazon API Gateway: インターネットからのHTTPリクエストを受け付ける窓口の役割を担います。APIのエンドポイント (
https://.../itemsのようなURL) を作成し、どのリクエストをどのLambda関数に渡すかを設定します。また、リクエストの検証、流量制御 (スロットリング)、認証・認可といったAPI管理に必要な機能も提供します。 -
AWS Lambda: API Gatewayから渡されたリクエスト情報をもとに、実際の処理を実行する バックエンド の心臓部です。データベースからデータを取得したり、他のサービスと連携したりといったビジネスロジックをここに実装します。処理が完了したら、その結果をAPI Gatewayが期待する形式のレスポンスとして返却します。
この2つを組み合わせることで、「ユーザーがAPIエンドポイントにリクエストを送る → API Gatewayが受け付ける → Lambda関数を呼び出す → Lambda関数が処理を実行し、結果を返す → API Gatewayがユーザーにレスポンスを返す」という一連の流れを、サーバーを一切管理することなく実現できるのです。
【ハンズオン】PythonとAPI GatewayでシンプルなAPIを作ってみよう
それでは実際に、現在時刻を返すだけのシンプルなAPIを Python を使って作成してみましょう。ここでは、AWSマネジメントコンソールを使った基本的な手順を紹介します。
1. Lambda関数の作成
まず、AWSマネジメントコンソールにログインし、Lambdaのサービスページを開きます。「関数の作成」ボタンをクリックし、以下の項目を設定します。
- オプション: 「一から作成」を選択
- 関数名:
my-first-api-functionなど、分かりやすい名前を入力 - ランタイム:
Python 3.12(または利用可能な最新バージョン) を選択 - アーキテクチャ:
x86_64(デフォルト) を選択
他の設定はデフォルトのままで「関数の作成」をクリックします。
2. Pythonコードの記述
関数が作成されると、コードエディタが表示されます。デフォルトで lambda_function.py というファイルに lambda_handler という関数が用意されています。この中身を、APIとして機能するように書き換えましょう。
以下のコードをコピーして、エディタに貼り付けてください。このコードは、日本の現在時刻を取得し、API Gatewayが要求するJSON形式でレスポンスを返します。
import json
from datetime import datetime, timezone, timedelta
def lambda_handler(event, context):
# 日本標準時 (JST, UTC+9) を定義
jst = timezone(timedelta(hours=+9), 'JST')
# 現在のJST時刻を取得し、文字列にフォーマット
current_time_jst = datetime.now(jst).strftime('%Y-%m-%d %H:%M:%S')
# レスポンスの本文を作成
response_body = {
"message": "Hello from your first serverless API!",
"currentTimeJST": current_time_jst
}
# API Gatewayが期待するレスポンス形式で返す
# statusCode: HTTPステータスコード
# headers: レスポンスヘッダー (Content-Typeなど)
# body: レスポンスの本文 (JSON文字列に変換)
return {
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": json.dumps(response_body)
}
コードを貼り付けたら、「Deploy」 ボタンをクリックして変更を保存します。
3. API Gatewayでトリガーを設定
次に、このLambda関数をインターネットから呼び出せるように、API Gatewayを「トリガー」として設定します。
- Lambda関数の設定画面上部にある「トリガーを追加」をクリックします。
- トリガーの選択で「API Gateway」を選びます。
- 「APIを作成する」を選択し、以下の設定を行います。
- APIタイプ:
HTTP API(よりシンプルでコスト効率が良いため、入門におすすめです) - セキュリティ:
オープン(誰でもアクセスできる設定。テスト用です)
- APIタイプ:
- 設定内容を確認し、右下の「追加」ボタンをクリックします。
しばらく待つとトリガーが作成され、「APIエンドポイント」 としてURLが表示されます。このURLが、私たちが作成したAPIの入り口です。
4. 動作確認
表示されたAPIエンドポイントのURLをコピーし、Webブラウザのアドレスバーに貼り付けてアクセスしてみてください。以下のようなJSONデータが表示されれば成功です!
{
"message": "Hello from your first serverless API!",
"currentTimeJST": "2026-07-02 15:30:00"
}
ターミナルで curl コマンドを使っても確認できます。
curl <あなたのAPIエンドポイントURL>
これで、サーバーを一台も構築することなく、Web APIを公開できました。
開発・テスト・デプロイをスムーズに進める実践テクニック
コンソールでの手作業は入門には最適ですが、実際の API開発 プロジェクトでは、より効率的で再現性の高い開発サイクルが求められます。
-
フレームワークの活用: AWS SAM (Serverless Application Model) や Serverless Framework といったツールを利用するのが一般的です。これらのフレームワークを使うと、Lambda関数やAPI GatewayなどのAWSリソースの構成をYAML形式のファイルでコードとして管理 (IaC: Infrastructure as Code) できます。これにより、手作業による設定ミスを防ぎ、誰が実行しても同じ環境を再現できます。
-
ローカルでのテスト: AWS SAM CLIなどのツールを使えば、Lambda関数やAPI Gatewayの動作をローカルマシン上でエミュレートできます。AWSにデプロイする前に、手元で素早く動作確認やデバッグができるため、開発効率が大幅に向上します。
-
CI/CDパイプラインの構築: GitHub ActionsやAWS CodePipelineといったサービスと連携させることで、コードをリポジトリにプッシュしたタイミングで自動的にテストとデプロイを実行するCI/CD (継続的インテグレーション/継続的デプロイメント) パイプラインを構築できます。これにより、デプロイ作業が自動化され、チーム開発における品質とスピードが向上します。
サーバーレスアーキテクチャのメリット・デメリットと注意点
サーバーレスは強力な選択肢ですが、万能ではありません。採用を検討する際は、メリットとデメリットの両方を理解しておくことが重要です。
メリット
- サーバー管理が不要: インフラの運用・保守から解放され、開発に集中できます。
- コスト効率: リクエストがないときは料金が発生しない従量課金制のため、特にトラフィックが少ない、または変動が大きいサービスではコストを抑えやすいです。
- 自動スケーリング: アクセスの増減に応じて自動でスケールするため、スケーラビリティの心配が不要です。
デメリットと注意点
- コールドスタート: 関数が長時間呼び出されていない場合、次回の初回実行時にコンテナの起動などで通常より時間がかかることがあります。これを「コールドスタート」と呼びます。レスポンス速度が非常に重要なAPIでは、Provisioned Concurrencyなどの対策を検討する必要があります。
- 実行時間の制限: Lambda関数には最大実行時間(2026年7月現在、最大15分)が設定されています。この時間を超えるような長時間のバッチ処理には向いていない場合があります。
- 状態管理の複雑さ: Lambda関数は基本的にステートレス(状態を持たない)です。そのため、複数のリクエストをまたいでデータを保持したい場合は、Amazon DynamoDBのような外部のデータベースやストレージサービスを利用する必要があります。
- ベンダーロックイン: AWS LambdaやAPI Gatewayなど、特定のクラウドプロバイダーのサービスに深く依存するため、将来的に他のプラットフォームへ移行する際のハードルが高くなる可能性があります。
より高度なサーバーレスアプリケーション設計のヒント
シンプルなAPIから一歩進んで、より複雑で堅牢なサーバーレスアプリケーションを構築するためのヒントをいくつか紹介します。
-
マイクロサービス化: 1つの巨大なLambda関数を作るのではなく、機能ごとに小さな関数に分割し、API Gatewayのパス (
/users,/productsなど) ごとに異なる関数を呼び出すように設計します。これにより、各機能の独立性が高まり、個別の開発やデプロイが容易になります。 -
非同期処理の導入: 時間のかかる処理 (例: 動画のエンコード、メール送信) は、APIで直接実行せず、一旦Amazon SQS (Simple Queue Service) のようなキューにタスクを入れ、別のLambda関数が非同期で処理する構成が有効です。これにより、APIはすぐにレスポンスを返すことができ、ユーザー体験が向上します。
-
データベースとの連携: サーバーレスアプリケーションには、同じくサーバーレスでスケーラブルなデータベースである Amazon DynamoDB (NoSQL) との相性が非常に良いです。インフラ管理の思想を統一することで、アーキテクチャ全体の見通しが良くなります。
-
認証・認可: Amazon Cognito を利用すれば、ユーザーのサインアップ・サインインといった認証機能を簡単に組み込めます。また、API Gatewayのオーソライザー機能を使えば、認証されたユーザーだけが特定のAPIを呼び出せるように制御できます。
サーバーレスアーキテクチャは、開発者がインフラの悩みから解放され、より創造的な作業に集中するための強力なパラダイムです。今回作成したシンプルなAPIを足がかりに、ぜひあなたのアイデアを形にしてみてください。


