Deep Dive: Amazon DynamoDB
This document provides an overview of Amazon DynamoDB including key concepts like tables, data types, indexes, scaling, data modeling best practices, and example scenarios. It discusses how to design DynamoDB tables for different data access patterns including 1:1, 1:N, and N:M relationships. It also provides recommendations for modeling time series data, popular fast-changing items, and messaging
AWSで構築した環境にありがちなシェルスクリプトたち まとめ ｜ DevelopersIO
AWSでサーバを運用する際にはEC2からAWS CLIを使って他のAWSのサービスと連携したりすることがあると思いますが、AWS環境ならではのシェルスクリプトを集めてみました。AWS CLIのバージョンは1.7.13、Pythonのバージョンは2.6.9を使っています。私はAmazon Linuxで動作を確認しています。 目次 準備する AWS CLIのインストール AWS CLIのアップデート aws configureでセットアップする IAM roles for EC2 instancesに関して 監視系 CloudWatchでカスタムメトリクスを設定する ZabbixからCloudWatchの値を取得する プロセス監視する バックアップ系 AMIとEBSのバックアップを作成する RDSのスナップショットを作成する S3のフォルダを削除する 便利スクリプト系 Route53の自動登録
実践 AWS Key Management Service - WebPay Engineering Blog
WebPayはサーバインフラの大部分でAWSを利用しており、クラウドサービスもAWSのものを好んで利用しています。 今回、新たにカード会員データを取り扱う部分を再構築するにあたり、AWS Key Management Serviceについてサーベイしました。 この記事ではその過程で得られた知見を、PCI DSSとの関係や実際のコードに触れながら紹介します。 カード決済に限らず、セキュリティが重要なシステムを構築しているエンジニアに是非読んで欲しい内容になっています。 AWS Key Management Serviceとカード会員データ AWS Key Management Service（以後KMS）は、端的にはデータの暗号化、復号化を実施するサービスです。 具体的な利用法や特徴については公式ドキュメント What is the AWS Key Management Service?に譲
AWSのアカウント管理の話 - プログラマでありたい
AWS Advent Calendar 2014の7日目です。あと、全部俺Advent Calendarも開催中です。 運用絡みで何か書くと宣言したので、AWSのアカウント運用について書いてみます。テクニックや技術より、考え方の面での整理です。 AWSのアカウントの種類 AWSで利用するアカウントは２種類あります。AWSアカウントとIAMアカウントです。AWSアカウントは、マスターアカウントと呼ぶこともあって大元のアカウントになります。AWSにサインアップ時に作るものが、AWSアカウントで１つだけ存在します。それに対して、IAMアカウントはユーザアカウントです。AWSの管理コンソールから、個々のユーザ向けなどに作成します。 AWSアカウントの取扱について AWSアカウントは、全権限を持っています。強力すぎるアカウントで、日常の運用に利用するには危険すぎます。日常の運用には使わないというのが
ELBの挙動とCloudWatchメトリクスの読み方を徹底的に理解する | DevelopersIO
よく訓練されたアップル信者、都元です。ELBはAWSにおけるWebシステムを構築する場合、ほぼ確実に利用するコンポーネントとして不動の地位を確立しつつあります。 利用方法としては、ELBを作成して配下にWebサーバを配置するだけというお手軽さがあり、非常に利用しやすいのも大きなメリットです。しかし、ELBの詳細な挙動について、しっかり理解できているでしょうか。本エントリではいつも利用しているELBについて、ちょっと深く突っ込んでみました。 ELBのロードバランシング戦略 ELBの配下には複数のAZにまたがるようにインスタンスを配置するのが一般的です。（cf. AWSにおける可用性の考え方） ELBを作成すると、DNS名が付与されますが、クライアントがELBにアクセスする際、まずこのホスト名をIPアドレスに変換するDNSの正引きリクエスト（下図中の緑色の矢印）を行います。digコマンドを使っ
【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみる | DevelopersIO
よく訓練されたアップル信者、都元です。今回のお題は久しぶりにVPCです。 この記事は、アップデート版が存在します。最新情報は【AWS】VPC環境構築ノウハウ社内資料 2014年4月版を参照してください。 VPCを利用する理由 弊社で構築するAWSのサーバ環境は、一部の例外を除いて全てVPCを利用しています。 突然ですが、筆者はあまり大規模なシステムに携わった経験がありません。大規模なプロジェクトだと「数百数千台のサーバがラッキングされ、それが論理的なネットワークで区切られていて」「複数のデータセンターが冗長化された専用線で結ばれて」等、正直ちょっと想像つかない世界があるんだと思います。よくわかんないですが。 (c)John McStravick. (CC BY 2.0 Licensed) 逆に、小さなシステムであれば、月々数万円でレンタルサーバを借りて「1台のマシンの中にWebサーバとDB
Eight meets AWS
2013.03.16 JAWS DAYS 2013 Day2のTrackC 17:00からのセッションで発表したときの資料です。
クラウド利用の責任分担が分かる、FISC対応リファレンスの見方
2013年9月12日、「金融機関向け『Amazon Web Services』対応セキュリティリファレンス」（以下、セキュリティリファレンス）についての解説記事「パブリッククラウドを安心安全に利用しよう、AWSの「FISC対応」リファレンスとは？」が掲載された。これを受けて本稿では、同リファレンスの読み解き方の詳細を解説する。筆者は同リファレンス策定のコアメンバーで、現在も改訂作業に積極的に関わっている。また、実際に金融機関でAWSを利用するプロジェクトで本リファレンスを活用する現場にも関与している。これらの経験を踏まえ、一般の方にも分かりやすい説明を試みる。 FISCおよびセキュリティリファレンスに関する記事 概要：パブリッククラウドを安心安全に利用しよう、AWSの「FISC対応」リファレンスとは？ 読み解き方：AWSのデータセンター立ち入り禁止が問題にならない理由 関連記事 セキュリテ
＜金融機関向け「Amazon Web Services」対応セキュリティリファレンス＞ | ソリューション | 電通国際情報サービス（ISID）
セキュリティリファレンスとは Amazon Web Services活用における、「金融機関等コンピュータシステムの安全対策基準・解説書」第8版に対応したセキュリティリファレンスです。 FISC「金融機関等コンピュータシステムの安全対策基準・解説書」第8版に対応 FISCが発刊する「金融機関等コンピュータシステムの安全対策基準・解説書」は、1985年12月に金融機関等の自主基準として策定されて以来、現在まで金融情報システムに関する安全対策のよりどころとして広く活用されています。同基準・解説書は、137の設備基準、107の運用基準、51の技術基準から構成されており、セキュリティリファレンスでは、これらの基準ごとにAWSのセキュリティ対応状況を調査した結果を整理しました。 ・関連プレスリリース SCSK、ISID、NRI 3社共同で「金融機関向け『Amazon Web Services』対応
Amazon ElastiCache – Now With a Dash of Redis | Amazon Web Services
AWS News Blog Amazon ElastiCache – Now With a Dash of Redis We launched Amazon ElastiCache about two years ago, and have steadily added features ever since. In the last two years we have added auto discovery, additional cache node types, and reserved cache nodes. We’ve reduced prices several times and we have added support for additional AWS Regions and VPC. Today we are taking a big leap forward
Public AMIを公開する場合のお作法 - プログラマでありたい
一般的にPublic AMIとして公開する必要があるケースは少ないです。そのため、AMIを公開する際の情報は少なく、どうしたものかなぁとなります。私も試しにしてみたかったので、公開してみたことがあります。その際の注意点をまとめておきます。今回の手順は、Redhat系OSを想定しています。 ※実際、一度目は手順としてまとめておかなかったので、抜け・漏れが発生しました。 自分の痕跡を消す 公開鍵の消去 これ必須です。忘れるとAWSから注意が来ることもあるそうです。私は来たことありませんが。。。 echo "" > /root/.ssh/authorized_keys echo "" > /home/*/.ssh/authorized_keys ログの消去 接続元情報などが漏れるので、消去しておいてください。ここのログは稼働しているサービスによって可変ですので、任意のものを消してください。 ec
Push Notifications to Mobile Devices Using Amazon SNS | Amazon Web Services
AWS News Blog Push Notifications to Mobile Devices Using Amazon SNS Does your mobile app keep on running in the cloud, even when the associated smartphone or tablet is closed? If so, you might want to proactively provide your customers with useful information. For example, a traffic app can warn of heavy traffic and a slow commute, allowing the user to arrive in time for their first meeting of the
AWSにおけるセキュリティとコンプライアンスのベストプラクティスを読んでみた | DevelopersIO
AWSは今エンタープライズ祭り AWSと聞いて、ホームページを運営するためのレンタルサーバーぐらいに思っている方は認識を改めた方が良いかと思います。今、AWSをエンタープライズ分野で利用する企業が増えています。そこで、必ずといっていいほど出てくるキーワードが、セキュリティです。まぁ、自前でラックを用意して運用するよりも、AWSに預けた方が安全なのは明らかなのですが、セキュリティがザルなオンプレからクラウドに移行するにあたって、改めて考えてみようということで読んで頂ければと思っています。今回は、トレンドマイクロ社が公開しているホワイトペーパーを読みながら理解を深めます。 クラウドコンピューティングとは 毎度おなじみの用語の定義です。ここでは、NIST（The US National Institute of Standards and Technology）が定義するクラウドコンピューティン
vagrant+awsであやふやな境界線へ | 公開懺悔日記
最近はまっているvagrant。楽しすぎる。 JAWSな人としてはEC2をvagrantで起動してという事やっておかないとねー^^;; ということで vagrant-aws を利用してEC2の起動にチャレンジ プラグインのインストールvagrant-awsをインストールします。 vagrant plugin install vagrant-aws これでインストール完了。かなり楽ちん 私が入れているpluginは sahara (0.0.15)vagrant-aws (0.2.2)vagrant-omnibus (1.1.0)boxの準備 vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box 起動するのはEC2だけどvagrantにはboxが必要なのでdummyのboxを用意し
【AWSにおけるセキュリティ】冗長バーチャルMFA | DevelopersIO
よく訓練されたアップル信者、都元です。さっきはヤられました…。早速ボスに「同じネタの記事書いちゃったんですよーｗｗ」という話をしたら、想像通りのドヤ顔を頂きました。ごちそうさまでした。 さて、マジで悔しいので再びMFAネタ。 MFAを滅失した場合 前のエントリで説明した通り、アカウントのセキュリティ向上にはMFAが有効です。特にルートアカウント（非IAMアカウント）はアカウントの解約までできてしまう、最も強い権限を持っていますので、是非ともMFAを活用したいところです。 しかし、MFAというのは基本的に個人に帰属してしまいがちなデバイスです。業務で利用するAWSアカウントについて、そのルートアカウントにMFAを設定した場合、そのMFAを持ち歩くのは、恐らくそのプロジェクトの責任者ということになります。 では、その責任者がMFAと共に、何らかの事故に巻き込まれてしまった場合、どうなるでしょう
AWSアカウントのセキュリティを強化する 〜 MFAの利用 | DevelopersIO
よく訓練されたアップル信者、都元です。アカウント認証というのはIDとパスワードによってなされるのが一般的です。パスワードは複数の文字種を使い、数字を含め、長いモノを設定する等、各種プラクティスはあちこちで議論されていますが、そもそものアカウントの数が多くなると、厳正なパスワード管理にもどこかにほころびが出てくる可能性 *1が出て来ます。 MFAによるセキュリティ向上 そういった状況で、パスワードだけに依らないセキュリティ向上の手段として、AWSではMFA（Multi-Factor Authentication - 二要素認証）に対応しています。 具体的にどういうことかというと、ログイン時には通常のIDとパスワード *2に加えて、そのログインのタイミングで手持ちのデバイス（ハードウェア）に表示されている数字 *3を入力しなければ、認証に成功しない、という認証方式です。デバイス上の数字は一定時
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大規模分散システム ”Amazon Web Services” の使い方
AWS上で使えるストレージ十番勝負
AWS特集 の記事一覧 | DevelopersIO
知る人ぞ知る特濃クラウドカンファレンス「GigaOM Structure 2013」を写真で振り返る その1
