Category: Advanced (300)

お客様は、それぞれの市場で競争力を維持するために、常にイノベーションを求めています。これを達成するための1つの方法は、サービスとアプリケーションを迅速かつ効率よく構築し、それによってコストを削減しながら市場投入までの時間を短縮することです。より具体的には、アプリケーション全体をゼロから構築するよりも、サーバーレスや AI/ML などのクラウドネイティブな機能を活用して管理コストを削減したり、目的別に作られたサービスを組み合わせたり、すでに構築済みのアプリケーションを再利用したりすることが有効です。 このブログ記事では、AWS Serverless Application Model (AWS SAM) と AWS CloudFormation を使用して、サーバーレスアプリケーションをビルドしてデプロイする方法を説明します。また、AWS Serverless Application Repository を使用して既存のアプリケーションを再利用し、開発時間を短縮します。

注：このブログでは、AWS サービスの IP レンジの情報から AWS WAF IP セットを自動的にアップデートする方法を説明しています。こちらの関連ブログでは VPC Security Group で使用されている Amazon CloudFront の IP レンジについて、同様のアップデートを行う方法を説明しています。 AWS Managed Rules for AWS WAF を使用すると、Web アプリケーションのベースライン保護をすばやく構築することができます。しかし、状況によっては AWS サービスの IP アドレスレンジで IP セットを作成し、これらサービスからのトラフィックを許可したい時があります。このブログでは AWS WAF の IP セットを、AWS サービスの Amazon CloudFront、Amazon Route 53 のヘルスチェック、Amazon EC2（さらに AWS Lambda、Amazon CloudWatch など、同じ IP アドレスレンジを共有するサービス）の IP アドレスレンジで自動的に更新するソリューションを紹介します。これらのサービスは AWS Managed Rules のAnonymous […]

この記事は、Building a Multi-Tenant SaaS Solution Using AWS Serverless Services を翻訳したものです。 本投稿は、AWS SaaS Factory の Sr. Partner Solutions Architect である Anubhav Sharma と AWS SaaS Factory の Partner Solutions Architect である Ujwal Bukka により寄稿されました。 SaaS (Software-as-a-Service) 提供モデルへの移行に際しては、コストと運用効率を最大限に高めたいという要望が伴います。 これは、利用傾向を予測することが困難なマルチテナント環境では特に難しい場合があります。なぜならば、テナントの活動とリソースの実際の消費量を一致させるスケーリング戦略の組み合わせを見つけることは困難だからです。今日はうまくいっていても、明日はうまくいかないかもしれません。 このような特性により、SaaS はサーバーレスモデルに非常に適していると言えます。SaaS のアーキテクチャからサーバーの概念を取り除くことで、企業はマネージドサービスを利用することによって、アプリケーションが消費するリソースの正確な数をスケーリングして提供することができます。 これにより、アプリケーションのアーキテクチャと運用のフットプリントが簡素化され、スケーリングポリシーを継続的に追跡・管理する必要がなくなります。また、運用上のオーバーヘッドや複雑さも軽減され、運用責任の多くをマネージドサービスに委ねることができます。 この記事では、機能的なマルチテナントのサーバーレス SaaS 環境に関してエンドツーエンドで提供するリファレンスソリューションを見ていきます。その目的は、このリファレンスソリューションを作成する際に考慮されたアーキテクチャと設計の検討事項を探ることです。

AWS Config  は、AWSリソースがあるべき設定状態に準拠しているかを監査するサービスです。記録された設定項目の数と 1 か月あたりのリソースごとに行われる AWS Config Rules の評価件数に基づいて課金されます。 この記事では、Amazon Athena を使用して AWS CloudTrail ログをクエリし、AWS Config Rules 評価の詳細な請求内訳を確認する方法をご紹介します。請求の内訳を把握することで月額コストに最も寄与しているルールを特定することができれば、特定のルールの実行頻度を減らしてコストを抑えるといったコスト最適化施策を講じることができます。なお、この記事ではAWS Configの設定項目の確認については触れていません。詳細については、ブログ記事「Identifying resources with the most configuration changes using AWS Config」を参照してください。

Prometheus は人気の高いオープンソースのメトリクスモニタリングソリューションで、さまざまなワークロードで広く利用されています。Prometheus を使用してコンテナワークロードを監視するのが一般的ですが、Prometheus は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスやオンプレミス環境の仮想マシン (VM)、サーバーの監視にも使用されています。 Amazon Managed Service for Prometheus (AMP) は、インフラストラクチャおよびアプリケーションメトリクスのための Prometheus 互換のモニタリングサービスであり、お客様は大規模なワークロードを安全にモニタリングすることが容易になります。セルフホスト環境で Prometheus を使用するお客様は、高可用性、拡張性、安全性を備えた Prometheus サーバー環境、メトリクスの長期保存のためのインフラ環境、アクセス制御の管理に課題を抱えています。AMP は AWS Identity and Access Management (IAM) と密に統合されたフルマネージドな環境を提供することで、これらの課題を解決します。

アマゾンのCEOであるアンディ・ジャシーの言葉を借りれば、『経験のための圧縮アルゴリズムは存在しません』ということになります。5000を超えるSAPのお客様がAWSを利用されていることにより、AWSはSAPワークロードの革新のためのプラットフォームとなっています。AWSはお客様起点の行動指針に基づくというリーダーシップ・プリンシプルに基づき、SAPのお客様が世界中のAWSリージョン内で堅牢性と信頼性の高い且つスケーラブルなSAPシステムを構築できるよう、多様なツールやサービスを提供しております。このブログでは、AWSプラットフォーム上に信頼性の高いSAPシステムを構築するための複数のAWSサービスについて紹介します。

本投稿は AWS のソリューションアーキテクトである Jack Iu、 カスタマーソリューションマネージャー Henry Su、アカウントマネージャー Gloria Vargas による寄稿を翻訳したものです。 金融業界による ISO 20022 通信メッセージ規格の採用は、銀行、市場インフラ、企業、消費者など、ペイメントチェーン全体のすべての参加者に利益をもたらします。SWIFT メッセージングおよび通信インフラストラクチャスタックを AWS に移行することで、お客様は ISO 20022 の導入を迅速化できます。同時に、コストを削減し、重要な支払いチャネルのセキュリティと回復性を向上させることができます。また、AWS クラウドの導入により、ISO 20022 の豊富なデータモデルを使用して、銀行はより俊敏性と革新を実現でき、顧客に対しよりよい支払い体験を提供することができます。

この記事は Under the hood: FireLens for Amazon ECS Task (記事公開日: 2019 年 11 月 18 日) を翻訳したものです。 2019 年 11 月、Amazon ECS は FireLens によるカスタムログルーティングのサポートを発表しました。FireLens によって、人気の高いオープンソースのロギングプロジェクトである Fluentd や Fluent Bit を簡単に使用することができ、さまざまな AWS サービスやパートナーの宛先にログを送信することができます。 この記事では、私たちがなぜ、どのようにして FireLens を作ったのか、詳しく説明します。また、私が FireLens を使用した結果を共有し、FireLens を設定するための推奨事項を紹介します。この記事では、FireLens、Fluent Bit や Fluentd について深く掘り下げます。Fluentd や Fluent Bit に馴染みのない方は、読み進める前に、Fluentd や Fluent Bit と FireLens のドキュメントをよく理解しておくことをお勧めします。

(この記事は、Integrate GitHub monorepo with AWS CodePipeline to run project-specific CI/CD pipelines を翻訳したものです。) AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、可視化、自動化できる継続的デリバリーサービスです。AWS CodePipeline を使用して、コードを構築し、稼働前の環境にデプロイし、アプリケーションをテストし、実稼働環境にリリースするまでの完全なリリースプロセスをモデル化できます。AWS CodePipeline は、コードが変更されるたびに定義されるワークフローに従って、アプリケーションを構築、テスト、デプロイします。多くの組織が GitHub をソースコードリポジトリとして使用しています。組織によっては、1 つの GitHub リポジトリに複数のアプリケーションまたはサービスをフォルダで分割して格納することを選択しています。リポジトリ内のソースコードをこのように整理する方法は、モノレポと呼ばれます。 この記事では、AWS Lambda で GitHub イベントペイロード（訳者注：GitHub 上でのアクティビティを元にトリガーされるイベント情報。詳細は GitHub イベントのドキュメントをご確認ください。）を読み取り、サービス固有のパイプラインを実行するようにカスタマイズする方法を示します。

本投稿は Open source mobile core network implementation on Amazon Elastic Kubernetes Service を翻訳したものです。 アマゾンウェブサービス (AWS) のホワイトペーパー『 AWS でのキャリアグレードのモバイルパケットコアネットワーク 』および 『AWS を使用した 5G ネットワークの進化』で紹介されているように、AWS で 4G Evolved Packet Core(EPC) および 5G Core(5GC) を実装することで、スケーラビリティ、柔軟性、プログラム可能なオーケストレーション、基盤となるインフラストラクチャレイヤーの自動化などの大きな価値とメリットを得ることができます。 このブログ投稿では、オープンソースプロジェクト Open5gs を使用して 4G コアネットワークを構築するための実用的な実装ステップに焦点を当てます。