Serverless Web Hosting Strategy For Modern Front-end Application
中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い(そんな状況あるのか?)という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない! ちょっとそこのハ○キルーペ貸してくれーw
はじめに 中山(順)です 4年ほど前にこの記事のタイトルと同じテーマで資料を作成したことがあるのですが、古い内容があったり新しいサービスのことが含まれていなかったりするので改めてまとめてみました。令和だし! その時の資料はこちらです(クラスメソッドにジョインするくらい2年前です)。 AWSアカウントを作ったら最初にやるべきこと サインアップ (業務利用の場合)非個人メールアドレスでサインアップ サポートプランの確認 ID管理 / 権限管理 CloudTrailの有効化 ルートアカウントのMFA設定 IAM User / IAM Groupの作成 パスワードポリシーの設定 GuardDutyの有効化 Security Hubの有効化 請求 IAM Userによる請求情報へのアクセス許可 支払通貨の変更 Budgetの設定 Cost Explorerの有効化 Cost Usage Report
はじめに 先日、Amazon Linuxで脆弱性が見つかった際に弊社のAWSチームのメンバーが以下の記事を公開していました。私は最近までクライアントサイドの開発案件を主に担当していたので自分の業務にはあまり関わりはないのですが、どのような手順でLinuxの脆弱性に対応しているのか興味があったので社内の人に聞いたり調べてみたことをまとめます。 [AmazonLinux] OpenSSLの脆弱性(CVE-2015-1793)について 1.脆弱性の情報を得る まずは脆弱性が見つかった情報はどこから得るのでしょうか?脆弱性に関する情報は以前から以下のサイトのRSSなどから情報を得ることができますが最近はTwitter見てたら知った、なんてこともあるそうです。 Japan Vulnerability Notes JPCERT コーディネーションセンター 以下はTwitterのアカウントです。 JVN
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く