@gyute

[WIP] AWS DevOpsサービス簡略概要

February 06, 2026

AWS DOP

Of the DOP, By the DOP, For the DOP

AWSのDevOpsサービスを理解するために、DOP試験で扱われる6つのドメインをざっくりまとめてみたいと思う。

未入力状態のサービスも今後追加していきたい。

  • 1. SDLC自動化[go]

  • 2. IaC[go]

  • 3. Cloud solution[go]

  • 4. Monitoring & Logging[go]

  • 5. Incident & Event[go]

  • 6. Security & Compliance[go]


1. SDLC[1]自動化return ↩

CodeBuild

アーキテクチャ AWS CodeBuild

* buildspec.ymlを用いる

* ビルドの情報はCodeBuild(要約)やCloudWatch Logs(詳細)に転送される

* CodePipelineを使ってのビルドの場合はCodePipelineで制限されたビルド情報を確認できる

* ビルドのソースはGitHub, S3などから取得できる

* 連携: CodeDeploy, S3, CloudWatch, IAM, Secrets Manager, SSM, etc.


CodeDeploy

* appspec.ymlを用いる

  • ↪︎ BeforeInstall, AfterInstall, ApplicationStart, ApplicationStop hooksが存在

* EC2/On-premises(オンプレミス), ECS, Lambdaにデプロイ可能

  • ↪︎ EC2/On-premises

    • ↪︎ EC2/On-premisesにデプロイする場合はCodeDeploy Agentが必要

    • ↪︎ デプロイ設定(In-place, Blue/green)

      項目 Note
      CodeDeployDefault.
      AllAtOnce      		 - In-place: 同時に全部デプロイ
       ↪︎ ex) 9つのインスタンスデプロイ時1つでも成功すればデプロイ成功, すべて失敗すればデプロイ失敗
      - Blue/green:
       ↪︎ Deployment to replacement environment: in-placeと同じ
       ↪︎ Traffic rerouting: トラフィックが少なくとも一つのインスタンスにrerouting成功したら成功, 全てが失敗したら失敗
      CodeDeployDefault.
      HalfAtATime      		 - In-place: 同時に最大で50%のインスタンスをデプロイ(切り捨て)
       ↪︎ ex) 9つのインスタンスデプロイ時1回で最大4つ(切り捨て)のインスタンスをデプロイ. 5つ以上のインスタンスデプロイに成功すれば成功 or 失敗
      NoteMultiple ASG環境でのデプロイ時CodeDeployはインスタンスが所属しているASGに関係なく同じく50%のデプロイをする
       ↪︎ ex)それぞれ10個のインスタンスを持つ2つのASGのASG1, ASG2がある時, CodeDeployはASG1の10個を1回目でデプロイする可能性があり, このデプロイの成功で50%に達したため成功と見なされる可能性がある
      - Blue/green:
       ↪︎ Deployment to replacement environment: in-placeと同じ
       ↪︎ Traffic rerouting: インスタンスの最大50%のトラフィックをroutingし, 最低で50%のreroutingに成功すれば成功 or 失敗
      CodeDeployDefault.
      OneAtATime      		 - In-place: 一度に1つのインスタンスをデプロイするが例外あり
       ↪︎ ex) 9つのインスタンスデプロイ時に一度に1つのインスタンスをデプロイするが, 最後の1つのインスタンスデプロイは失敗しても成功となる. 最後のインスタンスを除いては1つでも失敗したら失敗となる
        ↪︎ 1度に1つのインスタンスのみオフラインになるため
       ↪︎ ex) 1つのインスタンスの場合は1つのインスタンスデプロイ成功時, 成功
      - Blue/green:
       ↪︎ Deployment to replacement environment: in-placeと同じ
       ↪︎ Traffic rerouting: 新しい環境のインスタンス1つにトラフィックを1回ずつreroutingし, 全てのトラフィックがreroutingされると成功, 例外に最後のインスタンスは失敗しても成功となる(In-place同様)

  • ↪︎ ECS

    • ↪︎ デプロイ設定(Blue/green)
      項目 Note
      CodeDeployDefault.
      ECSLinear
      10PercentEvery1Minutes      		 1分に10%ずつシフト
      CodeDeployDefault.
      ECSLinear
      10PercentEvery3Minutes      		 3分に10%ずつシフト
      CodeDeployDefault.
      ECSCanary
      10Percent5Minutes      		 はじめに10%をシフトし, 5分後に残りの90%をシフ
      CodeDeployDefault.
      ECSCanary
      10Percent15Minutes      		 はじめに10%をシフトし, 15分後に残りの90%をシフト
      CodeDeployDefault.
      ECSAllAtOnce      		 トラファックを一気に新しいECS containerにシフト
      (ALB, NLB)
      NoteNetwork Load Balancer使用時はCodeDeployDefault.ECSAllAtOnceのみ使用可能

  • ↪︎ Lambda

    • ↪︎ デプロイ設定(Blue/green)
      項目 Note
      CodeDeployDefault.
      LambdaLinear
      10PercentEvery1Minute      		 1分に10%ずつシフト
      CodeDeployDefault.
      LambdaLinear
      10PercentEvery2Minutes      		 2分に10%ずつシフト
      CodeDeployDefault.
      LambdaLinear
      10PercentEvery3Minutes      		 3分に10%ずつシフト
      CodeDeployDefault.
      LambdaLinear
      10PercentEvery10Minutes      		 10分に10%ずつシフト
      CodeDeployDefault.
      LambdaCanary
      10Percent5Minutes      		 はじめに10%をシフトし, 5分後に残りの90%をシフト
      CodeDeployDefault.
      LambdaCanary
      10Percent10Minutes      		 はじめに10%をシフトし, 10分後に残りの90%をシフト
      CodeDeployDefault.
      LambdaCanary
      10Percent15Minutes      		 はじめに10%をシフトし, 15分後に残りの90%をシフト
      CodeDeployDefault.
      LambdaCanary
      10Percent30Minutes      		 はじめに10%をシフトし, 30分後に残りの90%をシフト
      CodeDeployDefault.
      LambdaAllAtOnce      		 トラファックを一気に新しいLambda functionsにシフト

* CloudWatch(Alarms, Logs, Events(→ EventBridge)), CloudTrail(Log Monitoring), SNSでモニタリング可能

* 簡略まとめ

  • In-place Blue/green Canary
    Downtime 大 中 ~ 少 無(設定による)
    Rollback 難 速 速
    Deploy Spped 速 速(設定による) 遅

CodeCommit

* 公式的な新規使用は2024.07.25に停止されてあるが,まだ既存顧客は使用可能(2025.03.27基準)

* CodeCommitと言うサービス名から,Git基盤のAWS Fully Managedサービスであるコト,コードのSourceとして使われる機能であることは熟知する必要あり


Elastic Compute Cloud(EC2)

* User data

  • ↪︎ CLIもしくは他のAWS serviceから使う場合はBase64 encodingが必要[2]
  • ↪︎ terraformのprovisionerと似ている

Elastic Container Service(ECS)

* ECS task definitionのイメージはECR, Docker hubの他にもプライベートレポジトリから取得可能


EC2 Image Builder

* AMI(Amazon Machine Image)及びContainer imageの作成

  • ↪︎ AMI → EC2 / ECR → Fargate

  • ↪︎ AMIはRegionに従属[3]されるため、Region間の移動にはコピーが必要

* 社内セキュリティ設定やパッチ(Security & Compliance)を含めたイメージの作成を自動化できる

* Concepts

  • * Image pipeline

  • * Recipe (Image / Container)

    • ↪︎ Image BuilderのImage typeセクションで選択するもので,どのImageにどのComponentを適用するかを定義

  • * Component

    • ↪︎ イメージ作成に必要なビルドやテスト段階で実行するタスク(コマンド)などを記述するスクリプト(sample)

    • ↪︎ parametersの定義も可能

* CloudFormation, CDKなどでも使用可能(sample)


Simple Storage Service(S3)

* S3はCloud Object Storageであり、ユニークなkey-valueで保存する


S3 Glacier

Elastic Container Registry(ECR)

Elastic Kubernetes Service(EKS)

Lambda

Elastic File System(EFS)

Elastic Block Store(EBS)

Identity and Access Management(IAM)

CodeArtifact

CodePipeline

CodeGuru

Command Line Interface(CLI)

CodeStar

Software Development Kit(SDK)


2. IaCreturn ↩

CloudFormation(CFN)

ダイアグラム AWS CloudFormation

* テンプレート(Templates)

  • ↪︎ CloudFormationがAWS resourcesを生成するために参照するblueprint
  • ↪︎ YAML or JSON形式で、.yaml, .json, .template, .txt拡張子で使用可能
  • ↪︎ CloudFormation consoleでも作成可能
  • ↪︎ Parameters
    • ↪︎ Typeが存在
  • ↪︎ その他のsectionについてはリンク参照

* スタック(Stacks)

  • ↪︎ CloudFormation templateによって生成されたAWS resources[4](EC2, S3, RDSなどの)の集合
  • ↪︎ 環境を手動ではなく, コード(Infrastructure as Code, IaC)で管理することで自動化および再利用が容易になる
  • ↪︎ スタック変更失敗時のためのオプションは, Retry, Update, Roll backがある
  • ↪︎ Stack Instance
    • ↪︎ StackSetのStackを参照(reference)する概念
      • ↪︎ Stack InstanceがあるからといってStackが必ず存在するわけではない

* 変更セット(Change sets)

ダイアグラム AWS CloudFormation Change Set

* Reference

* 連携: Service Catalog, S3, CloudWatch, IAM, Secrets Manager, SSM, etc.


Systems Manager(SSM)

* SSM Agent

* Documents

  • ↪︎ JSON, YAML形式のテンプレートで,SSMを使って行える作業を文書化(標準化)できる
  • ↪︎ AppConfig, Automation runbook(Automation, State Manager, Maintenance Windows), CloudFormation templateなどを使用可能
  • ↪︎ AWSが公式でメンテナンスするDocumentが豊富
    • ↪︎ AWS-ConfigureWindowsUpdate, AWS-RunPatchBaseline, AWS-StartInteractiveCommandなど
  • ↪︎ 出題ポイントとは違うと思うが, CDKを使って定義 & デプロイも可能

* Session Manager

* Run Command

* Parameter Store

  • ↪︎ アプリケーションの構成データ,シークレット情報などを階層構造で保存できる
  • ↪︎ KMSサポート
  • ↪︎ バージョン管理可能
  • ↪︎ Parameter Policiesを使うためにはAdvanced tierが必要
    • ↪︎ Expiration, ExpirationNotification, NoChangeNotification
  • ↪︎ Secrets Managerと使い分ける
  • 条件 オススメサービス
    シークレットの自動ローテーション Secrets Manager
    コストを抑えたい Parameter Storea(Standard)
    単純な設定値だけどセキュリティが必要 Parameter Store SecureString
    CI/CD pipelineで敏感な構成を注入したい 両方とも可能

* Patch Manager

* State Manager

* Inventory

* AppConfig


Serverless Application Model(SAM)

* template.ymlを用いる

  • ↪︎ テンプレートで簡単にAWS resource(Lambda, API Gateway, etc.)を定義できる

* CloudFormation基盤なのでStack関連機能を使える

* sam localを使ってローカル環境で開発できる

  • Demo AWS SAM local

* sam syncをCloudFormation Stackを全部redeployせず変更があったresourceだけアップデートできる(sam deployとの違い)

  • Demo AWS SAM sync

Cloud Development Kit(CDK)

Concept AWS CDK concepts

↪︎ App / Stack(s) / Construct構造

* Programming language(TypeScript, JavaScript, Python, Java, C#, Go)で作成したコードがCloudFormaitonテンプレートに変換


Secrets Manager

* SSM Parameter Storeと使い分ける


Service Catalog

User Workflow AWS Service Catalog

* 組織内で承認されたリソースを標準化してデプロイ可能

  • ↪︎ 意図しない変更によるセキュリティ問題,開発者(ユーザー)のAWSへの負荷を軽減でき,コスト管理が用意になる

* Products

  • ↪︎ デプロイされるAWS Resource
  • ↪︎ CloudFormation Templateのこと

* Provisioned Products

  • ↪︎ Service Catalogを使ってデプロイされたProducts
  • ↪︎ CloudFormation Stackのこと

* Portfolios

  • ↪︎ Productsの集合(collection)
  • ↪︎ 他のAWSアカウントにも提供可能

* Permissions

  • ↪︎ IAMを使ってユーザーのPortfolioへのアクセスを制御可能

* Constraints

  • Constraint Note
    Launch constraints IAM権限など
    Notification constraints AWS SNS topicを使ってStack eventsの管理
    Template constraints CFN templateへのカスタマイズを提供

Step Functions

* 分散アプリケーションの各段階をビジュアル化(visualize),プロセスの自動化,マイクロサービスのオーケストレーションするワークフロー(Workflows/State machines)を提供

  • Visualization example AWS Step Functions example

* Use cases

  • ユースケース図 AWS Step Functions use cases

* Workflows types比較

  • Standard Express
    実行時間 最大1年 最大5分
    実行速度 1秒に2,000回 1秒に100,000回
    実行保証 1回(Exactly-once) 最低1回(At-least-once)
    実行履歴 Step Functionsで確認可能 CloudWatch Logsから確認可能
    コスト 状態遷移数(state transition) 実行時間 + 回数
    • ↪︎ 長期ワークフロー → Standard
    • ↪︎ 高速処理/大容量イベント → Express

Elastic Beanstalk(EB)

* Application

  • ↪︎ Elastic Beanstalkのcomponentsを論理的に集めた(a logical collection)もの
  • ↪︎ Environments, Versions, and Environment configurationsを含む
  • ↪︎ Elastic BeanstalkでApplicationは概念的にフォルダーのようなもの

* Application version

  • ↪︎ 特定バージョンのラベルがついてデプロイ可能なアプリケーションのコード
  • ↪︎ 実際はコード入っているS3 objectを指す

* Environment

  • ↪︎ Application versionを実行するAWS resourceの集合
  • ↪︎ Environmentを生成するとElastic Beanstalkは指定されたバージョンのアプリケーションが実行できるAWS resourceを自動でprovisioning

* Environment tier

* Environment configuration

  • ↪︎ 環境及びリソースを構成するパラメータと設定の集合
  • ↪︎ Environment Configurationを変更するとElastic Beanstalkが自動で反映

* Saved configuration

  • ↪︎ ユニークな環境構成のためのテンプレート
  • ↪︎ API及びAWS CLIでは保存された構成をconfiguration templatesと呼ぶ

* Platform

  • ↪︎ PlatformはOS, programming language runtime, web server, application server, そしてElastic Beanstalk componentsを合わせた概念

* デプロイ設定

  • Policy Note
    All at once - 新しいバージョンを全てのインスタンスに同時にデプロイ
    - デプロイ中に環境の全てのインスタンスがサービスから除外される(downtime)
    Rolling - 新しいバージョンがBatch(グループのような概念)に別れてデプロイ
    - 各Batchごとにサービスから除外されるためデプロイ中にはBatchのインスタンス分処理量が減ることになる
    Rolling
    with additional batch    		 - 新しいバージョンがBatch(グループのような概念)に別れてデプロイされるが, デプロイ前にまず追加の新しいBatchを始めてデプロイ中にも処理量が維持される
    Immutable - Immutable updateにより新しいインスタンスをデプロイ後切り替える
    Traffic splitting - 新しいバージョンを新しい環境にデプロイ後, トラフィックを指定に比率で分配

* デプロイ比較

  • Method デプロイ失敗による影響 デプロイ所要時間 Zero downtime DNS変更 Rollback方法 デプロイ先
    All at once Downtime発生 ⏳ ❌ 🟢 手動redeploy 既存インスタンス
    Rolling - 1つのBatch分サービスから除外
    - 失敗前のBatchはデプロイ成功    		 ⏳⏳[5] 🟢 🟢 手動redeploy 既存インスタンス
    Rolling
    with an additional batch    		 - 最初のBatch失敗時に最小化
    - そうでなければRollingと類似    		 ⏳⏳⏳[5] 🟢 🟢 手動redeploy 既存 + 新規インスタンス
    Immutable 最小限 ⏳⏳⏳⏳ 🟢 🟢 新規インスタンス終了 新規インスタンス
    Traffic splitting 新規インスタンスに向かう
    指定の比率のトラフィックに影響    		 ⏳⏳⏳⏳[6] 🟢 🟢 トラフィックRerouting + 新規インスタンス終了 新規インスタンス
    Blue/green 最小限 ⏳⏳⏳⏳ 🟢 ❌ URL変更 新規インスタンス

* 簡略まとめ

  • ↪︎ Blue/greenは他の方式と違って2つの環境を運用することになるためDNSの変更(CNAME Swap)が発生し,別途Route 53を設定しない限りBlue(old)からGreen(new)へ一気に切り替わる
  • ↪︎ Traffic splittingはALB(EC2, ECS, EB), API Gateway Canary(Serverless)を使ってトラフィックを分配し,段階的に移行できる
    • ↪︎ ex) Stage 1(90%/10%) → Stage 2(50%/50%) → Stage 3(0%/100%)

Config

Organizations

SCP

Control Tower


3. Cloud solutionreturn ↩

API Gateway

* REST/HTTP/WebSocket APIを生成,デプロイ,管理できる

* Fully ManagedサービスであるためIAMやCognitoなどのAWS認証サービスとも統合可能(Authorization/Authentication)

* CI/CD統合やバージョン管理可能


DynamoDB

Relational Database Service(RDS)

Aurora

Redshift

Route 53

CloudFront

Fargate

Load Balancers(ALB, NLB, CLB)

Elastic Disaster Recovery(DRS)

Athena


4. Monitoring & Loggingreturn ↩

CloudWatch

CloudTrail

KMS

Kinesis Data Firehose

Kinesis Data Streams

OpenSearch Service

Inspector

QuickSight

X-Ray

Simple Notification Service(SNS)

Auto Scaling groups(ASG)


5. Incident & Eventreturn ↩

EventBridge

Health

Simple Queue Service(SQS)

Auto Scaling


6. Security & Compliancereturn ↩

Cognito

VPC

Multi-Factor Authentication(MFA)

Security Token Service(STS)

Access control list(ACL)

Network Firewall

Web Application Firewall(WAF)

Shield

Security Hub

Detective

Directory Service

Macie

Certificate Manager(ACM)

GuardDuty

Trusted Advisor

1: Systems development life cycle, SDLC(ソフトウェア開発ライフサイクル)とは何ですか?return ↩

2: ref.1: Base64 encoding, ref.2: Base64 encoded UserData propertyreturn ↩

3: AMIs are Region-specific resources—to launch an instance in a specific AWS Region, the AMI must be located in that Region.return ↩

4: AWS resource and property types referencereturn ↩

  • service-provider::service-name::data-type-name

5: Batchサイズによるreturn ↩

6: evaluation timeオプションによるreturn ↩