@gyute

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

March 27, 2025

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

Simple Storage Service(S3)

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)

* スタック(Stacks)

  • ↪︎ CloudFormation templateによって生成されたAWS resources[3](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
  • ↪︎ 既に存在するCloudFormation templateを更新する際に変更内容を確認(差分確認など)できる
  • ↪︎ 確認後, execute-change-setコマンドで実行可能
  • ↪︎ terraform planと似ている

* Reference

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


Systems Manager(SSM)

* SSM Agent

* Documents

* Session Manager

* Run Command

* Parameter Store

* Patch Manager

  • ↪︎ インスタンス,OSのパッチを自動化できる
  • ↪︎ コンプライアンスレポーティング(Compliance reporting)
    • ↪︎ Maintenance WindowsのScan or Installタスクによりターゲットで指定されたノードのPatch baselineを確認
    • ↪︎ csv形式のパッチコンプライアンスレポートをS3 bucketに出力可能
    • ↪︎ レポートは1回のみでも,定期的にでも出力可能
    • ↪︎ レポートはQuickSightなどで分析可能
  • ↪︎ ex) 全てのインスタンスはリリースから3日が経ったパッチだけをインストールしたい

* 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はデプロイ成功    		 ⏳⏳[4] 🟢 🟢 手動redeploy 既存インスタンス
    Rolling
    with an additional batch    		 - 最初のBatch失敗時に最小化
    - そうでなければRollingと類似    		 ⏳⏳⏳[4] 🟢 🟢 手動redeploy 既存 + 新規インスタンス
    Immutable 最小限 ⏳⏳⏳⏳ 🟢 🟢 新規インスタンス終了 新規インスタンス
    Traffic splitting 新規インスタンスに向かう
    指定の比率のトラフィックに影響    		 ⏳⏳⏳⏳[5] 🟢 🟢 トラフィック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: AWS resource and property types referencereturn ↩

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

4: Batchサイズによるreturn ↩

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