ホーム / ハック / amazon linux2にpython3とboto3を入れる
Amazon Web Services (AWS) が提供しているAmazon Linuxに新世代のAmazon Linux 2(以下AL2)がリリースされました。 AL2にはデフォルトでは Python 2.7 系がインストールされているため、Python3 を利用したい開発者向けに Python インストール後に venv で環境構築 Anaconda で Python まるごとまるっとインストール それぞれで Python 3.6 向けの環境を構築する方法を紹介します。 環境構築は一部宗教論争的な側面もありますが、個人的には venv : Python で何かやりたい人向け Anaconda : ソフトウェアが Python で書かれているので Python 実行環境が必要な人向け というような印象を持っています。 AL2デフォルトのPythonは2.7.14 AL2にはデフォルトで
おはこんばんちは!! 尾藤 a.k.a. BTO です。 HDEのメールアーカイブシステムでは、月間1億6000万通ものメールを処理しています。 それだけのメールを処理するので、メールのデータ量も大変なものになります。 一方で、過去のメールに関しては、それほど頻繁にアクセスするものでもありませんので、できるだけコストを抑えたい。 そこでAmazon Glacierを使ってみてはどうかと考えたのですが、詳しく調査してみると、気をつけないと破産をしかねない危険なものでもあるのが分かりましたので、今回はそれを書きたいと思います。 Amazon Glacier とは まずは Amazon Glacier についてご紹介しましょう。 Amazon Galcier は平たく言うと、安価なストレージサービスです。安価である代わりに、取り出すのに3〜5時間かかります。 Glacier と S3 の料金は次
2017年12月14日、目黒のAmazon Web Services (AWS) Japanオフィスにて、AWS re:Invent 2017前後にて発表されたセキュリティ関連情報を振り返るセミナーが開催されました。 AWS re:Invent 2017とは、2017年11月27日から12月1日までラスベガスで開催されたAWS最大のカンファレンスです。エンドユーザー様、パートナー様を中心に、世界中から40000人以上の来場者を集めました。re:Inventは基調講演やブレイクアウトセッション、ブートキャンプ、パートナー様ソリューション展示、参加者同士のネットワーキングなどからなります。例年同様、一人では回りきれないほど大量で多種多様なイベントが行われました。 そこで本セミナーは、セキュリティという観点に絞り、re:Invent 2017での情報を効率的に収集いただくと同時に、来年以降の日本
はじめに ついにELBがアクセスログを出力できるようになりました!(Elastic Load Balancing Announces Access Logs) ということでやってみました! 設定 [Load Balancers]画面を開き、設定したいELBを選択します。画面下部の[Description]タブの一番下に[Access Logs]という項目があります! なおこの項目は新しいManagement Consoleでしか表示されません。以前のManagement Consoleを使用されている場合は、画面右上に青い吹き出しのようなアイコンが表示されていますので、クリックし「Try the new design」の[Click here]リンクをクリックすると、新しいデザインのManagement Consoleに切り替わります。 さて、[Access Logs]の[Edit]リンク
Your AWS account has default quotas, formerly referred to as limits, for each AWS service. Unless otherwise noted, each quota is Region-specific. You can request increases for some quotas, but not all quotas can be increased. To view service quotas You can view service quotas by using the following options: From the documentation: Open the Service endpoints and quotas page in the documentation, se
公式ドキュメントによると、下記のような記述があります。 ロードバランサーが正しくスケーリングを行えるように、ロードバランサーをアタッチするサブネットの CIDR ブロックを、最低でも /27 ビットマスク(例: 10.0.0.0/27)に指定してください。 ロードバランサーをアタッチするサブネット内には自由な IP アドレスが 20 個以上含まれている必要があります。 http://docs.aws.amazon.com/ja_jp/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html というわけで、/27のサブネットでは、実際いくつまでELBを作る事ができるのか調べてみました。 10.0.1.0/27 でサブネットを作ったところ、初期の利用可能なIPアドレス数は27でした。 がつがつELBを作ってみたところ
AmazonWebServiceのELBは、とても簡単にサーバ分散化できる素晴らしいサービスなんだけど、ちょっとしたことに注意しないと、とんでもない目に遭う。というか、マニュアルとかにちゃんと書かれているから、読めよって話なんだけど。 AZ毎のEC2インスタンスは同じにする! 初めてELBを運用していた当初、どうもEC2インスタンスによってアクセスに偏りがあるな…と思ってたら、ELBはまず登録されているAZの数でトラフィックを分けて、その中から各EC2に振り分ける挙動だった。つまり、AZ_AにEC2が1個/AZ_BにEC2が10個あると、総トラフィックの約50%をAZ_AのEC2インスタンス1個が引き受けるという地獄に…。 マニュアルにも書かれています…。 着信トラフィックはロードバランサーで有効になっているすべてのアベイラビリティゾーン間で均等に負荷分散されるので、各ゾーンのインスタンス
1. © 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc. AWSマイスターシリーズ Elastic Load Balancing 2013.6.12 アマゾンデータサービスジャパン株式会社 ソリューション アーキテクト 舟崎 健治 平山 毅 安川 健太 2. © 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or
AWS のリソースを保護するには、AWS Identity and Access Management (IAM) を使用する際の以下のベストプラクティスに従ってください。 人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする 人間のユーザーとは、別名人間 ID と呼ばれ、人、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーを指します。人間のユーザーは AWS の環境とアプリケーションにアクセスするための ID を持っている必要があります。組織のメンバーである人間のユーザーは、ワークフォースアイデンティティとも呼ばれます。人間のユーザーには、あなたと共同作業を行う外部ユーザーや、あなたの AWS のリソースを操作する外部ユーザーも含まれます。この操作は、ウェブブラウザ、クライアン
以下に一覧表示されている AWS のサービスは、アルファベット順にグループ化されています。また、サポートされる IAM の機能に関する情報を含んでいます。 サービス – サービスの名前を選択し、このサービスの IAM 認可とアクセスに関する AWS ドキュメントを表示できます。 アクション – ポリシーで個々のアクションを指定できます。サービスでこの機能がサポートされていない場合、[visual editor] (ビジュアルエディタ) で [All actions] (すべてのアクション) を選択します。JSON ポリシードキュメントでは、* 要素に Action を使用する必要があります。各サービスのアクションのリストについては、「AWS のサービスの アクション、リソース、および条件キー」を参照してください。 リソースレベルのアクセス許可 – ARN を使用してポリシーで個々のリソース
1. 2016 / 03 / 15 アマゾン ウェブ サービス ジャパン 株式会社 プロフェッショナルサービス本部 高田 智己 【 AWS 初心者向け Webinar 】 AWSにおけるセキュリティとコンプライアンス 2. ご質問を受け付け致します! 質問を投げることができます! • Adobe Connect のチャット機能を使って、質問を書き込んで ください。(書き込んだ質問は、主催者にしか見えません) • 最後の Q&A の時間で可能な限り回答させていただきます。 ①画面右下のチャッ トボックスに質問を 書き込んでください ②吹き出しマークで 送信してください 3. AWS 初心者向け Webinar のご紹介 • AWS についてこれから学ぶ方むけの ソリューションカットの Webinar です • 過去の Webinar 資料 – AWS クラウドサービス活用資料集ページにて公開
よく訓練されたアップル信者、都元です。アカウント認証というのはIDとパスワードによってなされるのが一般的です。パスワードは複数の文字種を使い、数字を含め、長いモノを設定する等、各種プラクティスはあちこちで議論されていますが、そもそものアカウントの数が多くなると、厳正なパスワード管理にもどこかにほころびが出てくる可能性 *1が出て来ます。 MFAによるセキュリティ向上 そういった状況で、パスワードだけに依らないセキュリティ向上の手段として、AWSではMFA(Multi-Factor Authentication - 二要素認証)に対応しています。 具体的にどういうことかというと、ログイン時には通常のIDとパスワード *2に加えて、そのログインのタイミングで手持ちのデバイス(ハードウェア)に表示されている数字 *3を入力しなければ、認証に成功しない、という認証方式です。デバイス上の数字は一定時
AWSの別アカウントどうしでAMIを共有するのをやってみたので手順をメモしておく。 最近は別リージョンへのAMIコピー機能も追加され、AMIを作りなおさなくて良くて便利。 全てManagement Console上で実施。 やってみた手順 AMIの共有 AMIを所持している方のアカウントでEC2のAMIを表示 共有するAMIを選択して「Edit」実施 「Permissions」を選択して「Add Permissions」ボタンを押下 「AWS Account Number」に共有先AWSアカウントのアカウント番号入力してチェック 共有されたAMIの利用 AMIを共有されたアカウントでEC2のAMIを表示(共有元と同じリージョンにする) 「Filter」が「Owned By Me」になっている場合は「Private Images」にすると共有されたAMIが表示される EC2する際も、AMI選
VPC内のEC2に複数のEIP(Global IP)を付与してみます。 もっとも、VPC内のEC2には 直接EIPを付与することが出来ないため、実際にはENIへEIPを付与し、ENIをEC2へアタッチすることになります。 ・ENIコマンドを探す ENI が必要なことは分かっているので、そのコマンドを確認してみます。 $ ls -1 /opt/aws/bin/*network*interface* /opt/aws/bin/ec2-attach-network-interface /opt/aws/bin/ec2-create-network-interface /opt/aws/bin/ec2-delete-network-interface /opt/aws/bin/ec2-describe-network-interface-attribute /opt/aws/bin/ec2-des
2015/11/13追記:現行のサービスにおける上限値や制限値については下記のAWS公式ページに情報がまとまっているようです。サービス毎の状況を確認される場合はこちらをご参照ください。 - AWS Service Limits - Amazon Web Services - AWS サービス制限 - アマゾン ウェブ サービス AWSでインフラ構築作業を行っていると、規模によってはあっという間に(定められている)要素数の上限に達してしまいます。後述する『上限緩和申請』を行えばその上限は増やす事が出来るのですが、実際に構築を行う前にその辺りの申請はスムーズに済ませておきたいところ。と言うわけで、現在AWSで利用上限が定められている要素とそれらの上限を増やす(上限緩和申請)ための依頼フォームの情報を個人的学習目的及び今後の備忘録として整理してみました。 AWS Service Limits(A
3/9に行われた春のJAWS-UG 三都物語の資料が続々と公開されています。どれも面白いですが、cloudpackさんの"JAWS-UG三都物語 2013 春 よりセキュアなAWS環境 構築事例 〜PCI DSS対応〜"の事例が中々興味深かったです。 その中の1つに、AWS Management Consoleのログを取るというのがあります。割と実現して欲しいと要望の多い機能ではありますが、2013年3月現在のAWSのデフォルトの機能ではありません。この機能が何故必要かと言いますと、エンタープライズ向けで使うためには必要要件として定義されていることが多いからです。今回の例でもPCI DSS対応の為にも、必須とあるようです。 デフォルトの機能でないとすれば、どうすれば良いのか?1つはAPIを使って独自に作るという方法です。AWSのサービスは全てAPIが用意されています。つまり画面で出来ること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く