Amazon Web Services ブログ

Category: Best Practices

AWS IoT Eventsの探知器モデルのトラブルシューティング方法

AWS IoT Eventsは先日、新しいトラブルシューティング機能を発表しました。この機能では、探知器モデルを発行しなくても、潜在的な構文エラー、構造上の問題、およびランタイムエラーがないかどうか、探知器モデルを自動的に分析できます。この記事では、AWS IoT Eventsの探知器モデルでこの新機能を使用する方法をご紹介します。

Read More
VMware Cloud on AWS

オンプレミスからVMware Cloud on AWSへのネットワークL2延伸の選択肢

AWSでSpecialist Solution Architectを務めるSchneider Larbiによる記事です。 VMware Cloud on AWSではお客様のオンプレミスネットワークをレイヤー2レベルでシームレスにクラウドへ延伸することができます。これは重要なことです。なぜならオンプレミスのレイヤー2ネットワークからIPアドレスを変更せずに、仮想マシンをVMware Cloud on AWSへ移行できるからです。 本稿執筆時点(2020年7月7日)で、VMware Cloud on AWSへネットワーク延伸する方法は以下の2つがあります。 VMware Autonomous NSX Edge Appliance VMware Hybrid Cloud Extension (HCX) ネットワーク延伸を実装するにあたりオンプレミスにNSXを持つ必要はありません。オンプレミスにNSX-Tがある場合、NSXにより自動でプロビジョニングされるNSX-T Edgeを、Software Defined Data Center (SDDC)やVMware Cloud on AWSの環境に接続するためのL2VPN (レイヤー2 VPN)のクライアントサイドとして利用することはできません。 本稿では、オンプレミスのネットワークをVMware Cloud on AWSへ延伸する際のアーキテクチャの考慮事項について説明します。これによりハイブリッドクラウドを実装したり、IPアドレスを変更することなくクラウドへ移行することができるようになります。

Read More

AWS Control Tower アクションの追跡、およびワークフローの自動トリガーへのライフサイクルイベントの使用

現在、新規アカウントの作成やプロビジョニングに、AWS Control Towerをご利用になっているお客様が多く見受けられます。こういったお客様は、環境の作成に、AWS のネイティブなソリューションの使用をご希望されます。それが明文化された AWS のベストプラクティスに則っていることをご存知だからです。お客様は、作成したアカウントのスケーリングを行う際に、アカウントをさらに強化できる Control Tower の追加的な機能を利用することもできます。今回の記事では、ライフサイクルイベントの使用方法をご紹介していきます。これは、Control Tower’s Account Factory を使用して新しいアカウントを作成するなどのアクションが完了したことを追跡できるようにする、Control Tower における機能の 1 つです。今回は、このライフサイクルイベントで、自動化したワークフローをトリガーする方法についても、合わせてご紹介します。この記事では、次のようなサービスを使用しています。 AWS Control Tower AWS Service Catalog AWS CloudTrail Amazon CloudWatch Events Amazon SNS 背景 AWS Control Tower では、Well-Architected なマルチアカウントの AWS 環境構築のために、AWS Organizations、AWS IAM、AWS Config、AWS CloudTrail、および AWS Service Catalog などの AWS のサービスを複数使用します。これにより、組織単位 (OU) の中のアカウントでガードレールを有効化するなどのアクションを Control Tower が実行する際には、多くのプロセスが実行され、各サービスに対しては膨大な数の API 呼び出しが送られることになります。 […]

Read More

AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス

この記事では、AWS Cloud Development Kit (AWS CDK) を中心とした、大規模なチームで複雑なクラウドアプリケーションの開発を組織化するための戦略について説明します。AWS CDK では、開発者や管理者は、TypeScript、Python、Java、C#などの使い慣れたプログラミング言語を使ってクラウドアプリケーションを定義することができます。アプリケーションは、Stage、Stack、Constructに整理されており、ランタイムロジック (AWS Lambda コードやコンテナ化されたサービスなど) と、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Relational Database Service (Amazon RDS) データベース、ネットワークなどのインフラストラクチャコンポーネントの両方において、モジュール化された設計手法を可能にしています。 この記事では、AWS CDKの基本的なコンセプトに関する簡単なチュートリアルではなく、より実践的な内容について説明します。ローカルでコードを書きテストする方法や、本番環境や様々なステージングアカウントにデプロイする方法、そしてチームのアプリを整理して、より大きな組織で活用する方法について説明します。 AWS CDKを初めてご利用になる方は、AWS CDK Intro Workshop から始めることを強くお勧めします。この記事では、いくつかの高度なトピックを扱っていますが、基礎を把握しておくと良いでしょう。詳細については、AWS CDKリファレンスドキュメントとGitHub リポジトリにある aws-cdk-examples  のサンプルコードを参照してください。

Read More

新たに SaaS Journey Framework ホワイトペーパーを公開しました

AWS で SaaS Business Lead を務める Oded Rosenmann による記事です。 SaaS(Software as a Service)提供モデルは、多くの企業にとってますます魅力的になっています。 新規および既存のアプリケーション・プロバイダが、この提供モデルで成功を収めたいと望んでいる一方で、SaaS への移行はビジネスに大きな影響を与える可能性もあります。 多くの企業にとって、SaaS への移行は大きな変化をもたらす出来事であり、企業は自社のビジネスをあらゆる側面から検討する必要があります。サービスとしてのビジネスを定義、構築および運用するためには、製品の販売、マーケティング、開発、サポート、収益化の方法など、評価しなければいけない検討事項がたくさんあります。

Read More

AWS SaaS Boost を利用したモノリスアプリケーションの SaaS 移行

AWS SaaS Factory で Principal Partner Solutions Architect を務める Tod Golding による記事です。 SaaS (Software-as-a-Service) モデルへの移行は多くの企業にとって魅力的ですが、新しいマルチテナントアーキテクチャへの移行に必要な時間、労力、投資は大きな障壁となる場合があります。 多くの企業にとって、SaaS への移行には、新しいテクノロジーの習得、マルチテナント構造の実装、新しい運用ツールの作成、新しい課金体型の採用、といった作業を伴います。 こういった障壁は、SaaS への移行がビジネスを成長させ将来の成功の鍵になると考えている企業にとって、特に深刻な問題になる可能性があります。そのような企業の多くは、わざわざアプリケーションの再構築やコードの書き換えを行うことなく、そして時間やコストも奪われることなく、SaaS への移行を加速する方法を模索しています。 そういったニーズに対応するために、アマゾンウェブサービス (AWS) では、AWS SaaS Boost をリリースしました。

Read More

【開催報告&全資料まとめ&QA公開】Amplify Meetup #02

新年明けましておめでとうございます!アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉(@kimyan_udon2)です。私は年始早々、厳かな気持ちでこのブログを書き始めたのですが、気づけば2月に突入しておりました。皆様いかがお過ごしでしょうか? 年をまたいで2020年11月27日に「Amplify Meetup #02」を開催しました。「Amplify Meetup」はAWS AmplifyのユーザーとAWS Amplifyに興味のあるエンジニアのみなさんでLTなどを通して盛り上がるコミュニティーイベントです。タイトルに「#02」とありますように、今回は第2回目の開催となります。第1回目の盛り上がりも開催報告ブログにまとまっております。継続して開催できたのは、ひとえにご参加いただいた皆様のおかげです。皆様ありがとうございます!

Read More

AWS Fargate for Amazon ECS のアップデート

先日、AWS Fargate for Amazon ECS 経由でデプロイされたタスクの設定とメトリクスの収集体験を向上させる機能を発表しました。お客様からのフィードバックに基づき、以下の機能を追加しました。 環境ファイルのサポート シークレットバージョンと JSON キーを使用した、AWS Secrets Manager とのより深い統合 より詳細なネットワークメトリクスと、タスクメタデータエンドポイントを介して利用可能な追加データ この記事を通して、これらのアップデートについて深く掘り下げ、Amazon ECS for AWS Fargate にコンテナをデプロイすると、どこに価値をもたらすことができるかを説明します。まず、簡単なデモアプリケーションのデプロイから始めて、これらの各機能を説明します。

Read More

Amazon API Gateway で API キーを使わずに認証とアクセス制御を行う

はじめに Amazon API Gateway の API キーの利用を検討したものの、API キーの制約によってプロダクトの要件を満たせないことがあります。その際、それぞれ Amazon Cognito を利用した認証と AWS WAF を用いた IP ベースのレート制限を利用するという代替案をご紹介いたします。 背景 筆者は普段、プロトタイピングソリューションアーキテクトとして、お客様のプロダクトのプロトタイプ作りをお手伝いさせていただいております。お客様の中には、ユーザー認証やアクセス制御として Amazon API Gateway の API キーの利用を検討している場合があります。しかし、API キーでお客様の要件を満たせるかどうかは、慎重に検討が必要です。 API キーには数の上限があります。Amazon API Gateway のクォータと重要な注意点 にも記載がある通り、1 アカウント、1 リージョンあたりの API キー数の上限は 500 です。そのため、多くのユーザーを抱える API では API キーによる認証は適さないと言えます。 API キーのセキュリティについても検討が必要です。API キーは有効期限が設定できないので、有効期限を設定可能な認証方法に比べ、漏洩した際のリスクが大きいです。 このように、 API キーは容易に利用が可能な反面、いくつかの考慮事項があるため、選定は慎重に行う必要があります。次の考察で、認証とアクセス制限について、それぞれ代替案をご紹介したいと思います。 考察 では、ユースケース別に代替案をご紹介いたします。 一つ目は、認証として API キーを利用したいケースです。それぞれのユーザーに対し、ユニークな API キーを割り当てることを想定しています。この場合、背景にて説明した API […]

Read More

セキュリティの実践とベストプラクティス -日本銀行様『クラウドサービス利用におけるリスク管理上の留意点』によせて-

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第五弾です。
多くのお客様は、より安全にサービスを提供するために多様なセキュリティを組み込み、また規制要件を満たしていくことで組織としての説明責任を果たそうとしています。
日本銀行様では、多くの金融機関のお客様がよりクラウドを活用したイノベーションをおこし、サービスを向上するために『金融システムレポート別冊』として「クラウドサービス利用におけるリスク管理上の留意点」(以下、本別冊とします)を発表しました。本Blogでは本別冊に基づき、組織がセキュリティを実践するために必要な考え方のいくつかを示してみたいと思います。

Read More