タグ

awsに関するbasementjaxxのブックマーク (32)

  • GCP / AWS / Azure のコンプライアンス 決定版 | クラウドエース株式会社

    こちらの記事は弊社技術ブログに掲載していた内容となります。一部を除き、投稿当時の情報となりますので、紹介内容の最新情報については別途公式情報等をご参照下さい。 こんにちは。クラウドエース編集部です。 コンプライアンスを把握する必要性 多くの企業や官公庁はオンプレミスの時代からデータセンターや SIer の選定などで ISO や PCI DSS を取得しているかどうかのチェックを行っています。記事はメガクラウド(GCP / AWS / Azure)が独自監査を実施しているコンプライアンスを表でまとめています。オンプレミスからクラウドへの移行、クラウドからメガクラウドへの移行検討の際に参考にしてみてください。 オンプレミスからクラウドに移行する際には、様々な検討を重ねるのが通常です。検討する内容としては、クラウド上でのアーキテクチャ、スペック、コスト、セキュリティ、運用など、様々な項目があり

    GCP / AWS / Azure のコンプライアンス 決定版 | クラウドエース株式会社
  • AWSアカウントを作成したら最初にやるべきこと -セキュリティ編- - Qiita

    JAWS-UG 初心者支部 #22 ハンズオン用の資料です。 目的 AWSアカウントを不正利用されないために、アカウントを作成したらまずやるべきセキュリティ周りの設定を行います。 前提 AWSアカウントを作成済みであること AWSアカウントにログインしていること リージョンは東京リージョンを利用します ハンズオン手順 アカウント周りの設定 ルートアクセスキーの削除 ※ルートアカウントのアクセスキーは、デフォルトでは作成されておりません。アクセスキーを作成済みの方を対象とします。 ルートアカウントは全てのサービスへのアクセスが出来てしまうため、ルートアカウントは使用せず、IAMユーザーを使用しましょう。 CLI等のプログラムアクセスも不要なため、アクセスキーを削除します。 https://console.aws.amazon.com/iam/home#/security_credential

    AWSアカウントを作成したら最初にやるべきこと -セキュリティ編- - Qiita
  • サーバーレスパターン

    やりたいこと(ユースケース)から利用パターンへ到達できるように、ユースケース主導で紹介。利用するサービスのすべての機能をを覚えなくてもやりたいこと/部分からスタートできます。実際、類似するアーキテクチャの実例が多くあることがわかります。 パターン別のテンプレートから始めてみよう!  チュートリアルで体感しよう! - いくつかのパターンはテンプレート/雛形から始めることができます。それぞれのパターンの「Template」「Sample」「Solution」のリンク先を参照ください。 - 実際に作って動かせるチュートリアルに「Tutorial」「Workshop」リンクからアクセスできます。ちょっとしたトライに費用が気にならないのもサーバーレスの良いところ。 - 各パターンの特性に合わせたエラーハンドリングの記事を拡充中。それぞれのパターンの「エラーハンドリング」リンクからご確認ください。 -

    サーバーレスパターン
  • まだログイン認証で消耗してるの? ~ALBで簡単認証機構~ - Gunosy Tech Blog

    こんにちは!広告技術部のUT@mocyutoです! 最近はスマブラでなんのキャラを使おうか迷っています この記事はGunosy Advent Calender 19日目の記事です。 昨日の記事は@mathetakeのpeer-to-peerはGoogleの夢を見るかでした。 はじめに OIDC ALBの認証機能 一般的な認証機構 ALBを利用した認証 データフローの説明 実際の導入 APIでjwtから認証情報を取得する例 まとめ はじめに みなさんユーザ認証はどうやって作っていますか? フレームワークを使って実装していますか? それともイチから自前で作っていますか? SSOのシステムとかはどうでしょう? OIDCとAWSのALBを使えば簡単にユーザのログイン管理を作ることができます。 (少し煽り気味のタイトルですいません ;) OIDC OpenID Connect と言って、OAuth2

    まだログイン認証で消耗してるの? ~ALBで簡単認証機構~ - Gunosy Tech Blog
  • AWSを使うときに確認すべき52のセキュリティチェック項目と15分でできる簡単なチェックの方法|DevelopersIO

    はじめに 自分が使っているAWS環境のセキュリティに問題がないかと心配になることはないでしょうか?私はよくあります。そこでCIS Amazon Web Service Foundations Benchmark というAWSセキュリティのガイドラインに沿って使っているAWSアカウントのセキュリティの状況をチェックしてみました。チェック項目は全部で52あります。内容を一通り確認したところ知らなかったAWSセキュリティの機能やノウハウを知ることができ、見ただけでもとても勉強になりました。簡単にチェックする方法も併せて紹介しますのでぜひ使っているAWS環境でチェックしてみてください。 1 IAM 1.1 rootアカウントを利用しない rootアカウントは強力な権限を持つため、rootアカウントを利用せずIAMユーザーを利用してください。通常運用でrootアカウントが利用されていないか確認し

    AWSを使うときに確認すべき52のセキュリティチェック項目と15分でできる簡単なチェックの方法|DevelopersIO
  • 【AWS】アカウント契約の準拠法をワシントン州法から日本法に、管轄裁判所をワシントン州キング郡州裁判所から東京裁判所に変更する方法 - Qiita

    AWS】アカウント契約の準拠法をワシントン州法から日法に、管轄裁判所をワシントン州キング郡州裁判所から東京裁判所に変更する方法AWS要件定義契約非機能要件AWSArtifact はじめに AWSを利用しているプロジェクトのリーダーは一読ください。 AWSアカウント契約の準拠法と、管轄裁判所を変更する手順をまとめます。 お客様のAWS環境を自社が代行して契約しているようなケースの場合、米国法のままになっている可能性があります。後述するAWS Artifactから、番環境で使用しているAWSアカウントの準拠法を確認することをお勧めします。 AWSを使うプロジェクトでPLが意識すること RFPや要件定義時の非機能要件の確認事項として、「クラウドサービスの準拠法が日法であること」 を確認されたほうが良いと思います。 AWSとの契約のおさらい AWSは米国企業であるため、たとえ東京リージョン

    【AWS】アカウント契約の準拠法をワシントン州法から日本法に、管轄裁判所をワシントン州キング郡州裁判所から東京裁判所に変更する方法 - Qiita
  • AWS、何から勉強したらいい?に対する俺の答え - Qiita

    このツイートがわりと好評だったので解説。 「AWS、何から勉強したらいい?」に対する俺が考えた回答がこれ。 pic.twitter.com/ouuP3P27Bu — 伊藤 祐策(パソコンの大先生) (@ito_yusaku) 2018年4月17日 これは誰向け? メンテナー以上の領域を目指す人向け。 オペレータ ... システムの運用、監視、障害調査&対応をする人 メンテナー ... システムの拡張、改善をする人 アーキテクト ... システムを1から設計、構築する人 解説 各科目の選定基準 必修科目 ... AWS番運用するにあたって絶対に避けては通れないサービス。 重要科目 ... 間違った設計をすると、あとから取り返しがつかないサービス。 選択科目 ... 学習量を削るために仕方なく必修から外したが、Webサービスを構築するにあたりほぼ必須となるサービス。 必修科目で押さえておく

    AWS、何から勉強したらいい?に対する俺の答え - Qiita
  • S3 の事前署名付き(期限付き)URL を生成する

    S3 見習い兼 PHPRuby 初心者のかっぱ(@inokara)です。 はじめに 既にご存知の方もいらっしゃると思いますが、Amazon S3 の各バケットに保存されているコンテンツ(オブジェクト)に期限をつけてアクセスさせることが出来る機能(以下、「期限付き URL 生成機能」)があります。これは一時的に一部の方にだけファイルをダウンロードさせたい時等に非常に便利な機能だと思います。 Uploading Objects Using Pre-Signed URLs この期限付きの URL 生成方法について AWS SDK for PHPAWS SDK for Ruby の二種類を利用した手順を簡単にまとめてみたいと思います。 尚、上記のドキュメントでは Pre-Signed URL(事前署名付き URL)とありますが、記事はタイトルを除いて、全編を通して期限付き URL と

    S3 の事前署名付き(期限付き)URL を生成する
    basementjaxx
    basementjaxx 2018/04/17
    “AWS SDK for PHP”
  • Scout2

    Description Scout2 is an open source tool that helps assessing the security posture of AWS environments. Using the AWS API, the Scout2 Python scripts fetch CloudTrail, EC2, IAM, RDS, and S3, configuration data. The gathered configuration is analyzed and stored as JSON objects in several JavaScript files. These files are imported in the Scout2 HTML report, which allows for a quick and efficient rev

    Scout2
  • 今だから!Amazon CloudFront 徹底活用

    Yasuhiro Araki, Ph.DSenior Manager, Solutions Architect at Amazon Web Services

    今だから!Amazon CloudFront 徹底活用
  • AWS料金早見表

    サーバレスアーキテクチャ構成にしたときに 実際のところ、どれくらいの料金になるのか気になったので算出してみようと思います。 (あくまでシミュレーションしたものでAWS側で値段や計算方法が変わったりするため、責任は負いかねますので導入する際は自己責任でお願いします。) AWSのどこにどれくらいの料金がかかっているのか知ることは大事だと思ったのですが、トータルだとなかなかまとまってなかったのでまとめてみました。 間違ってたらご指摘いただけると助かります。 サーバレスアーキテクチャって何?って方はこちら参照してください 世界に先駆けてAWSサーバレスアーキテクチャでユーザ認証とAPI認可の実装をしてみた AWSサーバレスアーキテクチャでCloudFrontからWAFをかけてAPI Gatewayを呼ぶ Lambda+RDSはアンチパターン 全部教えます! サーバレスアプリのアンチパターン とチュ

    AWS料金早見表
  • Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く

    AWSの米国東部リージョン(US-EAST-1、バージニア北部)において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日

    Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
  • AWSバッドノウハウ集 2017/02 - Qiita

    おことわり 主観であり何らかのデータにもとづいてはいない この記事に書いてあることは信じずに自分で試そう EC2 t2 ファミリーは他ファミリーと比べて不安定 どのインスタンスもいつかは死ぬという点では共通なのですがそのなかでもt2は故障したり不具合が発生したりする確率が非常に高い気がする なので死んだり、死にかけ状態で動き続けたりしてほしくないインスタンスはあんまりリソースを使わなくても t2.micro とかじゃなくて m3.medium にしとくとすこし可用性があがる 追記: CPUクレジット理解していないだけではとか書かれていたんですがその辺は確認している。 t2の可用性が問題になったケースいくつかあるんだけど、自分の場合はネットワークがたまに断する問題が多くて、分散DBクラスタの死活監視で1secごとにpingするだけでCPUは常に1%以下みたいなものとかに使うとカジュアルに10

    AWSバッドノウハウ集 2017/02 - Qiita
  • LINE Bot API の HTTPS Callback は Amazon API Gateway を使うと簡単便利安価で最高 - おともだちティータイム

    追記 (4/15) 現在は Let's Encrypt の証明書が利用できるようになっているようです。なので「https で Callback が受け取れない」と言う理由のためだけに Amazon API Gateway を使う必要も無くなりました。 LINE Bot API は Callback URL が https のみで、しかも Let's Encrypt や StartSSL と言った無料の証明書が使えない。どうにか安価で Bot を動かしたいとなると Heroku のようなドメインを指定しなければ Wildcard 証明書が割り当てられている PaaS を使うのが一般的でしょう。 しかし Heroku は外に抜ける IP アドレスがどんどん変わっていくので、 Bot API の IP Whitelist に登録することが出来ない。仕方無いので Heroku に rack-rev

    LINE Bot API の HTTPS Callback は Amazon API Gateway を使うと簡単便利安価で最高 - おともだちティータイム
  • AWSを一年使ってみて、最初から知っておけば良かったこと

    AWSを使い始めて約一年が経過したので、この一年を振り返ってみて、最初から知ってた方が良かったな〜と思ったポイントをピックアップしてみました。 IAMロールはName変えられないし付け替えもできない件勢いだけで作ったIAMロールを付与して意気揚々と運用開始!数ヶ月後に付け替えできない事に気付いて、ec2ctrlとかいかにもEC2インスタンスをコントロールするためのロールなのに、なぜかS3の全権限付与してたり、もはや名前から予測できない事態になってしまったという話。 まぁ、別にオオゴトでは無いんですけどね。インスタンス作り直せば付け替えできるし、新しいロール作ってインスタンス作り直せばいいだけの話です。やるかやらないか。 やりませんけど! VPCVPN接続はリージョン毎に1つしか設定できなかった件IDC側のグローバルIPが複数用意できない前提ですが、IDCとAWS(VPC)間でのVPN接続

    AWSを一年使ってみて、最初から知っておけば良かったこと
  • まさに実践入門!!「Amazon Web Services 実践入門」 - プログラマでありたい

    舘岡さん(@iara)さんに、Amazon Web Services 実践入門を頂きました。ありがとうございます!! 早速読んでみましたが、実践入門という名前に違わず入門なのに実践的という内容にまとまっていました。その辺りは、著者陣の経験の深さがにじみ出ています。著者陣は、舘岡さんを筆頭に、今井さん、永淵さん、間瀬さん、三浦さん、柳瀬さんとAWS界隈のスーパースターたちです。それぞれの所属する会社は、日で5社しかないAWSのプレミアパートナー、従来の情報システム部の常識をスーパーのパックの刺身のツマほどの価値しか認めず常に大胆かつ合理的な方法でAWSを利用し周囲を驚かせるハンズラボ、オンラインによる名刺管理という業界を作りリーダーとして君臨するSansanの中の人とAWSを知り尽くした人々によって書かれています。 Amazon Web Services 実践入門が実践的な理由 書で取り

    まさに実践入門!!「Amazon Web Services 実践入門」 - プログラマでありたい
  • 単一のAWSアカウントに潜む重大な危険 | POSTD

    Amazon WebサービスAWS)のアカウントは、AWSでビジネスを展開している人にとって非常に大事なものです。ですが、AWSアカウントをたった一つしかもっていない場合、重大なセキュリティの危険に直面することになるでしょう。何が問題なのか、そしてどうすれば解決できるのかを、この記事でご紹介したいと思います。 危険性をはらむデフォルト設定:単一のAWSアカウント 単一のAWSアカウントには、EC2仮想サーバ、S3バケット、RDSデータベースなどビジネスに必要な様々なリソースとともに、IAMユーザが含まれています。アカウントへのログイン方法は基的に2通りあります。ユーザ名とパスワードを入力するAWS Management Console、またはCLIやSDKで用いられるAWSアクセス認証情報を使うのです。以下の図は、その仕組みを示したものです。 訳注 account「このアカウントにはI

    単一のAWSアカウントに潜む重大な危険 | POSTD
  • お名前.comからAmazon Route 53へドメインを移管する | DevelopersIO

    こんにちは、虎塚です。 Amazon Route 53でドメインが管理できるようになって数ヶ月がたちました。Route 53では、Amazon Route 53でドメインを購入する | Developers.IOにあるように、ドメインを新規に取得することができます。さらに、別のドメインレジストラで登録していたドメインを、移管して管理することもできます。 そこで今日は、他のドメインレジストラに登録しているドメインをRoute 53へ移管する手順を紹介します。例として、 お名前.comで管理しているドメインを想定して説明します。 ちなみに、移管手続きからAmazon側での処理完了までの所要時間は、移管元の事業者によって異なります(移管元が何も応答しなかった場合、5〜7日間かかるとのことです)。今回は約6時間でした。 はじめに この記事の内容は、AWSの公式ドキュメントをスクリーンショット入りで

    お名前.comからAmazon Route 53へドメインを移管する | DevelopersIO
  • コストを下げろと言われたら~AWSでまずやること~ - Qiita

    こんにちは。CYBIRDエンジニア Advent Calendar 9日目のgucchonです。 新卒2年目、webエンジニアです。 8日目はkeitarouさんのGitHubをもっと便利にするためのChrome拡張とかでした。 全くGitHub使えてなかったんだな…と身にしみる内容でした。お恥ずかしながら… 日の内容 「サーバ費、もっと下がらない?」 なかなか聞きたくない言葉ですね。サービスを継続させていく上では当然コスト面をしっかり考えて運用をしていかなくてはいけないのですが、まぁ正直めんd...少しばかり手間です。ただ、AWSならある程度簡単にコスト管理ができて、対応策も用意されているので助かりますね。それでも誰もやりたがらないけど(ボソッ ということで、コストを下げろと言われてしまったとき、CYBIRDのコストカッター、gucchonがまずやっていることをご紹介したいと思います

    コストを下げろと言われたら~AWSでまずやること~ - Qiita
  • 米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る

    Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10%にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました。 リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。 AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。 同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。 Chaos Monkeyによっ

    米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る