20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver
![20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver](https://cdn-ak-scissors.b.st-hatena.com/image/square/6a4bf56c66d3b916944b1a0949d38052ab7b1814/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20191016awsblackbeltroute53resolver-191018015819-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
マーケティングテクノロジーの情報やノウハウ・TIPS、エクスチュア社の情報を発信。【ブログネタ募集】ご興味のある分野を教えてください!ご要望の内容を記事に起こします!メニューの「ブログへの」リクエストよりお送りください。 menu IAMとは 「ユーザーに対してAWSのアクセスを制御する仕組み」のことです。 ※CloudFrontやRoute 53と同様、グローバルサービスなのでリージョンを気にする必要がありません。 IAM初回利用時の流れ IAMユーザー / IAMグループの登録 ルートユーザーを使用し最初のIAMユーザーを作成します。 IAMユーザーはユーザーまたはアプリケーションの実体で、構成要素は「名前」「認証情報(コンソールPW, アクセスキー)」です。 ※ここで作成したアクセスキーは共有してはいけません。もしセキュリティの侵害があった場合、IAMユーザーの削除 / PW変更など
コーヒーが好きな木谷映見です。 「IAM ってどんなもの?」という概念をざっくりと掴むことを目的として書きました。 この記事で書くこと IAM の主要概念のみざっくり説明 この記事で書かないこと 具体的な IAM の操作方法 具体的な IAM ポリシーの記述方法 AWS Identity and Access Management (IAM) とは? IAM で重要な 4 つの要素 IAM ユーザ (ユーザ) IAM ポリシー (ポリシー) IAM ユーザーグループ (ユーザーグループ) IAM ロール (ロール) 1. AWS サービス自体にアクセス権限を付与したいとき 2. IAM ユーザに、別の AWS アカウントへのアクセス権限を付与したいとき IAM のベストプラクティス 最小権限の原則 IAM ユーザーは使いまわさない 終わりに 参考 AWS Identity and Acce
みなさん、こんにちは! AWS事業本部の青柳@福岡オフィスです。 当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2020』の 16 日目のエントリです。 このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWS をこれから学ぼう!という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2020 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。 では、さっそくいってみましょう。16 日目のテーマは『Amazon Cognito』です。 AWSにおける「認証・認可
西村「はじめまして、テクニカルトレーナー/マネージャーの西村です。よろしくお願いします。」 下川「はじめまして、シニア サーバーレススペシャリスト ソリューションアーキテクトの下川です。よろしくお願いします。」 西村「早速ですが、私が実施しているトレーニングの場で聞かれる質問に関していくつか質問させてください。細かい話なのですが、“サーバレス” と “サーバーレス” のどちらの記載が一般的でしょうか ? “バ” の後を伸ばすべきかが地味に気になっています。」 下川「“サーバレス” よりも “サーバーレス” の方が、AWS ドキュメント検索時のヒット率が上がるので、“サーバーレス”と私は書きますね。」 西村「ちょっと得する話ですね、ありがとうございます。抽象的なお話ですが、サーバーレスとは何でしょう ? と聞かれたらどう応えるべきでしょうか。サーバーレスとは、サーバーがレスという表現だとシッ
前置き 今年も残り半年、4月に入社した弊社のキラキラ新卒社員は数ヶ月間の研修を終えて実際の業務に関わり始めてる様子が見られるようになりました。これから業務で開発を進めていくにあたってAWSに触れていく機会も増えていきます。 分からない事があれば社内で相談したり、サポートに問い合わせたり、今だったらChatGPTを活用するなどである程度どうにかなりますが、もっと前のめりになってAWSの事を知りたいとなった時にスムーズに必要な情報にアクセスできるように整備したいなと思い、公式をこれでもかと使い倒してもらえるようなコンセプトのまとめ記事として目指しました。 また、私自身AWS All AWS Certifications Engineerに選出されたわけですが、認定自体は何年か前に取得済みで何だったら今年は3年毎の有効期限に向けて10月から更新ラッシュが控えている事もあって改めて全体を網羅するの
基礎から学ぶ サーバーレス開発 タイトルに「AWS」が入っていませんが、AWSに限定してサーバーレス周りの開発の基礎を一通り解説した本。作者陣はCIerとしても有名なアイレット社の方々。JAWS-UG運営の方もいらっしゃいますね。そういえば2019年のAWS Summitに行った時にcloudpackのノベルティをもらった覚えがあります…… 基礎から学ぶ サーバーレス開発 CHAPTER01 サーバーレスとは CHAPTER02 サーバーレス開発でよく使うサービス CHAPTER03 サーバーレスアプリケーションの構築 CHAPTER04 サーバーレスの運用・監視 CHAPTER05 サーバーレス開発におけるセキュリティ CHAPTER06 サーバーレスの構築例 完全サーバーレスでのWebページ構築事案 APIバックエンドにRDSを用いた事例及び2019年のアップデートについて サーバーレ
弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の4日目のエントリでテーマはAWS Serverless Application Model (AWS SAM)です。 こんにちは、リサリサです。 当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の 4日目のエントリです。 このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWSをこれから学ぼう!という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂け
はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの長尾です。 WEARは2013年にリリースされ、現在8年目のサービスです。そして、2004年にリリースされた当時のZOZOTOWNと同じアーキテクチャを採用しているため、比較的古いシステム構成で稼働しています。本記事では、そのWEARのWebアプリケーション刷新とクラウド移行で実践している、Fastlyを活用したパスベースルーティングによる段階移行の取り組みを紹介します。 WEARをリプレイスする理由 WEARのWebアプリケーションは、データセンターでオンプレミス(以下、オンプレ)上で稼働しています。また、DBはSQL Serverを利用しています。長年このアーキテクチャで成長を続けてきましたが、今後さらに成長を加速させていくためには以下の3点を実現する必要があります。その実現に向け、2年前からリプレイスに
AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs(以下CW Logsと記載)とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
分割の基準を2つに絞っても、9パターンもありました。各構成を1つずつ見ていきましょう。 1. 単一のAWSアカウントを使う この構成パターンは、一見単純です。しかし、すべてのシステムを1つのAWSアカウントの中に構築するため、アカウント内の環境はかなり複雑になります。 1-1. 単一のAWSアカウント、単一のVPC default VPC以外のVPCを1つ明示的に作り、その中に複数のシステム、複数の環境を混在させる構成です 1-2. システムの種類と環境の用途でVPCを分割 システムの種類でVPCを分け、さらに本番用と開発用など環境の用途によってもVPCを分ける構成です 1-3. システムの種類でVPCを分割 システムの種類によってVPCを分けますが、開発環境や本番環境を1つのVPC内に構築する構成です 1-4. 環境の用途でVPCを分割 環境の用途によってVPCを分けますが、複数の異なる
みんなベストプラクティスできてる?「AWSセキュリティのベストプラクティスに関する利用実態調査レポート」まとめ 「Security-JAWS Insights AWSセキュリティのベストプラクティスに関する利用実態調査レポート」の解説です。みんなベストプラクティスを実践できているのか、知ることができます。 こんにちは、臼田です。 みなさん、AWSのセキュリティベストプラクティス実践できてますか?(挨拶 今回は、Security-JAWS運営メンバーが調査を実施し、レポートとしてまとめた「Security-JAWS Insights AWSセキュリティのベストプラクティスに関する利用実態調査レポート」の内容を解説するとともに、僕自身の提言をまとめます。 これを読んで頂くと、「周りのみんなはAWSのベストプラクティスどれくらいできているの?」「自分たちは十分にベストプラクティスに沿えているのか
ども、大瀧です。 本日、新しいELBとしてNLB(Network Load Balancer)がリリースされました。 NLB自体の使い方については大栗の以下の記事をご覧ください。ここでは全部で3種類になったELBをネットワークの視点から区分けしてみたいと思います。 [新機能]静的なIPを持つロードバランサーNetwork Load Balancer(NLB)が発表されました! | Developers.IO また、機能面の比較はAWS公式の以下のページが詳しいです。 Elastic Load Balancing Product Details ELBの種類と特徴 現在利用できるELBは以下の3種類で、一般名称と対応付けてみました。 [NEW!!]Network Load Balancer(以下NLB) : L4 NATロードバランサ Application Load Balancer(以下
お知らせ 2022年初頭に本記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル:AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 本書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス
クックパッドマートでサーバーサイドなどのソフトウェアエンジニアをしている石川です。 この記事では、クックパッドマートとは全然関係なく、私が正社員として新卒入社する前、2020 年初頭に技術部 SRE グループで就業型インターンをしていた際に実装したシステムについてご紹介します。 ALB のアクセスログ 弊社では AWS の Elastic Load Balancing (ELB) を多用しており、Application Load Balancer (ALB) が多くのウェブアプリケーションで利用されています。 ところで ALB はアクセスログを Amazon S3 に保存することができます。このアクセスログにはアクセス先の IP アドレスやリクエスト URL の他、レスポンスのステータスコード、レスポンスまでにかかった時間、User-Agent などの情報が記録されています。 これらの情報
AWSクラウドデザインパターンとは? AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
Eight事業部プロダクト部 Platform Group / Engineering Manager の 藤井洋太郎(yotaro) です。 さて、私が属するPlatform Groupは「アーキテクチャ刷新」「データ基盤整備」「セキュリティ」「環境整備」など多方面での開発・改善を行っています。 本記事では「ローカル開発/CI環境改善」の取り組みについて取り上げたいと思います。 早速ですが、みなさん、 テスト書いてますか? 書いてますよね、そうですよね!!!この令和時代において、テストを書いてない人がいるわけ無いですよね😇 一方で、AWSなどのフルマネージドサービスに依存するテストコード となるとどうでしょうか? ドキっとする人も多いのではないでしょうか? 外部サービスに依存するテストを真剣にやろうと思うと、意外と考えることが多く後回しになってしまいがちです。 みなさんも以下のような経
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く