🧱
＜ウェビナー参加＞AWS Partner: Well-Architected Best Practices

2025/12/03に公開
 目的設計思想など基礎的な内容だったので、基本を抑えたいとの思いから今年の夏に参加

 所感すごくよかった！
座学4、ハンズオン6
ハンズオンはアンチパターン構成のものをWell-Architectedの構成にする
座学内容は当たり前のことを言っているが、普段何気なくやっていることが、なぜこうすべきかの言語化がされていて参加して良かった。わざわざ言語化してくれるのがセミナー参加の意義だと感じた。
ハンズオン割合が多かったので身についた感がある。
今回の講義の発展版として、Advanced AWS Well-Architected Best Practicesの講義があって、ケーススタディの少人数制のディスカッション方式らしい。当講義を受けないと参加できないらしい。参加してみたい
特にラボ４が良かった。CloudWatchダッシュボード作成した時ちょっと感動した。
細い設定をしていると、何をしているのかわからなくなり迷子になりがち
何の為の設定か。今どこにいるのか。設定前に書き出すこと

ハンズオンにて、最初に確認すべきことは、アプリケーションは何か、それをどうしたいのか
今回は以下のような記録アプリ。これを、タグつけたり、DB作ったり、Cloudwatch、CloudtrailつけてAPI記録したり、、、、

ラボ１運用
> **目標**
このラボでは、2 つの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで構成される AWS リソースグループを作成し、AWS Systems Manager の「Run command」機能を使用して、ログを収集したり追加のメトリクスを取得したりするための Amazon CloudWatch エージェントをインストールします。

このラボでは、次のタスクを実行します。
> 
> - Amazon EC2 インスタンスにカスタムタグを追加する
> - 特定の Amazon EC2 インスタンス用の AWS リソースグループを作成する
> - Amazon EC2 インスタンスの設定には AWS Systems Manager を使用する
> - AWS Systems Manager Run command で Amazon CloudWatch エージェントをインストールする
> - Amazon CloudWatch で Amazon EC2 インスタンスのカスタムメトリクスとロググループを検証する

やったこと：RGでグループ化して、IAMで権限付与して、SSMを使って、Cloudwatchを入れて、アプリ動かして、ログを見た

- SSM便利、agentがEC2に既に入ってるのが便利。もっと多様な使い方があるので使ってみたい
- IAMは必ず出る。EC2にagent動いて良い権限付与。うまくいかない時だいたいIAMが原因な気がする
- ResouceGroupは使ったことなかった。タグのまとめてつけれる版？みたいな
- ログの見方をもっと学びたい。今回は4つ（db_general_query_log、httpd_access_log、mariadb_log、messages）出たが、なんとなくアクセスログが一番大事そう
- SSMagent使って、CloudWatch Agentをインストールした際は、インスタンス再起動した。再起動あるなしは覚えといた方がいいかも
- でもこれら全てハンズオンするのは、正直手間。terraformをもっと有効活用したい

ラボ２信頼
> **目標**
> 
> 
> このハンズオンラボでは、クラウドインフラストラクチャのデプロイを自動化することで、サービスの信頼性を向上させるステップを順にご紹介していきます。2 つ目のアベイラビリティーゾーン、Elastic Load Balancing (ELB)、ウェブアプリケーションの Auto Scaling グループに追加のサブネットを作成し、**水平方向にスケールして総合的なワークロードの可用性を向上させる** Well-Architected フレームワークの設計原則を適用します。また、データベースを RDS に移行し、マルチ AZ のデプロイを可能にします。アーキテクチャの準備ができたら、耐障害性が実装されたことを確認するテストを行い、**復旧手順をテストする**という設計原則を適用します。
> 
> このラボを修了すると、以下のことができるようになります。
> 
> - 既存のアーキテクチャを 2 つ目のアベイラビリティーゾーンに拡張する
> - アベイラビリティーゾーンにサブネットを追加する
> - マルチ AZ を使用した Amazon RDS をデプロイする
> - AWS Systems Manager Parameter Store でデータベースの認証情報を更新する
> - Application Load Balancer とターゲットグループを作成する
> - Systems Manager の Run Command を使用してデータベースを移行する
> - 起動テンプレートを作成する
> - Auto Scaling グループを作成する
> - Route 53 ヘルスチェックを作成する
> - アプリケーションの信頼性テストを実行する

- EC2をRDSへ切り替え
- ラボ2タスク5：ラジオボタンでの選択と、リンクの選択では操作が違う
    - 正確に操作すべし
- 全てCLIで実行。わかりにくいがざっくり何をしているコマンドかを理解したい
- 入力したコマンド
    
    １、2つ目のAZにサブネットを作成　環境変数とか
    
    ```
        sudo yum install gettext -y
        Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
        Package gettext-0.19.8.1-3.amzn2.x86_64 already installed and latest version
        Nothing to do
        export awsAccount=`aws sts get-caller-identity --query "Account" --output text` && echo awsAccount=$awsAccount >> ~/.bashrc
        export awsRegion=`curl -s http://169.254.169.254/latest/meta-data/placement/region` && echo awsRegion=$awsRegion >> ~/.bashrc
        export VPC=`aws ec2 describe-vpcs --filters Name=tag:Name,Values=wa-lab-vpc --query 'Vpcs[*].VpcId' --output text --region $awsRegion` && echo VPC=$VPC >> ~/.bashrc
        export awsAZ1=`aws ec2 describe-availability-zones --region $awsRegion --query 'AvailabilityZones[].ZoneName[]|[0]' --output text` && echo awsAZ1=$awsAZ1 >> ~/.bashrc
        export awsAZ2=`aws ec2 describe-availability-zones --region $awsRegion --query 'AvailabilityZones[].ZoneName[]|[1]' --output text` && echo awsAZ2=$awsAZ2 >> ~/.bashrc
        aws ec2 create-subnet --vpc-id $VPC --cidr-block "10.100.2.0/24" --availability-zone $awsAZ2 --tag-specifications 'ResourceType=subnet, Tags=[{Key=Name,Value=wa-public-subnet-2}]' --region $awsRegion
        aws ec2 create-subnet --vpc-id $VPC --cidr-block "10.100.3.0/24" --availability-zone $awsAZ2 --tag-specifications 'ResourceType=subnet, Tags=[{Key=Name,Value=wa-private-subnet-2}]' --region $awsRegion
        export publicSubnetId=`aws ec2 describe-subnets --filters Name=tag:Name,Values=wa-public-subnet-2 --query 'Subnets[*].SubnetId' --output text --region $awsRegion` && echo publicSubnetId=$publicSubnetId >> ~/.bashrc
        export privateSubnetId=`aws ec2 describe-subnets --filters Name=tag:Name,Values=wa-private-subnet-2 --query 'Subnets[*].SubnetId' --output text --region $awsRegion` && echo privateSubnetId=$privateSubnetId >> ~/.bashrc
        export publicRt=`aws ec2 describe-route-tables --filters Name=tag:Name,Values=wa-public-rt --query 'RouteTables[*].RouteTableId' --output text --region $awsRegion` && echo publicRt=$publicRt >> ~/.bashrc
        export privateRt=`aws ec2 describe-route-tables --filters Name=tag:Name,Values=wa-private-rt --query 'RouteTables[*].RouteTableId' --output text --region $awsRegion` && echo privateRt=$privateRt >> ~/.bashrc
        aws ec2 associate-route-table --subnet-id $publicSubnetId --route-table-id $publicRt --region $awsRegion
        aws ec2 associate-route-table --subnet-id $privateSubnetId --route-table-id $privateRt --region $awsRegion
    ```
    
    ２、マルチ AZ を使用して Amazon RDS をデプロイする
    
    ```
    aws ec2 create-subnet --vpc-id $VPC --cidr-block "10.100.4.0/24" --availability-zone $awsAZ1 --tag-specifications 'ResourceType=subnet, Tags=[{Key=Name,Value=wa-rds-subnet-1}]' --region $awsRegion
    aws ec2 create-subnet --vpc-id $VPC --cidr-block "10.100.5.0/24" --availability-zone $awsAZ2 --tag-specifications 'ResourceType=subnet, Tags=[{Key=Name,Value=wa-rds-subnet-2}]' --region $awsRegion
    export rdsSubnet1Id=aws ec2 describe-subnets --filters Name=tag:Name,Values=wa-rds-subnet-1 --query 'Subnets[*].SubnetId' --output text --region $awsRegion && echo rdsSubnet1Id=$rdsSubnet1Id >> ~/.bashrc
    export rdsSubnet2Id=aws ec2 describe-subnets --filters Name=tag:Name,Values=wa-rds-subnet-2 --query 'Subnets[*].SubnetId' --output text --region $awsRegion && echo rdsSubnet2Id=$rdsSubnet2Id >> ~/.bashrc
    aws ec2 associate-route-table --subnet-id $rdsSubnet1Id --route-table-id $privateRt --region $awsRegion
    aws ec2 associate-route-table --subnet-id $rdsSubnet2Id --route-table-id $privateRt --region $awsRegion
    aws rds create-db-subnet-group --db-subnet-group-name "wa-rds-subnet-group" --db-subnet-group-description "WA RDS Subnet Group" --subnet-ids $rdsSubnet1Id $rdsSubnet2Id --region $awsRegion
    aws ec2 create-security-group --description "RDS Security group" --group-name "wa-rds-sg" --vpc-id $VPC --region $awsRegion
    export rdsSg=aws ec2 describe-security-groups --filters Name=group-name,Values=wa-rds-sg --query 'SecurityGroups[*].GroupId' --output text --region $awsRegion && echo rdsSg=$rdsSg >> ~/.bashrc
    export ec2DbSg=aws ec2 describe-security-groups --filters Name=group-name,Values=wa-database-sg --query 'SecurityGroups[*].GroupId' --output text --region $awsRegion && echo ec2DbSg=$ec2DbSg >> ~/.bashrc
    aws ec2 authorize-security-group-ingress --group-id $rdsSg --source-group $ec2DbSg --protocol "tcp" --port "3306" --region $awsRegion
    aws rds create-db-instance --db-name "WaRdsDb" --db-instance-identifier "waDbInstance" --allocated-storage 20 --db-instance-class db.t3.micro --engine "mariadb" --master-username "mainuser" --master-user-password "WaStr0ngP4ssw0rd" --vpc-security-group-ids $rdsSg --db-subnet-group-name "wa-rds-subnet-group" --multi-az --no-publicly-accessible --backup-retention-period 0 --region $awsRegion
    ```
    
    ３、AWS Systems Manager Parameter Store データベースを更新する
    
    ```
    aws rds describe-db-instances --db-instance-identifier "waDbInstance" --query 'DBInstances[*].Endpoint.Address' --output text --region $awsRegion
    aws ssm get-parameters --names "DbPrivateDns" --region $awsRegion --output table
    export rdsEndPoint=aws rds describe-db-instances --db-instance-identifier "waDbInstance" --query 'DBInstances[*].Endpoint.Address' --output text --region $awsRegion && echo rdsEndPoint=$rdsEndPoint >> ~/.bashrc
    aws ssm put-parameter --name "DbPrivateDns" --value $rdsEndPoint --overwrite --region $awsRegion
    aws ssm get-parameters --names "DbPrivateDns" --output table --region $awsRegion
    ```
    
    ４、Application Load Balancer とターゲットグループを作成する
    
    ```
    aws ec2 create-security-group --description "ALB Security group" --group-name "wa-alb-sg" --vpc-id $VPC --region $awsRegion
    export albSg=`aws ec2 describe-security-groups --filters Name=group-name,Values=wa-alb-sg --query 'SecurityGroups[*].GroupId' --output text --region $awsRegion` && echo albSg=$albSg >> ~/.bashrc
    aws ec2 authorize-security-group-ingress --group-id $albSg --protocol "tcp" --port "80" --cidr "0.0.0.0/0" --region $awsRegion
    export albSubnet1Id=`aws ec2 describe-subnets --filters Name=tag:Name,Values=wa-public-subnet-1 --query 'Subnets[*].SubnetId' --output text --region $awsRegion` && echo albSubnet1Id=$albSubnet1Id >> ~/.bashrc
    export albSubnet2Id=`aws ec2 describe-subnets --filters Name=tag:Name,Values=wa-public-subnet-2 --query 'Subnets[*].SubnetId' --output text --region $awsRegion` && echo albSubnet2Id=$albSubnet2Id >> ~/.bashrc
    aws elbv2 create-load-balancer --name "waAlb" --subnets $albSubnet1Id $albSubnet2Id --security-groups $albSg --type "application" --region $awsRegion
    aws elbv2 create-target-group --name "waAutoscale-tg" --protocol "HTTP" --port 80 --vpc-id $VPC --target-type "instance" --region $awsRegion
    export waTg=`aws elbv2 describe-target-groups --names waAutoscale-tg --query 'TargetGroups[*].TargetGroupArn' --output text --region $awsRegion` && echo waTg=$waTg >> ~/.bashrc
    export albArn=`aws elbv2 describe-load-balancers --names waAlb --query 'LoadBalancers[*].LoadBalancerArn' --output text --region $awsRegion` && echo albArn=$albArn >> ~/.bashrc
    cd ~
    wget https://aws-tc-largeobjects.s3-us-west-2.amazonaws.com/ILT-TF-200-CSAWAF-10-EN/listener-source.json
    envsubst < "listener-source.json" > "listener.json"
    aws elbv2 create-listener --load-balancer-arn $albArn --protocol "HTTP" --port 80 --default-actions file://listener.json --region $awsRegion
    ```
    
    ５、AWS Systems Manager Run Command を使ったデータベースの移行
    
    ```bash
    
    aws rds describe-db-instances --db-instance-identifier "waDbInstance" --query 'DBInstances[*].{DB_Identifier:DBInstanceIdentifier,Status:DBInstanceStatus}' --output table --region $awsRegion
    
    RunCommand↓
    
    #!/bin/bash
    # Database backup using mysqldump utility
    mysqldump sample > backup.sql
    # Add RDS endpoint as an environment variable
    export awsRegion=curl -s <http://169.254.169.254/latest/meta-data/placement/region>
    export rdsendpoint=aws ssm get-parameter --name DbPrivateDns --query 'Parameter.Value' --region $awsRegion --output text
    # Set RDS instance admin user variable
    export user=mainuser
    # Set the RDS admin password value stored in Secrets Manager as variable
    export rdspasswd=aws secretsmanager get-secret-value --secret-id rdsPassword --query 'SecretString' --output text --region $awsRegion
    # Below commands creates database, loads MySQL backup into RDS, creates a user and set permissions in RDS database instance
    mysql -h $rdsendpoint -u $user -p$rdspasswd -e "CREATE DATABASE sample;"
    mysql -h $rdsendpoint -u $user -p$rdspasswd -e "USE sample;source backup.sql;"
    mysql -h $rdsendpoint -u $user -p$rdspasswd -e "CREATE USER 'tutorial_user'@'%' IDENTIFIED BY 'WaFram3w0rk';"
    mysql -h $rdsendpoint -u $user -p$rdspasswd -e "GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'tutorial_user'@'%' WITH GRANT OPTION;"
    mysql -h $rdsendpoint -u $user -p$rdspasswd -e "FLUSH PRIVILEGES;"
    ```
    
    ６、起動テンプレートを作成する
    
    ```bash
    
    49  aws ec2 create-security-group --description "Launch Template Security group" --group-name "wa-asg-sg" --vpc-id $VPC --region $awsRegion
    50  export asgSg=aws ec2 describe-security-groups --filters Name=group-name,Values=wa-asg-sg --query 'SecurityGroups[*].GroupId' --output text --region $awsRegion && echo asgSg=$asgSg >> ~/.bashrc
    51  aws ec2 authorize-security-group-ingress --group-id $asgSg --source-group $albSg --protocol "tcp" --port "80" --region $awsRegion
    52  aws ec2 authorize-security-group-ingress --group-id $rdsSg --source-group $asgSg --protocol "tcp" --port "3306" --region $awsRegion
    53  export webAMI=aws ec2 describe-instances --region $awsRegion --filters "Name=tag:Name,Values=wa-web-server" --query Reservations[].Instances[].ImageId[] --output=text && echo webAMI=$webAMI >> ~/.bashrc
    54  cd ~
    55  wget https://aws-tc-largeobjects.s3-us-west-2.amazonaws.com/ILT-TF-200-CSAWAF-10-EN/userData-source.sh
    56  envsubst < [userData-source.sh](http://userdata-source.sh/) > [userData.sh](http://userdata.sh/)
    57  export userData=base64 userData.sh | tr -d "\\n" && echo userData=$userData >> ~/.bashrc
    58  cd ~
    59  wget https://aws-tc-largeobjects.s3-us-west-2.amazonaws.com/ILT-TF-200-CSAWAF-10-EN/waLaunchTemplate-source.json-v1.1.0
    60  envsubst < "waLaunchTemplate-source.json-v1.1.0" > "waLaunchTemplate.json"
    61  aws ec2 create-launch-template --launch-template-name "waLaunchTemplate" --launch-template-data file://waLaunchTemplate.json --region $awsRegion
    62  export waLaunchTemplate=aws ec2 describe-launch-templates --launch-template-names waLaunchTemplate --query 'LaunchTemplates[*].LaunchTemplateId' --output text --region $awsRegion && echo waLaunchTemplate=$waLaunchTemplate >> ~/.bashrc
    ```
    
    ７、EC2 Auto Scaling グループを作成する
    
    ```bash
    
    63  export asgSubnet1Id=aws ec2 describe-subnets --filters Name=tag:Name,Values=wa-private-subnet-1 --query 'Subnets[*].SubnetId' --output text --region $awsRegion && echo asgSubnet1Id=$asgSubnet1Id >> ~/.bashrc
    65  aws autoscaling create-auto-scaling-group --auto-scaling-group-name "waAutoscaleGroup" --launch-template LaunchTemplateId=$waLaunchTemplate --min-size "2" --max-size "4" --target-group-arns $waTg --vpc-zone-identifier "$asgSubnet1Id,$asgSubnet2Id" --region $awsRegion
    ```
    
    ８、Route 53 ヘルスチェックを作成する
    　コンソールで実施
    
    ９、Amazon EC2 Auto Scaling 障害に対する耐障害性の検証
    
    ```bash
    
    66  aws ec2 describe-instances --filters Name=tag:Name,Values=wa-auto-scale-group --query 'Reservations[].Instances[*].{InstanceID:InstanceId,Type:InstanceType,AZ:Placement.AvailabilityZone,PrivateIP:PrivateIpAddress,Subnet:SubnetId,Time:LaunchTime,State:State.Name}' --output table --region $awsRegion
    67  aws ec2 terminate-instances --region $awsRegion --instance-ids i-05510870a66f13160
    68  history
    ```

ラボ３セキュリティ
> **目標**
このハンズオンアクティビティでは、主に追跡可能性を実現するの設計原則を適用し、AWS CloudTrail、セキュリティグループ、AWS Systems Manager などのクラウドネイティブコントロールを使用してクラウドアーキテクチャを安全に保つ方法を学習します。

セキュリティピラーの設計原則に関する情報は、AWS ドキュメント をご参照ください。
このラボを修了すると、以下のことができるようになります。

詳細なロギングを適用する
通信のきめ細かな制御を改善する
ネットワークベースのきめ細かな制御を改善する
詳細なロギングの機能を評価する
> 
> 
> 
- やったこと：Cloudtrail API設定、Config(変更履歴)の設定、DBのSG設定(ASGからの）、ネットワークACL設定(VPC)
    - そのメトリクス？記録結果を確認
        - CloudtrailからDL解凍して表示したjson
            
            > このログファイルのエントリから得られる情報は、ログインした IAM ユーザーのアイデンティティ (Mary_Major)、ログインした日時、ログインが成功したことだけではありません。そのユーザーがログインした IP アドレス、使用したコンピュータのオペレーティングシステムとブラウザソフトウェアを確認し、多要素認証を使用していなかったこともわかります。
            > 
            
            S3バケットからDL
            
            ![image.png](attachment:b142aaf2-bfae-44f8-a3b9-08f21dc73670:image.png)
            
    
    CotEditorで開いたjsonの中身　※みにくかったので改行/n(正規表現)で編集
    
    ![image.png](attachment:b95f6493-da64-4f26-8fd9-7c9259ab8886:image.png)
    
    Config は、設定変更してないので記録なし
    
    ![image.png](attachment:f79695e7-737f-4067-958a-6aedbeb8e5ea:image.png)

ラボ４パフォマンス
> **目標**
このラボを修了すると、以下のことができるようになります。
Amazon EC2 Auto Scaling グループのターゲット追跡スケーリングポリシーを作成する
Amazon CloudWatch ダッシュボードを作成する
ストレステストを実行してスケーリングポリシーを検証する
> 
- やったこと：
    - 動的スケーリングポリシー作成
        
        ![image.png](attachment:b53e16dc-7e69-4fb0-b78b-cef90c7a8ba0:image.png)
        
    - CloudWatch ダッシュボードで以下作成
        - ロードバランサーあたりの正常なインスタンス数
        - 平均 CPU% 平均使用率
        - アラームステータス
            
            ![image.png](attachment:e65e058c-adf4-45f8-b1a4-0d90b562a8f4:image.png)
            
    - RunCommand(SSM)でそれらを意図的に過剰に動かし、CloudWatchダッシュボードを確認
    
    ![image.png](attachment:88739d61-d81a-49c7-8d33-bb3053fc8e8b:image.png)

ラボ５コスト
> **目標**
このラボを修了すると、以下のことができるようになります。
AWS Config ルールを作成する
AWS Config の評価結果を確認して修正する
コンプライアンスのための予防的制御を適用する
> 
- やったこと：
    - Config ルールで”RequiredTagsCompliance”を作成
        - 絶対タグつけること
        - つけるタグはここから選ぶこと
            
            ![image.png](attachment:876f3f4e-087a-4287-a128-4b54d64c1be5:image.png)
            
        - EC2ならこのタイプだけ。違うなら`AWS-ResizeInstance`やで
            
            ![image.png](attachment:3919c49d-96fd-4ab9-975c-780bb6a53bc2:image.png)
            
        - 実際にそうなっているかの確認（↓コンプライアンス状況）
        
        ![image.png](attachment:2cf365f4-3885-48cb-9e0d-c13c8aeedcbf:image.png)
        

![image.png](attachment:a6824d20-139c-40a6-9cda-48c635730aa9:image.png)

![image.png](attachment:5be61b5a-0baf-48c9-8d8a-5301bfa0a237:image.png)


 資料(https://text.pianoslap.com/wabp_text.zip)
https://aws.amazon.com/jp/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc

 アジェンダモジュール 1: AWS Well-Architected Framework とは？

モジュール 2: 運用上の優秀性の柱

ラボ１

モジュール 3: 信頼性の柱

ラボ２

モジュール 4: セキュリティの柱

ラボ３

モジュール 5: パフォーマンス効率の柱

モジュール 6: コスト最適化の柱
↑要点のみ

 ーーーーーーーーーーーーーー↓時間があれば

 以下スライドとメモ
 モジュール１右の”持続可能性”が、昨年から増えた柱。（Well-Architectedは半年に一回内容見直しがある）

できるだけ電力使わないでおきましょう。的な

でも目新しいものではない、他の5つの柱から”環境配慮”的なものを集めただけ
でも上のスクショで言う”ベストプラクティス”は

下のスクショサイドバーの上の”ベストプラクティス”ではなく、下の”質問とベストプラクティス”の方。そっちを見て欲しい。
質問＝ケーススタディ、ベストプラクティス＝実際の設定。的な感じ？
Advancedはディスカッションあり、参加枠少なめ
オンプレの問題点、アーキテクチャ上の制限
クラウドはそれらを克服できる
AWS Well-Architectedレビュー
100点は取れないことを許容
できるだけ多くの関係者の意見を取り入れる。（具体的な意見を言える人と）
定期的にやること（健康診断的な）
→実際はやれないことが多い。安定稼働していると、触らなくなる。

　でもやりましょう。リファクタリングもそう、改善は常にやろう。

　フェーズごとにやるのが主流、「システム利用者〇〇以上になった」とか
Well-Architectedできてるかの診断ツールあるよ

 モジュール２ワークロードの意味2つ
狭義；アプリの塊　EC2とかDBとか実行基盤
広義；それを運用するチームお金など全て

運用のチーム編成について
小規模、横串のチームでやろ

そのアプリのビジネス成果って何？ちゃんと定義しよ
可観測性：オブザバビリティ

この三つで観測する　→　 メトリクス、ログ、トレース(一連の処理、入りから出るまで)
基本自動化しよ。人の手入れたらあかん

SystemsManager(多機能)をうまく使えるようになると、初級者→中級者になれる
コツコツ変更、コツコツ改善すること

それで、何か不具合あったら、すぐ元に戻せる
Single Point of Failureを作るな
ALBは、図では一つのAZにあるようだが、実は跨ってます
イベント＝障害　失敗から学ぶ　チームではなく、会社に還元できてる？

 ラボ１EC2をCloudwatchで管理する

 モジュール３意図的に障害を起こして、自分の構成の可用性をテストできるサービス
とにかく複数のAZにリソース作ろ

 ラボ２
 モジュール4基本MFA使お
トレーサビリティ、問題の特定
SSMからプライベートサブネットにあるEC２にはそのままでは接続できない
保護＝暗号化
例）RedShiftに人の手入れてて、テーブル壊してしまった
Detectiveは快活の件で使えそう

 ラボ３CloudtrailとConfigを設定する

 モジュール５車輪を再開発するな

　ダイナモでできるやん
サーバレスはオーバースペックなりがち、コスト高なりがち
メカニカルシンパシーとは？
裏でどう動いているかわかっときましょ。そして最適な使い方しましょ　

例）F1レーサーがマシンを理解して、最適なブレーキのかけ方を実施
Redshiftは列分析  キャッシュするDB ElastiCacheメモリDB  Dynamoハッシュのアルゴリズム分散

 ラボ４CloudwatchでAutoScalingの動きを見てみる

 モジュール６Well-Architected全部やるのは無理。理想論すぎ。でも、そこからトリアージ(層別)する。できそうインパクト大きそうからやってく。
メンテの手間考えてますか？　AWSマネージメントのリソーセス使お
誰が使ったのかタグつけてわかるように

 ラボ５Q&A質問:質問というより感想ですが。 Cloud Architectureの場合は，変動費になってくるのでreview中にコスト面の確認が重要になってくると感じています。 エンジニアだけが集まっても効果がなく，コストに対して責任を持つ人のreview参加が重要になるかと考えています。
回答:コメントありがとうございます。 まさしくおっしゃる通りで、クラウドのコストに関してはたとえばインフラチームだったりというような人たちだけが意識すればいい話ではなくなってくるというのがポイントです。 従来だと（たとえば私もいちデベロッパーだったので自覚がありますが）「なんだ、サーバーとかライセンスとかこんなに余ってるなら開発環境用に使わせてよ～」と考えがちですが、クラウドだと使った分だけコストになります。 そのため、インフラ／エンジニア／テスター／財務などなど、いろんな立場の人たちがしっかりとコストに対して意識をしていく体制を作る必要があります。 （このあたりは、「コスト最適化の柱」のところでも触れます）
質問:「Well-Architected レビュー」は「どのタイミングで誰がやるのか」をそれぞれの企業ごとに決めて 運用をまわしていくことが望ましい、という理解であっていますでしょうか？ ⇒当たり前の質問になってしまってすみません ⇒実際にこの運用を回せている企業は少ないのでは？と思ったので実際にはどのくらいレビューされている取り組みの事例があるのか知りたい、という思いも込めて質問させていただきました
回答:いえいえ、とても良い観点でのご質問でありがとうございます。 W-Aレビューをいつやるのか？は、なかなか難しくて、言ってみると「現実と理想」の永遠の課題的なところがあります。理想的には、「なるべく頻繁に」なのですが、ひとつのポイントとしては「フェーズの区切り」や「システムアーキテクチャに割と大き目な変更が加わったとき」が狙い目です（関係者に対して「やろうよー」と言う際の大義名分にもなりますし）。 そして、１回ずつのW-Aレビューが重くなりすぎると、なかなかやられなくなってしまうので、サラッとやるのもひとつのポイントです。１つの柱についてなるべく数時間だけとか、全部の柱を一気にやるのではなくて、必要に応じて数本の柱だけやるとか…いろいろな工夫があります。 そういった観点に合わせて、それぞれの企業やワークロードの性質（たとえば、セキュリティやコストの制約が厳しいプロジェクトであれば、それらの柱だけ頻繁にやるなど）に応じて適切なタイミングを設定していくのがいいかと思います。
質問:W-A reviewは監査ではない，ということですが，システム監査の一部としてW-A reviewが行われることはあるのではないでしょうか? 「監査ではない」というより，「監査事項とするかどうかは運用による」という印象を持ちました。
回答:もちろん、監査的な手続きに「活用」することはできるかと思います。 「W-Aレビューは監査ではない」というメッセージの一番の意図としては「レビュー時に、犯人捜しやできていないことを責める雰囲気になってしまうと、レビューの本来の目的である改善ポイントを見つけるができなくなってしまうから」ということです。 なので、もちろん監査に活用していただくことはできます。 ただし、監査は証跡にもとづいて厳密に進めていく必要があるものであり、W-Aレビューの場合はそこまでしっかりしたエビデンスを求めずに、とにかく「どこが改善できるかを見出していく」のが目的であるという違いについても留意しておくと良いと思います。
質問:「ビジネス成果を中心にチームを編成する」 コンウェイの法則ということでしょうか。 「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」
回答:まさしく、その通りです。コンウェイの法則もそうですし、マーティン・ファウラーのマイクロサービスに関する考え方においても、「チームの組織の仕方」と「アプリケーションのあり方」というのは非常に相互作用が大きいと論じられています。 鶏が先か卵が先かの話ですが、チームの構造とアプリケーションの設計・構築・運用の仕方というのは相互に近づいていくものなので、W-Aの運用上の優秀性で言われているような「小規模」「頻繁に改善」「迅速に変更」というような運用を達成するためには、小規模かつ独立性の高い形のクロスファンクショナル（いろんなロールを含む）な組織が理想になってきます。
質問:「運用上の優秀性」の「障害を予想する」と 「信頼性」の「障害から自動的に復旧する」 はどのあたりが違うのでしょうか。
回答:これ、W-Aフレームワークではあるあるなのですが、同じような内容が複数の柱に含まれていることがあるんですよね。 ただ、ポイントはその「観点」と「何を達成したいか」で、そこに着目すると違いが見えてきます。 運用上の優秀性では、「いかに運用の手間を削減して、正確にシステムを稼働させ続けるか」がポイントで、信頼性では「いかにシステムのダウンタイムを少なくしたり、データの損失をなくすか」がポイントです。 なので… ・運：障害を予想して冗長化構成にしておくことで、手動での復旧をしなくてよくなる（手間が削減される） ・信：障害を予想して冗長化構成にしておくことで、サービスが止まらなくなる（可用性が高まる） というとらえ方の違いに由来するものです。 方法論は似ているけど、それを達成することによって得られるものに対する観点の違いといったところでしょうか。
質問:感想です。 Secuirtyのレビューに関しては， W-A reviewで出てきたissueに対して そのworkloadだけ即対応，というのは難しい印象を受けました。 性能の問題と違って，全社のSecurity policyなどとの調整が発生する可能性が非常に高いからです。 チーム内で閉じた解決は難しそうです。
回答:そうですよね。まったくもって、よく聞く「あるあるな事情」です。これに関しては、「W-Aのレビュー後にどう対応するか」にヒントがあると思います。 W-Aのドキュメントでは、レビューしたあとに改善するアクションに移すフェーズについても詳しく述べられています。その中で、改善すべきポイントとして出てきたものを「重要度・緊急度」と「実装の難易度」で表（こういう表をアイゼンハワー・マトリクスというらしいです）にして検討します。 その中から、「重要性や緊急度が高い」かつ「難易度が低い」ものから順に改善していきます。いただきましたコメントにあるような「他の部門との調整が必要なもの」については「難易度が高い」ものとして、時間をかけて対応していく形になるかと思います。 もちろん、時間をかけても最終的に全社Security Policyと競合してしまって完全解決が難しい、というような場合には、リスクマネジメントでも言われるような「回避」「転嫁」「軽減」「受容」などのアプローチでなんとか最悪の状況にならないようにアプローチしていくのができることかなと思います。
目的

所感

資料

アジェンダ

ーーーーーーーーーーーーーー

以下スライドとメモ

モジュール１

モジュール２

ラボ１

モジュール３

ラボ２

モジュール4

ラボ３

モジュール５

ラボ４

モジュール６

ラボ５

Discussion
