今週はCloudFormationと戯れる毎日でございました。 普段、Network ACLはデフォルト値とし、セキュリティグループでアクセス制御をするのが 個人的な好みなのですが、顧客要件とあらば仕方ありませぬ。   特定のCIDRへのアクセスを全許可したり、TCPだけ全許可したり、 といった場合の記述をした際、一瞬「ん？」となりましたので、 忘れないようにメモを残しておこうと思いました。   TCPを全許可 特定のIPアドレスレンジへのALL TCPを全許可するには、 Port Rangeで全ポートを指定。 [text highlight=”10″] “InboundAllTcpNaclEntry” : { “Type” : “AWS::EC2::NetworkAclEntry”, “Properties” : { “NetworkAclId” : { “Ref” : “AllPermitNacl” }, “RuleNumber” : “95”, “Protocol” : “6”, “RuleAction” : “allow”, “Egress” : “false”, “CidrBlock” : “XXX.XXX.XXX.0/XX”, “PortRange” : { “From” : “0”, “To”.

  AWSから先月のBilling Statement届いてあせった。   Management ConsoleみたらSQL Server検証用のm4.large起動しっぱなしやないか～い！！！ $0.975 /1 時間が積み重なって２万・・２万か・・   Billing Alertはね、設定してたんですよ（ｳｯｳｯ でもね、閾値が最近の発生課金実績ぎりぎりのとこにあったんで、 毎月アラートがきちゃってたんですよ(←アホ)   今の閾値の倍の金額で、泣きながらもう１つBilling Alert追加しますた・・   AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus) posted with amazlet at 16.03.05 吉田 真吾 今井 智明 大瀧 隆太 松井 基勝 冨永 善視 藤原 吉規 大栗 宗 技術評論社 売り上げランキング: 497 Amazon.co.jpで詳細を見る  

  gihyo.jpでようやく電子版が出たので、『AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ]』を読みました。   旧ADSJのパートナー担当の方々とお打ち合わせをしていて、 「ニューノーマル」という用語を耳にし始めたのが2014年。 そして2015年のAWS Summit 2015における長崎社長の基調講演で、 「クラウドはニューノーマルである」と大々的に発表されたのは記憶に新しいところであります。   ニューノーマルアーキテクチャとして紹介されていた特集記事の技術は以下の５つ。 １、モバイルサービス ２、IoTバックエンド ３、APIサービス ４、機械学習 ５、Webサービス   強い印象として、「これからはますますアプリが主役だなあ」という点でした。   ますますアプリとインフラの境目がなくなる   基本的に、どのアーキテクチャもインフラはもうアマゾンが提供してくれます、 さあ、みんなコードを書きましょう！というサービスばかり。 インフラっぽいのは、せいぜいElastic Search Serviceぐらいでしょうか。   もう１つの「ニューレガシーなAWSアーキテクチャ」の特集では、 EC2を使ったAPサーバがあったり、ELBで負荷分散の仕組みを構築したりと、 インフラ担当の出番がありますが、 ニューノーマルアーキテクチャの時代になると、 「インフラだけ」やる担当者の出番はなくなりそうな気がします。   このあたり、私は割とインフラ寄りのキャリアを積んできていますので、 今後のスキル形成やキャッチアップを考えると、危機感を感ぜざるを得ません。 もうサーバ立てたんで、あとはアプリチームよろしく、の時代ではないのだなあという印象を深めました。 逆に考えると、インフラはAWSに任せて、サービスを作って価値を生み出す、 楽しい作業に没頭できる時代が来つつあるとも言えます。   ただしニューノーマル、もう少し時間がかかるのでは   AWSの2015年12月期の通期売上高は前年同期比69％増の78億8000万ドル（1ドル＝120円換算で約9450億円）、 営業利益は同182％増の18億6300万ドル（同約2230億円）(参照)とのことで、 AWSの勢いは留まることを知らない感じではありますが、 昨今の身近なエンタープライズ系システムの基幹システム刷新の事例を眺めておりますと、 まだまだホスティングに毛の生えたような似非クラウドにAWSがコンペで負けるのを何度も見ております。   要因としては、エンタープライズ系のお客様はオンプレミスにいわば「ハードコード」された 仕組み(Exadataのようなアプライアンス然り、膨大な数のクライアントPC管理然り)をたくさんお持ちですので、 そこも含めて面倒を見てくれる国産ベンダーに、まだまだ強みが残っているようです。   AWSファンとしては悔しい限りですが、「ニューノーマル」が浸透していく潮流はきっと止まらないと思います。.

  AWS認定試験ですが、最近仕事を通じて、その必要性が増している感があります。 社内での人材照会の際、「AWS認定の有無」の確認を受けますし、 お客様に提出するAWSインフラ構築案件の提案書にも メンバーのプロフィールとしてAWS認定資格の有無を必ず書かされます。   わたしは資格取得は好きですが、 どちらかというと資格はあくまで資格であり、 実際の仕事の上で技術力を発揮できるかどうかが重要と考えています。 しかし、世間の状況はそうも言っていられない状況のようです。 社内でもAWS認定資格取得者を大幅に増やそうという動きもあるようですので、 「AWS 認定ソリューションアーキテクト – アソシエイト」の学習方法を纏めてみました。   まず試験の概要を知る まずは、試験概要をよく読みましょう。 かなり出題範囲が広いことがよくわかります。 http://media.amazonwebservices.com/jp/training/AWS_certified_solutions_architect_associate_blueprint_11_16_2015_FINAL_JP.pdf   重点的に勉強すべきポイントを絞る 前述の広い出題範囲を漏れなく勉強するのは、かなりの時間を要します。 しかし、受験される方の多くは、会社から急ぎで資格取得を求められている方も少なくないのではないでしょうか？ そんな方には、重点的に勉強すべきポイントを絞ることをおすすめします。 私が考える最重要サービスは、 ・Amazon EC2：コンピューティング ・Amazon VPC：仮想ネットワーク ・Amazon S3：ストレージ ・IAM：アカウント認証 ・Auto Scaling：スケーリング ・Elastic Load Balancing：ロードバランサー ・Amazon EBS：ディスク ・Amazon Route 53：DNS ・Amazon CloudFront：コンテンツ配信 ・Amazon RDS：データベースサービス ・Amazon SQS：キューイング ・Amazon SNS：メッセージング です。 絞ってもまだこれだけあるのかと思われるかもしれないですが、 上記のサービスについては座学で知識を身に着けるだけでなく、 実際にManagement.

  Developers.IO 2016、今年も行って参りました。 あいにくの雨模様でしたが、今年も盛況でしたね。   今年は3セッション参加しました。 ■A-1 頑張らないクラウド最適化 ?クラウドネイティブだけでないAWS活用? ■D-2 AWSで生まれ変わる新しいエンタープライズシステムの理想と現実 ■La-3 実務で使うAWS Lambda   アーキテクチャ系、エンタープライズ系のセッションが中心でしたが、 クラスメソッドさんのAWS案件の進め方は、 SIerの伝統的なウォーターフォールとはやはり違いますね。 小さくすばやく作って、ユーザーフィードバックを元に改善していく。 そして、企業文化として根付いている「新しいもの好き」「チャレンジ精神」を、 実際のビジネス案件でも試している、 そんな印象を受けました。 AWS Lambdaのセッションにしても、 ビジネスとしての実案件を回す側面と、 新技術をビジネスの現場で採用する面における バランスをとるよう、日々努力されていると思いました。 非常にいい企業文化ですね。 うらやましい、正直にそう感じました。

  アカウントごとに(ハードウェア)MFAデバイス買うとお金がかかるなあ。 嫌だなあ。   『よくある質問』を読みます。 Q: 認証デバイスを複数の AWS アカウントで使用することは可能ですか? いいえ。認証デバイスまたはモバイルフォンの番号は、個々の AWS ID (IAM ユーザーまたはルートアカウント) に関連付けられます。   ですよね～と思いつつ、 実際にやろうとするとどうなるか、確かめた。 gemaltoのハードウェアMFAデバイス(私物)。 prduser01にハードウェアMFAデバイスを関連付けました。 その状態で、stguser01に同じMFAデバイスを関連付けようとすると・・   はい、怒られました。すいません。   結論： 多要素認証（MFA）したいAWSアカウント(IAMユーザ)が複数ある場合は、 その数だけMFAデバイスが必要です。   AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus) posted with amazlet at 16.02.16 吉田 真吾 今井 智明 大瀧 隆太 松井 基勝 冨永 善視 藤原 吉規 大栗 宗 技術評論社.

  聴いた。 https://connect.awswebcasts.com/well-arch-2016/event/event_info.html これまで発表されているAWSのベストプラクティスを記載した ホワイトペーパーのまとめという感じで、 設計上の重要ポイントをおさらいするにはよいドキュメントという印象を持った。 近々、日本語版のドキュメントもリリース予定とのことで、 楽しみですね。 実際に設計するアーキテクトの参考にもなりますが、 発注者側が設計レビューをする際、 「こういう観点では、どういう考え方で設計してありますか？」 と質問する際に役立つのではないかと思いましたね。   なるべくインタラクティブに、とのことでしたが、 時間の制約上質問への回答は３つ。 １、サイジングの目安ってある？ ⇒地道にやれ。KPIを設定して、達成できるようなシステムを作れ。 DBならリソース使用状況よりも、クエリが許容範囲内の時間で帰っているかが重要 ２、Amazon Linuxのパッチってどうやってあてるの？ ⇒基本はyum update。Tokyoにはまだないけど、AWS Inspectorってのもあるよ。 日次でyum updateすれようスケジュールしとくのがいいかもね。 ３、見積もりでリザーブドインスタンス考えるのって普通？ ⇒当然である。 でもリザーブドインスタンスは契約期間中に解約とか返金とかできないので、 １年に１回見直す運用がいいかも。 日本では難しいが、USならリザーブドインスタンスをマーケットで売買することもできるよ。   次回のBlack BeltはWorkSpacesとのこと。

  CloudFormationでSecurity Group作ろうとしたわけですよ。 このSecurity Groupがくせもので、 EC2インスタンスとActive Directory間の通信を定義するもの。 とにかくポートの種類が多いわけです。 ドメインコントローラが3台で冗長化されてるもんだから、 もう目もあてらんないっていう。 Management Consoleでポチポチやるの嫌なんで、 CloudFormationの.jsonファイルを書いたわけですが・・ The maximum number of rules per security group has been reached. Rollback・・と。 VPCの制限に引っかかってますね。 Amazon VPC の制限 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html   「セキュリティグループ当たりのインバウンドルールまたはアウトバウンドルールの数」は、 デフォルトだと「50」。 この数を増やすにはAWSサポートに依頼をする必要がありますが、 1ENIあたり、セキュリティグループ数×ルール数が250を超えることができないので、 サポートからは 「ルールの上限を80にしたいなら、セキュリティグループは3つしか作れなくなるよ」 との丁重なご返答を頂きました。 However, We typically don’t update the max rules per security group or the max security groups per.

  Elastic Load Balancer(ELB)でバックエンドのAPサーバに アクセスを振り分けるわけですが、 ELBでStickyを有効化して、 エンドユーザがAPサーバにアクセスしたブラウザを閉じるまで、 アクセス先のAPサーバを固定したい。 ELB作成後、「Description」タブのStickienessをEditします。 StickienessのCookieをELBから発行させるには、 “Enable Load Balancer Generated Cookie Stickiness”をチェックし、 “Expiration Period”を空白にして、Save。   Save後、IEやChrome等の複数のブラウザを使って、 ブラウザを閉じるまでアクセス先が固定されることを確認。 問題なし。 ただし、商用環境で負荷分散を実装する場合は、 セキュリティ向上の観点から、アプリのセッション管理機能を利用して、 セッションタイムアウト時間を設けるようにしましょう。   Amazon Web Services実践入門 (WEB+DB PRESS plus) posted with amazlet at 16.01.23 舘岡 守 今井 智明 永淵 恭子 間瀬 哲也 三浦 悟 柳瀬 任章 技術評論社 売り上げランキング: 3,202 Amazon.co.jpで詳細を見る

  最近MySQLの調子が悪く、 Apacheは生きているがブログは見れないという 恥ずかしい事態が結構起きるため、 CloudWatchでL7ヘルスチェックを実装することにした。   １、IAMロールの設定 EC2上にアクセスキーとシークレットキーを配置しなくてもいいように、 事前にEC2にIAMロールを割り当て、 そのポリシーでCloudWatchの”PutMetricData”をAllowしておきましょう。   ２、EC2にシェルを配置 HTTPステータスコードをチェックするシェル [http_status_check.sh] #!/bin/sh curl -s $1 -o /dev/null -w “%{http_code}”   CloudWatchに監視データをputするシェル [put_mon_http_custom_metric.sh] #!/bin/bash export AWS_REGION=us-west-1 instanceid=i-xxxxxxxa monitored_url=https://www.cyberarchitect.net/blog/ # http status check status=`/home/ec2-user/bin/http_status_check.sh $monitored_url` if [ $status -eq 200 ]; then Fail=0 else Fail=1 fi aws cloudwatch put-metric-data –metric-name “HttpStatusFailed” –namespace “Custom Metrics”.