コンニチハ、千葉です。 監査ログを悪意ある削除から、何が何でも守っていくぞのコーナーです。 みなさんは、AWSの監査ログ(CloudTrail)をどのように保護していますか？ CloudTrail を保護するために CloudTrail ログファイルの整合性の検証を有効化 CloudTrail ログファイルを暗号化 S3上のファイルを削除から守るために MFA削除の設定 が考えられます。 よし、保護している！って思っても、ユーザーが Admin 権限を持っている場合、暗号化していようが整合性チェックしていようがデータは削除可能です。しかも、 CloudTrail のレコーディング自体を停止 もできちゃいます。つまり、監査ログが保存されなくなり、何が行われたのか調査が難しくなります。 もしも、万が一、強い 権限がある Admin が第３者に渡ったとしても、大切なログを守りたいです。Admin
![[AWS]監査ログを悪意ある削除から守る | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3a9299c22c271be79f273b6db38d8ba6bc81bd1c/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F05%2F8823428add162ea6925215296ff8c67f.png)
※この投稿は米国時間 2023 年 2 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Run を使用すれば、デベロッパーは、Google のスケーラブルなインフラストラクチャ上で実行されるサーバーレス環境に本番環境のウェブ アプリケーションと API を簡単にデプロイできます。開発チームは Cloud Run を活用して開発のアジリティを向上させ、迅速に反復処理できますが、多くの場合、インフラストラクチャのセキュリティ体制が見落とされています。十分な注意が払われていないセキュリティの側面として特に注目すべきなのが、アクセス管理と最小権限の原則です。 最小権限の原則とは、あるリソースに対してその機能に必要なリソースのみへのアクセスを許可することを示します。この原則は、ID の侵害によって攻撃者に幅広いリソースへのアクセスが許可されるリスクに対応
初めに IAMのアクセスキーが漏洩してしまった際に、漏洩を検知して対象のIAMアクセスキーを削除する仕組みを作る必要があったのでその内容について記載します。 構成 Trusted Adviserのルールを利用してEventBridegeで検知し、SNSを利用して通知し、Step FunctionsとLambdaで検知したIAMアクセスキーを削除します。 構成としては以下のようになります。 ※この構成はTrusted Adviserがバージニア北部リージョンでしか情報を取得できない関係で、バージニア北部リージョンで作成する必要があります。 今回は以下のTrusted Advisor toolsを参考にしました。 Trusted Adviser Trusted Adviserでは有効化しておけば特に設定しておくことはないです。 「漏洩したアクセスキー」のルールを使用してIAMアクセスキーの漏洩
エムスリーエンジニアリンググループ AI・機械学習チームの笹川です。 趣味はバスケと筋トレで、このところはNBAはオフシーズンですが、代わりにユーロバスケが盛り上がっていて、NBAに来ていない良いプレーヤーがたくさんいるんだなーと思いながら見ています。 夜ご飯を催促するためデスク横で待機する犬氏（かわいい） 今回は、パブリッククラウドへの認証に必要な秘密情報をGitLab自体に格納することなく、安全に認証する方法について紹介します。 CI/CDの実行時のパブリッククラウドに対する認証 ナイーブな手法とその問題点 OpenID Connectを用いた認証 Terraformでパブリッククラウド側の設定を記述する Google Cloudの場合 AWSの場合 GitLab CI/CDで認証する Google Cloudの場合 AWSの場合 認証ステップの共通化 まとめ We are hirin
STORES 技術基盤グループの id:atpons です。普段は STORES 全体のパブリッククラウドや開発で利用している SaaS の管理をしています。今回は STORES で管理している AWS Organizations のメンバーアカウントのルートユーザーを全部削除したので、進め方について書いていきます。 この記事は STORES Product Blog Advent Calendar 2024 11日目 の記事です。 はじめに STORES では、プロダクトの開発や運用に AWS を採用しています。その上で、AWS Organizations を導入しており、各アカウントへのログインは IAM Identity Center と Okta を経由した SSO により、IAM ユーザーを利用しない方針で運用しています。STORES における AWS Organizations
RALGO : AIを組織に組み込む方法 -アルゴリズム中心組織設計- #RSGT2026 / RALGO: How to Integrate AI into an Organization – Algorithm-Centric Organizational Design
【8/17（火）リモート開催】AKIBA.AWS ONLINE #06 – AWS IAM 編- で登壇しました。スライド資料を共有します。 資料
LayerX Fintech事業部（※）で、ガバナンス・コンプラエンジニアリングをしている 鈴木 (@ken5scal )です。 ※三井物産デジタル・アセットマネジメントに出向しています。 今回は、AWS IAMポリシーの条件における「ForAllValues」の仕様を誤って理解していたことから、安全でないアクセス制御を実装していたという内容です。もし同様の勘違いをされている方がいたら参考になれば幸いです。 ユースケース AWS IAMユーザーを、ロールの trust policy がユーザーのタグで制御するケースで考えます。 具体的には、「Group A あるいは Group B」に所属し、且つ「Admin」権限のあるユーザーのみが行使できる役割「AdminABRole」があるとしましょう。 この場合、Group と Admin のタグが存在し、下記のようなパターン（※）が考えられます。
こんにちは。マネーフォワードのgotoken（@kennygt51）です。 突然ですが、マルチアカウントAWS環境の管理業務をおこなっている皆さん、AWS SSOやってますか？？ 当社のAWS環境の改善活動に取り組む中で、AWS SSOの便利さにすっかり虜になってしまいました。 今回の記事では僕が業務で取り組んだ『150超のAWSマルチアカウント環境における「AWS SSO」の設定をTerraform管理に移行した話』について紹介します AWSアカウントへのアクセスコントロールの歴史 AWS SSOやTerraform管理の話をする前に、当社のAWSアカウントへのアクセスコントロールの歴史を紐解いてみましょう。 はじめてのAWS SSO 2020年の初め頃、当社のAWS環境にAWS SSOがはじめて導入されました。それ以前は、踏み台用のAWSアカウントにのみIAMユーザを作成し、アクセスし
. ├── backend.conf ├── main.tf ├── registry.tf ├── terraform.tfvars └── variables.tf main.tfでは、terraformのバージョン指定とサービスアカウントのroleの指定が定義されています。repo_nameは権限を与えるgithubリポジトリなので、この段階で連携するリポジトリを決めておく必要があります。 terraform { required_version = "~> 1.1.9" backend "gcs" { prefix = "terraform/state" } } locals { cloudrun_roles = [ "roles/run.developer", "roles/iam.serviceAccountUser" ] } resource "google_project_
「Security-JAWS【第32回】」での登壇資料です。 イベントURL：https://s-jaws.doorkeeper.jp/events/167836
データシステム担当の黒瀬です。 こちらは、TVer Advent Calendar 2022の9日目の記事です。 この記事では、TVerで運用しているデータシステムの基本的な権限管理ポリシーについてご紹介します。 大まかな内容 GCP上に構築しているデータシステムをメンテナンスする際の権限を、従来は管理者が手動管理していたが、この運用にはリスクがありました。 そこで、権限を付与するためのサービスアカウントを経由する仕組みおよびその趣旨を明確にするルールを導入しました。 結果、管理者に依存せずにメンテナンスができる運用が可能になりました。 背景 TVerでは、主にBigQueryに視聴ログなどのデータを集約し、その上で集計や分析をするという方針をとっています。 ログを収集するシステムはAWSやGCPなど要件に合わせて各所に構築されていますが、これらからBigQueryへデータを収集・集約する
かなりしんどいので漏洩しないのがいちばんです。それでも万が一やってしまったときは、落ち着いて対応しましょう！ オペレーション部加藤(早)です。 AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 はじめに AWSアクセスキー/シークレットキーの漏洩により不正利用が発生すると、緊急の対応が必要な上かなりの工数も取られて相当しんどいです。 なので本当は漏洩させないのが１番です。が、万が一の時慌てて二
ども、ゲストのNTT東日本 大瀧です。 本日IAMロールAnywhereがリリースされました。IAMロールAnywhereは、AWSの認証基盤であるIAMの認証をPKI(公開鍵基盤)に外出しできる仕組みです。本ブログでは、手軽に試せるPKIとしてHashicorp Vaultを試す様子をご紹介します。 動作確認環境 OS : Ubuntu 20.04.4 LTS Vault : バージョン v1.11.0 AWS : 東京リージョン 1. Hashicorp Vaultのセットアップ まずはPKIのCA(認証局)となるVaultサーバーを立ち上げます。Vaultのダウンロードページの [Linux] - [LINUX BINARY DOWNLOAD]で Amd64 のリンクをコピーし、 wget の引数にしてダウンロードします。 $ wget https://releases.hashic
背景 去年7月にIAM Roles Anywhereがリリースされ、アクセスキー管理が不要でAWSの外部のリソースに対してIAMロールを割り当てるできるようになりました。 しかし公式のドキュメントには自己署名証明書を作成する方法が記載されていませんし、現在ネット上に上がっている記事では手順も複雑でなかなか容易に作成できないものが多いと感じました。 なので今回はIAM Roles Anywhere + 自己署名証明書を爆速で作成する方法を紹介します。 また、GitHub上にIAM Roles Anywhere作成のスクリプトも公開していますので、良かったらご活用ください。 1. cfsslのインストール まずはcfsslをインストールします。cfsslは簡単にCSR、秘密鍵を作成できるツールです。 opensslですといろんなオプションを指定しないといけないし、アルゴリズムを間違えたら信頼ア
IAM ユーザーだけでなく IAM ロールも棚卸ししたい コンバンハ、千葉（幸）です。 以前、IAM ユーザーを棚卸しする方法をまとめたことがありました。ここでは以下情報を取得することで IAM ユーザーがどのような権限を有しているかを確認しました。 IAM ユーザーが所属する IAM グループの一覧 IAM グループにアタッチされた管理ポリシーの一覧 IAM グループにアタッチされたインラインポリシーの一覧 IAM ユーザーに直接アタッチされた管理ポリシーの一覧 IAM ユーザーに直接アタッチされたインラインポリシーの一覧 ここで、ひとが使う IAM エンティティとして IAM ユーザーでなく IAM ロールがメインの環境もあるでしょう。となると IAM ロールを対象に同じことをしたいです。とは言え、AWS サービスが使用する IAM ロールは別に対象に含みたくないです。 うまいことやる
はじめに 概要 従来IAMユーザでローカルからAWSリソースを操作したい場合、アクセスキーを発行し、端末に設定する必要がありました。アクセスキーは長期認証情報にあたり、漏洩した場合は大きな被害につながる可能性があるため慎重に管理する必要がありました。 そんな中発表されたのが、AWS CLIのaws loginサブコマンドです。 端末でaws loginコマンドを打つと、マネジメントコンソールの認証情報（またはフェデレーション認証情報）を用いてブラウザベースで認証が行われます。IAMユーザはローカルにアクセスキーを保持することも、発行することもなくAWSリソースを操作することができるようになりました。 最初からブラウザ認証に対応しているIAM IdC（旧AWS SSO）が使えない環境も少なからずあるので個人的には待望のアップデートです。 要件 利用にあたっての要件はAWS CLIユーザガイド
こんにちは。Flatt Securityの@toyojuniです。 "エンジニアの背中を預かる" をミッションに、日々プロダクト開発組織のセキュリティを意思決定から技術提供までサポートするべく奮闘しています。 さて、Flatt Securityはこの度3月2日(土)に池袋サンシャインシティにて開催されたJAWS DAYS 2024にPlatinum Supporterとして協賛し、ブースを出展させていただきました！ このイベントは日本全国に60以上の支部をもつAWSのユーザーグループ「JAWS-UG」が主催するもので、参加は有料でありながら1000人以上が参加者として登録している非常に大規模なものです。当日も大盛況でした！ 日々AWSを用いてプロダクト開発・運用に向き合う皆様と直接お話しする機会は、我々にとって貴重なものでした。当日ブースにお越しいただいた皆様、ありがとうございました！ 「
こんにちは。 SRE の @suzuki-shunsuke です。 AWS IAM の管理を miam から Terraform に移行した話を紹介します。 なお、 AWS や miam に限らず「Terraform で管理されていない大量のリソースを Terraform で管理する」ことを検討している方には参考になる内容かと思います。 背景 本ブログでも何度か紹介したとおり、弊社では AWS のリソースを Terraform で管理しています。 しかし、実は IAM に関しては miam という別のツールで主に管理されていました。 miam は AWS IAM を管理することに特化したツールです。 miam には以下のような特徴があります。 Ruby の DSL によって柔軟にリソースの定義ができる miam によるリソース管理を強制できる DSL で定義されていないリソースは削除されて
Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment | Amazon Web Services
AWS for Industries Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment AWS financial services industry (FSI) customers often seek guidance on how to set up their AWS environment and accounts for best results. AWS has created a unified set of recommendations, called the multi-account strategy, to help customers like you make the best use of your AWS resource
マネージドサービス部 佐竹です。 本ブログでは、2025年10月20日(月)より発生しておりました AWS us-east-1 リージョンの障害に関連し、仮説を含めた技術的な考察を行いたいと思います。 はじめに：本ブログの立ち位置 2025年10月 us-east-1 障害の概要 10 ステップで理解する障害の概要 STS グローバルエンドポイントの透過的リージョン分離についての参考情報 前提：「STS」とは何か？ 過去の課題：STS の us-east-1 への潜在的依存状態 AWS が行った STS における「見えない改善」 参考情報 仮説検証：もし STS リージョン分離が完了していなかったら？ シナリオ1：グローバル認証基盤の停止 シナリオ2：全世界への障害連鎖 シナリオ3：壊滅的な影響 STS リージョン分離と障害に関する今回の学び 2025年10月24日 追記 Redshift
2021/11/17 に行われた下記AWSイベントの登壇資料です。 なぜあの会社は少人数でもシステム運用ができるのか？ 〜工夫を凝らし効率的に運用しているお客様事例祭り https://awsonlineseminar.splashthat.com/
Amazon Web Services ブログ AWS 請求、コスト管理、アカウントコンソール権限の変更 この記事は、 Bowen Wang が2023 年 1 月 10 日に投稿した “Changes to AWS Billing, Cost Management, and Account Consoles Permissions” を翻訳したものです。 このブログは、古い IAMアクションから新しいきめ細かな IAM アクションへの移行を完了していないアカウントのみ適用されます。2023 年 3 月 7 日 午前 4 時 (日本標準時) 以降に作成されたアカウントまたは AWS Organizations 組織に所属している場合、既にきめ細かな IAM アクションが適用されているため、このブログは対象外です。 AWS はサービスプレフィックスaws-portalと、発注書ネームスペース
今まで GitHub Actions から AWS を OIDC (OpenID Connect) で連携する場合にサムプリントを取得して ID プロバイダを作る必要があった💡しかし，2023年6月27日に GitHub Changelog でサムプリントを2種類設定するという記事が公開されて対応することになったけど，2023年7月6日から AWS 側で自動的に証明書の検証をしてくれるようになって，特に気にする必要がなくなった．結果的に適当なサムプリントを指定しておけば良く楽になった👀 動作確認をする機会があったので簡単にまとめておこうと思う． github.blog ちなみに「2023年7月6日」という日付は AWS から送られてきたメールに載っていた📩 [NOTIFICATION] OpenIDConnect (OIDC) errors when using GitHub OID
プレビュー ではありますが、昨年 AWS Verified Access の非 HTTPS(S) プロトコルがサポートされました。 本エントリでは、Verified Accessを使用して、プライベートサブネット上にある EC2 にリモートデスクトップ接続する方法を紹介します。 以下のブログを参考に設定しました。いつもありがとうございます。 やってみた 検証環境 検証環境の構成図は以下のとおりです。 IAM Identity Center で認証されたユーザーであれば、インターネットから Verified Access を経由し、プライベートサブネット上の EC2 にリモートデスクトップ接続できます。 Verified Access 信頼プロバイダーの作成 Verified Access 信頼プロバイダーを作成します。 ポリシー参照名は 32 文字以内であることと、ハイフンをサポートしてい
Simplified developer access to AWS with ‘aws login’ | Amazon Web Services
AWS Security Blog Simplified developer access to AWS with ‘aws login’ Getting credentials for local development with AWS is now simpler and more secure. A new AWS Command Line Interface (AWS CLI) command, aws login, lets you start building immediately after signing up for AWS without creating and managing long-term access keys. You use the same sign-in method you already use for the AWS Management
コンバンハ、千葉（幸）です。 2021年11月17日、皆さんはこれがなんの日付だか分かりますか？ そうですね、IAM 評価論理フローチャートが刷新された日ですね。 Document history for IAM - AWS Identity and Access Management 単一のアカウントにおけるプリンシパルからのリクエストが許可されるか拒否されるか、その評価ロジックを表したフローチャートです。親の顔より見た、という方も多いのではないでしょうか。 IAM はとにかく複雑なので一枚の図で漏れなく表現することはできないのですが、従来のものと比較してより詳細に、より正確に評価の流れが表されるようになりました。 穴が開くほど見つめていきましょう。 まとめ 鬼門はリソースベースポリシー、そしてセッションプリンシパル 新旧フローチャート比較 変更が加わったのは以下ページです。 アカウント
DevelopersIO 2021 Decadeでビデオセッションを公開しました。 概要 CloudFormationをデプロイするユーザのアクセスキーが漏れてしまったら？と心配するあなたへ。 AssumeRoleを活用すれば、アクセスキーが漏洩しても被害が最小限になるIAMユーザでデプロイできます。 動画 スライド コメンタリー テーマ選定の理由は、自分が知りたかったから ある程度、AWSを使っていると、画面ボタンポチポチではなく、Infrastructure as Code(IaC)で管理することが多くなります。AWSでIaCを実現するツールはいくつかあります。 AWS CloudFormtaion AWS SAM AWS CDK Serverless Framework Terraform そして、これらのIaCツールとIAMユーザの「アクセスキー」は、切っても切り離せない関係です（
PKIベースでAWSのIAMロールを使える IAM Role Anywhereが発表されました。早速使えるようだったのでOpenSSLでCA構築して使ってみた手順を残しておきます。 環境汚さないためにDocker使っています。 AWS Identity and Access Management introduces IAM Roles Anywhere for workloads outside of AWS What is AWS Identity and Access Management Roles Anywhere? - IAM Roles Anywhere Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere | AWS Security Blog [HostOS] RootCA用のDo
ジョブ管理システムから抜け出したくないですか? こんにちは、のんピ です。 皆さんはジョブ管理システムから抜け出したいと思ったことはありますか? 私は常に思っています。 ジョブ管理システムとは、バッチ処理やOSの起動の一つ一つの処理をジョブとして、制御・運用をするシステムです。 ジョブ管理システムを使うことによって、定型業務を自動化するなどのメリットがあります。 しかし、私が思うに、ジョブ管理システムが便利だからこその辛みもあると思っています。 私が感じるジョブ管理システムの辛いところを以下にまとめます。 ジョブ管理システムで全てのシステムのジョブネットを管理しているがために、ジョブ管理システムのメンテナンスが大変 ジョブ管理システムが停止すると、全てのシステムに影響があるため、高い可用性が求められる ジョブ管理システムによっては、エージェント毎にライセンスの購入が必要になり、大量のクライ
はじめに マルチアカウント環境ではIAM Identity Centerを使ってメンバーアカウントへログインすることが多いかと思います。 今回は特定のIAM Identity CenterユーザーのみAssumeRoleできるIAMロールを作成してみました。 前提 この記事ではマルチアカウント環境を前提としているため、以下については既に有効化・作成されているものとして進めます。 Control Tower or Organizations IAM Identity Center メンバーアカウントへログインできるIAM Identity Centerユーザー IAM Identity Centerユーザーが利用するアクセス許可セット 今回は以下２つのIAM Identity Centerユーザーを作成して、Administorator権限のアクセス許可セットでログインしています。 User
「AWSアカウントのクリーンアップにaws-nuke + GithubActionsいいぞ」 aws-nukeとGithubActions組み合わせたAWSアカウントのクリーンアップの仕組みを作って、運用してみた話です。 会社や個人の検証用アカウントのクリーンアップに悩んでいる方の参考になると嬉しいです。 背景 クラスメソッドでは、選考プロセスに実技試験があるポジションもあります。 私の所属しているAWS事業本部 コンサルティング部では、実技試験でAWSアカウントを使用します。 AWSアカウントにリソースを色々立ててもらうのですが、放置するとコストが発生するため試験終了後はリソースは削除する必要があります。 今までは、実技試験後に削除スクリプト + 一部手動でクリーンアップを行なっていました。 削除スクリプトで対応していないリソースやCLIでしか消せないリソースがあるなど、クリーンアップ作
SREチームの藤原です。 今回は CEL(Common Expression Language) を使って、AWSのIAMポリシーを検索するツールを作ったので紹介します。 github.com 3行でまとめ CEL (Common Expression Language)の式を指定してAWS IAMポリシーを検索するツールをOSSとして作りました。GetAccountAuthorizationDetails APIで取得したIAMポリシーをCELで評価して、マッチするものを出力します 例えば「lambda:GetFunctionがあるがlambda:ListTagsがないポリシーを探す」などができます AWSからたびたびやってくる、IAMポリシーに関するお知らせに対応するのに便利です 突然の「Action Required」 ある日、AWSからこんなメールが届きました。 Lambda Ge
これは Livesense Advent Calendar 2022 DAY 4 の記事です。 こんにちは。アルバイト事業部エンジニアの@mnmandahalfです。 今日は先日開催された社内LT大会で話したネタを記事にしてみたいと思います。 VPoEだけが追い出された？！エンジニアLT大会を開催した話 - LIVESENSE ENGINEER BLOG TL;DR クロスアカウントで暗号化したRDSスナップショットを共有するときはCMKで暗号化した方がベター CMKを作るときのキーポリシーに注意しよう やりたかったこと ざっくり説明すると、以下の通りです。 本番環境（以下、AWSのproductionアカウント）のDBデータをステージング環境（以下、AWSのstagingアカウント）に日次で同期して利用したい その際、個人情報等にアクセスできないようにマスキング処理（例：データの削除、改
はじめに AWSを学習していると、認証と認可という言葉がでてきます。特にIAM（AWS Identity and Access Management）によって権限を管理する際に、この考え方はとても重要になりますが、初心者である私はこれまで認証と認可の違いについて意識してこなかったため、理解するのが難しいと感じました。エンジニアの方に具体例を教えてもらい分かりやすかったので、自分でも身の回りにある認証と認可について考えてみました。 認証と認可とは 認証とは 「あなた誰？」を確認します。 本人確認書類、IDとパスワード、顔認証、指紋などの生体認証などを用いて、あなたが誰であるのかを特定するのが認証です。 認可とは 「何の権限持ってる？」を確認します。 条件を満たすことにより、許可を与えられます。 日常にある認証と認可 日常にも認証と認可はあります。身近な例についていくつか考えてみました。 運転
IAM の評価論理、完全に理解した。 コンバンハ、IAM 評価論理おじさん（幸）です。 私としたことがしばらく気づいていなかったのですが、2021年10月5日に IAM の AWS ドキュメントで激アツな更新がされていました。 Document history for IAM - AWS Identity and Access Management （機械翻訳）リソースベースのポリシーや同一アカウント内の異なるプリンシパルタイプの影響についての情報を追加しました。 これまで、同一アカウントの IAM 評価論理でリソースベースポリシーによる Allow が最終的にどのような評価をもたらすか、「プリンシパルごとに異なる動作をする場合がある」という記載がされていました。 え……その詳細が分からないと困るのでは……という状態でしたが、ついにプリンシパルごとの挙動の違いが記載されました。 「プリンシ
技術本部 Eight Engineering Unit（社内通称：Eight EU）の秋本です。普段は Eight をインフラ面からお世話することでご飯を食べています。 酷暑が続いていますね。酷暑は人々の健康を害し、健康が害されると稼動可能な人員が減り、人員が減ると業務負荷が増え、業務負荷が増えるとオペミスが発生しやすくなります。オペミスが発生してもバックアップがあれば最悪なんとかできる事が多く、もはや運用作業にはバックアップ取得が欠かせぬものとなっています。 本項では Eight におけるバックアップ取得の前史を述べ、そのうえで AWS Backup を導入していい感じになった風景を述べるものになります。 AWS Backup 導入まで Eight で使用しているデータの置き場所は以下があります。Eight では現状 AWS のみを使用しています： サービス 用途 S3 名刺画像データ、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS 請求、コスト管理、アカウントコンソール権限の変更 | Amazon Web Services
