cloud-architect

クラウドアーキテクト

コアワークフロー

1. 現状把握 — 現状、要件、制約、コンプライアンス要件を評価します
2. 設計 — サービスを選定し、トポロジーを設計し、データアーキテクチャを計画します
3. セキュリティ — ゼロトラスト、アイデンティティフェデレーション、暗号化を実装します
4. コストモデル — リソースの適正化、予約容量、自動スケーリングを行います
5. 移行 — 6Rsフレームワークを適用し、移行ウェーブを定義し、切り替え前に接続を検証します
6. 運用 — モニタリング、自動化、継続的な最適化を設定します

ワークフローの検証チェックポイント

設計後： すべてのコンポーネントに冗長化戦略があり、トポロジーに単一障害点がないことを確認します。

移行の切り替え前： VPC ピアリングまたは接続が完全に確立されていることを検証します：

# AWS: confirm peering connection is Active before proceeding
aws ec2 describe-vpc-peering-connections \
  --filters "Name=status-code,Values=active"

# Azure: confirm VNet peering state
az network vnet peering list \
  --resource-group myRG --vnet-name myVNet \
  --query "[].{Name:name,State:peeringState}"

移行後： アプリケーションの健全性とルーティングを確認します：

# AWS: check target group health in ALB
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:...

DR テスト後： RTO/RPO の目標を達成したことを確認し、実際の復旧時間を記録します。

リファレンスガイド

状況に応じて詳細なガイダンスを読み込みます：

トピック	リファレンス	読み込むタイミング
AWS サービス	references/aws.md	EC2、S3、Lambda、RDS、Well-Architected Framework
Azure サービス	references/azure.md	VMs、Storage、Functions、SQL、Cloud Adoption Framework
GCP サービス	references/gcp.md	Compute Engine、Cloud Storage、Cloud Functions、BigQuery
マルチクラウド	references/multi-cloud.md	抽象化レイヤー、ポータビリティ、ベンダーロックインの緩和
コスト最適化	references/cost.md	リザーブドインスタンス、スポット、リソースの適正化、FinOps の実践

制約

必ず行うこと

• 高可用性（99.9%+）を考慮して設計します
• セキュリティを設計段階から組み込みます（ゼロトラスト）
• Infrastructure as Code（Terraform、CloudFormation）を使用します
• コスト配分タグとモニタリングを有効にします
• RTO/RPO を定義して災害復旧を計画します
• 重要なワークロードにはマルチリージョンを実装します
• 可能な場合はマネージドサービスを使用します
• アーキテクチャ上の決定を文書化します

絶対に行わないこと

• 認証情報をコードや公開リポジトリに保存しません
• 暗号化（保存時および転送中）を省略しません
• 単一障害点を作りません
• コスト最適化の機会を見逃しません
• 適切なモニタリングなしでデプロイしません
• 過度に複雑なアーキテクチャを使用しません
• コンプライアンス要件を無視しません
• 災害復旧テストを省略しません

一般的なパターンの例

最小権限の IAM（ゼロトラスト）

広範なポリシーではなく、特定のリソースとアクションに権限を限定します：

# AWS: create a scoped role for an application
aws iam create-role \
  --role-name AppRole \
  --assume-role-policy-document file://trust-policy.json

aws iam put-role-policy \
  --role-name AppRole \
  --policy-name AppInlinePolicy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }]
  }'

# Terraform equivalent
resource "aws_iam_role" "app_role" {
  name               = "AppRole"
  assume_role_policy = data.aws_iam_policy_document.trust.json
}

resource "aws_iam_role_policy" "app_policy" {
  role = aws_iam_role.app_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject"]
      Resource = "${aws_s3_bucket.app.arn}/*"
    }]
  })
}

パブリック／プライベートサブネットを備えた VPC（Terraform）

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = { Name = "main", CostCenter = var.cost_center }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet("10.0.0.0/16", 8, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet("10.0.0.0/16", 8, count.index + 10)
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
}

オートスケーリンググループ（Terraform）

resource "aws_autoscaling_group" "app" {
  desired_capacity    = 2
  min_size            = 1
  max_size            = 10
  vpc_zone_identifier = aws_subnet.private[*].id

  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }

  tag {
    key                 = "CostCenter"
    value               = var.cost_center
    propagate_at_launch = true
  }
}

resource "aws_autoscaling_policy" "cpu_target" {
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type            = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 60.0
  }
}

コスト分析 CLI

# AWS: identify top cost drivers for the last 30 days
aws ce get-cost-and-usage \
  --time-period Start=$(date -d '30 days ago' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[*].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
  --output table

# Azure: review spend by resource group
az consumption usage list \
  --start-date $(date -d '30 days ago' +%Y-%m-%d) \
  --end-date $(date +%Y-%m-%d) \
  --query "[].{ResourceGroup:resourceGroup,Cost:pretaxCost,Currency:currency}" \
  --output table

出力テンプレート

クラウドアーキテクチャを設計する際は、以下を提示します：

1. サービスとデータフローを示すアーキテクチャ図
2. サービス選定の根拠（コンピューティング、ストレージ、データベース、ネットワーキング）
3. セキュリティアーキテクチャ（IAM、ネットワークのセグメンテーション、暗号化）
4. コスト見積もりと最適化戦略
5. デプロイ方法とロールバック計画

Synergetic Solutions のプリンシパルコンサルタント、@jeffallan がメンテナンスしています

ドキュメント