目次

AWSサービス一覧(2026年版 / テーブル)

取得元: AWS General Reference「Service endpoints and quotas」 取得日: 2026-04-15(一覧)/ 2026-04-26(コア 30 完全ガイド再更新) 注: 重要度は一般的な利用頻度ベースの目安です(プロジェクト要件で変動)。

  • 総サービス数: 275
  • ライフサイクル注記: Sunset未到来サービスは行を残し、キーワード にステータスを明記。EOS到来済みは削除。
  • 完全ガイド版: コア 30 サービス+次の 30(Tier 2)の計 60 サービス が完全ガイド v2.0(各 700〜2,600 行)に到達。参考文献の web fetch クロール を 2026-04-26 に実施し、AWS 公式 / ベンダー / OSS / 主要テックブログを横断して整備済み。

📘 完全ガイド版(コア30サービス)

2026-04-26 更新(v2.1):以下の 30 サービス完全ガイド v2.0(各 1,300〜2,600 行、Mermaid 図、ユースケース 10+ パターン、比較表、ベストプラクティス、トラブルシューティング、2025-2026 最新動向、参考文献多数)として整備しています。今回の更新では 参考文献を実際に web fetch でクロール し、AWS 公式・ベンダードキュメント・OSS ドキュメント・主要テックブログから 200 件以上の参考文献を更新・追加しました。

拡充済みコアサービス一覧

カテゴリ サービス 行数 主要トピック 2026 最新動向
Compute EC2 1,116 インスタンスタイプ、Graviton、Auto Scaling、Spot Graviton5 (M9g/C9g/R9g)、3nm、192 コア
Compute Lambda 1,116 イベントソース、SnapStart、同時実行、Function URL Durable Functions GA、SnapStart Python/.NET、Recursive Loop Detection
Containers ECS 1,997 Fargate、Service Connect、Auto Mode、ECS Anywhere Express Mode GA、Service Connect mTLS、Auto Mode CW Logs 統合
Containers EKS 2,382 EKS Auto Mode、Karpenter、IRSA、Pod Identity Auto Mode GA、Pod Identity GA、Karpenter v1
Storage S3 1,519 ストレージクラス、Iceberg、Vector Buckets、Express One Zone S3 Vectors GA(31 リージョン)、S3 Tables GA、Iceberg V3
Network VPC 1,407 サブネット設計、Transit Gateway、PrivateLink、Lattice RDS/ElastiCache IPv6、VPC Endpoints
Network CloudFront 1,857 CDN、Lambda@Edge、Functions、KeyValueStore HTTP/3 完全対応、HTTPS DNS Records
Network Route 53 1,378 ルーティングポリシー、ARC、DNSSEC、Resolver Accelerated Recovery GA(2026-04)
Network ALB 1,986 リスナールール、mTLS、HTTP/3、認証統合 mTLS GA、TLS 1.3 拡張
Network API Gateway 1,359 REST/HTTP/WebSocket、Authorizer、VPC Link Bedrock AgentCore Gateway 統合、OAuth 2.1 強化
Database RDS 1,502 エンジン、Multi-AZ、Blue/Green、Proxy Blue/Green 5 秒ダウンタイム、PostgreSQL 17/18、MySQL 8.4 LTS
Database Aurora 1,981 Serverless v2、Global Database、DSQL、Babelfish DSQL 31 リージョン、多言語コネクタ、IDE 統合
Database DynamoDB 1,911 キー設計、GSI/LSI、Streams、Global Tables Multi-account Global Tables、Standard-IA、PartiQL
Database ElastiCache 1,638 Redis OSS、Valkey、Memcached、Serverless Valkey 8.1(メモリ 20% 改善)、Redis Extended Support
Messaging SQS 1,717 Standard/FIFO、DLQ、Long Polling、ESM FIFO High-Throughput、Per-Message Filtering
Messaging SNS 2,247 Fan-out、SMS、Mobile Push、フィルタリング FCM v1 移行、Web Push、Message Data Protection
Integration EventBridge 2,261 Bus、Pipes、Scheduler、Schema Registry Pipes 拡張、Scheduler 強化、AI ルーティング
Integration Step Functions 1,890 ASL、Distributed Map、Express、200+統合 Bedrock AgentCore 統合(28+ サービス)、JSONata v2
Security IAM 2,037 ポリシー評価、SCP、PB、Identity Center、ABAC Policy Autopilot(AI 生成)、RCP、SPIFFE/SPIRE 連携
Security KMS 2,379 エンベロープ暗号化、Multi-region Key、XKS、PQC ML-KEM/ML-DSA(量子耐性)、PQC TLS 拡張
Security Secrets Manager 2,032 自動ローテーション、ESO、CSI Driver Cross-Region Replication、AI Secret Scanning、Batch API
Security Cognito 1,856 User Pool、Identity Pool、SAML/OIDC、Passkeys WebAuthn/Passkeys ネイティブ、Adaptive Auth
Identity CloudTrail 2,150 Management/Data Event、Lake、Insights Lake SQL 分析、Query Generator(自然言語)、Network Activity
Observability CloudWatch 1,388 Metrics、Logs、Alarms、Application Signals Application Signals SLO、EKS Add-on v5、Kiro IDE 統合
IaC CloudFormation 1,793 Template、StackSet、Hooks、Registry、Guard IaC Generator GA、cfn-guard、Terraform/Pulumi 比較
IaC CDK 1,326 Construct、L1/L2/L3、Pipelines、CDKTF/cdk8s CDK Mixins 安定化、EKS v2 GA、Q Developer 統合
Analytics Athena 1,450 Trino/Presto、Federated Query、Iceberg、Spark Iceberg REST Catalog、Delta Lake UniForm、Lake Formation 統合
Analytics AWS Glue 1,583 Data Catalog、ETL、Crawler、DataBrew Glue 5.1(Spark 3.5.6)、Data Quality Rule Labeling、Hudi 1.0
AI/ML SageMaker AI 1,944 Studio、JumpStart、HyperPod、Model Monitor SageMaker Lakehouse、HyperPod EKS/Trainium2、NVIDIA MIG
AI/ML Bedrock 2,626 Foundation Models、Agents、Knowledge Bases、Guardrails AgentCore Harness/CLI/Skills、Multi-agent、KB マルチソース

合計: 30 サービス / 約 53,800 行 / 100+ Mermaid 図 / 参考文献 600+ 件(うち 200+ が今回更新)

完全ガイドの構成

各完全ガイドは以下の章立てで統一されています:

  • 概要・課題・特徴・アーキテクチャ
  • コアコンポーネント詳細
  • 主要ユースケース 10+ パターン + 適性マトリクス
  • 設定・操作の具体例
  • 他の類似ツールとの比較(OSS、他クラウド、商用 SaaS)
  • クライアントとエコシステム(CLI、SDK、IaC、サードパーティ)
  • ベストプラクティス(✅/❌ 記号)
  • トラブルシューティング(症状/原因/対策の表形式)
  • 2025-2026 最新動向
  • 学習リソース・参考文献(公式ドキュメント10+ + ベンダー/OSS/テックブログ)
  • 実装例(小/中/大規模)・導入ロードマップ・実装チェックリスト

参考文献ポリシー(2026-04-26 更新)

各ガイドの参考文献は次の 4 層で構成しています:

  1. AWS 公式docs.aws.amazon.com、AWS Blog、aws.amazon.com/whats-new)
  2. ベンダードキュメント(HashiCorp、Cloudflare、Datadog、Splunk、Hugging Face、Anthropic 等)
  3. OSS / 標準仕様(Apache Iceberg、Apache Spark、Trino、PostgreSQL、Redis、Valkey、Kubernetes、CNCF プロジェクト、IETF RFC、NIST、FIDO Alliance、W3C 等)
  4. 学習リソース(Workshop、re:Invent セッション、各ベンダーの技術ブログ、OSS コミュニティ)

📗 完全ガイド版(次の30サービス / Tier 2)

2026-04-26 新設(v1.0):使用頻度・重要度が次に高い 30 サービス完全ガイド v2.0(各 700〜1,500 行、Mermaid 図、ユースケース 10+ パターン、比較表、ベストプラクティス、2025-2026 最新動向、参考文献)として整備しました。コア 30 と合わせて 計 60 サービスが完全ガイド対応 となります。

Tier 2 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
Compute EC2 Auto Scaling 1,118 ターゲット追跡、Warm Pool、Mixed Instances、Karpenter 比較 Predictive Scaling、Karpenter v1
Containers ECR 876 Pull Through Cache、Image Scanning、OCI Spec、Cross-Region Replication Enhanced Scanning、Image Usage Status
Storage EBS 950 gp3/io2 Block Express、Snapshot、Multi-Attach、Direct API gp3 80K IOPS、io2 全リージョン
Storage EFS 972 Performance/Throughput Mode、Access Points、CSI、Replication Intelligent Tiering、Elastic Throughput
Storage DataSync 937 Agent、Task、Schedule、Cross-Cloud Enhanced Mode、Agentless Transfer
Database Redshift 782 RA3、Serverless、Spectrum、Concurrency Scaling Zero-ETL GA、データ共有
Database Neptune 765 Property Graph / RDF、Neptune ML GraphStorm、GenAI Agents
Network NLB 776 TCP/UDP/TLS、Static IP、PrivateLink セキュリティグループ GA
Analytics OpenSearch Service 717 Domain/Serverless/Ingestion、UltraWarm、Vector Engine GPU 加速、OpenSearch 3.3
DevOps CodePipeline 1,001 V2、Trigger、Stage、Approval、Cross-account V2 統合、AI Pipeline 生成
DevOps CodeBuild 879 BuildSpec、Reserved Capacity Fleet、Lambda Compute Fleet 全リージョン、Lambda 秒単位
DevOps CodeDeploy 1,035 Blue-Green/Canary、Hook、Rollback、Lambda/ECS ECS B/G CFN、Auto-rollback AI
DevOps CodeArtifact 1,109 Domain/Repo、External Connection、Pull Through Cache Origin Controls GA、Cargo 対応
Observability X-Ray 1,021 Trace/Segment、Service Map、ADOT 連携 OpenTelemetry 移行(SDK EOS 2027-02)
Observability CloudWatch Logs 1,218 Log Group、Insights、Live Tail、Anomaly Detection Log Classes(IA)、Live Tail VPCE
Observability CloudWatch Application Signals 744 SLO、Auto-instrumentation、Service Map SLO Recommendations、Kiro IDE
Observability CloudWatch Synthetics 824 Canary、Selenium/Puppeteer、Visual Monitoring Multi-browser、Multi-check Canary
Integration SES 1,046 Identity、DKIM/SPF/DMARC、Mail Manager Mail Manager 拡張、DMARC 厳格化
Management Systems Manager 912 Session Manager、Patch Manager、Parameter Store Session Manager GUI、Advanced-instances
Governance AWS Config 727 Recorder、Rule、Conformance Pack、Aggregator Conformance Pack 拡張、Security Hub 統合
Governance Organizations 762 Account/OU、SCP/RCP、AI Services Opt-out RCP 対応サービス拡大、GovCloud
Security GuardDuty 1,536 Finding、Threat Intelligence、Runtime Monitoring Extended Threat Detection、Backup Malware
Security AWS WAF 792 Web ACL、Bot Control、Rate-based、Account Takeover Bot Control 地域拡張、WBA
Security CloudHSM 750 HSM Cluster、PKCS#11、KMS XKS 連携 KMS XKS 拡張、PQC 準備
Security Inspector 835 EC2/ECR/Lambda Scanning、SBOM、CISA KEV SBOM 標準化、Classic 廃止(2026-05)
Security STS 863 AssumeRole、OIDC/SAML、Session policies OIDC マルチプロバイダー、Identity Center 統合
Security IAM Identity Center 1,183 Identity Source、Permission Set、SSO Trusted Identity Propagation、SCIM
Security Macie 1,216 Sensitive data discovery、Custom identifier DSPM 統合、AI 駆動分類
Security Security Hub CSPM 961 Findings 統合、Standards、Automation Rules Security Lake 連携、Automation 高度化
Security IAM Access Analyzer 950 External Access、Unused Access、Policy Generation RCP 対応、Unused Access AI

合計: 30 サービス / 約 28,300 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件


📕 完全ガイド版(次の30サービス / Tier 3)

2026-04-26 新設(v1.0):使用頻度・重要度が次に高い 30 サービスを 完全ガイド v2.0(各 700〜1,800 行)として整備しました。コア 30 + Tier 2 + Tier 3 で 計 90 サービスが完全ガイド対応 となります。

Tier 3 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
Network AWS Direct Connect 1,032 Connection、VIF、SiteLink、MACsec 400 Gbps 対応、MACsec デフォルト化
Network VPC Lattice 1,312 Service Network、IAM 認証、EKS 統合 EKS 統合、生成 AI 推論最適化
Network Global Accelerator 1,089 Anycast IP、AWS Backbone 400 Gbps Edge、AI/ML 推論最適化
Network Cloud WAN 1,156 Core Network、NFG、SD-WAN IPv6 Dual-Stack、AI-driven 最適化
Network GWLB 1,098 GENEVE、3rd party Security AI/ML 脅威検知、Zero Trust 統合
Storage Storage Gateway 1,094 File/Volume/Tape/FSx Gateway AL2023 移行(2026-06 期限)、IMDSv2
Storage AWS Backup 1,213 Backup Plan、Vault Lock Logically Air-Gapped Vault、GuardDuty 統合
Storage Glacier 1,097 Storage Classes、Vault Lock Instant Retrieval デフォルト化
Migration Transfer Family 1,259 SFTP/FTPS/AS2、Custom IdP SFTP Connector VPC、IPv6、PQC
Database DocumentDB 1,286 MongoDB 互換、Elastic Clusters v8.0 性能 7 倍、並列ベクトル索引
Database Keyspaces 1,144 Cassandra 互換、CDC CDC Streams、WarmThroughput
Database QLDB 708 不変台帳 ⚠️ EOS 2025-07-31、Aurora PostgreSQL 移行
Database MemoryDB 1,102 Redis/Valkey 8、Multi-AZ Valkey デフォルト化、Vector Search
Compute App Runner 1,027 Source/ECR、AutoDeploy ⚠️ 新規受付終了(2026-04-30)
Compute Lightsail 923 VPS、Container、ブループリント Malaysia リージョン、Container Fargate
Compute EC2 Instance Connect 926 Browser SSH、IAM 認可 IPv6 GA、EICE デュアルスタック
Governance AWS Control Tower 975 Landing Zone、Guardrail、AFT Proactive Controls 200+、RCP 拡大
Integration MQ 1,237 ActiveMQ Artemis、RabbitMQ RabbitMQ 4.2 AMQP 1.0 ネイティブ
Migration AWS DMS 1,212 Replication、CDC、SCT DMS Serverless、Fleet Advisor 廃止(2026-05)
Integration AppFlow 1,251 SaaS Connector、Custom SDK Glue Data Catalog 統合、リアルタイム
Integration EventBridge Scheduler 1,222 One-time/Recurring、Flexible Time リトライ拡張、マルチリージョン Schedule Group
Security IAM Roles Anywhere 1,837 Trust Anchor、X.509 Post-Quantum Digital Certificates
Security Shield Advanced 1,442 DRT、Cost Protection AI/ML 異常検知、Lambda/RDS Cost Protection
Security Detective 1,517 Behavior Graph、Investigation Investigation GA、Security Lake 深度統合
Frontend Amplify 1,713 Hosting、Gen 2、Studio Edge Runtime、AI/Bedrock 統合
Analytics Managed Service for Apache Flink 1,618 Flink、Studio Notebook Iceberg 統合、PyFlink 強化
Observability CloudWatch OAM 1,023 Sink/Link、Cross-account Application Signals SLO 拡張
Management CloudShell 1,025 Browser shell、AWS CLI v2 VS Code Remote SSH、Copilot AI
Analytics AWS Data Exchange 774 Data Set、Subscription、Live Data AI-Generated Insights、Snowflake 統合
Analytics AWS Clean Rooms 826 Collaboration、Differential Privacy PySpark Job、Federated Learning

合計: 30 サービス / 約 31,600 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件

コア 30 + Tier 2 + Tier 3 の合計

  • コア 30: 約 53,800 行
  • Tier 2: 約 28,300 行
  • Tier 3: 約 31,600 行
  • 合計 90 サービス / 約 113,700 行 / 220+ Mermaid 図 / 1,200+ 参考文献

コア 30、Tier 2、Tier 3 の使い分け

[サービス選定]
  ↓
比較表(275サービス全体)で候補を絞る
  ↓
最初に検討: コア 30(実装頻度が圧倒的に高い、各行 🟢 完全ガイド T1)
  ↓
次に検討: Tier 2(重要な周辺機能、各行 🟡 完全ガイド T2)
  ↓
さらに検討: Tier 3(特定要件・統合機能、各行 🟠 完全ガイド T3)
  ↓
個別ノート / ユースケース集 で実装パターン確認

比較表内の行マーキング: 下記の各カテゴリ別比較表(Compute、Network 等)で、対応する行に 🟢 完全ガイド T1 / 🟡 完全ガイド T2 / 🟠 完全ガイド T3 / 🔵 完全ガイド T4 のラベルが付いています。


📓 完全ガイド版(次の30サービス / Tier 4)

2026-04-26 新設(v1.0):使用頻度・重要度がさらに次に高い 30 サービスを 完全ガイド v2.0(各 600〜1,900 行)として整備しました。コア 30 + Tier 2 + Tier 3 + Tier 4 で 計 120 サービスが完全ガイド対応 となります。

Tier 4 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
Analytics EMR 1,931 EC2/EKS/Serverless、Spark、Iceberg Spark 4.0.1、Iceberg v3、Ray on EMR
Analytics Lake Formation 1,425 Catalog、Cross-Account、LF-Tags Row-Level Lineage、AI 権限推奨
Analytics DataZone 1,082 Data Portal、Project、Glossary AI メタデータ自動生成、S3 Tables 統合
Governance Resource Groups and Tagging 976 Tag Policy、Cost Allocation、ABAC AI 推奨タグ、自動化強化
Migration Snow Family 1,024 Snowcone、Snowball Edge 複数 GPU、SageMaker Studio エッジ実行
Compute AWS Batch 1,193 Compute Environment、Multi-node SageMaker Job Queuing 統合
Storage FSx 966 NetApp ONTAP / OpenZFS / Lustre / Windows 第 2 世代 ONTAP(72 GBps)
Hybrid AWS Outposts 1,002 Rack/Server、Local Zones、Wavelength C7i/M7i/R7i、Bedrock AgentCore 統合
Compute EC2 Image Builder 1,071 Pipeline、Recipe、Component Inspector 連携強化、STIG 2026 Q1
Compute AWS Auto Scaling 1,002 横断スケール、Predictive Predictive Scaling 全 28 リージョン
Compute Application Auto Scaling 1,270 ECS/DynamoDB/Aurora/Lambda 個別 カスタムメトリクス、AI 駆動
Integration EventBridge Pipes 1,413 Source→Filter→Enrichment→Target Source 拡張、AI ルーティング
Governance AWS Service Catalog 1,298 Portfolio、Product、Constraint AI Generated Products、Hub & Spoke
Architecture AWS Well-Architected Tool 1,118 Lens、Workload、Improvement Plan GenAI Lens、AI レビュー支援
AI/ML Q Business 1,601 Application、Index、Plugin、Q Apps Identity-aware、Q Apps GA
AI/ML Q Developer 1,624 Inline Suggest、Code Transformation Java Upgrade、/test/review/doc
AI/ML Bedrock AgentCore 1,692 Runtime、Memory、Identity、Browser Harness、CLI、Skills、Multi-agent
AI/ML Transcribe 1,410 Streaming/Batch、Custom Vocab、Medical Toxicity Detection、Call Analytics
AI/ML Translate 1,273 Real-time/Batch、Custom Terminology Document Translate
AI/ML Polly 1,179 Standard/Neural/Generative voice Generative voice、Long-form 拡張
AI/ML Comprehend 667 Entity/Sentiment/PII、Medical ICD-10/SNOMED、Custom
AI/ML Textract 629 Forms/Tables、ID/Expense Bedrock 統合、Lending 拡張
AI/ML Rekognition 1,008 Image/Video、Face Liveness Streaming Video Events
AI/ML Personalize 933 User-Personalization、SIMS Domain Use Case、Next-best Action
AI/ML Fraud Detector 942 Online/Transaction/ATO Insights ⚠️ EOS 通知、代替案ガイド
Governance Audit Manager 949 Framework、Assessment、Evidence GenAI Framework、新規受付終了 2026-04-30
DevOps CodeCatalyst 740 Space、Project、Workflow ⚠️ 新規顧客受付停止、移行ガイド
DevOps CodeCommit 597 Repository、Branch、PR ⚠️ 2024-07 以降新規不可
Observability CloudWatch Network Synthetic Monitor 732 Network Probe、End-to-end Latency Hybrid 監視、Internet Monitor 連携
Cost Trusted Advisor API 832 Check、Resource、Priority Priority API、AI 推奨拡張

合計: 30 サービス / 約 33,600 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件


📔 完全ガイド版(次の30サービス / Tier 5)

2026-04-26 新設(v1.0):使用頻度・重要度がさらに次に高い 30 サービスを 完全ガイド v2.0(各 700〜1,600 行)として整備しました。コア 30 + Tier 2 + Tier 3 + Tier 4 + Tier 5 で 計 150 サービスが完全ガイド対応 となります。

Tier 5 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
Network/Security Network Firewall 1,032 Suricata 互換、TLS Inspection Suricata 7.0、PCRE2 移行、自動ルール生成
Network/Security Firewall Manager 1,087 Master/Member、6 種類ポリシー Multi-Admin 2025、自動修復
Security AWS Security Incident Response 946 24/7 CIRT、Triage→Recovery Metered Pricing、AI-Powered Investigation
Resilience AWS FIS 1,120 Experiment、Action、Stop Condition Bedrock AgentCore 統合
Streaming MSK 533 Provisioned/Serverless/Express、KRaft Express 5-10x 高速化、IAM 認証
Streaming Firehose 719 Delivery Stream、Lambda Transform Snowflake/Iceberg 対応、動的パーティション
Streaming Kinesis Data Streams 678 Shard、KCL、Enhanced Fan-out On-Demand 60% 低コスト、365 日リプレイ
Media Kinesis Video Streams 840 HLS/DASH、WebRTC、Edge Agent WebRTC 双方向、Rekognition 統合
Observability CloudWatch RUM 1,356 AppMonitor、Web Vitals、Session Replay Core Web Vitals 拡張、Session Replay
Observability CloudWatch Internet Monitor 985 Health Event、City-Network、RTT ISP 障害検出、CloudFront 効果測定
Observability CloudWatch Application Insights 830 自動検出、CFN Stack、ML 異常検知 OpsCenter 統合、SAP 監視
Observability Managed Grafana 715 Workspace、50+ Data Source IAM IC、Grafana Enterprise
Observability Managed Service for Prometheus 828 PromQL、Recording Rule、Alert Manager Trainium/Inferentia 監視、ADOT 統合
Compute/PaaS Elastic Beanstalk 1,230 Application/Environment、Multi-platform Spot Allocation Strategies
API AWS AppSync 1,586 GraphQL、Pub-Sub、Resolver AppSync Events GA、Merged API
Config AWS AppConfig 1,392 Feature Flag、Validator、Strategy Enhanced Targeting 2026-03
Containers ECR Public 1,041 Public Gallery、Pull Through OCI Referrer 自動同期
Database Timestream 1,191 LiveAnalytics + InfluxDB InfluxDB GA 拡張、Multi-measure
Identity Directory Service 864 Managed AD/AD Connector/Simple AD Forest Trust、IAM IC 統合
AI/ML Lex 926 Bot、Intent、Slot、Voice/Text Q in Connect、ASR、Bedrock 統合
AI/ML Comprehend Medical 830 ICD-10/RxNorm/SNOMED、PHI Detection Custom Medical Entity
Analytics DataBrew 838 Project、Recipe、250+ Transformation PII Detection/Masking
DevOps CodeConnections 1,401 GitHub/GitLab/Bitbucket Connection OAuth、Resource Sync
DevOps CodeGuru Reviewer 1,046 Code Review、Detector ⚠️ EOL 2025-04-30、Q Developer 統合
DevOps CodeGuru Security 1,109 SAST、OWASP Top 10、CWE ⚠️ EOL 2025-04-30、Inspector 統合
DR Elastic Disaster Recovery 946 Block-level Continuous Replication Cross-region failover、Failback
BI QuickSight 1,240 SPICE、Dashboard、Q、Generative BI Q in QuickSight 拡張
Mgmt AWS Health 1,237 Service/Personal Health、Health API Organizational view、EventBridge
Mgmt Service Quotas 1,250 Default/Adjustable、Increase Request Organizations Template
Storage Recycle Bin 1,105 Retention Rule、EBS Snapshot/AMI Tag-level、Region-level

合計: 30 サービス / 約 31,000 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件


📒 完全ガイド版(次の30サービス / Tier 6)

2026-04-26 新設(v1.0):使用頻度・重要度がさらに次に高い 30 サービスを 完全ガイド v2.0(各 600〜1,700 行)として整備しました。コア 30 + Tier 2〜6 で 計 180 サービスが完全ガイド対応 となります。

Tier 6 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
Security AWS Certificate Manager 1,652 Public/Private Certificate、Renewal DV/Wildcard、自動更新、Multi-domain
Security AWS Private CA 1,586 Root/Subordinate CA、CRL、OCSP IoT/K8s/Microservices PKI
Mgmt License Manager 1,111 License Configuration、BYOL Microsoft/SAP/Oracle/Adobe
DevOps AWS Proton 1,536 Environment/Service Template ⚠️ EOS 2025-12-31、CDK/Service Catalog
Workflow MWAA 1,168 Apache Airflow、Worker/Scheduler Airflow 2.x、Plugin、Private Webserver
DevOps SAR 1,051 Application、Version、SAM Public/Private 配布
Resilience Application Recovery Controller 704 Routing Control、Zonal/Region Shift ARC Region Switch
Database Aurora DSQL 952 Distributed SQL、Multi-region PostgreSQL 互換、Strong Consistency
Security Security Lake 1,009 OCSF、Iceberg、Subscriber OCSF v1.8.0、ITU 採用
Security Verified Access 1,112 Trust Provider、Cedar Policy 非 HTTPS リソース対応
Security Verified Permissions 1,324 Policy Store、Cedar、Schema Cedar 4.5、Policy Store Aliases
Observability DevOps Guru 1,019 Insight、Anomaly ⚠️ EOL 2026-04-30
Migration Migration Hub 1,140 Application/Server Tracker Cross-region tracking
Migration Migration Hub Refactor Spaces 1,145 Strangler Fig、API Gateway Microservices 抽出
Migration Migration Hub Orchestrator 665 Workflow Template、Step SAP/DB Migration
Migration Migration Hub Strategy Recommendations 886 Strategy Score、6Rs Rehost/Replatform/Refactor
Migration Application Migration Service 808 Lift-and-Shift、Block-level CloudEndure 後継
Migration Application Discovery Service 1,061 Agent/Agentless、Inventory Migration Hub 統合
Migration AWS Mainframe Modernization 1,162 Replatform/Refactor Micro Focus、Blu Age、COBOL→Java
AI/ML Forecast 747 Predictor、AutoML、DeepAR+ ⚠️ 縮小、SageMaker 移行
AI/ML AWS App Studio 594 GenAI low-code、Component Hosted apps
AI/ML AWS HealthOmics 750 Sequence/Variant Store Nextflow/WDL/CWL
EUC WorkSpaces 1,124 Personal/Pools、Bundle WSP/PCoIP、GPU
EUC WorkSpaces Secure Browser 740 Portal、URL Filtering Browser-based Zero-trust
EUC WorkSpaces Applications 796 App Streaming、Image Builder AppStream 2.0 後継
Contact Center Connect 831 Contact Flow、Routing、Q Customer Profiles、Voice ID
Marketing Pinpoint 1,012 Endpoint/Segment/Campaign ⚠️ 廃止 2026-10-30、EUM 移行
Communication Chime SDK 1,121 Meeting、WebRTC、PSTN SDK 継続、製品廃止
Messaging AWS End User Messaging 1,039 SMS/Voice/Push、10DLC Pinpoint 後継
Email WorkMail 1,080 Mailbox、Outlook 互換 ⚠️ 廃止 2027-03-31、M365 移行

合計: 30 サービス / 約 30,300 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件


📃 完全ガイド版(次の30サービス / Tier 7)

2026-04-26 新設(v1.0):使用頻度・重要度がさらに次に高い 30 サービスを 完全ガイド v2.0(各 530〜1,540 行)として整備しました。コア 30 + Tier 2〜7 で 計 210 サービスが完全ガイド対応 となります。

Tier 7 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
IoT AWS IoT Core 1,254 Thing、Rule Engine、Device Shadow MQTT 5、Fleet Provisioning
IoT AWS IoT Greengrass v2 1,134 Component、Recipe、Stream Manager TPM 2.0、ML at edge
IoT AWS IoT Device Management 975 Job、Bulk Provisioning、Fleet Hub OTA、Tunnel
IoT AWS IoT SiteWise 989 Asset Model、OPC UA、Edge Industrial Data Lake
IoT AWS IoT Events 1,116 Detector Model、State、Trigger ⚠️ EOS 2025-12-15
IoT AWS IoT Device Defender 1,181 Audit、Detect、ML Detect CIS Benchmarks
IoT AWS IoT FleetWise 1,348 Vehicle Model、Decoder、Campaign Vision System Data
IoT AWS IoT TwinMaker 1,329 Workspace、Entity、Scene Bedrock 統合、Vision Stream
Media MediaConvert 1,228 Job、QVBR、HEVC/AV1、HDR AV1 拡張
Media MediaLive 1,027 Channel、SCTE-35、Statmux Live to VOD
Media MediaPackage 923 HLS/DASH/CMAF、JIT Packaging Live to VOD 拡張
Media MediaConnect 778 SRT/Zixi/RIST/RTP CDI、Bridge
Media MediaTailor 790 SSAI、Channel Assembly Personalization Profile
DevOps CodeGuru Profiler 977 Profiling Group、Anomaly ⚠️ EOL 2025-04-30
Optimization Compute Optimizer 977 Recommendation、Idle Resource Generative Insights
Operations Incident Manager 983 Response Plan、Engagement、Runbook Chatbot Integration
Resilience Resilience Hub 1,037 Application、Resiliency Policy Drift Detection、AI
Network AWS Cloud Map 1,536 Namespace、Service Discovery ECS / Service Connect 連携
Sharing AWS RAM 1,114 Resource Share、Cross-account Customer-managed permissions
Identity Cloud Directory 826 Schema、Hierarchical data ⚠️ 縮小、Neptune 推奨
Discovery Resource Explorer 969 Index、View、Cross-region search Aggregator Index
Identity AWS Sign-In 1,016 Root/IAM/IDC Sign-In、MFA Passkey、AWS Builder ID
AI/Search Kendra 776 Index、Data Source、Faceted Search ⚠️ Q Business 統合
Location Location Service 934 Map、Place Index、Route Calculator 17 新 API、Amazon Leo
Integration AppFabric 1,027 SaaS Audit Log、Productivity AI OCSF 正規化、Bedrock
Communication AWS Ground Station 1,023 Antenna、Contact、Mission Profile 300+ 地上局、Amazon Leo
Cost Billing and Cost Management 972 Cost Explorer、Budgets、SP/RI CUR 2.0、Anomaly Detection
Marketplace AWS Marketplace 849 Listing、Private Offer、SaaS Bedrock Marketplace
Integration EventBridge Schemas 1,087 Schema Registry、Discovery OpenAPI 3.0、Code Bindings
DevOps AWS Cloud9 532 Workspace、Environment ⚠️ EOS 2025-12-15、Q Developer 移行

合計: 30 サービス / 約 30,400 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件


📰 完全ガイド版(次の30サービス / Tier 8)

2026-04-26 新設(v1.0):使用頻度・重要度がさらに次に高い 30 サービスを 完全ガイド v2.0(各 530〜1,270 行)として整備しました。コア 30 + Tier 2〜8 で 計 240 サービスが完全ガイド対応 となります。

Tier 8 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
Healthcare HealthImaging 1,166 DICOM、Datastore、Image Set Lossless 圧縮、AI 連携
Healthcare HealthLake 1,265 FHIR R4、SMART on FHIR、Bulk Comprehend Medical 統合
Quantum Braket 1,214 IonQ/Rigetti/QuEra/IQM、Hybrid Pulse Control、Direct Reservation
Blockchain Managed Blockchain 942 Hyperledger Fabric、Ethereum ⚠️ Fabric 新規受付停止
HPC AWS PCS 1,052 Slurm、Compute Node Group、EFA FSx Lustre 統合
Gaming GameLift Servers 701 Fleet、FlexMatch、Spot Reservation Container Fleet
Gaming GameLift Streams 774 Stream Group、WebRTC クラウドゲーミング
Streaming IVS 879 Channel、Stage、300ms 低遅延 Real-Time Streaming、Chat
Crowd Mechanical Turk 877 HIT、Worker、Qualification SageMaker Ground Truth 統合
HPC/Render AWS Deadline Cloud 718 Render Farm、Job、Step、Task Maya/Houdini/Blender 対応
Containers Red Hat OpenShift on AWS 878 ROSA HCP/Classic、OperatorHub HCP デフォルト化
Robotics AWS RoboMaker 706 Robot/Sim Application、Fleet ⚠️ EOS 2025-09-10
AI/ML AWS DeepRacer 803 Model、Track、Reward Function ⚠️ EOS 2025-08-15
Edge AI AWS Panorama 913 Appliance、Application、Camera ⚠️ EOS 2026-03-31
AI/ML Lookout for Vision 1,162 Project、Dataset、Anomaly ⚠️ EOS 2025-10-31
AI/ML Lookout for Equipment 1,122 Inference Scheduler、Sensor Data ⚠️ EOS 2025-10-17
AI/ML Lookout for Metrics 1,004 Detector、Anomaly Group ⚠️ EOS 2025-10-17
Industrial IoT Monitron 860 Sensor、Gateway、Mobile App ⚠️ EOS 2025-10-31
Workflow SWF 565 Domain、Workflow Type、Activity レガシー、Step Functions 推奨
Migration AWS Transform 532 GenAI Migration、.NET/VMware Code Refactoring 自動化
Telco AWS TNB 640 Network Service、CNF/VNF、ETSI MANO 5G Core、ORAN
DevOps Application Testing 663 Test Plan、Reusable Config SAP / Cloud Test
Data Entity Resolution 623 Matching Workflow、ID Mapping Rule/ML/Provider-based
Streaming MSK Connect 650 Connector、Plugin、Worker Debezium、Confluent
AI/ML Augmented AI (A2I) 785 Human Loop、Workflow ⚠️ Ground Truth Plus 統合
Healthcare Connect Health 734 Healthcare Contact Flow、HIPAA Patient Profile、Care Coordination
Hybrid EVS 746 VMware Cloud Foundation、SDDC NSX、vSAN、HCX
Edge AI Elemental Inference 996 ML video inference、Edge SageMaker Edge 後継推奨
Storage Data Lifecycle Manager 958 Lifecycle Policy、EBS Snapshot/AMI Cross-region/account
Media Elastic Transcoder 739 Pipeline、Job、Preset ⚠️ EOS 2025-11-13、MediaConvert 移行

合計: 30 サービス / 約 27,000 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件


📑 完全ガイド版(最終 30 サービス / Tier 9)

2026-04-26 新設(v1.0):残る重要サービスと管理系・レガシーを網羅した最終 30 サービスを 完全ガイド v2.0(各 590〜1,900 行)として整備しました。コア 30 + Tier 2〜9 で 計 270 サービスが完全ガイド対応 となります(残るのはリブランド済みリダイレクト 6 件のみ)。

Tier 9 サービス一覧

カテゴリ サービス 行数 主要トピック 2026 動向
Network Global Networks for TGW 696 Network Manager、Global Network、SD-WAN On-prem Visualization
IoT AWS IoT Wireless 795 LoRaWAN、Sidewalk、Network Server Sidewalk LoRa Global 2026
Embedded FreeRTOS 815 Kernel、LTS、Reference Integration LTS Backports
SAP SSM for SAP 993 SAP Discovery、Backint、Operations Insight SAP HANA Backup
Database Oracle Database@AWS 719 Exadata Cloud、Autonomous DB 2026 新サービス
Security Payment Cryptography 765 Key、PIN Translation、PCI DSS、TR-31 Tokenization 拡張
Security Signer 892 Code Signing for Lambda/IoT、Notation SBOM 統合
Communication Wickr 848 Encrypted Messaging、Burn-on-Read Compliance Recording
Communication Chime 589 Meeting、Voice Connector ⚠️ EOS 2026-02-20
Integration B2B Data Interchange 859 X12 EDI、AS2、Transformer EDIFACT、JEDI
Mgmt AWS Management Console 1,346 Console Home、Mobile App、Multi-session My Applications
Mgmt User Notifications 1,173 Notification Hub、Aggregation、Channel Slack/Teams 統合
Mgmt AWS Managed Services 1,053 Operations Plan、Change Management Accelerate / Advanced
DevOps CodeStar Notifications 705 Notification Rule、SNS / Chatbot CodePipeline/Build/Deploy
Support AWS Support 1,038 Plan、Case、TAM、Trusted Advisor Enterprise On-Ramp
Cost Billing Conductor 827 Billing Group、Pricing Plan、Custom Line Item MSP / Reseller
Compute Launch Wizard 786 SAP/SQL Server/AD 自動デプロイ Pre-deployment validation
Mgmt SSM Quick Setup 768 Configuration Type、Multi-account/Region Organizations 統合
Governance Control Catalog 835 Common Control、Mapping、Frameworks Audit Manager 統合
Search CloudSearch 962 Search Domain、Index ⚠️ Legacy、OpenSearch 推奨
Data Data Pipeline 683 Pipeline、Activity、DataNode ⚠️ EOS 2026-04-15
Database SimpleDB 834 Domain、Item、Attribute ⚠️ Legacy、DynamoDB 推奨
Database FinSpace 903 kdb+ Insights、Capital Markets ⚠️ EOS 2026-10-07
AI/ML AI Operations 1,069 AI-driven Insight、Q Developer Application Signals 統合
AI/ML Clean Rooms ML 1,106 Lookalike、Custom Trained Model Differential Privacy
API Cloud Control API 1,220 Resource API、Type Schema 1,500+ Resource Types
Observability CloudWatch Observability Admin 1,010 Telemetry Configuration、Auto-Config Multi-account 一元管理
EUC WorkSpaces Instances 1,237 Self-managed VDI、BYOL Citrix/VMware 比較
Knowledge re:Post Private 1,153 Private Q&A、IAM IC 統合 Stack Overflow 比較
Testing Device Farm 1,899 Mobile/Browser Testing、Real Device Appium/Espresso

合計: 30 サービス / 約 29,400 行 / 60+ Mermaid 図 / 各ガイドに参考文献 13-20 件

🎉 完全ガイド全体の総合計(コア 30 + Tier 2〜9)

  • コア 30: 約 53,800 行
  • Tier 2: 約 28,300 行
  • Tier 3: 約 34,700 行
  • Tier 4: 約 33,600 行
  • Tier 5: 約 31,000 行
  • Tier 6: 約 30,300 行
  • Tier 7: 約 30,400 行
  • Tier 8: 約 27,000 行
  • Tier 9: 約 29,400 行
  • 合計 270 サービス / 約 298,500 行 / 580+ Mermaid 図 / 3,000+ 参考文献

残り 6 サービス(cloudwatch-events、aws-codestar-connections、aws-iot-greengrass-v1、aws-waf-classic、inspector-classic、ml)は リブランド済みリダイレクト / Legacy バージョン であり、内容は後継サービスのページに集約されています。

比較表内の行マーキング: 下記の各カテゴリ別比較表で、対応する行に 🟢 完全ガイド T1 / 🟡 完全ガイド T2 / 🟠 完全ガイド T3 / 🔵 完全ガイド T4 / 🟣 完全ガイド T5 / 🟤 完全ガイド T6 / ⚪ 完全ガイド T7 / 🩶 完全ガイド T8 / 🔘 完全ガイド T9 のラベルが付いています。


完全ガイドが既存の比較表(下記)と補完する関係

下記の 275 サービス比較表 は「選定の最初の入口」として網羅性に優れます。一方、上記の 30 完全ガイド は「実装・運用の深掘り」として詳細度に優れます。

[サービス選定]
  ↓
比較表で候補を絞る(275サービス全体)
  ↓
完全ガイドで深掘り(コア30サービス)
  ↓
個別ノート / ユースケース集 で実装パターン確認

Compute (12)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
Lambda 🟢 完全ガイド T1 ★★★★★★★★★☆(9.4) イベント駆動サーバーレス実行基盤
  • イベント駆動に分割できる処理である
  • 実行時間を15分以内に収められる
  • DLQ/宛先で失敗制御を運用できる
  • EC2 では要件を満たしきれず、イベント駆動サーバーレス実行基盤 を重視して Lambda を第一候補にする場合。
  • Lambda を採用し、API Gateway と組み合わせて責任境界を明確にしたい場合。
  • ECS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EC2 は汎用的な選択肢だが、Lambda は「イベント駆動サーバーレス実行基盤」に責務を集中させやすい。
  • ECS と比べると、Lambda は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • API Gateway との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Lambda, Event Source Mapping, 同時実行, DLQ, Provisioned Concurrency
EC2 🟢 完全ガイド T1 ★★★★★★★★★☆(9.3) 自由度重視の仮想サーバー基盤
  • OS/カーネルカスタマイズが必要か
  • 実行時間上限なしの長時間処理か
  • リフト&シフトで既存OS環境を移行するか
  • Lambda では要件を満たしきれず、自由度重視の仮想サーバー基盤 を重視して EC2 を第一候補にする場合。
  • EC2 を採用し、VPC と組み合わせて責任境界を明確にしたい場合。
  • ECS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Lambda は汎用的な選択肢だが、EC2 は「自由度重視の仮想サーバー基盤」に責務を集中させやすい。
  • ECS と比べると、EC2 は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • VPC との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, EC2
EC2 Auto Scaling 🟡 完全ガイド T2 ★★★★★★★★★☆(8.7) EC2台数の需要追従と自己修復
  • トラフィック変動に応じたEC2台数の自動増減か
  • インスタンス障害の自己修復が必要か
  • CloudWatchメトリクス連動のスケールポリシーか
  • EC2 では要件を満たしきれず、EC2台数の需要追従と自己修復 を重視して EC2 Auto Scaling を第一候補にする場合。
  • EC2 Auto Scaling を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • Application Auto Scaling と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EC2 は汎用的な選択肢だが、EC2 Auto Scaling は「EC2台数の需要追従と自己修復」に責務を集中させやすい。
  • Application Auto Scaling と比べると、EC2 Auto Scaling は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, EC2 Auto Scaling
Elastic Beanstalk 🟣 完全ガイド T5 ★★★★★★★☆☆☆(6.7) アプリ配備中心のPaaS運用
  • アプリ+インフラをAWSに一体委譲したいか
  • EC2/ELB/RDSの設定管理を省略したいか
  • .ebextensionsによる柔軟なカスタマイズが必要か
  • App Runner では要件を満たしきれず、アプリ配備中心のPaaS運用 を重視して Elastic Beanstalk を第一候補にする場合。
  • Elastic Beanstalk を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • EC2 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • App Runner は汎用的な選択肢だが、Elastic Beanstalk は「アプリ配備中心のPaaS運用」に責務を集中させやすい。
  • EC2 と比べると、Elastic Beanstalk は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, Elastic Beanstalk
App Runner 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.5) コンテナ/コードの即時HTTP公開基盤
  • DockerfileのみでHTTPS公開したいか
  • インフラ設定なしのオートスケールか
  • ECRプッシュで自動デプロイするか
  • Elastic Beanstalk では要件を満たしきれず、コンテナ/コードの即時HTTP公開基盤 を重視して App Runner を第一候補にする場合。
  • App Runner を採用し、ECR と組み合わせて責任境界を明確にしたい場合。
  • ECS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Elastic Beanstalk は汎用的な選択肢だが、App Runner は「コンテナ/コードの即時HTTP公開基盤」に責務を集中させやすい。
  • ECS と比べると、App Runner は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECR との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, App Runner
EC2 Instance Connect 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.4) 一時鍵注入による接続統制
  • SSHキー配布なしの一時的シェルアクセスか
  • IAMポリシーで接続権限を制御するか
  • 踏み台サーバなしのアドホックアクセスか
  • Systems Manager では要件を満たしきれず、一時鍵注入による接続統制 を重視して EC2 Instance Connect を第一候補にする場合。
  • EC2 Instance Connect を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • EC2 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Systems Manager は汎用的な選択肢だが、EC2 Instance Connect は「一時鍵注入による接続統制」に責務を集中させやすい。
  • EC2 と比べると、EC2 Instance Connect は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, EC2 Instance Connect
Lightsail 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.4) 小規模向けシンプルVM運用
  • 月額固定のシンプルなVM運用か
  • ブループリントで即時起動したいか
  • 複雑なネットワーク設定が不要か
  • EC2 では要件を満たしきれず、小規模向けシンプルVM運用 を重視して Lightsail を第一候補にする場合。
  • Lightsail を採用し、Route 53 と組み合わせて責任境界を明確にしたい場合。
  • App Runner と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EC2 は汎用的な選択肢だが、Lightsail は「小規模向けシンプルVM運用」に責務を集中させやすい。
  • App Runner と比べると、Lightsail は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Route 53 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, Lightsail
AWS Auto Scaling 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.1) 複数サービス横断の容量最適化
  • EC2/ECS/DynamoDB/Aurora横断でスケールするか
  • 予測スケーリングで先読み調整が必要か
  • ターゲット追跡で複数サービスを自動調整するか
  • EC2 Auto Scaling では要件を満たしきれず、複数サービス横断の容量最適化 を重視して AWS Auto Scaling を第一候補にする場合。
  • AWS Auto Scaling を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • Application Auto Scaling と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EC2 Auto Scaling は汎用的な選択肢だが、AWS Auto Scaling は「複数サービス横断の容量最適化」に責務を集中させやすい。
  • Application Auto Scaling と比べると、AWS Auto Scaling は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, AWS Auto Scaling
AWS Batch 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.9) 大量バッチの統合スケジューリング
  • 長時間バッチジョブをキューで管理するか
  • スポットインスタンスでバッチコストを削減するか
  • ジョブのDAG依存関係を管理するか
  • Lambda では要件を満たしきれず、大量バッチの統合スケジューリング を重視して AWS Batch を第一候補にする場合。
  • AWS Batch を採用し、ECR と組み合わせて責任境界を明確にしたい場合。
  • ECS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Lambda は汎用的な選択肢だが、AWS Batch は「大量バッチの統合スケジューリング」に責務を集中させやすい。
  • ECS と比べると、AWS Batch は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECR との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, AWS Batch
EC2 Image Builder 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.8) AMI/コンテナイメージ生成の標準化
  • 定期パッチ済みGolden AMIを自動生成するか
  • イメージパイプラインをIaCで管理するか
  • 複数リージョンへのイメージ自動配布が必要か
  • Systems Manager では要件を満たしきれず、AMI/コンテナイメージ生成の標準化 を重視して EC2 Image Builder を第一候補にする場合。
  • EC2 Image Builder を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • EC2 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Systems Manager は汎用的な選択肢だが、EC2 Image Builder は「AMI/コンテナイメージ生成の標準化」に責務を集中させやすい。
  • EC2 と比べると、EC2 Image Builder は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, EC2 Image Builder
Application Auto Scaling 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.7) マネージド容量の自動調整制御
  • ECS/DynamoDB/Lambda/Aurora個別にスケールするか
  • カスタムメトリクスでターゲット追跡するか
  • スケジュールスケーリングで時間帯別調整するか
  • EC2 Auto Scaling では要件を満たしきれず、マネージド容量の自動調整制御 を重視して Application Auto Scaling を第一候補にする場合。
  • Application Auto Scaling を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • AWS Auto Scaling と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EC2 Auto Scaling は汎用的な選択肢だが、Application Auto Scaling は「マネージド容量の自動調整制御」に責務を集中させやすい。
  • AWS Auto Scaling と比べると、Application Auto Scaling は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, Application Auto Scaling
AWS Outposts 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.7) オンプレ拠点へのAWS拡張基盤
  • データ主権/超低レイテンシー要件があるか
  • 施設内でAWS APIを実行したいか
  • オンプレとクラウドを同一APIで一体運用するか
  • EC2 では要件を満たしきれず、オンプレ拠点へのAWS拡張基盤 を重視して AWS Outposts を第一候補にする場合。
  • AWS Outposts を採用し、Direct Connect と組み合わせて責任境界を明確にしたい場合。
  • EKS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EC2 は汎用的な選択肢だが、AWS Outposts は「オンプレ拠点へのAWS拡張基盤」に責務を集中させやすい。
  • EKS と比べると、AWS Outposts は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Direct Connect との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute, 公式読解, 制約設計, 運用判断, AWS Outposts

Containers & Platform (11)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
Application Load Balancer (ALB) 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.5) HTTP/HTTPS向けL7ルーティングを担うロードバランサ
  • パス/ホスト単位の振り分けが必要
  • WAFや認証連携を前提にする
  • HTTP系の可観測性を重視する
  • NLB では要件を満たしきれず、HTTP/HTTPS向けL7ルーティングを担うロードバランサ を重視して Application Load Balancer (ALB) を第一候補にする場合。
  • Application Load Balancer (ALB) を採用し、ECS と組み合わせて責任境界を明確にしたい場合。
  • GWLB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • NLB は汎用的な選択肢だが、Application Load Balancer (ALB) は「HTTP/HTTPS向けL7ルーティングを担うロードバランサ」に責務を集中させやすい。
  • GWLB と比べると、Application Load Balancer (ALB) は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ALB, L7, ターゲットグループ, HTTPルーティング
Network Load Balancer (NLB) 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.6) TCP/UDP中心のL4高性能ロードバランサ
  • 低遅延を最優先する
  • 固定IPや大量同時接続が必要
  • L7判断より転送性能を重視する
  • ALB では要件を満たしきれず、TCP/UDP中心のL4高性能ロードバランサ を重視して Network Load Balancer (NLB) を第一候補にする場合。
  • Network Load Balancer (NLB) を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • GWLB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ALB は汎用的な選択肢だが、Network Load Balancer (NLB) は「TCP/UDP中心のL4高性能ロードバランサ」に責務を集中させやすい。
  • GWLB と比べると、Network Load Balancer (NLB) は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
NLB, L4, 低遅延, 高スループット
Gateway Load Balancer (GWLB) 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.2) セキュリティアプライアンスを透過中継する基盤
  • トラフィック検査を共通化したい
  • 経路を透過的に維持したい
  • VPC横断の検査統制が必要
  • ALB では要件を満たしきれず、セキュリティアプライアンスを透過中継する基盤 を重視して Gateway Load Balancer (GWLB) を第一候補にする場合。
  • Gateway Load Balancer (GWLB) を採用し、VPC と組み合わせて責任境界を明確にしたい場合。
  • NLB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ALB は汎用的な選択肢だが、Gateway Load Balancer (GWLB) は「セキュリティアプライアンスを透過中継する基盤」に責務を集中させやすい。
  • NLB と比べると、Gateway Load Balancer (GWLB) は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • VPC との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
GWLB, 透過中継, 検査経路, アプライアンス
ECS 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.3) AWS統合で運用しやすいコンテナ実行基盤
  • AWS連携を最優先する
  • タスク定義を標準化できる
  • Kubernetes運用を持たずに進めたい
  • EKS では要件を満たしきれず、AWS統合で運用しやすいコンテナ実行基盤 を重視して ECS を第一候補にする場合。
  • ECS を採用し、ECR と組み合わせて責任境界を明確にしたい場合。
  • App Runner と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EKS は汎用的な選択肢だが、ECS は「AWS統合で運用しやすいコンテナ実行基盤」に責務を集中させやすい。
  • App Runner と比べると、ECS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECR との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ECS, タスク定義, サービス運用, Fargate
EKS 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.1) Kubernetes制御プレーンをマネージド化する基盤
  • Kubernetes標準を維持したい
  • 複数環境の統制が必要
  • クラスタ運用の責務分界を持てる
  • ECS では要件を満たしきれず、Kubernetes制御プレーンをマネージド化する基盤 を重視して EKS を第一候補にする場合。
  • EKS を採用し、ECR と組み合わせて責任境界を明確にしたい場合。
  • App Runner と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ECS は汎用的な選択肢だが、EKS は「Kubernetes制御プレーンをマネージド化する基盤」に責務を集中させやすい。
  • App Runner と比べると、EKS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECR との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EKS, Kubernetes, クラスタ, マネージド制御プレーン
ECR 🟡 完全ガイド T2 ★★★★★★★★☆☆(7.8) 権限統制付きのプライベートコンテナレジストリ
  • 社内配布を安全に運用したい
  • IAMで配布権限を制御する
  • 脆弱性スキャンを運用へ組み込みたい
  • ECR Public では要件を満たしきれず、権限統制付きのプライベートコンテナレジストリ を重視して ECR を第一候補にする場合。
  • ECR を採用し、ECS と組み合わせて責任境界を明確にしたい場合。
  • Docker Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ECR Public は汎用的な選択肢だが、ECR は「権限統制付きのプライベートコンテナレジストリ」に責務を集中させやすい。
  • Docker Hub と比べると、ECR は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ECR, イメージ管理, 脆弱性スキャン, ライフサイクル
ECR Public 🟣 完全ガイド T5 ★★★★★★★☆☆☆(7.2) 公開配布向けコンテナレジストリ
  • 外部配布を前提にする
  • 更新互換性を管理できる
  • 配布可用性を重視する
  • ECR では要件を満たしきれず、公開配布向けコンテナレジストリ を重視して ECR Public を第一候補にする場合。
  • ECR Public を採用し、ECR と組み合わせて責任境界を明確にしたい場合。
  • Docker Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ECR は汎用的な選択肢だが、ECR Public は「公開配布向けコンテナレジストリ」に責務を集中させやすい。
  • Docker Hub と比べると、ECR Public は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECR との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ECR Public, 公開配布, 互換性, 配布運用
AWS Serverless Application Repository 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.3) サーバーレスアプリを再利用配布する仕組み
  • 再利用資産を増やしたい
  • バージョン管理を厳密に行う
  • テンプレート統制を進めたい
  • Lambda+SAM直接運用 では要件を満たしきれず、サーバーレスアプリを再利用配布する仕組み を重視して AWS Serverless Application Repository を第一候補にする場合。
  • AWS Serverless Application Repository を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • AWS Proton と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Lambda+SAM直接運用 は汎用的な選択肢だが、AWS Serverless Application Repository は「サーバーレスアプリを再利用配布する仕組み」に責務を集中させやすい。
  • AWS Proton と比べると、AWS Serverless Application Repository は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SAR, 再利用, テンプレート, 配布管理
MWAA 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.0) Apache Airflow運用をマネージド化する基盤
  • Airflowを継続利用する
  • DAG運用を標準化したい
  • 基盤管理負荷を下げたい
  • Step Functions では要件を満たしきれず、Apache Airflow運用をマネージド化する基盤 を重視して MWAA を第一候補にする場合。
  • MWAA を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • EKS上Airflow と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Step Functions は汎用的な選択肢だが、MWAA は「Apache Airflow運用をマネージド化する基盤」に責務を集中させやすい。
  • EKS上Airflow と比べると、MWAA は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MWAA, Airflow, DAG, ワークフロー
AWS Proton 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.0) 配備テンプレートを標準化するプラットフォーム基盤
  • 組織横断テンプレート統制が必要
  • ライフサイクル情報を継続確認できる
  • 代替計画を保持できる
  • ECS/EKS直接運用 では要件を満たしきれず、配備テンプレートを標準化するプラットフォーム基盤 を重視して AWS Proton を第一候補にする場合。
  • AWS Proton を採用し、CloudFormation と組み合わせて責任境界を明確にしたい場合。
  • SAR と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ECS/EKS直接運用 は汎用的な選択肢だが、AWS Proton は「配備テンプレートを標準化するプラットフォーム基盤」に責務を集中させやすい。
  • SAR と比べると、AWS Proton は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudFormation との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Proton, テンプレート統制, 標準化, 移行計画
Red Hat OpenShift Service on AWS 🩶 完全ガイド T8 ★★★★☆☆☆☆☆☆(4.4) OpenShift運用をAWS上で提供するマネージド基盤
  • OpenShift資産を維持したい
  • 責任分界を明確にできる
  • コスト試算を事前に行える
  • EKS では要件を満たしきれず、OpenShift運用をAWS上で提供するマネージド基盤 を重視して Red Hat OpenShift Service on AWS を第一候補にする場合。
  • Red Hat OpenShift Service on AWS を採用し、ECR と組み合わせて責任境界を明確にしたい場合。
  • ECS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EKS は汎用的な選択肢だが、Red Hat OpenShift Service on AWS は「OpenShift運用をAWS上で提供するマネージド基盤」に責務を集中させやすい。
  • ECS と比べると、Red Hat OpenShift Service on AWS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECR との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ROSA, OpenShift, Kubernetes, 責任分界

Storage (8)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
S3 🟢 完全ガイド T1 ★★★★★★★★★★(9.6) 高耐久オブジェクトストレージ
  • オブジェクト保管が中心
  • ライフサイクル管理を運用できる
  • アクセス制御を厳密に設計できる
  • EBS では要件を満たしきれず、高耐久オブジェクトストレージ を重視して S3 を第一候補にする場合。
  • S3 を採用し、CloudFront と組み合わせて責任境界を明確にしたい場合。
  • EFS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EBS は汎用的な選択肢だが、S3 は「高耐久オブジェクトストレージ」に責務を集中させやすい。
  • EFS と比べると、S3 は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudFront との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
S3, オブジェクト, ライフサイクル, ストレージクラス
EBS 🟡 完全ガイド T2 ★★★★★★★★☆☆(8.1) EC2向けブロックストレージ
  • 低遅延ブロックI/Oが必要
  • EC2と同一AZで運用する
  • スナップショット運用を整備できる
  • EFS では要件を満たしきれず、EC2向けブロックストレージ を重視して EBS を第一候補にする場合。
  • EBS を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • FSx と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EFS は汎用的な選択肢だが、EBS は「EC2向けブロックストレージ」に責務を集中させやすい。
  • FSx と比べると、EBS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EBS, ブロック, IOPS, スナップショット
EFS 🟡 完全ガイド T2 ★★★★★★★★☆☆(7.5) マネージドNFS共有ファイルストレージ
  • 複数ノード共有が必要
  • POSIXファイル共有が前提
  • スループットモードを設計できる
  • EBS では要件を満たしきれず、マネージドNFS共有ファイルストレージ を重視して EFS を第一候補にする場合。
  • EFS を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • FSx と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EBS は汎用的な選択肢だが、EFS は「マネージドNFS共有ファイルストレージ」に責務を集中させやすい。
  • FSx と比べると、EFS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EFS, NFS, 共有ファイル, スループット
Storage Gateway 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.5) オンプレとAWSを接続するストレージブリッジ
  • オンプレ資産を継続利用
  • 段階移行が必要
  • 回線障害時の挙動を定義できる
  • DataSync では要件を満たしきれず、オンプレとAWSを接続するストレージブリッジ を重視して Storage Gateway を第一候補にする場合。
  • Storage Gateway を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • FSx と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DataSync は汎用的な選択肢だが、Storage Gateway は「オンプレとAWSを接続するストレージブリッジ」に責務を集中させやすい。
  • FSx と比べると、Storage Gateway は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Storage Gateway, ハイブリッド, 移行, キャッシュ
AWS Backup 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.3) バックアップポリシーを統合管理するサービス
  • 複数サービスを横断保護
  • 保持期間を統制
  • 監査要件に対応する
  • S3ライフサイクル では要件を満たしきれず、バックアップポリシーを統合管理するサービス を重視して AWS Backup を第一候補にする場合。
  • AWS Backup を採用し、EBS と組み合わせて責任境界を明確にしたい場合。
  • Storage Gateway と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • S3ライフサイクル は汎用的な選択肢だが、AWS Backup は「バックアップポリシーを統合管理するサービス」に責務を集中させやすい。
  • Storage Gateway と比べると、AWS Backup は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EBS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Backup, 保護ポリシー, 復旧, 保持期間
Glacier 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.2) 長期保管向け低コストアーカイブ層
  • 即時参照不要な長期保管
  • 復元時間を許容できる
  • 保管コスト最適化が目的
  • S3 Standard では要件を満たしきれず、長期保管向け低コストアーカイブ層 を重視して Glacier を第一候補にする場合。
  • Glacier を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • AWS Backup と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • S3 Standard は汎用的な選択肢だが、Glacier は「長期保管向け低コストアーカイブ層」に責務を集中させやすい。
  • AWS Backup と比べると、Glacier は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Glacier, アーカイブ, 復元時間, 低コスト保管
Snow Family 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.1) 大容量データをオフライン移送するデバイス群
  • ネットワーク転送が現実的でない
  • 移送期間を計画できる
  • 物理搬送の運用管理が可能
  • DataSync では要件を満たしきれず、大容量データをオフライン移送するデバイス群 を重視して Snow Family を第一候補にする場合。
  • Snow Family を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Storage Gateway と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DataSync は汎用的な選択肢だが、Snow Family は「大容量データをオフライン移送するデバイス群」に責務を集中させやすい。
  • Storage Gateway と比べると、Snow Family は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Snow Family, オフライン移送, 大容量データ, 物理搬送
FSx 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.8) 用途別に最適化されたマネージドファイルシステム
  • ワークロード別のファイル要件が明確
  • 性能プロファイルを選択できる
  • バックアップ運用を設計できる
  • EFS では要件を満たしきれず、用途別に最適化されたマネージドファイルシステム を重視して FSx を第一候補にする場合。
  • FSx を採用し、EKS と組み合わせて責任境界を明確にしたい場合。
  • EBS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EFS は汎用的な選択肢だが、FSx は「用途別に最適化されたマネージドファイルシステム」に責務を集中させやすい。
  • EBS と比べると、FSx は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EKS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
FSx, ファイルシステム, 性能最適化, 用途特化

Database (13)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
RDS 🟢 完全ガイド T1 ★★★★★★★★★☆(9.2) マネージドRDB運用基盤
  • RDBモデルが適合
  • バックアップ/復旧設計が可能
  • 運用自動化を重視する
  • Aurora では要件を満たしきれず、マネージドRDB運用基盤 を重視して RDS を第一候補にする場合。
  • RDS を採用し、AWS Backup と組み合わせて責任境界を明確にしたい場合。
  • DynamoDB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Aurora は汎用的な選択肢だが、RDS は「マネージドRDB運用基盤」に責務を集中させやすい。
  • DynamoDB と比べると、RDS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • AWS Backup との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
RDS, RDB, バックアップ, 運用設計
DynamoDB 🟢 完全ガイド T1 ★★★★★★★★★☆(8.8) キー設計主導のフルマネージドNoSQL
  • アクセスパターンを先に固定する
  • ホットパーティション回避を設計できる
  • 整合性/コストの両立を検証する
  • RDS では要件を満たしきれず、キー設計主導のフルマネージドNoSQL を重視して DynamoDB を第一候補にする場合。
  • DynamoDB を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Keyspaces と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • RDS は汎用的な選択肢だが、DynamoDB は「キー設計主導のフルマネージドNoSQL」に責務を集中させやすい。
  • Keyspaces と比べると、DynamoDB は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
DynamoDB, NoSQL, キー設計, スループット
Aurora 🟢 完全ガイド T1 ★★★★★★★★★☆(8.7) 高可用分散ストレージ型RDB
  • RDB互換が必要
  • 可用性要件が高い
  • 運用自動化を進めたい
  • RDS では要件を満たしきれず、高可用分散ストレージ型RDB を重視して Aurora を第一候補にする場合。
  • Aurora を採用し、RDS と組み合わせて責任境界を明確にしたい場合。
  • Aurora DSQL と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • RDS は汎用的な選択肢だが、Aurora は「高可用分散ストレージ型RDB」に責務を集中させやすい。
  • Aurora DSQL と比べると、Aurora は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • RDS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Aurora, RDB, 可用性, 運用自動化
Neptune 🟡 完全ガイド T2 ★★★★★★★☆☆☆(6.8) グラフデータ向けマネージドDB
  • グラフ探索要件がある
  • クエリ特性を把握している
  • 運用監視を定義できる
  • DocumentDB では要件を満たしきれず、グラフデータ向けマネージドDB を重視して Neptune を第一候補にする場合。
  • Neptune を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • RDS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DocumentDB は汎用的な選択肢だが、Neptune は「グラフデータ向けマネージドDB」に責務を集中させやすい。
  • RDS と比べると、Neptune は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Neptune, グラフDB, 探索, 可用性
Timestream 🟣 完全ガイド T5 ★★★★★★★☆☆☆(6.7) 時系列データ向け専用DB
  • 時系列データが中心
  • 保持期間設計が必要
  • 集計クエリを最適化したい
  • DynamoDB では要件を満たしきれず、時系列データ向け専用DB を重視して Timestream を第一候補にする場合。
  • Timestream を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • RDS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DynamoDB は汎用的な選択肢だが、Timestream は「時系列データ向け専用DB」に責務を集中させやすい。
  • RDS と比べると、Timestream は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Timestream, 時系列, 保持ポリシー, 集計
DocumentDB 🟠 完全ガイド T3 ★★★★★★★☆☆☆(6.6) ドキュメントデータ向けマネージドDB
  • ドキュメントモデル適合
  • インデックス設計を管理できる
  • 互換性要件を確認する
  • DynamoDB では要件を満たしきれず、ドキュメントデータ向けマネージドDB を重視して DocumentDB を第一候補にする場合。
  • DocumentDB を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • RDS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DynamoDB は汎用的な選択肢だが、DocumentDB は「ドキュメントデータ向けマネージドDB」に責務を集中させやすい。
  • RDS と比べると、DocumentDB は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
DocumentDB, ドキュメント, 互換性, 運用
Keyspaces 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.5) Cassandra互換マネージドDB
  • Cassandra互換が必要
  • パーティション設計が可能
  • 容量計画を持てる
  • DynamoDB では要件を満たしきれず、Cassandra互換マネージドDB を重視して Keyspaces を第一候補にする場合。
  • Keyspaces を採用し、Application Auto Scaling と組み合わせて責任境界を明確にしたい場合。
  • RDS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DynamoDB は汎用的な選択肢だが、Keyspaces は「Cassandra互換マネージドDB」に責務を集中させやすい。
  • RDS と比べると、Keyspaces は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Application Auto Scaling との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Keyspaces, Cassandra互換, 分散, スループット
ElastiCache 🟢 完全ガイド T1 ★★★★★★☆☆☆☆(6.3) インメモリキャッシュ基盤
  • キャッシュ戦略を設計できる
  • 失効ポリシーを運用できる
  • 整合性影響を評価できる
  • MemoryDB では要件を満たしきれず、インメモリキャッシュ基盤 を重視して ElastiCache を第一候補にする場合。
  • ElastiCache を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • DynamoDB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • MemoryDB は汎用的な選択肢だが、ElastiCache は「インメモリキャッシュ基盤」に責務を集中させやすい。
  • DynamoDB と比べると、ElastiCache は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ElastiCache, キャッシュ, 低遅延, 性能改善
QLDB 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.2) 改ざん検知可能な台帳DB
  • 監査証跡要件が厳しい
  • 追記中心モデルに適合
  • 運用監査を継続できる
  • RDS では要件を満たしきれず、改ざん検知可能な台帳DB を重視して QLDB を第一候補にする場合。
  • QLDB を採用し、KMS と組み合わせて責任境界を明確にしたい場合。
  • Aurora と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • RDS は汎用的な選択肢だが、QLDB は「改ざん検知可能な台帳DB」に責務を集中させやすい。
  • Aurora と比べると、QLDB は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • KMS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
QLDB, 台帳, 改ざん検知, 監査
MemoryDB 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.1) Redis互換の耐久性付きインメモリDB
  • 低遅延要件が厳しい
  • Redis互換運用が必要
  • 耐久性要件がある
  • ElastiCache では要件を満たしきれず、Redis互換の耐久性付きインメモリDB を重視して MemoryDB を第一候補にする場合。
  • MemoryDB を採用し、ECS と組み合わせて責任境界を明確にしたい場合。
  • DynamoDB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ElastiCache は汎用的な選択肢だが、MemoryDB は「Redis互換の耐久性付きインメモリDB」に責務を集中させやすい。
  • DynamoDB と比べると、MemoryDB は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MemoryDB, Redis互換, 低遅延, 耐久性
Aurora DSQL 🟤 完全ガイド T6 ★★★★★★☆☆☆☆(5.9) 分散SQLワークロード向けデータ基盤
  • 整合性要件を明確化
  • 分散時の遅延を許容できる
  • 運用責務を定義できる
  • Aurora では要件を満たしきれず、分散SQLワークロード向けデータ基盤 を重視して Aurora DSQL を第一候補にする場合。
  • Aurora DSQL を採用し、Aurora と組み合わせて責任境界を明確にしたい場合。
  • RDS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Aurora は汎用的な選択肢だが、Aurora DSQL は「分散SQLワークロード向けデータ基盤」に責務を集中させやすい。
  • RDS と比べると、Aurora DSQL は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Aurora との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Aurora DSQL, 分散SQL, 可用性, 運用設計
SimpleDB 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.2) シンプルな属性ストア型DB
  • データ規模が限定的
  • 機能要件がシンプル
  • 将来移行計画を持てる
  • DynamoDB では要件を満たしきれず、シンプルな属性ストア型DB を重視して SimpleDB を第一候補にする場合。
  • SimpleDB を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • Keyspaces と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DynamoDB は汎用的な選択肢だが、SimpleDB は「シンプルな属性ストア型DB」に責務を集中させやすい。
  • Keyspaces と比べると、SimpleDB は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SimpleDB, 属性ストア, 軽量, 移行
Oracle Database@AWS 🔘 完全ガイド T9 ★★★★☆☆☆☆☆☆(4.4) 要件別に選定するマネージドデータ基盤
  • データモデル適合を確認
  • 運用要件を満たす
  • 復旧計画を定義する
  • RDS では要件を満たしきれず、要件別に選定するマネージドデータ基盤 を重視して Oracle Database@AWS を第一候補にする場合。
  • Oracle Database@AWS を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • DynamoDB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • RDS は汎用的な選択肢だが、Oracle Database@AWS は「要件別に選定するマネージドデータ基盤」に責務を集中させやすい。
  • DynamoDB と比べると、Oracle Database@AWS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Database, 制約設計, 運用判断, 公式読解

Networking & Content Delivery (8)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
VPC 🟢 完全ガイド T1 ★★★★★★★★★☆(9.1) ネットワーク分離を担う仮想プライベート基盤
  • CIDR/ルート設計を早期確定
  • 境界防御と到達性を両立
  • 接続方式を責務分離で設計
  • Transit Gateway では要件を満たしきれず、ネットワーク分離を担う仮想プライベート基盤 を重視して VPC を第一候補にする場合。
  • VPC を採用し、Direct Connect と組み合わせて責任境界を明確にしたい場合。
  • Cloud WAN と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Transit Gateway は汎用的な選択肢だが、VPC は「ネットワーク分離を担う仮想プライベート基盤」に責務を集中させやすい。
  • Cloud WAN と比べると、VPC は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Direct Connect との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
VPC, ネットワーク分離, ルート制御, 境界設計
CloudFront 🟢 完全ガイド T1 ★★★★★★★★★☆(8.9) エッジ配信とキャッシュ最適化を担うCDN
  • キャッシュ戦略を先に設計
  • オリジン保護を組み込む
  • 配信コストと遅延を両立
  • Global Accelerator では要件を満たしきれず、エッジ配信とキャッシュ最適化を担うCDN を重視して CloudFront を第一候補にする場合。
  • CloudFront を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • ALB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Global Accelerator は汎用的な選択肢だが、CloudFront は「エッジ配信とキャッシュ最適化を担うCDN」に責務を集中させやすい。
  • ALB と比べると、CloudFront は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudFront, CDN, キャッシュ, エッジ配信
Route 53 🟢 完全ガイド T1 ★★★★★★★★★☆(8.6) DNSとヘルスチェックで経路制御する基盤
  • DNS設計を可用性要件と整合
  • フェイルオーバー条件を明示
  • TTLと伝播影響を管理
  • CloudFront では要件を満たしきれず、DNSとヘルスチェックで経路制御する基盤 を重視して Route 53 を第一候補にする場合。
  • Route 53 を採用し、VPC と組み合わせて責任境界を明確にしたい場合。
  • Global Accelerator と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudFront は汎用的な選択肢だが、Route 53 は「DNSとヘルスチェックで経路制御する基盤」に責務を集中させやすい。
  • Global Accelerator と比べると、Route 53 は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • VPC との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Route 53, DNS, フェイルオーバー, ヘルスチェック
Global Networks for Transit Gateways 🔘 完全ガイド T9 ★★★★★★★☆☆☆(6.7) 複数VPC/拠点接続を集約するハブ基盤
  • 接続集約でルート統制
  • セグメント分離を維持
  • 伝播ルールを明確化
  • Cloud WAN では要件を満たしきれず、複数VPC/拠点接続を集約するハブ基盤 を重視して Global Networks for Transit Gateways を第一候補にする場合。
  • Global Networks for Transit Gateways を採用し、VPC と組み合わせて責任境界を明確にしたい場合。
  • VPC Peering と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Cloud WAN は汎用的な選択肢だが、Global Networks for Transit Gateways は「複数VPC/拠点接続を集約するハブ基盤」に責務を集中させやすい。
  • VPC Peering と比べると、Global Networks for Transit Gateways は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • VPC との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Transit Gateway, 接続集約, ルート伝播, セグメント
AWS Direct Connect 🟠 完全ガイド T3 ★★★★★★★☆☆☆(6.6) 専用線でオンプレとAWSを接続する基盤
  • 回線冗長と帯域計画を必須化
  • 障害時の迂回経路を定義
  • 責任分界を運用文書化
  • VPN では要件を満たしきれず、専用線でオンプレとAWSを接続する基盤 を重視して AWS Direct Connect を第一候補にする場合。
  • AWS Direct Connect を採用し、VPC と組み合わせて責任境界を明確にしたい場合。
  • Transit Gateway と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • VPN は汎用的な選択肢だが、AWS Direct Connect は「専用線でオンプレとAWSを接続する基盤」に責務を集中させやすい。
  • Transit Gateway と比べると、AWS Direct Connect は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • VPC との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Direct Connect, 専用線, 冗長化, ハイブリッド
Cloud WAN 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.3) 広域ネットワークを統合管理する基盤
  • 拠点間ポリシーを統一
  • リージョン跨ぎ運用を標準化
  • 可視化を前提設計
  • Transit Gateway では要件を満たしきれず、広域ネットワークを統合管理する基盤 を重視して Cloud WAN を第一候補にする場合。
  • Cloud WAN を採用し、VPC と組み合わせて責任境界を明確にしたい場合。
  • Direct Connect と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Transit Gateway は汎用的な選択肢だが、Cloud WAN は「広域ネットワークを統合管理する基盤」に責務を集中させやすい。
  • Direct Connect と比べると、Cloud WAN は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • VPC との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Cloud WAN, 広域ネットワーク, ポリシー, 統合管理
Global Accelerator 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.3) グローバル経路最適化で到達性を高める基盤
  • グローバル遅延を短縮
  • リージョン障害時の切替を設計
  • 転送コストを試算
  • CloudFront では要件を満たしきれず、グローバル経路最適化で到達性を高める基盤 を重視して Global Accelerator を第一候補にする場合。
  • Global Accelerator を採用し、ALB と組み合わせて責任境界を明確にしたい場合。
  • Route 53 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudFront は汎用的な選択肢だが、Global Accelerator は「グローバル経路最適化で到達性を高める基盤」に責務を集中させやすい。
  • Route 53 と比べると、Global Accelerator は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ALB との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Global Accelerator, Anycast, 経路最適化, 可用性
VPC Lattice 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.3) ネットワーク分離を担う仮想プライベート基盤
  • VPC・アカウント境界を越えたサービス間通信を統一管理するか
  • IAM認証ベースのサービス間ゼロトラストか
  • ECS/EKS/Lambda混在環境での均一トラフィック制御か
  • Transit Gateway では要件を満たしきれず、ネットワーク分離を担う仮想プライベート基盤 を重視して VPC Lattice を第一候補にする場合。
  • VPC Lattice を採用し、Direct Connect と組み合わせて責任境界を明確にしたい場合。
  • Cloud WAN と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Transit Gateway は汎用的な選択肢だが、VPC Lattice は「ネットワーク分離を担う仮想プライベート基盤」に責務を集中させやすい。
  • Cloud WAN と比べると、VPC Lattice は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Direct Connect との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
VPC, ネットワーク分離, ルート制御, 境界設計

Security, Identity & Compliance (30)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
IAM 🟢 完全ガイド T1 ★★★★★★★★★★(9.5) 認証・認可の中核を担うアクセス管理基盤
  • 権限境界を最小化できる
  • ロール設計を運用可能
  • 監査ログを追跡可能
  • IAM Identity Center では要件を満たしきれず、認証・認可の中核を担うアクセス管理基盤 を重視して IAM を第一候補にする場合。
  • IAM を採用し、STS と組み合わせて責任境界を明確にしたい場合。
  • Cognito と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IAM Identity Center は汎用的な選択肢だが、IAM は「認証・認可の中核を担うアクセス管理基盤」に責務を集中させやすい。
  • Cognito と比べると、IAM は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • STS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
IAM, 最小権限, ロール, 認可
AWS KMS 🟢 完全ガイド T1 ★★★★★★★★★☆(8.8) 暗号鍵ライフサイクルを統制する鍵管理基盤
  • 鍵運用を標準化できる
  • 暗号化要件を満たせる
  • 監査証跡を維持できる
  • CloudHSM では要件を満たしきれず、暗号鍵ライフサイクルを統制する鍵管理基盤 を重視して AWS KMS を第一候補にする場合。
  • AWS KMS を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Secrets Manager と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudHSM は汎用的な選択肢だが、AWS KMS は「暗号鍵ライフサイクルを統制する鍵管理基盤」に責務を集中させやすい。
  • Secrets Manager と比べると、AWS KMS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
KMS, 鍵管理, 暗号化, 監査
Secrets Manager 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.0) 機密情報を安全に保管・ローテーションする基盤
  • 機密情報をコード外管理
  • 自動ローテーションを運用
  • アクセス監査を実施
  • Parameter Store では要件を満たしきれず、機密情報を安全に保管・ローテーションする基盤 を重視して Secrets Manager を第一候補にする場合。
  • Secrets Manager を採用し、RDS と組み合わせて責任境界を明確にしたい場合。
  • KMS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Parameter Store
  • KMS
  • Parameter Store は汎用的な選択肢だが、Secrets Manager は「機密情報を安全に保管・ローテーションする基盤」に責務を集中させやすい。
  • KMS と比べると、Secrets Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • RDS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Secrets Manager, シークレット, ローテーション, 監査
Cognito 🟢 完全ガイド T1 ★★★★★★★★☆☆(7.9) アプリ認証基盤を提供するID管理サービス
  • ユーザー認証を統合したい
  • MFA等の認証強化が必要
  • トークン連携を運用できる
  • IAM Identity Center では要件を満たしきれず、アプリ認証基盤を提供するID管理サービス を重視して Cognito を第一候補にする場合。
  • Cognito を採用し、API Gateway と組み合わせて責任境界を明確にしたい場合。
  • Auth0 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IAM Identity Center は汎用的な選択肢だが、Cognito は「アプリ認証基盤を提供するID管理サービス」に責務を集中させやすい。
  • Auth0 と比べると、Cognito は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • API Gateway との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Cognito, 認証, ユーザープール, トークン
GuardDuty 🟡 完全ガイド T2 ★★★★★★★★☆☆(7.8) 脅威検知をマネージドで行う監視基盤
  • 脅威検知を自動化したい
  • 検知→対応フローを持てる
  • 誤検知調整を継続できる
  • Security Hub では要件を満たしきれず、脅威検知をマネージドで行う監視基盤 を重視して GuardDuty を第一候補にする場合。
  • GuardDuty を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • Detective と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Security Hub は汎用的な選択肢だが、GuardDuty は「脅威検知をマネージドで行う監視基盤」に責務を集中させやすい。
  • Detective と比べると、GuardDuty は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
GuardDuty, 脅威検知, 異常検知, セキュリティ運用
AWS WAF 🟡 完全ガイド T2 ★★★★★★★★☆☆(7.7) アプリ層攻撃を制御する保護基盤
  • Web保護ルールを運用
  • 誤検知調整を継続
  • 配信基盤と統合できる
  • Shield Advanced では要件を満たしきれず、アプリ層攻撃を制御する保護基盤 を重視して AWS WAF を第一候補にする場合。
  • AWS WAF を採用し、CloudFront と組み合わせて責任境界を明確にしたい場合。
  • Network Firewall と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Shield Advanced は汎用的な選択肢だが、AWS WAF は「アプリ層攻撃を制御する保護基盤」に責務を集中させやすい。
  • Network Firewall と比べると、AWS WAF は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudFront との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
WAF, ルール制御, アプリ保護, 誤検知調整
AWS CloudHSM 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.2) 専用HSMで鍵を保護する暗号基盤
  • 専有鍵管理が必要
  • 規制要件を満たす
  • 運用責務を持てる
  • KMS では要件を満たしきれず、専用HSMで鍵を保護する暗号基盤 を重視して AWS CloudHSM を第一候補にする場合。
  • AWS CloudHSM を採用し、KMS と組み合わせて責任境界を明確にしたい場合。
  • External HSM と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • KMS
  • External HSM
  • KMS は汎用的な選択肢だが、AWS CloudHSM は「専用HSMで鍵を保護する暗号基盤」に責務を集中させやすい。
  • External HSM と比べると、AWS CloudHSM は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • KMS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudHSM, HSM, 専用鍵管理, 規制対応
Inspector 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.1) 脆弱性評価を継続実施する診断基盤
  • 脆弱性管理を継続
  • 修正優先度を定義
  • 対象資産を可視化
  • Security Hub では要件を満たしきれず、脆弱性評価を継続実施する診断基盤 を重視して Inspector を第一候補にする場合。
  • Inspector を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • GuardDuty と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Security Hub は汎用的な選択肢だが、Inspector は「脆弱性評価を継続実施する診断基盤」に責務を集中させやすい。
  • GuardDuty と比べると、Inspector は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Inspector, 脆弱性, 診断, 優先度
AWS STS 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.1) セキュリティ統制を支えるマネージド基盤
  • 一時的認証情報で短命アクセスを付与するか
  • クロスアカウントロール引き受けが必要か
  • 長期キー不要でIAMロールを動的付与するか
  • IAM では要件を満たしきれず、セキュリティ統制を支えるマネージド基盤 を重視して AWS STS を第一候補にする場合。
  • AWS STS を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • Security Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IAM は汎用的な選択肢だが、AWS STS は「セキュリティ統制を支えるマネージド基盤」に責務を集中させやすい。
  • Security Hub と比べると、AWS STS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Security, 統制, 監査, 運用
CodeArtifact 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.0) セキュリティ統制を支えるマネージド基盤
  • パッケージリポジトリをIAM制御でプライベート管理するか
  • npm/pip/Maven/NuGetのキャッシュ管理が必要か
  • サプライチェーンリスクを内製リポジトリで管理するか
  • IAM では要件を満たしきれず、セキュリティ統制を支えるマネージド基盤 を重視して CodeArtifact を第一候補にする場合。
  • CodeArtifact を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • Security Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IAM は汎用的な選択肢だが、CodeArtifact は「セキュリティ統制を支えるマネージド基盤」に責務を集中させやすい。
  • Security Hub と比べると、CodeArtifact は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Security, 統制, 監査, 運用
IAM Identity Center 🟡 完全ガイド T2 ★★★★★★★☆☆☆(6.9) SSOと権限割当を統制する認証基盤
  • SSO統合を進めたい
  • アカウント権限を統一管理
  • 監査対応を容易化
  • IAM では要件を満たしきれず、SSOと権限割当を統制する認証基盤 を重視して IAM Identity Center を第一候補にする場合。
  • IAM Identity Center を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • Cognito と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IAM は汎用的な選択肢だが、IAM Identity Center は「SSOと権限割当を統制する認証基盤」に責務を集中させやすい。
  • Cognito と比べると、IAM Identity Center は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
IAM Identity Center, SSO, 権限管理, 統制
Directory Service 🟣 完全ガイド T5 ★★★★★★★☆☆☆(6.7) ディレクトリ連携を提供する認証統合基盤
  • 既存AD連携が必要
  • 認証統合を維持
  • 運用責務を明確化
  • IAM Identity Center では要件を満たしきれず、ディレクトリ連携を提供する認証統合基盤 を重視して Directory Service を第一候補にする場合。
  • Directory Service を採用し、WorkSpaces と組み合わせて責任境界を明確にしたい場合。
  • Cognito と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IAM Identity Center は汎用的な選択肢だが、Directory Service は「ディレクトリ連携を提供する認証統合基盤」に責務を集中させやすい。
  • Cognito と比べると、Directory Service は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • WorkSpaces との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Directory Service, AD連携, 認証統合, ディレクトリ
IAM Access Analyzer 🟡 完全ガイド T2 ★★★★★★★☆☆☆(6.7) 外部公開リスクを分析するアクセス検証基盤
  • 公開設定を検査したい
  • 過剰権限を検出したい
  • 改善サイクルを回せる
  • Config では要件を満たしきれず、外部公開リスクを分析するアクセス検証基盤 を重視して IAM Access Analyzer を第一候補にする場合。
  • IAM Access Analyzer を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • Security Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Config は汎用的な選択肢だが、IAM Access Analyzer は「外部公開リスクを分析するアクセス検証基盤」に責務を集中させやすい。
  • Security Hub と比べると、IAM Access Analyzer は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Access Analyzer, 公開分析, 権限検査, リスク検出
Macie 🟡 完全ガイド T2 ★★★★★★★☆☆☆(6.7) 機微データ検出と保護を支援する分類基盤
  • 機微データを検出したい
  • 保護ルールを運用
  • 監査証跡を残せる
  • Security Hub では要件を満たしきれず、機微データ検出と保護を支援する分類基盤 を重視して Macie を第一候補にする場合。
  • Macie を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • GuardDuty と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Security Hub は汎用的な選択肢だが、Macie は「機微データ検出と保護を支援する分類基盤」に責務を集中させやすい。
  • GuardDuty と比べると、Macie は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Macie, 機微データ, 分類, 保護
Security Hub CSPM 🟡 完全ガイド T2 ★★★★★★★☆☆☆(6.7) セキュリティ所見を集約する統合可視化基盤
  • 所見集約を重視
  • 対応優先度を統一
  • 複数検知源を連携
  • GuardDuty では要件を満たしきれず、セキュリティ所見を集約する統合可視化基盤 を重視して Security Hub CSPM を第一候補にする場合。
  • Security Hub CSPM を採用し、Config と組み合わせて責任境界を明確にしたい場合。
  • Detective と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • GuardDuty は汎用的な選択肢だが、Security Hub CSPM は「セキュリティ所見を集約する統合可視化基盤」に責務を集中させやすい。
  • Detective と比べると、Security Hub CSPM は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Config との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Security Hub, 所見集約, 統合監視, 優先度
IAM Roles Anywhere 🟠 完全ガイド T3 ★★★★★★★☆☆☆(6.6) 外部ワークロードにIAMロールを安全適用する基盤
  • 外部環境連携が必要
  • 証明書ベース認証を運用
  • 権限境界を維持
  • OIDC Federation では要件を満たしきれず、外部ワークロードにIAMロールを安全適用する基盤 を重視して IAM Roles Anywhere を第一候補にする場合。
  • IAM Roles Anywhere を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • 長期キー運用 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • OIDC Federation
  • 長期キー運用
  • OIDC Federation は汎用的な選択肢だが、IAM Roles Anywhere は「外部ワークロードにIAMロールを安全適用する基盤」に責務を集中させやすい。
  • 長期キー運用 と比べると、IAM Roles Anywhere は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
IAM Roles Anywhere, 外部連携, 証明書認証, 権限委譲
Detective 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.2) インシデント調査を支援する相関分析基盤
  • 調査時間短縮を重視
  • 証跡相関を行う
  • 調査手順を標準化
  • GuardDuty では要件を満たしきれず、インシデント調査を支援する相関分析基盤 を重視して Detective を第一候補にする場合。
  • Detective を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • Security Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • GuardDuty は汎用的な選択肢だが、Detective は「インシデント調査を支援する相関分析基盤」に責務を集中させやすい。
  • Security Hub と比べると、Detective は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Detective, 調査, 相関分析, インシデント
Shield Advanced 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.2) DDoS耐性を強化する保護基盤
  • DDoS対策を重視
  • 対応手順を整備
  • 配信基盤と統合
  • WAF では要件を満たしきれず、DDoS耐性を強化する保護基盤 を重視して Shield Advanced を第一候補にする場合。
  • Shield Advanced を採用し、Route 53 と組み合わせて責任境界を明確にしたい場合。
  • CloudFront と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • WAF は汎用的な選択肢だが、Shield Advanced は「DDoS耐性を強化する保護基盤」に責務を集中させやすい。
  • CloudFront と比べると、Shield Advanced は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Route 53 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Shield Advanced, DDoS, 耐性, 保護
Audit Manager 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.1) 監査証跡の収集・整理を自動化する基盤
  • 監査対応を効率化
  • 証跡収集を標準化
  • 統制要件に追従
  • Config では要件を満たしきれず、監査証跡の収集・整理を自動化する基盤 を重視して Audit Manager を第一候補にする場合。
  • Audit Manager を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • Security Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Config は汎用的な選択肢だが、Audit Manager は「監査証跡の収集・整理を自動化する基盤」に責務を集中させやすい。
  • Security Hub と比べると、Audit Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Audit Manager, 監査, 証跡, 統制
AWS Security Incident Response 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) セキュリティインシデント対応を支援する基盤
  • 初動手順を標準化
  • エスカレーションを明確化
  • 訓練を継続
  • Incident Manager では要件を満たしきれず、セキュリティインシデント対応を支援する基盤 を重視して AWS Security Incident Response を第一候補にする場合。
  • AWS Security Incident Response を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • 手動運用 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Incident Manager は汎用的な選択肢だが、AWS Security Incident Response は「セキュリティインシデント対応を支援する基盤」に責務を集中させやすい。
  • 手動運用 と比べると、AWS Security Incident Response は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Security Incident Response, 初動, 対応手順, エスカレーション
Firewall Manager 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.3) 複数アカウントの防御ポリシーを統制する基盤
  • 組織横断でポリシー統制
  • 逸脱検知を運用
  • 統制変更を標準化
  • Organizations SCP では要件を満たしきれず、複数アカウントの防御ポリシーを統制する基盤 を重視して Firewall Manager を第一候補にする場合。
  • Firewall Manager を採用し、WAF と組み合わせて責任境界を明確にしたい場合。
  • Security Hub と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations SCP は汎用的な選択肢だが、Firewall Manager は「複数アカウントの防御ポリシーを統制する基盤」に責務を集中させやすい。
  • Security Hub と比べると、Firewall Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • WAF との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Firewall Manager, ポリシー統制, 組織横断, 防御運用
Security Lake 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.3) セキュリティログを集約するデータレイク基盤
  • ログ統合分析を重視
  • スキーマ標準化を進める
  • 長期分析を行う
  • CloudWatch Logs では要件を満たしきれず、セキュリティログを集約するデータレイク基盤 を重視して Security Lake を第一候補にする場合。
  • Security Lake を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • SIEM と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudWatch Logs は汎用的な選択肢だが、Security Lake は「セキュリティログを集約するデータレイク基盤」に責務を集中させやすい。
  • SIEM と比べると、Security Lake は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Security Lake, ログ集約, 分析, 標準化
Verified Access 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.3) ゼロトラスト接続を実現するアクセス基盤
  • 接続条件を厳密化
  • 端末/ユーザー条件を評価
  • アクセス監査を継続
  • VPN では要件を満たしきれず、ゼロトラスト接続を実現するアクセス基盤 を重視して Verified Access を第一候補にする場合。
  • Verified Access を採用し、IAM Identity Center と組み合わせて責任境界を明確にしたい場合。
  • ZTNA製品 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • VPN
  • ZTNA製品
  • VPN は汎用的な選択肢だが、Verified Access は「ゼロトラスト接続を実現するアクセス基盤」に責務を集中させやすい。
  • ZTNA製品 と比べると、Verified Access は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM Identity Center との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Verified Access, ゼロトラスト, 接続制御, 評価ポリシー
AWS Signer 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.2) コード署名を統制する供給網保護基盤
  • 署名運用を標準化
  • 改ざん検知を強化
  • リリース統制を実施
  • KMS では要件を満たしきれず、コード署名を統制する供給網保護基盤 を重視して AWS Signer を第一候補にする場合。
  • AWS Signer を採用し、CodePipeline と組み合わせて責任境界を明確にしたい場合。
  • 外部署名基盤 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • KMS
  • 外部署名基盤
  • KMS は汎用的な選択肢だが、AWS Signer は「コード署名を統制する供給網保護基盤」に責務を集中させやすい。
  • 外部署名基盤 と比べると、AWS Signer は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodePipeline との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Signer, 署名, サプライチェーン, 改ざん検知
AWS WAF Classic ★★★★★☆☆☆☆☆(5.2) アプリ層攻撃を制御する保護基盤
  • 既存WAF Classicルールを維持継続運用するか
  • WAF v2への段階移行期間中か
  • Classic特有のIPセット/文字列マッチルールで十分か
  • Shield Advanced では要件を満たしきれず、アプリ層攻撃を制御する保護基盤 を重視して AWS WAF Classic を第一候補にする場合。
  • AWS WAF Classic を採用し、CloudFront と組み合わせて責任境界を明確にしたい場合。
  • Network Firewall と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Shield Advanced は汎用的な選択肢だが、AWS WAF Classic は「アプリ層攻撃を制御する保護基盤」に責務を集中させやすい。
  • Network Firewall と比べると、AWS WAF Classic は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudFront との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
WAF, ルール制御, アプリ保護, 誤検知調整
AWS Certificate Manager 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.1) 証明書ライフサイクルを管理する基盤
  • 証明書更新を自動化
  • 公開経路と統合
  • 失効対応を運用
  • Private CA では要件を満たしきれず、証明書ライフサイクルを管理する基盤 を重視して AWS Certificate Manager を第一候補にする場合。
  • AWS Certificate Manager を採用し、CloudFront と組み合わせて責任境界を明確にしたい場合。
  • 手動証明書運用 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Private CA は汎用的な選択肢だが、AWS Certificate Manager は「証明書ライフサイクルを管理する基盤」に責務を集中させやすい。
  • 手動証明書運用 と比べると、AWS Certificate Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudFront との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ACM, 証明書, TLS, 更新
Verified Permissions 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.0) アプリ認可ポリシーを外部化する基盤
  • 認可ロジックを分離
  • 監査可能な認可判断
  • ポリシー更新を安全化
  • IAM では要件を満たしきれず、アプリ認可ポリシーを外部化する基盤 を重視して Verified Permissions を第一候補にする場合。
  • Verified Permissions を採用し、Cognito と組み合わせて責任境界を明確にしたい場合。
  • アプリ内認可 と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IAM
  • アプリ内認可
  • IAM は汎用的な選択肢だが、Verified Permissions は「アプリ認可ポリシーを外部化する基盤」に責務を集中させやすい。
  • アプリ内認可 と比べると、Verified Permissions は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Cognito との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Verified Permissions, 認可外部化, ポリシー, 監査
Network Firewall 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(4.8) ネットワーク境界で通信制御する防御基盤
  • 境界制御を強化
  • ルール運用を継続
  • 経路設計と一体化
  • WAF では要件を満たしきれず、ネットワーク境界で通信制御する防御基盤 を重視して Network Firewall を第一候補にする場合。
  • Network Firewall を採用し、VPC と組み合わせて責任境界を明確にしたい場合。
  • GWLB と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • WAF は汎用的な選択肢だが、Network Firewall は「ネットワーク境界で通信制御する防御基盤」に責務を集中させやすい。
  • GWLB と比べると、Network Firewall は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • VPC との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Network Firewall, 境界防御, ルール制御, 通信検査
Inspector Classic ★★★★★☆☆☆☆☆(4.6) 脆弱性評価を継続実施する診断基盤
  • Inspector Classic継続稼働が必要な移行過渡期か
  • EOL後の新Inspector(v2)移行計画を策定済みか
  • EC2エージェントベースの旧評価ルールが前提か
  • Security Hub では要件を満たしきれず、脆弱性評価を継続実施する診断基盤 を重視して Inspector Classic を第一候補にする場合。
  • Inspector Classic を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • GuardDuty と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Security Hub は汎用的な選択肢だが、Inspector Classic は「脆弱性評価を継続実施する診断基盤」に責務を集中させやすい。
  • GuardDuty と比べると、Inspector Classic は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Inspector, 脆弱性, 診断, 優先度
AWS Private CA 🟤 完全ガイド T6 ★★★★☆☆☆☆☆☆(4.5) プライベート証明書発行を統制する基盤
  • 内部PKIが必要
  • 発行ポリシーを運用
  • 監査要件を満たす
  • ACM では要件を満たしきれず、プライベート証明書発行を統制する基盤 を重視して AWS Private CA を第一候補にする場合。
  • AWS Private CA を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • 外部CA と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ACM は汎用的な選択肢だが、AWS Private CA は「プライベート証明書発行を統制する基盤」に責務を集中させやすい。
  • 外部CA と比べると、AWS Private CA は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Private CA, PKI, 証明書発行, 内部CA

Observability (3)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
Managed Grafana 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.3) Grafana運用をマネージド化して横断可視化を統一する基盤
  • 既存ダッシュボード資産を移行しやすいか
  • 認証連携と権限制御を一元化できるか
  • データソース増加時も運用を維持できるか
  • CloudWatch は汎用的な選択肢だが、Managed Grafana は「Grafana運用をマネージド化して横断可視化を統一する基盤」に責務を集中させやすい。
  • OpenSearch Service と比べると、Managed Grafana は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Managed Service for Prometheus との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Managed Grafana, ダッシュボード, 可視化統合, 権限統制
DevOps Guru 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(4.9) 機械学習で異常兆候を検出し原因調査を短縮する運用支援
  • 対象ワークロードの観測データが十分か
  • 通知ノイズを運用で吸収できるか
  • 運用改善サイクルへ組み込めるか
  • CloudWatch では要件を満たしきれず、機械学習で異常兆候を検出し原因調査を短縮する運用支援 を重視して DevOps Guru を第一候補にする場合。
  • DevOps Guru を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • Trusted Advisor と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudWatch は汎用的な選択肢だが、DevOps Guru は「機械学習で異常兆候を検出し原因調査を短縮する運用支援」に責務を集中させやすい。
  • Trusted Advisor と比べると、DevOps Guru は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
DevOps Guru, 異常検知, インサイト, 運用改善
Managed Service for Prometheus 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(4.7) Prometheus互換メトリクスを大規模運用する収集・評価基盤
  • PromQL運用を継続したいか
  • 高カーディナリティ対策を設計できるか
  • 保持期間と課金を制御できるか
  • CloudWatch は汎用的な選択肢だが、Managed Service for Prometheus は「Prometheus互換メトリクスを大規模運用する収集・評価基盤」に責務を集中させやすい。
  • Managed Grafana と比べると、Managed Service for Prometheus は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EKS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AMP, Prometheus, PromQL, メトリクス保持

Analytics (18)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
Athena 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.0) S3上データをサーバレスSQLで直接分析するクエリエンジン
  • スキャン量最適化の設計が可能か
  • テーブル定義と更新頻度を管理できるか
  • 即時分析の需要が高いか
  • Redshift では要件を満たしきれず、S3上データをサーバレスSQLで直接分析するクエリエンジン を重視して Athena を第一候補にする場合。
  • Athena を採用し、Glue Data Catalog と組み合わせて責任境界を明確にしたい場合。
  • EMR と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Redshift は汎用的な選択肢だが、Athena は「S3上データをサーバレスSQLで直接分析するクエリエンジン」に責務を集中させやすい。
  • EMR と比べると、Athena は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Glue Data Catalog との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Athena, サーバレスSQL, S3分析, クエリ課金
AWS Glue 🟢 完全ガイド T1 ★★★★★★★★☆☆(7.9) データ統合とメタデータ管理を担うETL中核サービス
  • データカタログ統合が必要か
  • ETLジョブ数の増加に対応できるか
  • データ品質管理を標準化したいか
  • EMR では要件を満たしきれず、データ統合とメタデータ管理を担うETL中核サービス を重視して AWS Glue を第一候補にする場合。
  • AWS Glue を採用し、Athena と組み合わせて責任境界を明確にしたい場合。
  • DataBrew と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EMR は汎用的な選択肢だが、AWS Glue は「データ統合とメタデータ管理を担うETL中核サービス」に責務を集中させやすい。
  • DataBrew と比べると、AWS Glue は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Athena との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Glue, ETL, Data Catalog, スキーマ管理
Redshift 🟡 完全ガイド T2 ★★★★★★★★☆☆(7.6) 高性能DWHで複雑集計を高速実行する分析基盤
  • 集計性能要求が高いか
  • 同時実行とワークロード分離が必要か
  • 運用チューニングを継続できるか
  • Athena では要件を満たしきれず、高性能DWHで複雑集計を高速実行する分析基盤 を重視して Redshift を第一候補にする場合。
  • Redshift を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • RDS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、Redshift は「高性能DWHで複雑集計を高速実行する分析基盤」に責務を集中させやすい。
  • RDS と比べると、Redshift は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Redshift, DWH, 列指向, 分析最適化
OpenSearch Service 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.4) 全文検索とログ分析を統合する分散検索基盤
  • 検索レイテンシ要件が厳しいか
  • インデックス運用を継続できるか
  • ログ分析と検索を統合したいか
  • CloudWatch Logs Insights では要件を満たしきれず、全文検索とログ分析を統合する分散検索基盤 を重視して OpenSearch Service を第一候補にする場合。
  • OpenSearch Service を採用し、Kinesis Data Firehose と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudWatch Logs Insights は汎用的な選択肢だが、OpenSearch Service は「全文検索とログ分析を統合する分散検索基盤」に責務を集中させやすい。
  • Redshift と比べると、OpenSearch Service は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Kinesis Data Firehose との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
OpenSearch, 全文検索, ログ分析, インデックス
Managed Service for Apache Flink 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.4) データ取り込み・加工・活用を最適化する分析サービス
  • 処理遅延と鮮度要件に合うか
  • 運用体制で継続改善できるか
  • 課金モデルを制御できるか
  • Athena では要件を満たしきれず、データ取り込み・加工・活用を最適化する分析サービス を重視して Managed Service for Apache Flink を第一候補にする場合。
  • Managed Service for Apache Flink を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、Managed Service for Apache Flink は「データ取り込み・加工・活用を最適化する分析サービス」に責務を集中させやすい。
  • Redshift と比べると、Managed Service for Apache Flink は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Managed Service for Apache Flink, 分析, データ基盤, 可観測性
AWS Clean Rooms 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.3) 機密データを保護しながら共同分析を実現する分析環境
  • 外部組織との共同分析が必要か
  • 生データ非開示が必須か
  • 分析クエリを統制できるか
  • Data Exchange では要件を満たしきれず、機密データを保護しながら共同分析を実現する分析環境 を重視して AWS Clean Rooms を第一候補にする場合。
  • AWS Clean Rooms を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • S3 Access Points と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Data Exchange は汎用的な選択肢だが、AWS Clean Rooms は「機密データを保護しながら共同分析を実現する分析環境」に責務を集中させやすい。
  • S3 Access Points と比べると、AWS Clean Rooms は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Clean Rooms, 共同分析, プライバシー保護, データ連携
AWS Data Exchange 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.3) 外部データ製品の購読と提供を安全に行う流通基盤
  • 外部データ調達頻度が高いか
  • 契約/利用範囲を管理できるか
  • 継続更新データが必要か
  • Marketplace では要件を満たしきれず、外部データ製品の購読と提供を安全に行う流通基盤 を重視して AWS Data Exchange を第一候補にする場合。
  • AWS Data Exchange を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • direct share と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Marketplace は汎用的な選択肢だが、AWS Data Exchange は「外部データ製品の購読と提供を安全に行う流通基盤」に責務を集中させやすい。
  • direct share と比べると、AWS Data Exchange は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Data Exchange, データ流通, 購読, 外部データ
AWS Clean Rooms ML 🔘 完全ガイド T9 ★★★★★★☆☆☆☆(6.2) 機密データを保護しながら共同分析を実現する分析環境
  • 生データ非開示でMLモデルを協調学習するか
  • 機密データでのルックアライク分析が必要か
  • Clean RoomsとのデータメッシュML統合か
  • Data Exchange では要件を満たしきれず、機密データを保護しながら共同分析を実現する分析環境 を重視して AWS Clean Rooms ML を第一候補にする場合。
  • AWS Clean Rooms ML を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • S3 Access Points と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Data Exchange は汎用的な選択肢だが、AWS Clean Rooms ML は「機密データを保護しながら共同分析を実現する分析環境」に責務を集中させやすい。
  • S3 Access Points と比べると、AWS Clean Rooms ML は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Clean Rooms, 共同分析, プライバシー保護, データ連携
DataZone 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.0) データ資産の公開・発見・統制を横断管理するガバナンス基盤
  • 部門横断のデータ共有課題があるか
  • メタデータ統制を標準化したいか
  • セルフサービス分析を促進したいか
  • Lake Formation では要件を満たしきれず、データ資産の公開・発見・統制を横断管理するガバナンス基盤 を重視して DataZone を第一候補にする場合。
  • DataZone を採用し、IAM Identity Center と組み合わせて責任境界を明確にしたい場合。
  • Glue Data Catalog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Lake Formation は汎用的な選択肢だが、DataZone は「データ資産の公開・発見・統制を横断管理するガバナンス基盤」に責務を集中させやすい。
  • Glue Data Catalog と比べると、DataZone は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM Identity Center との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
DataZone, データガバナンス, カタログ, 共有統制
EMR 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.0) 分散処理基盤をマネージド提供する大規模データ処理サービス
  • Spark/Hadoop資産を活用するか
  • ジョブ処理量の変動が大きいか
  • クラスタ最適化の運用体制があるか
  • Glue では要件を満たしきれず、分散処理基盤をマネージド提供する大規模データ処理サービス を重視して EMR を第一候補にする場合。
  • EMR を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Athena と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Glue は汎用的な選択肢だが、EMR は「分散処理基盤をマネージド提供する大規模データ処理サービス」に責務を集中させやすい。
  • Athena と比べると、EMR は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EMR, Spark, 分散処理, バッチ分析
Lake Formation 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.9) データ取り込み・加工・活用を最適化する分析サービス
  • 列・行レベルのFGACアクセス制御が必要か
  • クロスアカウントのデータメッシュ共有か
  • Glue Data Catalogとの統合ガバナンスか
  • Athena では要件を満たしきれず、データ取り込み・加工・活用を最適化する分析サービス を重視して Lake Formation を第一候補にする場合。
  • Lake Formation を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、Lake Formation は「データ取り込み・加工・活用を最適化する分析サービス」に責務を集中させやすい。
  • Redshift と比べると、Lake Formation は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Lake Formation, 分析, データ基盤, 可観測性
AWS Data Pipeline 🔘 完全ガイド T9 ★★★★★★☆☆☆☆(5.5) データ取り込み・加工・活用を最適化する分析サービス
  • 既存Data Pipelineワークロードの継続稼働のみか
  • Step Functions/Glueへの移行計画が必要か
  • スケジュールベースのETLオーケストレーション(レガシー)か
  • Athena では要件を満たしきれず、データ取り込み・加工・活用を最適化する分析サービス を重視して AWS Data Pipeline を第一候補にする場合。
  • AWS Data Pipeline を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、AWS Data Pipeline は「データ取り込み・加工・活用を最適化する分析サービス」に責務を集中させやすい。
  • Redshift と比べると、AWS Data Pipeline は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Data Pipeline, 分析, データ基盤, 可観測性
DataBrew 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) データ取り込み・加工・活用を最適化する分析サービス
  • コードなしのビジュアルデータ準備か
  • 250以上の組み込み変換で要件を満たすか
  • データプロファイリングと品質チェックか
  • Athena では要件を満たしきれず、データ取り込み・加工・活用を最適化する分析サービス を重視して DataBrew を第一候補にする場合。
  • DataBrew を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、DataBrew は「データ取り込み・加工・活用を最適化する分析サービス」に責務を集中させやすい。
  • Redshift と比べると、DataBrew は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
DataBrew, 分析, データ基盤, 可観測性
Kinesis Video Streams 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) データ取り込み・加工・活用を最適化する分析サービス
  • カメラ/IoTデバイスからの動画ストリーム収集か
  • WebRTC双方向通信が必要か
  • Rekognition Videoとのリアルタイム分析か
  • Athena では要件を満たしきれず、データ取り込み・加工・活用を最適化する分析サービス を重視して Kinesis Video Streams を第一候補にする場合。
  • Kinesis Video Streams を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、Kinesis Video Streams は「データ取り込み・加工・活用を最適化する分析サービス」に責務を集中させやすい。
  • Redshift と比べると、Kinesis Video Streams は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Kinesis Video Streams, 分析, データ基盤, 可観測性
CloudSearch 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.3) データ取り込み・加工・活用を最適化する分析サービス
  • 既存CloudSearchを継続利用するか
  • OpenSearch Serviceへの移行計画か
  • Solrベースの全文検索(レガシー)か
  • Athena では要件を満たしきれず、データ取り込み・加工・活用を最適化する分析サービス を重視して CloudSearch を第一候補にする場合。
  • CloudSearch を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、CloudSearch は「データ取り込み・加工・活用を最適化する分析サービス」に責務を集中させやすい。
  • Redshift と比べると、CloudSearch は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudSearch, 分析, データ基盤, 可観測性
Firehose 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.3) ストリームデータを宛先へ自動配送する配信サービス
  • 運用レスで配信したいか
  • 変換/圧縮処理の要件があるか
  • 配信先の多様性が必要か
  • Kinesis Data Streams では要件を満たしきれず、ストリームデータを宛先へ自動配送する配信サービス を重視して Firehose を第一候補にする場合。
  • Firehose を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Glue と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Kinesis Data Streams は汎用的な選択肢だが、Firehose は「ストリームデータを宛先へ自動配送する配信サービス」に責務を集中させやすい。
  • Glue と比べると、Firehose は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Firehose, 配送, バッファ, ストリーム集約
Kinesis Data Streams 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.3) リアルタイムイベントを低遅延で収集するストリーム基盤
  • 秒単位での取り込みが必要か
  • 順序性と再処理要件があるか
  • コンシューマ拡張を見込むか
  • MSK では要件を満たしきれず、リアルタイムイベントを低遅延で収集するストリーム基盤 を重視して Kinesis Data Streams を第一候補にする場合。
  • Kinesis Data Streams を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • SQS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • MSK は汎用的な選択肢だが、Kinesis Data Streams は「リアルタイムイベントを低遅延で収集するストリーム基盤」に責務を集中させやすい。
  • SQS と比べると、Kinesis Data Streams は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Kinesis, ストリーム, 低遅延, リアルタイム処理
FinSpace 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(4.7) データ取り込み・加工・活用を最適化する分析サービス
  • 金融時系列データの専門管理か
  • 金融計算フレームワーク統合が必要か
  • データ系譜と監査証跡が要件か
  • Athena では要件を満たしきれず、データ取り込み・加工・活用を最適化する分析サービス を重視して FinSpace を第一候補にする場合。
  • FinSpace を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Redshift と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Athena は汎用的な選択肢だが、FinSpace は「データ取り込み・加工・活用を最適化する分析サービス」に責務を集中させやすい。
  • Redshift と比べると、FinSpace は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
FinSpace, 分析, データ基盤, 可観測性

Machine Learning & AI (20)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
SageMaker AI 🟢 完全ガイド T1 ★★★★★★★☆☆☆(6.9) 機械学習ライフサイクル全体を統合管理する開発基盤
  • MLOps体制を構築するか
  • 学習から推論まで一元管理したいか
  • 実験再現性を重視するか
  • Vertex AI では要件を満たしきれず、機械学習ライフサイクル全体を統合管理する開発基盤 を重視して SageMaker AI を第一候補にする場合。
  • SageMaker AI を採用し、ECR と組み合わせて責任境界を明確にしたい場合。
  • Databricks と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Vertex AI
  • Databricks
  • Vertex AI は汎用的な選択肢だが、SageMaker AI は「機械学習ライフサイクル全体を統合管理する開発基盤」に責務を集中させやすい。
  • Databricks と比べると、SageMaker AI は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECR との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SageMaker, MLOps, 学習基盤, 推論運用
Fraud Detector 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.9) 不正検知モデルを運用統合するリスク判定基盤
  • 不正判定のリアルタイム性が必要か
  • 説明可能性を担保できるか
  • 誤検知許容を定義できるか
  • custom fraud model では要件を満たしきれず、不正検知モデルを運用統合するリスク判定基盤 を重視して Fraud Detector を第一候補にする場合。
  • Fraud Detector を採用し、EventBridge と組み合わせて責任境界を明確にしたい場合。
  • GuardDuty と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom fraud model は汎用的な選択肢だが、Fraud Detector は「不正検知モデルを運用統合するリスク判定基盤」に責務を集中させやすい。
  • GuardDuty と比べると、Fraud Detector は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EventBridge との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Fraud Detector, 不正検知, リスクスコア, 判定
Transcribe 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.9) 音声をテキスト化して分析可能にする文字起こし基盤
  • リアルタイム文字起こしが必要か
  • 話者分離要件があるか
  • 誤認識補正運用を回せるか
  • Whisper では要件を満たしきれず、音声をテキスト化して分析可能にする文字起こし基盤 を重視して Transcribe を第一候補にする場合。
  • Transcribe を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom ASR と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Whisper
  • custom ASR
  • Whisper は汎用的な選択肢だが、Transcribe は「音声をテキスト化して分析可能にする文字起こし基盤」に責務を集中させやすい。
  • custom ASR と比べると、Transcribe は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Transcribe, 音声認識, ASR, 文字起こし
AI Operations 🔘 完全ガイド T9 ★★★★★★☆☆☆☆(5.6) 機械学習機能を業務へ組み込むマネージドAIサービス
  • MLモデルのドリフト・品質劣化を自動検知するか
  • 本番推論監視とアラート自動化が必要か
  • SageMaker AIとのAIOpsパイプラインか
  • SageMaker では要件を満たしきれず、機械学習機能を業務へ組み込むマネージドAIサービス を重視して AI Operations を第一候補にする場合。
  • AI Operations を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom model と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SageMaker は汎用的な選択肢だが、AI Operations は「機械学習機能を業務へ組み込むマネージドAIサービス」に責務を集中させやすい。
  • custom model と比べると、AI Operations は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AI Operations, 機械学習, 推論, 運用設計
Polly 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.6) 高品質音声合成をAPIで提供する音声生成基盤
  • 多言語音声が必要か
  • 音声品質要件が高いか
  • 配信コストを制御できるか
  • Azure TTS では要件を満たしきれず、高品質音声合成をAPIで提供する音声生成基盤 を重視して Polly を第一候補にする場合。
  • Polly を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom TTS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Azure TTS
  • custom TTS
  • Azure TTS は汎用的な選択肢だが、Polly は「高品質音声合成をAPIで提供する音声生成基盤」に責務を集中させやすい。
  • custom TTS と比べると、Polly は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Polly, 音声合成, TTS, 音声API
Comprehend Medical 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) 自然言語解析をマネージド提供するテキスト分析基盤
  • 日本語精度要件を満たせるか
  • 分類/抽出要件が整理済みか
  • 運用監視を継続できるか
  • Bedrock custom model では要件を満たしきれず、自然言語解析をマネージド提供するテキスト分析基盤 を重視して Comprehend Medical を第一候補にする場合。
  • Comprehend Medical を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Open source NLP と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Bedrock custom model
  • Open source NLP
  • Bedrock custom model は汎用的な選択肢だが、Comprehend Medical は「自然言語解析をマネージド提供するテキスト分析基盤」に責務を集中させやすい。
  • Open source NLP と比べると、Comprehend Medical は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Comprehend, NLP, テキスト分類, エンティティ抽出
Lex 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) 対話ボットを構築し業務窓口を自動化する会話基盤
  • 対話シナリオを継続改善できるか
  • 既存チャネル連携が必要か
  • 応答失敗時の人手引継ぎがあるか
  • Dialogflow では要件を満たしきれず、対話ボットを構築し業務窓口を自動化する会話基盤 を重視して Lex を第一候補にする場合。
  • Lex を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Bedrock Agents と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Dialogflow は汎用的な選択肢だが、Lex は「対話ボットを構築し業務窓口を自動化する会話基盤」に責務を集中させやすい。
  • Bedrock Agents と比べると、Lex は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Lex, チャットボット, 対話設計, 業務自動化
Monitron 🩶 完全ガイド T8 ★★★★★★☆☆☆☆(5.5) 機械学習機能を業務へ組み込むマネージドAIサービス
  • IoTセンサーで工場設備の振動・温度異常を検知するか
  • 設置即日からMLモデル適用の予兆保全か
  • スマートフォンアプリで保全作業員が確認するか
  • SageMaker では要件を満たしきれず、機械学習機能を業務へ組み込むマネージドAIサービス を重視して Monitron を第一候補にする場合。
  • Monitron を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom model と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SageMaker は汎用的な選択肢だが、Monitron は「機械学習機能を業務へ組み込むマネージドAIサービス」に責務を集中させやすい。
  • custom model と比べると、Monitron は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Monitron, 機械学習, 推論, 運用設計
ML ★★★★★☆☆☆☆☆(5.4) 機械学習機能を業務へ組み込むマネージドAIサービス
  • 既存Amazon MLワークロードの継続稼働のみか
  • SageMaker AIへの移行計画が必要か
  • レガシーMLモデルのバッチ推論継続か
  • SageMaker では要件を満たしきれず、機械学習機能を業務へ組み込むマネージドAIサービス を重視して ML を第一候補にする場合。
  • ML を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom model と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SageMaker は汎用的な選択肢だが、ML は「機械学習機能を業務へ組み込むマネージドAIサービス」に責務を集中させやすい。
  • custom model と比べると、ML は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ML, 機械学習, 推論, 運用設計
A2I 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(5.3) 機械学習結果に人手レビューを組み込む品質保証基盤
  • 高リスク判定の人手確認が必要か
  • レビュー業務を運用できるか
  • 判定品質を継続測定するか
  • custom human loop では要件を満たしきれず、機械学習結果に人手レビューを組み込む品質保証基盤 を重視して A2I を第一候補にする場合。
  • A2I を採用し、SageMaker と組み合わせて責任境界を明確にしたい場合。
  • SageMaker Clarify と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom human loop は汎用的な選択肢だが、A2I は「機械学習結果に人手レビューを組み込む品質保証基盤」に責務を集中させやすい。
  • SageMaker Clarify と比べると、A2I は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SageMaker との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
A2I, Human-in-the-loop, レビュー, 品質保証
Forecast 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.2) 時系列予測を迅速導入する需要予測サービス
  • 予測対象が時系列中心か
  • 季節性要因を扱うか
  • 予測誤差を業務反映できるか
  • SageMaker では要件を満たしきれず、時系列予測を迅速導入する需要予測サービス を重視して Forecast を第一候補にする場合。
  • Forecast を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Prophet と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SageMaker は汎用的な選択肢だが、Forecast は「時系列予測を迅速導入する需要予測サービス」に責務を集中させやすい。
  • Prophet と比べると、Forecast は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Forecast, 需要予測, 時系列, 予測モデル
Translate 🔵 完全ガイド T4 ★★★★★☆☆☆☆☆(5.1) 多言語翻訳をAPIで自動化する翻訳基盤
  • 翻訳品質評価を運用できるか
  • 専門用語辞書を管理できるか
  • 大量翻訳のコストを抑えたいか
  • custom NMT では要件を満たしきれず、多言語翻訳をAPIで自動化する翻訳基盤 を重視して Translate を第一候補にする場合。
  • Translate を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Google Translate API と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom NMT は汎用的な選択肢だが、Translate は「多言語翻訳をAPIで自動化する翻訳基盤」に責務を集中させやすい。
  • Google Translate API と比べると、Translate は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Translate, 機械翻訳, 多言語, 翻訳API
Personalize 🔵 完全ガイド T4 ★★★★★☆☆☆☆☆(5.0) レコメンドモデルを運用最適化する推奨エンジン
  • 推薦施策を継続改善するか
  • 行動データを継続投入できるか
  • 評価指標を運用で追えるか
  • custom recommender では要件を満たしきれず、レコメンドモデルを運用最適化する推奨エンジン を重視して Personalize を第一候補にする場合。
  • Personalize を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • SageMaker と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom recommender は汎用的な選択肢だが、Personalize は「レコメンドモデルを運用最適化する推奨エンジン」に責務を集中させやすい。
  • SageMaker と比べると、Personalize は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Personalize, 推薦, レコメンド, 行動データ
Textract 🔵 完全ガイド T4 ★★★★★☆☆☆☆☆(5.0) 文書OCRと構造抽出を自動化するドキュメント解析基盤
  • 帳票種類のばらつきが大きいか
  • 抽出精度検証を回せるか
  • 後続ワークフロー連携が必要か
  • Document AI では要件を満たしきれず、文書OCRと構造抽出を自動化するドキュメント解析基盤 を重視して Textract を第一候補にする場合。
  • Textract を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom OCR と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Document AI
  • custom OCR
  • Document AI は汎用的な選択肢だが、Textract は「文書OCRと構造抽出を自動化するドキュメント解析基盤」に責務を集中させやすい。
  • custom OCR と比べると、Textract は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Textract, OCR, 帳票解析, 文書抽出
Lookout for Equipment 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(5.0) 設備データから故障予兆を検知する保全最適化基盤
  • 設備センサーデータを収集できるか
  • 予兆検知の先行時間を評価できるか
  • 保全計画へ組み込めるか
  • IoT Analytics では要件を満たしきれず、設備データから故障予兆を検知する保全最適化基盤 を重視して Lookout for Equipment を第一候補にする場合。
  • Lookout for Equipment を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • custom predictive maintenance と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IoT Analytics
  • custom predictive maintenance
  • IoT Analytics は汎用的な選択肢だが、Lookout for Equipment は「設備データから故障予兆を検知する保全最適化基盤」に責務を集中させやすい。
  • custom predictive maintenance と比べると、Lookout for Equipment は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Lookout for Equipment, 予兆保全, 設備監視, 異常検知
Comprehend 🔵 完全ガイド T4 ★★★★★☆☆☆☆☆(4.9) 自然言語解析をマネージド提供するテキスト分析基盤
  • 日本語精度要件を満たせるか
  • 分類/抽出要件が整理済みか
  • 運用監視を継続できるか
  • Bedrock custom model では要件を満たしきれず、自然言語解析をマネージド提供するテキスト分析基盤 を重視して Comprehend を第一候補にする場合。
  • Comprehend を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Open source NLP と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Bedrock custom model
  • Open source NLP
  • Bedrock custom model は汎用的な選択肢だが、Comprehend は「自然言語解析をマネージド提供するテキスト分析基盤」に責務を集中させやすい。
  • Open source NLP と比べると、Comprehend は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Comprehend, NLP, テキスト分類, エンティティ抽出
Kendra完全ガイド T7 ★★★★★☆☆☆☆☆(4.9) 企業内データ横断検索を高精度化する検索基盤
  • 検索対象システムが多いか
  • アクセス制御連携が必要か
  • 検索品質改善を継続できるか
  • OpenSearch Service では要件を満たしきれず、企業内データ横断検索を高精度化する検索基盤 を重視して Kendra を第一候補にする場合。
  • Kendra を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Bedrock Knowledge Base と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • OpenSearch Service は汎用的な選択肢だが、Kendra は「企業内データ横断検索を高精度化する検索基盤」に責務を集中させやすい。
  • Bedrock Knowledge Base と比べると、Kendra は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Kendra, エンタープライズ検索, 検索品質, コネクタ
Rekognition 🔵 完全ガイド T4 ★★★★★☆☆☆☆☆(4.9) 画像・動画解析をAPIで迅速導入する認識サービス
  • 画像認識要件が明確か
  • 誤検知対策を設計できるか
  • データ取り扱い規制を満たせるか
  • custom vision model では要件を満たしきれず、画像・動画解析をAPIで迅速導入する認識サービス を重視して Rekognition を第一候補にする場合。
  • Rekognition を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Vision API と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom vision model
  • Vision API
  • custom vision model は汎用的な選択肢だが、Rekognition は「画像・動画解析をAPIで迅速導入する認識サービス」に責務を集中させやすい。
  • Vision API と比べると、Rekognition は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Rekognition, 画像認識, 動画解析, API利用
Lookout for Metrics 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.8) 時系列メトリクス異常を自動検知する監視分析基盤
  • KPI異常検知を自動化したいか
  • アラート運用を継続できるか
  • 誤検知率を評価できるか
  • CloudWatch Anomaly Detection では要件を満たしきれず、時系列メトリクス異常を自動検知する監視分析基盤 を重視して Lookout for Metrics を第一候補にする場合。
  • Lookout for Metrics を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom detector と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudWatch Anomaly Detection は汎用的な選択肢だが、Lookout for Metrics は「時系列メトリクス異常を自動検知する監視分析基盤」に責務を集中させやすい。
  • custom detector と比べると、Lookout for Metrics は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Lookout for Metrics, 異常検知, 時系列, KPI監視
Lookout for Vision 🩶 完全ガイド T8 ★★★★☆☆☆☆☆☆(4.4) 製造画像の異常検査を自動化する外観検査基盤
  • 検査画像の品質が安定しているか
  • 誤検知時の再判定フローがあるか
  • ライン速度要件に合うか
  • Rekognition Custom Labels では要件を満たしきれず、製造画像の異常検査を自動化する外観検査基盤 を重視して Lookout for Vision を第一候補にする場合。
  • Lookout for Vision を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom vision と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Rekognition Custom Labels は汎用的な選択肢だが、Lookout for Vision は「製造画像の異常検査を自動化する外観検査基盤」に責務を集中させやすい。
  • custom vision と比べると、Lookout for Vision は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Lookout for Vision, 外観検査, 異常検知, 製造AI

Generative AI (5)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
Bedrock 🟢 完全ガイド T1 ★★★★★★★☆☆☆(7.2) 基盤モデル選択とガードレールを統合する生成AI実行基盤
  • 複数モデル比較が必要か
  • 安全制御を標準化したいか
  • 推論コストを継続管理できるか
  • SageMaker AI では要件を満たしきれず、基盤モデル選択とガードレールを統合する生成AI実行基盤 を重視して Bedrock を第一候補にする場合。
  • Bedrock を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • OpenAI API と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SageMaker AI は汎用的な選択肢だが、Bedrock は「基盤モデル選択とガードレールを統合する生成AI実行基盤」に責務を集中させやすい。
  • OpenAI API と比べると、Bedrock は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Bedrock, 基盤モデル, ガードレール, 推論管理
Q Business 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.1) 生成AIアプリ開発を加速するマネージドサービス
  • 社内ドキュメントへのRAGベースQ&Aが必要か
  • IAM Identity Center連携でアクセス制御付きチャットか
  • Kendraなしで企業データ統合検索+生成AIか
  • Bedrock では要件を満たしきれず、生成AIアプリ開発を加速するマネージドサービス を重視して Q Business を第一候補にする場合。
  • Q Business を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom LLM と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Bedrock は汎用的な選択肢だが、Q Business は「生成AIアプリ開発を加速するマネージドサービス」に責務を集中させやすい。
  • custom LLM と比べると、Q Business は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Q Business, 生成AI, LLM, 運用設計
Q Developer 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.8) 生成AIアプリ開発を加速するマネージドサービス
  • IDE統合のAIコード補完・生成が必要か
  • セキュリティ脆弱性のコードスキャンとAI修正提案か
  • AWS CLIとコンソールのAI操作ガイダンスか
  • Bedrock では要件を満たしきれず、生成AIアプリ開発を加速するマネージドサービス を重視して Q Developer を第一候補にする場合。
  • Q Developer を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom LLM と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Bedrock は汎用的な選択肢だが、Q Developer は「生成AIアプリ開発を加速するマネージドサービス」に責務を集中させやすい。
  • custom LLM と比べると、Q Developer は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Q Developer, 生成AI, LLM, 運用設計
Bedrock AgentCore 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.7) 基盤モデル選択とガードレールを統合する生成AI実行基盤
  • LLMエージェントに外部ツール・APIを統合するか
  • マルチステップ自律エージェントのオーケストレーションか
  • エージェントの実行履歴・デバッグが必要か
  • SageMaker AI では要件を満たしきれず、基盤モデル選択とガードレールを統合する生成AI実行基盤 を重視して Bedrock AgentCore を第一候補にする場合。
  • Bedrock AgentCore を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • OpenAI API と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SageMaker AI は汎用的な選択肢だが、Bedrock AgentCore は「基盤モデル選択とガードレールを統合する生成AI実行基盤」に責務を集中させやすい。
  • OpenAI API と比べると、Bedrock AgentCore は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Bedrock, 基盤モデル, ガードレール, 推論管理
QuickSight 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.4) 生成AIアプリ開発を加速するマネージドサービス
  • サーバーレスBIダッシュボードをSaaS組み込みで公開するか
  • SPICEエンジンで大量データのインタラクティブ分析か
  • Q(自然言語クエリ)でデータ質問するか
  • Bedrock では要件を満たしきれず、生成AIアプリ開発を加速するマネージドサービス を重視して QuickSight を第一候補にする場合。
  • QuickSight を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom LLM と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Bedrock は汎用的な選択肢だが、QuickSight は「生成AIアプリ開発を加速するマネージドサービス」に責務を集中させやすい。
  • custom LLM と比べると、QuickSight は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
QuickSight, 生成AI, LLM, 運用設計

Application Integration (11)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
API Gateway 🟢 完全ガイド T1 ★★★★★★★★★☆(8.8) アプリ間連携を標準化する統合サービス
  • REST/HTTP/WebSocket APIの管理とスロットリングが必要か
  • Lambda/バックエンドHTTPのフロントエンドAPIか
  • 認証・認可・APIキー管理を一元化するか
  • EventBridge では要件を満たしきれず、アプリ間連携を標準化する統合サービス を重視して API Gateway を第一候補にする場合。
  • API Gateway を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • SQS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EventBridge は汎用的な選択肢だが、API Gateway は「アプリ間連携を標準化する統合サービス」に責務を集中させやすい。
  • SQS と比べると、API Gateway は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
API Gateway, 連携, 統合, イベント
SQS 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.4) 非同期メッセージキューで疎結合を実現する連携基盤
  • 順序保証の要件があるか
  • 再試行/デッドレター設計があるか
  • 処理遅延許容を定義できるか
  • SNS では要件を満たしきれず、非同期メッセージキューで疎結合を実現する連携基盤 を重視して SQS を第一候補にする場合。
  • SQS を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Kafka と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SNS は汎用的な選択肢だが、SQS は「非同期メッセージキューで疎結合を実現する連携基盤」に責務を集中させやすい。
  • Kafka と比べると、SQS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SQS, キュー, 非同期処理, 再試行
EventBridge 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.2) イベント駆動連携を統合するルーティング基盤
  • イベント契約を管理できるか
  • クロスアカウント連携が必要か
  • ルール爆発を抑制できるか
  • SNS では要件を満たしきれず、イベント駆動連携を統合するルーティング基盤 を重視して EventBridge を第一候補にする場合。
  • EventBridge を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Step Functions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SNS は汎用的な選択肢だが、EventBridge は「イベント駆動連携を統合するルーティング基盤」に責務を集中させやすい。
  • Step Functions と比べると、EventBridge は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EventBridge, イベント駆動, ルーティング, 統合
SNS 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.1) Pub/Subで多系統通知を同時配信するイベント配信基盤
  • 複数購読先へ同報配信するか
  • 配信失敗時の再送設計があるか
  • 通知優先度を運用管理できるか
  • EventBridge では要件を満たしきれず、Pub/Subで多系統通知を同時配信するイベント配信基盤 を重視して SNS を第一候補にする場合。
  • SNS を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • SQS と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • EventBridge は汎用的な選択肢だが、SNS は「Pub/Subで多系統通知を同時配信するイベント配信基盤」に責務を集中させやすい。
  • SQS と比べると、SNS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SNS, 通知, PubSub, ファンアウト
  • KafkaPubSub(通知配信)
Step Functions 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.0) ワークフローを宣言的に定義するオーケストレーション基盤
  • 長時間処理の可視化が必要か
  • 補償トランザクションが必要か
  • 業務フロー変更頻度が高いか
  • Temporal では要件を満たしきれず、ワークフローを宣言的に定義するオーケストレーション基盤 を重視して Step Functions を第一候補にする場合。
  • Step Functions を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • MWAA と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Temporal は汎用的な選択肢だが、Step Functions は「ワークフローを宣言的に定義するオーケストレーション基盤」に責務を集中させやすい。
  • MWAA と比べると、Step Functions は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Step Functions, ワークフロー, 状態管理, 補償処理
AWS AppSync 🟣 完全ガイド T5 ★★★★★★★☆☆☆(6.7) GraphQL APIで複数データ源を統合するAPI連携基盤
  • クライアント最適取得が必要か
  • リアルタイム配信を使うか
  • 認可設計を一元化できるか
  • API Gateway では要件を満たしきれず、GraphQL APIで複数データ源を統合するAPI連携基盤 を重視して AWS AppSync を第一候補にする場合。
  • AWS AppSync を採用し、Cognito と組み合わせて責任境界を明確にしたい場合。
  • Hasura と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • API Gateway は汎用的な選択肢だが、AWS AppSync は「GraphQL APIで複数データ源を統合するAPI連携基盤」に責務を集中させやすい。
  • Hasura と比べると、AWS AppSync は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Cognito との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AppSync, GraphQL, リアルタイム, 統合API
AppFlow 🟠 完全ガイド T3 ★★★★★★★☆☆☆(6.6) SaaS間データ連携をノーコードで自動化する統合基盤
  • SaaS連携を短期間で構築したいか
  • 変換処理を最小実装で済ませるか
  • 同期頻度を業務要件に合わせるか
  • Glue では要件を満たしきれず、SaaS間データ連携をノーコードで自動化する統合基盤 を重視して AppFlow を第一候補にする場合。
  • AppFlow を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • custom ETL と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Glue は汎用的な選択肢だが、AppFlow は「SaaS間データ連携をノーコードで自動化する統合基盤」に責務を集中させやすい。
  • custom ETL と比べると、AppFlow は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AppFlow, SaaS連携, ノーコード, データ同期
MQ 🟠 完全ガイド T3 ★★★★★★★☆☆☆(6.6) 既存メッセージブローカー運用を移行しやすい互換基盤
  • RabbitMQ/ActiveMQ互換が必要か
  • 既存接続方式を維持するか
  • 運用移行リスクを最小化したいか
  • SQS では要件を満たしきれず、既存メッセージブローカー運用を移行しやすい互換基盤 を重視して MQ を第一候補にする場合。
  • MQ を採用し、ECS と組み合わせて責任境界を明確にしたい場合。
  • MSK と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SQS は汎用的な選択肢だが、MQ は「既存メッセージブローカー運用を移行しやすい互換基盤」に責務を集中させやすい。
  • MSK と比べると、MQ は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • ECS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MQ, RabbitMQ, ActiveMQ, 互換移行
EventBridge Scheduler 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.4) イベント駆動連携を統合するルーティング基盤
  • cron/rate式で定期タスクのスケジュール実行か
  • タイムゾーン対応の柔軟な時刻指定が必要か
  • CloudWatch Eventsより細粒度のスケジューラか
  • SNS では要件を満たしきれず、イベント駆動連携を統合するルーティング基盤 を重視して EventBridge Scheduler を第一候補にする場合。
  • EventBridge Scheduler を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Step Functions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SNS は汎用的な選択肢だが、EventBridge Scheduler は「イベント駆動連携を統合するルーティング基盤」に責務を集中させやすい。
  • Step Functions と比べると、EventBridge Scheduler は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EventBridge, イベント駆動, ルーティング, 統合
EventBridge Pipes 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.8) イベント駆動連携を統合するルーティング基盤
  • SQS/DynamoDB StreamからターゲットへのP2Pパイプか
  • ソースフィルタリングと変換を一箇所に集約するか
  • Lambdaなしの軽量イベントルーティングか
  • SNS では要件を満たしきれず、イベント駆動連携を統合するルーティング基盤 を重視して EventBridge Pipes を第一候補にする場合。
  • EventBridge Pipes を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Step Functions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SNS は汎用的な選択肢だが、EventBridge Pipes は「イベント駆動連携を統合するルーティング基盤」に責務を集中させやすい。
  • Step Functions と比べると、EventBridge Pipes は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EventBridge, イベント駆動, ルーティング, 統合
EventBridge Schemas完全ガイド T7 ★★★★★★☆☆☆☆(5.7) イベント駆動連携を統合するルーティング基盤
  • イベントスキーマをレジストリで一元管理するか
  • スキーマから型付きコードを自動生成するか
  • イベント契約をドキュメント化・共有するか
  • SNS では要件を満たしきれず、イベント駆動連携を統合するルーティング基盤 を重視して EventBridge Schemas を第一候補にする場合。
  • EventBridge Schemas を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Step Functions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SNS は汎用的な選択肢だが、EventBridge Schemas は「イベント駆動連携を統合するルーティング基盤」に責務を集中させやすい。
  • Step Functions と比べると、EventBridge Schemas は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EventBridge, イベント駆動, ルーティング, 統合

Developer Tools (15)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
CodePipeline 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.4) リリース工程を自動化するCI/CDオーケストレーション基盤
  • 承認ゲートが必要か
  • 複数環境へ段階配備するか
  • 失敗時ロールバックを自動化するか
  • GitHub Actions では要件を満たしきれず、リリース工程を自動化するCI/CDオーケストレーション基盤 を重視して CodePipeline を第一候補にする場合。
  • CodePipeline を採用し、CodeBuild と組み合わせて責任境界を明確にしたい場合。
  • Jenkins と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • GitHub Actions
  • Jenkins
  • GitHub Actions は汎用的な選択肢だが、CodePipeline は「リリース工程を自動化するCI/CDオーケストレーション基盤」に責務を集中させやすい。
  • Jenkins と比べると、CodePipeline は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodeBuild との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodePipeline, CI/CD, パイプライン, 自動化
CodeBuild 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.3) ビルドとテストをマネージド実行するCI基盤
  • ビルド並列化が必要か
  • カスタムビルド環境が必要か
  • 実行コストを管理できるか
  • GitHub Actions では要件を満たしきれず、ビルドとテストをマネージド実行するCI基盤 を重視して CodeBuild を第一候補にする場合。
  • CodeBuild を採用し、CodePipeline と組み合わせて責任境界を明確にしたい場合。
  • CircleCI と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • GitHub Actions
  • CircleCI
  • GitHub Actions は汎用的な選択肢だが、CodeBuild は「ビルドとテストをマネージド実行するCI基盤」に責務を集中させやすい。
  • CircleCI と比べると、CodeBuild は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodePipeline との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeBuild, ビルド, テスト自動化, CI
X-Ray 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.2) 分散トレースで原因特定を短縮する解析基盤
  • マイクロサービス遅延を可視化するか
  • サービス間依存を追跡するか
  • 運用監視と統合するか
  • CloudWatch では要件を満たしきれず、分散トレースで原因特定を短縮する解析基盤 を重視して X-Ray を第一候補にする場合。
  • X-Ray を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • OpenTelemetry と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudWatch は汎用的な選択肢だが、X-Ray は「分散トレースで原因特定を短縮する解析基盤」に責務を集中させやすい。
  • OpenTelemetry と比べると、X-Ray は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
X-Ray, トレース, 遅延解析, 依存可視化
CodeDeploy 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.0) 段階デプロイで本番影響を抑えるリリース実行基盤
  • Blue/Greenを採用するか
  • 自動ロールバックが必要か
  • アプリ停止時間を抑えたいか
  • Argo Rollouts では要件を満たしきれず、段階デプロイで本番影響を抑えるリリース実行基盤 を重視して CodeDeploy を第一候補にする場合。
  • CodeDeploy を採用し、CodePipeline と組み合わせて責任境界を明確にしたい場合。
  • Spinnaker と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Argo Rollouts
  • Spinnaker
  • Argo Rollouts は汎用的な選択肢だが、CodeDeploy は「段階デプロイで本番影響を抑えるリリース実行基盤」に責務を集中させやすい。
  • Spinnaker と比べると、CodeDeploy は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodePipeline との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeDeploy, BlueGreen, ロールバック, 配備
Application Testing 🩶 完全ガイド T8 ★★★★★★☆☆☆☆(6.0) 開発ライフサイクルを標準化する開発支援サービス
  • モバイル/WebアプリのE2Eテストを実機デバイスで実行するか
  • テスト環境プロビジョニングを自動化するか
  • CI/CDパイプラインへのテスト組み込みか
  • CodePipeline では要件を満たしきれず、開発ライフサイクルを標準化する開発支援サービス を重視して Application Testing を第一候補にする場合。
  • Application Testing を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • GitHub Actions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CodePipeline は汎用的な選択肢だが、Application Testing は「開発ライフサイクルを標準化する開発支援サービス」に責務を集中させやすい。
  • GitHub Actions と比べると、Application Testing は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Application Testing, 開発支援, 自動化, 運用
CodeCatalyst 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.9) 開発ライフサイクルを標準化する開発支援サービス
  • プロジェクト・リポジトリ・CI/CDをAWS上で一元管理するか
  • GitHubなしのAWS完結型DevOps環境か
  • IssueトラッキングとCIパイプラインの統合管理か
  • CodePipeline では要件を満たしきれず、開発ライフサイクルを標準化する開発支援サービス を重視して CodeCatalyst を第一候補にする場合。
  • CodeCatalyst を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • GitHub Actions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CodePipeline は汎用的な選択肢だが、CodeCatalyst は「開発ライフサイクルを標準化する開発支援サービス」に責務を集中させやすい。
  • GitHub Actions と比べると、CodeCatalyst は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeCatalyst, 開発支援, 自動化, 運用
CodeCommit 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.7) ソース管理をAWS内へ統合するGitリポジトリ基盤
  • 社内閉域で運用したいか
  • 既存Git運用を維持するか
  • 監査ログ要件が厳しいか
  • GitHub では要件を満たしきれず、ソース管理をAWS内へ統合するGitリポジトリ基盤 を重視して CodeCommit を第一候補にする場合。
  • CodeCommit を採用し、CodeBuild と組み合わせて責任境界を明確にしたい場合。
  • GitLab と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • GitHub
  • GitLab
  • GitHub は汎用的な選択肢だが、CodeCommit は「ソース管理をAWS内へ統合するGitリポジトリ基盤」に責務を集中させやすい。
  • GitLab と比べると、CodeCommit は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodeBuild との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeCommit, Git, リポジトリ, 監査
Elastic Transcoder 🩶 完全ガイド T8 ★★★★★★☆☆☆☆(5.7) 開発ライフサイクルを標準化する開発支援サービス
  • 既存Elastic Transcoderのメディア変換を継続稼働するか
  • MediaConvertへの移行計画が必要か
  • S3格納動画ファイルのフォーマット変換(レガシー)か
  • CodePipeline では要件を満たしきれず、開発ライフサイクルを標準化する開発支援サービス を重視して Elastic Transcoder を第一候補にする場合。
  • Elastic Transcoder を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • GitHub Actions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CodePipeline は汎用的な選択肢だが、Elastic Transcoder は「開発ライフサイクルを標準化する開発支援サービス」に責務を集中させやすい。
  • GitHub Actions と比べると、Elastic Transcoder は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Elastic Transcoder, 開発支援, 自動化, 運用
CodeConnections 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.6) 開発ライフサイクルを標準化する開発支援サービス
  • GitHub/Bitbucket/GitLabリポジトリをCodePipelineに接続するか
  • 外部SCMとAWS CI/CDツールのOAuth連携か
  • CodeCatalystなしの外部リポジトリ統合か
  • CodePipeline では要件を満たしきれず、開発ライフサイクルを標準化する開発支援サービス を重視して CodeConnections を第一候補にする場合。
  • CodeConnections を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • GitHub Actions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CodePipeline は汎用的な選択肢だが、CodeConnections は「開発ライフサイクルを標準化する開発支援サービス」に責務を集中させやすい。
  • GitHub Actions と比べると、CodeConnections は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeConnections, 開発支援, 自動化, 運用
CodeGuru Reviewer 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) 開発ライフサイクルを標準化する開発支援サービス
  • PRのコードをMLで自動レビューするか
  • セキュリティ脆弱性と品質問題の自動検出か
  • Java/Pythonコードの改善提案を自動化するか
  • CodePipeline では要件を満たしきれず、開発ライフサイクルを標準化する開発支援サービス を重視して CodeGuru Reviewer を第一候補にする場合。
  • CodeGuru Reviewer を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • GitHub Actions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CodePipeline は汎用的な選択肢だが、CodeGuru Reviewer は「開発ライフサイクルを標準化する開発支援サービス」に責務を集中させやすい。
  • GitHub Actions と比べると、CodeGuru Reviewer は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeGuru Reviewer, 開発支援, 自動化, 運用
CodeGuru Security 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.4) 開発ライフサイクルを標準化する開発支援サービス
  • コードベースのセキュリティ脆弱性スキャンか
  • OWASP top 10のコードレベル検出が必要か
  • 開発段階でのシフトレフトセキュリティ検査か
  • CodePipeline では要件を満たしきれず、開発ライフサイクルを標準化する開発支援サービス を重視して CodeGuru Security を第一候補にする場合。
  • CodeGuru Security を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • GitHub Actions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CodePipeline は汎用的な選択肢だが、CodeGuru Security は「開発ライフサイクルを標準化する開発支援サービス」に責務を集中させやすい。
  • GitHub Actions と比べると、CodeGuru Security は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeGuru Security, 開発支援, 自動化, 運用
AWS CodeStar Notifications 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.3) 開発プロジェクトの初期構成を迅速化する統合テンプレート基盤
  • CodePipeline/CodeBuildのイベントをSlack/SNSへ通知するか
  • 開発パイプラインの状態変化を即時通知するか
  • チャットツールとCI/CDイベントを接続するか
  • Backstage では要件を満たしきれず、開発プロジェクトの初期構成を迅速化する統合テンプレート基盤 を重視して AWS CodeStar Notifications を第一候補にする場合。
  • AWS CodeStar Notifications を採用し、CodePipeline と組み合わせて責任境界を明確にしたい場合。
  • internal template と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Backstage
  • internal template
  • Backstage は汎用的な選択肢だが、AWS CodeStar Notifications は「開発プロジェクトの初期構成を迅速化する統合テンプレート基盤」に責務を集中させやすい。
  • internal template と比べると、AWS CodeStar Notifications は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodePipeline との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeStar, テンプレート, 初期構築, 統合
CodeGuru Profiler完全ガイド T7 ★★★★★☆☆☆☆☆(5.0) 開発ライフサイクルを標準化する開発支援サービス
  • 本番アプリのCPU/メモリホットスポットをプロファイリングするか
  • パフォーマンスコスト発見とML最適化提案が必要か
  • 本番稼働中Lambda/EC2コードのプロファイルか
  • CodePipeline では要件を満たしきれず、開発ライフサイクルを標準化する開発支援サービス を重視して CodeGuru Profiler を第一候補にする場合。
  • CodeGuru Profiler を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • GitHub Actions と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CodePipeline は汎用的な選択肢だが、CodeGuru Profiler は「開発ライフサイクルを標準化する開発支援サービス」に責務を集中させやすい。
  • GitHub Actions と比べると、CodeGuru Profiler は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeGuru Profiler, 開発支援, 自動化, 運用
AWS Cloud9完全ガイド T7 ★★★★★☆☆☆☆☆(4.9) クラウドIDEで開発環境共有を簡素化する基盤
  • 開発環境統一が必要か
  • 教育用途で迅速起動したいか
  • 権限制御を運用できるか
  • GitHub Codespaces では要件を満たしきれず、クラウドIDEで開発環境共有を簡素化する基盤 を重視して AWS Cloud9 を第一候補にする場合。
  • AWS Cloud9 を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • JetBrains Gateway と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • GitHub Codespaces
  • JetBrains Gateway
  • GitHub Codespaces は汎用的な選択肢だが、AWS Cloud9 は「クラウドIDEで開発環境共有を簡素化する基盤」に責務を集中させやすい。
  • JetBrains Gateway と比べると、AWS Cloud9 は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Cloud9, クラウドIDE, 開発環境, 共有
AWS CodeStar Connections ★★★★★☆☆☆☆☆(4.9) 開発プロジェクトの初期構成を迅速化する統合テンプレート基盤
  • GitHub/Bitbucket等の外部SCMをAWSサービスへOAuth接続するか
  • CodeConnectionsの旧名称で既存設定継続か
  • 外部リポジトリのWebhookをCodePipelineにブリッジするか
  • Backstage では要件を満たしきれず、開発プロジェクトの初期構成を迅速化する統合テンプレート基盤 を重視して AWS CodeStar Connections を第一候補にする場合。
  • AWS CodeStar Connections を採用し、CodePipeline と組み合わせて責任境界を明確にしたい場合。
  • internal template と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Backstage
  • internal template
  • Backstage は汎用的な選択肢だが、AWS CodeStar Connections は「開発プロジェクトの初期構成を迅速化する統合テンプレート基盤」に責務を集中させやすい。
  • internal template と比べると、AWS CodeStar Connections は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodePipeline との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CodeStar, テンプレート, 初期構築, 統合

Management & Governance (43)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
CloudWatch 🟢 完全ガイド T1 ★★★★★★★★★☆(9.1) 監視指標とログを統合運用する可観測性基盤
  • SLO連動監視を実施するか
  • 通知ノイズを制御できるか
  • 運用ダッシュボードを標準化するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch を第一候補にする場合。
  • CloudWatch を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
CloudTrail 🟢 完全ガイド T1 ★★★★★★★★★☆(8.8) API操作履歴を監査証跡として保全する基盤
  • 監査要件が厳格か
  • 全アカウント横断で収集するか
  • 長期保管方針を設計するか
  • Config では要件を満たしきれず、API操作履歴を監査証跡として保全する基盤 を重視して CloudTrail を第一候補にする場合。
  • CloudTrail を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • SIEM audit log と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Config は汎用的な選択肢だが、CloudTrail は「API操作履歴を監査証跡として保全する基盤」に責務を集中させやすい。
  • SIEM audit log と比べると、CloudTrail は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudTrail, 監査証跡, APIログ, 証跡保全
CloudFormation 🟢 完全ガイド T1 ★★★★★★★★☆☆(8.3) IaCで構成変更を再現可能に管理する基盤
  • 変更をコードレビューで統制するか
  • ドリフト検知を継続運用するか
  • 複数環境へ同一展開するか
  • Terraform では要件を満たしきれず、IaCで構成変更を再現可能に管理する基盤 を重視して CloudFormation を第一候補にする場合。
  • CloudFormation を採用し、Config と組み合わせて責任境界を明確にしたい場合。
  • CDK と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Terraform
  • CDK
  • Terraform は汎用的な選択肢だが、CloudFormation は「IaCで構成変更を再現可能に管理する基盤」に責務を集中させやすい。
  • CDK と比べると、CloudFormation は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Config との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudFormation, IaC, ドリフト管理, 再現性
Systems Manager 🟡 完全ガイド T2 ★★★★★★★★☆☆(8.0) 運用タスクを自動化してインスタンス管理を統合する基盤
  • 運用手順をRunbook化するか
  • パッチ適用を標準化するか
  • 踏み台レス運用へ移行するか
  • Ansible では要件を満たしきれず、運用タスクを自動化してインスタンス管理を統合する基盤 を重視して Systems Manager を第一候補にする場合。
  • Systems Manager を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • Puppet と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Ansible
  • Puppet
  • Ansible は汎用的な選択肢だが、Systems Manager は「運用タスクを自動化してインスタンス管理を統合する基盤」に責務を集中させやすい。
  • Puppet と比べると、Systems Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Systems Manager, Runbook, パッチ管理, 運用自動化
AWS Config 🟡 完全ガイド T2 ★★★★★★★★☆☆(7.6) 構成準拠状態を継続評価するコンプライアンス基盤
  • 準拠ルールをコード化するか
  • 逸脱検知後の是正を自動化するか
  • 組織横断で統制するか
  • CloudTrail では要件を満たしきれず、構成準拠状態を継続評価するコンプライアンス基盤 を重視して AWS Config を第一候補にする場合。
  • AWS Config を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • custom compliance scanner と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudTrail は汎用的な選択肢だが、AWS Config は「構成準拠状態を継続評価するコンプライアンス基盤」に責務を集中させやすい。
  • custom compliance scanner と比べると、AWS Config は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Config, 準拠評価, 設定監査, 継続統制
CloudWatch Application Signals 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.2) 監視指標とログを統合運用する可観測性基盤
  • アプリのSLO/SLAを可用性・レイテンシーメトリクスで追跡するか
  • X-Rayトレースとメトリクスを統合観測するか
  • サービス健全性をSLA目標と連動で監視するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Application Signals を第一候補にする場合。
  • CloudWatch Application Signals を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Application Signals は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Application Signals は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
CloudWatch Internet Monitor 🟣 完全ガイド T5 ★★★★★★★☆☆☆(7.2) 監視指標とログを統合運用する可観測性基盤
  • ユーザーのインターネット経路遅延・可用性を可視化するか
  • ISP/AS障害のユーザー影響をリアルタイム把握するか
  • クラウドとインターネット両方のレイテンシーを分析するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Internet Monitor を第一候補にする場合。
  • CloudWatch Internet Monitor を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Internet Monitor は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Internet Monitor は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
CloudWatch Observability Admin 🔘 完全ガイド T9 ★★★★★★★☆☆☆(7.2) 監視指標とログを統合運用する可観測性基盤
  • Container/Lambda Insightsの組織横断有効化を管理するか
  • 組織レベルでObservability設定を標準化・強制するか
  • CloudWatch機能の有効化状態を集中管理するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Observability Admin を第一候補にする場合。
  • CloudWatch Observability Admin を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Observability Admin は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Observability Admin は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
Organizations 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.2) 複数アカウントを統制ポリシーで一元管理する基盤
  • ガードレールを全体適用するか
  • OU設計を長期運用できるか
  • アカウントライフサイクルを標準化するか
  • Control Tower では要件を満たしきれず、複数アカウントを統制ポリシーで一元管理する基盤 を重視して Organizations を第一候補にする場合。
  • Organizations を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom account vending と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Control Tower は汎用的な選択肢だが、Organizations は「複数アカウントを統制ポリシーで一元管理する基盤」に責務を集中させやすい。
  • custom account vending と比べると、Organizations は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Organizations, OU, SCP, マルチアカウント
CloudWatch Events ★★★★★★★☆☆☆(7.1) 監視指標とログを統合運用する可観測性基盤
  • AWSリソース状態変化でLambda等を自動トリガーするか
  • EventBridgeへの移行前の既存ルール継続稼働か
  • スケジュールcronイベントをシンプルに設定するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Events を第一候補にする場合。
  • CloudWatch Events を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Events は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Events は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
CloudWatch RUM 🟣 完全ガイド T5 ★★★★★★★☆☆☆(7.1) 監視指標とログを統合運用する可観測性基盤
  • Webアプリのユーザー側Core Web Vitals(LCP等)を計測するか
  • フロントエンドのエラーとレイテンシーをリアルユーザーで収集するか
  • X-RayトレースとRUMデータを統合分析するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch RUM を第一候補にする場合。
  • CloudWatch RUM を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch RUM は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch RUM は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
CloudWatch Synthetics 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.1) 監視指標とログを統合運用する可観測性基盤
  • APIエンドポイントを定期カナリアで死活監視するか
  • Headlessブラウザでユーザーフローを自動検証するか
  • 本番稼働前の障害をカナリアで早期検知するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Synthetics を第一候補にする場合。
  • CloudWatch Synthetics を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Synthetics は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Synthetics は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
CloudWatch Application Insights 🟣 完全ガイド T5 ★★★★★★★☆☆☆(7.0) 監視指標とログを統合運用する可観測性基盤
  • .NET/SQLServer等のアプリ問題をML自動検出するか
  • アプリのログ・メトリクスを相関分析するか
  • マネージドサービス(RDS/ECS)の問題を自動診断するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Application Insights を第一候補にする場合。
  • CloudWatch Application Insights を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Application Insights は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Application Insights は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
AWS Systems Manager for SAP 🔘 完全ガイド T9 ★★★★★★★☆☆☆(6.8) 運用タスクを自動化してインスタンス管理を統合する基盤
  • EC2上のSAP HANA/NetWeaverをSystems Managerで一元管理するか
  • SAPのパッチ・バックアップ・起動停止を自動化するか
  • SAP on AWSのRunbookと運用手順を標準化するか
  • Ansible では要件を満たしきれず、運用タスクを自動化してインスタンス管理を統合する基盤 を重視して AWS Systems Manager for SAP を第一候補にする場合。
  • AWS Systems Manager for SAP を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • Puppet と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Ansible
  • Puppet
  • Ansible は汎用的な選択肢だが、AWS Systems Manager for SAP は「運用タスクを自動化してインスタンス管理を統合する基盤」に責務を集中させやすい。
  • Puppet と比べると、AWS Systems Manager for SAP は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Systems Manager, Runbook, パッチ管理, 運用自動化
CloudWatch Logs 🟡 完全ガイド T2 ★★★★★★★☆☆☆(6.8) 監視指標とログを統合運用する可観測性基盤
  • Lambda/EC2/ECSのログをリアルタイム収集・検索するか
  • ログパターンマッチでアラートをトリガーするか
  • Logs Insightsでアドホックログ分析するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Logs を第一候補にする場合。
  • CloudWatch Logs を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Logs は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Logs は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
AWS AppConfig 🟣 完全ガイド T5 ★★★★★★★☆☆☆(6.7) 構成準拠状態を継続評価するコンプライアンス基盤
  • 本番再デプロイなしにフィーチャーフラグを動的切替するか
  • 設定変更のロールアウトと自動ロールバックが必要か
  • システム設定の安全な段階適用が必要か
  • CloudTrail では要件を満たしきれず、構成準拠状態を継続評価するコンプライアンス基盤 を重視して AWS AppConfig を第一候補にする場合。
  • AWS AppConfig を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • custom compliance scanner と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudTrail は汎用的な選択肢だが、AWS AppConfig は「構成準拠状態を継続評価するコンプライアンス基盤」に責務を集中させやすい。
  • custom compliance scanner と比べると、AWS AppConfig は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Config, 準拠評価, 設定監査, 継続統制
CloudWatch OAM 🟠 完全ガイド T3 ★★★★★★★☆☆☆(6.6) 監視指標とログを統合運用する可観測性基盤
  • マルチアカウントのメトリクス・ログを中央観測アカウントへ集約するか
  • クロスアカウントのダッシュボード/アラーム共有か
  • 組織全体の監視を単一ビューで統合するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch OAM を第一候補にする場合。
  • CloudWatch OAM を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch OAM は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch OAM は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
CloudShell 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.5) マルチアカウント運用を標準化する管理統制サービス
  • ブラウザからAWS CLIをインストールなしで即時実行するか
  • セキュアなシェル環境をIAMで制御するか
  • 一時的な管理タスクを認証済み環境で実行するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して CloudShell を第一候補にする場合。
  • CloudShell を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、CloudShell は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、CloudShell は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudShell, 管理統制, 運用標準化, 継続改善
CloudWatch Network Synthetic Monitor 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.4) 監視指標とログを統合運用する可観測性基盤
  • VPCエンドポイント間の遅延・到達性を合成テストで監視するか
  • オンプレ↔AWSのネットワーク品質を継続監視するか
  • Transit GW/Direct Connectの経路品質を測定するか
  • Prometheus では要件を満たしきれず、監視指標とログを統合運用する可観測性基盤 を重視して CloudWatch Network Synthetic Monitor を第一候補にする場合。
  • CloudWatch Network Synthetic Monitor を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Datadog と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Prometheus
  • Datadog
  • Prometheus は汎用的な選択肢だが、CloudWatch Network Synthetic Monitor は「監視指標とログを統合運用する可観測性基盤」に責務を集中させやすい。
  • Datadog と比べると、CloudWatch Network Synthetic Monitor は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
CloudWatch, 監視, アラート, 運用可視化
AWS Well-Architected Tool 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(6.2) 設計レビューを継続運用し技術負債を可視化する基盤
  • 定期レビューを回せるか
  • 改善計画を追跡するか
  • 複数チームに展開するか
  • Trusted Advisor では要件を満たしきれず、設計レビューを継続運用し技術負債を可視化する基盤 を重視して AWS Well-Architected Tool を第一候補にする場合。
  • AWS Well-Architected Tool を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • architecture review checklist と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Trusted Advisor は汎用的な選択肢だが、AWS Well-Architected Tool は「設計レビューを継続運用し技術負債を可視化する基盤」に責務を集中させやすい。
  • architecture review checklist と比べると、AWS Well-Architected Tool は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Well-Architected, 設計レビュー, 技術負債, 継続改善
AWS Control Tower 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.1) ランディングゾーンを標準化して統制導入を加速する基盤
  • 初期統制を迅速展開したいか
  • 運用ガードレールを標準化するか
  • 監査要件を共通化するか
  • Organizations では要件を満たしきれず、ランディングゾーンを標準化して統制導入を加速する基盤 を重視して AWS Control Tower を第一候補にする場合。
  • AWS Control Tower を採用し、Config と組み合わせて責任境界を明確にしたい場合。
  • Landing Zone Accelerator と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS Control Tower は「ランディングゾーンを標準化して統制導入を加速する基盤」に責務を集中させやすい。
  • Landing Zone Accelerator と比べると、AWS Control Tower は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Config との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Control Tower, ランディングゾーン, 統制標準化, ガードレール
Resource Groups and Tagging 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.9) マルチアカウント運用を標準化する管理統制サービス
  • リソースのタグ付け状態を横断検索・一覧化するか
  • タグポリシーで命名規則を組織横断で強制するか
  • コスト配賦や環境区分のためのタグ管理か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Resource Groups and Tagging を第一候補にする場合。
  • Resource Groups and Tagging を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Resource Groups and Tagging は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Resource Groups and Tagging は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Resource Groups and Tagging, 管理統制, 運用標準化, 継続改善
AWS Service Catalog 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.7) 承認済みテンプレートでセルフサービス提供を統制する基盤
  • 標準テンプレート配布が必要か
  • 利用部門ごとの権限制御が必要か
  • 申請運用を簡素化したいか
  • Backstage では要件を満たしきれず、承認済みテンプレートでセルフサービス提供を統制する基盤 を重視して AWS Service Catalog を第一候補にする場合。
  • AWS Service Catalog を採用し、CloudFormation と組み合わせて責任境界を明確にしたい場合。
  • internal portal と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Backstage
  • internal portal
  • Backstage は汎用的な選択肢だが、AWS Service Catalog は「承認済みテンプレートでセルフサービス提供を統制する基盤」に責務を集中させやすい。
  • internal portal と比べると、AWS Service Catalog は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudFormation との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Service Catalog, セルフサービス, 標準化, 承認統制
Trusted Advisor API 🔵 完全ガイド T4 ★★★★★★☆☆☆☆(5.7) 運用ベストプラクティス逸脱を継続診断する最適化基盤
  • 改善提案を定期運用するか
  • 対象アカウントが多いか
  • コスト/性能/可用性を横断評価するか
  • Well-Architected では要件を満たしきれず、運用ベストプラクティス逸脱を継続診断する最適化基盤 を重視して Trusted Advisor API を第一候補にする場合。
  • Trusted Advisor API を採用し、Support と組み合わせて責任境界を明確にしたい場合。
  • custom health check と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Well-Architected
  • custom health check
  • Well-Architected は汎用的な選択肢だが、Trusted Advisor API は「運用ベストプラクティス逸脱を継続診断する最適化基盤」に責務を集中させやすい。
  • custom health check と比べると、Trusted Advisor API は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Support との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Trusted Advisor, 最適化診断, 運用品質, 改善提案
Recycle Bin 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.6) マルチアカウント運用を標準化する管理統制サービス
  • 削除したスナップショット/AMIを誤削除から一定期間保護するか
  • EBSスナップショット・AMIの一時保留・復元が必要か
  • 規制要件で一定保持期間を義務付けるか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Recycle Bin を第一候補にする場合。
  • Recycle Bin を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Recycle Bin は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Recycle Bin は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Recycle Bin, 管理統制, 運用標準化, 継続改善
AWS Health 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.4) マルチアカウント運用を標準化する管理統制サービス
  • AWSサービス障害・メンテナンス予告を組織全体で収集するか
  • Organization Health ViewでマルチアカウントのAWS健全性を集中管理するか
  • EventBridgeと連携した障害自動対応か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して AWS Health を第一候補にする場合。
  • AWS Health を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS Health は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、AWS Health は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Health, 管理統制, 運用標準化, 継続改善
Service Quotas 🟣 完全ガイド T5 ★★★★★☆☆☆☆☆(5.4) マルチアカウント運用を標準化する管理統制サービス
  • ソフトリミット引き上げをAPI/コンソールで申請・管理するか
  • 使用量アラームでクォータ上限到達を事前通知するか
  • リソースプロビジョニング前にクォータ充足を確認するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Service Quotas を第一候補にする場合。
  • Service Quotas を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Service Quotas は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Service Quotas は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Service Quotas, 管理統制, 運用標準化, 継続改善
AWS HealthOmics 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.3) マルチアカウント運用を標準化する管理統制サービス
  • ゲノム・バイオインフォマティクスデータのFHIR標準処理か
  • DNAシーケンスデータを大規模にクラウド分析するか
  • 医療オミクスデータのパイプラインとストレージを統合管理するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して AWS HealthOmics を第一候補にする場合。
  • AWS HealthOmics を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS HealthOmics は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、AWS HealthOmics は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS HealthOmics, 管理統制, 運用標準化, 継続改善
Quick Setup 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.3) マルチアカウント運用を標準化する管理統制サービス
  • Systems ManagerのPatch/ConfigRecorderをワンクリック有効化するか
  • 複数アカウントの推奨SSM設定を一括適用するか
  • SSM初期設定を最小工数で完了するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Quick Setup を第一候補にする場合。
  • Quick Setup を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Quick Setup は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Quick Setup は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Quick Setup, 管理統制, 運用標準化, 継続改善
Support 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.3) マルチアカウント運用を標準化する管理統制サービス
  • Business/Enterprise Supportプランのテクニカル対応が必要か
  • サポートケースをAPIで自動化・統合管理するか
  • TAM連携やConciergeサポートが必要か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Support を第一候補にする場合。
  • Support を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Support は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Support は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Support, 管理統制, 運用標準化, 継続改善
AWS Control Catalog 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.2) マルチアカウント運用を標準化する管理統制サービス
  • Control Tower/SCPのコントロール定義を横断検索・管理するか
  • 規制要件と実装済みコントロールのマッピングを管理するか
  • コンプライアンスフレームワーク横断での統制整理か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して AWS Control Catalog を第一候補にする場合。
  • AWS Control Catalog を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS Control Catalog は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、AWS Control Catalog は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Control Catalog, 管理統制, 運用標準化, 継続改善
License Manager 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.2) 運用コストと契約情報を統制管理する基盤
  • 予算逸脱を早期検知するか
  • 契約/ライセンス運用を標準化するか
  • 請求分析を自動化するか
  • Cost Explorer では要件を満たしきれず、運用コストと契約情報を統制管理する基盤 を重視して License Manager を第一候補にする場合。
  • License Manager を採用し、Budgets と組み合わせて責任境界を明確にしたい場合。
  • third-party finops と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Cost Explorer は汎用的な選択肢だが、License Manager は「運用コストと契約情報を統制管理する基盤」に責務を集中させやすい。
  • third-party finops と比べると、License Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Budgets との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
License Manager, コスト統制, 請求管理, finops
AWS Management Console 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.0) マルチアカウント運用を標準化する管理統制サービス
  • ブラウザGUIでAWSリソースを視覚的に管理するか
  • 複数アカウントへのスイッチロールを統合UIで管理するか
  • Q DeveloperアシスタントとのコンソールUI統合か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して AWS Management Console を第一候補にする場合。
  • AWS Management Console を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS Management Console は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、AWS Management Console は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Management Console, 管理統制, 運用標準化, 継続改善
User Notifications 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.0) マルチアカウント運用を標準化する管理統制サービス
  • Console Mobile/SlackへのAWSアラートを一元集約するか
  • CloudWatch/Config/Security Hubの通知をチャネル横断で管理するか
  • Organization全体の重要通知を統一チャンネルで受信するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して User Notifications を第一候補にする場合。
  • User Notifications を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、User Notifications は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、User Notifications は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
User Notifications, 管理統制, 運用標準化, 継続改善
AWS Panorama 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.9) マルチアカウント運用を標準化する管理統制サービス
  • 工場・店舗のIPカメラにMLモデルをEdgeデプロイするか
  • クラウド送信なしのオンプレ映像分析が必要か
  • Rekognitionモデルをカメラデバイスで直接推論するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して AWS Panorama を第一候補にする場合。
  • AWS Panorama を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS Panorama は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、AWS Panorama は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Panorama, 管理統制, 運用標準化, 継続改善
AWS Managed Services 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(4.8) マルチアカウント運用を標準化する管理統制サービス
  • AWSインフラの日常運用をAWSに完全委託するか
  • 24x7の運用対応・パッチ・変更管理をManagedで実施するか
  • 自社AWS運用チームなしでエンタープライズ級SLAが必要か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して AWS Managed Services を第一候補にする場合。
  • AWS Managed Services を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS Managed Services は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、AWS Managed Services は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Managed Services, 管理統制, 運用標準化, 継続改善
Cloud Control API 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(4.8) マルチアカウント運用を標準化する管理統制サービス
  • CloudFormation外のリソースをCRUD統一APIで操作するか
  • サードパーティリソースをCloudFormationレジストリで管理するか
  • AWSとサードパーティリソースの統一プロビジョニングか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Cloud Control API を第一候補にする場合。
  • Cloud Control API を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Cloud Control API は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Cloud Control API は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Cloud Control API, 管理統制, 運用標準化, 継続改善
Launch Wizard 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(4.8) マルチアカウント運用を標準化する管理統制サービス
  • SAP/SQL Server/Redisの推奨構成をガイド付きで素早くデプロイするか
  • ベストプラクティス構成を最小入力でプロビジョニングするか
  • Well-Architectedなワークロード初期構築を自動化するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Launch Wizard を第一候補にする場合。
  • Launch Wizard を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Launch Wizard は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Launch Wizard は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Launch Wizard, 管理統制, 運用標準化, 継続改善
Resilience Hub完全ガイド T7 ★★★★★☆☆☆☆☆(4.8) 運用耐障害性を検証して復旧力を高める運用基盤
  • 障害演習を定期実施するか
  • RTO/RPOを明文化するか
  • 復旧手順を自動化するか
  • Resilience Hub では要件を満たしきれず、運用耐障害性を検証して復旧力を高める運用基盤 を重視して Resilience Hub を第一候補にする場合。
  • Resilience Hub を採用し、CloudWatch と組み合わせて責任境界を明確にしたい場合。
  • custom chaos tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Resilience Hub は汎用的な選択肢だが、Resilience Hub は「運用耐障害性を検証して復旧力を高める運用基盤」に責務を集中させやすい。
  • custom chaos tool と比べると、Resilience Hub は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudWatch との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Resilience Hub, 障害演習, 復旧, 運用強化
HealthLake 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.7) マルチアカウント運用を標準化する管理統制サービス
  • FHIR R4準拠の医療データをクエリ・分析するか
  • 電子カルテ(EMR)データをAWSで集中管理するか
  • 医療データ解析のためのFHIR APIが必要か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して HealthLake を第一候補にする場合。
  • HealthLake を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、HealthLake は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、HealthLake は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
HealthLake, 管理統制, 運用標準化, 継続改善
Resource Explorer完全ガイド T7 ★★★★★☆☆☆☆☆(4.7) マルチアカウント運用を標準化する管理統制サービス
  • 全リージョン・全AWSリソースを横断検索するか
  • 未タグリソースや孤立リソースを発見するか
  • マルチアカウントの資産可視化が必要か
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して Resource Explorer を第一候補にする場合。
  • Resource Explorer を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、Resource Explorer は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、Resource Explorer は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Resource Explorer, 管理統制, 運用標準化, 継続改善
AWS RAM完全ガイド T7 ★★★★★☆☆☆☆☆(4.6) マルチアカウント運用を標準化する管理統制サービス
  • VPCサブネット/Transit GW/Route 53をクロスアカウント共有するか
  • Organizations内でリソースを重複作成なしに共有するか
  • 共有リソースのアクセス制御をIAM連携で管理するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して AWS RAM を第一候補にする場合。
  • AWS RAM を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、AWS RAM は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、AWS RAM は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS RAM, 管理統制, 運用標準化, 継続改善
HealthImaging 🩶 完全ガイド T8 ★★★★☆☆☆☆☆☆(4.5) マルチアカウント運用を標準化する管理統制サービス
  • DICOM医療画像をFHIR準拠で大規模クラウド保管するか
  • 放射線科のDICOM画像を低コストで長期アーカイブするか
  • AI医療画像解析のデータ基盤として活用するか
  • Organizations では要件を満たしきれず、マルチアカウント運用を標準化する管理統制サービス を重視して HealthImaging を第一候補にする場合。
  • HealthImaging を採用し、CloudTrail と組み合わせて責任境界を明確にしたい場合。
  • custom governance tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Organizations は汎用的な選択肢だが、HealthImaging は「マルチアカウント運用を標準化する管理統制サービス」に責務を集中させやすい。
  • custom governance tool と比べると、HealthImaging は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CloudTrail との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
HealthImaging, 管理統制, 運用標準化, 継続改善

Cost & Commerce (4)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
AWS Payment Cryptography 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.0) 請求配賦と契約条件を統制する課金管理基盤
  • PCI-DSS準拠の決済用暗号鍵をHSMで管理するか
  • PIN暗号化・カード検証コードの安全処理が必要か
  • オンプレHSMベース決済インフラをクラウド移行するか
  • Cost Explorer では要件を満たしきれず、請求配賦と契約条件を統制する課金管理基盤 を重視して AWS Payment Cryptography を第一候補にする場合。
  • AWS Payment Cryptography を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • ERP billing と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Cost Explorer は汎用的な選択肢だが、AWS Payment Cryptography は「請求配賦と契約条件を統制する課金管理基盤」に責務を集中させやすい。
  • ERP billing と比べると、AWS Payment Cryptography は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Payment Cryptography, 課金管理, 配賦, 統制
AWS Marketplace完全ガイド T7 ★★★★★☆☆☆☆☆(4.8) 請求配賦と契約条件を統制する課金管理基盤
  • サードパーティSaaS/ソフトウェアをAWSアカウントに統合購入するか
  • Marketplaceソフトウェアの請求をAWS請求に一元化するか
  • ISVとしてAWS上でソフトウェアを販売するか
  • Cost Explorer では要件を満たしきれず、請求配賦と契約条件を統制する課金管理基盤 を重視して AWS Marketplace を第一候補にする場合。
  • AWS Marketplace を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • ERP billing と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Cost Explorer は汎用的な選択肢だが、AWS Marketplace は「請求配賦と契約条件を統制する課金管理基盤」に責務を集中させやすい。
  • ERP billing と比べると、AWS Marketplace は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Marketplace, 課金管理, 配賦, 統制
Billing and Cost Management完全ガイド T7 ★★★★☆☆☆☆☆☆(4.5) 請求配賦と契約条件を統制する課金管理基盤
  • AWSコストをサービス/タグ/アカウント別に分析するか
  • 予算超過を事前にBudgetsアラートで検知するか
  • 一括請求をOrganizationsで統合するか
  • Cost Explorer では要件を満たしきれず、請求配賦と契約条件を統制する課金管理基盤 を重視して Billing and Cost Management を第一候補にする場合。
  • Billing and Cost Management を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • ERP billing と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Cost Explorer は汎用的な選択肢だが、Billing and Cost Management は「請求配賦と契約条件を統制する課金管理基盤」に責務を集中させやすい。
  • ERP billing と比べると、Billing and Cost Management は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Billing and Cost Management, 課金管理, 配賦, 統制
AWS Billing Conductor 🔘 完全ガイド T9 ★★★★☆☆☆☆☆☆(4.4) 請求配賦と契約条件を統制する課金管理基盤
  • MSP/リセラーが顧客向けに独自料金設定でカスタム請求するか
  • コスト配賦を実際の請求から分離したカスタムレートで管理するか
  • 内部振替価格でチャージバックを標準化するか
  • Cost Explorer では要件を満たしきれず、請求配賦と契約条件を統制する課金管理基盤 を重視して AWS Billing Conductor を第一候補にする場合。
  • AWS Billing Conductor を採用し、Organizations と組み合わせて責任境界を明確にしたい場合。
  • ERP billing と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Cost Explorer は汎用的な選択肢だが、AWS Billing Conductor は「請求配賦と契約条件を統制する課金管理基盤」に責務を集中させやすい。
  • ERP billing と比べると、AWS Billing Conductor は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Organizations との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Billing Conductor, 課金管理, 配賦, 統制

Migration & Transfer (11)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
DataSync 🟡 完全ガイド T2 ★★★★★★★☆☆☆(6.7) オンプレ/クラウド間データ転送を高速化する移送基盤
  • 大容量転送が継続発生するか
  • 転送自動化が必要か
  • 整合性検証を重視するか
  • rsync では要件を満たしきれず、オンプレ/クラウド間データ転送を高速化する移送基盤 を重視して DataSync を第一候補にする場合。
  • DataSync を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Storage Gateway と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • rsync は汎用的な選択肢だが、DataSync は「オンプレ/クラウド間データ転送を高速化する移送基盤」に責務を集中させやすい。
  • Storage Gateway と比べると、DataSync は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
DataSync, データ転送, 同期, 高速移送
AWS DMS 🟠 完全ガイド T3 ★★★★★★★☆☆☆(6.6) DB移行と継続レプリケーションを担うデータ移行基盤
  • 異種DB移行が必要か
  • 停止時間を抑えるか
  • CDC運用を継続できるか
  • native replication では要件を満たしきれず、DB移行と継続レプリケーションを担うデータ移行基盤 を重視して AWS DMS を第一候補にする場合。
  • AWS DMS を採用し、RDS と組み合わせて責任境界を明確にしたい場合。
  • GoldenGate と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • native replication
  • GoldenGate
  • native replication は汎用的な選択肢だが、AWS DMS は「DB移行と継続レプリケーションを担うデータ移行基盤」に責務を集中させやすい。
  • GoldenGate と比べると、AWS DMS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • RDS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
DMS, DB移行, CDC, レプリケーション
Transfer Family 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.4) 移行計画と実行を標準化するトランスファーサービス
  • SFTP/FTPS/FTPでS3EFSへのセキュアなファイル転送が必要か
  • 既存FTPワークフローをAWSに移行するか
  • パートナーとのファイル授受プロトコルを維持するか
  • MGN では要件を満たしきれず、移行計画と実行を標準化するトランスファーサービス を重視して Transfer Family を第一候補にする場合。
  • Transfer Family を採用し、Migration Hub と組み合わせて責任境界を明確にしたい場合。
  • custom migration tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • MGN
  • custom migration tool
  • MGN は汎用的な選択肢だが、Transfer Family は「移行計画と実行を標準化するトランスファーサービス」に責務を集中させやすい。
  • custom migration tool と比べると、Transfer Family は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Migration Hub との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Transfer Family, 移行, 転送, 切替計画
  • OpenSSH SFTP Server
Elastic Disaster Recovery 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) 移行計画と実行を標準化するトランスファーサービス
  • オンプレ・クラウドサーバのDRレプリケーションをAWSへか
  • 分単位RPOのフェイルオーバーとフェイルバックが必要か
  • 低コストDRサイトをサブスクリプション課金で構築するか
  • MGN では要件を満たしきれず、移行計画と実行を標準化するトランスファーサービス を重視して Elastic Disaster Recovery を第一候補にする場合。
  • Elastic Disaster Recovery を採用し、Migration Hub と組み合わせて責任境界を明確にしたい場合。
  • custom migration tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • MGN
  • custom migration tool
  • MGN は汎用的な選択肢だが、Elastic Disaster Recovery は「移行計画と実行を標準化するトランスファーサービス」に責務を集中させやすい。
  • custom migration tool と比べると、Elastic Disaster Recovery は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Migration Hub との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Elastic Disaster Recovery, 移行, 転送, 切替計画
Migration Hub Orchestrator 🟤 完全ガイド T6 ★★★★★★☆☆☆☆(5.5) 移行進捗を一元可視化して計画実行を統制する管理基盤
  • 複数移行ツールを併用するか
  • 進捗報告を標準化するか
  • 依存関係管理が必要か
  • custom PMO dashboard では要件を満たしきれず、移行進捗を一元可視化して計画実行を統制する管理基盤 を重視して Migration Hub Orchestrator を第一候補にする場合。
  • Migration Hub Orchestrator を採用し、MGN と組み合わせて責任境界を明確にしたい場合。
  • Jira と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom PMO dashboard
  • Jira
  • custom PMO dashboard は汎用的な選択肢だが、Migration Hub Orchestrator は「移行進捗を一元可視化して計画実行を統制する管理基盤」に責務を集中させやすい。
  • Jira と比べると、Migration Hub Orchestrator は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • MGN との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Migration Hub, 進捗管理, 可視化, 移行統制
Migration Hub Strategy Recommendations 🟤 完全ガイド T6 ★★★★★★☆☆☆☆(5.5) 移行進捗を一元可視化して計画実行を統制する管理基盤
  • 複数移行ツールを併用するか
  • 進捗報告を標準化するか
  • 依存関係管理が必要か
  • custom PMO dashboard では要件を満たしきれず、移行進捗を一元可視化して計画実行を統制する管理基盤 を重視して Migration Hub Strategy Recommendations を第一候補にする場合。
  • Migration Hub Strategy Recommendations を採用し、MGN と組み合わせて責任境界を明確にしたい場合。
  • Jira と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom PMO dashboard
  • Jira
  • custom PMO dashboard は汎用的な選択肢だが、Migration Hub Strategy Recommendations は「移行進捗を一元可視化して計画実行を統制する管理基盤」に責務を集中させやすい。
  • Jira と比べると、Migration Hub Strategy Recommendations は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • MGN との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Migration Hub, 進捗管理, 可視化, 移行統制
AWS Migration Hub Refactor Spaces 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.4) 移行進捗を一元可視化して計画実行を統制する管理基盤
  • モノリスをマイクロサービスへ段階的にリファクタリングするか
  • 既存アプリのトラフィックを新マイクロサービスへ徐々に移行するか
  • ストラングラーフィグパターンの実装を支援するか
  • custom PMO dashboard では要件を満たしきれず、移行進捗を一元可視化して計画実行を統制する管理基盤 を重視して AWS Migration Hub Refactor Spaces を第一候補にする場合。
  • AWS Migration Hub Refactor Spaces を採用し、MGN と組み合わせて責任境界を明確にしたい場合。
  • Jira と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom PMO dashboard
  • Jira
  • custom PMO dashboard は汎用的な選択肢だが、AWS Migration Hub Refactor Spaces は「移行進捗を一元可視化して計画実行を統制する管理基盤」に責務を集中させやすい。
  • Jira と比べると、AWS Migration Hub Refactor Spaces は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • MGN との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Migration Hub, 進捗管理, 可視化, 移行統制
Migration Hub 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.0) 移行進捗を一元可視化して計画実行を統制する管理基盤
  • 複数移行ツールを併用するか
  • 進捗報告を標準化するか
  • 依存関係管理が必要か
  • custom PMO dashboard では要件を満たしきれず、移行進捗を一元可視化して計画実行を統制する管理基盤 を重視して Migration Hub を第一候補にする場合。
  • Migration Hub を採用し、MGN と組み合わせて責任境界を明確にしたい場合。
  • Jira と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom PMO dashboard
  • Jira
  • custom PMO dashboard は汎用的な選択肢だが、Migration Hub は「移行進捗を一元可視化して計画実行を統制する管理基盤」に責務を集中させやすい。
  • Jira と比べると、Migration Hub は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • MGN との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Migration Hub, 進捗管理, 可視化, 移行統制
Application Discovery Service 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(4.9) 移行計画と実行を標準化するトランスファーサービス
  • オンプレサーバの依存関係とパフォーマンスを自動検出するか
  • Migration Hubへのインベントリデータ供給が必要か
  • 移行前のサーバ棚卸しと依存関係マッピングか
  • MGN では要件を満たしきれず、移行計画と実行を標準化するトランスファーサービス を重視して Application Discovery Service を第一候補にする場合。
  • Application Discovery Service を採用し、Migration Hub と組み合わせて責任境界を明確にしたい場合。
  • custom migration tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • MGN
  • custom migration tool
  • MGN は汎用的な選択肢だが、Application Discovery Service は「移行計画と実行を標準化するトランスファーサービス」に責務を集中させやすい。
  • custom migration tool と比べると、Application Discovery Service は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Migration Hub との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Application Discovery Service, 移行, 転送, 切替計画
Application Migration Service 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(4.9) サーバ移行を自動化しリホストを加速する基盤
  • 短期移行を優先するか
  • 停止時間を最小化したいか
  • 大量サーバ移行が必要か
  • DMS では要件を満たしきれず、サーバ移行を自動化しリホストを加速する基盤 を重視して Application Migration Service を第一候補にする場合。
  • Application Migration Service を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • VMware HCX と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • DMS は汎用的な選択肢だが、Application Migration Service は「サーバ移行を自動化しリホストを加速する基盤」に責務を集中させやすい。
  • VMware HCX と比べると、Application Migration Service は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MGN, リホスト, 移行自動化, サーバ移行
AWS Mainframe Modernization 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(4.8) 移行計画と実行を標準化するトランスファーサービス
  • COBOLメインフレームアプリをAWSにリプラットフォームするか
  • メインフレームコードの変換・テストをマネージドで実施するか
  • z/OSやIBM System iのワークロードをAWSへ移行するか
  • MGN では要件を満たしきれず、移行計画と実行を標準化するトランスファーサービス を重視して AWS Mainframe Modernization を第一候補にする場合。
  • AWS Mainframe Modernization を採用し、Migration Hub と組み合わせて責任境界を明確にしたい場合。
  • custom migration tool と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • MGN
  • custom migration tool
  • MGN は汎用的な選択肢だが、AWS Mainframe Modernization は「移行計画と実行を標準化するトランスファーサービス」に責務を集中させやすい。
  • custom migration tool と比べると、AWS Mainframe Modernization は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Migration Hub との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Mainframe Modernization, 移行, 転送, 切替計画

Business Applications (11)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
SES 🟡 完全ガイド T2 ★★★★★★★☆☆☆(7.1) 大規模メール配信を制御する送信基盤
  • 到達率最適化が必要か
  • 送信ドメイン管理を実施するか
  • バウンス対応を自動化するか
  • SendGrid では要件を満たしきれず、大規模メール配信を制御する送信基盤 を重視して SES を第一候補にする場合。
  • SES を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Mailgun と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • SendGrid
  • Mailgun
  • SendGrid は汎用的な選択肢だが、SES は「大規模メール配信を制御する送信基盤」に責務を集中させやすい。
  • Mailgun と比べると、SES は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SES, メール配信, 到達率, 送信管理
Connect 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.3) コンタクトセンター業務をクラウド化する運用基盤
  • オムニチャネル対応が必要か
  • 通話品質KPIを運用するか
  • CRM連携を標準化するか
  • Genesys では要件を満たしきれず、コンタクトセンター業務をクラウド化する運用基盤 を重視して Connect を第一候補にする場合。
  • Connect を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Twilio Flex と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Genesys
  • Twilio Flex
  • Genesys は汎用的な選択肢だが、Connect は「コンタクトセンター業務をクラウド化する運用基盤」に責務を集中させやすい。
  • Twilio Flex と比べると、Connect は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Connect, コールセンター, オムニチャネル, 運用
MSK Connect 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(5.1) コンタクトセンター業務をクラウド化する運用基盤
  • MSK/KafkaのConnectコネクタをマネージドでデプロイするか
  • KafkaとデータソースS3/RDS/OpenSearchのパイプラインをサーバーレスか
  • KafkaコネクタをEKS不要で安全に管理するか
  • Genesys では要件を満たしきれず、コンタクトセンター業務をクラウド化する運用基盤 を重視して MSK Connect を第一候補にする場合。
  • MSK Connect を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Twilio Flex と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Genesys
  • Twilio Flex
  • Genesys は汎用的な選択肢だが、MSK Connect は「コンタクトセンター業務をクラウド化する運用基盤」に責務を集中させやすい。
  • Twilio Flex と比べると、MSK Connect は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Connect, コールセンター, オムニチャネル, 運用
Chime 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.0) 会議・通話機能を業務アプリへ組み込む通信基盤
  • リアルタイム通話が必要か
  • 会議記録連携が必要か
  • セキュリティ要件を満たせるか
  • Zoom SDK では要件を満たしきれず、会議・通話機能を業務アプリへ組み込む通信基盤 を重視して Chime を第一候補にする場合。
  • Chime を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Twilio と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Zoom SDK
  • Twilio
  • Zoom SDK は汎用的な選択肢だが、Chime は「会議・通話機能を業務アプリへ組み込む通信基盤」に責務を集中させやすい。
  • Twilio と比べると、Chime は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Chime, 通話, 会議, 埋め込み通信
AWS End User Messaging 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.0) 業務アプリ連携を標準化するビジネスサービス
  • SMS/Eメール/プッシュ通知を統合APIで一元配信するか
  • Pinpointに統合される多チャネル通知基盤か
  • エンドユーザーへのトランザクション・プロモーション配信か
  • custom SaaS では要件を満たしきれず、業務アプリ連携を標準化するビジネスサービス を重視して AWS End User Messaging を第一候補にする場合。
  • AWS End User Messaging を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • third-party app と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom SaaS
  • third-party app
  • custom SaaS は汎用的な選択肢だが、AWS End User Messaging は「業務アプリ連携を標準化するビジネスサービス」に責務を集中させやすい。
  • third-party app と比べると、AWS End User Messaging は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS End User Messaging, 業務連携, 運用標準化, SaaS
Connect Health 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(5.0) コンタクトセンター業務をクラウド化する運用基盤
  • Amazon Connectコンタクトセンターの健全性メトリクスを監視するか
  • コールセンター品質のリアルタイム監視が必要か
  • Connect運用のSLAモニタリングか
  • Genesys では要件を満たしきれず、コンタクトセンター業務をクラウド化する運用基盤 を重視して Connect Health を第一候補にする場合。
  • Connect Health を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Twilio Flex と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Genesys
  • Twilio Flex
  • Genesys は汎用的な選択肢だが、Connect Health は「コンタクトセンター業務をクラウド化する運用基盤」に責務を集中させやすい。
  • Twilio Flex と比べると、Connect Health は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Connect, コールセンター, オムニチャネル, 運用
MediaConnect完全ガイド T7 ★★★★★☆☆☆☆☆(4.9) コンタクトセンター業務をクラウド化する運用基盤
  • プロライブ映像をIPネットワーク経由で安全に転送するか
  • ブロードキャスト品質の映像フローをAWSへ取り込むか
  • 低遅延映像配信インフラをST2110/SRT対応で構築するか
  • Genesys では要件を満たしきれず、コンタクトセンター業務をクラウド化する運用基盤 を重視して MediaConnect を第一候補にする場合。
  • MediaConnect を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Twilio Flex と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Genesys
  • Twilio Flex
  • Genesys は汎用的な選択肢だが、MediaConnect は「コンタクトセンター業務をクラウド化する運用基盤」に責務を集中させやすい。
  • Twilio Flex と比べると、MediaConnect は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Connect, コールセンター, オムニチャネル, 運用
B2B Data Interchange 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(4.8) 業務アプリ連携を標準化するビジネスサービス
  • EDI/X12/EDIFACT形式のB2Bメッセージを変換・交換するか
  • サプライチェーンパートナーとの電子商取引を標準化するか
  • TradingパートナーへのAS2/SFTP配信か
  • custom SaaS では要件を満たしきれず、業務アプリ連携を標準化するビジネスサービス を重視して B2B Data Interchange を第一候補にする場合。
  • B2B Data Interchange を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • third-party app と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom SaaS
  • third-party app
  • custom SaaS は汎用的な選択肢だが、B2B Data Interchange は「業務アプリ連携を標準化するビジネスサービス」に責務を集中させやすい。
  • third-party app と比べると、B2B Data Interchange は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
B2B Data Interchange, 業務連携, 運用標準化, SaaS
Chime SDK 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(4.6) 会議・通話機能を業務アプリへ組み込む通信基盤
  • リアルタイム通話が必要か
  • 会議記録連携が必要か
  • セキュリティ要件を満たせるか
  • Zoom SDK では要件を満たしきれず、会議・通話機能を業務アプリへ組み込む通信基盤 を重視して Chime SDK を第一候補にする場合。
  • Chime SDK を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Twilio と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Zoom SDK
  • Twilio
  • Zoom SDK は汎用的な選択肢だが、Chime SDK は「会議・通話機能を業務アプリへ組み込む通信基盤」に責務を集中させやすい。
  • Twilio と比べると、Chime SDK は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Chime, 通話, 会議, 埋め込み通信
AWS Wickr 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(4.6) 業務アプリ連携を標準化するビジネスサービス
  • エンドツーエンド暗号化メッセージング・ファイル共有が必要か
  • 金融・政府・医療の高機密通信を規制準拠で管理するか
  • ガバナンス要件のある組織内通信の記録・保全か
  • custom SaaS では要件を満たしきれず、業務アプリ連携を標準化するビジネスサービス を重視して AWS Wickr を第一候補にする場合。
  • AWS Wickr を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • third-party app と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom SaaS
  • third-party app
  • custom SaaS は汎用的な選択肢だが、AWS Wickr は「業務アプリ連携を標準化するビジネスサービス」に責務を集中させやすい。
  • third-party app と比べると、AWS Wickr は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Wickr, 業務連携, 運用標準化, SaaS
AWS Entity Resolution 🩶 完全ガイド T8 ★★★★☆☆☆☆☆☆(4.5) 業務アプリ連携を標準化するビジネスサービス
  • 複数データソースの同一エンティティを名寄せ・マッチングするか
  • ML/ルールベースのレコード一致が必要か
  • クロスデータセットの顧客ID統合か
  • custom SaaS では要件を満たしきれず、業務アプリ連携を標準化するビジネスサービス を重視して AWS Entity Resolution を第一候補にする場合。
  • AWS Entity Resolution を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • third-party app と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom SaaS
  • third-party app
  • custom SaaS は汎用的な選択肢だが、AWS Entity Resolution は「業務アプリ連携を標準化するビジネスサービス」に責務を集中させやすい。
  • third-party app と比べると、AWS Entity Resolution は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Entity Resolution, 業務連携, 運用標準化, SaaS

End User Computing (5)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
WorkSpaces Secure Browser 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.4) 仮想デスクトップを迅速提供するエンドユーザー基盤
  • エンドポイントにデータを保存しないクラウドブラウザ(RBI)か
  • BYODからVPNなしで社内WebアプリにアクセスするRBIか
  • コピー・ダウンロード・印刷を細粒度制御するか
  • AVD では要件を満たしきれず、仮想デスクトップを迅速提供するエンドユーザー基盤 を重視して WorkSpaces Secure Browser を第一候補にする場合。
  • WorkSpaces Secure Browser を採用し、Directory Service と組み合わせて責任境界を明確にしたい場合。
  • Citrix と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • AVD
  • Citrix
  • AVD は汎用的な選択肢だが、WorkSpaces Secure Browser は「仮想デスクトップを迅速提供するエンドユーザー基盤」に責務を集中させやすい。
  • Citrix と比べると、WorkSpaces Secure Browser は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Directory Service との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
WorkSpaces, 仮想デスクトップ, 端末統制, リモートワーク
  • VDIクライアントAD連携
WorkSpaces Applications 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.3) 仮想デスクトップを迅速提供するエンドユーザー基盤
  • WindowsアプリをAppStream 2.0でブラウザ配信するか
  • インストールなしでCAD/Matlab等を配信するか
  • セッション終了でデータをクリーンアップするか
  • AVD では要件を満たしきれず、仮想デスクトップを迅速提供するエンドユーザー基盤 を重視して WorkSpaces Applications を第一候補にする場合。
  • WorkSpaces Applications を採用し、Directory Service と組み合わせて責任境界を明確にしたい場合。
  • Citrix と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • AVD
  • Citrix
  • AVD は汎用的な選択肢だが、WorkSpaces Applications は「仮想デスクトップを迅速提供するエンドユーザー基盤」に責務を集中させやすい。
  • Citrix と比べると、WorkSpaces Applications は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Directory Service との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
WorkSpaces, 仮想デスクトップ, 端末統制, リモートワーク
  • VDIクライアントAD連携
WorkSpaces 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(4.9) 仮想デスクトップを迅速提供するエンドユーザー基盤
  • フルWindowsデスクトップをクラウドで永続的に提供するか
  • Active Directory連携の個人割当VDIか
  • ユーザー設定・データが永続するデスクトップか
  • AVD では要件を満たしきれず、仮想デスクトップを迅速提供するエンドユーザー基盤 を重視して WorkSpaces を第一候補にする場合。
  • WorkSpaces を採用し、Directory Service と組み合わせて責任境界を明確にしたい場合。
  • Citrix と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • AVD
  • Citrix
  • AVD は汎用的な選択肢だが、WorkSpaces は「仮想デスクトップを迅速提供するエンドユーザー基盤」に責務を集中させやすい。
  • Citrix と比べると、WorkSpaces は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Directory Service との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
WorkSpaces, 仮想デスクトップ, 端末統制, リモートワーク
  • VDIクライアントAD連携
WorkMail 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(4.6) メール/予定表をマネージド提供する業務コミュニケーション基盤
  • メール基盤を運用簡素化したいか
  • モバイル利用を許可するか
  • 暗号化要件を満たすか
  • Microsoft 365 では要件を満たしきれず、メール/予定表をマネージド提供する業務コミュニケーション基盤 を重視して WorkMail を第一候補にする場合。
  • WorkMail を採用し、SES と組み合わせて責任境界を明確にしたい場合。
  • Google Workspace と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Microsoft 365
  • Google Workspace
  • Microsoft 365 は汎用的な選択肢だが、WorkMail は「メール/予定表をマネージド提供する業務コミュニケーション基盤」に責務を集中させやすい。
  • Google Workspace と比べると、WorkMail は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SES との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
WorkMail, メール, 予定表, 業務連絡
  • VDIクライアントAD連携
WorkSpaces Instances 🔘 完全ガイド T9 ★★★★☆☆☆☆☆☆(4.3) 仮想デスクトップを迅速提供するエンドユーザー基盤
  • GPU(g4dn/g4ad)搭載デスクトップでグラフィックス集約型作業か
  • カスタムAMIで特定ソフトをプリインストールするか
  • EC2インスタンスを直接WorkSpaces環境として使用するか
  • AVD では要件を満たしきれず、仮想デスクトップを迅速提供するエンドユーザー基盤 を重視して WorkSpaces Instances を第一候補にする場合。
  • WorkSpaces Instances を採用し、Directory Service と組み合わせて責任境界を明確にしたい場合。
  • Citrix と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • AVD
  • Citrix
  • AVD は汎用的な選択肢だが、WorkSpaces Instances は「仮想デスクトップを迅速提供するエンドユーザー基盤」に責務を集中させやすい。
  • Citrix と比べると、WorkSpaces Instances は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Directory Service との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
WorkSpaces, 仮想デスクトップ, 端末統制, リモートワーク
  • VDIクライアントAD連携

Frontend Web & Mobile (3)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
Amplify 🟠 完全ガイド T3 ★★★★★★☆☆☆☆(6.3) フロントエンド開発とホスティングを統合する開発基盤
  • 迅速リリースを重視するか
  • 認証/API連携を簡素化したいか
  • プレビュー運用を回すか
  • Vercel では要件を満たしきれず、フロントエンド開発とホスティングを統合する開発基盤 を重視して Amplify を第一候補にする場合。
  • Amplify を採用し、Cognito と組み合わせて責任境界を明確にしたい場合。
  • Netlify と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Vercel
  • Netlify
  • Vercel は汎用的な選択肢だが、Amplify は「フロントエンド開発とホスティングを統合する開発基盤」に責務を集中させやすい。
  • Netlify と比べると、Amplify は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Cognito との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Amplify, フロント開発, ホスティング, CI/CD
Device Farm 🔘 完全ガイド T9 ★★★★★★☆☆☆☆(5.9) 実機テストをクラウド実行するモバイル品質保証基盤
  • 多端末検証が必要か
  • 自動テストを継続実行するか
  • リリース前検証を短縮するか
  • BrowserStack では要件を満たしきれず、実機テストをクラウド実行するモバイル品質保証基盤 を重視して Device Farm を第一候補にする場合。
  • Device Farm を採用し、CodeBuild と組み合わせて責任境界を明確にしたい場合。
  • Firebase Test Lab と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • BrowserStack
  • Firebase Test Lab
  • BrowserStack は汎用的な選択肢だが、Device Farm は「実機テストをクラウド実行するモバイル品質保証基盤」に責務を集中させやすい。
  • Firebase Test Lab と比べると、Device Farm は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • CodeBuild との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Device Farm, 実機テスト, モバイルQA, 自動検証
Pinpoint 🟤 完全ガイド T6 ★★★★★☆☆☆☆☆(5.1) ウェブ/モバイル配信を加速するフロント基盤
  • メール/SMS/プッシュ通知のターゲティングキャンペーンか
  • セグメント分析とA/Bテストで配信最適化するか
  • ユーザー行動イベント収集とジャーニー自動化か
  • CloudFront では要件を満たしきれず、ウェブ/モバイル配信を加速するフロント基盤 を重視して Pinpoint を第一候補にする場合。
  • Pinpoint を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Vercel と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudFront は汎用的な選択肢だが、Pinpoint は「ウェブ/モバイル配信を加速するフロント基盤」に責務を集中させやすい。
  • Vercel と比べると、Pinpoint は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Pinpoint, フロント, 配信, 開発

Media Services (6)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
MediaTailor完全ガイド T7 ★★★★★★☆☆☆☆(5.5) 広告挿入を動的制御して収益最適化する配信基盤
  • サーバーサイド広告挿入が必要か
  • 広告ルールを細かく制御するか
  • 視聴体験を維持したいか
  • Google DAI では要件を満たしきれず、広告挿入を動的制御して収益最適化する配信基盤 を重視して MediaTailor を第一候補にする場合。
  • MediaTailor を採用し、MediaPackage と組み合わせて責任境界を明確にしたい場合。
  • Yospace と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Google DAI
  • Yospace
  • Google DAI は汎用的な選択肢だが、MediaTailor は「広告挿入を動的制御して収益最適化する配信基盤」に責務を集中させやすい。
  • Yospace と比べると、MediaTailor は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • MediaPackage との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MediaTailor, 広告挿入, SSAI, 収益化
MediaLive完全ガイド T7 ★★★★★☆☆☆☆☆(5.4) ライブ映像をリアルタイム配信向けにエンコードする基盤
  • 低遅延ライブ配信が必要か
  • 多系統冗長化が必要か
  • 運用監視を24/7で回せるか
  • Wowza では要件を満たしきれず、ライブ映像をリアルタイム配信向けにエンコードする基盤 を重視して MediaLive を第一候補にする場合。
  • MediaLive を採用し、MediaPackage と組み合わせて責任境界を明確にしたい場合。
  • Nimble Streamer と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Wowza
  • Nimble Streamer
  • Wowza は汎用的な選択肢だが、MediaLive は「ライブ映像をリアルタイム配信向けにエンコードする基盤」に責務を集中させやすい。
  • Nimble Streamer と比べると、MediaLive は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • MediaPackage との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MediaLive, ライブ配信, リアルタイム, エンコード
MediaConvert完全ガイド T7 ★★★★★☆☆☆☆☆(5.0) 映像トランスコードをジョブ単位で最適化する変換基盤
  • 多形式配信が必要か
  • 画質/ビットレート最適化が必要か
  • バッチ変換を自動化するか
  • FFmpeg on EC2 では要件を満たしきれず、映像トランスコードをジョブ単位で最適化する変換基盤 を重視して MediaConvert を第一候補にする場合。
  • MediaConvert を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Bitmovin と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • FFmpeg on EC2
  • Bitmovin
  • FFmpeg on EC2 は汎用的な選択肢だが、MediaConvert は「映像トランスコードをジョブ単位で最適化する変換基盤」に責務を集中させやすい。
  • Bitmovin と比べると、MediaConvert は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MediaConvert, トランスコード, 映像変換, 配信最適化
Elemental Inference 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.9) メディア処理をマネージド化して配信運用を標準化する基盤
  • 映像処理量が多いか
  • 配信品質を安定化したいか
  • 運用負荷を下げたいか
  • self-hosted media stack では要件を満たしきれず、メディア処理をマネージド化して配信運用を標準化する基盤 を重視して Elemental Inference を第一候補にする場合。
  • Elemental Inference を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • SaaS media と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • self-hosted media stack
  • SaaS media
  • self-hosted media stack は汎用的な選択肢だが、Elemental Inference は「メディア処理をマネージド化して配信運用を標準化する基盤」に責務を集中させやすい。
  • SaaS media と比べると、Elemental Inference は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Elemental Inference, メディア, 配信, 映像処理
MediaPackage完全ガイド T7 ★★★★★☆☆☆☆☆(4.9) ライブ/オンデマンド配信向けにパッケージ化する配信基盤
  • 複数デバイス向け配信が必要か
  • DRM連携が必要か
  • 配信起点を統一したいか
  • CloudFront origin では要件を満たしきれず、ライブ/オンデマンド配信向けにパッケージ化する配信基盤 を重視して MediaPackage を第一候補にする場合。
  • MediaPackage を採用し、MediaLive と組み合わせて責任境界を明確にしたい場合。
  • Akamai packaging と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • CloudFront origin は汎用的な選択肢だが、MediaPackage は「ライブ/オンデマンド配信向けにパッケージ化する配信基盤」に責務を集中させやすい。
  • Akamai packaging と比べると、MediaPackage は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • MediaLive との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MediaPackage, パッケージング, 配信, DRM
IVS 🩶 完全ガイド T8 ★★★★☆☆☆☆☆☆(4.2) インタラクティブ低遅延配信を簡易導入する基盤
  • 双方向性が重要か
  • 数秒未満遅延が必要か
  • 短期イベント配信を頻繁に行うか
  • Agora では要件を満たしきれず、インタラクティブ低遅延配信を簡易導入する基盤 を重視して IVS を第一候補にする場合。
  • IVS を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • Twitch IVS alternatives と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Agora
  • Twitch IVS alternatives
  • Agora は汎用的な選択肢だが、IVS は「インタラクティブ低遅延配信を簡易導入する基盤」に責務を集中させやすい。
  • Twitch IVS alternatives と比べると、IVS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
IVS, 低遅延配信, インタラクティブ, ライブ

IoT & Edge (11)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
AWS IoT Device Management完全ガイド T7 ★★★★★☆☆☆☆☆(5.3) デバイス群の登録・更新・監視を統合管理する基盤
  • 大量デバイス更新が必要か
  • 障害端末検知を自動化するか
  • 運用手順を標準化するか
  • MDM tools では要件を満たしきれず、デバイス群の登録・更新・監視を統合管理する基盤 を重視して AWS IoT Device Management を第一候補にする場合。
  • AWS IoT Device Management を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • custom OTA と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • MDM tools
  • custom OTA
  • MDM tools は汎用的な選択肢だが、AWS IoT Device Management は「デバイス群の登録・更新・監視を統合管理する基盤」に責務を集中させやすい。
  • custom OTA と比べると、AWS IoT Device Management は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
IoT Device Management, OTA, デバイス管理, 運用統合
AWS IoT FleetWise完全ガイド T7 ★★★★★☆☆☆☆☆(5.1) 車両データ収集を標準化して分析活用する車載基盤
  • 車両フリート規模が大きいか
  • 信号定義管理が必要か
  • OTA連携を設計するか
  • custom telematics では要件を満たしきれず、車両データ収集を標準化して分析活用する車載基盤 を重視して AWS IoT FleetWise を第一候補にする場合。
  • AWS IoT FleetWise を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • Azure Mobility と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom telematics
  • Azure Mobility
  • custom telematics は汎用的な選択肢だが、AWS IoT FleetWise は「車両データ収集を標準化して分析活用する車載基盤」に責務を集中させやすい。
  • Azure Mobility と比べると、AWS IoT FleetWise は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
FleetWise, 車両データ, テレマティクス, フリート
AWS IoT Device Defender完全ガイド T7 ★★★★★☆☆☆☆☆(5.0) IoT導入を加速するデバイス連携基盤
  • IoTデバイスのセキュリティポリシー準拠を継続監査するか
  • 異常な接続・通信パターンをML検出するか
  • デバイス証明書・権限の不正利用を検知するか
  • IoT platform では要件を満たしきれず、IoT導入を加速するデバイス連携基盤 を重視して AWS IoT Device Defender を第一候補にする場合。
  • AWS IoT Device Defender を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • custom stack と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IoT platform
  • custom stack
  • IoT platform は汎用的な選択肢だが、AWS IoT Device Defender は「IoT導入を加速するデバイス連携基盤」に責務を集中させやすい。
  • custom stack と比べると、AWS IoT Device Defender は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS IoT Device Defender, IoT, デバイス, 運用
AWS IoT TwinMaker完全ガイド T7 ★★★★★☆☆☆☆☆(4.9) IoT導入を加速するデバイス連携基盤
  • 工場設備の3Dデジタルツインを構築するか
  • センサーデータと空間モデルで設備の仮想レプリカを作成するか
  • Grafanaでデジタルツインをダッシュボード化するか
  • IoT platform では要件を満たしきれず、IoT導入を加速するデバイス連携基盤 を重視して AWS IoT TwinMaker を第一候補にする場合。
  • AWS IoT TwinMaker を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • custom stack と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IoT platform
  • custom stack
  • IoT platform は汎用的な選択肢だが、AWS IoT TwinMaker は「IoT導入を加速するデバイス連携基盤」に責務を集中させやすい。
  • custom stack と比べると、AWS IoT TwinMaker は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS IoT TwinMaker, IoT, デバイス, 運用
AWS IoT Events完全ガイド T7 ★★★★★☆☆☆☆☆(4.8) 設備イベントを状態遷移で判定する検知基盤
  • 複合条件検知が必要か
  • アラート誤検知を減らしたいか
  • 運用保守フローへ連携するか
  • custom CEP では要件を満たしきれず、設備イベントを状態遷移で判定する検知基盤 を重視して AWS IoT Events を第一候補にする場合。
  • AWS IoT Events を採用し、SNS と組み合わせて責任境界を明確にしたい場合。
  • Flink rules と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • custom CEP
  • Flink rules
  • custom CEP は汎用的な選択肢だが、AWS IoT Events は「設備イベントを状態遷移で判定する検知基盤」に責務を集中させやすい。
  • Flink rules と比べると、AWS IoT Events は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • SNS との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
IoT Events, 状態判定, 異常検知, 設備監視
AWS IoT Greengrass V1 ★★★★★☆☆☆☆☆(4.8) エッジ側で推論/処理を実行するデバイス実行基盤
  • オフライン処理が必要か
  • 現場側で低遅延制御するか
  • デバイス更新運用を回せるか
  • K3s edge では要件を満たしきれず、エッジ側で推論/処理を実行するデバイス実行基盤 を重視して AWS IoT Greengrass V1 を第一候補にする場合。
  • AWS IoT Greengrass V1 を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • Azure IoT Edge と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • K3s edge
  • Azure IoT Edge
  • K3s edge は汎用的な選択肢だが、AWS IoT Greengrass V1 は「エッジ側で推論/処理を実行するデバイス実行基盤」に責務を集中させやすい。
  • Azure IoT Edge と比べると、AWS IoT Greengrass V1 は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Greengrass, エッジ処理, オフライン, 現場推論
AWS IoT Core完全ガイド T7 ★★★★★☆☆☆☆☆(4.7) デバイス接続とメッセージ中継を担うIoT中核基盤
  • 接続デバイス数が多いか
  • 証明書運用を継続できるか
  • 双方向制御が必要か
  • Azure IoT Hub では要件を満たしきれず、デバイス接続とメッセージ中継を担うIoT中核基盤 を重視して AWS IoT Core を第一候補にする場合。
  • AWS IoT Core を採用し、Lambda と組み合わせて責任境界を明確にしたい場合。
  • EMQX と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Azure IoT Hub
  • EMQX
  • Azure IoT Hub は汎用的な選択肢だが、AWS IoT Core は「デバイス接続とメッセージ中継を担うIoT中核基盤」に責務を集中させやすい。
  • EMQX と比べると、AWS IoT Core は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Lambda との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
IoT Core, デバイス接続, MQTT, IoT中核
AWS IoT Greengrass V2完全ガイド T7 ★★★★★☆☆☆☆☆(4.7) エッジ側で推論/処理を実行するデバイス実行基盤
  • オフライン処理が必要か
  • 現場側で低遅延制御するか
  • デバイス更新運用を回せるか
  • K3s edge では要件を満たしきれず、エッジ側で推論/処理を実行するデバイス実行基盤 を重視して AWS IoT Greengrass V2 を第一候補にする場合。
  • AWS IoT Greengrass V2 を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • Azure IoT Edge と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • K3s edge
  • Azure IoT Edge
  • K3s edge は汎用的な選択肢だが、AWS IoT Greengrass V2 は「エッジ側で推論/処理を実行するデバイス実行基盤」に責務を集中させやすい。
  • Azure IoT Edge と比べると、AWS IoT Greengrass V2 は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Greengrass, エッジ処理, オフライン, 現場推論
AWS IoT SiteWise完全ガイド T7 ★★★★★☆☆☆☆☆(4.7) 産業設備データを資産モデルで可視化する基盤
  • 工場設備可視化が必要か
  • 資産モデル管理を継続するか
  • 現場KPIを標準化するか
  • Ignition では要件を満たしきれず、産業設備データを資産モデルで可視化する基盤 を重視して AWS IoT SiteWise を第一候補にする場合。
  • AWS IoT SiteWise を採用し、Greengrass と組み合わせて責任境界を明確にしたい場合。
  • PI System と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • Ignition
  • PI System
  • Ignition は汎用的な選択肢だが、AWS IoT SiteWise は「産業設備データを資産モデルで可視化する基盤」に責務を集中させやすい。
  • PI System と比べると、AWS IoT SiteWise は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • Greengrass との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SiteWise, 設備データ, 産業IoT, 資産モデル
AWS IoT Wireless 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(4.6) IoT導入を加速するデバイス連携基盤
  • LoRaWAN/Sidewalkの低消費電力ワイヤレスIoT接続か
  • 自己運用LoRaWANゲートウェイをAWSに接続するか
  • 農業・スマートシティのLPWA IoT基盤か
  • IoT platform では要件を満たしきれず、IoT導入を加速するデバイス連携基盤 を重視して AWS IoT Wireless を第一候補にする場合。
  • AWS IoT Wireless を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • custom stack と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IoT platform
  • custom stack
  • IoT platform は汎用的な選択肢だが、AWS IoT Wireless は「IoT導入を加速するデバイス連携基盤」に責務を集中させやすい。
  • custom stack と比べると、AWS IoT Wireless は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS IoT Wireless, IoT, デバイス, 運用
FreeRTOS ★★★★☆☆☆☆☆☆(4.5) IoT導入を加速するデバイス連携基盤
  • マイコン/組み込みデバイス向けリアルタイムOSが必要か
  • IoT Coreへの安全接続ライブラリを小型デバイスに展開するか
  • メモリ制約の組み込みデバイスにAWS接続機能を追加するか
  • IoT platform では要件を満たしきれず、IoT導入を加速するデバイス連携基盤 を重視して FreeRTOS を第一候補にする場合。
  • FreeRTOS を採用し、IoT Core と組み合わせて責任境界を明確にしたい場合。
  • custom stack と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IoT platform
  • custom stack
  • IoT platform は汎用的な選択肢だが、FreeRTOS は「IoT導入を加速するデバイス連携基盤」に責務を集中させやすい。
  • custom stack と比べると、FreeRTOS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IoT Core との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
FreeRTOS, IoT, デバイス, 運用

Specialized & Industry (27)

サービス名 重要度(使用頻度) 1フレーズで本質 選定基準 利用シーン 比較対象 差別化ポイント 関連サービス キーワード 使用(類似)ライブラリ
MSK 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) 業界特化要件へ対応する専門ソリューション基盤
  • Kafkaクラスタをフルマネージドで運用するか
  • 既存KafkaアプリをAWSに移行するか
  • MSK ConnectでKafkaコネクタを統合するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して MSK を第一候補にする場合。
  • MSK を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、MSK は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、MSK は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
MSK, 業界特化, 専門基盤, 運用
ARC 🟤 完全ガイド T6 ★★★★★★☆☆☆☆(5.5) 業界特化要件へ対応する専門ソリューション基盤
  • マルチリージョンDRのフェイルオーバー経路を一元制御するか
  • 復旧準備態勢(Readiness Check)を継続評価するか
  • ゾナル・リージョナルシフトで障害影響をAZから逃すか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して ARC を第一候補にする場合。
  • ARC を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、ARC は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、ARC は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
ARC, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS App Studio 🟤 完全ガイド T6 ★★★★★★☆☆☆☆(5.5) 業界特化要件へ対応する専門ソリューション基盤
  • コードなしで業務アプリをGUIで構築するか
  • バックエンドAWSサービスをノーコードで接続するか
  • ITエンジニアなしで部門アプリを迅速に作成するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS App Studio を第一候補にする場合。
  • AWS App Studio を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS App Studio は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS App Studio は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS App Studio, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS FIS 🟣 完全ガイド T5 ★★★★★★☆☆☆☆(5.5) 業界特化要件へ対応する専門ソリューション基盤
  • 本番環境へのカオスエンジニアリング実験を管理するか
  • EC2/ECS/RDSへの障害インジェクションでレジリエンスを検証するか
  • 実験の安全ガード(停止条件)付きで障害試験するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS FIS を第一候補にする場合。
  • AWS FIS を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS FIS は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS FIS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS FIS, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
Managed Blockchain 🩶 完全ガイド T8 ★★★★★★☆☆☆☆(5.5) 業界特化要件へ対応する専門ソリューション基盤
  • HyperledgerFabricの許可型ブロックチェーンをマネージドで構築するか
  • 複数組織間でデータ改ざん不可の共有台帳が必要か
  • イーサリアムノードをインフラ管理なしで運用するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して Managed Blockchain を第一候補にする場合。
  • Managed Blockchain を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、Managed Blockchain は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、Managed Blockchain は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Managed Blockchain, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
Mechanical Turk 🩶 完全ガイド T8 ★★★★★★☆☆☆☆(5.5) 業界特化要件へ対応する専門ソリューション基盤
  • AIトレーニング用データのラベリングを人間のワーカーに委託するか
  • 大量の繰り返しタスクをクラウドソーシングで処理するか
  • SageMaker Ground Truthなしで柔軟なHITワークフローを設計するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して Mechanical Turk を第一候補にする場合。
  • Mechanical Turk を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、Mechanical Turk は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、Mechanical Turk は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Mechanical Turk, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
GameLift Servers 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(5.4) 業界特化要件へ対応する専門ソリューション基盤
  • マルチプレイヤーゲームのセッションサーバをAWS自動スケーリングで管理するか
  • ゲームサーバのマッチメイキングとセッション管理をAWS完結でするか
  • EC2/コンテナを使わず専用ゲームサーバフリートを管理するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して GameLift Servers を第一候補にする場合。
  • GameLift Servers を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、GameLift Servers は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、GameLift Servers は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
GameLift Servers, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
EVS 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(5.3) 業界特化要件へ対応する専門ソリューション基盤
  • VMware Cloud FoundationをEC2ベアメタル上でそのまま実行するか
  • vSphere/vSAN/NSX環境をクラウド移行しながらVMwareツールをそのまま使うか
  • VMwareライセンスを持ち込みEC2で自己管理するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して EVS を第一候補にする場合。
  • EVS を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、EVS は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、EVS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
EVS, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
GameLift Streams 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(5.3) 業界特化要件へ対応する専門ソリューション基盤
  • ゲームアプリをクラウドストリーミングでブラウザ/デバイスに配信するか
  • クライアント端末の処理能力に依存しないクラウドゲーミングか
  • ゲームのダウンロード不要でブラウザアクセスを実現するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して GameLift Streams を第一候補にする場合。
  • GameLift Streams を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、GameLift Streams は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、GameLift Streams は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
GameLift Streams, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
Compute Optimizer完全ガイド T7 ★★★★★☆☆☆☆☆(5.2) 業界特化要件へ対応する専門ソリューション基盤
  • EC2/Lambda/EBSのインスタンスサイズ最適化推奨をMLで受けるか
  • 過剰プロビジョニングを継続的に検出しコスト削減するか
  • Savings Plans/Reserved Instanceと組み合わせてコスト最適化するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して Compute Optimizer を第一候補にする場合。
  • Compute Optimizer を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、Compute Optimizer は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、Compute Optimizer は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Compute Optimizer, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
Location Service完全ガイド T7 ★★★★★☆☆☆☆☆(5.1) 業界特化要件へ対応する専門ソリューション基盤
  • アプリにマップ・ジオコーディング・ルーティングを組み込むか
  • デバイスの位置追跡とジオフェンスアラートが必要か
  • Google Maps/HERE Mapsの代替をAWS統合コストで利用するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して Location Service を第一候補にする場合。
  • Location Service を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、Location Service は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、Location Service は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Location Service, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS Ground Station完全ガイド T7 ★★★★★☆☆☆☆☆(5.1) 衛星通信地上局をクラウド利用する宇宙通信基盤
  • 衛星データ受信頻度が高いか
  • 地上局設備を自前保有しないか
  • 短期間運用が必要か
  • self ground station では要件を満たしきれず、衛星通信地上局をクラウド利用する宇宙通信基盤 を重視して AWS Ground Station を第一候補にする場合。
  • AWS Ground Station を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • KSAT と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • self ground station
  • KSAT
  • self ground station は汎用的な選択肢だが、AWS Ground Station は「衛星通信地上局をクラウド利用する宇宙通信基盤」に責務を集中させやすい。
  • KSAT と比べると、AWS Ground Station は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Ground Station, 衛星通信, 地上局, 宇宙データ
  • ドメイン特化SDKAPI
Incident Manager完全ガイド T7 ★★★★★☆☆☆☆☆(5.1) 業界特化要件へ対応する専門ソリューション基盤
  • AWSリソース障害時の対応ランブックを自動実行するか
  • オンコール通知・エスカレーション・ポストモーテムを一元管理するか
  • Systems Managerと連携したインシデント対応を自動化するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して Incident Manager を第一候補にする場合。
  • Incident Manager を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、Incident Manager は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、Incident Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Incident Manager, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AppFabric完全ガイド T7 ★★★★★☆☆☆☆☆(5.0) 業界特化要件へ対応する専門ソリューション基盤
  • 複数SaaSアプリのアクティビティログをASFF形式でSecurity Hubへ集約するか
  • SaaSアプリ横断のセキュリティ監査とコンプライアンスが必要か
  • SaaS間のユーザープロビジョニングをSCIM連携で自動化するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AppFabric を第一候補にする場合。
  • AppFabric を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AppFabric は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AppFabric は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AppFabric, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS re:Post Private 🔘 完全ガイド T9 ★★★★★☆☆☆☆☆(5.0) 業界特化要件へ対応する専門ソリューション基盤
  • 社内エンジニアのAWS技術Q&Aコミュニティをプライベートで構築するか
  • AWSエキスパートへの優先アクセスと回答品質保証が必要か
  • Q&Aナレッジベースを組織内に蓄積・管理するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS re:Post Private を第一候補にする場合。
  • AWS re:Post Private を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS re:Post Private は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS re:Post Private は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS re:Post Private, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
Data Lifecycle Manager 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.9) 業界特化要件へ対応する専門ソリューション基盤
  • EBSスナップショットのライフサイクルポリシーを自動化するか
  • 定期スナップショット取得・保持・削除をルールで管理するか
  • AWS Backupなしで軽量なEBSスナップショット自動化か
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して Data Lifecycle Manager を第一候補にする場合。
  • Data Lifecycle Manager を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、Data Lifecycle Manager は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、Data Lifecycle Manager は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Data Lifecycle Manager, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS Sign-In完全ガイド T7 ★★★★★☆☆☆☆☆(4.9) 業界特化要件へ対応する専門ソリューション基盤
  • AWSコンソールへのIAMユーザーサインインとMFA強制を管理するか
  • フェデレーテッドサインインとIAM Identity Center統合か
  • rootアカウントとIAMユーザーの認証ポリシーを設定するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS Sign-In を第一候補にする場合。
  • AWS Sign-In を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS Sign-In は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS Sign-In は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Sign-In, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS Transform 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.9) 業界特化要件へ対応する専門ソリューション基盤
  • .NETアプリをLinux/コンテナへAI支援で自動変換するか
  • メインフレーム/レガシーコードをAWS向けにAI変換するか
  • 手動改修最小化でコードベースをモダン化するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS Transform を第一候補にする場合。
  • AWS Transform を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS Transform は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS Transform は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Transform, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
SWF 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.8) 業界特化要件へ対応する専門ソリューション基盤
  • 既存SWFワークロードの継続稼働のみか
  • Step Functionsへの移行計画が必要か
  • 長時間実行(1年超)の外部タスク協調ワークフロー(レガシー)か
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して SWF を第一候補にする場合。
  • SWF を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、SWF は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、SWF は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
SWF, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS Cloud Map完全ガイド T7 ★★★★★☆☆☆☆☆(4.8) 業界特化要件へ対応する専門ソリューション基盤
  • マイクロサービスのサービスディスカバリーをDNS/APIで提供するか
  • ECS/EKSのサービス検出をRoute 53と連携するか
  • IPアドレス・ARN等のリソースを動的に名前解決するか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS Cloud Map を第一候補にする場合。
  • AWS Cloud Map を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS Cloud Map は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS Cloud Map は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Cloud Map, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS Deadline Cloud 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.8) 業界特化要件へ対応する専門ソリューション基盤
  • VFX/映像制作のレンダーファームをクラウドで管理するか
  • レンダリングジョブのキューと優先度管理をマネージドで実施するか
  • EC2スポットインスタンスを活用したコスト効率の高いレンダリングか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS Deadline Cloud を第一候補にする場合。
  • AWS Deadline Cloud を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS Deadline Cloud は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS Deadline Cloud は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS Deadline Cloud, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS TNB 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.8) 業界特化要件へ対応する専門ソリューション基盤
  • 5G/通信事業者のネットワーク機能(VNF/CNF)をAWSにデプロイするか
  • ETSI NFV標準のネットワークサービス記述子でインフラを管理するか
  • テレコムグレードのネットワーク機能オーケストレーションか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS TNB を第一候補にする場合。
  • AWS TNB を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS TNB は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS TNB は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS TNB, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS PCS 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.7) 業界特化要件へ対応する専門ソリューション基盤
  • SlurmベースのHPCクラスタをマネージドで構築するか
  • 気象・金融・バイオインフォマティクスのHPCワークロードをAWSで実行するか
  • EC2スポットインスタンスを活用した大規模バッチ計算か
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS PCS を第一候補にする場合。
  • AWS PCS を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS PCS は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS PCS は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS PCS, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
Cloud Directory完全ガイド T7 ★★★★★☆☆☆☆☆(4.7) 業界特化要件へ対応する専門ソリューション基盤
  • 組織・デバイス・ユーザーの階層データをマルチ軸で管理するか
  • IAMCognito User Poolsでは表現できない複雑な階層・グラフ構造か
  • 組織図・ネットワークトポロジー等の多次元ディレクトリデータか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して Cloud Directory を第一候補にする場合。
  • Cloud Directory を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、Cloud Directory は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、Cloud Directory は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Cloud Directory, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
AWS DeepRacer 🩶 完全ガイド T8 ★★★★★☆☆☆☆☆(4.6) 業界特化要件へ対応する専門ソリューション基盤
  • 強化学習アルゴリズムを物理/仮想レーシングカーで体験学習するか
  • 社内ML教育・ハッカソンの強化学習入門コンテンツか
  • DeepRacerリーグ参加と強化学習モデルのトレーニングか
  • industry SaaS では要件を満たしきれず、業界特化要件へ対応する専門ソリューション基盤 を重視して AWS DeepRacer を第一候補にする場合。
  • AWS DeepRacer を採用し、IAM と組み合わせて責任境界を明確にしたい場合。
  • custom domain platform と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • industry SaaS
  • custom domain platform
  • industry SaaS は汎用的な選択肢だが、AWS DeepRacer は「業界特化要件へ対応する専門ソリューション基盤」に責務を集中させやすい。
  • custom domain platform と比べると、AWS DeepRacer は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • IAM との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
AWS DeepRacer, 業界特化, 専門基盤, 運用
  • ドメイン特化SDKAPI
Braket 🩶 完全ガイド T8 ★★★★☆☆☆☆☆☆(4.4) 量子アルゴリズム実験を実行する量子開発基盤
  • 量子アルゴリズムを実機量子コンピュータで試験実行するか
  • クラシカルシミュレータで量子回路を事前検証するか
  • IonQ/Rigetti/Oxford等の複数量子ハードウェアを統一SDKで評価するか
  • IBM Quantum では要件を満たしきれず、量子アルゴリズム実験を実行する量子開発基盤 を重視して Braket を第一候補にする場合。
  • Braket を採用し、S3 と組み合わせて責任境界を明確にしたい場合。
  • Azure Quantum と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • IBM Quantum
  • Azure Quantum
  • IBM Quantum は汎用的な選択肢だが、Braket は「量子アルゴリズム実験を実行する量子開発基盤」に責務を集中させやすい。
  • Azure Quantum と比べると、Braket は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • S3 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
Braket, 量子計算, 研究, 実験
  • ドメイン特化SDKAPI
AWS RoboMaker 🩶 完全ガイド T8 ★★★★☆☆☆☆☆☆(3.7) ロボット開発・シミュレーションを支援するロボティクス基盤
  • ROSベースのロボットアプリをGazeboシミュレーションでテストするか
  • 仮想環境テストからIoT GreengrassでのEdgeデプロイを自動化するか
  • フリートのロボットデバイスをクラウドから遠隔管理するか
  • ROS tools では要件を満たしきれず、ロボット開発・シミュレーションを支援するロボティクス基盤 を重視して AWS RoboMaker を第一候補にする場合。
  • AWS RoboMaker を採用し、EC2 と組み合わせて責任境界を明確にしたい場合。
  • Gazebo only と比較して、運用手順を簡素化しやすい方を選定したい場合。
  • ROS tools
  • Gazebo only
  • ROS tools は汎用的な選択肢だが、AWS RoboMaker は「ロボット開発・シミュレーションを支援するロボティクス基盤」に責務を集中させやすい。
  • Gazebo only と比べると、AWS RoboMaker は運用設計(監視/障害対応/変更管理)の標準化を進めやすい。
  • EC2 との連携境界を先に固定することで、他の類似サービスより判断根拠を残しやすい。
RoboMaker, ロボット, シミュレーション, ROS
  • ドメイン特化SDKAPI