本日の主なトピック #
- Amazon EC2: M4 Max Mac インスタンスが一般提供開始 (GA)。M1 Ultra 比でビルド性能が最大 25% 向上。
- Amazon Route 53:
.ai,.shopなど 10 種類の新しいトップレベルドメイン (TLD) のサポートを開始。 - AWS Security Agent: GitHub Enterprise Cloud をサポートし、プライベートリポジトリの自動コードレビューや修正が可能に。
- Amazon EC2 (Graviton4): 最大サイズ
48xlargeが登場。EBS 帯域幅 300 Gbps、144万 IOPS を実現。 - Amazon Connect: Step-by-Step Guides で条件付き UI ロジックとリアルタイムデータ更新が可能に。
¥3,520 Amazonで見る
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本(ソフトカバー) – 2025/7/11
Amazon Connect Step-by-Step Guides が条件付きロジックとリアルタイム更新を追加 #
投稿日: 2026年01月23日
何ができるようになったのか #
Amazon Connect Step-by-Step Guides において、ユーザーの操作に応じて変化する条件付きユーザーインターフェース (UI) を作成できるようになりました。 具体的には、以前のフィールドへの入力内容に基づいて、ドロップダウンメニューでフィールドの表示/非表示を切り替えたり、デフォルト値を変更したり、必須項目を調整したりすることが可能です。 また、フローモジュールなどの Connect リソースから、指定した間隔でデータを自動的に更新 (リフレッシュ) する機能も追加されました。
何が嬉しいのか #
エージェント (オペレーター) の操作状況に合わせて必要な情報だけを表示できるため、ワークフローが効率化され、入力ミスや混乱を減らすことができます。 また、自動更新機能により、エージェントは常に最新の情報を参照しながら業務を行えるようになり、古いデータに基づく誤った対応を防ぐことができます。
これまでとどう変わるのか #
- これまで: ガイドの画面構成は比較的静的であり、入力内容に応じた動的なフィールドの出し分けを行うには、複数のビューを作成して遷移させるなどの複雑な設定が必要な場合がありました。また、画面上のデータは表示時点のものであり、リアルタイムな更新には手動での再読み込み等が必要でした。
- これから: 設定だけで動的なフィールド制御が可能になり、画面遷移を伴わずに直感的な UI を構築できます。データの自動更新により、常に最新の状態が維持されます。
具体的なユースケース #
- 条件分岐のある申込み受付: 顧客が「配送希望」を選択した場合のみ、住所入力フィールドを表示する。
- リアルタイムなステータス確認: バックエンドシステムでの処理状況を定期的にポーリングし、完了した時点でエージェントに通知や次のステップを提示する。
Amazon Connect Step-by-Step Guides は、コンタクトセンターのエージェントに対して、顧客対応時の推奨アクションや手順を画面上に提示する機能です。 主な特徴は以下の通りです。
- エージェントのデスクトップ画面に統合されたワークフロー表示
- ノーコード/ローコードでの画面構築 (UI)
- AWS Lambda などと連携したバックエンド処理の実行
Amazon EC2 M4 Max Mac インスタンスの一般提供開始 (GA) #
投稿日: 2026年01月23日
何ができるようになったのか #
Apple の最新ハードウェアである Mac Studio (M4 Max チップ搭載) をベースとした、新しい Amazon EC2 Mac インスタンス「M4 Max Mac インスタンス」が一般提供開始 (GA) となりました。 これらのインスタンスは、16コア CPU、40コア GPU、16コア Neural Engine、および 128GB のユニファイドメモリを搭載しています。
何が嬉しいのか #
iOS、macOS、watchOS、visionOS などの Apple プラットフォーム向けアプリケーションのビルドやテストにおいて、高いパフォーマンスを発揮します。 特に、以前の世代である Amazon EC2 M1 Ultra Mac インスタンスと比較して、アプリケーションのビルドパフォーマンスが最大 25% 向上しています。これにより、開発サイクルを短縮し、より迅速なリリースが可能になります。
これまでとどう変わるのか #
- これまで: EC2 Mac インスタンスとして、M1 Mac、M2 Mac (Pro/Max)、M1 Ultra Mac などが提供されていました。大規模なビルドには M1 Ultra などが利用されていましたが、より高い処理能力が求められていました。
- これから: M4 Max チップを搭載したインスタンスが選択可能になり、特に計算負荷の高いビルドやテストワークロードに対して、より優れたパフォーマンスとコスト効率を提供します。ネットワーク帯域幅は最大 10 Gbps、EBS 帯域幅は最大 8 Gbps をサポートします。
具体的なユースケース #
- 大規模な iOS アプリの CI/CD: 複雑な依存関係や多数のテストケースを持つアプリのビルド時間を短縮する。
- グラフィックス重視のアプリテスト: 40コア GPU を活用し、レンダリングや画像処理を伴うアプリケーションの自動テストを実行する。
Amazon EVS が複数の VMware NSX Edge Gateway のサポートを開始 #
投稿日: 2026年01月23日
何ができるようになったのか #
Amazon Elastic VMware Service (Amazon EVS) において、VMware Software-Defined Data Centers (SDDC) 内に複数の VMware NSX Tier-0 Gateway をデプロイできるようになりました。
何が嬉しいのか #
複数の Tier-0 Gateway を使用することで、ネットワークトラフィックを複数の NSX Edge Cluster に分散させ、パフォーマンスと拡張性を向上させることができます。 また、ワークロード環境ごとにネットワークを分離し、ゲートウェイごとに異なるセキュリティポリシーを適用するといった、より高度なネットワークセグメンテーションが可能になります。 さらに、本番環境への影響を最小限に抑えながら、ネットワーク設定の検証やゲートウェイのアップグレードを行うための独立したテスト環境を作成することも容易になります。
これまでとどう変わるのか #
- これまで: SDDC 内で利用できる NSX Tier-0 Gateway は単一であったか、構成の柔軟性が限られており、すべてのトラフィックが同じゲートウェイを経由する必要があった可能性があります。
- これから: 複数のゲートウェイを展開できるため、ビジネス要件に合わせてネットワークトポロジーを柔軟に設計でき、運用効率を維持しながらネットワークの分離や負荷分散を実現できます。
具体的なユースケース #
- 本番環境と開発環境の完全分離: 本番用と開発用で異なる Tier-0 Gateway を使用し、ルーティングとセキュリティポリシーを完全に分離する。
- トラフィックの負荷分散: 高トラフィックなアプリケーション専用のゲートウェイを設け、他のシステムへの影響を防ぐ。
Amazon RDS for Oracle がマルチテナント構成でのレプリカをサポート #
投稿日: 2026年01月23日
何ができるようになったのか #
Amazon RDS for Oracle において、Oracle マルチテナント構成 (Multi-Tenant Configuration) でセットアップされたインスタンスに対して、データベースレプリカ (リードレプリカなど) を作成できるようになりました。 これにより、1つのコンテナデータベース (CDB) 内に複数のプラガブルデータベース (PDB) をホストする構成でも、レプリケーション機能を利用できます。
何が嬉しいのか #
マルチテナント構成による集約でコスト削減や管理の簡素化を図りつつ、同時にレプリカを利用して読み取りワークロードの分散 (スケーリング) や、クロスリージョンレプリカの構築が可能になります。 また、災害対策 (DR) のシナリオにおいて、レプリカを新しいスタンドアロンデータベースとして昇格させたり、スイッチオーバーを実行してプライマリとレプリカの役割を入れ替えたりすることで、迅速な復旧が可能になります。
これまでとどう変わるのか #
- これまで: RDS for Oracle のマルチテナント構成では、Amazon RDS が管理するレプリカ機能 (Oracle Data Guard を利用した自動的なレプリケーション) がサポートされていなかったか、制限があった可能性があります。
- これから: マルチテナント環境でも、非マルチテナント環境と同様に、マウントモードまたは読み取り専用モードでレプリカを作成・管理できるようになりました。
具体的なユースケース #
- 読み取り負荷の分散: 分析レポート作成などの重い読み取りクエリを、マルチテナント構成のレプリカ側で処理させ、プライマリへの負荷を減らす。
- ディザスタリカバリ (DR): 別のリージョンにレプリカを作成し、大規模な障害発生時にフェイルオーバーする。
Amazon Route 53 Domains が .ai などの新しいトップレベルドメイン (TLD) をサポート #
投稿日: 2026年01月23日
何ができるようになったのか #
Amazon Route 53 Domains において、新たに 10 種類のトップレベルドメイン (TLD) の登録と管理が可能になりました。
追加された TLD は以下の通りです:
.ai, .nz, .shop, .bot, .moi, .spot, .free, .deal, .now, .hot
何が嬉しいのか #
特に人工知能 (AI) 関連の企業やプロジェクトで非常に人気の高い .ai ドメインが、AWS 上で直接取得・管理できるようになりました。
これまでは .ai ドメインを取得するために別のレジストラを利用する必要があった場合でも、今後は AWS Route 53 に一元化でき、DNS 設定や自動更新の管理が容易になります。
また、.shop (Eコマース向け) や .bot (チャットボット向け) など、ビジネスの目的に特化したドメインも選択肢に加わりました。
これまでとどう変わるのか #
- これまで: Route 53 でサポートされている TLD は多数ありましたが、
.aiなどの特定の人気 TLD は未サポートでした。 - これから: AI ブームで需要が急増している
.aiを含む、より多様なドメイン名を AWS コンソールから直接登録できます。
具体的なユースケース #
- AI スタートアップ: サービス名に
.aiを付けたドメイン (例:my-gen-ai.ai) を取得し、Route 53 でホストする。 - Eコマースサイト: ブランド名に
.shopを使用してオンラインストアを開設する。
.ai は本来、イギリス領アンギラ (Anguilla) の国別コードトップレベルドメイン (ccTLD) ですが、“Artificial Intelligence” の略称として広く利用されています。
AWS Outposts racks がルワンダで利用可能に #
投稿日: 2026年01月22日
何ができるようになったのか #
AWS Outposts racks の配送と設置が、ルワンダ (Rwanda) のデータセンターおよびオンプレミス拠点で可能になりました。
何が嬉しいのか #
ルワンダ国内にデータを保持する必要があるデータレジデンシー要件への対応や、現地のオンプレミスシステムに対する超低遅延なアクセスが必要なワークロードを、AWS の一貫したインフラストラクチャ上で実行できるようになります。
これまでとどう変わるのか #
- これまで: ルワンダは AWS Outposts racks のサポート対象地域に含まれていませんでした。
- これから: ルワンダの拠点に物理的な AWS インフラストラクチャ (ラック) を持ち込み、ハイブリッドクラウド環境を構築できます。
具体的なユースケース #
- 通信・金融業界: 国内法規制によりデータを国外に出せないシステムの AWS 化。
- 工場の自動化: 現地の製造設備とミリ秒単位の通信が必要な制御システム。
AWS Config が 13 の新しいマネージドルールを追加 #
投稿日: 2026年01月22日
何ができるようになったのか #
AWS Config に、セキュリティ、耐久性、運用などのユースケースに対応する 13 個の新しいマネージドルールが追加されました。 追加されたルールの主な対象サービスと内容は以下の通りです。
- Amazon Cognito: 削除保護、MFA の有効化、カスタム認証の脅威チェック
- AWS CloudFormation: サービスロールのチェック、削除保護の確認
- Amazon ECS: キャパシティプロバイダーの終了保護、タスク定義での EFS 暗号化、非 root/非管理者ユーザーの使用
- その他: Aurora Global Database の保管時の暗号化、EBS スナップショットのパブリックアクセスブロック、CloudFront のキーグループ有効化、SES の TLS 送信必須化
何が嬉しいのか #
これらのルールを使用することで、AWS 環境全体のコンプライアンス状況やセキュリティ体制をより広範囲に自動チェックできるようになります。 例えば、Cognito ユーザープールが意図せず削除されるリスクがないか、ECS タスクが推奨されるセキュリティ設定 (非 root 実行など) で構成されているかなどを簡単に評価できます。
これまでとどう変わるのか #
- これまで: これらの特定のチェック項目については、カスタムルールを作成するか、手動で確認する必要がありました。
- これから: マネージドルールとして提供されるため、設定を有効にするだけで即座に評価を開始できます。また、Conformace Packs を使用して組織全体に一括展開することも可能です。
具体的なユースケース #
- コンテナセキュリティの強化: ECS タスク定義がルートユーザーで実行されないように監視するルール (
ECS_TASK_DEFINITION_LINUX_USER_NON_ROOT) を適用する。 - 誤削除の防止: 本番環境の CloudFormation スタックや Cognito ユーザープールに削除保護が設定されているかを監査する。
AWS Security Agent が GitHub Enterprise Cloud をサポート #
投稿日: 2026年01月22日
何ができるようになったのか #
AWS Security Agent が GitHub Enterprise Cloud をサポートしました。 これにより、GitHub Enterprise Organization を AWS Security Agent に接続し、プライベートリポジトリに対して AI を活用したセキュリティ機能を利用できるようになります。
何が嬉しいのか #
開発チームは、GitHub のワークフローに直接統合された形で、以下の高度なセキュリティ分析機能を活用できます。
- 自動コードレビュー: 新しいプルリクエストに対して包括的なセキュリティレビューを自動実行し、マージ前に脆弱性や内部セキュリティ要件への準拠状況を特定します。
- ペネトレーションテスト統合: ペネトレーションテスト活動中にコードベースを分析し、潜在的な弱点や攻撃ベクトルを特定するために利用できます。
- 自動コード修正: 特定されたセキュリティ問題に対して、推奨される修正を含むプルリクエストを AWS Security Agent が自動的に作成し、修正プロセスを加速させることができます。
これまでとどう変わるのか #
- これまで: AWS Security Agent のサポート範囲は限られており、GitHub Enterprise Cloud のプライベートリポジトリを直接対象とすることはできなかったか、制限がありました。
- これから: GitHub Enterprise Cloud のリポジトリに対しても、AWS Security Agent の AI 駆動のセキュリティ分析と自動修正機能をフルに活用できるようになります。
具体的なユースケース #
- セキュリティシフトレフト: プルリクエスト作成時に自動的にセキュリティ診断を行い、脆弱性の混入を未然に防ぐ。
- ペネトレーションテストの効率化: ペネトレーションテスト中に発見された脆弱性に対し、修正コード (PR) を自動生成させて対応時間を短縮する。
EC2 Auto Scaling がグループ削除保護のための新しいメカニズムを導入 #
投稿日: 2026年01月23日
何ができるようになったのか #
EC2 Auto Scaling において、Auto Scaling Group (ASG) の誤削除を防ぐための2つの新しい機能が導入されました。
- 新しい IAM 条件キー
autoscaling:ForceDelete:DeleteAutoScalingGroupアクション実行時にForceDeleteパラメータ (インスタンス実行中でも強制削除するかどうか) の使用を制御できます。 - グループレベルの削除保護機能: ASG 自体に削除保護設定 (Deletion Protection) を適用できるようになりました。ASG の作成時または更新時に設定可能です。
何が嬉しいのか #
これらを組み合わせることで、稼働中のインスタンスを含む重要な ASG が誤って削除されるリスクを大幅に低減できます。
例えば、本番環境の重要な ASG に対して削除保護を有効にし、さらに IAM ポリシーで ForceDelete の使用を制限することで、意図しないサービス停止に対する多層的な防御が可能になります。
これまでとどう変わるのか #
- これまで: ASG 自体には、ELB や RDS のような明示的な「削除保護フラグ」がありませんでした。また、
ForceDeleteオプションを使用した強制削除を IAM レベルで細かく制御する専用の条件キーもありませんでした。 - これから: ASG リソースレベルでの削除保護と、IAM ポリシーによる操作レベルの制限の双方を利用して、より堅牢な運用が可能になります。
具体的なユースケース #
- 本番環境の保護: 本番用 ASG の
deletion-protectionを有効化し、管理者以外の IAM ユーザーにはautoscaling:ForceDeleteを拒否するポリシーを適用する。 - 誤操作防止: インスタンスがまだ起動している ASG を、確認なしにコマンド一発で削除してしまう事故を防ぐ。
ForceDelete パラメータは、ASG 内にインスタンスが残っていても、それらを終了させて ASG を削除するためのオプションです。通常、インスタンスがある状態で ASG を削除しようとするとエラーになりますが、このオプションを使うと強制的に削除できます。
Amazon EC2 (Graviton4搭載) に 48xlarge および metal-48xl サイズが登場 #
投稿日: 2026年01月22日
何ができるようになったのか #
AWS Graviton4 プロセッサを搭載した Amazon EC2 インスタンス (C8gb, M8gb, R8gb) において、最大サイズとなる 48xlarge および metal-48xl (C8gb と R8gb のみ) が利用可能になりました。
何が嬉しいのか #
これらの新しいサイズは、非アクセラレーテッド EC2 インスタンスの中で最高の EBS パフォーマンスを提供します。
- EBS 帯域幅: 最大 300 Gbps
- EBS IOPS: 最大 1,440,000 (1.4M) IOPS
- ネットワーク帯域幅: 最大 400 Gbps
これにより、ストレージI/Oがボトルネックになりやすい大規模なデータベース、分析ワークロード、および密結合されたクラスターアプリケーションのパフォーマンスを大幅に向上させることができます。
これまでとどう変わるのか #
- これまで: Graviton4 インスタンスのラインナップにおいて、これほどの巨大なリソースと I/O 性能を持つサイズは提供されていなかったか、Graviton3 世代の最大サイズに留まっていました。
- これから:
48xlargeの登場により、スケールアップの選択肢が広がり、単一インスタンスで処理できるワークロードの限界が引き上げられました。
具体的なユースケース #
- 大規模データベース: 高速な I/O を必要とするインメモリデータベースや大規模なリレーショナルデータベース。
- HPC とビッグデータ: Elastic Fabric Adapter (EFA) を活用した、低遅延かつ高スループットなクラスターコンピューティング。
b (例: C8gb) は、EBS 最適化のパフォーマンスが強化されたインスタンスファミリーであることを示しています (Block storage optimized)。
Amazon WorkSpaces で Microsoft Office / Visio / Project 2024 が利用可能に #
投稿日: 2026年01月22日
何ができるようになったのか #
Amazon WorkSpaces Personal および Core において、以下の新しい Microsoft LTSC (Long-Term Servicing Channel) 2024 アプリケーションが利用可能になりました。
- Microsoft Office LTSC Professional Plus 2024 / Standard 2024
- Microsoft Visio LTSC Professional 2024 / Standard 2024
- Microsoft Project Professional 2024 / Standard 2024
何が嬉しいのか #
最新の Microsoft Office アプリケーションを WorkSpaces 上で利用できるため、組織全体でモダンでセキュアなデスクトップ環境を標準化できます。 既存のアプリケーション管理ワークフローを使用して、新規または既存の WorkSpaces インスタンスにこれらのアプリを追加可能です。
これまでとどう変わるのか #
- これまで: Office 2021 や 2019 などの旧バージョンが提供されていました。
- これから: 2024 バージョンの機能とサポートを享受できるようになります。特に LTSC 版は機能が固定されており、長期的な安定性が求められる環境に適しています。
具体的なユースケース #
- VDI 環境のモダナイゼーション: 従業員の仮想デスクトップ環境を最新の Office スイートにアップグレードする。