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で詳細を見る