Category: Advanced (300)

アマゾンの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 コアネットワークを構築するための実用的な実装ステップに焦点を当てます。

この記事は How to use AWS Secrets & Configuration Provider with your Kubernetes Secrets Store CSI driver を翻訳したものです。 AWS Secrets Manager を使用して、Amazon Elastic Kubernetes Service (Amazon EKS) の Kubernetes Pod で使用するために、AWS Secrets Manager からシークレットを安全に取得できるようになりました。AWS Secrets and Config Provider (ASCP) の登場により、Amazon EKS 上で動作するアプリケーションにシークレットを提供するために使用される業界標準の Kubernetes Secrets Store と Container Storage Interface (CSI) ドライバー の、使いやすいプラグインが利用できます。ASCP を使用して、ファイルシステムや etcd を介してシークレットをフェッチする従来の Kubernetes […]

Sanjay Garje と Vebhhav (Veb) Singh の共著あらゆる規模の企業が AWS クラウドに移行しています。エンタープライズチームのリーダーシップから、コストを抑えながら Amazon SageMaker に簡単にアクセスできる方法を模索しているという話を耳にします。これにより、データサイエンスを使った実験を促進し、新しいビジネスチャンスを開拓して現状を打破しています。このブログ記事では、Amazon SageMaker、AWS Service Catalog、および AWS Key Management Service (KMS) を使用してセルフサービスの安全なデータサイエンスを簡単に使えるようにする方法を紹介します。 このブログ記事では、AWS Service Catalog が事前設定された AWS KMS キーを使用して、複雑で不要な詳細をデータサイエンティストに公開することなく、ノートブックインスタンスにアタッチされている機械学習 (ML) ストレージボリュームで保存されているデータを暗号化する方法を説明します。ML ストレージボリュームの暗号化は、一元化されたセキュリティチームやインフラストラクチャチームが事前設定および調整した AWS Service Catalog 製品で行われます。Amazon SageMaker ノートブックインスタンス、トレーニングジョブ、またはエンドポイントを作成するときに、AWS KMS キー ID を指定できます。そのキーが、アタッチされた ML ストレージボリュームを暗号化します。トレーニングジョブ用の出力 Amazon S3 バケットを指定できます。トレーニングジョブも、AWS KMS で管理されるキーで暗号化されます。モデルのアーティファクトをその出力 Amazon S3 バケットに格納するための KMS キー ID を渡すことができます。 […]

お客様は、新しいビジネスユニットのオンボーディングやアプリケーションワークロードのセットアップを行うたびに、AWS Control Tower で新しいアカウントをプロビジョニングしています。場合によっては、組織はクラウドユーザー、開発者、およびデータサイエンティストに、新しいアカウントでセルフサービス標準化された安全なパターンとアーキテクチャをデプロイすることも求めます。以下にいくつか例を示します。 開発者またはクラウドエンジニアが、golden AMI から Amazon EC2 インスタンスを起動したいと考えています。 データサイエンティストは、承認済みの AMI とインスタンスタイプで Amazon EMR クラスターを起動したいと考えています。 データベース管理者は、新しくプロビジョニングされた AWS アカウントで承認済みの Amazon RDS データベースを起動する必要があります。 この記事では、AWS Control Tower の Account Factory を使用して新しい AWS アカウントをプロビジョニングする方法を示します。また、AWS Service Catalog を使用して、RDS データベースのポートフォリオなどのカスタム製品を新しいアカウントと共有する方法も示します。さらに、AWS Control Tower のガードレールを使用して新しいアカウントでガバナンスを実施する方法についても説明します。 このソリューションで使われる AWS のサービスは、以下のとおりです。 AWS Control Tower AWS Service Catalog AWS CloudFormation Amazon CloudWatch Amazon RDS AWS Organizations […]

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (Dev) 、品質保証 (QA) 、そして実稼働 (Prod) といった開発ライフサイクル (SDLC) の各フェーズに合わせ、環境全体で完全な分離を実現するために、個別の AWS アカウントを作成する手法を選択しています。しかしながら、アカウント作成時点でアプリケーションからの要件が完全に理解できていない場合、必要なインフラストラクチャコンポーネントをプロビジョニングすることが困難になり得ます。加えて、作成されたアカウントが増えるに従い、それらの異なるカウント間でのインフラストラクチャのコンプライアンスと一貫性を実現するための手法を模索しなければなりません。 AWS Service Catalog は、こういった課題に対処するため役立ちます。これにより開発者は、どのような環境においても、インフラストラクチャコンポーネントを、素早く、安全かつ簡単にデプロイできるようになります。次の図は、このワークフローを示しています。ここでは、アプリケーションにおける Dev/QA/Prod 用の各アカウントが、実稼働および非実稼働向けのインフラストラクチャコンポーネントを共有するために、AWS Service Catalog が使用されています。 お客様の多くに、AWS Service Catalog を使用するメリットは「一枚のガラス」を通すようにインフラストラクチャがプロビジョニングできることである、と捉えていただいていますが、実はこれには、製品のデプロイを自動化する機能も備わっています。前出の図にあるワークフローでは、アプリケーションのアカウントで共有している各製品は、それぞれの継続的統合/継続的デリバリー (CI/CD) パイプラインから、直接デプロイすることが可能です。これにより、コードおよびインフラストラクチャの依存関係と、各チームに分散した個別コンポーネントの所有権とを、開発者が固く結びつけることができる環境が提供されます。 このモデルからは、次のように 2 つの主要なメリットが得られます。 中心チームは、承認されたインフラストラクチャのバージョンを定義することで、コンプライアンスと標準化を実施できるようになります。 アプリケーション所有者が、使用すべきインフラストラクチャコンポーネントを自身で選択できる、セルフサービス型の環境が提供されます。 次の図で、このプロセスをさらに詳細に説明しています。ここでは、インフラストラクチャの定義は Shared Services チームにより処理されます。このチームにより、アプリケーションアカウントとの間で共有する、ネットワークやコンピューティングベースのリソースに関するカタログが作成されます。アプリケーションの所有者には、各要件に最も適合するコンポーネントを決定する役割があり、各所有者は複数のバージョンをが共有できます。これらの製品は、アプリケーションの CI/CD プロセスの一環として、AWS CodePipeline などの AWS のサービスを使用してデプロイされます。この、インフラストラクチャのデプロイ手法には、セキュリティ上のメリットもあります。アプリケーションパイプラインのアクセス権限は、基盤となっている AWS のサービスではなく、最小権限を保証しながら AWS Service Catalog ポートフォリオに対し適用されるからです。 AWS Service Catalog アカウントポートフォリオの共有を活用する CI/CD パイプラインの自動構築は、次の GitHub レポジトリから Amazon […]

AWS Key Management Service (AWS KMS) が AWS KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) 1.2 暗号化プロトコルにおいて新しいハイブリッド型のポスト量子暗号（耐量子暗号）鍵交換アルゴリズムをサポートするようになりました。これらの新しいハイブリッドポスト量子アルゴリズムは、古典的な鍵交換による実証済みのセキュリティと、標準化作業で評価中の新しいポスト量子鍵交換の潜在的な耐量子安全特性を組み合わせたものです。これらのアルゴリズムの中で最も高速なものは、古典的な TLS ハンドシェイクと比較して約 0.3 ミリ秒のオーバーヘッドがあります。追加された新しいポスト量子暗号鍵交換アルゴリズムは、Kyber のラウンド 2 バージョン、Bit Flipping Key Encapsulation（BIKE）、および Supersingular Isogeny Key Encapsulation（SIKE）です。標準化に参加している各組織は、米国国立標準技術研究所（NIST） のポスト量子暗号の標準化プロセスの一環として、アルゴリズムを NIST に提出しています。このプロセスは、複数年にわたる数ラウンドの評価にまたがり、2021 年以降も続く可能性があります。 以前のハイブリッド量子暗号 TLS に関するブログ投稿で、AWS KMS がラウンド 1 バージョンの BIKE と SIKE を備えたハイブリッドポスト量子暗号 TLS 1.2 をリリースしたことを発表しました。ラウンド 1 のポスト量子暗号 アルゴリズムは引き続き AWS KMS でサポートされていますが、ラウンド […]