11 月 18 日週、 ブラジル で 2024 年最後のラテンアメリカ Amazon Web Services (AWS) Community Day が開催されました。また、これに並行して複数のイベントも開催されました。ゴイアニアでは、Senior Developer Advocate の Marcelo Palladino と AWS コミュニティビルダーの Marcelo Paiva 氏が基調講演を行いました。フロリアノポリスでは Senior Developer Advocate の Ana Cunha が出演しました。 チリのサンティアゴ では私も AWS コンテナヒーローの Rossana Suarez 氏とともに基調講演を行うことができて光栄でした。これらのイベントは、コミュニティによってコミュニティのために開催されるもので、ネットワークを築き、何か新しいことを学び、コミュニティに没頭する機会を提供します。コミュニティでは、誰もが共に成長し、取り残される人は 1 人もいません。 AWS Lambda は 10 周年を迎えました 。AWS Lambda は、私が AWS と出会うきっかけとなったサービスで、今でも私のお気に入りです。顧客のニーズから生まれ、サーバー管理なしでコードを実行できるようにすることで、クラウドコンピューティングに革命をもたらしました。誕生以来、Amazon.com の Chief Technology Officer である Dr. Werner Vogels のこの LinkedIn 投稿 にて、オリジナルの PR/FAQ 文書を通じて進捗が記録されています。このサービスは飛躍的に成長し、1 ミリ秒の請求精度や 10GB メモリのサポートなどの機能が導入されました。ありがとう、 AWS Lambda 。今後もたくさんの記念日を迎えられますように。 Amazon は、Trainium チップを使用する大学での AI 研究を支援するために 1 億 1,000 万 USD を投資しています。 このイニシアチブでは、AWS Trainium チップを使用するコンピューティングリソースを提供し、研究者が新しい AI アーキテクチャと機械学習のイノベーションを開発できるよう支援します。これらの開発内容は、より広範な進歩に向けてオープンソース化される予定です。AWS の CEO である Matt Garman による Linkedin の投稿 をご覧ください。 11 月11 日週のリリース re:Invent 2024 での AWS BuilderCards 第 2 エディション – re:Invent 2024 で、 Jeff Barr は AWS BuilderCards 第 2 エディションの発売を発表しました。デザインとゲームの仕組みの改善に加えて、生成 AI の新しいアドオンパックが含まれています。これまでのイベントでは 15,000 セット以上が配布され、ユーザーからの素晴らしいフィードバックも寄せられています。re:Invent 以降はオンラインで購入できるようになります。 Amazon EventBridge がイベントバスのエンドツーエンドのレイテンシーを最大 94% 改善したことを発表 – Amazon EventBridge はイベントバスのエンドツーエンドのレイテンシーを最大 94% 改善し、平均レイテンシーを 2,235.23 ミリ秒 (2023 年 1 月に測定) から 129.33 ミリ秒 (2024 年 8 月に P99 で測定) に短縮しました。この機能強化により、Amazon EventBridge が利用可能なすべての AWS リージョン (AWS GovCloud (米国) リージョンを含む) で、不正検知、産業オートメーション、ゲームなどの速度が重要視されるアプリケーションの処理を、追加料金なしで高速化できるようになります。 AWS Organizations の新しいタイプの認可ポリシーであるリソースコントロールポリシー (RCP) のご紹介 – リソースコントロールポリシー (RCP) は、 AWS Organizations の新しい認可ポリシーです。RCP を使用すると、プリンシパルの権限を制御するサービスコントロールポリシー (SCP) を補完して、リソースに付与される最大のアクセス許可を一元的に制御できます。RCP では、 Amazon Simple Storage Service (Amazon S3) バケット などのリソースへの外部アクセスを制限して、組織全体にデータ境界を適用することが可能です。 Amazon Data Firehose を使用して、データベースから Apache Iceberg テーブルに変更をレプリケート (プレビュー) – データベースの変更をキャプチャして Amazon S3 の Apache Iceberg テーブルにレプリケートする、 Amazon Data Firehose の新しいプレビュー機能です。この機能は PostgreSQL および MySQL データベースをサポートし、パフォーマンスに影響を与えることなくデータベースの更新をストリーミングするシンプルなソリューションを提供します。データの分割とスキーマの進化を自動的に処理するため、複雑な ETL プロセスが不要になります。 Amazon S3 が AWS アカウントあたり最大 100 万バケットのサポートを開始 – Amazon S3 は、デフォルトのバケットクォータを AWS アカウントあたり 100 から 10,000 に増やしました。お客様は最大 100 万バケットまでの増加をリクエストできるようになりました。最初の 2,000 バケットは無料で、それ以降は追加のバケットに少額の月額料金がかかります。 Amazon Keyspaces (Apache Cassandra 向け) が価格を最大 75% 引き下げ – Amazon Keyspaces (Apache Cassandra 向け) は最大 75% の大幅な値下げを発表しました。このサービスにより、オンデマンドモードの料金が、単一リージョンの場合は最大 56%、マルチリージョンの場合は最大 65% 引き下げられます。有効期限 (TTL) の削除料金も 75% 削減されました。 AWS Organizations を使用するお客様のためのルートアクセスの一元管理 – AWS Identity and Access Management (IAM) は、 AWS Organizations のルートアクセスを一元管理する新機能をリリースしました。この機能により、セキュリティチームはメンバーアカウントから長期的なルート認証情報を削除し、特定のアクションでタスクを対象とする一時的なルートセッションを使用できるようになります。このソリューションは、必要な特権操作を実行する機能を維持しながら永続的なルート認証情報を削除することで、セキュリティを強化します。 Amazon DynamoDB がオンデマンドスループットとグローバルテーブルの料金を値下げ – Amazon DynamoDB は、 オンデマンドモード のスループットコストを 50%、グローバルテーブルを最大 67% 削減するという大幅な値下げを発表しました。マルチリージョンのレプリケートされた書き込みが単一リージョンの料金と一致するようになりました。これらの変更により、ほとんどの DynamoDB ワークロードではオンデマンドモードが推奨されるようになります。 Datadog と Wiz 用の Amazon Q Developer プラグインの一般提供を開始 – Amazon Q Developer は、 Datadog と Wiz サービス用のプラグインの提供を開始し、ユーザーは AWS コンソール から直接これらのパートナー機能にアクセスできるようになりました。ユーザーは @datadog や @wiz などの自然言語コマンドを使用して情報をクエリし、リアルタイムの最新情報やセキュリティに関するインサイトを得ることができます。 その他の AWS ブログ記事 その他の興味深いプロジェクトとブログ記事をいくつかご紹介します。 Amazon SageMaker JumpStart の Stable Diffusion 3.5 Large のご紹介 – このパワフルな 81 億個のパラメータモデルにより、テキストプロンプトから写真のようにリアルで高品質な画像を生成できるようになりました。お客様はモデルを Amazon SageMaker JumpStart にシームレスにデプロイして使用し、Amazon SageMaker のセキュリティおよび機械学習オペレーション (MLOps) 機能の利点を活用することができます。 AWS AI と生成 AI サービスを使用した、ブラウザでのライブストリームの文字起こし、翻訳、要約 – このブログ記事では、AI サービスを使用してライブストリーミング体験を強化する Chrome 拡張機能を開発した経緯をご紹介します。この拡張機能は、 Amazon Transcribe 、 Amazon Translate 、 Amazon Bedrock を使用して、ライブストリームのリアルタイムの文字起こし、翻訳、要約をブラウザで直接提供します。文字起こしでは 50 言語以上、翻訳では 75 言語以上をサポートしているため、世界中からコンテンツにアクセスできるようになります。 Amazon Bedrock とベクトルデータベースによる自動車の損傷処理の簡素化 – このブログ記事では、 Amazon Bedrock とベクトルデータベースを組み合わせて自動車の損傷評価を合理化するソリューションをご紹介します。このシステムは、AI を使用して車両の損傷画像を分析し、費用を見積もり、既存のデータセットの類似事例と照合します。 Anthropic の Claude 3 と Amazon Titan Multimodal Embeddings を使用して、効率的で正確な処理を実現します。 Amazon Bedrock と Amazon Location Service で旅行計画に革命を – Amazon Bedrock と Amazon OpenSearch Service のベクトルデータベースを組み合わせ、AI を使用して画像を分析し、履歴データと照合して正確な修理見積もりを行うことで、自動車の損傷評価を自動化します。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Community Day  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。今後予定されている AWS Community Day は、 インドネシア (11 月 23 日) と、 インド、コーチ (12 月 14 日) です。 AWS re:Invent 2024 – ラスベガスで私たちと一緒に AWS のすべてを学びましょう。1 年に 1 度のカンファレンスは、スキルを伸ばすための最良かつ最速の方法です。直接参加できない場合は、オンラインで Watch re:Invent に登録して、バーチャルでご参加いただけます。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 AWS ビルダー ID を作成 し、エイリアスをご予約ください。ビルダー ID はユニバーサルログイン認証情報で、ユーザーは AWS マネジメントコンソールだけでなく、600 以上の無料トレーニングコース、コミュニティ機能、Amazon Q Developer をはじめとするデベロッパーツールなどの AWS ツールやリソースにアクセスできます。 11 月 18 日週のニュースは以上です。11 月 25 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! チリの AWS コミュニティの写真を提供してくれた Odina Jacobs に感謝します。 – Eli この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

この記事は、 AWS Payment Cryptography is PCI PIN and P2PE certified を翻訳したものです。 Amazon Web Services (AWS) は、 AWS Payment Cryptography (*1) がPayment Card Industry PIN Security Requirements Version 3.1 および PCI Point-to-Point Encryption (P2PE) Version 3.1 Decryption Componentに準拠したことを発表します。 Payment Cryptography を使用することで、PCI PIN Transaction Security (PTS) HSM認定を受け、AWSによって完全に管理されているPCI PIN / P2PEに準拠した鍵管理を備えたペイメントハードウェアセキュリティモジュール (HSM) を、決済業務アプリケーションで使用できます。これらの準拠により、コンプライアンス準拠のオーバーヘッドを削減しながら、準拠対象のワークロードを柔軟に展開することができます。 PCI P2PE Decryption Componentは、PCI P2PEソリューションが、AWSを使用して決済端末からのクレジットカードトランザクションを復号化することを可能にし、PCI PIN認証はPINベースのトランザクションを処理するアプリケーションでの利用に必要です。PCI SSCによると、「PCI P2PE ソリューションを使用することで、加盟店は決済業務で PCI DSS が適用される場所や方法を減らすことができ、PCI DSS への準拠を簡素化しながら顧客データのセキュリティを高めることができる」とあります。 サードパーティのQualified PIN Assessor (QPA) およびQualified Security Assessor (QSA) であるCoalfireが、Payment Cryptographyを評価しました。顧客は、 AWS Artifact を通じてPCI PIN Attestation of Compliance (AOC) レポート、PCI PIN Shared Responsibility Summary、PCI P2PE Attestation of Validationにアクセスできます。 AWSのPCIプログラムやその他のコンプライアンス、セキュリティプログラムの詳細については、 AWSコンプライアンスプログラム のページをご覧ください。AWSコンプライアンスチームへのお問い合わせは、 お問い合わせページ からお願いいたします。 この投稿に関するフィードバックがある場合は、以下のコメント欄にコメントをお寄せください。この投稿に関するご質問は、 AWS サポート までお問い合わせください。 (*1) AWS Payment Cryptographyに関しての AWSブログ もご参照ください。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

この記事は Improving deployment visibility for Amazon ECS services (記事公開日 : 2024 年 11 月 7 日) の翻訳です。 ソフトウェアをデプロイする際、デプロイメントプロセスのすべてのステップを可視化することは非常に重要です。安全で信頼性の高いリリースプロセスを実現するためには、進行中のデプロイメントの状況を把握し、問題が発生した際にはトラブルシューティングを行い、過去のデプロイメントの監査証跡を保持しておく必要があります。これらのニーズに対応するために、 Amazon Elastic Container Service (Amazon ECS) は、強化された可視性とトレーサビリティの機能を提供開始しました。新しく導入されたサービスデプロイメント (サービスデプロイ) とサービスリビジョンを活用することで、Amazon ECS におけるアプリケーションデプロイメントについて、より深い洞察を得ることができます。 Amazon ECS において、 ECS サービス は長時間実行されるアプリケーションを管理するリソースであり、同一の ECSタスクのグループが Amazon ECS によってデプロイ、管理、スケーリングされます。新しいバージョンのソフトウェアをリリースする際は、Amazon ECS がデプロイメントプロセスを管理し、古いタスクを新しいタスクに 段階的に置き換えます 。Amazon ECS では、安全なソフトウェアリリースを実現するためのビルトインの保護機能を提供しており、例えば ECS deployment circuit breaker を用いると、新しいデプロイメントが失敗した際に、自動的に前のバージョンのサービスにロールバックさせることが可能です。今回のリリースでは、Amazon ECS の 2 つの新しいリソース (サービスリビジョン、サービスデプロイメント) と新しい API ( listServiceDeployments 、 describeServiceRevisions 、 describeServiceDeployments ) が導入され、デプロイメントプロセスの可視性が向上しました。 まず、サービスリビジョンは、Amazon ECS がデプロイするワークロードの設定を記録します。これには、タスク定義、コンテナイメージ、サービスレベルのパラメーター ( Amazon Elastic Block Store (Amazon EBS) ボリュームやロードバランサー、 ECS Service Connect の設定など) が含まれます。 また、サービスデプロイメント (サービスデプロイ) は、進行中または以前のサービスリビジョンのデプロイメントに関する包括的な視点を提供します。ここでは、デプロイメントの開始点 (ソースリビジョン)、どのデプロイメントがロールアウトされているのか (ターゲットリビジョン)、設定したサーキットブレイカーや Amazon CloudWatch アラーム を含むデプロイメントの状況を確認することができます。 これまで、Amazon ECS のデプロイメントの履歴を追跡することは困難でした。今回のリリースにより、成功したかどうかに関わらず、各サービスデプロイメントは 90 日間保持され、Amazon ECS コンソールまたは listServiceDeployments API を通じて確認できるようになりました。これにより、Amazon ECS サービスのデプロイメントの履歴を確認し、各ロールアウトでどのサービスリビジョンが使用されたかを把握することができます。 Amazon ECS は、これらの強化された可視性とトレーサビリティの機能を提供することで、アプリケーションデプロイメントに関するより優れた監視、トラブルシューティング、管理を可能にし、より信頼性と透明性の高いリリースプロセスを実現します。以下の図は、既存の Amazon ECS リソースと、新しく導入されたサービスデプロイメントおよびサービスリビジョンの関係を示します。 図 1 : サービスリビジョンとサービスデプロイメントの関係 ソリューション概要 このセクションでは、Amazon ECS にソフトウェアをデプロイする際に、サービスリビジョンとサービスデプロイメントがどのように可視性を向上させるのか、ハンズオン形式で説明していきます。この例では、まず新しいサービスを作成し、安定するまで待ちます。次に、既知のバグを含むリビジョンを作成し、エラーのトラブルシューティングやサーキットブレイカーの状態の管理において、新しく導入されたサービスデプロイメント API と Amazon ECS コンソールの「デプロイ」タブがどのように役立つかを確認していきます。 前提条件 このウォークスルーを完了するには、以下の前提条件が必要です。 Amazon ECS リソースを作成するための適切な権限を持った AWS CLI (新しく導入された API を利用するため、必要に応じて AWS CLI のバージョンを更新してください。) 既存の ECS クラスター 既存の ECS タスク実行ロール 既存の VPC サブネット と セキュリティグループ (このセキュリティグループには、インバウンドルールは不要です。) ウォークスルー 1. まず、このウォークスルー全体で使用する環境変数を設定 (export) します。これらのリソースが自身の AWS アカウントに存在することを確認し、自身のリソースの値に置き換えてください。 export AWS_REGION=ap-northeast-1 export ECS_EXECUTION_ROLE="arn:aws:iam::111222333444:role/ecsTaskExecutionRole" export ECS_CLUSTER="your-cluster-name" export VPC_SUBNET_ONE="subnet-07bd4d10ea848a008" export VPC_SUBNET_TWO="subnet-0ebc3139ba5dcf871" export VPC_SECURITY_GROUP="sg-003bf5ba3cb1a1168" 2. 無限にスリープする単一のコンテナで構成された、新しい ECS タスク定義を登録します。 cat <<EOF >>taskdefinition_one.json { "family": "deployment-demo", "executionRoleArn": "${ECS_EXECUTION_ROLE}", "networkMode": "awsvpc", "containerDefinitions": [ { "name": "demo", "image": "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal", "command": [ "/bin/bash", "-c", "echo 'sleeping' && sleep infinity" ] } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "memory": "512" } EOF aws ecs register-task-definition \ --cli-input-json file://taskdefinition_one.json 3. タスク定義を登録したら、既存の VPC サブネットとセキュリティグループを使用して、 AWS Fargate 上で実行するように設定した ECS サービスを作成します。 cat <<EOF >>service.json { "cluster": "${ECS_CLUSTER}", "serviceName": "deployment-demo", "taskDefinition": "deployment-demo", "desiredCount": 1, "launchType": "FARGATE", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true } }, "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "${VPC_SUBNET_ONE}", "${VPC_SUBNET_TWO}" ], "securityGroups": [ "${VPC_SECURITY_GROUP}" ], "assignPublicIp": "ENABLED" } } } EOF aws ecs create-service \ --cli-input-json file://service.json 4. 新しく導入された listServiceDeployments API を使用すると、作成したサービスに関連するサービスデプロイメントの一覧を確認することができます。(訳註 : もしエラーが出た場合は、AWS CLI のバージョンが十分新しいか、確認してください。) aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" このサービスは作成されたばかりなので、サービスデプロイメントは 1 つのみです。このサービスデプロイメントでは、ステータスが IN_PROGRESS (進行中) であり、ターゲットサービスリビジョンは 1544415738210471021 であることを確認できます。(これらの値はあくまで例で、実行する環境によって異なります。) { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", "serviceArn": "arn:aws:ecs:ap-northeast-1:111222333444:service/default/deployment-demo", "clusterArn": "arn:aws:ecs:ap-northeast-1:111222333444:cluster/default", "startedAt": "2024-11-20T10:46:40.661000+09:00", "createdAt": "2024-11-20T10:46:36.612000+09:00", "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "status": "IN_PROGRESS" } ] } サービスデプロイメントの一覧は、Amazon ECS コンソールの「デプロイ」タブでも確認できます。 5. 新しく導入された describeServiceDeployments API を使用すると、特定のサービスデプロイメントに関して、そのリビジョンの希望タスク数やサーキットブレイカーの状況などの詳細情報を確認できます。 DEPLOYMENT_ARN=$(aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query "serviceDeployments[0].serviceDeploymentArn" \ --output text) aws ecs describe-service-deployments \ --service-deployment-arns $DEPLOYMENT_ARN ここで、出力の sourceServiceRevisions キーが空になっていることを確認できます。これは、このデプロイメントが、このサービスの最初のデプロイメントであることを示しています。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", ... "sourceServiceRevisions": [], "targetServiceRevision": { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "requestedTaskCount": 1, "runningTaskCount": 1, "pendingTaskCount": 0 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true }, "maximumPercent": 200, "minimumHealthyPercent": 100 }, "deploymentCircuitBreaker": { "status": "MONITORING", "failureCount": 0, "threshold": 3 }, "alarms": { "status": "DISABLED" } } ], "failures": [] } サービスデプロイメントは、コンソール画面からも確認できます。 6. describeServiceRevisions API を使用すると、デプロイされているリソース (サービスリビジョン) に関するより詳細な情報を確認できます。 REVISION_ARN=$(aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query serviceDeployments[0].targetServiceRevisionArn \ --output text) aws ecs describe-service-revisions \ --service-revision-arns $REVISION_ARN この情報は、タスク定義リビジョンとサービスレベルのパラメーターで構成されています。 { "serviceRevisions": [ { "serviceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "serviceArn": "arn:aws:ecs:ap-northeast-1:111222333444:service/default/deployment-demo", "clusterArn": "arn:aws:ecs:ap-northeast-1:111222333444:cluster/default", "taskDefinition": "arn:aws:ecs:ap-northeast-1:111222333444:task-definition/deployment-demo:3", "launchType": "FARGATE", "platformVersion": "1.4.0", "platformFamily": "Linux", "networkConfiguration": {...}, "containerImages": [ { "containerName": "demo", "imageDigest": "sha256:96bbe031e236f8e767a358f6ba2e05a378508ae6227a814848a1c8a7833b5850", "image": "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal" } ], "guardDutyEnabled": false, "createdAt": "2024-11-20T10:46:26.169000+09:00" } ], "failures": [] } 7. 次のステップに進む前に、デプロイメントが SUCCESSFUL になるのを待ちます。これには数分かかる可能性があります。以下のコマンドを実行して、デプロイメントの状態を確認してください。 aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query "serviceDeployments[0].status" \ --output text 8. 次に、不正な設定 (bash で exit 1 コマンドを実行) を含む新しいサービスリビジョンをロールアウトします。そのために、まず 2 つ目のタスク定義を登録します。 cat <<EOF >>taskdefinition_two.json { "family": "deployment-demo", "executionRoleArn": "${ECS_EXECUTION_ROLE}", "networkMode": "awsvpc", "containerDefinitions": [ { "name": "demo", "image": "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal", "command": [ "/bin/bash", "-c", "echo 'sleeping' && sleep 15 && echo 'exiting' && exit 1" ] } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "memory": "512" } EOF aws ecs register-task-definition \ --cli-input-json file://taskdefinition_two.json update-service コマンドを実行し、新しいサービスリビジョンを作成してデプロイメントを開始します。 cat <<EOF >>updateservice.json { "cluster": "${ECS_CLUSTER}", "service": "deployment-demo", "desiredCount": 1, "taskDefinition": "deployment-demo" } EOF aws ecs update-service \ --cli-input-json file://updateservice.json 9. listServiceDeployments API を使用して、再度このサービスに関連するサービスデプロイメントの一覧を確認しましょう。 aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" このサービスには、現在 2 つのデプロイメントが存在していることを確認できます。1 つは最初に完了したデプロイメント、もう 1 つは新しく開始した IN_PROGRESS (進行中) のデプロイメントです。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "status": "IN_PROGRESS" }, { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "status": "SUCCESSFUL" } ] } この一覧は、ECS コンソール「デプロイ」タブの「サービスデプロイ」からも確認できます。 10. 新しいサービスデプロイメントの詳細を確認すると、2 つの異なるサービスリビジョン間で ECS サービスを遷移させていることを確認できます。 DEPLOYMENT_ARN=$(aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query "serviceDeployments[0].serviceDeploymentArn" \ --output text) aws ecs describe-service-deployments \ --service-deployment-arns $DEPLOYMENT_ARN この例では、ソースリビジョンの ID は 1544415738210471021 で、ターゲットリビジョンの ID は 7111358678511081979 となっています。また、ロールアウトが進行中のため、サーキットブレイカーが MONITORING (監視中) の状態であることが分かります。さらに、このデプロイメントにおいて失敗したタスクの数 (failureCount) と、ロールバックをトリガーするためのしきい値 (threshold) を確認できます。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "sourceServiceRevisions": [ { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "requestedTaskCount": 0, "runningTaskCount": 1, "pendingTaskCount": 0 } ], "targetServiceRevision": { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "requestedTaskCount": 1, "runningTaskCount": 0, "pendingTaskCount": 1 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true }, "maximumPercent": 200, "minimumHealthyPercent": 100 }, "deploymentCircuitBreaker": { "status": "MONITORING", "failureCount": 2, "threshold": 3 }, "alarms": { "status": "DISABLED" } } ], "failures": [] } Amazon ECS コンソールの「デプロイ」タブでは、サービスリビジョンを比較するための画面が新しく導入されています。ここでは、異なるサービスリビジョン間の違いを視覚的に確認することができます。 11. 再度  describeServiceDeployments API を使用して、このデプロイメントの詳細を確認しましょう。 aws ecs describe-service-deployments \ --service-deployment-arns $DEPLOYMENT_ARN 時間の経過とともに、タスクが失敗し、 deploymentCircuitBreaker キーの下の failureCount が増加していきます。最終的に、サーキットブレイカーが TRIGGERED になり、ECS サービスは以前のサービスリビジョンにロールバックされます。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "sourceServiceRevisions": [ { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "requestedTaskCount": 1, "runningTaskCount": 1, "pendingTaskCount": 0 } ], "targetServiceRevision": { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "status": "ROLLBACK_SUCCESSFUL", "statusReason": "Service deployment rolled back because the circuit breaker threshold was exceeded.", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true }, "maximumPercent": 200, "minimumHealthyPercent": 100 }, "rollback": { "reason": "Service deployment rolled back because the circuit breaker threshold was exceeded.", "startedAt": "2024-11-20T10:57:06.840000+09:00", "serviceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021" }, "deploymentCircuitBreaker": { "status": "TRIGGERED", "failureCount": 3, "threshold": 3 }, "alarms": { "status": "DISABLED" } } ], "failures": [] } 12. 最後に、 listServiceDeployments API を使用して、すべてのサービスデプロイメントを確認しましょう。 aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" 最初のデプロイメントと失敗したデプロイメントの両方が表示されていることを確認できます。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "status": "ROLLBACK_SUCCESSFUL", "statusReason": "Service deployment rolled back because the circuit breaker threshold was exceeded." }, { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "status": "SUCCESSFUL" } ] } 後片付け 以下のコマンドを実行すると、このウォークスルーで作成したサービスとタスク定義を削除できます。このウォークスルーを実施するために ECS クラスターや VPC を作成した場合は、それらのリソースも削除してください。 aws ecs delete-service \ --cluster "${ECS_CLUSTER}" \ --service "deployment-demo" \ --force TASK_DEFS=$(aws ecs list-task-definitions \ --family-prefix "deployment-demo" \ --query taskDefinitionArns \ --output text) for TASK_DEF in $TASK_DEFS do aws ecs deregister-task-definition --task-definition "${TASK_DEF}" done まとめ この記事では、新しく導入された Amazon ECS のサービスデプロイメントとサービスリビジョンの機能について深掘りしました。これらの機能により、ソフトウェアリリースプロセスの可視性とトレーサビリティが向上し、より自信を持ってデプロイできるようになります。サービスデプロイメントとサービスリビジョンを使用すると、進行中のロールアウトの状況を深く把握、問題をより効率的にトラブルシューティングし、過去のデプロイメントの履歴を確認できます。この強化された可視性は、より信頼性と透明性の高いソフトウェアリリースライフサイクルを実現するのに役立つでしょう。 Amazon ECS の各機能の詳細については、 Amazon ECS 開発者ガイド を確認することをおすすめします。実際に手を動かしながら学びたい場合は、より実践的なガイドと例を含む、 Amazon ECS ワークショップ もぜひ活用してみてください。

現代のクラウド中心のビジネス環境では、データが複数のクラウドやオンプレミスのシステムに分散していることが多くあります。この断片化は、お客様が機械学習 (ML) イニシアチブとして、データを統合し、分析する作業を複雑にしています。 本稿では、さまざまなクラウド環境の中でも Google Cloud Platform (GCP) BigQueryに焦点を当て、データソースを移動することなく、データを直接抽出するアプローチをご紹介します。これにより、クラウド環境間でデータ移動の際に発生する複雑さとオーバーヘッドを最小限に抑えることができるため、組織は ML プロジェクトで様々なデータ資産にアクセスし、活用できるようになります。 今回焦点を当てるのは、 Amazon Athena Federated Query を使用して、GCP BigQuery からデータを抽出し、 Amazon SageMaker Data Wrangler を使用してデータ準備を行い、準備されたデータをノーコードの ML インターフェースである Amazon SageMaker Canvas で ML モデルを構築する、という一連のプロセスです。 SageMaker Canvas では、ビジネスアナリストは、コーディングや幅広い機械学習の経験がなくても、50 を超えるソースのデータにアクセスしてインポートし、自然言語と 300 を超える組み込みの変換を使用してデータを準備し、高精度のモデルを構築してトレーニングし、予測を生成し、モデルを本番環境にデプロイすることができます。また、コネクタとして用意されていない場合も、Amazon Athena などのサービスを通じて、データを活用することもできます。今回は、コネクタを通じて利用できる Amazon Athena を活用して、GCP BigQuery へライブクエリを行う方法についてご紹介します。 ソリューション概要 ソリューションでの、主なステップは以下の 2 点です。 CGP BigQuery から Federated Query を Amazon Athena でセットアップし、Athena から直接 GCP BigQuery でライブクエリを実行できるようにします。 Athena を中継し、BigQuery から SageMaker Canvas にデータをインポートします。 データソースのクエリ結果が SageMaker Canvas へインポートされた後は、ノーコードのインターフェースを使用して ML モデルを構築し、インポートされたデータに基づいて予測を生成できるようになります。 SageMaker Canvas を使用すると、コードを書かずに初期データ準備のルーチンを作り、正確な予測を生成することができます。ただし、ML の要件が進化したり、より高度なカスタマイズが必要になった場合は、ノーコード環境からコードファーストのアプローチに移行しなくてはならなくなる可能性があります。SageMaker Canvas と Amazon SageMaker Studio を統合すると、本番規模のデプロイのための、データ準備ルーチンの運用を実現できます。詳細については、「 Seamlessly transition between no-code and code-first machine learning with Amazon SageMaker Canvas and Amazon SageMaker Studio 」を参照してください。 以下のアーキテクチャ概要は、AWS サービスを使用して GCP BigQuery データウェアハウスにシームレスにアクセスし、SageMaker Canvas に統合して ML モデルを構築およびデプロイする方法を示しています。 ワークフローには以下のステップが含まれています。 SageMaker Canvas インターフェース上で、ユーザーは GCP BigQuery データウェアハウスに対して実行する SQL クエリを作成します。SageMaker Canvas はこのクエリを Athena に受け渡します。Athena は 中継として機能し、SageMaker Canvas と BigQuery 間の通信を促します。 Athena は、 Athena Google BigQuery connector を使用します。 Athena Federated Query は、 AWS Lambda 関数を利用してデータソースに接続し、クエリを実行する機能です。この Lambda 関数は、GUI 上で構成が可能です。また、必要な BigQuery の認証情報 (service account private key ) を取得します。 認証後は、Lambda 関数は、取得した認証情報を使用して BigQuery へクエリし、目的の結果セットを取得します。さらにこの結果セットをパースし、Athena に返送します。 Athena は、BigQuery からクエリされたデータを SageMaker Canvas へ返します。ノーコードインターフェース上で、ML モデルの学習や開発にそのデータを利用することができるようになります。 このソリューションには、次のメリットがあります。 シームレスな統合 – SageMaker Canvas を使用すると、BigQuery などのクラウド データウェアハウスを含む、様々なソースからのデータを、ノーコードの ML 環境へ直接統合し、使用できるようになります。この統合で、追加のデータ移動や複雑な統合が不要になります。データエンジニアリング タスクのオーバーヘッドがなくなるため、ML モデルの構築とデプロイに集中できるようになります。 セキュアなアクセス – Secrets Manager を使用すると、BigQuery の認証情報を安全に保存し、アクセスできるようになるため、ソリューション全体のセキュリティが強化されます。 スケーラビリティ – Lambda 関数のサーバレスの性質と、Athena の大規模データセットを処理する能力により、増大するデータ量に対応できるようになります。さらに、複数のクエリを使って、データをソースに対して並列に、パーティション分割することができます。 次のセクションでは、技術的な実装の詳細を詳しく説明し、このソリューションを順に説明します。 データセット 本稿では、ノーコード ML を行うために SageMaker Canvas にデータをインポートする方法の例を示しています。この例では、GCP BigQuery から Athena を介して、データをインポートする方法を示しています。 データセットとしては、通信携帯電話キャリアのデータセット ( synthetic dataset ) を使用します。このサンプルデータセットは、5,000 件のレコードが含まれ、各レコードでは、顧客プロファイルとして 21 個の属性を使用しています。データセットの Churn 列は、顧客が解約したかどうか (true/false) を示します。この Churn 属性は、ML モデルが予測するターゲット変数です。 前提条件 以下の前提条件のステップを完了させてください。 GCP の service account と service account key を作成します。 private key を JSON ファイルでダウンロードします。 JSON ファイルを Secrets Manager へ保存します。 Secrets Manager コンソール上で、ナビゲーションペインの「シークレット」を選択し、「新しいシークレットを保存する」を選択します。 シークレットのタイプは「その他のシークレットのタイプ」を選択します。 JSON ファイルの内容をコピーし、「キー/値のペア」の「プレーンテキスト」タブへ入力します。 SageMaker ドメインをまだ作成していない場合、ユーザープロファイルと共に作成してください。手順については「 Quick setup to Amazon SageMaker 」を参照してください。 以下のリソースに対して、SageMaker ドメインのユーザープロファイルの AWS Identity and Access Management (IAM) ロールに、 glue:GetDatabase と athena:GetDataCatalog の権限が付与され、Athena を呼び出せるようになっていることを確認します。既定では以下の権限は付与されていないため、必要に応じて付与してください。設定には、次の例を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "glue:GetDatabase", "athena:GetDataCatalog" ], "Resource": [ "arn:aws:glue:*: <AWS account id> :catalog", "arn:aws:glue:*: <AWS account id> :database/*", "arn:aws:athena:*: <AWS account id> :datacatalog/*" ] } ] } Athena データソースコネクタを登録する 以下の Athena data source connector のセットアップを完了させてください。 Athena コンソール上で、ナビゲーションペインの「データソース」を選択します。 「データソースの作成」を選択します。 「データソースを選択」ページで、「Google BigQuery」を選択し、「次へ」を選択します。 「データソースの詳細を入力」ページで、以下の情報を入力します。 「データソース名」で、任意の名前を入力します。 「説明」で、オプションとして説明を入力します。 「Lambda 関数」で、接続の設定を行うために「Lambda 関数の作成」をクリックします。  Lambda 関数の作成画面の「アプリケーションの設定」で、以下の情報を入力します。 「SpillBucket」で、Lambda 関数のレスポンスサイズ制限を超えるデータを保存するための、アカウント内の S3 バケットの名前を入力します。 「GCPProjectID」で、GCP の project ID を入力します。 「LambdaFunctionName」で、作成した Lambda 関数の名前を入力します。 「SecretNamePrefix」で、Secrets Manager で保存した GCP 認証情報が含まれるシークレットの名前を入力します。 「デプロイ」を選択します。「データソースの詳細を入力」ページに戻ります。 「接続の詳細」セクションで、「Lambda 関数」で更新アイコンを押します。 先ほど作成した Lambda 関数を選択します。Lambda 関数の ARN が表示されます。 オプションとして、「タグ」で、データソースに紐づける「キー/値」のペアを追加します。タグについて詳細は「 Tagging Athena resources 」を参照してください。 「次へ」を選択します。 「確認と作成」ページで、データソースの詳細を確認し「データソースを作成」を選択します。 データソースのページでの「データソースの詳細」セクションでは、新しいコネクタの情報が表示されます。Athena クエリで、そのコネクタを利用することができます。クエリでのデータコネクタを利用する事について、詳細は「 Running federated queries 」を参照してください。 Athena から クエリするには、Athena SQL エディタを開き、先ほど作成したデータソースを選択してください。BigQuery のデータセットに対して、ライブクエリを行うことができます。 Athena をデータソースとして SageMaker Canvas に接続する Athena からデータをインポートするために、以下のステップを完了させてください。 SageMaker Canvas コンソールで、ナビゲーションペインの「Data Wrangler」を選択します。 「Import data and prepare」を選択します。 「Tabular」を選択します。 データソースとして、「Athena」を選択します。 SageMaker Canvas の SageMaker Data Wrangler では、データの準備、特徴量エンジニアリング、分析を行うことができます。コーディングをほとんど使わず、またはノーコードで、 SageMaker Data Wrangler データ準備フローを ML ワークフローに統合することができます。データの前処理、特徴量エンジニアリングを簡素化し、合理化します。 左ペインの AWSDataCatalog で Athena テーブルを選択し、テーブルを右ペインへ ドラッグ ＆ ドロップ します。 「Edit in SQL」を選択し、次の SQL クエリを入力します。 SELECT state, account_length, area_code, phone, intl_plan, vmail_plan, vmail_message, day_mins, day_calls, day_charge, eve_mins, eve_calls, eve_charge, night_mins, night_calls, night_charge, intl_mins, intl_calls, intl_charge, custserv_calls, churn FROM " bigquery "." athenabigquery "." customer_churn " order by random() limit 50 ; 上記のクエリでは、 bigquery は Athena で作成されたデータソース名、 athenabigquery はデータベース名、 customer_churn はテーブル名です。 データセットの準備のため「Run SQL」を選択します。データが十分であれば、「Import」を選択します。 ML を使用する場合、データセットをランダム化、またはシャッフルすることが重要です。数百万または数十億のデータポイントにアクセスできる場合でも、データセットの全量が必要ない場合は、ランダムにサンプリングすることで、学習用のサブセットを作成できます。データをシャッフルして準備したら、データの準備、特徴量評価、モデルの学習、学習済みモデルのホスティングという、反復的なプロセスを開始できます。 SageMaker Data Wrangler を使うと、データを処理したり、ML ワークフローに適した場所にエクスポートできます。例えば、変換されたデータを、SageMaker Canvas データセットとしてエクスポートし、そこから ML モデルを作成できます。 また、ML モデル作成に利用する学習用のデータセットと別に、推論評価用のデータセットを分けて保存しておくことをお勧めします。その場合、SageMaker Data Wrangler の組み込みのデータ変換「Split data」を Steps の一つとして追加すると、容易に分割を行うことができます。 データをエクスポートした後、「Create model」を選択して、データから ML モデルを作成します。 データは、Athena の特定のテーブルからデータセットとして SageMaker Canvas にインポートされます。これで、このデータセットを使用してモデルを作成できます。 モデルの学習 データがインポートされると、SageMaker Canvas の「Datasets」ページに表示されます。この段階になると、モデルを構築することができます。そのためには、次の手順を行ってください。 データセットを選択してから、「Create a model」を選択します。 「Model name」で、任意のモデル名を入力してください。(本稿では my_first_model )SageMaker Canvas では、予測分析、画像分析、テキスト分析のモデルを作成できます。 今回は顧客が解約したかどうかを分類したいため、「Problem type」で「Predictive analysis」を選択します。 「Create」を選択します。 「Build」ページで、欠損値の割合やデータのモードなど、データセットに関する統計情報を確認できます。 「Target column」で、予測したい列を選択します。(本稿では churn )SageMaker Canvas では、予測を生成するために、2 種類のモデルが提供され。Quick build は、制度よりも速度が優先され、2 〜 15 分でモデルが提供されます。Standard build では、速度よりも精度が優先され、30 分 〜 2 時間でモデルが提供されます。 この例では、「Quick build」を選択します。 モデルの学習後は、モデルの精度を分析できます。 「Overview」タブでは、列の影響、つまり、ターゲット列を予測する時の、各列の推定重要度が表示されます。この例では、 Night_calls 列が顧客が解約するかどうかを予測する上で最も大きな影響を与えています。この情報は、マーケティングチームが顧客離れを減らすための対策を講じる際の、洞察を得るのに役に立ちます。例えば、 CustServ_Calls が低い場合も高い場合も、顧客離れの可能性が高いことがわかります。マーケティングチームは、これらの学びに基づいて、顧客離れを防ぐための対策を講じることができます。例えば、Web サイトに詳細な FAQ を作成して、カスタマーサービスへの問い合わせを減らしたり、FAQ に関する顧客向け教育キャンペーンを実施してエンゲージメントを維持することが挙げられます。 予測を生成する 「Predict」タブでは、バッチ予測と単一予測の両方を生成できます。バッチ予測を生成するには、以下の手順を実施します。 予測を生成するために、サンプルの inference dataset をダウンロードします。 バッチ予測のテストを行うために、「Batch prediction」を選択します。SageMaker Canvas を使用すると、手動で、またはスケジュールに従って自動的にバッチ予測を生成できます。スケジュールに従って、バッチ予測を自動化する方法は、「 Manage automations 」を参照してください。 本稿では、「Manual」を選択します。 先ほどダウンロードしたファイルをアップロードします。 「Generate prediction」を選択します。 数秒後に予測が完了すると、「View」を選択して、予測を確認することができます。 必要に応じて、「Download」を選択して、すべてのアウトプットを含む CSV ファイルをダウンロードすることができます。SageMaker Canvas は、データの各行の予測と、予測が正しい確率を返します。 オプションとして、モデルをエンドポイントにデプロイして予測をこなうことができます。詳細については「 Deploy your models to an endpoint 」を参照してください。 クリーンアップ 将来の不要な請求を避けるために、SageMaker Canvas で作業が完了したら、Canvas アプリケーションからログアウトしてインスタンスを終了するか、ワークスペースインスタンスを自動終了するようにアプリケーションを設定することをお勧めします。詳細な情報は、「 log out of SageMaker Canvas 」を参照してください。 SageMaker Canvas からのログアウト Canvas からログアウトしても、モデルとデータセットは影響を受けませんが、クイックビルドタスクをキャンセルできます。ログアウトすると、Canvas は別のタブで再起動するよう指示します。クイックビルド実行中の場合は、アプリケーション再起動が完了するまで、ビルドが中断される可能性があります。ログアウトしても、標準ビルドは続行されます。 Canvas アプリケーションからログアウトするには、「Log out」アイコンを選択してください。 SageMaker Canvas を自動的にシャットダウンする アクティブな Canvas アプリケーションをシャットダウンするスケジュールを作成するか、アイドル状態になったらすぐにシャットダウンするオートメーションを作成することができます。ソリューションの詳細は、ブログ「 自動シャットダウンソリューションを使ってAmazon SageMaker Canvas のコストを最適化する方法 」を参照してください。 まとめ 本稿では、Athena Federated Query とサンプルデータセットを使用して、BigQueryからデータを抽出するソリューションを紹介しました。次に、抽出したデータを使用して、ノーコードで SageMaker Canvas で ML モデルを構築し、解約リスクがある顧客を予測しました。SageMaker Canvas を使用すると、ビジネスアナリストはノーコードのインターフェースを通じて ML モデルを簡単に構築、およびデプロイできるため、組織全体で ML を民主化することができます。これにより、高度な分析と ML の力を活用して、専門的な技術スキルの必要なく、ビジネスインサイトとイノベーションを推進できます。 より詳しい情報は、「 Query any data source with Amazon Athena’s new federated query 」と「 Import data from over 40 data sources for no-code machine learning with Amazon SageMaker Canvas 」を参照してください。もし、SsageMaker Canvas についてよく知らない場合は、「 Build, Share, Deploy: how business analysts and data scientists achieve faster time-to-market using no-code ML and Amazon SageMaker Canvas 」を参照してください。 本稿は、 Import data from Google Cloud Platform BigQuery for no-code machine learning with Amazon SageMaker Canvas の翻訳となります。 翻訳は、ソリューションアーキテクト 加藤 菜々美が担当しました。 著書について Amit Gautam Amit Gautam は、英国のエンタープライズ顧客のクラウド導入をサポートする AWS シニアソリューションアーキテクトであり、ビジネス成果の達成に役立つアーキテクチャに関するアドバイスやガイダンスを提供しています。 Sujata Singh Sujata Singh は、英国のエンタープライズ顧客のクラウド導入をサポートする AWS シニアソリューションアーキテクトであり、ビジネス成果の達成に役立つアーキテクチャに関するアドバイスやガイダンスを提供しています。

本稿は、2024 年 10 月 29 日に AWS Cloud Enterprise Strategy Blog で公開された “ How Executives Can Avoid Being Disrupted by Emerging Technologies ” を翻訳したものです。 経営幹部は、ビジネスをますます破壊する急速なテクノロジーの変化を予測し、新たな市場と提携の機会を見つけなければなりません。経済、社会、地政学、気候、消費者、テクノロジーの変化を数値化したアクセンチュア社の グローバル・ディスラプション・インデックス によると、破壊の速度はわずか 5 年前と比較して 50 倍に加速しています。経営幹部はどのようにして時代の先端を行くことができるでしょうか？ テクノロジーのトレンドを予測することは重要 破壊的なテクノロジーを予測し、それらを活用する体制を整えることで、先見の明のある経営陣は、事業の陳腐化を防ぎ、成長、効率性、イノベーションの新たな道筋を発見することができます。企業は、テクノロジーを早期に特定し、採用することで、生産性を向上させ、ワークフローを合理化し、顧客体験をパーソナライズし、戦略的意思決定に役立つデータ主導の洞察を引き出すことができます。 Amazon は、eコマースの分野で早期に事業を展開し、オンラインインフラとロジスティクスに多額の投資を行い、業界のリーダーとなりました。Apple は 2007 年に iPhone を発売し、タッチスクリーン技術、モバイルアプリ、洗練されたユーザーエクスペリエンスにより、携帯電話業界に革命をもたらしました。Netflix はビデオオンデマンドを導入することで従来のケーブルテレビや DVD レンタルのビジネスモデルを破壊し、Uber はアプリベースのライドシェアリングによりタクシーやリムジン業界を一変させました。これらの企業は、新興技術を特定し活用することで、新たなビジネスチャンスを生み出し、市場シェアを獲得し、収益を増加させ、革新的なリーダーとしての評価を確固たるものにしてきました。 あなたは「テクノロジーの予言者」になれるか 新たなテクノロジーは、コストや使いやすさ、使いやすさに対する知覚価値、新たな標準規格など、さまざまな要因により、予測が難しいことで知られています（訳者注：知覚価値とは、顧客が製品やサービスに対して抱く総合的な価値のことであり、お金に限らず健康の増進や様々な経験の向上なども含まれます）。新型コロナウイルス (COVID-19) のパンデミックのような予期せぬ混乱は、入念に練られた予測を一夜にして時代遅れにしてしまう可能性があります。 また、アーリーアダプターは、入手しやすい情報を過信しすぎたり、もはや実行不可能な投資をあきらめられないという問題にも直面します。テクノロジーの成功は、それを支えるインフラや補完的な製品に左右されますが、それらの製品は相互依存のウェブを形成しており、予測が困難です。経営陣は、新たなテクノロジーに関する情報を常に把握し、最も重要なテクノロジーを積極的に採用する必要があります。 テクノロジーのトレンドを特定する方法 絶対確実な「テクノロジーの予言者」になることはできませんが、学習、適応、革新に適した組織の生態系を育成することは可能です。そのためには、テクノロジーに対する認識、関与、機敏性を企業の組織構造に組み込む多面的な戦略が必要です。経営陣がテクノロジーのトレンドを特定するために、次の4つの能力を開発することをお勧めします。 1. テクノロジーのモニタリングと調査を行う これは、業界トレンドの何気ない観察を越えたものであり、テクノロジーの現状を調査するための体系的なアプローチを必要とします。有望なイノベーションを特定し、ビジネスへの潜在的な影響を評価し、それらを迅速に試す専任のテクノロジー調査チームを編成することができます。このチームには、自社にとって最も重要なトレンドを迅速に絞り込むための使命と仕組みが求められます。また、研究機関や最先端のスタートアップ企業と提携し、現在および将来のビジネス上の問題の解決に役立つ新たなテクノロジーへの直接的なパイプラインを確保すべきでしょう。業界レポートやアナリストの見解を読んだり、テクノロジー関連のカンファレンスに参加したり、パートナー企業とネットワークを築くなど、業界におけるテクノロジーの進化の最新情報を入手し把握してください。 ヒント： 新たなテクノロジーとそれが自社のビジネスに与える影響について、ブリーフィングを実施しましょう。 これらのテクノロジーを活用してビジネス上の問題を解決するボランティアを募ります。 これにより、指導者的なグループが構築され、事業部門に必要なテクノロジースキルが身に付きます。 ヒント： テクノロジー・スカウトチームは、目新しさだけを求めて新たなテクノロジーを探求するのではなく、具体的なビジネス価値の提供に重点を置かなければなりません。製品、業務、または顧客体験への影響についてチームに説明責任を負わせるための KPI を設定します。 ヒント： 専任のテクノロジー・スカウトチームの設置が現実的でない場合は、組織内のリーダーで構成されるバーチャルなスカウトチームを編成するという賢明な代替策があります。異なる事業部門の利害関係者の多様な視点や専門知識を活用することで、新たなテクノロジーとその潜在的な影響をより深く理解することができます。 2. 好奇心と実験の文化を創り出す この文化の変化には、従業員に情報を入手し続けるよう促す以上のことが必要です。革新的な思考が報われ、リスクを冒すことが奨励される環境を作りましょう。組織が従業員の集合知と創造性を活用することが目標です。 ヒント： CoE (Center of Engagement) を設置する。 ここでいう CoE とは、Center of Excellence ではなく、Center of Engagement (エンゲージメントの中心) のことです。 この CoE では、技術者とビジネスユーザーの全員が新たなテクノロジーを試し、その結果を報告することが奨励されます。CoE は小規模で迅速に運営され、現場での迅速なトレーニングを奨励し、成功と失敗を共有します。実験とコラボレーションを推進することで、どの新たなテクノロジーを組織全体でより迅速に採用すべきかを決定することができます。 ヒント： 社内ハッカソンを開催し、テクノロジープロバイダーに参加を呼びかけましょう。これにより、スタッフがテクノロジーと全社的な実験に信頼を寄せるのに役立ちます。また、NASA が開発した測定システムである、 Technology Readiness Level で評価することもできます。 3. テクノロジーロードマップ作成とシナリオプランニングにテクノロジーを活用する 洗練されたテクノロジーロードマップ作成とシナリオプランニングを行うには、複数の結果を想定し、対応策を準備する必要があります。技術的専門知識とビジネス感覚を兼ね備えた、小規模で多様な部門横断チームを編成します。これらのチームは、ダイナミックで順応性のあるップを作成するために、モデリング技術とデータ分析を使用します。これらのロードマップは、技術の急速な変化に対応できるよう、定期的に見直し、更新されます。 各テクノロジーについて、以下を検討します。 従業員がそれを受け入れるだろうか？ ビジネス上の問題を解決できるか？ ビジネスユーザーに説明できるか？ 導入にコストをかけられるか？ ヒント： 興味のある新たなテクノロジーについて、1 ページのポジションペーパーを作成する。 その技術に対する現在のアクション (つまり、観察、評価、テスト、積極的な実験、運用、または廃止など) をリストアップする。 その技術が自社ビジネスにどう関連するのかについて、パラグラフを追加する。 各技術について、どの事業部門が恩恵を受けられるか、また関係する人々やパートナーについて、セクションを追加する。 半年ごとにポジションを更新する。 この簡潔なポジションペーパーを、協力関係を築きたいサプライヤー、パートナー、顧客と共有することを検討しましょう。「X というテクノロジーについて、あなたはどの程度ご存知ですか？」と尋ねる従業員に、このペーパーはインパクトを与えるでしょう。 4. 外部パートナーシップを結ぶ どんなに規模が大きく、資金力のある組織であっても、すべてのテクノロジー開発に遅れずについていくことは不可能です。パートナーの多様なネットワーク (実績のあるテクノロジーベンダーから、柔軟な対応力を持つ新興企業、学術機関から業界の同業者まで) と関わることで、洞察力を得たり、最先端のイノベーションにアクセスしたりすることができます。こうしたパートナーシップには、正式な研究協力から、業界コンソーシアムへの参加、新たなテクノロジーに焦点を当てたベンチャーキャピタルファンドへの投資など、さまざまな形態があります。 ヒント： プロバイダーのロードマップについて話し合い、新たなテクノロジーのテストを申し出てください。実際のビジネス上の問題の解決に役立つのであれば、パートナーとしての優先順位が上がり、正式採用が加速するでしょう。さらに良いことに、そのテクノロジーのメンテナンスはテクノロジーパートナーが行うため、自社でメンテナンスを行う必要はありません。 ヒント： 社外のイノベーションを評価し、統合するための正式なプロセスを確立しましょう。そのプロセスには、潜在的な技術提携や買収を評価する専門チームの編成が含まれるかもしれません。このような取り組みを行う企業は、社外のイノベーションと社内の能力を組み合わせるメリットを享受することができます。 今すぐ始めましょう。今なら間に合います。昨日ならもっと良かったのですが。 デジタル革命は、リーダーが技術革新に遅れずについていくことを要求しています。AI 、 IoT 、クラウド、サイバーセキュリティ、サステナビリティなど、破壊的なトレンドに遅れずについていくために、テクノロジーのモニタリング、実験、ロードマップ作成、外部パートナーシップを活用することができるのです。 Tom Soderstrom トム・ソダーストロームは 2020 年に AWS に入社し、AWS パブリックセクターのチーフテクノロジスト組織を構築し率いた後、2023 年に AWS エンタープライズ戦略チームに入社しました。AWS 入社前は、2006 年から 2020 年まで、NASA のジェット推進研究所 (JPL) で IT Chief Technology and Innovation Officer を務めていました。クラウドの初期のパイオニアとして、 JPL 、 NASA 、米国連邦政府でクラウドコンピューティングを導入し、指導しました。 Tom Godden トム・ゴッデンは、Amazon Web Services (AWS) のエンタープライズストラテジスト兼エバンジェリストです。AWS 入社前は、Foundation Medicine の最高情報責任者 (CIO) として、FDA の規制下にある世界トップクラスの癌ゲノム診断、研究、患者治療結果のプラットフォームの構築に携わり、治療結果の改善と次世代の精密医療の実現に貢献しました。それ以前は、Alphen aan den Rijn Netherlands にある Wolters Kluwer で複数の上級技術リーダー職を歴任し、ヘルスケアおよび生命科学業界での経験は 17 年以上に及びます。トムはアリゾナ州立大学で学士号を取得しています。

本ブログは 2024 年 11 月 15 日に公開された Blog “ Secure by Design: AWS enhances centralized security controls as MFA requirements expand ” を翻訳したものです。 Amazon Web Services (AWS) は、Day 1 (創業当初) からセキュア・バイ・デザインの原則に基づいてサービスを開発してきました。初期状態でもお客様のセキュリティポスチャが高い基準に設定されている特徴があります。強力な認証は、アカウントセキュリティ全体の基礎となる要素であり、多要素認証 (MFA) の使用はシステムやデータへの不正アクセスを防ぐための最もシンプルで効果的な方法の 1 つです。MFA を有効にすることで、パスワードを狙った攻撃の 99% 以上を防止できることがわかっています。本日は、MFA の要件拡大について、 最初に発表してから の過去 1 年間の進捗状況をお伝えします。2023 年 10 月の発表では、AWS Management Console のルートユーザーに MFA の使用を必須とすることで、お客様のデフォルトのセキュリティポスチャを向上させることを要件としました。 近年、一般的な職場環境は大きく変化しています。ハイブリッドワークや BYOD (私用デバイスの業務利用) ポリシーなどの導入が増加し、セキュリティ境界の定義はより複雑になりました。ほとんどの組織は、アイデンティティベースの統制を重視するようにセキュリティ境界を調整しましたが、これによってユーザーパスワードが境界における新たな弱点となりました。ユーザーは使いやすさを重視して複雑さの低いパスワードを選択したり、複数のウェブサイトで同じ複雑なパスワードを再利用したりすることがあり、あるウェブサイトでデータ漏洩が発生した場合に大きなリスクとなります。 このようなリスクに対するお客様のレジリエンスを向上させるため、私たちは多くの対策を講じています。例えば、漏洩した認証情報をオンラインソースでモニタリングし、それらが AWS で悪用されることを防いでいます。また、脆弱なパスワードが設定されることを防止し、ユーザーにデフォルトのパスワードを設定することは決してありません。さらに、MFA をまだ有効にしていないお客様に対して異常なサインイン活動を検出した場合、プライマリメールアドレスにワンタイム PIN を送信して検証を行います。これらの対策にもかかわらず、パスワードのみの認証には本質的なリスクが残ります。 状況を改善するために、2 つの重要な改善機会を認識しました。1 つ目は、お客様の MFA 採用を加速し、高い権限を持つユーザーに MFA を要求することで、AWS のデフォルトのセキュリティポスチャを強化することです。2024 年 5 月、大規模な環境のユーザーから始めて、 AWS Organizations 管理アカウントのルートユーザーに MFA を要求するようになりました。そして 6 月には、MFA 方式として FIDO2 パスキーのサポートして、お客様のセキュリティ要件を満たし、非常に安全性が高くありながらユーザーフレンドリーな新たな選択肢も追加しました。同時に、 MFA 要件を拡大し 、スタンドアロンアカウントのルートユーザーも含めることを発表しました。 AWS Identity and Access Management (IAM) が 2024 年 6 月に FIDO2 パスキーのサポートを開始して以降、フィッシング攻撃に強い MFA の登録率は 100% 以上増加しました。2024 年 4 月から 10 月の間に、75 万以上の AWS ルートユーザーが MFA を有効にしました。 2 つ目に認識したのは、不要なパスワードを完全に排除することです。パスワードのセキュリティ上の問題に加えて、パスワードベースの認証を保護しようとすると、特に大規模に運用しているお客様や、規制要件によって定期的なパスワードのローテーションが必要なお客様にとって、運用上のオーバーヘッドが発生します。本日、AWS Organizations で管理されているアカウントのルートアクセスを一元管理する 新機能 を発表しました。この機能により、ルートプリンシパルの使用に対する強力な統制を維持しながら、管理が必要なパスワードの数を大幅に削減できます。お客様は、IAM コンソールまたは AWS CLI を通じた簡単な設定変更で一元化されたルートアクセスを有効にできるようになりました。この手順の詳細は こちらのブログ で説明されています。その後、組織内のメンバーアカウントのルートユーザーの長期的な認証情報（パスワードや長期的なアクセスキーを含む）を削除できます。これにより、運用の負担を軽減しながら、お客様のセキュリティポスチャを改善することができます。 Organizations 利用のお客様には、これらのメリットを体験していただくため、集中管理されたルートアクセス機能を今すぐ有効にすることを強くお勧めします。ただし、お客様が引き続きルートユーザーを維持する場合、高い権限を持つこれらの認証情報を適切に保護することが不可欠です。大規模運用をされているお客様へのサポート強化と、パスキーなどの追加機能により、AWS Organizations のメンバーアカウントに対する MFA 要件を拡大しています。2025 年春より、ルートアクセスの集中管理を有効にしていないお客様は、AWS マネジメントコンソールにアクセスするために、AWS Organizations のメンバーアカウントのルートユーザーに対して MFA を登録する必要があります。管理アカウントやスタンドアロンアカウントへの以前の適用拡大と同様に、この変更は段階的に展開され、対応が必要なお客様には事前に個別に通知を行い、日常業務への影響を最小限に抑えながら新しい要件に準拠できるようサポートします。 ルートアクセスを一元管理する新機能の詳細については IAM ユーザーガイド を、AWS での MFA の使用については IAM ユーザーガイドの AWS MFA をご参照ください。 Arynn Crow Arynn Crow は AWS Identity のアカウント保護担当プリンシパルプロダクトマネージャーです。2012 年にカスタマーサービスエージェントとして Amazon に入社し、2017 年にセキュリティとアイデンティティの分野で自分の居場所を見つけるまで、何年もの間さまざまな役割に挑戦してきました。Arynn は、アカウント保護、規制と標準、セキュアバイデザインの取り組みに焦点を当てています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 6 月 11 日に公開された Blog “ Passkeys enhance security and usability as AWS expands MFA requirements ” を翻訳したものです。 Amazon Web Services (AWS) は、お客様のワークロードを実行するための最も安全なインフラストラクチャとなるように設計されています。クラウドにおける「セキュア・バイ・デザイン」と「セキュア・バイ・デフォルト」の実践を、AWS は Day 1 (創業当初) から先駆的に実践してきました。本日 (2024 年 6 月 11 日)、AWS は MFA 機能の拡張の一環として、多要素認証 (MFA) の方法として FIDO2 パスキーのサポートを開始しました。お客様の強力な認証のオプションをさらに強化する取り組みです。パスキーは、多くのお客様に対して、高度に安全でユーザーフレンドリーな MFA オプションを提供します。 変更点 2023 年 10 月、AWS は AWS アカウントで最も特権を持つユーザーに対して MFA を必須とする ことを最初に発表しました。これは AWS Organizations の管理アカウントのルートユーザーから始まり、その後他のユースケースに拡大されます。2024 年 7 月から、独立したアカウント (AWS Organizations で管理されていないアカウント) のルートユーザーは、AWS マネジメントコンソールにログインする際に MFA の使用が必須となります。管理アカウントと同様に、この変更は少数のお客様から始まり、数ヶ月かけて段階的に拡大していきます。お客様には MFA を有効にするための猶予期間が設けられ、ログイン時にお知らせとして表示されます。この変更は、AWS Organizations のメンバーアカウントのルートユーザーには適用されません。メンバーアカウントなど、残りのルートユーザーのユースケースに対する MFA 要件については、2024 年後半に詳細な情報を共有する予定です。これは、より多くのユーザーに対して大規模に MFA を管理するための追加機能の開発を進めながら行います。 今後、数ヶ月間でこのプログラム拡大の準備を進める中、本日、FIDO2 パスキーを MFA 方式としてサポートすることを発表します。これにより、お客様は MFA 要件に準拠し、基本的なセキュリティポスチャを強化できるようになります。パスキーはすでに世界中の何十億ものコンピューターやモバイルデバイスに使われており、デバイスに組み込まれている指紋、顔スキャン、PIN などのセキュリティメカニズムのみが使用されています。パスキーを使用する例として、iPhone の Apple Touch ID や、ラップトップの Windows Hello を認証機能として設定し、同じパスキーを MFA 方式として使用して、お使いの様々なデバイスから AWS コンソールにサインインすることができます。 この 1 年間、業界ではパスキーについて多くの議論がありました。そこで、このブログでは、パスキーに関するよくある質問に回答し、セキュリティ戦略にどのように組み込めるかについての考察を共有します。 そもそもパスキーとは何か？ パスキーは、なじみのある技術に付けられた新しい名前です。パスキーは FIDO2 クレデンシャルであり、公開鍵暗号を使用して強力でフィッシング耐性のある認証を提供します。パスキーは同期機能を持ち、Apple、1Password、Google、Dashlane、Microsoft などのクレデンシャル管理サービスによる FIDO2 実装の進化形です。これにより、FIDO キーは USB ベースのキーなどの物理デバイスに保存される代わりに、デバイスやオペレーティングシステム間でバックアップや同期が可能になります。 これらの進化は、利便性とアカウントの復旧を重視するお客様にとって大幅な改善となります。しかし、FIDO2 を構成する仕様に変更を加える必要はありませんでした。パスキーは、FIDO2 が当初から備えていた、暗号技術的に安全でフィッシング耐性のある基本的な特性を同じように備えています。FIDO アライアンスのメンバー企業として、AWS は FIDO と協力して強力な認証技術の進化と成長をサポートし続けており、利便性と強力なセキュリティのバランスが取れた FIDO 技術の新しい利用体験を実現できたことを大変喜ばしく思います。 パスキーの利用対象者は？ パスキーを利用すべき人について説明する前に、 どのような タイプの MFA でも、MFA を全く使用しないよりは良いということを強調しておきます。MFA は、アカウントに適用できる最もシンプルで効果的なセキュリティ管理策の 1 つであり、誰もが 何らかの タイプの MFA を使用すべきです。しかし、個人で使用するものや会社で導入するものを決める際には、MFA のタイプ間の主な違いを理解しておくことが有用です。 フィッシング耐性のある MFA タイプとして、パスキーや他の FIDO2 認証器 (Authenticator) を推奨します。近年、認証情報を狙った攻撃が増加するにつれ、ワンタイム PIN (OTP) を MFA に使用するユーザーを標的としたフィッシングやソーシャルエンジニアリングの攻撃も増加しています。例えば、OTP デバイスのユーザーは、デバイスから PIN を読み取って手動で入力する必要があるため、悪意のある攻撃者が、無自覚なユーザーに OTP を読み上げさせようとし、MFA の効果を無効化しようとする可能性があります。パスキーは、他の MFA と同様にパスワードのみの認証よりも明らかに改善されています。さらに多くの場合、OTP ベースの MFA よりもユーザーフレンドリーで安全です。これが、パスキーがセキュア・バイ・デザイン戦略において重要なツールである理由です。効果的なセキュリティには、使いやすいセキュリティが不可欠です。このため、パスキーは多くの人にとって、ユーザー体験とセキュリティのバランスを取るための優れたオプションです。より安全でありながら使いやすいセキュリティメカニズムを見つけるのは常に容易ではありませんが、OTP ベースの MFA と比較すると、パスキーはそのような好ましい例外の 1 つです。 同期機能のない FIDO2 ハードウェアセキュリティキーや認証アプリなど、他のタイプの MFA をすでに使用している場合、同期可能なパスキーに移行すべきかどうかは、お客様や組織の用途や要件によって異なります。FIDO2 セキュリティキーは、作成したデバイスにのみクレデンシャルが紐付けられているため、 FIPS 認証 デバイスなど、最も強力な認証形式を必要とする規制やセキュリティ要件を持つお客様に対して、最高レベルのセキュリティ保証を提供します。また、パスキープロバイダーのセキュリティモデルを理解することも重要です。例えば、鍵保管庫へのアクセスや回復のためにプロバイダーが設定する要件などが、今後どのような種類の MFA を導入または使用するかを決定する際の全体的なセキュリティモデルにおいて重要な考慮事項となります。 MFA の利用拡大 2024 年 5 月の RSA カンファレンスで、AWS は 米国サイバーセキュリティ・インフラセキュリティー庁 (CISA) のセキュア・バイ・デザインの誓約 に署名することを決定しました。これは CISA のセキュア・バイ・デザイン原則に沿った、エンタープライズソフトウェア製品およびサービスのための自主的な誓約です。この誓約の重要な要素の 1 つは、アカウントセキュリティを強化する最もシンプルで効果的な方法の 1 つである、多要素認証 (MFA) の利用を促進することです。 MFA として使用される場合、パスキーはユーザーフレンドリーな方法で認証のセキュリティを強化します。AWS コンソールアクセスのセキュリティを強化するために、今すぐパスキーを登録して使用できます。これにより、2024 年 7 月から多くのお客様に展開される AWS のデフォルト MFA セキュリティ要件に準拠するのに役立ちます。セキュア・バイ・デザインの取り組みの他の要素に関する状況と進捗については、今後のお知らせでさらに詳しくお伝えします。それまでの間、サインインを行うすべてのサービスで何らかのタイプの MFA を採用することを強くお勧めします。特に、FIDO2 パスキーによって強化されたフィッシング耐性のある MFA の採用をお勧めします。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Arynn Crow Arynn は、AWS Identity のユーザー認証製品のシニアマネージャーです。Arynn は 2012 年に Amazon のカスタマーサービスエージェントとしてキャリアをスタートし、その後何年もの間さまざまな役割を経験しました。2017 年にセキュリティとアイデンティティの分野で自分の居場所を見つけました。現在、Arynn はユーザー認証サービスの開発を担当する製品チームを率いています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2023 年 10 月 3 日に公開された Blog “ Secure by Design: AWS to enhance MFA requirements in 2024 ” を翻訳したものです。 Amazon Web Services (AWS) では、セキュリティが最優先事項です。多要素認証 (MFA) の使用を必須とすることで、お客様の環境のデフォルトのセキュリティポスチャをさらに強化していくことをお知らせします。これは、アカウント内の最も権限の高いユーザーから始めます。MFA は、アカウントのセキュリティを強化する最もシンプルで効果的な方法の 1 つであり、システムやデータへの不正アクセスを防ぐための追加の保護層を提供します。 2024 年半ばより、 AWS Organizations の管理アカウントのルートユーザーで AWS マネジメントコンソールにサインインするお客様は、MFA を有効化する必要があります。MFA の有効化が必要なお客様には、コンソールへのサインイン時のプロンプトを含む複数のチャネルを通じて、この変更について事前に通知されます。 2024 年を通じて、AWS Organizations 外のスタンドアロンアカウントなど、さらに多くのシナリオにこのプログラムを拡大していく予定です。このために、MFA の導入と大規模な管理がさらに容易になる機能をリリースしていきます。ただし、MFA のメリットを活用するために 2024 年を待つ必要はありません。 AWS Identity and Access Management (IAM) ユーザーガイド にアクセスして、AWS での MFA の有効化方法を確認できます。また、対象となるお客様は、 注文ポータル から無料のセキュリティキーをリクエストすることができます。 (※訳者注: 2024 年 11 月時点では、過去 3 か月間に 300 USD 以上を消費した、米国を拠点とするルートアカウント所有者が、無料の MFA セキュリティキー受け取りの対象者となります) AWS で最も特権を持つユーザーが MFA で保護されていることを確認することは、AWS のお客様のセキュリティポスチャを継続的に強化するという私たちの取り組みの最新のステップです。より多くのお客様が MFA の導入を開始できるよう、2021 年秋には、米国の対象となる AWS アカウント所有者に無料の MFA セキュリティキーの提供を開始しました。そして 2022 年 11 月には、AWS のアカウントルートユーザーまたは IAM ユーザーごとに最大 8 つの MFA デバイスを登録できるようにサポートを開始し、MFA 戦略に柔軟性と強靭性を追加しました。 すべてのユーザーに何らかの形式の MFA を採用することをお勧めしており、さらにセキュリティキーなどのフィッシング耐性のある MFA の形式を選択することをお勧めしています。Organizations の管理アカウントのルートユーザーに対する MFA の有効化要件は 2024 年に導入される予定ですが、ルートユーザーだけでなく、環境内のすべてのユーザータイプに対して MFA を有効にすることを、ぜひ今すぐに開始することをお勧めします。例えば、AWS IAM Identity Center では、パスキーや認証アプリケーションなど、複数の MFA オプションを有効にすることができます。詳細については、 AWS IAM Identity Center の MFA ユーザーガイドをご覧ください。 このブログに関するご質問は、 AWS Support までお問い合わせください。 AWS のセキュリティに関する最新情報をもっと知りたいですか？ X でフォローしてください。 Steve Schmidt Steve Schmidt は 2008 年 2 月に Amazon に入社し、現在 Amazon のチーフセキュリティオフィサーを務めています。情報セキュリティ、物理セキュリティ、セキュリティエンジニアリング、規制プログラムのチームを統括しています。2010 年から 2022 年まで、Amazon Web Services (AWS) のチーフ・インフォメーション・セキュリティ・オフィサーを務めました。Amazon 入社前は FBI で幅広いキャリアを積み、上級幹部として勤務。FBI では、技術的な情報収集・分析の開発・運用を監督する暫定チーフテクノロジーオフィサーや、コンピュータおよびネットワーク侵入の技術調査を担当する FBI サイバー部門のセクションチーフなどを歴任しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

This article is a contribution from Mr. Eiji Natsuaki, Executive Officer and Head of the Business Creation Division of Osaka Gas Co., Ltd., regarding our company’s efforts to use generative AI for a carbon credit evaluation system. It is the second part of a two-part series. This is the second part of the article. The first part can be found here: “ Introduction to the Carbon Credit Evaluation System Using Generative AI by Osaka Gas Co., Ltd. (First half) ” 1. Approach to the Carbon Credit Domain Our company aims to achieve carbon neutrality by 2050 and plans to contribute to a reduction of 10 million tons of carbon dioxide emissions by 2030. To achieve this goal, our company sees carbon credits as an effective means. Currently, we are providing carbon credits bundled with gas and electricity, delivering carbon-neutral energy to customers. Going forward, our company is also considering the standalone sale of carbon credits, expanding opportunities for more people to contribute to carbon neutrality. Figure 1: Image of our carbon credit offerings Interviews with customers revealed that the three key factors they look for in carbon credits are quality, variety, and price. Therefore, our company is considering handling high-quality, diverse, and affordable carbon credits (Figure 2). Figure 2: Example of a carbon credit portfolio The quality of carbon credits is crucial, as low-quality ones could harm the customer’s reputation. Therefore, we will continuously improve the generative AI-based quality evaluation system developed this time to provide customers with carbon credits they can purchase with confidence. 2. Screening of Carbon Credit Projects Using Generative AI Carbon credit projects are diverse, and their quality varies. Therefore, careful selection is necessary when considering investment. We conduct a detailed risk assessment by comparing with similar existing projects. This method allows us to selectively handle only high-quality credits. Figure 3: Example of carbon credit project screening As shown in Figure 3, by evaluating on the same axes as existing similar projects and visualizing the relative quality and risks, we believe it can lead to appropriate and unbiased screening. 3. Future Development Direction The focus of future development is on increasing diversity and improving accuracy. Carbon credit projects include a variety of types, such as nature-based, emission reduction, and CO2 removal. As new projects and rules are expected to emerge, we aim to develop a system that can flexibly adapt to them. We will also continue to work on improving the accuracy of the generative AI. While perfection is difficult, the goal is to get as close to 100% as possible. In this way, we will continue to develop a more accurate evaluation system while adapting to the ever-changing environment. 4. System Development Using AWS We have maximized the use of AWS services in developing this system. The scalable infrastructure and advanced generative AI services of AWS enable agile and flexible development. The AWS infrastructure services allow efficient system development and operation by flexibly adjusting resources according to the project scale. Additionally, AWS security features provide “assurance” for the carbon credit evaluation process, which handles highly confidential data. Furthermore, by leveraging the wealth of AWS services, the training and deployment of generative AI models can be done quickly, enabling development that responds to market needs. 5. Conclusion The carbon credit quality evaluation system developed by us is believed to play an important role in climate change mitigation. However, we do not intend to monopolize this technology, but rather to share it widely and utilize it in collaboration with many others. Climate change is a global issue that requires a rapid response. Therefore, we prioritize cooperation over competition, aiming to contribute to the sound development of the market as a whole through this technology. Improving the reliability and transparency of the carbon credit market is the key to maximizing its impact. We plan to further enhance the accuracy and reliability of this system through collaboration with others. By incorporating feedback from various industries and regions, a more fair and inclusive system can be built, contributing to the overall market benefit and accelerating climate change mitigation. Ultimately, we hope to make this system a common platform for climate change countermeasures. To this end, we will emphasize cooperation with others and aim for the healthy development of the carbon credit market. Time is of the essence in addressing climate change, so cooperation beyond a single company, across the industry and globally, is essential. We will contribute to the realization of a sustainable future through this initiative. Author Eiji Natsuaki Eiji Natsuaki Executive Officer and Head of Business Creation Division, Osaka Gas Co., Ltd. Eiji Natsuaki joined Osaka Gas Co., Ltd. in 1992 after completing his master’s course at Kyoto University Faculty of Engineering. He has served in positions such as General Manager of the Business Strategy Department in the Energy Business Division, General Manager of the Overseas Business Development Department in the Resources & International Business Division, and Head of the Innovation Headquarters. Since April 2024, he has held his current position as Head of the Business Creation Division, overseeing R&D, including Methanation technology, as well as new business development and M&A for the Daigas Group. This article was translated by AWS Professional Services Riho Matsui, and Solutions Architect Satoshi Aoyama.

もし組織の AWS 支出を管理していて、2024 re:Invent に時間を割いてAWS のコストと使用量のより良い管理方法や最適化に役立つソリューションについて学ぶ計画があれば、少し立ち止まってこのブログポストを読んでください。コスト配分、計画、コスト管理などのように一般的な Cloud Financial Management トピックに焦点を当てた様々なセッションやワークショップのラインナップを確認できます。これらのセッションを調べて、re:Invent 登録サイトの参加者ポータルから席を予約できます。もしくは、 AWS Event モバイルアプリから場所を確保できます。 ブレイクアウトセッション くつろいでこれらのプレゼンテーションを楽しみ、最新のソリューション機能強化や実用的なアプリケーションの最新情報を入手してください。AWS のエキスパートとゲストスピーカーが価値のあるインサイトと実際の事例を共有します。 COP203 | Control the cost of your generative AI services（生成 AI サービスのコスト管理） Wednesday (Dec.4) 11:30AM – 12:30PM PT | Mandalay Bay | Level 2 South | Ballroom L Alex Head, Sr. Manager OPTICS, AWS Adam Richter, Senior Optimization Solutions Architect, AWS Brent Segner, Distinguished Engineer | Director, Capital One COP218 | Best practices and new tools for cost reporting and estimation（コストのレポートと見積もりのベストプラクティスと新しいツール） Thursday (Dec.5) 12:30PM – 1:30PM PT | Venetian | Level 2 | Summit Showroom Bowen Wang, Principal Product Marketing Manager, AWS Matt Berk, Principal TAM, AWS Corey Quinn, Chief Cloud Economist, Duckbill Group COP204 | What’s new with AWS cost optimization（AWS コスト最適化の新機能） Thursday (Dec.5) 2:00PM – 3:00PM PT | Wynn | Convention Promenade | Latour 2 Letian Feng, Principal Product Manager-Tech, AWS Rick Ochs, Senior Manager of Cost Optimization, AWS チョークトークセッション AWS のスピーカーが冒頭で短い説明をし、議論の場を設けます。質問を投げかけたり、AWS のエキスパートや他のお客様と一緒にトピックを深く掘り下げましょう。 COP348 | Simplifying cost reporting with Amazon Q and Data Exports（Amazon Q と Data Exports によるコストレポートの簡易化） Monday (Dec.2) 3:00-4:00PM PT | MGM | Level 1 | 105 Liam Greenamyre, Senior Product Manager, AWS Zach Erdman, Senior Product Manager, AWS COP217 | Cost allocation strategies to improve accountability（アカウンタビリティー向上のためのコスト配分戦略） Tuesday (Dec.3) 12:00-1:00PM PT | Caesar’s Form | Level 1 | Academy 414 Marina Vitale, Senior Product Manager, Amazon Rich Roscoe, Senior Technical Account Manager, Amazon COP347| Proactive cost control strategies for AWS Workloads（AWS ワークロードのプロアクティブなコスト管理戦略） Tuesday (Dec.3) 1:30-2:30PM PT | MGM | Level 3 | 302 Repeat Thursday (Dec.5) 11:00AM – 12:00PM PT: MGM | Level 1 | Boulevard 158 Fredrik Tunvall, Senior Product Manager, AWS Shlomo Dubrowin, Sr Technical Account Manager COP212| Creating effective FinOps KPIs（効果的な FinOps KPI の作成） Thursday (Dec.5) 11:00-12:00PM PT | Wynn | Convention Promenade | Lafite 1 Repeat Thursday (Dec.5) 3:30-4:30PM PT | Caesars Forum | Level 1 | Academy 416 Marcelo Lucchesi, BRA Partner Migrations Program, AWS Tony Griffiths, Senior Technical Account Manager, AWS COP354 | Estimating your AWS costs using AWS Pricing Calculator（AWS Pricing Calculator を利用した AWS コスト見積もり方法） Thursday (Dec.5) 12:30PM-1:30PM PT |Wynn | Convention Promenade | Lafite 1 Jeremiah Myers, Senior Product Manager , AWS Meredith Holborn, Sr Technical Account Manager, AWS COP213 | Optimize savings through a tailored AWS purchase strategy（状況に合わせた AWS 購入戦略による節約最適化） Thursday (Dec.5), 2:00PM – 3:00 PM PT |Wynn | Convention Promenade | Lafite 1 Mary Nachimov, Senior Product Manager, AWS Wade Piehl, FinOps Success Manager, AWS コードトークセッション チョークトークに似ていますが、ユースケースを通じて説明する代わりに、スピーカーはデモコードサンプルを用いてライブで紹介します。実際のコードを見て、一般的なコスト分析の疑問を解決するためにどのように適用するのか学びましょう。 COP403 | Advanced analytics with AWS Cost and Usage Reports（AWS Cost and Usage Reports による高度な分析方法） Thursday (Dec.5), 11:00AM-12:00PM PT| Wynn | Convention Promenade | Margaux 1 Steph Gooch, Sr. Optimization SA Advocate, AWS Justin Marks, Sr. TAM, AWS ハンズオンワークショップとビルダーズセッション AWS のスピーカーが、課題に取り組むためのユースケースとツールを紹介します。インストラクションに従い、タスクを完了させ、各機能のさらなる理解を持ち帰ってください。 COP306| Elevate your cost allocation strategy with AWS Cost Categories (Builder’s session)（AWS Cost Categories を用いたコスト配分戦略の強化、ビルダーズセッション） Monday (Dec.2) 10:30-11:30AM PT | Mandalay Bay | Level 2 South | Surf E Repeat Thursday (Dec.5) 2:30-3:30PM PT | Mandalay Bay | Level 2 South | Surf E Savanna Jensen, Sr. FinOps Success Manager, AWS Shubir Kapoor, Principal Product Manager, AWS Scottie Enriquez, Senior Solutions Developer, Amazon Web Services Connor Murphy, Sr. FinOps Success Manager, Amazon Web Services Alok Verma, Principal PMT, Amazon Web Services COP410 | Advanced cost allocation for AWS containerized workloads (Workshop)（コンテナ化された AWS ワークロードの高度なコスト配分、ワークショップ） Tuesday (Dec.3) 12:30-2:30PM PT | Mandalay Bay | Level 2 South | Oceanside D Nataliya Godunok, Cloud Optimization Success Solutions Architect, AWS Chris Strzelczyk, Sr. Technical Account Manager, AWS COP309 | Visualize and optimize cloud cost efficiency (Workshop)（クラウドのコスト効率の可視化と最適化、ワークショップ） Tuesday (Dec.3) 4:30 – 6:30PM PT | Mandalay Bay |Lower Level North | South Pacific F Judith Lehner, Senior Technical Account Manager, AWS Yuriy Prykhodko, Principal Technologist | Head of Cloud Intelligence Dashboards, AWS FinOps Foundation のネットワーキングイベントに参加しましょう FinOps Foundation は今年の re:Invent で火曜日 (12/3) にいくつかの活動をスポンサーします。1日を通して、プロダクトのフィードバックセッション (11:00AM-12:30PM PT と 2:30-4:00PM PT)、ランチパネルディスカッション (1:00-2:30PM PT) や夜のレセプションパーティー (4:30-8:00PM PT) が開催されます。AWS CFM チームのプロダクトリードやエンジニアリングリード、FinOps Foundation チームや他の同じ意見を持つプロフェッショナルと RockHouse で会いましょう。 こちら から夜のネットワーキングレセプションに登録してください。また、日中( 火曜日 2024/12/3) のプロダクションディスカッショングループやパネルディスカッションへの参加に興味があれば、アカウントチームに連絡してください。 画像 1. FinOps Foundation social event at re:Invent Cloud Financial Management のブースで AWS のエキスパートに会いましょう AWS Village Expo Hall にある Cloud Financial Management ブースを訪れて、質問したり、ソリューションを探したり、限定プレゼントのために立ち寄ってください。Larry Im (Sr Solutions Architect, AWS)、Roy Wolman (Sr. Manager of Cost Reporting, AWS)、 Yin Lei (Sr. TAM, AWS) と Chris Geiger (Sr Solutions Architect, AWS) がお手伝いします。セッションのスピーカーも週を通して交代してブースにいます。 結論 このブログポストが 2024 re:Invet の CFM セッションのアジェンダ作成の参考になることを願っています。Vegas でお会いできるのを楽しみにしています。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Bowen Wang Bowen は AWS Billing and Cost Management services のプリンシパルプロダクトマーケティングマネージャーです。財務やビジネスのリーダーがクラウドの価値と Cloud Financial Management を最適化する方法をより理解できるようにすることに重点を置いています。以前のキャリアでは、テックスタートアップの中国市場参入を支援していました。

AWS re:Invent 2024 で皆様をお迎えできることを、私たちは大変楽しみにしています。このイベントは、12 月 2 日から 12 月 6 日までラスベガスで開催されます。AWS re:Invent では、世界中からクラウド愛好家が集まり、互いに協力し学び合う機会があります。AWS の専門家と会談したり、技術セッションに参加したり、コミュニティイベントを探索したりと、様々な経験ができます。 このブログでは、クラウドガバナンスとコンプライアンスに焦点を当てたセッションを紹介します。これらはクラウド運用における 2 つのソリューションの分野で、セキュリティ、運用、コンプライアンス、コスト基準を遵守しながら、組織がより迅速に動けるようにするものです。クラウドガバナンスとコンプライアンスにより、統制の効いたワークロードのプロビジョニングを加速し、動的な規制が適用される状況でも運用を行い、合併・買収を効率化し、開発者の生産性を向上させることができます。 AWS re:Invent では、様々な形式とレベルの学習セッションを提供しており、自分のペースで知識を広げ、スキルを向上させることができます。レベルはセッション ID で示されています。re:Invent のセッションタイプについては、 こちら をご覧ください。 お客様のクラウドガバナンスとコンプライアンスがどんなレベルにいるかによって変わるとは思いますが、いくつかの役立ちそうなセッションを紹介いたします。 著者のおすすめ クラウド環境のコントロールを設定することは、適切に設計されたクラウド基盤を作る上で重要なステップです。著者のおすすめは、COP342 の Chalk Talk です。これは、AWS サービスを活用して堅牢なセキュリティのコントロールを実現し、コンプライアンス目標を達成する方法についての洞察を提供します。ジャーニーのどの段階にいても、適切に設計され、強力なセキュリティ態勢を維持することが最優先事項です。これは、金融サービスやヘルスケアなど、私たちがサポートする高度に規制された業界の顧客と関わる際に重要です。この Chalk Talk では、AWS サービスを使用して環境全体にわたってポリシーを一元的に定義し、適用し、監視する方法について説明します。 COP342 | Top controls for a secure, well-architected environment – Chalk Talk タイトルの参考和訳「安全で適切に設計された環境に必要なコントロールとは」 あらゆる規模の組織は、リスクを軽減し、適切に設計された環境を運用するために堅牢なコントロールを実装する必要があります。ガバナンス、コンプライアンス、セキュリティの目標達成に役立つ推奨コントロールを見つけましょう。 AWS Organizations 、 AWS Control Tower 、 AWS Config 、 AWS Security Hub などの AWS サービスを活用して、環境全体にわたってポリシーを一元的に定義し、適用し、監視する方法を学びます。包括的なアクセスコントロールを確立し、設定ミスを防ぎ、セキュリティ態勢の可視性を獲得するための戦略を探ります。新たな脅威や変化するビジネス要件に対応しながら、環境の進化に合わせてコントロールを適応させる方法を理解します。 参加すべきその他のガバナンスとコンプライアンスのセッション COP326 | Unlocking business insights with AWS Config ft. Itaú Unibanco – Breakout Session タイトルの参考和訳「AWS Config を活用したビジネスインサイトの解放 ft. Itaú Unibanco」 AWS 上で複雑かつ多岐にわたる IT 環境を大規模に運用している組織は、何千もの個別のパイプライン、リソース、サービスから設定メタデータ、バージョニング、コンプライアンスを抽出するという課題に直面しています。 AWS Config をリソースメタデータのソースとして使用することで、顧客はアカウントと AWS リージョン全体でコンプライアンス監視、変更追跡、リソース関係の可視性を得ることができます。このセッションでは、Itaú Unibanco が AWS Config を活用して何千ものアカウントの何百万ものリソースのコスト非効率、停止の原因、旧バージョンの技術、コンプライアンスの問題を特定するためのメタデータ一元化を行った方法を紹介します。 COP327 | Accelerating auditing and compliance for generative AI on AWS – Breakout Session タイトルの参考和訳「AWS 上の生成 AI の監査とコンプライアンスの加速」 生成 AI はエキサイティングな新しいイノベーションをもたらしますが、一方で、責任ある使用とコンプライアンスに関する新たな課題が発生します。このセッションでは、 Amazon Bedrock とその他の関連サービスである、 Amazon Simple Storage Service (Amazon S3) 、 AWS Lambda 、 Amazon Virtual Private Cloud (Amazon VPC) に対して、コンプライアンスとガバナンスのベストプラクティスに従っていることを可視化する方法をどのように提供できるかを説明します。AWS Organizations、 AWS Audit Manager 、 AWS CloudTrail などの AWS ガバナンスおよびコンプライアンスサービスを探索し、これらのサービスが生成 AI インフラストラクチャを継続的に監査する際にどのように役立つかを学びます。これらのサービスが証跡の収集を自動化し、コンプライアンスと監査のニーズを満たす監査準備レポートを提供する方法を学びます。 COP383 | Achieving governance at scale – Breakout Session タイトルの参考和訳「スケールするガバナンスの実現」 企業がクラウド運用をスケールアップするにつれて、ポリシーと標準の一貫した適用を維持することがますます複雑になります。このブレイクアウトセッションでは、 AWS Control Tower 、 AWS Config 、 AWS Organizations の強力な機能を掘り下げ、大規模な状況でもガバナンスを実現する方法についての包括的な理解を参加者に提供します。 AWS サービスを統合してガバナンスプロセスを自動化し、インシデント対応を効率化し、 AWS 環境全体でセキュリティのベストプラクティスを適用する方法を学びます。また、顧客から AWS 上でのガバナンスのジャーニーについて話を聞くこともできます。 COP402 | Dive deep on AWS Cloud Governance – Breakout Session タイトルの参考和訳「AWS クラウドガバナンス Dive Deep」 組織が急速にクラウドコンピューティングを採用する中で、効果的なガバナンスはますます重要になっています。この Dive Deep セッションでは、 AWS 上で堅牢なクラウドガバナンスを実装するための高度な戦略と基盤となる AWS サービスを探ります。アカウント設計、セキュリティコントロール、監査レポート、自動化に焦点を当てて、環境にガバナンスを適用するための AWS サービスと戦略について学びます。 COP338 | Architecting AWS Accounts for Scale – Chalk Talk  タイトルの参考和訳「スケールに向けた AWS アカウントの設計」 このセッションでは、アカウント構成やドメインのコントロールに加え、AWS アカウント、AWS Organizations、AWS Control Tower を通じたセキュリティ境界の確立など、アカウント管理のベストプラクティスに焦点を当てます。これにより、ビジネスアプリケーションとデータをより簡単に管理し、コストを最適化しながら運用の優位性、セキュリティ、信頼性を達成できます。 COP343 | Best practices for cloud governance – Chalk Talk  タイトルの参考和訳「クラウドガバナンスのベストプラクティス」 企業のクラウド導入が進むにつれ、クラウドガバナンスがますます重要かつ複雑な課題として浮上してきています。クラウドの利用を始めたばかりの企業でも、すでに十分な経験を持つ企業でも、俊敏性と統制のトレードオフをナビゲートすることは困難な場合があります。この Chalk Talk では、 AWS の専門家が、権限管理、セキュアなワークロードのデプロイメント、ガバナンスの戦略を含む、効果的でスケーラブルなクラウドガバナンス基盤を構築するための戦略を共有します。 AWS や他の参加者と共に、クラウドを成功裏に採用した組織からの洞察を共有し学びましょう。 COP346 | Centralize audit data for hybrid and multicloud environments – Chalk Talk  タイトルの参考和訳「ハイブリッドおよびマルチクラウド環境の監査データの一元化」 顧客がクラウドへの移行を加速しビジネスを変革する中で、ハイブリッド環境で IT 運用を管理しなければならない状況に直面する場合があります。これはあなたにも当てはまりますか？この Chalk Talk では、 AWS CloudTrail Lake の有効化、過去の CloudTrail ログのインポート、パートナー統合、カスタムソリューション、多くの AWS リソースからの監査ログの集約方法をご紹介します。また、調査分析やセキュリティ目的でこのデータをクエリする方法についても説明します。 COP349 | Implement controls faster with generative AI – Chalk Talk タイトルの参考和訳「生成 AI を活用したコントロールの迅速な実装」 コンプライアンスの管理は面倒なプロセスですが、監査の準備には必要不可欠です。イノベーションのためのリソースを解放するために、 AWS Config や AWS CloudTrail などのサービスを Amazon Q と組み合わせて、カスタムコンプライアンスルールを迅速に構築できます。監査の時期が来たら、生成 AI を使用して CloudTrail の証跡や AWS Config での AWS リソースの現在の構成状態をクエリすることもできます。この Chalk Talk に参加して、 AWS 上の生成 AI がコンプライアンスと監査プロセスをより迅速かつ効率的にする方法を学びましょう。 COP405 | Coding for account customizations with AWS Control Tower – Code Talk  タイトルの参考和訳「AWS Control Tower を使用したアカウントのカスタマイズのコーディング」 ライブコーディングとインタラクティブなディスカッションを通じて、マルチアカウント AWS 環境全体にベースライン構成とアカウントのカスタマイズを大規模に適用する方法をデモンストレーションします。このセッションでは、いくつかの実際の例を深く掘り下げ、数百から数千にわたるアカウントを安全にカスタマイズする方法を探ります。さらに、Amazon Q が Instrastructure as Code を可能にし、カスタマイズを迅速に実装するのに役立つ方法もお見せします。 COP311 | Simplify and automate continuous compliance with AWS – Workshop タイトルの参考和訳「AWS を使用した継続的なコンプライアンスの簡素化と自動化」 このハンズオンワークショップに参加して、 AWS サービスを使用して AWS リージョンとアカウント全体で継続的な監査とコンプライアンスプロセスを効率化する方法を学びましょう。 AWS Config と AWS Systems Manager Explorer を使用して、複数のリージョンならびに複数のアカウントからコンプライアンスデータを集約し可視化します。 AWS Config 適合パックと AWS Systems Manager Automation ドキュメントを使用して、非準拠リソースの修復を自動化する方法を探ります。また、 AWS Config の生成 AI を活用した自然言語クエリ生成を使用して、 AWS リソース構成とコンプライアンスメタデータの調査と検索を簡素化する方法も学びます。参加にはラップトップを持参する必要があります。 まとめ このブログでは、参加をお勧めするいくつかのクラウドガバナンスとコンプライアンスセッションを紹介しました！これらのセッションでお会いできることを楽しみにしています。さらに質問がある場合や、より深く掘り下げたい場合は、ベネチアンの Expo にある AWS Village のクラウドガバナンスとコンプライアンスのキオスクにお立ち寄りください。セッションについて詳しく知りたい場合は、 re:Invent イベントセッションページ をご覧ください。 著者 Tiffany Chen Tiffany Chen は AWS の CSC チームのソリューションアーキテクトで、ヘルスケアとライフサイエンス業界にフォーカスしています。お客様のデプロイメントワークロードをサポートし、現在はエンタープライズの顧客と協力して、コスト最適化されたソリューションを構築しています。趣味は旅行、ガーデニング、お菓子作り、バスケットボール観戦です。 Winnie Chen Winnie Chen は AWS のソリューションアーキテクトで、金融サービス業界を中心にエンタープライズグリーンフィールドの顧客をサポートしています。AWS へのインフラ移行や構築を支援していて、趣味は旅行とハイキング、サイクリング、ロッククライミングなどのアウトドアです。 このブログの翻訳はソリューションアーキテクトの桂井が担当しました。原文は こちら です。

Penta Security は、 AWS のデータ暗号化パートナー であり、 27年間の顧客のサイバーセキュリティを担当した企業で、データセキュリティ、ウェブセキュリティ、認証セキュリティの領域で安全なクラウド環境を提供しています。 韓国のデータセキュリティ市場で 15 年間シェア 1 位を守り続けている D’Amo は、グローバル CC 認証および韓国国家情報院の認証を受けた暗号化モジュールを通じて、顧客の重要データを安全に保護し、国内外のプライバシー関連コンプライアンスをすべて遵守しています。 D’Amo は、強力なデータ暗号化技術に基づき、次の機能を提供します。 顧客のビジネス環境に最適化された全システムレイヤーでの暗号化サービスを提供 韓国国家情報院認証の暗号化モジュールを使用した安全な暗号化アルゴリズムの提供 カラム単位の暗号化と DB アクセス制御機能の提供 クラウド環境専用の鍵管理システム D’Amo KMS を用いた暗号鍵、外部鍵、Oracle TDE 鍵など、企業全体の暗号鍵管理 統合された集中管理システム D’Amo Control Center によるインフラ内の暗号化製品とサーバー管理のサポート Amazon RDS Custom での D’Amo による暗号化・復号環境の構築 Amazon RDS Custom は Oracle と Microsoft SQL Server エンジンをサポートしています。 Amazon RDS Custom は、Amazon RDS が提供しているスナップショットやバックアップ、リカバリ機能、パッチ適用サポート、データベースのモニタリング、ログ管理など多くの管理機能を提供します。さらに、SYSDBA および OS レベルのアクセスが可能なため、これまでの Amazon RDS では対応できなかった暗号化ソリューションの導入や、パッケージアプリケーション（例えば、ERP、MES、SCM、HRなど）のデータベースとしても利用できます。 また、Amazon RDS for Oracle がサポートしていない Oracle 12c などのバージョンも利用でき、Oracle RMAN や Data Guard、DB Vault、Flashback といった機能やサードパーティ製ソリューションもインストールして使用することが可能です。 通常の Amazon RDS インスタンスでは OS および SYSDBA へのアクセスができないため、商用データベースセキュリティソリューションの構築が難しい状況でした。しかし、Amazon RDS Custom インスタンスであれば、OS と SYSDBA へのアクセスが可能なため、D’Amo を利用して安全な暗号化・復号環境を構築することができます。 図1 – DB 暗号化ソリューションの観点からの Amazon RDS とAmazon RDS カスタムアーキテクチャの比較 Penta Security は、Amazon RDS Custom インスタンス上で D’Amo が正常に動作することを確認するため、以下の項目について検証を行いました。 D’Amo テスト環境 OS: Oracle Linux DBMS: Oracle Database 19c、12c (64 bit) D’Amo 機能検証リスト 主な検証機能 暗号化ポリシーの管理機能：管理ツールで設定した暗号化ポリシーの正常動作確認 VTI (View/Trigger Interface) モードでカラムの暗号化・復号：管理ツールによるVTI暗号化作業の正常動作確認 API モードでカラムの暗号化・復号：管理ツールによる API 暗号化作業の正常動作確認 図 2 – 暗号化ポリシー管理、VTI 及び API 暗号化・複合の正常動作結果画面 カラムアクセス制御：管理ツールで設定した対象カラムへのアクセス許可・遮断が正常に動作することの確認 ポリシーアクセス制御：管理ツールで設定した対象ポリシーへのアクセス許可・遮断が正常に動作することの確認 暗号化・復号権限制御：管理ツールで設定した権限による暗号化・復号の許可・遮断が正常に動作することの確認 図3 – 暗号化・復号の権限、カラムおよびポリシーへのアクセス制御の正常動作結果画面 追加の動作確認 DB キー管理、カラムインデックスの設定、ストレージ設定などの DBMS 管理機能の正常動作確認 Penta Security は、Amazon RDS Custom 環境で 79 の検証項目が正常に動作することを確認し、D’Amo の Amazon RDS Custom 環境での正式サポートを発表しました。 Amazon RDS Custom での D’Amo の暗号化タイプ D’Amo は、Amazon RDS Custom インスタンスを使用しているお客様向けに、D’Amo DA と DP の両製品を提供しており、企業環境に最適な暗号化方式を選択できます。 D’Amo DA（DBMS Application 暗号化）：D’Amo DA は、DBMS の内部に暗号化・復号 API をインストールして暗号化を行う製品で、DB サーバーの負荷を最小限に抑えて運用できる点が特徴です。また、暗号化対象のテーブル名やカラム名を変更せずに暗号化環境を構築できます。 D’Amo DP（DBMS Pakage 暗号化）：D’Amo DP は、DBMS に暗号化パッケージをインストールして暗号化を行う製品でカラム単位の暗号化、アクセス制御、権限制御など多様な管理機能を提供します。アプリケーションと独立した暗号化方式として動作するため、クエリやコードの変更を最小限に抑えて構築することが可能です。 D’Amo を構築するお客様のための多様なサポート特典 D’Amo は、オンプレミス環境で暗号化を適用していたお客様が Amazon RDS Custom に切り替える際に、既存の RDB 構造を維持します。また、検証済みの暗号モジュールを通じて、アプリケーションを変更せずにお客様のビジネス環境に合わせた暗号化を提供します。なお、Amazon RDS Custom でサポートされている Oracle や Microsoft SQL Server のすべてのバージョンに 100％ 対応しています。 さらに、Penta Security は AWS の公式 ISV パートナーとして、D’Amo を活用するお客様に向けて、さまざまな特典を提供しています。 AWS PoC サポート：既存のインフラストラクチャから AWS への移行や、クラウド環境に不慣れなお客様に対し、カウンセリングおよび技術サポートを提供します。 AWS クレジットの提供：D’Amo のインストールや内部テストのための AWS クレジットを提供することでコスト負担を軽減し、企業のデータベース環境に最適な暗号化ソリューションを構築できます。 トレーニングサポート：クラウドおよびデータ暗号化担当者のデジタルスキル向上のための個別トレーニングをサポートします。 今後、Penta Security は AWS と継続的に協力し、Amazon RDS Custom サービスに合わせたさまざまな機能や特典を拡充していきます。PoC サポート、クレジット提供、トレーニングサポートの詳細については、AWS の担当営業チームまたは Penta Security 営業チーム（cloudbiz@pentasecurity.com）までお問い合わせください。 サマリー 既存のオンプレミス（レガシー）環境やカスタム環境の制約により Amazon RDS の利用が難しかったお客様は、Amazon RDS Custom を活用することで、Amazon RDS の便利な管理機能を利用できます。 Amazon RDS Custom 環境で信頼性が証明されている Penta Security の D’Amo は、企業の重要な情報を安全に保護し、国内外のプライバシーに関するコンプライアンス要件をすべて満たすことができます。 Penta Security の D’Amo を導入する際には、AWS の公式 PoC サポートやテスト用クレジットの提供、トレーニングサポートなど、さまざまな支援を受けることが可能です。 D’Amo の詳細については、 Penta Security の Web サイト を参照してください。 翻訳はソリューションアーキテクト鄭宇鎭（ジョン ウジン）が担当しました。原文は こちら です。

2024年11月1日に、「コンテナ/サーバーレスによるモダン・プロジェクト実践」と題して 3社にご講演いただきました。 コンテナやサーバーレスを利用することで、従来とは異なるランニングコストの構造に移行し、迅速な対応・変更で利用者/お客様のニーズに迅速に対応できるようになります。それを実際にプロジェクトで実践されているお客様のそのままの声をお伝えし、選択のポイントや勘所を理解する機会として、特に従来型の慣れた手法からまだ抜け出せない方・組織の後押しとなるヒントとなるべく、本セミナーは企画されました。 今回は 3社 それぞれ異なる領域のシステムでの経験談をご紹介いただきました。 貴重な実体験をご紹介いただいたのは以下のお客様です。 保険Web申込サービスの顧客体験価値向上のため、4週間ごとの改善リリースを実現 はなさく生命保険株式会社様 Step Functionsで決裁を回そう -内製ワークフロー・チケットシステムの紹介- クックパッド株式会社様 SQSを用いたクレジットカード決済の非同期化 株式会社ZOZO様 各セッションの内容について 保険Web申込サービスの顧客体験価値向上のため、4週間ごとの改善リリースを実現 はなさく生命保険株式会社 / CS戦略部 課長　渡邉 佑亮 様 はなさく生命保険様からは、Web申込サービスのローンチ（2021/09）に際して、どのような思考、優先度でプロジェクトが発足したのか、どのような体制で進められたのかが紹介されました。不確実な新規ビジネスに対し、SIパートナー（開発ベンダー）との共創型のアジャイル開発体制をとることで変化対応力を確保したこと、「当たり前に動く」ことが前提の金融サービスを安定的に支える仕組みとして選択されたアーキテクチャや技術方式についてのご説明がありました。IT システムの開発・運用を開発パートナー企業とともに実施されている企業は日本には多く存在します。モダンな開発スタイルへのチャレンジには、技術的な観点だけではなく、開発パートナー企業とどのように座組みすると良いのかという観点において、参考になる内容が含まれていたように感じました。また、視聴者から、サーバーレス型による運用のため、費用の変動による予算とのブレをどうお考えかという質問がありましたが、そもそも新規のプロジェクトであり、どのくらいアクセスがあるかは不透明だったので、厳密な予算管理を行うことが困難だった。サービスローンチ後は月次でシステム稼働状況と費用の確認を行っているが、オンプレ運用費用との比較においても適性水準であると判断しているとのコメントがありました。これは、サーバーレス型ではよく聞かれる質問の一つですが、実際のお客様の判断が伺えたのは良い機会でした。 資料は こちら です。 Step Functionsで決裁を回そう -内製ワークフロー・チケットシステムの紹介- クックパッド株式会社 / Software Engineer　Shota Nagasaki 様 Head of Corporate Engineering and Security　Sorah Fukumori 様 クックパッド様からは、AWSサーバーレスおよびコンテナサービスをフレームワークとして利用したカスタムの決裁ワークフローのシステム（Fryegg）を構築・展開し、元々お持ちのワークフローシステムから移行された事例をご紹介いただきました。ここでキーとなるAWSサービスが Step Functions です。条件分岐などはもちろん、上長の承認を待つ待機処理や何かシステム上の問題で処理が途中でエラーになってしまった際の再開処理など、ワークフローに求められる機能の大部分が Step Functions の近年の機能アップデートでカバーされ、それが後押しになったとのこと。日本企業の決裁や承認処理は特殊で、多くの場合、企業ごとにカスタマイズが必要、とよく言われますが、複数のシステムや組織をまたがるワークフローをサーバーレス型で実装できれば、ランニングコストの改善への影響は大きいです。しかし、主要メンバー2名で、4ヶ月でやり切るのはすごい。 資料は こちら です。将来的には、この Fryegg をOSSとして公開するビジョンもあるとのことで、個人的にも期待したいです! SQSを用いたクレジットカード決済の非同期化 株式会社ZOZO / EC基盤開発本部 SRE部 カート決済SREブロック　金田 卓巳 様 EC基盤開発本部 カート決済部 カート決済基盤ブロック　林 友貴 様 ZOZOTOWN の、特にセールスキャンペーン時の終了時間直前の決済処理のスパイクに対し、将来のサービス成長を考慮してどう対処すべきなのか、それに対する現時点での対応策がご紹介されました。最終的に SQS を挟んだ非同期型の連携構成までの具体的な検討のポイント・思考フローでは、決済処理という重要機能に対する判断と利用者の利便性を両立させようとする考慮が見えました。負荷の高い部分の処理における非同期アーキテクチャの効果を技術的には理解できても、特に決済に関する処理となると心理的になかなか踏み込みにくいものです。しかし、ZOZOTOWNという日本でも有数のサービスのカード決済部分で実現し、効果があるという話は大きな説得力があります。また、その負荷テストのために使用した EKS上のシステムの紹介も、負荷テストにおけるコンテナ活用の良い一例となりました。 資料は こちら です。なお、負荷テストとしてEKS上で稼働させたツールは こちら であるのことでした。 まとめ 顧客フロントのサイトやカード決済のような業務でも、コンテナやサーバーレス型のサービスを使うことはもう珍しいことではありません。運用の工数を省力化し、その分、機能拡張や改善リリースのサイクルを回す方に力を注ぐことができます。一方、モダンなアーキテクチャの活用の前に、まだ既存の従来型システムが足枷になって、という方が多いのも事実です。全部を一気には変えられませんし、全てを変える必要があるかどうかも疑問です。せめて、新しいプロジェクトでモダンな方式で進めてみて、その体験を実感してから今後の方針を決めるのでも十分良いスタートです。実際、先人の企業の多くは、こうしたアプローチをとった結果、その領域を拡大して今に至っているのです。一歩を進み始めないとその先はありません。 なお、コンテナやサーバーレスをあらためて理解したい方には、自習型の以下のワークショップがあります。ご自分のペースで進めながら来たる次のプロジェクトに備えてはいかがでしょうか。 ECS、EKS を学びたい ECS Workshop Introduction to EKS ひとまずコンテナ化してみる! App2Container サーバーレスをこれから始めるなら… サーバーレス自己学習ガイド サーバーレスの勉強方法を聞いてみた サーバーレス/クラウドネイティブ系 実践力を鍛えるBootcamp – クラウドネイティブ編 サーバーレス事業開発 杉

本ブログは 2024 年 11 月 11 日に公開されたBlog “ Maximize your cloud security experience at AWS re:Invent 2024: A comprehensive guide to security sessions ” を翻訳したものです。 AWS re:Invent 2024 は、12 月 2 日から 6 日までラスベガスで開催され、最新のセキュリティイノベーションを学びたいセキュリティの専門家、クラウドアーキテクト、コンプライアンスリーダーにとって有益なセッションが満載です。今年のイベントでは、ゼロトラスト、生成 AI を活用したセキュリティ、アイデンティティとアクセス管理 (IAM)、DevSecOps、ネットワークとインフラストラクチャセキュリティ、データ保護、脅威検出とインシデント対応のベストプラクティスに焦点を当てています。このイベントは、クラウドセキュリティの専門家にとって、貴重な学習とネットワーキングの機会をご提供します。 re:Invent 2024 の豊富なセッションを効果的に活用し、学習効果を最大限に高めるため、 必見のセキュリティセッション のリストを厳選しました。ぜひ 今すぐご登録 いただき、ラスベガスでお会いしましょう！ 基調講演とイノベーショントーク AWS re:Invent 2024 の 基調講演 と イノベーショントーク は、AWS のシニアリーダーから直接、革新的な洞察を得る機会となります。これらのセッションでは、生成 AI、クラウドセキュリティ、そしてアプリケーション開発と AWS クラウドの未来に新たな方向性を示す革新的なアーキテクチャにおける最新のブレークスルーを深く掘り下げます。 KEY002 – CEO Keynote with Matt Garman (Matt Garman による CEO 基調講演) 。基幹サービスの刷新から新しい体験の創造まで、AWS がクラウド全体でどのようにイノベーションを起こし、お客様とパートナーが安全で豊かな未来を構築できるようにしているかをご覧ください。 SEC203-INT – Security insights and innovation from AWS with Chris Betz (Chris Betz による AWS のセキュリティに関する洞察とイノベーション) 。 AWS の CISO である Chris Betz が、セキュリティを統合・自動化し、チームが重要な取り組みに集中できるようにする変革的な戦略を明らかにする中で、革新的なセキュリティ技術と生成 AI が、組織のセキュアなイノベーションの加速をどのように支援するかをご覧ください。 イノベーショントーク の全リストをご確認ください。今年、現地に参加されない方も、基調講演とイノベーショントークはライブ配信でご視聴いただけます。 セッション セッションタイトルのリンクを選択するとセッション情報と時間場所を確認できます。セッションを予約し、AWS re:Invent のお客様のアジェンダにセッションの追加もできます。 高度なアクセス分析による最小権限の実現の加速 攻撃対象範囲を最小限に抑え、ゼロトラストアーキテクチャを実現するために、アイデンティティ管理とアクセス制御のベストプラクティスを学びます。 (訳者注: チョークトーク（Chalk talk）は、少人数の参加者を対象とした 1 時間の双方向性の高いセッションです。特定のトピックを深く掘り下げ、AWS のエキスパートと直接対話し、その場で質問できることもあります。) SEC325 | チョークトーク | A least privilege journey made easier by IAM Access Analyzer (IAM Access Analyzer による最小権限への容易な移行) : 集中管理をしているセキュリティチームと IAM ポリシー作成者が、 IAM Access Analyzer を使用して、未使用や過剰な権限を可視化し、実用的な推奨事項を活用してスケーラブルな最小権限を実現する方法を学びます。 SEC337 | チョークトーク | Scaling IAM: advanced administration and delegation patterns (IAM のスケーリング: 高度な管理と委任パターン) : 組織の拡大に伴うセキュリティと俊敏性のバランスを取りながら、効果的なアクセス管理のための革新的な戦略をご覧ください。実際のシナリオ、ベストプラクティス、最先端のテクニックから、スケーラビリティ、パフォーマンス、将来の成長のための IAM インフラストラクチャの最適化方法を学びます。 SEC202 | ビルダーズセッション | API Authorization with Amazon Cognito and Verified Permissions (Amazon Cognito と Verified Permissions による API 認可) : このセッションでは、AWS 上のマイクロサービスベースのアーキテクチャにおけるモダンな認可について実践的な経験を得られます。 Amazon Cognito による認証の外部化とカスタマイズ、 Amazon Verified Permissions を使用したポリシーベースのアクセス制御による詳細な認可の適用、 Amazon API Gateway で保護された API との統合方法を学びます。参加にはラップトップの持参が必要です。 SEC334 | チョークトーク | Building zero trust architectures with AWS practical guidance (AWS による実践的なゼロトラストアーキテクチャの構築ガイダンス) : このチョークトークでは、AWS サービスを使用したゼロトラストネットワークアーキテクチャの構築について詳しく説明します。ゼロトラストの観点から、ユーザーからアプリケーション、アプリケーション間、その他のアクセスシナリオをセキュアにする方法を学びます。 SEC232 | ブレイクアウトセッション | Secure by design: Enhancing the posture of root with central control (セキュアバイデザイン: 中央管理によるルートのセキュリティポスチャの強化) : このセッションでは、集中管理とガバナンスを維持しながら、AWS 環境全体でルートアクセスを安全に管理する方法を説明します。さらに、多要素認証 (MFA) を実施し、業界の取り組みと連携し、環境を安全に保つための AWS が提供する最新のツールと取り組みについて説明します。 脅威検出とインシデント対応によるセキュリティポスチャの強化 AWS のセキュリティサービスを使用して、セキュリティリスクを継続的に特定し優先順位付けすることで、セキュリティポスチャを強化し、セキュリティ運用を効率化できます。 (訳者注: コードトーク（code talk）は、ソリューションの構築に使用される実際のコードを詳しく見ていき、参加者がアプローチの「理由」を理解し、エラーも含めた開発プロセスを観察できます。参加者は質問をしたり、実際に手を動かしながら学んだりすることが推奨され、より深い実践的な学習体験を得ることができます。) SEC321 | ブレイクアウトセッション | Innovations in AWS detection and response (AWS の検出と対応におけるイノベーション) : このセッションでは、脅威の検出、ワークロードとデータの保護、自動化された継続的な脆弱性管理、一元化されたモニタリング、継続的なクラウドセキュリティポスチャ管理、統合されたセキュリティデータ管理、調査と対応、生成 AI などの実践的なユースケースに焦点を当てます。AWS の検出および対応サービスをシームレスに統合して、ワークロードを大規模に保護し、セキュリティポスチャを強化し、AWS 環境全体でセキュリティ運用を効率化する方法について、より深く理解することができます。 SEC332 | チョークトーク | Anatomy of a ransomware event targeting data within AWS (AWS 上のデータを標的としたランサムウェアイベントの分析) : このチョークトークでは、AWS 上のお客様環境のデータを標的としたランサムウェアイベントの検出、対応、復旧について解説します。環境内のランサムウェアイベントから保護するために使用できる AWS のサービスと機能、およびランサムウェアイベントが発生した場合の調査方法について、より深い理解を得ることができます。 SEC301 | ワークショップ | Threat detection and response using AWS security services (AWS セキュリティサービスを使用した脅威検出と対応) : このワークショップでは、さまざまなリソースと動作にわたる複数のセキュリティイベントをシミュレートします。提供されたサンドボックス環境で、シミュレートされたイベントから得られた検出結果を確認し、対応する実践的な体験ができます。参加にはラップトップの持参が必要です。 SEC219 | ブレイクアウトセッション | Uncovering sophisticated cloud threats with Amazon GuardDuty (Amazon GuardDuty による高度なクラウドの脅威の発見) : Amazon GuardDuty が AWS 環境全体にわたるエンドツーエンドの可視性を提供する、フルマネージド型の脅威検出を実現する方法について学びます。GuardDuty の独自の検出機能は、クラウドの脅威状況に対する AWS の可視性に基づいており、対応者がより迅速に問題に対処し、修復までの平均時間 (MTTR) を最小限に抑え、セキュリティリソースを最適化するのに役立ちます。これにより、チームはセキュリティリスクへの対応に追われる時間を減らし、より多くの時間をイノベーションに費やすことができます。 SEC343 | チョークトーク | Identify a prioritization strategy for security response & remediation (セキュリティ対応と修復のための優先順位付け戦略の見極め) : このチョークトークでは、アカウントのセキュリティ検出結果への対応と修復を自動化するためのフレームワークについて学びます。 AWS Security Hub を基盤として、どの検出結果を自動修復できるか、自動修復アプローチの影響、そして迅速かつ徹底的な対応を実現する方法について検討します。 SEC401 | コードトーク | Inspect and secure your application with generative AI (生成 AI を使用したアプリケーションの検査とセキュリティ確保) : 生成 AI を使用してアプリケーションのセキュリティを向上させる方法を詳しく見ていきます。AI を活用したツールがセキュリティ問題を迅速に特定し、修復を推奨する方法について学びます。 Amazon Inspector がアプリケーションのソフトウェアとコードの脆弱性を検出する方法について学び、統合開発環境 (IDE) で生成 AI を使用してセキュリティ上の問題をスキャンし修復する方法をご確認ください。 新たな脅威に対するエッジの保護 AWS エッジセキュリティサービスを使用して、アプリケーションに対する分散型サービス妨害 (DDoS) 攻撃や脆弱性攻撃から保護し、より一貫性のあるセキュリティポスチャを実現します。 SEC322 | ブレイクアウトセッション | Reduce your risk exposure with least privilege egress controls (最小権限のアウトバウンド通信制御によるリスクの低減) : このセッションでは、アウトバウンド通信制御戦略を最小権限の原則に合わせる方法を学びます。 AWS Network Firewall 、 Amazon Route 53 Resolver DNS Firewall 、その他のセキュリティサービスの最新リリースが、様々なリスクを低減するのにどのように役立つかを学びます。実装を簡素化し、ユースケースに特化したルールの推奨事項を紹介します。セキュリティポリシーが意図したニーズを満たしているという確信を得ることができます。 SEC344 | チョークトーク | Lessons learned from DDoS mitigation (DDoS 対処から学んだ教訓) : AWS Shield Response Team (AWS SRT) の重大インシデントからの洞察：このチョークトークでは、過去の DDoS イベントを掘り下げ、AWS SRT がセキュリティインシデントをどのように対処したかを解説します。この種の侵入に関する洞察を得て、アプリケーションをより DDoS 耐性の高いものにするための緩和戦略を学びます。 SEC327 | チョークトーク | Building secure network designs for generative AI applications (生成 AI アプリケーションのためのセキュアなネットワーク設計戦略の構築) : このチョークトークでは、AWS 上で生成 AI アプリケーションをセキュアに加速し、問題をより迅速に保護、検出、対応するための階層化されたネットワークセキュリティ制御の構築方法を学びます。多層的な防御のネットワーク設計目標を達成するための主要な考慮事項、ベストプラクティス、リファレンスアーキテクチャをご確認ください。 SEC304 | ワークショップ | Mitigate zero-day events and ransomware risks with VPC egress controls (VPC アウトバウンド制御によるゼロデイイベントとランサムウェアリスクの軽減) : このネットワークセキュリティワークショップでは、ソフトウェアサプライチェーンの依存関係、ゼロデイイベント、暗号通貨マイニング、ランサムウェアからのリスクを軽減するための AWS アウトバウンド制御のベストプラクティスの実装方法を学びます。参加にはラップトップの持参が必要です。 SEC317 | ブレイクアウトセッション | How Amazon threat intelligence helps protect your infrastructure (Amazon が脅威インテリジェンスをお客様のインフラストラクチャ保護に役立ててる方法) : AWS の脅威インテリジェンス機能を理解し、 AWS WAF 、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall などのセキュリティサービスにおいて、マネージドファイアウォールルールとセキュリティ検出結果をどのように強化しているかを学びます。AWS が AWS インフラストラクチャの保護し、新しいセキュリティ機能を開発し、お客様の AWS 上のアプリケーション保護の強化に使用している脅威インテリジェンスについて学びます。 生成 AI 時代における機密データの保護 最新の AI テクノロジーを実装する際に、データの機密性とプライバシーを保護するのに役立つ高度なテクニックと AWS サービスをご紹介します。 SEC323 | ブレイクアウトセッション | The AWS approach to secure generative AI (生成 AI に対する AWS のセキュリティアプローチ) : このセッションでは、AWS が生成 AI スタックの 3 つのレイヤー (インフラストラクチャのボトム層、モデルやツールへのアクセスを提供するミドル層、大規模言語モデル (LLM) やその他の基盤モデル (FM) を活用して作業を効率化するアプリケーションを含むトップ層) にわたるセキュリティをどのように考えているかについて学びます。 SEC310 | ワークショップ | Persona-based access to data for generative AI applications (生成 AI アプリケーションにおけるユーザーの役割に基づいたデータアクセス) : このワークショップでは、組織内の様々なユーザーロールに合わせて調整されたチャットボットアプリケーションによるドキュメントアクセスを管理します。アクセス権限を職務に合わせることで、セキュアな情報配信に関する課題に対処し、効率性とコンプライアンスを向上させる方法を学びます。参加にはラップトップの持参が必要です。 SEC336 | チョークトーク | Security and compliance considerations using Amazon Q Business (Amazon Q Business を使用する際のセキュリティとコンプライアンスの考慮事項) : このチョークトークでは、 Amazon Q Business アプリケーションのセキュリティ確保のためのベストプラクティスについて、アクセスコントロール、データ保護、コンプライアンスの考慮事項を含めて説明します。 生成 AI に焦点を当てたセッションについては、 こちらのブログ もご覧ください。 セキュリティを重視するカルチャーで開発者を支援する DevSecOps の実践にセキュリティをシームレスに統合し、市場への投入時間を短縮してリスクを軽減します。 SEC216 | ブレイクアウトセッション | Build trust in your CI/CD pipeline (CI/CD パイプラインにおける信頼の構築) : スケーラブルなコンテナセキュリティのコード化: このセッションでは、スケーラブルなコンテナのセキュリティとコンプライアンスを自動化する方法を学びます。 Amazon Q Developer 、Amazon Inspector、 Amazon Elastic Compute Cloud (Amazon EC2) Image Builder がどのように連携して、セキュアなコンテナイメージの作成とその Amazon Elastic Container Registry (Amazon ECR) への保存を自動化するのかを探ります。セキュリティを損なうことなく、開発者をサポートし、迅速な開発を可能にする方法を習得することができます。 SEC217 | ブレイクアウトセッション | Building a resilient and effective culture of security (レジリエントで効果的なセキュリティのカルチャーの醸成) : このセッションでは、リーダーシップからのサポート獲得、セキュリティオーナーシップの共有、心理的安全性の定着による信頼、透明性、そしてプロアクティブなセキュリティファーストのマインドセットの構築など、レジリエントで力強いセキュリティのカルチャーの醸成についてのガイダンスを提供します。 SEC218 | ブレイクアウトセッション | Emotionally intelligent security leadership to drive business impact (ビジネスインパクトを生み出す感情知性を備えたセキュリティリーダーシップ) : リーダーシップを向上させ、セキュリティニーズと戦略的なビジネス成果を一致させ、インパクトのある変革を先導し、持続可能なセキュリティのカルチャーを醸成する方法を学びます。AWS とお客様がどのように共感を持ってセキュリティをリードし、セキュリティの目的を結果に変換し、イノベーションを促進し、ポジティブなエスカレーションカルチャーを改善するための関係を育むかについての内部からの視点をご紹介します。的確なリーダーシップを発揮し、セキュリティ目標を意味のあるビジネスインパクトに結びつける技術を習得し、セキュリティが成功とレジリエンスの触媒となる未来へ組織を導く力を身につけることができます。 SEC314 | コードトーク | Accelerate your DevOps pipeline and remain secure with policy as code (policy as code で DevOps パイプラインを加速させながらセキュリティを維持) : このコードトークでは、オープンソースの汎用 policy as code 評価ツールである AWS CloudFormation Guard を使用して、AWS インフラストラクチャのコンプライアンスルールを定義し評価する方法を学びます。既存のデプロイメントパイプラインに自動化されたポリシー検証をシームレスに統合し、DevOps エンジニアが CI/CD パイプラインにポリシー評価ステップを組み込めるようにする方法を学びます。セキュリティ評価者は、堅牢なセキュリティポスチャを維持しながら、合理化されたレビュープロセスを体験できます。 SEC302 | ブレイクアウトセッション | Better together: Protecting data through culture and technology (より良い協力関係: カルチャーとテクノロジーを通じたデータ保護) : このセッションでは、AWS で利用可能なデータ保護機能の全範囲と、ベストプラクティスとカルチャーがこれらの機能を補完してセキュリティ成果を向上させる方法について考察します。組織がすべてのレイヤーにセキュリティを一貫して組み込むことで、データを保護しセキュリティのカルチャーを強化する方法について、多層防御の観点から詳しく学ぶことができます。 Expo の概要 クラウドセキュリティについて AWS のエキスパートと直接話したいですか？ Expo 会場 のセキュリティアクティベーションエリアで、AWS のセキュリティエキスパートと 1 対 1 で会話できるこの機会をお見逃しなく。組織のセキュリティポスチャを強化するお手伝いをします。 以下のような主要なセキュリティ領域について詳しく説明します 検出と対応: 大規模なワークロードを保護するために、セキュリティリスクの検出と対応のテクニックを探ります。 ネットワークとインフラストラクチャのセキュリティ: AWS サービスを使用して、安全なグローバルネットワークを構築および管理する方法を学びます。 アプリケーションセキュリティ: セキュアなソフトウェアを提供し、アプリケーションセキュリティの課題に対処するための戦略を探ります。 アイデンティティとアクセス管理: 最新のクラウドネイティブなアイデンティティソリューションを採用し、最小権限のアクセス制御を適用します。 デジタル主権とデータ保護: データの制御を維持し、AWS クラウドでデータをセキュアに保護し管理する方法を選択できます。 楽しみはまだまだこれから！ 革新的な洞察と深い学習に満ちた刺激的な 1 週間の後、世界的に有名な re:Play パーティー にご参加ください。これは re:Invent のフィナーレを飾るパーティーです！ヘッドライナーアーティストによるライブエンターテイメント、絶品の料理、たっぷりの飲み物に囲まれながら、リラックスし、交流を深め、無限の可能性に満ちた未来に乾杯しましょう。 今すぐ登録 re:Invent 2024 は素晴らしいイベントになることは間違いありません。みなさまにお会いできることを楽しみにしています！ 今すぐ登録 して、参加枠を確保してください。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Apurva More Apurva は AWS セキュリティ、ID、およびコンプライアンスチームのメンバーで、スタートアップから大企業まで、グローバルなプロダクトマーケティングで 13 年の経験を持っています。市場ポジショニング、競合分析、顧客インサイトのエキスパートとして知られ、ターゲット層に響き収益成長を促進する製品を立ち上げてきました。また、製品ビジョンと市場ニーズ、ビジネス目標を連携させるため、部門を超えた協力を行っています。 Justin Criswell Justin は AWS のセキュリティソリューションアーキテクチャのシニアマネージャーです。クラウドセキュリティとカスタマーサクセスを専門とする 12 年を含む、20 年にわたる技術 expertise を持っています。企業の AWS ユーザーがセキュリティサービスを導入・運用し、可視性を高め、リスクを低減し、AWS クラウドでのセキュリティポスチャを強化するために、スペシャリストチームを率いています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この記事は、“ Orchestrating Clinical Generative AI Workflows Using AWS Step Functions ” を翻訳したものです。 医療分野の急速な進化に伴い、生成 AI を活用することで、患者ケアを革新し、臨床プロセスを合理化する可能性があります。しかし、HIPAA などの規制に準拠しながら、データのセキュリティを確保しつつ、これらの複雑なワークフローを調整することは難しい課題です。一般的なパターンは、ソースデータから始め、生成 AI モデルを選択し、プロンプトを使用して各データレコードに対して特定のタスクを実行することです。このブログ記事では、 AWS Step Functions と他の AWS サービスを組み合わせて、セキュアで拡張性と柔軟性に優れた、臨床生成 AI ワークフローのオーケストレーションソリューションを構築する方法を探ります。 ユースケース例 図 1: アーキテクチャ図 この設計を実証するため、私たちは AWS HealthLake 、 Amazon Bedrock などの生成 AI サービス、および他の AWS コンポーネントを組み合わせて、臨床ノートを要約するヘルスケア特化ソリューションを構築しました。簡単なデプロイと管理のために AWS Cloud Development Kit (CDK) を使用して構築されたこのソリューションは、 GenAIWorkflow と呼ばれる AWS Step Functions ステートマシンによってオーケストレーションされています。以下で、このワークフローの各ステップを確認しましょう。 図 2. GenAIWorkflow ステートマシン まず、 AWS Systems Manager Parameter Store からクエリパラメータを取得します。パラメータには、処理するレコード ID のリストを取得する Amazon Athena クエリと、AWS HealthLake データストアの詳細が含まれます。 Amazon Athena の StartQueryExecution を呼び出して、Athena クエリを実行します。 Amazon Athena の GetQueryResults は、クエリの結果であるレコード ID のリストを取得します。クエリと結果セットによっては、最大数の結果が返されます。追加の結果がある場合は、 NextToken が返され、すべてのレコードを取得するには後続のクエリを実行する必要があることを示します。 分散モードのマップステート は、返されたレコード ID のリストを反復処理し、同時に処理します。デフォルトでは、Step Functions は同時実行数 10 を使用します。 各レコード ID について、Amazon Athena の StartQueryExecution API を呼び出してクエリの実行を開始します。 このステップでは、クエリの結果 (レコード ID に関連付けられたレポートのコンテンツ) を取得します。 Choice State を使用して、このステップでは、処理ロジックを続行する前に結果が返されたかどうかを判断します。 これは、 AWS Lambda 関数を使用して、Athena クエリの結果に必要な書式設定を行うオプションのステップです (例: 複数の列の値を 1 つの値に結合する、またはクエリ結果から JSON レコードを作成する)。 Parameter Store から、特定のタスクのプロンプトテンプレートを取得します。このプロンプトは、ユースケースに合わせてカスタマイズし、呼び出すモデルに最適化する必要があります。 このステップでは、プロンプトテンプレートとレポートコンテンツを組み合わせてプロンプトを作成し、Amazon Bedrock API を呼び出します。ここでは、さまざまな種類の Amazon Bedrock API 呼び出しの例外をキャッチして再試行するメカニズムを設定できます。 別の Lambda 関数を呼び出して、Amazon Bedrock API レスポンスを解析し、出力データを Amazon DynamoDB テーブルに保存できる形式に変換します。 PutItem API を使用して、構造化された出力データを DynamoDB テーブルに保存します。 結果が返されない場合は、反復処理をスキップします。 Choice state を使用して、 NextToken 値の有無を判断します。 NextToken が存在する場合は、Amazon Athena の GetQueryResults API を NextToken とともに再度呼び出して、次のバッチの結果を取得します。 処理するレコードがなくなると、ワークフローが成功します。 メリット AWS Step Functions を使用して生成 AI ワークフローを調整することには、いくつかの利点があります。Step Functions の中核は、さまざまな AWS サービスとシームレスに統合されるビジュアルワークフロー調整ツールであり、複雑な臨床生成 AI ワークフローを管理するのに最適です。このソリューションではセキュリティが最重要で、特に Step Functions が最近 カスタマーマネージドキーのサポート を発表したことで、独自の暗号化キーを使用してワークフロー定義と実行データを暗号化できるようになりました。この強化されたセキュリティは、 AWS KMS Customer Managed Keys (CMKs) を通じて保護された医療情報 (PHI) の堅牢な取り扱いと、遷移中と処理中の両方でコンポーネント全体にわたる包括的な暗号化にも及びます。このアーキテクチャは、Amazon Athena、AWS Lambda、Amazon DynamoDB などのサービスを通じて、セキュアなデータ処理とストレージを活用しています。また、このソリューションは非常に拡張性が高く、SQL クエリと生成 AI プロンプトを AWS Systems Manager Parameter Store のパラメータとして格納しているため、コード変更なしに変更が可能です。さらに、Lambda 関数を更新して、生成 AI ステップの前後にユースケース固有のロジックを組み込むこともできます。 このソリューションは、運用の信頼性とパフォーマンスにも優れています。Step Functions には、組み込みのエラー処理と再試行メカニズムがあり、自動再試行や適切な障害処理を通じてワークフローの回復力を確保します。また、 redrive 機能を使用して、失敗したステップから実行を再開することができます。以下のスクリーンショットは、Step Functions のビジュアルエディタと、堅牢なエラー処理機能を示しています。このアーキテクチャでは、Lambda や Athena などのサーバーレステクノロジーを活用しているため、ワークロードに基づいて自動的にスケーリングされ、必要なリソースのみを消費することで、パフォーマンスとコスト効率の両方を最適化できます。最後に、Step Functions には包括的な監視とログ機能が組み込まれているため、ワークフローの進行状況を追跡し、プロセスの各ステップでの入出力データを検査することができます。 図 3. Step Functions のエラー処理 次のステップ AWS Step Functions やその他の AWS サービスを活用することで、臨床現場での生成 AI ワークフローを実現するための、セキュリティ、拡張性、スケーラビリティに優れたソリューションを構築できます。これにより、医療機関は生成 AI の可能性を最大限に活用しながら、データ保護とコンプライアンスの最高水準を確保できます。 このソリューション を検討し、ご自身の要件に合わせてカスタマイズし、患者ケアと臨床プロセスに新たな可能性を切り開いてください。私たちはコミュニティとの協力を重視しており、 プルリクエスト を送ってソリューションの機能強化に貢献したり、 GitHub の Issue で問題を報告したり、コメント欄で経験や提案を共有したりすることを歓迎します。皆様のフィードバックと参加により、このソリューションを改善し、医療コミュニティのニーズにより良く応えられるよう努めていきます。 Qing Liu Qing Liu はAWSのシニアソリューションアーキテクトです。彼はヘルスケアIT業界で10年以上の経験を持っています。彼はヘルスケアデータを活用してより良い洞察を得て患者の治療成績を改善することに情熱を注いでいます。余暇には、妻や友人とテニスをするのが好きです。 Nick Ragusa Nick Ragusa はAWS教育チームのプリンシパルソリューションアーキテクトで、教育機関や大学病院がクラウド技術を活用して学習体験と患者の治療成績の両方を変革するのを支援しています。クラウドソリューションの設計をしていない時は、3人の子供たちのスポーツイベントで観客席から声援を送ったり、さわやかな秋の朝のランニングで思索しながら長距離を走ったり、あるいは慎重に選んだデザートで甘い物好きの自身を満足させたりしています。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

このブログは、2024 年 11 月 14 日に AWS Cloud Operations Blog で公開された “ Operations re:Imagined – Know Before You Go – AWS re:Invent 2024 ” を翻訳したものです。 12 月 2 日から 12 月 6 日にかけて毎年恒例のクラウドコンピューティングカンファレンス、 AWS re:Invent 2024 がラスベガスで開催されます。このカンファレンスでは、刺激的な基調講演に参加し、サービスを深く掘り下げて学び、クラウド利用に熱意のあるユーザー同士で交流する機会が得られます。初心者からエキスパートまで、全ての参加者に合わせたセッションやイベントをご用意しています。 学習するサービスが多数あるため、オペレーションに関するセッションを事前に検討しておくことをおすすめします。AWS でのノードやアプリケーションの管理は複雑になりがちですが、ハイブリッド環境やマルチクラウド環境でも同様です。特に新しい技術が絶えず登場する中で、一元的な運用によりノードやアプリケーションの運用面での洞察を得ることができます。AWS Systems Manager、Amazon CloudWatch、AWS Resource Explorer などのサービスは、AWS とそのお客様の両方に利益をもたらすベストプラクティスを適用するよう設計されています。大量なリソースの管理とタグ付けから、運用データに基づいて改善を促す洞察の提供まで、AWSにおける運用のベストプラクティスを強化する最新機能をご覧いただけます。 AWS re:Invent では、参加者のスキルレベルに合わせて様々な形式のセッションをご用意しています。セッション ID によってレベルが示されています。re:Invent のセッションタイプの詳細は こちら をご覧ください。 このブログでは、AWS クラウド運用をさらに活用するための、AWS re:Invent 2024 の一元的な運用に関するセッションをいくつか紹介します。 筆者のおすすめ マルチアカウント環境の構築に取り組む際、タグポリシーの実装や、アカウントにまたがって展開されたリソースの管理に関する課題に直面することがあります。タグ付けとリソース管理は、クラウド基盤構築の重要な要素ですが、組織にとって適した戦略を考案するのは時間がかかる作業です。そこで、AWS エキスパートが異なるお客様向けに実践してきた様々な戦略について議論するセッションをご紹介します。ここでの洞察が、タグ付けとリソース管理の戦略立案や、既存の取り組みの改善の一助となれば幸いです。 COP351 | Effective multi-account tagging and resource discovery strategies – Chalk Talk 数千ものリソースを複数のアプリケーションや AWS アカウントにまたがって管理する際は、適切なタグ付けとリソース管理の戦略を立案し、実行に移すのは時間がかかり、非常に複雑な作業となります。このセッションでは、未タグ付けのリソースを検出し、アプリケーションごとにリソースを整理する方法、および AWS Organizations を使ったアプリケーションの管理方法について学びます。さらに、リソースとアプリケーションを大規模に管理する方法について、AWS エキスパートに質問する機会も設けられています。 その他の運用管理セッション COP321 | Centralize Multicloud Management using AWS – Breakout Session マルチクラウド環境で運用する場合、オペレーションの複雑さが増す可能性があります。このセッションでは、AWS Systems Manager を使ってインスタンスの管理を簡素化する方法を学びます。Amazon CloudWatch と Amazon Managed Grafana を活用すれば、あらゆるデータソースからのメトリクスとログを単一のダッシュボードで把握できます。これらのサービスを使えば、AWS やオンプレミス、他のクラウドにまたがるワークロードの日々のタスクを簡素化し、コントロールを維持しつつリソースを最適化できます。マルチクラウドの複雑さを解消し、ビジネスに集中できるようサポートします。 COP325 | Operating your fleet of resources at scale is easier than you think! – Breakout Session これまでは、大規模な組織全体にまたがった AWS リソース、マルチクラウド、オンプレミスのリソースを運用するには多数のツールと手動プロセスが必要でした。AWS では自動化によって効率を高め、コストを削減できます。このセッションでは、AWS Systems Manager、Amazon CloudWatch などのサービスを使って、コンピューティングリソースの一括パッチ適用、アプリの展開、インシデントの解決など、さまざまな運用タスクを自動化する方法を学びます。数多くのお客様が、数百万ものリソースを AWS、マルチクラウド、オンプレミス、IoT にわたって管理するのに、これらのサービスを活用しています。今回、それらのサービスがさらに簡単に使えるようになりました。 COP328 | Streamlining application management on AWS – Breakout Session 開発チームとオペレーションチームには、リソースを効率的に管理・監視できる一元的な方法が必要です。このセッションでは、AWS myApplications を使ったアプリケーションの管理と監視のベストプラクティスを考察します。リソースを論理的なアプリケーション単位で整理する方法や、単一のダッシュボードからアプリケーションポートフォリオの可視化、コスト、セキュリティ、パフォーマンスの重要指標の把握、標準化された方法でのアプリケーションの展開と拡張を加速する方法について説明します。 COP337 | All things patching: Manage and monitor at scale – Chalk Talk このセッションでは、AWS Organization に属する EC2、オンプレミス、マルチクラウドのインスタンスの最新のオペレーティングシステムセキュリティパッチを確実に適用する、一元的なパッチ管理アプローチについて学びます。管理アカウントでポリシーを定め、アカウントやアプリケーションのコンプライアンス状況を把握する方法を習得します。さらに、組織全体のインスタンスからどのパッチが不足しているかを素早く特定する方法も学びます。これにより、セキュリティ脆弱性への対応時間を短縮し、組織全体のセキュリティポスチャーを高めることができます。 COP339 | Adopt AWS’s Ops management culture on your team – Chalk Talk AWS は、サービスの信頼性がお客様の重要な要件であることを認識しています。このセッションでは、非中央集権組織において、重要なプロセスであるインシデント管理を Amazon がどのように文化的・技術的な仕組みを用いて効果的に運用しているかについて学びます。重大度判断、優先順位付け、インシデント対応と緩和に使われる当社のメカニズムとツールを掘り下げて説明し、それらを支える Amazon の企業文化についても探ります。日々のオペレーション負荷を軽減し、インシデントの平均解決時間 (MTTR) を短縮するために、Amazon が使っている実践的な手法とツールについて解説します。 COP346 | Centralize audit data for hybrid and multicloud environments – Chalk Talk お客様がクラウドへの移行を加速し、事業変革を遂げる中で、ハイブリッド環境の IT 運用を管理しなければならない状況に直面することがあります。これにお困りではありませんか？このセッションでは、AWS CloudTrail Lake を有効にし、過去の CloudTrail ログをインポートし、パートナー製品との統合、カスタムソリューション、多数の AWS リソースからの監査ログを集約する方法を説明します。また、調査分析とセキュリティ目的でこのデータをクエリする方法についても扱います。 まとめ このブログでは、AWS クラウド運用に関連するいくつかのセッションをご紹介しました。re:Invent の当日は、AWS ビレッジのクラウド運用ブースにお立ち寄りいただき、さらに詳しいお話をお聞きいただければと思います。セッションの詳細は、re:Invent の イベントセッションサイト をご確認ください 筆者について Tiffany Chen Tiffany は、ヘルスケアとライフサイエンス業界を担当する AWS のソリューションアーキテクトです。デプロイメント業務のサポートを行い、現在はエンタープライズ顧客と協力して、Well-Architected にコスト最適化されたソリューションの構築に取り組んでいます。趣味は旅行、園芸、お菓子作り、バスケットボールの観戦です。 Winnie Chen Winnie は AWS のソリューションアーキテクトで、金融サービス業界の新規顧客を支援しています。AWS上でのインフラストラクチャの移行と構築を支援しています。趣味は旅行、ハイキング、自転車、岩登りなどのアウトドア活動です。

この記事は Amazon EKS and Kubernetes sessions at AWS re:Invent 2024 (記事公開日: 2024 年 11 月 16 日) を翻訳したものです。 イントロダクション Amazon Web Services の年次イベントである AWS re:Invent 2024 が近づいています。今年のイベントでは、Kubernetes やその他のクラウドネイティブ技術に焦点を当てたセッションのフルトラックを含みます。広大なセッションカタログを簡単に参照できるよう、Kubernetes とクラウドネイティブ関連トピックのセッションリストを作成しました。 コアトピックごとにまとまっており、re:Invent セッションカタログのセッション詳細へのリンクもあります。 さぁ、参加者ポータルのカタログで、今すぐセッションを予約し始めましょう。 興味のあるセッションの予約席を確保できない場合は、ほとんどのセッションタイプで Walk-up 席が利用できます。 注目すべきセッションの 1 つに、 KUB201: Kubernetes on AWS の未来 があります。ここでは、 AWS の Kubernetes Head of Product である Nathan Taber 氏 と、 Snowflake の Princilal Software Engineer である Hyungtae Kim 氏 が登壇します。このセッションでは、EKS の最新のイノベーションと、Snowflake の次世代 AI/ML プラットフォームの洞察について学ぶことができます。 必ず聞くべきセッションの 1 つに、 CMP215: あらゆるアプリケーションのためのコンピューティング・イノベーション があります。こちらは、 AWS の VP & Distinguished Engineer, Compute & Networking, Amazon EC2 である Anthony Liguori と、 AWS の VP Serverless Compute である Holly Mesrobia によるセッションです。 このセッションでは、AWS のインフラとソリューションに対する革新の取り組みが紹介されます。これによりお客様は、クラウドだけでなくオンプレミスやエッジでもアプリケーションのビルド、実行、スケーリングが可能になります。 是非ご参加いただき、これらの AWS のイノベーションがコンピューティングの世界をどのように変革しているか、内部からの視点をご覧ください。 さまざまなセッション形式の詳細な説明は re:Invent ラーニングフォーマット をご確認ください。 Kubernetes によるプラットフォームの構築 Amazon EKS – Kubernetes とコンテナによって構築されたアプリケーションや開発者プラットフォームの最新のイノベーションを探索しましょう。今年の re:Invent のラインナップには、コンテナ化が初めての方でも、既にあるワークフローを改善したい方であっても、Kubernetes のスキルを向上させるのに最適なセッションが用意されています。 AWS のエキスパートや同じ考えを持つプロフェッショナルと協力して、Kubernetes の管理を簡素化し、あらゆる規模のチームにとっての可能性を解き放つ、最新の戦略を探ってください。 KUB308 | IDP ファストトラック: エンタープライズ DevOps のための CNOE を活用したデプロイレース(ワークショップ) KUB301 | Amazon EKS を用いた、スケーラブルなプラットフォームの構築 (ブレイクアウト) PEX402-R | Amazon Q を用いた AWS におけるモダンなエンジニアリング技術の取り入れ (ワークショップ) KUB102-S | Zesty における最適化されたプラットフォームによる Kubernetes 管理の革新 (ライトニングトーク) KUB402-R | Amazon EKS: Infrastructure as code、GitOps、CI/CD (チョークトーク) KUB306-R | Amazon EKS へのアプリケーションデプロイの簡素化 (ビルダーセッション) KUB307-R | 組織における Kubernetes のスケールの基礎 (ワークショップ) SAS311-R | Amazon EKS でのマルチテナント SaaS アーキテクチャの最適化 (チョークトーク) データ、機械学習、生成 AI これらのセッションに参加して、AWS 上のデータ処理、機械学習、Kubernetes が交差する領域を探索してください。これらのセッションは、EKS を分析のためのデータプラットフォームとして活用することから、生成 AI モデルのデプロイとスケーリング、責任ある AI のプラクティスの採用まで、EKS のスケールとパフォーマンスを、データ処理、機械学習、生成 AI と組み合わせるうえでの、貴重な洞察を提供します。 KUB405 | 分析のためのデータプラットフォームとしての Amazon EKS (ブレイクアウト) KUB313 | Amazon EKS 上の MLOps のためのアーキテクチャパターン (チョークトーク) KUB401 | Amazon EKS におけるデータと生成 AI (ワークショップ) KUB314 | Amazon EKS におけるハイパフォーマンスな生成 AI (ブレイクアウト) KUB316 | Amazon EKS への最適化された推論パイプラインのデプロイ (チョークトーク) KUB403 | Amazon EKS における高性能な LLM 推論のスケーリング (チョークトーク) KUB320-R | Amazon EKS でのモダンなデータ処理パイプラインの構築 (チョークトーク) OPN309-R | オープンソースと共に実現する責任ある生成 AI の実践 (チョークトーク) DAT202-S | チャットボットを超えて: AI がリアルタイムにビジネスクリティカルな意思決定をおこなう方法 (ブレイクアウト) STG406-R | Amazon S3 と Amazon EKS での AI/ML ワークロードのオンボーディングと最適化 (ワークショップ) ANT410 | Amazon EMR on EKS でデータパフォーマンスを最大化する (チョークトーク) コスト最適化とパフォーマンス Amazon EKS での Kubernetes 環境における、クラスター効率の最大化、無駄の削減、イノベーションの解放のための最新の戦略を発見するために、ご参加ください。 これらのセッションでは、クラスターを動的にスケーリングする方法、Kubernetes のコストをビジネス価値と整合させる FinOps アプローチを採用する方法、クラウドコスト最適化のベストプラクティスを探索する方法についての知識を身につけることができます。 KUB312 | Amazon EKS と Karpenter による自動化されたクラスターインフラストラクチャー (ブレイクアウト) KUB309-R | Karpenter: Amazon EKS のベストプラクティスとクラウドコストの最適化 (ワークショップ) KUB311-R | Kubernetes を採用する FinOps :ビジネス革新のためのコスト最適化 (チョークトーク) セキュリティ AWS で Kubernetes ワークロードを実行しているお客様にとって、セキュリティは最も重要です。これらのセッションに参加して、Kubernetes のセキュリティの重要な領域を探索し、EKS 環境の保護に役立つ重要なツールとベストプラクティスを理解しましょう。これらのセッションでは、Kubernetes ワークロードの保護を深く掘り下げ、ソフトウェアサプライチェーンを最適化し、セキュリティと可観測性が交差する領域を調査し、Policy as Code で Kubernetes のセキュリティを強化する方法を学ぶことができます。 KUB319 | Amazon ECR を使用したソフトウェアサプライチェーンのセキュリティ強化と最適化 (チョークトーク) KUB315 | Amazon EKS における Kubernetes ワークロードのセキュリティ対策 (ブレイクアウト) KUB305-R | Amazon EKS クラスターのセキュリティ対策と監視 (ビルダーズセッション) KUB302-R | セキュアなコンテナ環境の戦略とベストプラクティス (チョークトーク) OPN306-R | Kyvernoを使った Policy as Code によるKubernetes セキュリティ強化 (チョークトーク) ストレージ Amazon EKS 上のコンテナ化アプリケーションのストレージを効果的に管理および最適化する方法を知ることができます。 ステートフルワークロード向けに AWS ストレージサービスを活用する方法と、コンテナ化アプリケーションのデプロイにおけるベストプラクティスを探求します。 KUB324 | AWS のストレージサービスを活用した、Amazon EKS でのステートフルなワークロードの実現 (ライトニングトーク) STG331 | Amazon EBS でのコンテナ化されたアプリケーションのデプロイ (チョークトーク) 運用、デプロイ、可観測生 re:Invent 2024 で、EKS の効率的な運用、堅牢な可観測性、効果的なデプロイ戦略に深く踏み込む包括的なセッションを披露できることを楽しみにしています。参加者の皆様は、生成 AI を活用して EKS 運用を最適化する方法、可観測性のベストプラクティス、Kubernetes とサーバーレスコンピューティングが交差する領域、Kubernetes API を介したインフラストラクチャの管理の最新動向を探索する機会が得られます。手を動かしたい方向けに「Amazon EKS フリート管理への Dive Deep」ワークショップでは、Kubernetes 環境の効果的な管理とスケーリングの実践的な体験を提供します。 KUB321 | 生成 AI で Amazon EKS の運用を効率化する(コードトーク) KUB323 | Amazon EKS ワークロードにおける可観測性戦略 (ライトニングトーク) KUB101-S | Amazon EKS ワークロードにおける可観測性のデータコストと複雑さの制御 (ライトニングトーク) KUB303-R | Amazon EKS フリート管理への Dive Deep (ワークショップ) KUB203-S | プロダクトカルチャーの再構築: Smarsh による AWS でのスケーリングと移行 (ライトニングトーク) KUB202-S | 生成 AI のスケーリング: Kubernetes での運用課題の対処 (ブレイクアウト) KUB304-R | Cloud-native Java on AWS (ビルダーズセッション) API308 | Kubernetes が出会う Serverless: Kubernetes API で EDA をデプロイする (ブレイクアウト) OPN312 | Infrastructure as Kubernetes API (ブレイクアウト) OPN202 | AWS Controllers for Kubernetes による API 経由のインフラストラクチャ管理 (ライトニングトーク) SAS404 | Kubernetes DevOps ツールを活用した SaaS プロビジョニングとデプロイの自動化 (ワークショップ) スケーラビリティ、レジリエンシー、接続性 AWS に Kubernetes をデプロイするにあたって、アプリケーションのスケーラビリティ、レジリエンス、接続性を確保する必要があります。最新の戦略とイノベーションを探索し、本番グレードのアーキテクチャ構築、クラスターパフォーマンスの最適化、機械学習ワークフローの効率化の方法を学びましょう。 ネットワーク戦略やサービスメッシュから、コスト効果の高い ML トレーニングやエッジデプロイまで、 AWS 上での Kubernetes のポテンシャルを最大限に引き出すためのベストプラクティスとツールについて深掘りします。 KUB404 | Amazon EKS での本番グレードのレジリエンスアーキテクチャの構築 (ブレイクアウト) KUB406 | Kubernetes のネットワーク戦略 (ブレイクアウト) KUB310 | エッジおよびハイブリッドなユースケースのための Amazon EKS (ブレイクアウト) KUB322-R | Amazon EKS で回復力のあるアプリケーションを構築する (チョークトーク) KUB318-R | Karpenter による Kubernetes クラスターのスケール、最適化、アップグレード (チョークトーク) NET315 | Kubernetes のネットワーク戦略 (チョークトーク) OPN307 | Kubernetes の接続性: サービスメッシュから未来へ (チョークトーク) CMP403 | Amazon EKS と AWS Batch を活用したスケーラブルかつコスト効率な MLトレーニング (チョークトーク) AWS Village の Kubernetes kiosk や、Developer Pavilion の Modern Apps と Open Source Zone を訪れるため、 Expo Hall にお立ち寄りください。AWS 上でのモダンアプリケーション構築について専門家に質問したり、デモを見たり、オープンソースチームと会ったりできます。 立ち寄って挨拶をして、楽しんで、スナックをつまんで、クレーンゲームから商品をゲットしましょう！ re:Invent に直接参加できない場合も問題ありません！バーチャルパスを 登録 することで、Keynote と Leadership Session のライブ配信に参加できます。 また、ブレイクアウトセッションをお見逃しなく！イベント後に AWS Events YouTube でオンデマンド視聴できます。 これらのセッションや、AWS の専門知識があなたの組織にどのように役立つかについて、さらに詳しく知りたいですか？詳細は AWS アカウントチームにお問い合わせください。 あなたの組織で Kubernetes を最大限に活用する方法の詳細については、 Amazon EKS のウェブページをご覧ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

本ブログは “ Upgrade Amazon DocumentDB 4.0 to 5.0 with near-zero downtime ” を翻訳したものです。 Amazon DocumentDB (MongoDB 互換) は、MongoDB ワークロードをサポートする、高速でスケーラブルで可用性の高いフルマネージド型のドキュメントデータベースサービスです。基盤となるインフラストラクチャの管理について心配することなく、同じ MongoDB 3.6、4.0、5.0 アプリケーションコード、ドライバ、およびツールを使用して、Amazon DocumentDB でワークロードを実行、管理、およびスケーリングできます。Amazon DocumentDB はドキュメントデータベースであるため、JSON データの格納、クエリ、インデックス作成が行えます。 Amazon DocumentDB バージョン 5.0 のリリースにより、Amazon DocumentDB クラスターのバージョン 3.6 および 4.0 から 5.0 へのメジャーバージョンアップグレードを実行して、 複数の拡張機能 を活用できるようになりました。Amazon DocumentDB 5.0 は、ベクター検索、ドキュメント圧縮、I/O 最適化ストレージ、インデックス構築ステータスによる高速インデックス作成、クライアント側 Field Level Encryption (FLE) などをサポートしています。 この投稿では、 メジャーバージョンのインプレースアップグレード 、 Amazon DocumentDB ボリュームクローニング 、 AWS Database Migration Service (AWS DMS) を使用して、Amazon DocumentDB 4.0 から 5.0 へのダウンタイムをほとんど発生させずにアップグレードする方法を記載します。 既存のアップグレードオプション 現在、Amazon DocumentDB 4.0 のユーザーは、以下の方法を使用して Amazon DocumentDB 5.0 へのメジャーバージョンアップグレードを実行できます。 mongodump と mongorestore — mongodump や mongorestore などのコマンドラインユーティリティを使用して Amazon DocumentDB データベースのバイナリバックアップを作成し、それらを新しい Amazon DocumentDB 5.0 クラスターに復元できます。この方法では、アップグレード中に Amazon DocumentDB クラスターがオフラインになるため、ダウンタイムに耐えられるワークロードに最適です。 AWS DMS — AWS DMS を使用して、既存のクラスターから新しい Amazon DocumentDB 5.0 クラスターにデータを移行することができます。AWS DMS はマネージド型サービスで、サポートされているソースやターゲット間で既存のデータを移行するために使用できます。この方法では、追加の DocumentDB I/O 料金と AWS DMS の使用料が発生します。詳細については、「 AWS データベース移行サービスを使用した Amazon DocumentDB クラスターのアップグレード 」を参照してください。 インプレース メジャーバージョン アップグレード — この機能を使用すると、データの移行やエンドポイントを変更したりする必要なく、Amazon DocumentDB クラスターのインプレースアップグレードを実行できますが、ダウンタイムが必要となり、ダウンタイムの長さはコレクション、データベース、コレクション、インデックスの数によって異なります。詳細については、 インプレース メジャーバージョン アップグレードのドキュメント を参照してください。 ソリューション概要 この記事では、メジャーバージョンのインプレースアップグレード、ボリュームクローニング、AWS DMS を使用して、ダウンタイムをほとんど発生させずにメジャーバージョンアップグレードを実行するハイブリッドアプローチについて説明します。このアプローチでは、クラスターデータ全体を新しいエンドポイントに移行する際に通常かかる I/O コストとアップグレードに要する時間を最小限に抑えることもできます。この手法は下記の流れで実施します。 Amazon DocumentDB クラスターで変更ストリームを有効にする Amazon DocumentDB クラスターのクローンを作成します クローンしたクラスターでインプレースメジャーバージョンアップグレードを実行します AWS DMS を使用して Amazon DocumentDB クラスターからクローンクラスターに変更データキャプチャ (CDC) を複製します レプリケーションが終了したら、アプリケーションエンドポイントをクローンクラスターに変更します アップグレード後のクリーンアップを実行します 前提条件 さらに進めるには、AWS DMS、 インプレースメジャーバージョンアップグレード 、および ボリュームクローニング について高いレベルで理解している必要があります。このソリューションを利用すると、Amazon DocumentDB 変更ストリーム、AWS DMS レプリケーションインスタンス、その他のリソースに関連して、アカウントで発生するコストを最小限に抑えることができます。 AWS Pricing Calculator ツールを使用すると、設定に基づいてコストを見積もることができます。 Amazon DocumentDB クラスターをより高いバージョンにアップグレードする場合は、廃止された機能や演算子、または使用方法の変更がないか確認してください。アプリケーションを新しいバージョンに対して実行し、アプリケーションに意図的な変更がない限り、動作とパフォーマンスが以前のバージョンと同じであることを確認します。 エンドポイントの切り替え時に、ある程度のダウンタイムが発生することに注意してください。実稼働環境で試す前に、検証環境でこのアプローチを複数回ドライランすることを強くお勧めします。 Amazon DocumentDB クラスターで変更ストリームを有効にする Amazon DocumentDB クラスターのメジャーバージョンアップグレードを最小限のダウンタイムで実行するには、クラスターで 変更ストリーム を有効にする必要があります。変更ストリームは、Amazon DocumentDB クラスター内で発生する更新イベントを時系列で提供します。 CDC でトランザクション漏れが発生しないように、変更ストリームログの保持期間を設定する必要があります。変更ストリームログのデフォルトの保持期間は 3 時間です。この期間は 1 時間から 7 日の間の任意の値に設定できます。この属性は 24 時間以上に設定することをおすすめします。 次の AWS コマンドラインインターフェイス では、保持期間が 24 時間に延長されます。 aws docdb modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name <parameter group name> \ --parameters "ParameterName=change_stream_log_retention_duration, ParameterValue=86400,ApplyMethod=immediate" Amazon DocumentDB コンソール から変更ストリームを有効にすることもできます。 すべてのデータベースで変更ストリームを有効にするには、Amazon DocumentDB クラスターに接続し、次のコマンドを使用して変更ストリームを有効にします。 db.adminCommand({modifyChangeStreams: 1,database :"",enable: true}); 変更ストリームの作成を確認するには、 $listChangeStreams アグリゲーションパイプラインステージを使用して、クラスターで有効になっているすべての変更ストリームを一覧表示します。詳細については、「 変更ストリームの有効化 」を参照してください。 Amazon DocumentDB クラスターのクローン Amazon DocumentDB のクローニングでは、お使いの Amazon DocumentDB プロダクションクラスターと同じ Amazon DocumentDB クラスターボリュームを使用し、同じデータを持つ新しいクローンクラスターを作成できます。クローンの作成は、スナップショットの復元などの他の手法を使用してデータを物理的にコピーするよりも高速で、スペース効率も高くなります。 Amazon DocumentDB プロダクションクラスターのクローンを作成するには、以下のステップを実行します。 Amazon DocumentDB コンソールのナビゲーションペインで、[クラスター] を選択します。 Amazon DocumentDB プロダクションクラスターを選択し、[アクション] メニューで [クローンの作成] を選択します。 [クラスター識別子] に、クローンされた Amazon DocumentDB クラスターに付ける名前を入力します (たとえば、 cloned-docdb-cluster など)。 [インスタンス]、[構成]、[ネットワーク設定]、[保存時の暗号化]、[ログのエクスポート]、[ポート]、[削除保護] では、Amazon DocumentDB クラスターと同じ設定を選択します。Amazon DocumentDB クラスターとインスタンスの設定の詳細については、Amazon DocumentDB クラスターの管理を参照してください。 [クローンを作成] を選択して、選択した Amazon DocumentDB クラスターのクローンを起動します。クローンが作成されると、他の Amazon DocumentDB クラスターとともに [クラスター] ページに表示され、現在の状態が表示されます。状態が Available になると、クローンは使用できる状態になります。 クラスターページで、クローンクラスターを選択し、構成タブに移動して、クラスターの作成時間をメモします。 クローンされたクラスターでインプレースメジャーバージョンアップグレードを実行する このステップでは、データを移行したりエンドポイントを変更したりせずに、複製された Amazon DocumentDB 4.0 クラスターを 5.0 にアップグレードします。クローンされたクラスターでメジャーバージョンのインプレースアップグレードを実行しても、追加料金は発生しません。 インプレースメジャーバージョンアップグレードを実行する前に、前提条件となるステップをすべて完了していることを確認してください。詳細については、 Amazon DocumentDB インプレースメジャーバージョンアップグレード を参照してください。 Amazon DocumentDB イベントのサブスクライブ の手順に従って、クローンクラスターのメンテナンスイベントをサブスクライブします。次に、以下のステップを実行してクラスターをアップグレードします。 Amazon DocumentDB コンソールのクラスターページでクローンクラスターを選択し、アクションメニューで [変更] を選択します。 [クラスター識別子] に、クラスターの名前を入力します。 [エンジンバージョン] には 5.0.0 を選択します。 VPC セキュリティグループを指定します。 クラスターオプションセクションで、適切なデフォルトまたはカスタムクラスターパラメータグループを選択し、[Continue] を選択します。 「変更のスケジュール設定」セクションで、「すぐに適用」を選択します。 [Modify cluster] を選択して、クラスターのインプレースアップグレードを開始します。これで、クラスターのステータスが Upgrade に変わります。アップグレードが完了すると、クラスターのステータスが Available に戻り、「データベースクラスターのメジャーバージョンがアップグレードされました」というイベントが表示されます。イベントページを監視することで、アップグレードの進行状況を追跡できます。 インプレースメジャーバージョンアップグレードが完了したら、サニティチェックを実行して、アップグレードしたクローンが機能していて、すべてのデータとインデックスが損なわれていないことを確認します。 注:データの不整合が発生する可能性があるため、複製したクラスターのデータを変更しないように注意してください。 AWS DMS を使用して、ソースクラスターからクローンクラスターに CDC をレプリケートする このステップでは、クローンの作成後に行われたすべてのデータベース変更をレプリケートすることで、クローンクラスターを Amazon DocumentDB ソースクラスターと同期させます。AWS DMS レプリケーションインスタンスは、Amazon DocumentDB プロダクションクラスターに接続してデータを読み取り、それをターゲットのクローンクラスターに書き込むことで CDC を実行します。 AWS DMS レプリケーションインスタンスを作成する レプリケーションインスタンスを作成するには、以下のステップを実行します。 AWS DMS コンソールで [レプリケーションインスタンスを作成] を選択します。 名前 ( docdb40todocdb50 など) とオプションの説明を入力します。 インスタンスクラスでは、必要に応じてサイズを選択します。 [エンジンバージョン] で [3.5.1] を選択します。 Amazon VPC の場合は、ソースとターゲットの Amazon DocumentDB クラスターを収容する VPC を選択してください。 [割り当て済みストレージ] には、デフォルトの 50 GiB を使用します。書き込みスループットのワークロードが高い場合は、ワークロードに合わせてこの値を増やしてください。 マルチ AZ では、高可用性とフェイルオーバーサポートが必要な場合は [はい] を選択してください。 パブリックにアクセスできるようにするには、このオプションを有効にします。 [レプリケーションインスタンスを作成] を選択します。 AWS DMS のソースエンドポイントとターゲットエンドポイントの作成 ソースエンドポイントを作成するには、以下のステップを実行します。 AWS DMS コンソールのナビゲーションペインで [Endpoints] を選択します。 [エンドポイントの作成] を選択します。 [エンドポイントタイプ] で [ソース] を選択します。 [エンドポイント識別子] には、覚えやすい名前 ( docdb40-source など) を入力します。 [ソースエンジン] には [Amazon DocumentDB] を選択します。 [サーバー名] には、Amazon DocumentDB プロダクションクラスターの DNS 名を入力します。 ポートには、Amazon DocumentDB プロダクションクラスターのポート番号を入力します。 SSL モードの場合は、[すべてを確認] を選択します。 CA 証明書の場合は、「新しい CA 証明書の追加」を選択し、次の手順を実行します。 新しい CA 証明書をダウンロードして TLS 接続バンドルを作成します。 「証明書の識別子」には、 global-bundle.pem と入力します。 [新しい CA 証明書の追加] で [ファイルを選択] を選択し、ダウンロードした.pem ファイルに移動します。 ファイルを選択して開きます。 [証明書のインポート] を選択し、[証明書の選択] ドロップダウンメニューで global-bundle.pem を選択します。 [ユーザー名] には、ソースクラスターのプライマリユーザー名を入力します。 Password には、ソースクラスターのプライマリパスワードを入力します。 Amazon DocumentDB クラスターのすべてのデータベースから CDC を複製する場合は、[データベース名] を空白のままにします。または、テーブルマッピングを使用して特定のデータベースを指定することもできます。 エンドポイント接続をテストし、接続が機能することを確認します [エンドポイントの作成] を選択します。 2 つ目のエンドポイントを作成し、エンドポイントタイプに Target を選択し、クローンしたクラスターの詳細を指定します。 AWS DMS 移行タスクを作成する AWS DMS タスクはレプリケーションインスタンスをソースインスタンスおよびターゲットインスタンス関連付けます。移行タスクを作成するときは、ソースエンドポイント、ターゲットエンドポイント、レプリケーションインスタンス、および必要な移行設定を指定します。AWS DMS タスクには、「既存のデータを移行する」、「既存のデータを移行して、継続的な変更をレプリケートする」、「データ変更のみをレプリケートする」の 3 つの移行タイプがあります。 クラスター作成の開始までにすべてのデータを含むボリュームクローンを使用してターゲットクラスターを作成した場合は、クラスター作成後にソースで発生した差分変更をコピーするだけでよいので、AWS DMS の「データ変更のみをレプリケートする」移行タイプを使用します。このオプションを使用すると、AWS DMS はソースクラスターの動作を維持したまま、変更内容をクラスターからクローンクラスターにレプリケートします。最終的に、ソースデータベースとターゲットデータベースは同期され、移行のダウンタイムはほぼゼロになります。 次の手順を実行して移行タスクを作成します。 AWS DMS コンソールのナビゲーションペインで [Tasks] を選択します。 [タスクを作成] を選択します。 [タスク識別子] に、名前 ( mvu-cdc-task など) を入力します。 [レプリケーションインスタンス] で、作成したレプリケーションインスタンスを選択します。 [ソースデータベースエンドポイント] で、作成したソースエンドポイントを選択します。 [ターゲットデータベースエンドポイント] で、作成したターゲットエンドポイントを選択します。 [移行タイプ] で [データ変更のみをレプリケート] を選択します。 「タスク設定」セクションで、「ウィザード」を選択し、「カスタム CDC 開始モードを有効にする」を選択します。 開始時間を、先ほど書き留めたクローンクラスターの作成時間の 2 分早く指定してください。 [ターゲットテーブル準備モード] で [何もしない] を選択します。 LOB 列の設定では、デフォルトの最大 LOB サイズ (32) で制限付き LOB モードを選択します。 [CloudWatch ログの有効化] を選択します。 詳細タスク設定はデフォルト設定のままにします。 テーブルマッピングでは、[ウィザード] を選択します。 「選択ルール」で、スキーマには「EnterSchema」、ソース名には「%」、ターゲット名には「%」、「アクション」には「include」を選択します。 [タスクを作成] を選択します。 監視と検証 これで、AWS DMS はソース Amazon DocumentDB クラスターからターゲット Amazon DocumentDB クラスターへの CDC のレプリケーションを開始します。タスクステータスが [開始] から [レプリケーション中] に変わるはずです。AWS DMS コンソールのタスクページで進捗状況をモニタリングできます。変更内容によっては、数分から数時間かかることがあります。DMS タスクに 並列スレッドを追加 することで、CDC のスループットを向上させることができます。 最終的に、ソースとターゲットは同期されます。コレクションで count () 操作を実行してすべての変更イベントが移行されたことを確認することで、両者が同期しているかどうかを確認できます。 Amazon DocumentDB DataDiffer ツール を使用してデータ検証を実行することもできます。 レプリケーションが追いついたら、アプリケーションエンドポイントを 5.0 クラスターに変更 新しい Amazon DocumentDB 5.0 クラスターが同期され、すべてのチェックに合格したことを確認したら。これで、アプリケーションのデータベース接続エンドポイントを Amazon DocumentDB クラスターから Amazon DocumentDB 5.0 クラスターに変更する準備が整いました。 アップグレード後のクリーンアップを実行 以下の手順を実行してリソースをクリーンアップできます。 Amazon DocumentDB クラスターを削除 します。 Amazon DocumentDB 5.0 プロダクションクラスターの変更ストリームを無効にします。 必要に応じて AWS DMS インスタンス、レプリケーションタスク、エンドポイントをすべて削除 します。 Amazon DocumentDB 5.0 クラスターにインスタンスを追加して Amazon DocumentDB プロダクションクラスターに一致させるには、Amazon DocumentDB コンソールのクラスターページでクローンクラスターを選択し、アクションメニューで [インスタンスを追加] を選択します。 Amazon DocumentDB 4.0 クラスターにあったモニタリングとアラートをコピーまたは設定します。 結論 この投稿では、インプレースメジャーバージョンアップグレードと AWS DMS を使用して、Amazon DocumentDB 4.0 から 5.0 にアップグレードする方法と、ダウンタイムをほぼゼロに抑える方法を紹介しました。 Amazon DocumentDB 5.0 は、ベクター検索、ドキュメント圧縮、I/O 最適化ストレージ、インデックス構築ステータスによるインデックス作成の高速化、クライアント側 FLE などをサポートしています。Amazon DocumentDB クラスターのバージョン 3.6 と 4.0 から 5.0 へのメジャーバージョンアップグレードを実行することで、複数の拡張機能を活用できます。詳細については、 ドキュメントを参照 してください。 著者について Kunal Agarwal は、アマゾンウェブサービスのシニアプロダクトマネージャーです。Kunal はデータに情熱を傾け、顧客の問題を解決するスケーラブルな製品を構築することが大好きです。AWS に入社する前、Kunal はテクノロジー業界で製品管理と戦略に 12 年間携わっていました。 Anshu Vajpayee は、アマゾンウェブサービス (AWS) のシニア DocumentDB スペシャリストソリューションアーキテクトです。彼は、お客様が NoSQL データベースを採用し、Amazon DocumentDB を活用したアプリケーションをモダナイズできるよう支援してきました。AWS に入社する前は、リレーショナルデータベースと NoSQL データベースを幅広く扱っていました。 本ブログの翻訳はソリューション アーキテクトの大井が担当しました。

この投稿では、 AWS Network Load Balancer (NLB) の Transmission Control Protocol (TCP) フローのアイドルタイムアウトを設定する手順を説明します。 NLB は Open Systems Interconnection (OSI) モデルのレイヤー 4 で動作する Amazon Web Services (AWS) の Elastic Load Balancing ファミリの一部で、TCP または User Datagram Protocol (UDP) でクライアント接続を管理し、それらをロードバランサーのターゲットに分散します。 NLB は接続の確立から、非アクティブ (アイドルタイムアウト) による閉鎖またはタイムアウトまでを追跡します。 デフォルトでは、TCP 接続のアイドルタイムアウトは 350 秒、UDP 接続のタイムアウトは 120 秒です。 新しく TCP のアイドルタイムアウトが設定可能になったため、既存および新規の NLB TCP リスナーでこの属性を変更できるようになり、NLB が非アクティブな接続を終了するまでの時間を決められるようになりました。 TCP 接続確率の手順の理解 始める前に、TCP プロトコルの動作の概要を説明します。より深く理解するには、 TCP の RFC(RFC 9293) を参照してください。 図 1. TCP 接続確立の段階 TCP 接続には確立、データ転送、正常なクローズなどのいくつかの段階があります。 ハーフオープン : クライアントが SYN を送信し、サーバーが応答しますが、まだクライアントがハンドシェイクを完了していない状態。 接続確立 : 3 ウェイハンドシェイクが完了した状態。 データ転送 : ハンドシェイク後、クライアントとサーバーの間でデータを交換している状態。この図の部分は、読みやすくするために簡略化されています。 クローズ : クライアントが FIN パケットを送信し、正常にクローズされます。 NLB の TCP 接続処理 NLB は、レイヤー 4 プロキシとして動作し、確立された各接続をフローテーブルで追跡します。 ハーフオープン、正常にクローズした接続、またはクライアントまたはサーバーでリセットされた接続は追跡されません。 単一の接続は 5 つの属性の組み合わせ (5 タプル) によって定義され、プロトコル (TCP)、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポートからなります。 図 2. NLB デプロイのサンプルアーキテクチャ デフォルトでは、クライアントとターゲット間でトラフィックがない状態が 350 秒続くと、NLB のフローテーブルからその接続が削除されます。 接続が追跡されなくなった後にクライアントがトラフィックを送信しようとすると、NLB は新しい接続を確立する必要があることを示す TCP RST を返します。 多くのアプリケーションでは、接続がタイムアウトしても問題ありません。 しかし、一部の場合は問題となることがあります。 例えば、定期的にデータを送信する IoT (Internet of Things) デバイスは、それぞれの送信時で少量のデータしか転送しません。 そのたびにデータが送信されるごとに、特に暗号化された接続を再度開くと、リソースを大量に消費し、コストがかかります。 接続がタイムアウトしないように、TCP キープアライブを設定して、確立された接続に対して決められた間隔でプローブ(※1)を送信することができます。このプローブにはデータは含まれていませんが、NLB などの中継システムでのアイドルタイマーをリセットすることができます。TCP キープアライブの設定方法の詳細については、以前の記事” Implementing long-running TCP Connections within VPC networking “を参照してください。 アプリケーションで長期間持続する永続的な TCP 接続が必要で、TCP キープアライブを使用できない場合は、NLB の TCP アイドルタイムアウトを変更できます。 TCP アイドルタイムアウトの更新時の考慮事項 各 NLB TCP リスナーのアイドル タイムアウト値は 60 ～ 6000 秒の範囲内で調整できます。 この変更はすでに進行中の接続には影響せず、新しい TCP 接続にのみ影響します。 その他のリスナの種類 (TLS、UDP など) では、現時点でアイドル タイムアウト値の調整はサポートされていません。 アイドルタイムアウト値を設定する前に、アプリケーションのニーズを理解し、TCP キープアライブが代替手段になり得るかを検討してください。 NLB の TCP アイドルタイムアウトは、アプリケーションの TCP アイドルタイムアウトよりも長く設定するのが適切です。 つまり、NLB ではなく、アプリケーションが接続管理とタイムアウトを処理することになります。 アイドルタイムアウトを高すぎる値に設定すると、フローテーブルがいっぱいになるリスクが高まります。テーブルがいっぱいになると、NLB が新しい接続を暗黙に拒否するようになります。 Amazon CloudWatch の新しいメトリクス (監視セクションで説明) を使って、接続拒否を監視する必要があります。 接続が拒否された場合は、TCP アイドルタイムアウトの値を小さくする必要があります。 TCP アイドルタイムアウトを AWS API/CLI で設定する手順 AWS は TCP アイドルタイムアウト機能を Network Load Balancer に導入するにあたり、新しい API を公開しました。以下の例は API の動作を示しています。 TCP アイドルタイムアウトの現在の値を確認するための、NLB リスナーについて説明します。 入力: aws elbv2 describe-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:000011112222:listener/network/NLBTest/123/123 出力: { "Attributes": [ { "Value": "350", "Key": "tcp.idle_timeout.seconds" } ] } TCP アイドルタイムアウトの値を変更する 入力: aws elbv2 modify-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:000011112222:listener/network/NLBTest/123/123 \ --attributes \ Key = tcp.idle_timeout.seconds,Value = 600 出力: { "Attributes": [ { "Value": "600", "Key": "tcp.idle_timeout.seconds" } ] } TCP アイドルタイムアウトを AWS マネジメントコンソールで設定する手順 次の手順では、 AWS マネジメントコンソール でタイムアウト値を変更する方法を示します。 1. NLB の TCP リスナーを見つけます。 図 3. NLB TCP リスナー 2. Attributes セクションで現在の TCP アイドルタイムアウト の値を確認します。 図 4. NLB リスナーの Attributes 3. リスナー属性の編集 セクションで、新しい TCP アイドルタイムアウト 値を入力します。 図 5. アイドルタイムアウトの設定 監視 Network Load Balancer の TCP アイドルタイムアウトの導入により、2 つの新しいメトリクス RejectedFlowCount (フローテーブルがいっぱいで拒否されたフロー数の合計) と RejectedFlowCount_TCP (同じ理由で拒否された TCP フロー数) が追加されました。 これらのメトリクスを使って、アイドルタイムアウト設定の影響を監視できます。 NLB がフローの受け入れを拒否し始めたときにあなたに通知を受け取れるように、 CloudWatch アラーム をセットアップすることをお勧めします。 RejectedFlowCount の増加は、タイムアウトを短縮する必要があることを示していて、より早くフローを削除し、フローテーブルが一杯になるのを防ぐことができます。 既存の NLB メトリクス (NewFlowCount、NewFlowCount_TCP、ActiveFlowCount、ActiveFlowCount_TCP など) は変更されません。 結論 NLB での TCP アイドルタイムアウトを設定すると、長時間接続するアプリケーションなどで特に接続管理をより詳細に制御できます。アイドルタイムアウトを調整し関連するメトリクスを監視することで、NLB のパフォーマンスを最適化し接続の問題を防ぐことができます。 本稿は、2024年9月3日に Networking & Content Delivery で公開された “ Introducing NLB TCP configurable idle timeout ” を翻訳したものです。翻訳は Solutions Architect の長屋が担当しました。

こんにちは。AWS ソリューションアーキテクトの木村です。 みなさん、Rufus（ルーファス）という単語を聞いたことがありますでしょうか？ Rufus（ルーファス）とは、生成 AI を搭載した Amazon の新たな対話型ショッピングアシスタントの名前です。Amazon.co.jp で「登山に必要なものは？」「5歳児と雨の日に遊べるゲーム」「この商品の耐久性はどう？」「電気カミソリの種類を比較して」などの質問に対応することができ、商品を見つけやすくなるようお客様をサポートします。 先日、ベータ版の日本への導入を発表 し、一部のお客様向けにリリースされています。買い物体験が変わると思うとワクワクしますね。ぜひアプリやサイトをチェックしてみてください！ 11 月に入り AWS 公式ウェブマガジン、builders.flash の記事が公開されていますので生成 AI に関係するものをピックアップしてみます。承認・検索・エージェントなど色々なシーンで生成 AI が活用されておりユースケースの参考になりますね。 生成AI(Claude3.5 Sonnet)による次世代型レビュー承認システムの実現 (DMM.com合同会社様) 日本一のポイントモールへとグロースさせるための「生成AIを用いた検索体験向上」チャレンジ (株式会社オズビジョン様) AWS IoTと生成AIを使って自宅の消費電力を測定・予測してみよう AWS Summit Japan 2024 Game Industry Booth の舞台裏 また最近、SNS 等で AWS re:Invent 2024 に関する投稿が増えてきているように感じます。今年も楽しみですね。12 月 6 日(金) の 12:00-13:00 に毎年恒例の「 新サービス・新機能の全てを1時間でサクッとお伝えするWebinar 」を開催しますので、ぜひご参加ください。 「 AWSジャパン生成AI実用化推進プログラム 」のお申し込みも募集しています。11 月 22 日が締め切りになりますので、検討されている方はお早めに意思表明をお願いします。 それでは、11 月 11 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社ペライチ様、Amazon Bedrock を使用したホームページ自動生成サービスを開発 株式会社ペライチ様は、ホームページ作成サービス「ペライチ」を運営しています。ペライチは、誰でも簡単にホームページを作って運用できるように豊富なテンプレートが用意されていますが、イメージをホームページの形に落とし込むのが難しく公開まで至らないユーザーが存在するといった課題がありました。そこで、ユーザーが任意のサイトのURLを入力すると、そのサイトの特徴や用途に応じた情報を生成 AI が抽出し、それに基づいた最適なテンプレートを選択しサンプルのホームページを生成して提案する「ペライチクリエイトアシスタント」を開発しました。入力された URL 情報から WEB ページの情報抽出・説明・要約する処理は、AWS Step Functions と AWS Lambda そしてAmazon Bedrock を活用しています。現在、 無料モニターを受け付けています 。この取り組みは、ペライチ様に AWS ジャパン生成 AI 実用化推進プログラム に参加いただき、企画ワークショップ、 プロトタイピングプログラム による実装支援を AWS から提供しています。 AWS生成AI国内事例ブログ: 株式会社 JPX 総研様、生成 AI を活用したタグ付により適時開示資料・銘柄検索における検索性の向上を実現 JPX 総研様は、JPX グループ等が保有するデータを網羅的にカタログ化するポータルサイト「 JPxData Portal 」の提供を行っています。200 種類を超える幅広いデータを提供する一方で、データの種類が多すぎて探しにくいといった課題を抱えていました。そこで、全ての適時開⽰資料の PDF をAmazon Bedrock に連携し、⽣成 AI ( Claude ) を活⽤してファイル内の文章からタグを生成して、キーワードを付与する取り組みを行いました。その結果、ユーザーは「持続可能性」や「グッドデザイン」といったタグ情報を利用して検索することができるようになり、目的の開示情報を容易に探せるようになりました。また AWS Lake Formation によるアクセス管理を導入したことで、生成されたタグ情報の他システムへの容易な連携や、運用の効率化といったメリットも享受されています。 AWS生成AI国内事例ブログ: IQVIAサービシーズ ジャパン合同会社様、社内 RAG チャットシステムの構築により検索・調査に費やしていた時間を 93 % 削減 IQVIA 様は、ヘルスケアや人々の健康の進展に取り組むお客様を支援するグローバルリーディングカンパニーです。臨床試験などの業務においては、規制等が書かれているドキュメントを都度確認する必要があり、この検索・調査に費やす時間が多大にかかっているという課題がありました。そこで Amazon Bedrock のナレッジベースを用いた RAG ベースの AI チャット問い合わせ対応ソリューションを構築しました。この RAG チャットソリューションを IQVIA 様 全体に導入し、約 2 ヶ月で社内ユーザー 321 人の利用を達成。月あたりの検索・調査に費やしていた時間を 93 % 削減することができたそうです。また、RAG ソリューションの検証と構築は、担当者 １ 名のみで実施し、約 2 ヶ月という短期間で実現されました。フルサーバレスな構成を採用することで、開発・運用コストの最適化も実現されています。 AWS生成AI国内事例ブログ: 株式会社アーベルソフト様、 災害監視用の自社開発モデルの代わりとして Amazon Bedrock を活用することで、 約45 %の精度向上・年間コスト約 260 時間削減を達成 アーベルソフト様は、災害写真情報サービス「 ビューちゃんねる（防災 DX） 」を開発しており、複数の自治体に向けてサービスを提供しています。その中で自社で開発した画像認識モデルを用いて、冠水を自動判定する Web サービスを提供しているのですが、機械学習モデルの作成や精度改善にかかるコストに課題を抱えていました。そこで、Amazon Bedrock 上で利用可能なマルチモーダルモデルである Claude 3.5 Sonnet の導入を行いました。その結果、精度が従来から約 45 %向上、開発・運用コストが年間約 260 時間削減、さらに交通事故や火災などのこれまで行なっていないユースケースに対応することが可能になった、といった効果を得ることができました。削減できたコストはお客様に還元することを検討しており、最終的には約 40 %低減させた価格で提供できる見込みとなっているようです。 ブログ記事「製造業における技能継承への生成 AI・音声・映像の活用とサンプルソースのご紹介」を公開 製造業における技能継承は、日本のモノづくりの競争力を維持する上で非常に重要な課題となっています。本ブログでは、生成 AI や音声・映像技術を活用した技能伝承支援ソリューションを紹介しています。Amazon Bedrock が過去のデータや膨大な資料から効率的に解決策を推測し、Amazon Chime の Chime SDK を利用してベテランエンジニアがリモートから映像や音声を通じて若手を支援するソリューションとなっています。こちらは GitHub にて公開しています。 ブログ記事「Amazon Bedrock 上で基盤モデルのコストと利用状況を追跡できる社内 SaaS サービスを構築する」を公開 この記事では、マルチテナント環境で Amazon Bedrock を使用して基盤モデルにアクセスする社内 SaaS プラットフォームの構築方法について紹介しています。特に、テナントごとの使用量とコストの追跡、およびテナントごとの使用量制限などのコントロールに焦点を当てています。ソリューションは GitHub にて公開しています。社内で生成 AI の管理をされている方は是非ご覧ください。 ブログ記事「AWS Supply Chain と Amazon Q を活用して製造業における運用の優秀性（オペレーショナルエクセレンス）を推進」を公開 製造業の企業は、生産計画や材料管理から可視性やデータ統合に至るまで、サプライチェーン業務全体でさまざまな課題に直面しています。このブログでは、 AWS Supply Chain と Amazon Q を連携させ、サプライチェーンの課題に対する解決策をどのように提供するのかを紹介しています。 ブログ記事「【開催報告 & 資料公開】今から始める！Publisher 向け生成 AI」を公開 2024 年 10 月 10 日に、新聞・出版・メディア業界のお客様向けに、「AWS Media Seminar 2024 – 今から始める！Publisher 向け生成 AI」というテーマでセミナーを開催しました。このブログは、セミナーの開催報告記事です。コネヒト株式会社様からは mamari での生成 AI 活用による検索機能向上、株式会社朝日新聞社様からはコンテンツ制作支援サービス ALOFA における生成 AI 活用について登壇いただいています。資料と動画を公開していますのでぜひご覧ください。 ブログ記事「Amazon Bedrock Guardrails を使用したモデルに依存しない安全対策を実装する」を公開 Amazon Bedrock Guardrails は現在、Amazon Bedrock 外で利用可能な LLM のユーザー入力とモデル応答を評価するための ApplyGuardrail API をサポートしています。この記事では、一般的な生成 AI アーキテクチャで ApplyGuardrail API を使用する方法について紹介しています。 ブログ記事「IoT@Loft #25 進化するIoTカメラソリューション – 生成AIで拓く新時代」を公開 こちらは、2024 年 10 月 30 日に開催された 「IoT@Loft #25 進化する IoT カメラソリューション – 生成 AI で拓く新時代」の開催報告記事です。 AI/IoT ネイティブカメラを扱っているi-PRO 株式会社様の生成AI活用の取り組み、株式会社 USEN 様による店舗 DX をテーマにした IoT×AI カメラソリューションなどが紹介されています。また当日のデモ展示の様子も書かれています。 サービスアップデート Amazon Q Developer で、Datadog および Wiz 向けプラグインが一般提供開始 AWS マネジメントコンソールで Amazon Q とチャットする際、お客様は自然言語を使用して Datadog と Wiz サービスの情報にアクセスできるようになりました。例えば、「@datadog アクティブなアラートはありますか？」や「@wiz 今日のトップ3のセキュリティ問題は何ですか？」といった質問を投げかけることで情報をより速く見つけ、作業の高速化を図ることが可能です。詳細は ブログ を参照ください。 Amazon Q Developer Pro にて、ユーザーアクティビティの閲覧が可能に Amazon Q Developer Pro ティアで、管理者がサブスクリプションユーザーのアクティビティをより詳細に把握できるようになりました。管理者はユーザーの最終アクティビティ情報を閲覧することが可能です。これにより非アクティブなサブスクリプションを簡単に特定できるようになります。また送信メッセージ数や AI が生成したコード行数などが記載されたユーザー別アクティビティレポートも作成できるようになりました。 Amazon Q Developerにて以下の新機能が追加されました ・Java 8/11 から 17 へのコード変換機能がエージェンティックワークフローにより強化されました ・Q Developer が全ての YAML ファイルと JSON ファイルに対してのコード提案をサポートするようになりました ・Ruby、Scala、SQL に対してより長い複数行のインラインコード提案をサポートするようになりました ・Dart、Lua、R、Swift、SystemVerilog、PowerShell、Vue に対してのインラインコード提案をサポートするようになりました AWS B2B Data Interchangeにて生成AIベースのEDIマッピング機能を提供 AWS B2B Data Interchange は、EDI 規格のデータの変換をフルマネージドで行うサービスです。今回、AWS B2B Data Interchange にて生成 AI を使用した EDI マッピングコードを生成する機能が提供されました。この新機能により、双方向の EDI マッピングの作成とテストのプロセスが迅速化され、EDI ワークロードを AWS に移行する際の時間、労力、コストが削減されます。 AWS CloudTrail Lake にて AI 機能で強化されたログ分析が可能に AWS CloudTrail Lake は、アクティビティログや AWS Config の設定項目を保存し分析するためのデータレイクサービスです。今回、AWS CloudTrail Lakeに 2 つの AI 機能が追加されました。1 つは、自然言語によるクエリ生成機能です。この機能により「先週、権限不足で失敗したAPIイベントは何？」といったような質問で AWS アクティビティに関する情報が得られるようになりました。2 つ目は、クエリ結果要約機能です。この機能により、AWSアクティビティログから意味のあるインサイトを得るために必要な時間と労力が大幅に削減できるようになりました。現時点では英語のみのサポートとなっています。 SageMaker Model Registry がモデルのリネージをサポートし、モデルガバナンスを向上 Amazon SageMaker Model Registry が機械学習モデルのリネージ追跡をサポートするようになりました。これにより、データ準備やトレーニングからモデル登録、デプロイメントまで、ML ワークフローの各ステップに関する情報を自動的に取得し保持することが可能になります。これによりモデルライフサイクル全体の可視性が向上し、モデルガバナンスが改善されます。 Amazon SageMaker Model Registryが機械学習モデルのライフサイクルステージをサポート Amazon SageMaker Model Registry が ML モデルのライフサイクルステージをサポートするようになりました。今回のリリースにより、モデルレジストリ内の ML モデルに対して、開発、テスト、本番環境などのカスタムステージを定義できるようになりました。これにより、トレーニングから推論まで、ライフサイクルの異なるステージ間でのモデルの遷移を簡単に追跡および管理できます。 Amazon SageMaker ノートブックインスタンスが Trainium1 および Inferentia 2 ベースのインスタンスをサポート Amazon SageMaker ノートブックインスタンスで、Trainium1 (Trn1) および Inferentia2 (Inf2) ベースの EC2 インスタンスの一般提供を開始しました。Trn1 は生成 AI モデルのトレーニング、Inf2 は 推論において低いコストで高いパフォーマンスを実現します。Amazon SageMaker 上で、コスト効率良く LLM などを扱うことができるようになりました。 Amazon EC2 キャパシティブロックが新しいリージョンに拡大 EC2 キャパシティブロックとは、需要の高い GPU インスタンスを、必要な時間分予約することができる機能です。今回、P5 インスタンスの EC2 キャパシティブロックが 2 つの新しいリージョン（オレゴンおよび東京）で利用可能になりました。EC2 キャパシティブロックを使用すると、1〜64 インスタンス（512 GPU）のサイズで、最大 8 週間前から最大 28 日間の GPU キャパシティを予約することができます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。