Author: AWS Japan

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 コーディングのエディタ/IDEは人それぞれ好みがありますが、最近はVisual Studio Codeを利用している方が増えた気がしています。そのVisual Studio Code上でAWSの開発効率を上げることができるプラグインが用意されている事をご存知でしょうか？Python, Node.js, .NET coreでのAWS開発に対応していて、導入も簡単です。詳しくはこちら(AWS Toolkit for Visual Studio Code)をご覧ください。また、こちらには.NET core+AWSでの利用ガイドもあります。 それでは、先週の主なアップデートについて振り返っていきましょう。

本番環境に対応したアーキテクチャに移行する際、お客様のアプリケーションチームはサンドボックス環境で AWS のサービスを試して、AWS の進化していくイノベーションに対応することができます。アプリケーションチームは、さまざまな AWS のサービスとリソースにタイムリーにアクセスする必要があります。つまり、最低限の権限を与えられることを保証するメカニズムを必要とします。通常、アプリケーションチームは、定期的に Amazon Elastic Block Store のスナップショットバックアップを行う AWS Lambda 関数や、セキュリティチームが管理する一元化された情報セキュリティアカウントにイベントを送信する Amazon CloudWatch Events ルールなどの管理リソースにアクセスできません。 このブログ投稿では、さまざまなサンドボックス、開発、テスト環境で作業しているアプリケーションチームが AWS Identity and Access Management (IAM) ポリシーを作成および検証するため、一元化かつ自動化したワークフローを作成する方法をご紹介します。セキュリティ開発者は、セキュリティチームの特定の要件に従ってこのワークフローをカスタマイズできます。セキュリティ開発者は、アカウントの種類または所有チームに基づいたアクセス許可セットを制限するロジックも作成できます。AWS CodePipeline を使用して、さまざまな段階や複数の AWS アカウントにわたるワークフローを作成および管理します。これについては、次のセクションで詳しく説明します。 ソリューションの概要 次のシナリオから始めましょう。Alice は AWS サンドボックスアカウントの管理者です。これは、組織のデータサイエンティストが Amazon Athena や Amazon EMR などの AWS の分析サービスを試す際に使用します。データサイエンティストは、機密情報が取り出された後、実際のデータセットの一部に対して分析ジョブのサンプルを実行することで、これらのサービスが本番ユースケースに適合しているかを評価します。データセットは既存の Amazon Simple Storage Service (Amazon S3) バケットに保存されます。Alice は新しいプロジェクトごとに、プロジェクトチームに要求された Amazon S3 バケットにアクセスして、分析クラスターを作成できるようにする新しい IAM […]

AWS GlueはApache Spark ETLジョブでのデータ分析・データ処理を行うために、様々なデータソースから大量のデータセットを準備(抽出および変換)し、ロードするサーバーレスな環境を提供します。この投稿のシリーズでは、Apache SparkアプリケーションとGlueのETLジョブの開発者、ビッグデータアーキテクト、データエンジニア、およびビジネスアナリストが、AWS Glue上で実行するデータ処理のジョブを自動的にスケールするのに役に立つベストプラクティスについて説明します。 まず最初の投稿では、データ処理を行うジョブのスケーリングを管理する上で重要な2つのAWS Glueの機能について説明します。1つ目は、大規模に分割可能なデータセットに対して、Apache Sparkアプリケーションを水平にスケールアウトできるようにすることです。2つ目は新しいAWS Glueのワーカータイプを使用して、メモリインテンシブ(メモリを大量に消費する)なApache Sparkアプリケーションを垂直にスケールアップするということです。また、Amazon Kinesis Data Firehoseを使ったストリーミングアプリケーションから一般的に取り込まれる多数の小さなファイルに対して、Apache SparkアプリケーションをスケールさせるAWS Glueの使い方についても説明します。最後に、AWS GlueジョブがAmazon S3上に存在する大量のデータセットのパーティション構造を利用して、Apache Sparkアプリケーションの実行時間を短縮する方法についても説明します。

みなさん、こんにちは。アマゾン ウェブ サービス、プロダクトマーケティング シニアエバンジェリストの亀田です。 2019年9月24日から、Amazon EC2 で vCPU ベースのオンデマンドインスタンス制限が利用可能になりました。 この点に関してサポートに多くのお問い合わせをいただいておりますので、ブログにてその機能やメリットなどをご紹介いたします。 【機能の概要】 Amazon EC2 のオンデマンドインスタンス制限が、現在のインスタンスタイプごとの数量ベースの制限から、新たに vCPU ベースの制限に移行されます。これにより、よりシンプルにAmazon EC2 のオンデマンドインスタンス制限を管理できるようになりました。 現在従来のインスタンスタイプごとの制限に比べて、vCPUの制限範囲において、自由なインスタンスタイプを選ぶことができるようになります。現在オプトイン（管理者による申し込み）で新しい制限タイプへの移行が可能ですが2019年11月8日にはすべてのAWSアカウントが移行されます。 EC2の以下の画面からオプトイン処理が可能です。 すでに上限緩和などで申請済みの制限は再申請の必要はありません。 プラン変更のドキュメントは以下になります。 https://aws.amazon.com/jp/ec2/faqs/#EC2_On-Demand_Instance_limits 上限緩和申請の出し方はこちらのBlogを参考にしてください。 https://aws.amazon.com/jp/blogs/news/aws-service-quotas/ サポートケースでの申請方法については、本ブログの【計算例】を参考にしてください 【変更点】 従来は、インスタンスタイプ毎に制限が設けられており、上限緩和依頼は個別に行なう必要がありました。 vCPU ベースの制限では、インスタンスファミリー毎に上限が設けられます。A, C, D, H, I, M, R, T, Z インスタンスはスタンダードとしてまとまります インスタンスファミリー毎に設けられる vCPU の数と、各インスタンスタイプ毎に設けられる vCPU の数によって、柔軟な組み合わせを単一の上限緩和申請で設定できるようになります。 例：All Standard(A, C, D, H, I, M, R, T, Z)インスタンスにおける vCPU […]

皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 本日(10/24）、私が執筆したモダンアプリケーション開発のホワイトペーパーの英語版がAWSのWhitepapers & Guidesの英語サイト（言語でEnglishを選択してください）で公開されましたので、その内容を紹介させて頂きます。   ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、 「Modern Application Development on AWS – Cloud-Native Modern Application Development and Design Patterns on AWS –」（英語版） というタイトルの42ページのドキュメントで、Introduction、Modern Application Development、Modern Application Design Patterns、Continuous Integration and Continuous Delivery on AWS 、Conclusionの章から構成されています。   Introduction Introductionの章では、なぜモダンアプリケーションが重要なのかを説明しています。この章ではモダンアプリケーションによって我々がInnovation Flywheelと呼んでいる実験、フィードバック、新たなアイデアの創出というイノベーションのループを回すことが重要であることを説明しています。   Modern Application Development Modern Application Developmentの章では、モダンアプリケーションの特徴とモダンアプリケーション開発における6つのベストプラクティスを紹介しています。またベストプラクティスを実践する際に関連するAWSの各サービスについても触れているのでそちらも参考にして頂けます。これらのベストプラクティスは同時にモダンアプリケーション開発のチェックリストとして使えるようにもなっています。   Modern Application Design Patterns Modern Application […]

こんにちは、AWSソリューションアーキテクトの小林です。つい最近まで残暑が厳しかったのに、最近は急に寒くなってきたような気がします。年々秋が短くなっているような気がするのですが気のせいでしょうか？そういえば、私は暑い時期に冷やし中華を食べるのが好きなのですが、毎年食べ納めをやることができず残念な思いをしています。冷やし中華が始まるタイミングはきちんと認識できるのですが、終わるタイミングは人知れずひっそりと終わってしまっているような気がします。来年こそはしっかりと、食べ納めをしたいところです……

AWS Organizations では、複数アカウントに対する集中ガバナンスおよび集中マネジメントを提供します。集中セキュリティ管理者の皆さんは AWS Organizations を使用してサービスコントロールポリシー (SCP) を適用することで、IAM プリンシパル (ユーザーおよびロール) が忠実に順守するコントロールを確立しています。今回、SCP を使用して、AWS Identity and Access Management (IAM) ポリシー言語がサポートする精緻なコントロールでアクセス許可のガードレールを設定できることになりました。これにより、ポリシーを微調整して、組織内のガバナンスルールの要件に厳密に適合させることがこれまで以上に簡単になります。 SCP を使用すると、Conditions、Resources、NotAction を指定して、組織全体または組織単位で複数アカウントにわたるアクセスを拒否できます。たとえば、SCP を使って、特定の AWS リージョンへのアクセスを制限できます。また、お客様の集中管理者が使用する IAM ロールのような共有リソースを、IAM プリンシパルが削除できないようにすることも可能です。さらに、お客様のガバナンスコントロールの例外を定義できると同時に、特定の管理者ロールを除いてアカウント内のすべての IAM エンティティ (ユーザー、ロール、ルート) に対するサービスアクションを制限できます。 SCP を使ってアクセス許可のガードレールを運用するには、AWS Organizations コンソールにある新しいポリシーエディタを使用します。このエディタ内でアクション、リソース、条件を追加することで、SCP を簡単に作成できます。この記事では、SCP の概要をご説明し、新機能をご紹介して、さらに皆さんの組織でも今すぐ使えるような SCP のサンプルの作成方法をご覧いただきます。 サービスコントロールポリシーという概念の概要 例をいくつかご紹介する前に、SCP の機能と AWS Organizations について説明します。 SCP は、アカウント内のすべての IAM エンティティに対するアクセス権限を一元管理できる機能を提供します。そのため、皆さんが必要だと考えるアクセス許可を社内の対象者全員に対して施行できます。SCP を使用すると、開発者が自分のアクセス許可を管理する自由度が増しますが、これは開発者のオペレーションが皆さんが定義した境界線内に限られるからです。 SCP は AWS Organizations によって作成、適用します。組織を作成すると、AWS […]

Amazon Elastic Block Store (EBS) は Amazon EBS ボリュームの暗号化ソリューションを提供するため、ブロックストレージの暗号化キーを管理するための独自のインフラストラクチャを構築、維持、保護する必要はありません。Amazon EBS 暗号化は、暗号化されたの Amazon EBS ボリュームを作成するときにAWS Key Management Service (AWS KMS) のカスタマーマスターキー (CMK) を使用し、AWS KMS の使用に関連する 利点をすべて提供します。Amazon EBS ボリュームを暗号化するには、AWS 管理型 CMK またはカスタマー管理型 CMK のいずれかを指定できます。カスタマー管理型 CMK を使用する場合、AWS KMSでの CMK を毎年ローテーションするなど、暗号化キーをきめ細かく制御できます。CMK の作成の詳細については、のキーの作成を参照してください。 この投稿では、EC2 コンソール、AWS CLI、AWS SDK から EC2 インスタンスを起動するときに、カスタマー管理型 CMK を使用して暗号化された Amazon EBS ボリュームを作成する方法を示します。 EC2 コンソールから暗号化された Amazon EBS ボリュームを作成する […]

先日 (2019/10/16) 開催しました AWS Black Belt Online Seminar「 Amazon Route 53 Resolver 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. オンプレミスと Amazon VPC との相互の名前解決は、AWS Direct Connect や Internet VPN を用いて、オンプレミスと Amazon VPC が接続されていることが前提という理解でよろしいでしょうか。 A. はい。ご認識の通りです。 Q. Route53 Resolver を無効にするユースケースは、例えばどのようなものがありますか？ A. お客様が独自にDNSを構築し、そちらのみを利用したいケースなどが考えられます。 Q. Route 53 Resolver for Hybrid […]

こんにちは。アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクトの平間です。 9月24日に、「Amazon Analytics 事例祭り – データウェアハウスマイグレーション」を開催いたしました。今回は既存のデータウェアハウス(DWH)環境から、AWSの高速かつ完全マネージド型のDWHであるAmazon Redshiftへ移行されたお客様に、移行の決め手や移行後の効果について「本音」でお話ししていただきました。セミナーは前半がAWSソリューションアーキテクトからAWSのデータレイク及びアナリティクスサービスの概要と、DWHの移行をどのように検討すればよいかの方法をお話させていただき、後半はお客様より移行時の体験談をお話しいただいております。