Category: Networking & Content Delivery

AWS Lambda は、サーバーをプロビジョニングまたは管理する必要なしでコードを実行できるサービスです。コードをアップロードするだけで、Lambda がすべての作業を実行してコードを実行およびスケーリングして、高可用性を実現します。現在、AWS のお客様の多くは、このサーバーレスコンピューティングプラットフォームを使用して、アプリケーションの開発と運用中に生産性を大幅に向上させています。 本日、AWS Lambda が AWS PrivateLink をサポートすることをお知らせいたします。これにより、トラフィックをパブリックインターネットに公開することなく、Virtual Private Cloud (VPC) やオンプレミスのデータセンター内から安全に Lambda 関数を呼び出すことができるようになります。 これまでは、Lambda 関数を呼び出すために、VPC には インターネットゲートウェイ、ネットワークアドレス変換 (NAT) ゲートウェイ、パブリック IP アドレスが必要でした。今回の更新により、PrivateLink は AWS プライベートネットワーク経由でコールをルーティングするため、インターネットアクセスが不要になりました。さらに、AWS Direct Connect または AWS VPN 接続を使用して VPC に接続することで、オンプレミスのデータセンターから Lambda API を直接呼び出すことができるようになります。

先日 (2020/10/21) 開催しました AWS Black Belt Online Seminar「Amazon VPC 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201021 AWS Black Belt Online Seminar Amazon VPC AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. オンプレミス設計ではいくつかのネットワークを使い分けていました。1. サービス用NW 2. バッチ用NW 3. 管理用NW。Linux であれば bond0, bond1, bond2 と複数のデバイスを割り当てていました。分けていた理由は NW ACL 設定を分けるため (バッチ用 NW と管理用NWのみ SSH 許可 かつ SSH デーモンが Listen するのも対象I/Fのみ、など)　それぞれ N/W 帯域を使い切ってしまったときに影響を局所化するため、でした。Amazon VPC では、どのように設計するのがよいのか教えていただけますか？オンプレミス比較でのドキュメント、ホワイトペーパー、ブログなどあれば紹介いただけると助かります。 A. クラウドコンピューティングのためのアーキテクチャ・ベストプラクティス はいかがでしょうか。オンプレミスの考え方をそのまま踏襲してしまうと余計な手間やコストを生んでしまうので Well-Architectedフレームワークを利用してよりよいアーキテクチャを作ることをおすすめいたします。 […]

みなさん、こんにちは。セキュリティ ソリューション アーキテクトの中島です。先日(2020年10月23日)にオープンソースで公開した SIEM on Amazon Elasticsearch Service (Amazon ES) をご紹介します。SIEM on Amazon ES は、セキュリティインシデントを調査するためのソリューションです。AWS のマルチアカウント環境下で、複数種類のログを収集し、ログの相関分析や可視化をすることができます。 SIEM on Amazon ES とは SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。Amazon ES は、オープンソースの Elasticsearch と Kibana を大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。Amazon ES の環境に SIEM として必要な機能を実装したのが SIEM on Amazon ES です。

先日 (2020/10/22) 開催しました AWS Black Belt Online Seminar「AWS App Mesh Deep Dive」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201014 AWS Black Belt Online Seminar AWS App Mesh Deep Dive AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. APM として New Relic を採用しています。 Envoy のコントロールプレーンとして Istio を利用した場合New Relic 提供の newrelic-istio-adapter が利用できますが、Envoy のコントロールプレーンとして AWS App Mesh を利用した場合どのような方法があるのか教えていただけますか？Roadmap の話は QA 対象外ということですので、現時点での代替案、ワークアラウンドなどについて教えていただけますか？ A. 現時点では、New Relic を利用する方法はありませんが、Envoy のメトリクスについては、Prometheus でのモニタリング、または […]

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1：サーバーレス LAMP スタックの紹介 パート2：リレーショナルデータベース パート3：Webサーバーの置き換え パート5：CDK コンストラクトライブラリ パート6：MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプローチで Laravel アプリケーションをデプロイする方法を学びます。 これは「サーバーレス LAMP スタック」シリーズの4番目の投稿になります。過去の投稿はこちらです。 パート1：サーバーレス LAMP スタックの紹介 パート2：リレーショナルデータベース パート3：Webサーバーの置き換え Laravel は PHP 用のオープンソースの Web アプリケーションフレームワークです。フレームワークを使用すると、開発者は一般的なコンポーネントとモジュールを再利用することで、より速く構築できます。また、開発標準に準拠することにより、長期的なメンテナンスにも役立ちます。ただし、従来の LAMP スタックを使用して PHP フレームワークをスケーリングする場合は、まだ課題があります。サーバーレスアプローチを使用してフレームワークをデプロイすると、これらの課題の解決に役立ちます。 Laravel アプリケーションのサーバーレスインフラストラクチャへの展開を簡素化する方法は数多くあります。ここで紹介する方法では、AWSサーバーレスアプリケーションモデル（AWS SAM）テンプレートを使用しています。これによって、Laravel アプリケーションが単一の Lambda 関数にデプロイされます。この関数は、Bref FPM カスタムランタイムレイヤーを使用して PHP を実行します。AWS SAMテンプレートは、「サーバーレス LAMP スタック – パート3: […]

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1：サーバーレス LAMP スタックの紹介 パート2：リレーショナルデータベース パート4：サーバーレス Laravel アプリの構築 パート5：CDK コンストラクトライブラリ パート6：MVC からサーバーレスマイクロサービスへ この投稿では、Web サーバーを使用せずにサーバーレス PHP アプリケーションを構築する方法を学びます。 この投稿の後半で、bref および Serverless Visually Explained の作成者である Matthieu Napoli が FastCGI Process Manager の実装を Lambda 関数内で使うことでそれを可能にする方法を説明しています。Bref は、PHP 用のオープンソースのランタイム Lambda レイヤーです。 また、プライベート Amazon S3 バケットから静的アセットを安全に提供およびキャッシュするように Amazon CloudFront を構成する方法を示します。動的リクエストは、その後 Amazon API Gateway にルーティングされ、単一の […]

次期自治体情報セキュリティクラウドの見直し 総務省が2020年5月に公開した「自治体情報セキュリティ対策の見直しのポイント」では、次期自治体情報セキュリティクラウドの見直しのポイントが整理されており、追加の対策としてContent Delivery Network(CDN)の活用が求められています。自治体情報セキュリティクラウドとは、各県が県及び市町村のインターネットゲートウェイを集約し共通化したセキュリティ機能及びSOC（セキュリティ専門人材による監視機能）を民間事業者に委託のうえ提供しています。県によっては公式ホームページ等のWebサーバをホスティングとして提供していることもあるでしょう。昨今、災害時等インターネットからの通常時とは異なる大量のウェブアクセスや DDoS 攻撃を受けることで、ウェブサーバ処理能力の限界到達又は接続回線帯域の圧迫となり、コンテンツ提供の遅延や提供不可となりうる状況が懸念されています。住民・自治体双方にとって公式ホームページは市民接点となる重要サービスの位置づけであり、災害等の有事の際にも常時利用できるように対応しておく必要があります。Webサーバへのキャッシュ対応及び DDoS 対策として、コンテンツ配信サービス機能を導入し、DDoS 対策も講じることは、自治体情報セキュリティクラウドに限ったことでなく自治体が独自に運用しているWebサーバにおいても必須と言えるでしょう。 なぜAWSのCDNを利用するのか？ Amazon CloudFrontが配置されているエッジロケーションは日本国内だけで 18 拠点以上あり，これは3年前（2017年）と比較して3倍以上の数に増えています。AWSのCDNではありますが、元データの存在元（オリジン）はAWS以外の環境（オンプレミスなど）でも利用することが可能です。 Amazon CloudFrontは、AWS Shield Standardというマネージド型の分散サービス妨害 (DDoS) に対する保護サービスと連携され、追加料金なく、インフラストラクチャ (レイヤー 3 および 4) を標的とする既知の攻撃を総合的に保護できます。また、クライアント端末の所在地(国情報)を判別し挙動に反映できる補完機能をもっており、特定国、地域等からの攻撃を遮断する機能を有します。Amazon CloudFront では、SSL/TLS 経由でコンテンツや API、アプリケーションを配信できるため、高度な SSL 機能が自動的に有効になります。 アクセス・トラフィック量の確認が管理コンソールより GUI で可能であり、トラフィック量が超過した場合などにアラーム（メール）などでの通知が可能です。さらに、AWS WAFを併用することで、一般的なWebの脆弱性からWebアプリケーションまたは API を保護するWebアプリケーションファイアウォールを適用し、SQLインジェクションのような、Webアプリケーションへの不正な通信を検知・防御することが可能です。また、これらのサービスは、クラウドの特徴を生かした完全従量課金であるため初期費用がゼロで始められる点などコストパフォーマンスが良いため、公共機関を含む多くの日本のお客様にご利用いただいています。Amazon CloudFront、AWS WAF共に、ISO/IEC27017:2015 の認定を受けています。 自治体情報セキュリティクラウドを踏まえた利用パターン 自治体の公式ホームページにおいて導入実績が多いCMS（LAMP構成）を想定したAWS上で構成する際の構成例(図１）を記載します。 ①オリジンはオンプレミス ・Webサーバ、CMSは従来のセキュリティクラウドに配置し、CDNの機能にAmazon CloudFront、そしてAWS WAFを利用します。BCP対策としてWEBサーバのコンテンツをAmazon S3へコピーします。 ②オリジンもAWSへ移行 ・Webサーバ、CMSをAWSへ移行し、CDNの機能にAmazon CloudFront、そしてAWS WAFを利用します。BCP対策としてWEBサーバのコンテンツをAmazon S3へコピーします。オリジンとなるWebサーバ、CMS、データベースをAWSに移行することで、容易にマルチAZ構成に対応できるため、一層継続性の高いサービスを提供することが可能です。 ※図１　自治体CMSの構成例 まとめ 自治体情報セキュリティクラウドの見直しに合わせて、自治体公式ホームページ等のWebサイトにAmazon […]

Amazon CloudFront は AWS グローバルネットワークを使用して、静的および動的なウェブコンテンツを低レイテンシかつ高速で安全に配信するコンテンツ配信ネットワーク (CDN) です。 この度 CloudFront でリアルタイムに利用可能な、デリバリーログを配信する機能が発表されました。このリアルタイムログには、CloudFront が受け取った全てのリクエストに関する詳細情報が含まれます。詳細な情報をリアルタイムで確認することで、運用イベントに迅速に対応できるようになります。 リアルタイムログでは、収集する情報とその配信先をカスタマイズできます。リアルタイムログは Amazon Kinesis Data Streams と統合されており、Amazon Kinesis Data Firehose を使用して一般的な HTTP エンドポイントにログを配信できます。 Amazon Kinesis Data Firehose では Amazon S3、Amazon Redshift、Amazon Elasticsearch Service (Amazon ES)、および Datadog、New Relic、Splunk などのサービスプロバイダにログを配信できます。このログを使用して、リアルタイムダッシュボードの作成、アラートの設定、異常の調査や運用イベントへの迅速な対応を行うことができます。追跡できる一般的なデータポイントとしては、異なる地理的リージョンからのビューアーリクエスト数や、レイテンシが高いユニークビューアー数などがあります。

学術情報ネットワークSINETは、国立情報学研究所(NII)が構築、運用している日本全国の大学や研究機関などの教育研究機関が接続された情報通信ネットワークです。このたび 学術情報ネットワーク (SINET) 大阪 DC 経由でのSINETクラウド接続サービスが利用可能となりました。これまでも SINET 東京 DC1 経由で複数の10Gbps 回線で接続されておりましたが、このたび協賛企業様のご協力もいただき SINET 大阪 DC 経由においても複数の 10Gbps 回線で接続されました。 今回の SINET 大阪 DC 経由の追加により、いわゆるSINET経由での SINET 利用形態として、 SINET クラウド接続サービス利用での SINET 東京1 DC 経由や SINET 大阪 DC 経由、通常の SINET-IX ピアリングでの利用の経路がそれぞれ利用可能となります。 SINET クラウド接続サービスと通常利用( IX 経由)での接続についての説明は以前ブログにてご紹介いたしました内容をご覧ください。 SINET 大阪 DC 経由の SINET クラウド接続サービスの利用についても、お客様が利用される際の負担は、これまでと同じくAWS側から見でdata outとなるデータ転送料金だけとなります。物理回線費、ポート占有にかかる費用に関してはお客様の負担なくご利用いただけます。 SINETならびにSINETクラウド接続サービス自体が基本的にベストエフォートであり、SLA等が規定されてるわけでは無い点を理解した上で、例えば東京リージョンで基幹系システムをご利用の場合、東京リージョンとの接続をSINETクラウド接続サービスのSINET東京1DC、SINET大阪DC経由の両方を利用することでSINET-AWS間を冗長化するなどが考えられます。 これまでと同様、SINETクラウド接続サービスに関しましては、国立情報学研究所のSINET担当、AWS側の両方へ申請が必要となります。AWS側の申請に関しましては　sinet@amazon.com までお問い合わせください。尚、研究でSINETクラウド接続サービスを利用されている場合には、データ転送料金を低減するプログラムに参加可能な場合がございますので営業 (aws-jpps-er@amazon.com) までお問い合わせください。 — パブリックセクター ソリューションアーキテクト […]

先日 (2020/07/31) 開催しました AWS Black Belt Online Seminar「AWS App Mesh」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200721 AWS Black Belt Online Seminar AWS App Mesh AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. サービスメッシュはマイクロサービスアーキテクチャを構築する当初から導入すべきでしょうか？それとも、ある程度の規模になってから導入するべきでしょうか？ A. マイクロサービスアーキテクチャを採用したワークロードを新規構築する様な場合は、当初から導入することを検討いただければと思います。一方で、規模が小さい間からマイクロサービスアーキテクチャで構築するべきか？といった観点も必要になります。最初はモノリスで開発し、ある程度の規模になって運用の中でシステムのコンテキスト境界が見えてきた段階でマイクロサービスをサービスメッシュと合わせて検討する、といった例もございます。 Q. アプリケーション間の直接通信からサービスメッシュへ移行するためのコスト・タスク量について知りたいです。 A. サービスメッシュへ移行するためのマイグレーション手段はいくつか考えられますが、Envoy を導入したアプリケーションを別途作成し、既存のアプリケーションを縮退させる方法などが考えられます。上記の作業に関して、アプリケーションの規模や通信方式によって移行コストやタスク量が異なってきますので、まず、検証環境でマイグレーションを実施し、事前にコストやタスク量を見積もるよう推奨いたします。 Q. AppMesh と Istio の互換性について教えて下さい A. App Mesh と Istio は、サービスメッシュとしてのモデルや API に互換性はありません。 Q. AWS Lambda のネットワーク通信でも App Mesh は適用可能でしょうか?それとも、もともとの Lambda の設定を見直すだけでApp Meshの機能の一部でも実現可能でしょうか? […]