運用アセスメントサービスのご紹介

運用アセスメントサービスのご紹介

プラットフォーム技術部 山本です。 「自社システム運用のレベルはどうなのか?」「漠然と課題感はあり現場は困っているが、経営層に改善の必要性をうまく訴求できない」などなど企業のIT管理部門が抱えるお悩みに応え、弊社の豊富なシステム運用の実績をベースに第三者的な評価サービスを実施してきました。 今回は最近の事例に沿って弊社の「運用アセスメント」サービスについてご紹介いたします。 IT部門が抱える課題、ニーズ IT部門でも特に「システム基盤に関わる各種企画やイベント対応」が山積している中で「日々の運用保守業務」も回さなければならない、予算も少なく体制も拡充しにくい「インフラ担当部署」は悩みが多いと思います。実際そういった悩みを抱え自助努力ではにっちもさっちもいかなくなったお客様からご相談をいただくケースがほとんどです。システム運用管理がしっかり回っていない、そもそも枠組みが整備できていない 個人のスキルに依存 業務負荷の集中、慢性的な高負荷 課題対策や改善が遅々として進まない 要員とスキル不足が深刻でベンダーコントロール、プロジェクトマネジメントに手が回らない。結果、品質が悪くトラブルが頻発。。。と悪循環が止まらない運用アセスメントサービスとは? 表示されている画像の文字が小さくて読みづらい場合は、画像上にて右クリックをしていただき、新しいタブやウィンドウで表示いただくことによって、読みやすい大きさで表示することができます。 弊社運用アセスメントの標準的な評価対象は下記6領域となります。 システム運用保守の評価と改善策検討および改善実行計画の策定までを以下のステップで実施します。  ASIS分析 このステップでは、各種資料確認や数回の現場担当者ヒアリング及び過去障害対応履歴の確認結果から課題を抽出します。 以下は実際のアウトプットサンプル(一部抜粋)になります。抽出した課題から簡潔に総評を纏めました。TOBE検討 このステップでは、ASIS分析ステップで抽出した各課題への対策方針と期待効果及び必要コスト概算を検討しました。 以下は実際のアウトプットサンプル(一部抜粋)になります。 赤枠内が本ステップでの追記内容(優先度、対策方針、難易度、効果、効果目安、必要コスト概算)となります。  各対策の優先度と前後関係を踏まえて全体の関係を図示し、直近実施するスコープをお客様と協議・合意し、まずは優先度高の対策について具体的な実行計画を策定することになりました。  改善策の実行計画策定 優先度の高い対応策について具体的な実行計画を策定しました。 以下は実際のアウトプットサンプル(一部抜粋)になります。 「目的」「目標」「実施イメージ」「スケジュールとWBS」「必要なHW、SWなど」「成果物」「期待効果」の章立てで纏めました。実際にこのお客様では引き続き改善実行フェーズのご支援に繋がり、 これから順次改善をお客様と共に進めていきます。 その他実績 これまで実施してきました運用アセスメント及び改善支援の実績をいくつかご紹介いたします。 駐車場 2005~2009年 アセス後に改善支援を約3年に渡って実施。 各種運用改善から始まり、システム更改プロジェクトなどイベント案件のPM支援から技術支援までお客様の課題・ニーズに柔軟に対応。 物流 2008~2012年 アセス後に改善支援を約3年に渡って実施。 監視基盤構築や基幹業務システムの仮想環境集約移行支援など多数イベント案件対応や運用改善支援などお客様の課題・ニーズに柔軟に対応。 金融 2011~2014年 アセス後に改善支援を約2年半に渡って実施。 基幹業務システムのセンター集約+仮想環境移行のPM支援や各種セキュリティ対策支援などお客様の課題・ニーズに柔軟に対応。 最後に 弊社は下記の基本スタンスに基づき、「お客様のそばで、お客様のためのITを」をモットーに真にお客様に貢献するサービスを提供いたします。お客様が抱える課題の解決を第一に考え、壁を設けず最大限可能な支援を ベンダー製品・サービスに縛られることなく、中立的に解決策を考え、お客様に解かりやすく示します 弊社リレーション有無にかかわらず、フラットに最適なソリューションを持つベンダー、SIerを巻き込み目的指向で解決策を検討します お客様の「費用感」「達成レベル感」「スピード感」「優先順位」を適切に把握し、柔軟かつバランスのよい現実的な解決策を提案します アセスメントやコンサルに終わらず、実効性の高い解決策から具体的な計画に落とし、お客様との確実な合意形成のもと責任をもって結果を出します「運用アセスメント」に限らず、お困りの際はお気軽にご相談ください。
【CVE-2017-5638 / S2-045】SELinuxポリシーのバグフィックスでTomcatアプリのRCEは防げるようになったのか

【CVE-2017-5638 / S2-045】SELinuxポリシーのバグフィックスでTomcatアプリのRCEは防げるようになったのか

プラットフォーム技術部の佐藤です。 だいぶ前の話になりますが、CentOS7/RHEL7のSELinuxポリシーのバグフィックスで、tomcatプロセスを制限のあるプロセス(confined)として動作させられるようになりました。 以前は制限のないプロセス(unconfined)の状態で、実質SELinuxのアクセス制御を受けない状態でした。 Firewallのルールに例えると、制限なし(unconfined)は最後のルールがallow all、制限あり(confined)は最後のルールがdeny allな状態です。RHBA-2017:1861 - Bug Fix Advisory Bug 1432083 – tomcat_t domain is in unconfined_domainただ、実はこのバグフィックスだけではtomcatサービスが起動できない状態になってしまうので、そのまま適用するためには次のバグフィックスまで待つ必要がありました。RHBA-2018:0763 - Bug Fix Advisory Bug 1470735 –
CentOS 5.11 で AWS CLI を使ってみた

CentOS 5.11 で AWS CLI を使ってみた

こんにちは。AWSを触り始めて約半年、入社2年目。プラットフォーム技術部の大畑です。 先日、CentOS 5.11環境でAWS CLIを使う機会があったのですが、主な導入方法として公式で紹介されているpipではインストールすることが出来ず、導入前から若干ハマるという事件が起こりました。 CentOSと言えば、2018年5月現在の最新バージョンは7系ですが、場合によっては古いOSを使い続けなければならないこともあるかと思います。 そこで本記事では、CentOS 5.11におけるAWS CLIの導入方法についてまとめてみたいと思います。※CentOS 5系のサポート期限は2017年3月31日で切れています。  今から導入する人はくれぐれも化石バージョンを選ばないようにしましょう。 環境・制約条件CentOS 5.11 なるべく現行システムに変更を加えない 最低限のツールのみをインストールする導入方法 Python 2.6の導入 AWS CLIをインストールするために必要な要件は以下となります。Python 2 バージョン 2.6.5+ または Python 3 バージョン 3.3+ Windows、Linux, macOS, or UnixCentOS
【Webアナリスト⑥】Webサイトでの回遊

【Webアナリスト⑥】Webサイトでの回遊

本連載では、JWA公認 Webアナリスト検定を受けてみたい!という人向けに、私が勉強したことをベースに解説を簡単にまとめ、不定期に公開したいと思います。【受けてみた】JWA公認 Webアナリスト検定 【Webアナリスト①】Webアナリストのお仕事 【Webアナリスト②】Webサイトのボトルネックを特定する 【Webアナリスト③】Webサイトへ集客を行う方法 【Webアナリスト④】集客に関する指標の用語や計算式のまとめ 【Webアナリスト⑤】Webサイトへの流入 【Webアナリスト⑥】Webサイトでの回遊(本記事)こんにちは。ソリューション開発部 情報発信分科会の佐々木です。 今回はWebサイトでの回遊について解説します。 回遊とは、「ユーザーがWebサイトやページ内のコンテンツを見て回ること」を指します。回遊の分析においては、サイトを訪れたユーザーが目的の情報に辿りついているかに着目することが大切です。 流入の分析とサイトの改善 入口ページの分析と改善 ユーザーがサイトの入口となるページだけを見て帰ってしまった数を直帰数、サイトの閲覧を開始したセッションの総数のうち最初の1ページ目だけを見て帰ったセッションの割合を直帰率といいます。入口ページを分析する際は、まずサイトの直帰率を確認するところから始めます。 閲覧開始数が多く、直帰数・直帰率の高いページがある場合、ページに基本的な欠陥(読み込みに時間がかかりすぎる、ユーザーが知りたい情報がどこにあるかわからない等)がある可能性が高いです。ユーザー目線でページを訪問して検証を行い、ページの欠陥を優先的に修正していきます。 また、流入数が少なく直帰数・直帰率が低いページがある場合にはSEOやリスティングなどによって流入数を増やす施策を行います。 流入数が少なく直帰数・直帰率が高いページについては、直帰数を減らす施策を行ったとしても流入数が少ないため改善のインパクトが低いと考えられます。そのため、改善の施策を行うかどうか検討する必要があります。 サイト内の経路分析と回遊の改善 入口ページの分析の次は、サイト内の経路分析を行います。 ユーザーがサイト内をどのように回遊して、どこから離脱したかを確認し、ユーザーが想定していたシナリオ通りにサイト内を進んでいるか、迷っている遷移はないかなどを分析していきます。 離脱とは 次のページを読み込むまでをページ滞在時間、サイト内でユーザーが閲覧した最後のページ(離脱ページ)を読み込むまでをサイト滞在時間といいます。なお、ユーザーが入口ページから直帰してしまった場合はページ滞在時間もサイト滞在時間もわかりません。サイトを閲覧中にユーザーが別サイトに飛んだ場合でも、セッションが切れていなければ(別サイトに飛んでから戻ってくるまでの間が30分未満であれば)サイトの滞在時間も継続されます。また、別サイトに飛んでいなかったとしても、1つのページに30分以上滞在するとセッションが切れてしまうため、サイトの滞在時間はそこでリセットされます。セッションが切れていない場合も、ブラウザを閉じてしまうとページの滞在時間はリセットされます。ユーザーが離脱した数を離脱数、ページが表示された回数(ページビュー数)のうち離脱ページになった割合を離脱率といいます。 各ページの離脱率とコンテンツの内容を確認し、ユーザーが想定したページ(コンバージョンページ等)で離脱しているかどうかを検証します。 コンバージョンページ コンバージョンとは、サイト運営者が望むページにユーザーが辿り着くことを差します。このとき、ゴールとなるページのことをコンバージョンページといいます。コンバージョンページのページビュー数から、どれだけのユーザーがサイト運営者の望むアクションを行ったかを計測することができます。 【コンバージョンページの例】商品を購入した後の完了ページ メールマガジンの登録完了ページ アンケートの回答完了ページまた、コンバージョンページが存在しないサイトの場合は、以下の方法でユーザーのアクションを計測することができます。 仮想ページビューによるページトラッキング サイト内に仮想のページを設定して、その仮想ページのページビュー数を計測することでユーザーのアクションを計測します。 この方法は、資料のダウンロードや外部サイトへの誘導が目的のサイト、同一URLのページの遷移でゴールページを表示するようなサイトの計測に適しています。 イベントトラッキング 計測したいユーザーのアクションをイベントとして計測します。 この方法は、Q&Aサイト等でページ内リンクのクリック数を計測する場合や、上述の仮想ページビューと同様に資料のダウンロードや外部サイトへの誘導を目的としたサイトの計測に適しています。 おわりに ユーザーがサイトを訪問したとしても、コンバージョンページに辿り着けなければサイトの目的は達成されません。ユーザーが途中で離脱していないか、離脱していまう原因は何かを分析していく必要があります。 ページの滞在時間とサイトの訪問時間は難しいかもしれませんが、きちんと理解しましょう。 今後も引き続き、Webアナリスト関連の記事を書いていきますので、どうぞよろしくお願いいたします。ソリューション開発部では、資格・検定の取得や各種セミナーの受講にも力を入れています。メンバー自らが受講してみたい講座を選ぶことによって、自らの意志によってスキルアップができる環境を整えています。Webアナリスト検定 連載一覧【受けてみた】JWA公認 Webアナリスト検定 【Webアナリスト①】Webアナリストのお仕事 【Webアナリスト②】Webサイトのボトルネックを特定する 【Webアナリスト③】Webサイトへ集客を行う方法 【Webアナリスト④】集客に関する指標の用語や計算式のまとめ 【Webアナリスト⑤】Webサイトへの流入 【Webアナリスト⑥】Webサイトでの回遊(本記事)
AWS PrivateLinkの使い方と注意点 ~VPCピアリングとの使い分け~

AWS PrivateLinkの使い方と注意点 ~VPCピアリングとの使い分け~

プラットフォーム技術部の小林です。 本記事ではVPCサービスとして提供されているPrivateLinkについて、2017年11月のリリース以降エンハンスされた機能も含めた現行機能の整理と、PrivateLinkの使いどころや注意点などをまとめます。 最後に、実際にPrivateLinkを使ってプライベートサブネットからインターネットを経由せずにKinesisに対してAPIコールを実行する手順を掲載します。 PrivateLinkって何? PrivateLinkとは「AWSへのAPIアクセスをインターネットを経由せずに行えるインターフェースタイプのVPCエンドポイント」です。 PrivateLinkを使うことでインターネットに出る必要がなくなるため「IGW、NATデバイス、VPNコネクション、パブリックIP」の導入・設定が不要になり、環境設計が必要なコンポーネントを減らすことができます。また、セキュリティ要件の厳しいシステムやクローズドな環境での稼動が必須となるシステムをAWS上に構築する際に役立ちます。 そもそもVPCエンドポイントって何? さきほどのPrivateLinkの説明の中でPrivateLinkはインターフェースタイプのVPCエンドポイントと書きましたが、そもそもVPCエンドポイントとは何でしょうか。 VPCエンドポイントとは、VPCと他のサービス間の通信を可能にするVPCコンポーネントで、その実態は仮想デバイスです。VPCエンドポイントをVPCに作成することで、VPC内のインスタンスとVPC外のサービスとで通信ができるようになります。(詳細はVPCエンドポイントのガイドを参照してください。) VPCエンドポイントは下記の2つのタイプが提供されています。インターフェースタイプPrivateLinkと呼んでいる 実態はプライベートアドレスをもつENIゲートウェイタイプルートテーブルで送信先に対するターゲットとして指定する二つのタイプのVPCエンドポイントを使用した構成例を下図に示します。タイプによって、インスタンスとサービス間での通信経路が異なります。 ゲートウェイタイプを使用する場合はルーティング設定が必要です。図に示したルートテーブルにあるように、Destinationとして「使用するサービスのエンドポイント(この場合は東京リージョンのS3のpl-id(プレフィックスリストID))」、Targetとして「作成したVPCエンドポイントのID(vpce-id)」を指定します。このルートを設定することでVPC内部からVPC外のサービスへの通信ができるようになります。  タイプによる違いを整理:ゲートウェイとインターフェース ゲートウェイタイプとインターフェースタイプで異なる制限を下表に整理します。 [table id=12 responsive="desktop"/] カテゴリとサービス一覧 タイプによって利用できるカテゴリとサービスが異なりますので、それぞれ利用できるものを整理します。 カテゴリ一覧 まずはカテゴリの一覧です。2018年5月時点で利用できるカテゴリは下表のとおりです。 [table id=13 responsive="desktop"/] サービス一覧 つぎは各カテゴリで利用可能なサービスについて整理します。 AWSサービス まず1つめの「AWSサービス」カテゴリでは、AWSプリンシパルなサービスが提供するエンドポイントを選択できます。 下表に、現時点で提供されているサービスと対応するエンドポイントタイプ、エンドポイントをまとめています。 [table id=14 responsive="desktop"/] ※"amazon"、"aws"という語は省略してサービス名順に並べています 昨年11月のre:invent 2017で紹介されたサービスや、2018年になって新たに追加されたサービスも記載しています。いずれも東京リージョンで利用可能なサービスです。VPCエンドポイントに対応するサービスはどんどん追加されていきますので、VPCエンドポイントを使用する際にはその時点でどのサービスが利用可能なのかを確認するようにしましょう。 なお、公式のVPCエンドポイントのガイドに掲載されているサービス一覧表は最新の状態にアップデートされていないため、2018年5月時点ではこちらの表に記載の内容が正しいです。ご注意ください。 独自サービス 2つめは「独自サービス(VPCエンドポイントサービス)」です。 マネジメントコンソールでは「サービスを名前で検索」というカテゴリで表示されています。インターフェイスタイプのエンドポイントが利用可能なカテゴリです。 独自に作成したサービスをVPCエンドポイントサービスとして公開し、AWSネットワークに閉じて利用することができます。利用するにはNLBの作成が必須です。 独自サービスを利用するために図に示したように3つのステップで設定していきます。①独自アプリケーションの前段にNLBを配置して、②NLBを指定してVPCエンドポイントサービスを作成します(例:com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxxxxxx)。③そのVPCエンドポイントサービスに接続するインターフェースVPCエンドポイントを作成します。エンドポイントサービスの作成にはNLBの関連付けが必須となりますのでご注意ください。  図に示したように、PrivateLinkとNLBのVPCエンドポイントサービスを使用することで異なるVPC間の通信が可能になります。となると、VPCピアリングとの使い分けについても気になると思いますがそちらについては「VPCピアリングとの違い」の節でまとめていますので参考にしてください。 マーケットプレイスサービス 3つめはマーケットプレイスサービスです。 マネジメントコンソールでは「ご使用のAWSマーケットプレイスサービス」として表示されています。このカテゴリは2017年11月に追加されたカテゴリです。AWSマーケットプレイスが提供するサービスを利用できます。対応するタイプはインターフェイスタイプのみです。マーケットプレイスでSaaSとして提供されているサービスに対してVPCエンドポイントを作成することで、インターネットを介さずにSaaSを利用することができます。 [blogcard url="https://aws.amazon.com/jp/about-aws/whats-new/2017/11/aws-privatelink-on-aws-marketplace-now-available/"] 2018年5月時点で利用可能なVPCエンドポイント対応のマーケットプレイスサービスは下表のとおりです。 [table id=15 responsive="desktop"/] セキュリティ関連のSaaSが利用可能になっているようです。こちらも随時対応サービスが拡張されていくと思いますので、VPCエンドポイントを使用したSaaS利用を検討している方はチェックしておきましょう! VPCピアリングとの違い 独自アプリケーションのVPCエンドポイントサービスを作成することができるようになり、異なるVPC間での通信が可能になりました。「異なるVPC間での通信」という観点で、PrivateLink機能を利用するべきか、VPCピアリングを利用するべきかを検討する際の参考情報として下表に機能の違いを整理しました。 [table id=16 responsive="desktop"/] ユースケース 上記の比較を受けて、PrivateLinkはどのような状況で使用するべきでしょうか。 独自のサービスにクローズドな環境で通信をしたい場合はPrivateLinkが適しているかもしれません。また、そのサービスがマーケットプレイスでエンドポイントサービスとして提供されているものである場合はPrivateLinkを選択しましょう。 Direct Connect接続経由のエッジツーエッジルーティングを実現したい場合は、VPCピアリング接続では実現できないのでPrivarteLinkを選択する必要があります。 VPCのCIDRブロックが重複している場合も、VPCピアリング接続での実現ができないのでPrivateLinkを使用します。すでに存在するVPC同士を接続する場合は、CIDRブロックを確認してVPCピアリング接続が可能かどうかを確認しましょう。 現在のネットワーク構成やセキュリティ要件、通信要件からはVPCピアリングとPrivateLinkのどちらを使用しても大差ないという状況であれば、設計・構築・運用の作業の大変さ、という観点でどちらがいいかを検討するのもよいでしょう。 VPCピアリングを使用する場合は、ルートテーブル/NACL/SGでアクセスを限定していくので詳細な制御ができる反面、設計や構築作業、構築後のメンテナンスが複雑になってしまうかもしれません。PrivateLinkを使用することで通信経路が可視化され構成図がシンプルになる可能性もあります。現行の運用方法に即して選択することをおすすめします。 PrivateLinkを使ってみる 実際にPrivateLinkを使ってみます。今回は下図のような簡易な構成を作成していきます。 プライベートサブネット内のインスタンスからインターネットを経由しないでKinesisのエンドポイントにAPIアクセスをしてみます。PrivateLinkの作成 VPCサービスから「エンドポイント > エンドポイントの作成」と選択します。サービスカテゴリは「AWSサービス」を選択します。 表示されたサービス名の一覧から「Kinesis-streams」サービスを選択します。(東京リージョンで作業をしているので、com.amazonaws.ap-northeast-1.kinesis-streamsと表示されています)つづいて、VPC、AZ、プライベートDNS設定、セキュリティグループを選択していきます。 VPCをプルダウンから選択すると利用可能なAZとサブネットが表示されるので、VPCエンドポイントを作成するサブネットを選択します。プライベートサブネット内のインスタンスから、AWS CLI によってVPCエンドポイントに対してHTTPS で
【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編

【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます!【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展! 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編 【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編(本記事)本サービスの詳細や、Zabbixを活用したソリューションにご興味をお持ちの方がいらっしゃいましたら サービス紹介ページ からお気軽にお問合わせ下さい。こんにちは!プラットフォーム技術部の齊藤(沙)です。 前回はZabbixが監視設定や履歴データを保管するデータベースの中でも監視項目であるアイテムに関連するテーブルについて確認しました。今回は監視閾値であるトリガーに関連するテーブルについて確認していきます。 Zabbixを知ろう -Zabbixのデータベースについて –
MR花見~HoloLensで花見をしよう~

MR花見~HoloLensで花見をしよう~

こんにちは。ソリューション開発部 HoloLens分科会の中川です。 先生、花見が、、、したいです。 季節が巡るのはホントに早いですね。 ふと思い立って花見をしようとしたら、なんととっくに桜は散っていたんですよ。 満開の時は何となく、いつでもできるから、という気になって結局やらず。 桜が散ってから花見がしたくなる気持ち、わかりますよね? しかし2018年になった今、我々にはMR(Mixed Reality)という技術があるではないですか。 肌寒い中で無理して冷たいビールを飲むなんて時代遅れですよ。 外が寒ければ屋内で花見すればいいじゃない。 桜が散ってしまったなら、また咲かせればいいじゃない。   そう、時代はMR花見だ! HoloLensで花見をしよう!!   MR花見を作るのだ。 というわけで、MR花見アプリを作りましょう。 終業時刻までに完成させて、定時になると同時に花見をしたいので急いで作らなければなりません。 基本は過去の記事「MixedRealityToolkit-Unityを使ったHoloLens開発クイックスタート」の手順そのままです。 円柱の代わりに桜の木のCGを用意すればいいだけです。 慣れれば5分もかからない作業です。 桜の木のCGが手元になかったので、Freeの木のAssetをダウンロードし、緑の葉の部分を桜色に塗りつぶして代用することにしました。  普通の緑の木  葉をピンクにするだけで、桜っぽく見えてくる不思議。  MRならサイズは自由なので、机の上に桜を咲かせることもできます。  無事に花見ができました。 キャプチャした画像だと桜の存在感が薄いですが、HoloLensを通してみるともっときれいに見えます。 しかしHoloLensをかけているのは私だけなので、他のメンバーはただ単にオフィスで一杯やっているだけですが。   MRと季節行事は相性がいい。 VR花見だと手元のビールが見えないので困りますが、MRなら普段通りに花見をすることができます。 現実とヴァーチャルを融合するMRのお手本のような活用方法ではないでしょうか。 夏以降も、MR花火大会、MR月見、MRハロウィンやMRホワイトクリスマスなどなど、いろいろな応用ができそうです。
AWS LambdaをVPC内に配置する際の注意点

AWS LambdaをVPC内に配置する際の注意点

はじめまして。プラットフォーム技術部の山崎です。 オンプレ環境のEOSL対応から始まったAWSリプレースプロジェクトで、インフラ周りの設計構築を担当しています。そこで得たナレッジをご紹介していきます。 今回はAWS LambdaのVPC内ヘの配置についてです。手軽にできるものと思っていたら、環境設定でいくつか考慮すべきことがありましたので、配置する際の注意点をまとめます。VPC内にLambdaを置くケース まずはじめに、Amazon Web Serviceの公式見解では、LambdaをVPC内に置くメリットは基本的にないというスタンスです。しかし、Amazon EC2やAmazon RDSなど、VPC内にあるリソースとLambdaで内部通信する場合はVPC内への配置が必要となります。例えば外部公開しないADサーバーとLambdaで認証情報をやりとりする、など。 [blogcard url="https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html#lambda-vpc"]VPC内に配置する際の注意点 主に5つです。 LambdaをVPC内に配置すると、Lambda実行時にENI(仮想ネットワークインターフェース)が付与されるようになります。それに伴い考慮すべきことがあります。 セキュリティグループの設定 Lambdaに対してセキュリティグループが設定できるようになります。 EC2/RDS等のVPC内リソースのセキュリティグループにて、Lambdaからのアクセスを許可しましょう。設定内容はLambdaのセキュリティグループや、Lambda専用サブネットを作成していたらそのサブネットなど、環境により適切な方法で設定します。 Lambdaのセキュリティグループは必要に応じて設定しますが、API Gatewayなど呼び出し元が特定できない場合はデフォルトのままとすることもあります。 IAMロールの設定 Lambda自身がENIを作成/削除できるようにするため、Lambdaに対してIAM(Identity and Access Management)権限を付与します。既にIAMポリシーとして「AWSLambdaVPCAccessExecutionRole」が用意されているので、Lambda用のIAMロールを作成する際にこのポリシーをあてて設定することも可能です。 所属サブネットの残りのIP 当然ながらVPCサブネットのプライベートIPアドレスを浪費するので、サブネット内の残りのIP数が枯渇しないよう注意してください。AWSのベストプラクティスでは、他のAWSリソースに影響が出ないようLambda専用のサブネットを用意することを推奨しています。冗長化のため、Lambdaも他のAWSリソースと同様マルチAZ(アベイラビリティゾーン)で構成します。 起動スピードが若干遅くなる Lambda実行時、ENIを作成しLambdaに付与する時間(数秒~数十秒程度)がかかります。 ただし、時間がかかるのは初回のLambda実行時のみで、それ以降は基本的には付与されているENIを使いまわします。Lambda実行リクエストが一定時間なければENIは自動削除されます。 なお、遅延時間分はLambda実行時間にはカウントされないため、その分の料金は計上されません。どうしても初回遅延が許容できないというのであれば、定期的にダミーのLambda実行をしてENIを自動削除させない、といった方法も考えられますが、仕組みは自身で構築する必要があります。 VPC外でも、厳密に言うとENI作成ほどではありませんがLambda初回実行時は若干時間がかかります。「コンテナ」と呼ばれるLambda実行環境を作成するためです。外部ネットワークと通信する際は、、、 ここが一番のポイントです。外部ネットワークと通信する際は、NATゲートウェイ等の設定が必要です。VPC内にあるLambda(ENI)にはパブリックIPが付与されないので、外部ネットワークと通信することができません。そのため、VPC内のパブリックサブネットにNATゲートウェイもしくはNATインスタンスを設定します。 結果、Lambdaの送信元IP(グローバルIPアドレス)は固定されることになります。 NATゲートウェイの場合は、冗長化を考慮するとAZ毎に設定が必要になるため、NATゲートウェイのコストが2,3倍となることも考えられます。まとめ VPC内にLambdaを置く場合は通信関連の考慮が必要になり、場合によってはランニングコストが増えるかもしれません。「お金がかかるのでNATゲートウェイを使用しない」という方針で設計すると、このようなケースでどうしても必要になることもありますので、アプリケーションや認証関連でLambdaを内部通信させる必要があるのか、事前に把握しておくとよいと思います。