EC2をあきらめない - Amazon EC2を活用したアプリ実行基盤のモダンな運用を考える / please-do-not-give-up-ec2-in-2021

© 2021, Amazon Web Services, Inc. , Accenture. All rights
reserved. EC2をあきらめない - Amazon EC2を活用したアプリ実行基盤のモダンな運用を考える岡智也シニア・プリンシパルアクセンチュア株式会社 G-3

reserved. This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

reserved. 自己紹介アクセンチュア株式会社テクノロジーコンサルティング本部インテリジェントソフトウェアエンジニアリングサービスグループシニア・プリンシパル 2021 APN Ambassador 2021 APN ALL AWS Certifications Engineer 好きなAWSサービス：Aurora, Fargate, Lambda 岡智也 Tomoya Oka

reserved. ⚫ アクセンチュアのご紹介 ⚫ Why Amazon EC2？ ⚫ EC2の構築、運用を支援する5つのTips ⚫ 最後にアジェンダ

reserved. アクセンチュアのご紹介

reserved. アクセンチュアのご紹介企業概要概要 ◼ 売上：443億US$(2020年8月期) ◼ 創業： 1953年 ◼ 従業員数：約56.9万人 ◼ 日本事務所：約16,000名(2021年6月1日時点) ◼ 最高経営責任者：Julie Sweet (日本) 代表取締役社長：江川昌史アクセンチュアの組織と提供サービス ◼ 世界50カ国200都市以上に展開 ◼ 「ストラテジーおよびコンサルティング」「インタラクティブ」「テクノロジー」「オペレーションズ」の4つの領域で幅広いサービスとソリューションを提供各業界の歴史、業界固有の課題やテクノロジーに精通したプロフェッショナルが、お客様に応じた各分野におけるサービスを提供通信・メディア・ハイテク本部金融サービス本部製造・流通本部公共サービス・医療健康本部素材・エネルギー本部先端技術やソリューション、サービスに特化したプロフェッショナルが業界横断でサービスを提供展開国 & 事業内容  全社戦略開発支援  グローバル戦略  デジタル戦略、等 Client Group  全社成長  全社収益  サステナビリティ  IT・セキュリティ  人材・組織・オペレーティングモデル  イノベーション  AI  IoT  M&A  営業・マーケティング  サプライチェーン Strategy & Consulting ビジネスコンサルティング本部  パーパスとイノベーションが両立する意義深い顧客体験の設計  製品・サービスの再定義  プラットフォームの構築  クリエイティブ、メディア、マーケティング戦略  キャンペーン、コンテンツ、チャネル設計・運用 Interactive インタラクティブ本部  テクノロジー・インフラ＆クラウド戦略策定  テクノロジー研究開発(R&D)  エコシステム＆プラットフォーム構築  システム・インテグレーション  アプリケーション・インフラストラクチャ・アウトソーシング  アクセンチュア・ソフトウエア開発・提供  アクセンチュアラボ・アクセンチュアベンチャーズ  製造業のデジタル化実現  業界別ソリューション  サイバーディフェンス  アプライド・サイバーセキュリティ  マネージド・セキュリティ Technology テクノロジーコンサルティング本部  経理・財務オペレーションサービス  人事・人材管理オペレーションサービス  調達オペレーションサービス  マーケティングオペレーションサービス  セールス(コマース)オペレーションサービス  カスタマーサービスオペレーションサービス  サプライチェーン・オペレーションサービス(製造業)  R&Dオペレーションサービス(製薬業)  契約管理オペレーションサービス(保険業)  トラスト＆セーフティオペレーションサービス (プラットフォーム産業)  その他、様々なファンクション/業界向けオペレーションサービス Operations オペレーションズコンサルティング本部

reserved. アクセンチュアAWSビジネスグループ（AABG） URL: https://www.accenture.com/jp-ja/services/cloud/aws-business-group

reserved. アクセンチュア・クラウド・ダイアリーズ URL: https://www.accenture.com/jp-ja/blogs/cloud-diaries

reserved. Why Amazon EC2？

reserved. Amazon EC2とは ✓ Amazon Elastic Compute Cloud(以下、EC2)は、アマゾンウェブサービス（AWS）上で必要なコンピュートリソースを必要な時に仮想サーバとして起動し、従量課金型で利用するサービス ✓ AWSの代名詞とも言える、非常にメジャーなサービス ✓ はじめてEC2を利用した時(2009年)は、本当に衝撃を受けました・・

reserved. お子さんだとすると、中学3年生ですね！！！ EC2、15周年おめでとうございます！！！引用: https://aws.amazon.com/jp/ec2/15th-birthday-event/

reserved. EC2と、15年間に起きたこと ✓ EC2がリリースされてから15年の間に、サーバーレスやコンテナといった概念や実現するための技術、そして、それらをマネージド型で提供するAWSサービスも続々とリリースされてきました ✓ 2021年現在では、アプリケーション実行基盤をEC2から新しいAWSサービス(Amazon Fargate、AWS Lambda、等)に乗り換えるケースも、一般的になっています ✓ 次頁にて、EC2や、その後新たにリリースされたAWSサービスの現状を概観します

reserved. 長年、アプリはEC2で実行し、データベース等のマネージドサービスを組み合わせる設計が主流でした。しかし、コンテナを前提としたアプリ設計・開発の流行、Amazon Fargateのリリース、そしてAmazon Lambdaの継続的な機能改善等が契機となり、アプリ実行基盤としてのEC2利用見直しが検討されるようになりました。 AWSにおける、アプリ実行基盤の進化の流れ Amazon EC2 beta(2006) IaaS (Infrastructure as a Service) クラウドベンダが、ハードウェア、仮想化基盤、OSイメージまでを提供。ユーザは、OS選択・設定とミドルウェアのインストール・設定・運用、アプリ開発・デプロイを担当 Amazon EC2 クラウドサービス種別クラウドサービス種別概要 AWSにおける該当サービス AWS Elastic Beanstalk(2011) PaaS (Platform as a Service) クラウドベンダが、様々なミドルウェアを選択可能なアプリ実行基盤を提供。ユーザは、アプリ開発・デプロイを担当 AWS Elastic Beanstalk, AWS OpsWorks, AWS App Runner AWS Lambda(2014) FaaS (Function as a Service) クラウドベンダが、短時間で完了する処理を「ファンクション」として実行可能なアプリ実行基盤を提供。ユーザは、ファンクションの開発・デプロイを担当 AWS Lambda 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 AWS OpsWorks(2013) Amazon ECS(2015) CaaS (Containers as a Service) クラウドベンダがコンテナオーケストレーション基盤を提供。ユーザは、アプリ開発・コンテナイメージ作成・デプロイと、コンテナ同士の連携動作に必要な設定・運用を担当 Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS) AWS App Runner(2021) Amazon EKS(2018) Amazon Fargateリリース(2017)▼ Amazon FargateのEKSサポート開始(2019)▼ Amazon LambdaのAmazon RDS Proxyサポート開始(2020)▼ おおよそのAWSサービスリリースタイミング ※()内の数字はリリース年

reserved. EC2は長年の間、継続的にサービス改善・機能追加が行われており、EC2でなければ実現できない要件も多い。一方、数年前にEC2上で開発したシステムが「レガシー化」し、その運用保守が重荷になっているケースもあります。 2021年時点で、EC2を利用する主な理由技術的な要件 ✓ OS以上のレイヤーを自由にカスタマイズし、さらにOS障害時もユーザー自身で対応できるようにしたい ✓ 極めてハイスペックなインスタンスタイプを利用したい (例:機械学習、HPC(High Performance Computing)等) ✓ システムで利用するソフトウェアのインストール要件として、EC2が必要 (例: ERPパッケージ、Amazon Relational Database Service(Amazon RDS)がサポートしないRDBMSを利用したい、等) ✓ ベアメタルインスタンスを利用したいコンプライアンスや社内規定等への対応 ✓ 業界規制や、インストールするソフトウェアのライセンス契約により、「Dedicated Host」タイプのインスタンスを利用し、 AWSのデータセンター上でハードウェアを占有且つ特定する必要がある ✓ 社内のクラウド利用ガイドラインにおいて、利用可能なAWSサービスが限定されている (例: EC2は利用可能だが、Amazon FargateやAWS Lambdaは許可されていない、等) 予算やスキル、技術的負債による制約 ✓ 新規に開発したアプリケーションは、コンテナ化やサーバーレスアーキテクチャの採用を進めている。しかし、数年前にオンプレミス環境からEC2に移行したシステムについては、予算や社内での優先度の関係上、「塩漬け」にしている ✓ 既存のEC2ベースのシステムの運用保守で手一杯であり、技術的なトレンドやAWSの新サービスリリースへの追随が難しい。結果として、アーキテクチャの刷新に踏み込めないでいる

reserved. OS以上のレイヤーに関する「設計・構築の自由度の高さ」のトレードオフとして、ユーザ自身が運用しなければならない要素が相対的に多くなるというのは、IaaSの特性です。(EC2が悪いわけではない) EC2の運用保守で負担になりがちな作業例監視、アラートや障害対応、スケーリング(手で対応) Auto Scalingできないアプリ (ミドルウェア制約、クラスタリングetc..) OSパッチ適用ミドルウェアパッチ適用 OS設定やSecurity Group変更(セキュリティアラート対応等) OSやミドルウェアの設定やパッチレベルを揃えるのがつらい。というか揃ってないバックアップ(AMI、スナップショット)の管理 OSアカウントや証明書の管理ハードウェアのRetireやパッチ適用に伴う OS再起動対応不揃いなタグそもそもタグが付与されていないケースも OSバージョンアップ

reserved. EC2をあきらめない次章にて、EC2の構築、運用を支援する5つのTipsをご紹介します ✓ 本来、AWS Cloud9(ベースはEC2)のように、ソフトウェア開発に携われる方々が「自由度の高いアプリ実行環境を、気軽に手に入れられる」特性が、EC2の良さの1つのはず ✓ AWSの利用者は、今も増え続けています。初学者の方は、おそらくEC2からAWSに入門されるケースが多いのではないでしょうか ✓ 「EC2の始め方」に関するまとまった情報は、ネット、書籍等で簡単に手に入りますが、「EC2の管理や運用を楽にする方法」は、情報が分散していたり、情報が古かったりする印象があります ✓ アプリ開発者やデータ分析者の方々がEC2を利用される際、本来の「価値を生み出す」作業に集中できるよう、EC2の管理や運用を少しでも楽にできるようなTipsをご紹介したいと思います

reserved. EC2の構築、運用を支援する5つのTips

reserved. Tips 1: AWS Systems Managerを活用しよう(1/6) ー AWS Systems Managerとは ✓ AWS Systems Manager(以下、SSM)は、 AWSリソースの情報収集・表示、操作、アプリケーション支援等の、運用管理を支援する様々な機能を提供するサービス ✓ EC2からSSMを利用するためには、最低限以下の条件を満たす必要あり • EC2に、AWS Systems Managerエージェント(SSM Agent)をインストール • EC2から、SSM APIへのアクセス経路を確保 ※VPCエンドポイントによるプライベートネットワーク経由でのアクセスを推奨 • EC2のIAMロールに、SSMを利用するために必要なIAMポリシー (AmazonSSMManagedInstanceCore、等)をアタッチ AWS Systems Manager

reserved. Tips 1: AWS Systems Managerを活用しよう(2/6) Systems Managerは非常に多機能で、一見とっつきにくいです。すべての機能を利用する必要はなく、特定の機能を利用するだけでも、運用負荷を緩和できます。ー SSMの機能全体像(2021年9月時点)(1/2) No 機能タイプ機能機能概要 1 高速セットアップ高速セットアップ AWS推奨設定で、SSMの設定を設定 2 運用管理エクスプローラーオペレーションデータ(OpsData)のダッシュボード 3 OpsCenter 運用作業項目(OpsItems)の管理 4 CloudWatchダッシュボード Amazon CloudWatch情報の表示 5 PHD AWS Personal Health Dashboard (PHD)の表示 6 インシデントマネージャーインシデント管理の支援 7 アプリケーション管理アプリケーションマネージャーアプリケーションの自動検出、関連する情報の表示・管理 8 AppConfig アプリケーション設定(機能フラグ、等)の管理 9 パラメータストア設定パラメータ値のデータストア 10 変更管理変更マネージャーアプリやインフラの変更管理の支援 11 自動化一般的なメンテナンスとデプロイのタスクを自動化

reserved. Tips 1: AWS Systems Managerを活用しよう(3/6) (前頁の続き) 本セッションでは、赤枠で囲った機能の活用方法をご紹介します。ー SSMの機能全体像(2021年9月時点)(2/2) No 機能タイプ機能機能概要 12 (変更管理の続き) カレンダーの変更自動実行の除外日や、非定期作業のカレンダー設定 13 メンテナンスウィンドウ定期的な作業のスケジューリング 14 ノード管理フリートマネージャーサーバ群をグルーピングし、リモート管理 15 コンプライアンスコンプライアンス適合状況をダッシュボード表示 16 インベントリサーバ構成情報のインベントリ表示 17 ハイブリッドアクティベーションオンプレミス環境のサーバをSSM管理対象として登録 18 セッションマネージャーマネジメントコンソール経由で、サーバにsshログイン 19 Run Command サーバ上で実行するコマンドを定義・実行 20 ステートマネージャーサーバのあるべき状態を定義・維持 21 パッチマネージャー指定ルールに基づき、サーバにパッチを適用 22 ディストリビューターサーバにパッケージをインストール 23 共有リソースドキュメント SSMで実行する処理をドキュメントとして記述・登録

reserved. Tips 1: AWS Systems Managerを活用しよう(4/6) ーセッションマネージャーを活用し、ブラウザ経由でEC2にログイン ✓ (SSMの機能と意識せず、既に利用されている方も多いかもしれませんが) セッションマネージャーを利用することで、AWSマネジメントコンソール(つまりブラウザ)経由でEC2 にsshアクセスが可能になります • セッションマネージャー経由でポート転送セッションも確立できますので、LinuxサーバへのGUIを利用したSCP 接続や、Windows Serverへのリモートデスクトップ接続も可能となります • セキュリティやアプリのテスト要件次第ですが、この方式を活用することで、EC2へのsshアクセスのために別途「踏み台サーバ」用途で利用していたEC2や、踏み台サーバにアクセスするために利用していたVPN環境 (AWS Client VPN、等)をなくすことができる可能性があります ✓ 【注意】セッションマネージャー経由でEC2へのアクセスを許可する場合は、事前のリスク分析と対策検討を行い、IAMポリシーを定義してセッションマネージャーを利用できるユーザや対象サーバを制限する、セッションマネージャ経由のアクセスログや操作履歴を保存する、等は併せて実装しましょう

reserved. Tips 1: AWS Systems Managerを活用しよう(5/6) ーパッチマネージャーを活用し、EC2のパッチ自動適用(1/2) ✓ パッチマネージャーは、SSMエージェントがインストールされたサーバへのOSパッチ適用内容やタスクを定義、管理する機能です • パッチ自動適用を実現するためには、パッチマネージャと、いくつかのSSMの機能が連携して動作する必要があります。アーキテクチャは以下のとおりです AWS Systems Manager パッチマネージャパッチベースライン (どのパッチを適用？) パッチグループ (対象サーバは？) メンテナンスウィンドウウィンドウ (いつ、どのタスクを実行？) Run Command タスク (どのドキュメントを実行？) ドキュメント実行するコマンドの内容 Amazon Elastic Compute Cloud (Amazon EC2) SSMの提供機能 SSM エージェントパッチ自動適用に必要な各種設定 SSM APIを経由して、ドキュメントに定義されたコマンド実行を命令 (今回はパッチ適用) 結果を返却

reserved. Tips 1: AWS Systems Managerを活用しよう(6/6) ーパッチマネージャーを活用し、EC2のパッチ自動適用(2/2) ✓ パッチマネージャーをはじめとするSSMの提供機能は、LinuxやWindowsに対応した前述の「パッチベースライン」や、パッチ適用のような汎用的な作業(つまり一連のコマンドをまとめたシェルスクリプト)を「タスク」や「ドキュメント」として提供しています ✓ シンプルなパッチ適用要件(例:緊急度「Critical」の最新パッチがリリースされた場合、リリースから3日経過後、特定のタグの値を持つ全サーバに対してパッチを適用、等)であれば、簡易な設定で実現可能 • 当然、現実の運用では、開発環境やステージング環境にてパッチ適用を行い、OSやアプリの動作への影響確認を行うことになる • パッチマネージャーの「パッチベースライン」では、動作検証の結果問題のあったパッチを除外指定する、特定のCVE番号のパッチ単体を指定する、といった定義もできるため、パッチ適用フローを検討の上、効果的に活用しましょう

reserved. Tips 2: 監視やログ収集は自動化しよう(1/2) ー Amazon CloudWatch ✓ Amazon CloudWatch(以下、CloudWatch)は、 AWSリソースのメトリクス情報やログ情報を収集・表示するサービス ✓ 有名な話ですが、CloudWatchのデフォルトメトリクスではEC2のメモリ使用率やディスクスペースの使用状況は取得できませんので、CloudWatchエージェントをインストールしましょう*1 ✓ OS上のログ(システムログ、アプリケーションログ、等)についても、CloudWatchエージェントの設定ファイルで定義を行い、CloudWatch Logsに送信しておきましょう • ログの確認のためにOSにログインする、という手間を撲滅 • 既存の運用と合わせるという観点で、Fluentdなどを利用してログ収集するのもありです • とにかく「サーバのローカルディスク上にしかログがない」という状況を避ける Amazon CloudWatch *1 数年前までは、メモリ使用率やディスクスペースは、カスタムメトリクスとしてシェルからAPIを呼び出して登録していた

reserved. Tips 2: 監視やログ収集は自動化しよう(2/2) ー監視SaaSの導入も検討を ✓ これもまた有名な話ですが、CloudWatchでは「意味のあるメトリクス情報」を長期間保持することが仕様上できません • 収集間隔3600秒(1時間)単位のデータポイントを15か月間保存できても、あまり意味があるとは思えない • 収集間隔が60秒のデータポイントは15日間、300秒のデータポイントは63日間 ✓ EC2で監視サーバを構築するのも1つの手段ですが・・そもそも管理するEC2自体を減らしたいはずなので、監視SaaS導入も検討しましょう • もはやEC2だけの話ではないですが、メトリクスやログ情報の収集が簡単なだけでなく、監視運用やメトリクスの Visualizationのためのテンプレートも豊富に用意されており、システム規模が大きくなるほど効果を感じられると思います(ログ情報も含めて大量に保存すると、そこそこいいお値段したりしますが・・) • 注意点として、何も考えずにアラート設定する(例: とりあえずCPU使用率の5分間平均が90%を超えたら通知、等)と、メトリクスやログ情報の収集が簡単なだけに、無駄なアラートを増やすことになります • オライリーの『入門監視』は良い本です。とても良い本です

reserved. Tips 3: タグや設定チェックもマネージドで(1/2) ー AWS Config ✓ AWS Configは、AWSリソースの設定項目、設定内容とその履歴を保持、集約するだけでなく、ルールベースで設定内容を評価可能なサービス • 同じマネジメント&ガバナンスカテゴリのサービスであるAWS CloudTrailや、セキュリティ、アイデンティティ & コンプライアンスカテゴリのサービスであるAmazon GuardDutyなどと併せて、AWSアカウント作成と同時に有効化すべきサービスの1つ AWS Config

reserved. Tips 3: タグや設定チェックもマネージドで(2/2) ー AWS Configマネージドルール ✓ AWS Configは有効化して履歴を保持しておくだけでも意味はありますが、ぜひAWS Config マネージドルールの有効化とアラート通知を設定しましょう • AWS Configマネージドルールは、AWSのベストプラクティスに違反した設定がないかチェックするために、あらかじめ用意されたルール。以下は、有効化すべきルール例*1 ➢ “required tags”ルール ⇒ AWSリソースに対して、必要なタグが付与されているかどうかをチェック。タグが設定されているかどうかは、運用の自動化を実現するための前提になるものなので、積極的にチェックしましょう ➢ “ec2-instance-managed-by-systems-manager”ルール ⇒ EC2インスタンスにSSMエージェントがインストールされ、管理されているかどうかをチェック。 Tips 1で紹介した内容を実現する前提条件となり、「野良EC2」を発見する上でも重要 ➢ “restricted-ssh”ルール ⇒ Security Groupにおいて、インバウンドのsshアクセスが無制限に許可されていないかどうかをチェック。セキュリティ系のチェックルールは、他にも多数用意されているため、利用しているサービスに応じ有効化を推奨 *1 List of AWS Config Managed Rules - AWS Config https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html

reserved. Tips 4: EC2のバックアップは自動化しようー AWS Backup ✓ AWS Backupは、様々なAWSリソースのバックアップ取得や復元、スケジューリングや保持期間の管理等、バックアップを一元管理可能なサービス • 2020年から、EC2のバックアップとしてのAMI取得、Amazon Elastic Block Store(Amazon EBS) (以下、EBS)のスナップショット取得も管理対象としてサポートされるようになりました • バックアッププランを作成し、取得タイミング、保持期間、対象リソース指定等を設定しておけば、自動でバックアップを取得してくれる*1 • 対象リソース指定は、タグを活用することで、個別のリソースID指定の手間を省けます • (参考) EC2に特化したバックアップ関連サービスとしては、Amazon Data Lifecycle Managerというサービスも提供されています。2018年にリリースされ、EBSスナップショットの自動取得・管理サービス*2としては先行していました。AWS BackupがEC2サポートを開始したため、2021年時点ではAWS Backupを利用しておけばよいと考えます AWS Backup *1 数年前までは、EC2のバックアップ取得とバックアップ世代管理はAWS Lambdaで関数を書いていた *2 現在はAMI取得もサポート

reserved. Tips 5: EC2のOS以上のレイヤーもコードで管理(1/4) ー OSの設定やミドルウェア導入もコードで管理 ✓ AWSのインフラ構成は、AWS CloudFormationやTerraform等を利用してコードとして管理することで、環境構築の自動化や、構成変更の差分の確認がしやすくなります ✓ EC2のOS以上のレイヤー構成(OS設定、ミドルウェア導入・設定、等)についても、EC2の userdata機能を利用するか、3rd Partyの構成管理ツール(Ansible、Chef、等)を利用することで、コードとして管理することが可能になります

reserved. Tips 5: EC2のOS以上のレイヤーもコードで管理(2/4) ーゴールデンイメージ(おさらい) ✓ EC2の起動にはAMIが必要です • 通常、AMIはAWS提供の標準イメージをベースとして、ユーザの要件に合わせたOS設定、ミドルウェア導入・設定等を行った上で、カスタムAMIを作成し、EC2起動時のベーステンプレートとします。これを「ゴールデンイメージ」と呼びます • ゴールデンイメージを作成した場合は、イメージをテストすべきですし、イメージ内にどのレイヤーまでを含めるかは、EC2の起動速度にも影響しますアプリケーションミドルウェアおよび設定 OS設定 OS ゴールデンイメージ Userdata等で起動時にデプロイアプリケーションミドルウェアおよび設定 OS設定 OS ゴールデンイメージ Userdata等で起動時にデプロイアプリケーションミドルウェアおよび設定 OS設定 OS ゴールデンイメージ EC2の起動速度遅い速い

reserved. Tips 5: EC2のOS以上のレイヤーもコードで管理(3/4) ー Amazon EC2 Image Builder ✓ Amazon EC2 Image Builder(以下、EC2 Image Builder)は、 AWSやオンプレミス環境で使用する仮想サーバやコンテナイメージの構築、テスト、配布をパイプライン管理可能なサービス • EC2 Image Builderは、AMIの作成・検証・テストに必要な作業をパイプライン化して実行でき、 AMIの作成作業の内容(ビルドコンポーネント)とテストの内容(テストコンポーネント)をYAML形式で記述できる=コードとして管理可能 • ビルドコンポーネントの中で、Ansible Playbookを呼び出すことも可能 Amazon EC2 Image Builder 参考: https://d1.awsstatic.com/webinars/jp/pdf/services/20200825_BlackBelt_EC2imagebuilder.pdf

reserved. Tips 5: EC2のOS以上のレイヤーもコードで管理(4/4) ー (参考)Packer+Ansibleの方が慣れているんですが・・ ✓ Packer+Ansibleの場合、AMIのテスト定義やパイプライン化部分は自前で準備する必要がありますが、依然として有力なソリューション ✓ Packerは、マルチクラウド環境で利用できる(スキルを流用できる)、という利点あり (Terraformと同様) ✓ EC2を運用される組織の状況や、エンジニアの方のスキルセット等も考慮して決定すべきと思います

reserved. 最後に

reserved. あきらめないで！まとめ(1/3) ✓ 2021年時点でも、EC2を利用するユースケースはたくさんあります ✓ EC2を単体で利用した場合に発生するペインポイントが比較的多いのは事実ですが、本日のセッションでご紹介したようなサービスを活用することで、構築や運用負荷を下げられる部分はたくさんあります ✓ AWSに任せられるタスクはAWSに任せ、EC2を利用した「価値を生み出す」作業に注力しましょう！

reserved. タイムリーなことに、10/14にAWSさんによるEC2最新情報を解説して下さるセミナーがあるそうです。みなさんぜひ参加しましょう！まとめ(2/3) 引用: https://pages.awscloud.com/JAPAN-event-OE-20211014-EC2-reg-event.html

reserved. Special Thanks to AABG Solutions Architect team and Cloud CoE members! アクセンチュアは、お客様の新しいサービス、ビジネスに技術力で貢献するデベロッパー、クラウドエンジニアを大募集しています！！！まとめ(3/3) URL: https://www.accenture.com/jp-ja/careers/local/intelligent-cloud-infrastructure Cloudのキャリア・採用情報 l アクセンチュア

EC2をあきらめない - Amazon EC2を活用したアプリ実行基盤のモダンな運用を考える / please-do-not-give-up-ec2-in-2021

EC2をあきらめない - Amazon EC2を活用したアプリ実行基盤のモダンな運用を考える / please-do-not-give-up-ec2-in-2021

More Decks by cyberarchitect

Other Decks in Technology

Featured

Transcript