AWS LambdaからEC2インスタンス上で稼働するREST APIに接続したい

Question

前提・実現したいこと

Lambda関数(Node.js、以下Lambda)からEC2インスタンス(以下EC2)上で動いているサービスのREST APIにパブリックIPに解決可能なホスト名で接続したいのですが、ETIMEDOUTで失敗します。これを成功させたいです。
※Labmdaから別の外部のREST APIへの接続には成功しています。
※EC2の当該REST APIには、自PC等外部からの接続には成功しています。

構成

サービス	VPC	リージョン	Security Group	IPアドレス
Lambda関数	VPC A	東京A	SG L(必要なポート上で0.0.0.0をインバウンド許可、アウトバウンドは全て許可)	-
EC2インスタンス	VPC A	東京A	SG E(必要なポート上でSG Lをインバウンド許可、アウトバウンドは全て許可)	myHost(1.2.3.4のpublic Elastic IPに解決する)

発生している問題・エラーメッセージ

Lambdaの実行ログに以下のエラーが発生し、EC2上で動くREST APIへの接続ができませんでした。
なお、別の外部のREST APIへの接続は問題なく成功しました。（公共情報等の自由にアクセス可能なREST API）
↑ごめんなさい！！VPC使ってるときは外部APIにもつながってませんでした！！！間違いでした！！！実際はNAT Gatewayまでのルーティングが正しくなかったです。。。

ERROR Uncaught Exception
{
    "errorType": "Error",
    "errorMessage": "connect ETIMEDOUT 1.2.3.4:<my port>",
    "code": "ETIMEDOUT",
    "stack": [
        "Error: connect ETIMEDOUT 1.2.3.4:<my port>",
        "    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1106:14)"
    ],
    "errno": "ETIMEDOUT",
    "syscall": "connect",
    "address": "1.2.3.4",
    "port": <my port>
}

該当のソースコード

async function test(url) {
  const https = require('https');
  const urlObj = require('url').parse(url);
  return new Promise((resolve, reject) => {
    https.get(urlObj, async res => {
      const { statusCode } = res;
      const contentType = res.headers['content-type'];

      let error;
      if (statusCode !== 200) {
        error = new Error('Request Failed.\n' + `Status Code: ${statusCode}`);
      } else if (!/^application/json/.test(contentType)) {
        error = new Error(
          'Invalid content-type.\n' +
          `Expected application/json but received ${contentType}`
        );
      }
      if (error) {
        console.error(error.message);
        // Consume response data to free up memory
        res.resume();
        reject(error);
      }
      res.on('data', d => resolve(j));
    });
  });
}

exports.handler = async (event, context, callback) => {
  const url = "https://myHost:port/MYRESTAPI"
  const val = await test();
  console.log(val);
};

試したこと

• EC2側のSG(SG E)にLambda側のSG(SG L)の許可設定を追加しました。
• 最初はLambdaを非VPCにしていましたが、EC2と同一のVPC上に載せました。

補足情報（FW/ツールのバージョンなど）

• Node.js 10.x

その他必要な情報あれば追記依頼いただければ助かります。

Answer 1

恐らくですが、

SG E(必要なポート上でSG Lをインバウンド許可、アウトバウンドは全て許可)

にもかかわらず

1.2.3.4(public Elastic IP)にリクエストを投げているからだと思われます。
セキュリティグループを許可する設定にすると、Privateネットワークでの通信が許可されるものの、恐らくPublicな通信まで許可されるわけではないのかなと。
せっかく同一VPCに置いているのであれば、PrivateIPへリクエストを投げてみてはどうでしょう？

Comments

[退会済みユーザー]

ご回答ありがとうございます。なるほど、パブリックIPで接続するには、SG EにSG Lを追加しても意味がないんでしたか・・Lambda側の(と言っても共有していますが)NAT GatewayにSG Lを登録して・・・とかやれば通るかな、試してみます。

ちなみにprivateのIPは、インスタンス起動ごとに変わってしまいませんか？

[yu_1985]

そのへんの挙動はどうだったかなと自分も思ったのですが、さっき試してみたらダメでした。
Private IPはインスタンスのStop、Startでは変わりません。
Terminateして作り直すと変わりますが、明確に指定することも可能です。

[退会済みユーザー]

ありがとうございます。なるほど、Private IPも固定でいけるんですね。
しかし今気づいたところですが、httpsの証明書がホスト名で発行されている制約がありました。。。
つまりPublic IP直書きの1.2.3.4でも、Private IPでも[doesn't match certificate's altnames]でリクエストが通らないということでした。。。ここんところ追記しておきます。

やはりパブリックな接続で、さらにホスト名で行く方法を見つける必要があります。。後だしになりごめんなさい。

[yu_1985]

Internalな通信であれば別にhttpsでなくても問題ないかとは思いますが…。
ただそのへんはポリシーとサーバの設定に関わる部分ですね。

単にやりたいことを実現するだけなら、LambdaはVPC内からNAT Gateway（NATインスタンスかもしれません）を介してインターネットにリクエストを投げる必要があるかと思います。
LambdaはIPを固定できないため接続元としてしていするIPが判別できないのですが、NATを経由すればNATのIPを接続元として許可すれば行けるはずです。

ただし、NAT Gatewayを経由する場合はその分アウトバウンド通信に料金がかかるので、大量に通信する場合は要注意です。

他には[InternalなELBを作ってそこに証明書を適用してHTTPSで通信する](https://dev.classmethod.jp/cloud/aws/internal-alb-https/)、というのも考えられます。
そもそもInternalな通信なのでHTTPSじゃなくても…という気がしないこともないですが…。

さすがに全てをここには書ききれないのでそこは申し訳なく…。

[退会済みユーザー]

なるほど、PublicならばやはりNAT Gatewayを用いる形ですね。そちらで試してみます。
ちなみに通信は月に一度程度なので、アウトバウンド通信料金は無視できるレベルですね。
＃今回は話し相手(EC2側)がGitHub Enterpriseなので、I/Fを自由にできないんですよね。。。

[退会済みユーザー]

成功しました！！PublicにつなぐならVPCやサブネットを共有する意味がなかった（というかむしろルートテーブルでサブネットとNAT Gatewayを繋げること考えると、サブネット共有は悪だった。。。）
最終的には下記の手順に沿ってLambda用のPubicに飛び出す道を作ってあげることで解決しました！
https://qiita.com/keitakn/items/b140b7d63f81d86233ce

相談に乗っていただいたことでたどり着けたのでベストアンサーにしつつ、後世のために解決方法に記載しておきます！

Answer 2

問題はLambdaからPublicに飛び出すためのルーティングがまちがっていたことでした。

質問に記載した構成の場合（サブネットをEC2とLambdaで共有している）、サブネットが使うルートテーブルが、EC2はインターネットゲートウェイにつながなきゃいけないのにLambdaはNATゲートウェイにつながなきゃいけないため共存できませんでした。（元の構成のルートテーブルはインターネットゲートウェイにルーティングしていたので、Lambdaが外に出られなかった）

以下の記事の手順でいけました。
https://qiita.com/keitakn/items/b140b7d63f81d86233ce

記事にある絵の通り、Lambda用に以下のようなリソース群を作成しルートしました。

VPC（Labmda用）
サブネット（プライベート、Lambdaが所属）
サブネット（パブリック、NATゲートウェイが所属）
インターネットゲートウェイ（サブネット（パブリック）と繋がり外に出る）
ルートテーブル（サブネット（パブリック）とインターネットゲートウェイのルーティングを規定）
NATゲートウェイ（サブネット（パブリック）に所属し「中から出れるけど外から入れない」を実現する）
ルートテーブル（サブネット（プライベート）とNATゲートウェイのルーティングを規定）