タグ

awsに関するackintoshのブックマーク (47)

  • AWS FinTech リファレンス・アーキテクチャー日本版の公開について | Amazon Web Services

    Amazon Web Services ブログ AWS FinTech リファレンス・アーキテクチャー日版の公開について アマゾン ウェブ サービス(以下 AWS )は、日の金融機関の皆様が参照される FISCのガイドライン や PCI DSS, ISO27001, ISO27017 などの様々な統制やセキュリティ基準への対応をしてきました。現在ではグローバルに世界各国の金融機関やFinTech のお客様にAWS のサービスをご活用いただいております。この度そうした知見や実績を活かし、日の金融機関やFinTechのお客様が主に参照される各種のガイドラインの主要な要求事項と技術的検討が必要な項目を網羅的に確認し、「AWS FinTech リファレンス・アーキテクチャー 日版」を作成し、AWSコンプライアンスWEBサイトの日のFinTech向けのページにて公開しました。お客様は、

    AWS FinTech リファレンス・アーキテクチャー日本版の公開について | Amazon Web Services
  • AWSの新サービス群に対する一行所感 - プログラマでありたい

    今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな?認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか? 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに(≒一人の人間)が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ

    AWSの新サービス群に対する一行所感 - プログラマでありたい
  • 【速報】AWS re:Invent 2017 Keynote 1日目で発表された新サービスまとめ #reinvent | DevelopersIO

    今からキャッチアップしたい人のために! AWS re:Invent 2017のKeynote 1日目で発表された新サービスの速報記事をまとめました。ついでに、Keynote前日までに発表されている新サービスもまとめています。 Keynote Day 1での発表 AWS Elastic Container Service for Kubernetes(EKS) AWS Fargate Amazon Aurora Multi-Master Amazon Aurora Serverless Amazon DynamoDB Global Table Amazon DynamoDB Backup and Restore Amazon Neptune Amazon S3 Select Amazon Glacier Select Amazon SageMaker AWS DeepLens Amazon

    【速報】AWS re:Invent 2017 Keynote 1日目で発表された新サービスまとめ #reinvent | DevelopersIO
  • S3でIPアドレス制限をかけたい - Qiita

    バケットポリシーを以下のような感じにします。hogehogeは該当のバケットを指定してください。192.0.2.0/24と203.0.113.1からのアクセスのみを許可したい場合の設定です。 { "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "AllowPublicRead", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "s3:*", "Resource": "arn:aws:s3:::hogehoge/*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.1" ] } }

    S3でIPアドレス制限をかけたい - Qiita
  • AWS Application Load Balancer + Amazon ECS でDockerのホットデプロイ環境を構築した - Glide Note

    TL;DR AWS Application Load Balancer(以下ALB) + Amazon ECS でDockerのホットデプロイ環境を構築した ALBのTarget GroupとECSのServiceを紐付けることで、ALB配下のコンテナの入れ替えが自動で行われるようになる ALBは先日リリースされたばかりで、私もまだ色々と検証している段階なので、内容や認識等に誤りがあるかもしれないのでご容赦下さい。(詳しい人教えてください!!) その他弊社の前提情報 GitHub + CircleCIが連携済み Docker RepoにはAmazon EC2 Container Registry(以下ECR)を利用 DeployはGitHubのデプロイブランチへのマージを契機にCircleCI経由で、Docker Pushとecs-deployでDockerデプロイを実施 準備 ALBとE

  • Amazon EC2 Container Serviceで構築されたシステムでDockerコンテナを入れ替える | DevelopersIO

    はじめに ついにAmazon EC2 Container Service(ECS)がAWS管理コンソールから使えるようになりましたね! GA&東京に来たAmazon EC2 Container Service(ECS)を触ってみた #AWSSummit まだ実装されていないAPIがあったりしますが、CLIだけでなくGUIで操作が出来るというのは、格段に敷居が低くなりますね。 で、こんな用途を想定して、試してみました。 Amazon ECSでシステムを構築している。 システムにバージョンアップがあった場合、古いシステムが入ったコンテナを廃棄し、新しいシステムが入ったコンテナをデプロイして入れ替える。 やってみる Clusterなどは前述の触ってみた記事で一通り完了していると想定します。 最初のバージョンのDockerイメージを作成する 今回は静的コンテンツで構成されたWebシステムとします。

    Amazon EC2 Container Serviceで構築されたシステムでDockerコンテナを入れ替える | DevelopersIO
  • Amazon EC2 Container Service(ECS)の概念整理 - Qiita

    概念図 とりあえずECSに出てくるエンティティがそれぞれどんな多重度で関連しているのかをまとめてみました。ここからはそれぞれのエンティがどんな概念なのかを解きほぐしていきたいと思います。 図1 概念図 Serviceが中心 ECSは平たく言うと クラスター(=複数EC2インスタンスの集合)の上で Dockerコンテナを使って、 Serviceを動作させる ものです。 図2 例えばの構成 上図は、 Front Service (裏にいるAPIをCallしてWEB UIを提供するもの) API Service (ビジネスロジック、DBへの読み書きをRESTful APIで提供するもの) と言う2つのService で構成されるWEBアプリケーションの例です。 ECSで言うServiceは、Serviceは利用者から見た「サービス」よりも一段階か二段階細かいもので、APIサーバーとか、フロントサ

    Amazon EC2 Container Service(ECS)の概念整理 - Qiita
  • 「AWS is 何」を3行でまとめてみるよ - Qiita

    すべてのAWSのサービスを 3行以下でまとめました。 AWSが色々ありすぎてわからん! 3行以下で誰かまとめて!!という思いで、AWSを3行で書いてるところがなかったので自分で作りました。 掲載した金額は最小使用時のもの。無料枠や大量購入割引(Volume discount)、あと転送量でかなり変わるので、参考程度に。 以下からのカッコよすぎな見出しは AWSクラウド製品のページ からのそのままの引用です。「 広範かつ奥深いコアクラウドインフラストラクチャサービス」って僕が言ってるわけじゃない! 広範かつ奥深いコアクラウドインフラストラクチャサービス なんのこっちゃ。 よーするに「基サービスですよ」ってことらしい。基サービス多すぎだろ・・・。 い。 コンピューティング AWS is 何 いくら?

    「AWS is 何」を3行でまとめてみるよ - Qiita
  • Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD

    あるシステムを、1人のユーザから1100万人以上にスケーリングするにはどのようにすれば良いのでしょうか。Amazonのウェブサービスソリューションアーキテクトである Joel Williams が AWS re: Invent 2015 Scaling Up to Your First 10 Million Users でスケーリング方法について素晴らしいプレゼンをしています。 AWS上級者のユーザには適さないプレゼンですが、AWS初心者やクラウド初心者、Amazonが次々と送り出す新機能の流れについていけていない人が始めるには素晴らしい内容だと思います。 おおよその見当は付いていると思いますが、このプレゼンはAmazonによって提供されているため、どの問題についても解決策として提案されているものは全てAmazonのサービスになります。amazonのプラットフォームの役割は、印象深く、分か

    Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD
  • 手作業で構築した AWS リソースの管理には awspec が良いと思ったのでメモ - ようへいの日々精進XP

    tl;dr 手作業で構築した AWS リソースの管理には以前から気になっていた awspec が良いと思ったのでメモ。 二台、三台のインスタンスなら...とうっかりと手作業で構築したインスタンスや、どんな設定で作ったか判らないけど、なんとなく利用されている S3 Bucket の管理をどうしようかなと思っていたら awspec の generate コマンドがリソース情報を生成してくれるので試してみた。 参考 github.com qiita.com memo インストール $ cat Gemfile source "https://rubygems.org" gem 'awspec' gem 'rake' $ bundle 初期化 $ bundle exec awspec init + spec/ + spec/spec_helper.rb + Rakefile + spec/.giti

    手作業で構築した AWS リソースの管理には awspec が良いと思ったのでメモ - ようへいの日々精進XP
  • AWSで避けるべき5つの間違い | POSTD

    今年からAWSAmazon Web Services)クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈:(左から)DNS、CDN、静

    AWSで避けるべき5つの間違い | POSTD
  • s3fsよりも高速に使えるgoofysを試してみた | DevelopersIO

    西澤です。S3バケットを直接マウントしてファイルシステムのように使いたいケースがありますが、s3fsはややパフォーマンスに難があります。Goで書かれていてs3fsよりも高速に動作することを売りにした"goofys"というツールを見つけたので、早速試してみることにしました。 s3fs-fuse/s3fs-fuse · GitHub GitHub - kahing/goofys: a Filey System for Amazon S3 written in Go 前提パッケージのインストール 今回はAmazon Linux(Amazon Linux AMI 2015.09.1 (HVM), SSD Volume Type)環境で検証を行いました。golangとfuseパッケージが前提として必要となりますので、下記のようにインストールします。 $ sudo yum install golang

    s3fsよりも高速に使えるgoofysを試してみた | DevelopersIO
  • 【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた | DevelopersIO

    はじめに こんにちは植木和樹です。AWSでEC2と並んでよく使われているサービスがRDSだと思います。障害時のフェイルオーバーやバックアップも自動で行ってくれるため、データベースを手間をかけずに利用することができ当に便利なサービスです。 さてRDSを用いたサービスをリリースしてしばらく経つと、徐々にCPUやメモリなどの使用率が増えていき、いよいよインスタンスタイプの見直しを検討しなければならなくなるかと思います。その時に気になるのが「インスタンスタイプ変更にはどれくらい時間がかかるのか?」「サービスの停止が必要なのか?」という点です。 日はSingle-AZ/Multi-AZそれぞれのRDSについて、インスタンスタイプの変更にかかる時間や挙動を調べてみました。 今回のブログに記載したインスタンスタイプ変更の流れは、AWS公式のものでなくイベントログやDBの動きから筆者個人が「おそらくこ

    【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた | DevelopersIO
  • Elastic Load Balancing の暖気申請について | DevelopersIO

    はじめに Elastic Load Balancing の暖気申請についての申請方法や申請に必要な情報をご紹介します。 ELBの暖気運転について ELBは負荷に合わせてスケールする機能がありますがELBのスケールにはある程度の時間がかかり リクエストが瞬間的に増えたときはELBのスケールが間に合わないことがあります。 その際ELBはHTTP 503を返します。 そこで回避策としてあらかじめTVやメディアによる露出など急激なアクセス増が予想される場合に ELBの暖気申請を行い事前にELBをスケールしておきます。 注意事項としてAWSサポートプランはBusiness / Enterpriseに加入している必要があります。 ELB暖気申請フォーマット 以下、申請フォーマットの内容です。 ELB名・リージョン、またはFQDN 予測されるピーク時のリクエスト数 (requests/秒) 予想されるピ

    Elastic Load Balancing の暖気申請について | DevelopersIO
  • AWSのELBでSSLの証明書を設定する方法(2015年5月版) | 株式会社LIG(リグ)|DX支援・システム開発・Web制作

    こんにちは、まろCです。突然のお別れを経験しました。これだから出会うことを思い出にしたくないんです。いつも最後が悲しいのはもう嫌です。 さて、日はタイトルのとおり、AWSのELBでSSLの証明書を設定する事例がありましたのでそのログを記事にしたいと思います。 僕はフロントエンドエンジニアなのですが、その案件ではインフラ、バックエンド、フロントと全部担当しました。AWS自体はさわっていたのですが、久しぶりでした。 コンソールが変わっていたり日語を選択できたりしていたので、いろいろメモを残しておきたいと思い、今回記事にしました。AWSをさわる方のTipsになれば幸いです。 早速流れを追ってみましょう。 秘密鍵とCSRの生成 ELB用にパスフレーズなしのCSRを生成します。実際ELB配下に設置するEC2上で、秘密鍵から作っていきましょう。サーバーはAmazon Linuxを選択しました。 以

    AWSのELBでSSLの証明書を設定する方法(2015年5月版) | 株式会社LIG(リグ)|DX支援・システム開発・Web制作
  • AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita

    AWSアカウントを作成したら最初にやっておきたいことをまとめてみた。 あわせて読みたい 記事の内容を含めた最新の手順は、下記の書籍にまとまっている。 クラウド破産を回避するAWS実践ガイド AWSアカウント(ルートアカウント)の保護 AWSアカウントが乗っ取られると詰むので、真っ先にセキュリティを強化する。 AWSアカウントへ二段階認証を導入 AWSアカウントでのログインは、AWSアカウント作成時のメールアドレス・パスワードだけでできてしまう。心許ないにもほどがあるので、まずは二段階認証を設定しよう。 IAMのページを開く https://console.aws.amazon.com/iam/home 「ルートアカウントのMFAを有効化」を選択して、「MFAの管理」ボタンをクリック 「仮想MFAデバイス」にチェックが入っていることを確認し、「次のステップ」ボタンをクリック 注意書きを読ん

    AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita
  • amazon ec2 - Chrome: Slow 'Initial connection' to EC2 - Stack Overflow

  • AWS CLIを使ってEC2インスタンスの情報を取得する - Qiita

    はじめに AWS CLIの ec2 describe-instances コマンドを使用してインスタンスの情報を取得する方法を記述します。 環境 Amazon Linux AMI release 2014.03 aws-cli 1.4.4 jq 1.4 AWS CLIの設定 ※ 「AWS Access Key ID」「AWS Secret Access Key」「Default region name」「Default output format」を指定しておきます。 AWS CLIでEC2インスタンスの情報を取得する リージョン内で稼働している全インスタンスの情報を取得する場合

    AWS CLIを使ってEC2インスタンスの情報を取得する - Qiita
  • AWSのネットワーク設計をサボらないでちゃんとやる

    新規事業の立ち上げにAWSを選択する こういう状況はままあるでしょう。最安というわけではないけれど、将来どんな開発が必要になるか全く想像できない新規事業立ち上げフェーズにおいて、多種多様なPaaSを提供してくれるAWSはとても魅力的。 さて、いざ、EC2インスタンスを立ち上げてアプリケーションをデプロイするわけだが、みなさん、ちゃんとネットワーク設計していますか?まさかデフォルトVPCでサービス運営なんてしてないですよね? というわけでネットワーク設計をして、VPCを設定していくわけだが、何を作ればよいか決まっている事業フェーズならともかく、新規事業立ち上げフェーズでは「将来どんな機能が必要になるかわからない」という前提でネットワーク設計をしておかなければいけない。そこで、「例えばこんな設計はどうでしょう」という提案をしてみる。 IPレンジ設計 まずはVPCとサブネットを使ってIPレンジを

    AWSのネットワーク設計をサボらないでちゃんとやる
  • RubyとAWSでつくるメディアストレージ基盤 - Qiita

    概要 基盤の果たす役割としては、「利用者が基盤に向けてファイルをアップロードし、なんらかの(変換を含む)処理を行って利用サービス側に通知する」というものになる。 そこで、想定する利用イメージを大まかにでも理解してもらうため、抽象的なイメージを図示する。 ファイルをアップロードしたいユーザーは、まず基盤の利用サービスに対してアップロード権限の発行を依頼する。 図では省略したものの、利用サービス側はその依頼を受けて、基盤に対してアップロードチケットの発行を依頼し、取得した情報をアップロードしたいユーザーに対して返す。 アップロードユーザーはそれを受けて、基盤に対してファイルのアップロードを行い、アップロード・バリデーション・変換が済んだものについては基盤が利用サービスに結果を通知するというのが大まかな流れとなる。 次に、基盤の持つ責務について簡単に解説したい。 基盤は、メディア

    RubyとAWSでつくるメディアストレージ基盤 - Qiita