Author: AWS Japan Staff


EMRFSを利用して、別AWSアカウントからデータを安全に分析する

分析されるデータは、異なるアカウントが所有するバケットに分散されることがあります。データのセキュリティを確保するためには、適切な認証情報管理が必要です。これは、さまざまな部門の異なるAmazon S3バケットにデータを格納している大企業にとって特に当てはまります。例えば、顧客サービス部門は、研究部門が所有するデータにアクセスする必要があるかもしれませんが、研究部門はそのアクセスを安全な方法で提供する必要があります。

データを保護するこの側面は非常に複雑になる可能性があります。 Amazon EMRは、統合メカニズムを使用して、S3に格納されたデータにアクセスするためのユーザー認証情報を提供します。 EMR上でアプリケーション(Hive、Sparkなど)を使用してS3バケットとの間でファイルを読み書きする場合、S3 API呼び出しには認証するための適切な認証情報で署名する必要があります。

通常、これらの認証情報は、クラスターの起動時に指定するEC2インスタンスプロファイルによって提供されます。そのオブジェクトが異なる認証情報セットを必要とするため、EC2インスタンスプロファイルの認証情報がS3オブジェクトにアクセスするのに十分でない場合はどうなるでしょうか?

このポストは、カスタム認証プロバイダを使用して、EMRFSのデフォルトの認証プロバイダがアクセスできないS3オブジェクトにアクセスする方法を示しています。

(more…)

【開催報告】Amazon Athena Meetup – Startup and AdTech

こんにちは、ソリューションアーキテクトの篠原英治です。

Amazon AthenaおよびAmazon EMRのGeneral ManagerであるRahul Pathakの来日に伴い、AWSをご利用いただいているスタートアップおよびアドテクのエンジニアの皆さまをAWSジャパンのオフィスにお招きしてAmazon Athenaに関する勉強会を開催しました。

Amazon Athena Meetup in Tokyo

 

– Amazon Athenaのご紹介

お客様からいただいたフィードバックからAthenaを開発するに至ったという背景や、フィロソフィー、そして特徴などについて、AWSのBigData関連サービスを担当している事業開発マネージャーの一柳による逐次通訳とともに、ご紹介させていただきました。

Introducing Athena - Rahul and Kenta Introducing Athena - Rahul Serverless

Amazon QuickSightとの連携や、JDBCコネクタを使った実装、Apache ParquetやApache ORCといったカラムナフォーマット利用の推奨、Apache Spark on EMRで既存ファイルをカラムナフォーマットに変換する方法から、実際にご利用いただいているお客様のユースケースのご紹介にいたるまで、多岐にわたる内容となりました。

Athena - QuickSight Athena - ANSI SQL

 

– Q&Aセッション

Q&A形式で活発なディスカッションが行われました。
Athena - Discuss2 Athena - QA1

非常に実践的で詳細なご質問や大変貴重なフィードバックを数多くいただきました。またRafulからもスキャンデータの圧縮によるコスト効率の改善などのTIPSも共有させていただきました。こちらに関しましては、先日データサイエンス領域をメインに担当させていただいているSAの志村が翻訳した『 Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ 』も併せてご覧ください。

Athena - QA Athena - QA

Rahulおよび一柳は『 お客様からAthenaに対する期待やフィードバックを直接いただくことができ、今後の改善のアイデア得ることができました。このMeetupを開催できて本当に良かったです。お忙しい中ご参加くださった皆様ありがとうございました! 』と申しておりました。

Athena - Discuss kenta - rokuro

 

Amazon Athenaに関しまして、フィードバック等ございましたら、お近くのAWSジャパンの人間にお声がけいただければと思いますので、今後ともよろしくお願い致します。

また、日本語でAmazon Athenaの概要を知るには [PDF] AWS Black Belt Online Seminar Amazon Athena もおすすめですので、是非ご覧くださいませ。

AWS KMSを使用してAmazon Kinesisレコードを暗号化および復号する

コンプライアンスやデータセキュリティの要件が厳しいお客様は、AWSクラウド内での保存中や転送中など、常にデータを暗号化する必要があります。この記事では、保存中や転送中もレコードを暗号化しながら、Kinesisを使用してリアルタイムのストリーミングアプリケーションを構築する方法を示します。

Amazon Kinesisの概要

Amazon Kinesisプラットフォームを使用すると、要求に特化したストリーミングデータを分析または処理するカスタムアプリケーションを構築できます。 Amazon Kinesisは、ウェブサイトクリックストリーム、金融取引、ソーシャルメディアフィード、ITログ、トランザクショントラッキングイベントなど、何十万ものソースから1時間につき数テラバイトのデータを連続的にキャプチャして保存できます。
Amazon Kinesis Streamsは、HTTPSを使用してクライアント間でデータを暗号化し、転送されているレコードの盗聴を防止します。ただし、HTTPSで暗号化されたレコードは、データがサービスに入ると解読されます。このデータは24時間保管され(最大168時間まで延長可能)、アプリケーションの処理、再処理、処理遅延の際の巻き取りに対して十分なゆとりが確保されています。

ウォークスルー

Amazon Kinesis Producer Library(KPL)、Kinesis Consumer Library(KCL)、AWS KMSaws-encryption-sdkを使用してサンプルKinesisプロデューサおよびコンシューマアプリケーションへの暗号化と復号を行います。この記事で使用されているKinesisレコードの暗号化と復号に使用される方法とテクニックは、あなたのアーキテクチャに簡単に再現できます。いくつか制約があります:

  • AWSは、暗号化と復号のためのKMS APIリクエストの使用料金を請求します。詳しくは、「AWS KMSの料金」を参照してください。
  • Amazon Kinesis Analyticsを使用して、このサンプルアプリケーションのクライアントによって暗号化されたレコードのAmazon Kinesis Streamにクエリすることはできません。
  • アプリケーションでレイテンシの低い処理が必要な場合は、レイテンシに多少の上乗せがあることに注意してください。

次の図は、ソリューションのアーキテクチャを示しています。

(more…)

Amazon ElastiCache for Redis の リードレプリカの自動フェイルオーバのテスト

“信頼するが、確認する”

– ロナルド・レーガン米国大統領、1987

このコメントで、レーガン大統領は、核軍縮条約の哲学について、ロシアの諺を引用しました。DevOpsにも同じ考え方が当てはまります!

 

Amazon ElastiCache for Redisは、自動化されたフェイルオーバとリカバリを備え、高可用性を提供しています。ElastiCacheクラスタを作成したければ、 Redis Cluster モードを使用し、クラスタ内のシャード数を設定します。各シャードには、1つのプライマリノード(読み取りと書き込み用)と0〜5つのレプリカノード(読み取りとフェールオーバー保護用)があります。1つのクラスタは、レプリカがゼロ(1ノード)のシャードと同じくらい小さくても、5つのシャード(5つのレプリカ(合計90ノード))を持つことができます。

 

AWSでは障害が頻繁に発生することはありませんが、いずれのマシンでも障害は発生します。レプリカノードに障害が発生すると、障害が検出され、数分でノードが置き換えられます。

 

Redis Cluster では、プライマリノードに問題が起きた時に、Redis Cluster は障害を検知しレプリカノードを新しいシャードのプライマリとして昇格させます。このプロセスは大体30秒程で実施されます。問題の起きたノードは入れ替えられ、クラスタのレプリカノードとして復帰します。Redis ClusterとElstiCacheを、エンジンとして Redis 3.2.4 と Cluster モードを有効にすることによって使うことができます。

 

これを信じてください…しかし検証するべきです。

 

ElastiCacheのテストフェイルオーバのおかげで検証は簡単です。マネジメントコンソールかAWS CLIを使用し、ElasiCache クラスタのいずれかのノード障害をシミュレートする事ができます、そして、どのようなプロセスで貴方のアプリケーションが動くのかも見ることができます。マルチシャード、もしくはシングルシャードの環境でもテストは可能です。さらに古いRedis 2.8の環境でもテストは可能です。
コンソールまたはAWS CLIを使用して、ElastiCacheクラスタ内の任意のノードの障害をシミュレートし、自分のアプリケーションでフェールオーバープロセスがどのように機能するかを確認できます。マルチシャード環境とシングルシャード環境、さらに古いRedis 2.8ブランチ環境でもフェールオーバーをテストできます。コンソールでこれを行うには、クラスタとシャードを選択してノードビューを表示し、次にフェールオーバープライマリを選択します。マネジメントコンソールでテストを行う際には、クラスタとシャードを選択してNode Viewを確認し、次にFailover primaryを選択します。

 

使用には注意してください。どのようなクラスタでも同じように動きます。なぜならどのクラスタも開発環境、テスト、本番かをAWSが知るすべが無いためです。その本番のクラスタで実行しても良い事が確信していない限りは本番ノードでは障害を発生させないでください。

 

自動フェイルオーバのテストを試してみてください!

 

翻訳は桑野が担当しました。原文はこちら

Amazon Aurora: Fast DDLの詳細

Anurag GuptaはAmazon Auroraを含む彼がデザインに参加した、いくつかのAWSデータベースサービスに携わっています。 Under the Hoodシリーズでは、Auroraを支える技術や設計について説明します。

Amazon Auroraはオープンソースデータベースのシンプルさとコスト効率とハイエンドなコマーシャルデータベースの可用性と性能を兼ね備えたMySQL互換のデータベースです。この投稿では、Amazon Auroraが一般的な、完了までMySQLでは数時間かかるようなDDL文をほぼ即座に実行出来る仕組みを見ていこうと思います。

 

Fast DDLとは?なぜ考慮するのか

アプリケーションを変更すると、それに付随するデータベースのスキーマを変更する必要があるケースがあります。クエリのワークロードが変わると、インデックスの追加や削除を行う必要があります。データのフォーマットが変更になると、既存のカラムのデータタイプを変更する必要があります。そして、このような変更は頻繁に起こりえます。Ruby on Railsアプリケーションをサポートする一部のDBAは、週に数十回スキーマを変更すると話しています。

多くのMySQLのDBAはご存知のように、このようなスキーマの変更はプロダクションシステムの中断が発生する可能性があります。変更に時間がかかるからです。場合によっては、完了まで数時間から数日かかることもあります。システムのリソースも奪われるため、アプリケーションのスループットも低下します。また、長時間のオペレーションは長時間のクラッシュリカバリが発生する可能性があります。DDL操作の一部は書き込みロックが必要なため、アプリケーションの一部が使用できなくなります。加えて一時的なスペースを多く必要とする可能性があり、小規模のインスタンスではディスクが不足する可能性もあります。

私たちはこのような点を取り除けるように改善を行っており、良く見る一般的なDDL操作(nullableカラムをテーブルの最後に追加)から改善を始めました。

 

なぜ既存の方法では問題が起こるのか?

MySQLがどの様にnullableカラムをテーブルの最後に追加する実装になっているか見ていきましょう。

MySQLは以下のような処理を行っています:

  1. データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します
  2. 変更後のスキーマで新しい空のテーブルを作成します
  3. 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます
  4. 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します
  5. オリジナルテーブルをdropし、テーブルをリネームします

これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。

 

もっと良い方法はないのでしょうか?

これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。

完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。

Auroraでは、DDLをユーザが実行すると

  1. データベースがINFORMATION_SCHEMAのシステムテーブルを新しいスキーマで更新します。加えて、各操作に対してタイムスタンプを付与し変更をリードレプリカに伝搬します。古いスキーマ情報は新しいシステムテーブル(Schema Version Table)内に格納されます

同期的に行う操作はこれだけで完了です。

そして、その後のDML文は、影響のうけるデータページがスキーマの変更を待っている状態か監視します。この操作は、各ページのlog sequence number (LSN)タイムスタンプとスキーマ変更のLSNタイムスタンプを比べるだけで簡単に行なえます。必要に応じて、DML文を適用する前に新しいスキーマにページを更新します。この操作は、redo-undoレコードページの更新と同じ更新プロセスで実行されます。そして、I/Oはユーザの実行するクエリと同様に扱います。

DML操作では、ページ分割が発生する可能性があるため、ページの変更に注意する必要があります。変更はAuroraのレプリカノードでも同様に扱う必要があります。そして、リードレプリカではどのデータへの変更も許可されていません。SELECT文のために、MySQLに戻されるメモリ上のバッファ内のイメージ変更します。この方法では、ストレージ内で新旧のスキーマが混在していたとしても常に最新のスキーマを参照出来ます。

もし、皆さんがAuroraがどのようにストレージからの読み込みとログの適用を行っているかご存知の場合、このアプローチが似ていると感じると思います。しかし、このアプローチではredo logのセグメントではなく、変更を記録するためにテーブルを使用します。

パフォーマンス比較は以下のようになっています。Auroraは Schema Version Tableを変更するために一定の時間で処理が完了しているのがおわかりになると思います。しかし、MySQLではテーブルサイズにほぼ比例して線形に処理時間が増加しています。

TableComparison

明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。

このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。

質問やフィードバックはありますか?aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。

注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。

翻訳は星野が担当しました。原文はこちら

AWS Server Migration Service – クラウドへのサーバー移行が簡単に!

これはAhmed Omranのゲストポストです。 AhmedはAWSのMigration Solutions Architectです。

大規模構成におけるオンプレミスサーバーの移行は、自動化、スケジューリング、少ない帯域幅の消費や移行時間の短縮を調整することなしに行うことはできません。

この記事では、AWS Server Migration Service(AWS SMS)を使用して、オンプレミスのワークロードをAWSに効率的に移行する方法を段階的に説明します。

AWS Server Migration Serviceとは何ですか?

2016年10月、エンドツーエンドのサーバー移行プロセスを簡素化する目的でAWS SMS を紹介しました。 AWS SMS は現在、仮想アプライアンスを使用したエージェントレスサービスとしてのオンプレミス仮想マシン(VMs)の移行をサポートしています。 AWS SMSには、次の主要な利点があります:

  • ライブサーバーボリュームのAWSへのレプリケーションを順次自動化することにより、カットオーバー時のサーバーダウンタイムを削減します。
  • 費用対効果の高い方法で大規模サーバーの移行を行います。
  • 広く使用されている多くのオペレーティングシステムをサポートします。
  • 使いやすいUIを使用して、サーバー移行の進捗状況を管理および追跡します。

AWS SMSは、VMware 環境からAWSへの大規模マイグレーションを計画している場合に重要な考慮事項となる、ダウンタイム、エージェントレスツール、順次レプリケーション、およびカットオーバー前のアプリケーションテストなどに対する理想的なソリューションです。

AWS SMSは、サーバーの移行に使用する無料のサービスです。 Amazon EBS スナップショットAmazon S3など、移行プロセス中に使用されたストレージリソースにのみ支払います。

現在、米国東部(米国バージニア州)、米国西部(オレゴン州)、米国東部(オハイオ州)、EU(アイルランド)、アジア太平洋(シドニー)、アジア太平洋(東京)、アジア太平洋(ソウル) 、アジア太平洋地域(ムンバイ)でサービスが利用可能です。

どのように機能するのですか?

AWS SMS を使用してワークロードを移行する手順を説明する前に、移行プロセス自体とAWS SMS がどのように処理するかについて詳しく説明します。

移行プロセスは、次の図に示すように、4つの段階に分かれています。

AWS SMS 移行プロセスの概要

AWS SMS の最終出力はAmazon Machine Image(AMI)です。移行プロセスは、ジョブが終了されるまで(あなたが消去するか、または90日後に自動的に終了するまで)、各レプリケーションの実行ごとにAMIを生成します。

移行段階は、調整された複製頻度で反復されます。各レプリケーションの実行間隔の最短時間は12時間で、最大時間は24時間です。この反復サイクルの有効期間は90日です。その後、レプリケーションジョブは終了します。

移行するVMのグループを選択できます。 SMS は、アカウントごとに最大50の同時VM移行をサポートします。

AWS SMS はどのように使用しますか?

AWS SMSには、移行プロセスのワークフローを調整するコネクターが必要です。このコネクターは、vCenter にデプロイされます。

SMS コネクタを展開する前に、環境がAWSのSMS要件を満たし、正しいファイアウォール設定をしていることを確認してください。 DHCP、DNS、HTTPS、ICMP、およびNTPサービスのステートフルな送信接続を許可するようにファイアウォールを再設定できないと、展開に失敗する可能性があります。

また、AWS SMS のドキュメントに記載されているように、AWS SMS 用の適切なポリシーと権限を持つvCenterサービスアカウントとIAMユーザーを作成する必要があります。

Server Migration Connector仮想アプライアンスを展開する

Server Migration Connectorは、VMware 環境へデプロイするためにOVA形式で提供されている、事前設定されたFreeBSD仮想マシンです。 AWS からConnector の最新バージョンをダウンロードできます。

Server Migration Connector をダウンロードしたら、デプロイのための十分な権限を持つvCenterにログインします。

インベントリからvCenterのコンテキスト(右クリック)メニューを開き、OVF テンプレートの展開を選択します。

 

ソースの選択ページで、ソースOVFテンプレートが存在する場所を指定し、次へを選択します。

確認の詳細 ページで、OVF テンプレートに関する情報を確認し、 次へを選択します。

アプライアンスは、シンプロビジョニングの場合は5.9 GB、シックプロビジョニングの場合は299.0 GBのサイズ容量でデプロイされます。実稼働環境では、シックプロビジョニングを推奨します。

名前とフォルダの選択ページで、アプライアンス名と配置場所を指定します。

リソースの選択ページで、OVF テンプレートを展開したいクラスタ、ホスト、vAPP、またはリソースプールを選択します。

ストレージの選択ページで、仮想ディスク形式からThick Provisioned Lazy Zeroedを選択し、OVF テンプレートをデプロイする必要があるデータストアを選択します。

セットアップネットワークページでネットワークマッピングを設定するために、 宛先 ドロップダウンメニューからネットワークを選択し、 次へ をクリックします。

準備完了ページで、すべての構成設定を確認し、展開後に電源をオンにして、完了を選択します。

コネクターを構成する前に、Server Migration ConnectorがvCenterとESXiホストのFQDNを解決できることを確認してください。

ネットワーク設定の再設定が必要な場合、コネクタアプライアンスコンソールにログインし、Advanced Network Configurationガイドに従います。

コネクターの構成

WebブラウザーでIPアドレスを指定し、Connector VM にアクセスし、セットアップ・ウィザードを開きます。

今すぐ開始を選択します。

 

使用許諾契約書を確認し、条件に同意する場合はチェックボックスを選択し、次へを選択します。

コネクターのパスワードを作成します。

ネットワーク情報 ページで、ネットワーク情報を確認し、 次へ を選択します。

ログを自動的にアップロードし、AWS Server Migration Serviceの自動アップグレードに参加するかどうかを確認して決定します。

AWS Regionについては、リストから希望のリージョンを選択します。

AWS 資格情報には、前提条件のステップで作成したIAMユーザーのIAMアクセスキー秘密鍵キー入力します。

vCenter Service Accountには、vCenter のホスト名、ユーザー名、およびパスワードを入力します。

vCenter 証明書を受け入れたら、登録を完了し、コネクター構成ダッシュボードを表示します。

コネクター ページで、登録したコネクターが表示されていることを確認します。

コネクターページは4つのセクションに分かれています:

  • AWS Server Migration Service セクションには、AWSアクセスキー、シークレットアクセスキー、およびvCenterログインなど、編集可能な設定が用意されています。
  • General Healthセクションには、ヘルスチェックと接続ステータスが表示されます。
  • アクション セクションでは、SMS 管理者パスワードを変更し、コネクターの登録を解除できます。常に最新のアップデートを適用する場合は、自動アップグレードアクションを有効にします。
  • サポートセクションでは、ログをダウンロードしたり、問題を報告したり、ドキュメントを確認したりすることができます。

これで、サーバーインベントリをインポートして、移行イベントを編成して自動化する準備が整いました。

サーバーカタログをインポートする

コネクターがインストールされ、正しく登録されたら、AWS SMS コンソールにアクセスし、コネクター、サーバーカタログのインポートを選択して、サーバーの完全なリストを収集します。サーバーカタログが完全に取り込まれ、表に表示されるまでには時間がかかることがあります。

注:サーバーカタログはいつでも再インポートまたはクリアできます。

移行ジョブを作成する

移行ジョブを開始する前に、データストアに一時スナップショットのための十分な領域があることを確認し、選択したVMにISOが接続されていないことを確認します。

AWS SMS コンソールで、 レプリケーションジョブレプリケーションジョブの作成を選択し、ウィザードに従います。

テーブルから複製するサーバーを選択し、次へを選択します。

レプリケーションジョブから作成されるAMIのライセンスタイプを選択します。 LinuxサーバーはBring Your Own License(BYOL)のみを使用でき、WindowsサーバーはAWS提供のライセンスまたはBYOLを使用できます。完了したら、次へを選択します。

レプリケーションジョブ設定を構成し、次へをクリックします。レプリケーションの実行をすぐに開始させることも、後の日時から、現在の時刻から最大30日後に開始するようにスケジュールすることもできます。

Replicate server every ドロップダウンリストから目的のオプションを選択して複製頻度を選択できます。複製の最小頻度は12時間で、最大は24時間です。つまり、選択したサーバーのポイントインタイムレプリカを最小でも12時間ごとに作成できます。

設定を確認します。設定が正しい場合は、作成を選択します。表示されていない場合は、前へを選択して適切なページに戻り、設定を変更します。

AWS SMSコンソールの レプリケーションジョブ ページで、すべてのレプリケーションジョブを表示できます。 1つのレプリケーションジョブを選択すると、 ジョブの詳細パネルにレプリケーションジョブの詳細が表示されます。

前のスクリーンショットからわかるように、移行が開始され、VMDK がAmazon S3にアップロードされる第2段階にあります。

vCenter 画面から移行タスクのステータスを確認すると、開始されたスナップショットとOVFテンプレートが転送用にエクスポートされたことがわかります。

転送後、移行プロセスは第3段階になり、VMDK をAmazon Elastic Block Store(Amazon EBS)のスナップショットに変換します。

変換が完了すると、移行プロセスは最終ステージになり、この複製実行のポイントインタイムコピーのAMIを作成します。

AWS SMS コンソールのレプリケーションジョブ、実行履歴タブから、各レプリケーション実行で使用可能なすべてのAMIを表示できます。

実際のカットオーバーの前にテストする

オンプレミスアプリケーションを廃止する前に、アプリケーションをテストする機会があります。レプリケーション頻度に応じて、多数のポイントインタイムレプリカをテストしてから、差分の最後のレプリケーションジョブをスケジュールできます。

インスタンスを起動するには、前の手順で示したように実行履歴を開き、レプリケーションジョブを選択して、テストしたいインスタンスの起動を選択します。ウィザードに従って、インスタンスの種類の選択、インスタンスの構成、ストレージの追加、インスタンスのタグ付け、およびセキュリティグループの構成を行います。

実際のカットオーバー

テストを完了して実際のカットオーバーを実行することを決定したら、すべてのIOPを休止し、増分レプリケーションジョブを開始してから、AMIを起動します。 AWS SMS は増分レプリケーションを使用するため、以前のレプリケーション実行からの変更に応じて、カットオーバー時間は最小限になります。

レプリケーションジョブの削除

移行が正常に完了し、移行されたVMが正しく構成されて実行されたら、レプリケーションジョブを削除してオンプレミスデータセンターからAWSへのレプリケーションを停止できます。 AWS SMS コンソールの レプリケーションジョブページで、ジョブを選択し、アクションレプリケーションジョブの削除を選択します。

まとめ

この記事では、AWS Server Migration Serviceのメリットと機能について説明しました。また、SMS Connectorのインストールと構成の方法を説明し、稼働中のワークロードをオンプレミスデータセンターからAWSに移行するための移行プロセスの4つの段階について、ダウンタイムを最小限に抑える方法を説明しました。また、実際のカットオーバーの前に複数のポイントインタイムレプリカをテストする機能についても説明しました。

このブログ記事に関するコメントがある場合は、この記事のコメントセクションに投稿してください。あなたからの便りを楽しみにしています。

AWS Service Migration Serviceを開始する方法の詳細については、当社のWebサイトをご覧ください。

(翻訳は諸岡が担当しました。原文はこちら)

 

Amazon Redshift のデータ圧縮の強化で圧縮率が最大 4 倍に

今回は、Amazon Redshift シニアプロダクトマネージャーの Maor Kleider からのゲスト投稿です。

-Ana


Amazon Redshift は、ペタバイト規模の高速なフルマネージド型データウェアハウスサービスであり、すべてのデータをシンプルにコスト効率よく分析できます。多くのお客様 (ScholasticKing.comElectronic ArtsTripAdvisorYelp など) は、Amazon Redshift に移行して機敏性を実現し、洞察が得られるまでにかかる時間を短縮して、同時にコストも大幅に削減しています。

列指向の圧縮は、Amazon Redshift の重要なテクノロジーです。このテクノロジーにより、ノードの効果的なストレージ容量を増やしてコストを削減し、SQL リクエストの処理に必要な I/O を削減してパフォーマンスを向上させることができます。I/O の効率を高めることは、データウェアハウスに非常に重要です。昨年、I/O の向上に伴ってクエリスループットは倍増しました。この度、Amazon Redshift に新しい圧縮の強化機能が追加されました。以下に、いくつかをご紹介します。

まず、Zstandard 圧縮アルゴリズムのサポートが追加されました。このアルゴリズムは、ビルド 1.0.1172 での高い圧縮率とスピードを適切なバランスに維持します。標準の TPC-DS、3 TB ベンチマークで raw データに適用した場合、Zstandard はディスク容量の 65% を節減します。Zstandard は幅広く適用できます。SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ のいずれのデータ型にも使用できます。

2 番目として、CREATE TABLE AS、CREATE TABLE、ALTER TABLE ADD COLUMN の各コマンドで作成されたテーブルに対する圧縮の自動化が強化されました。Amazon Redshift のビルド 1.0.1161 以降では、これらのコマンドで作成された列のデフォルト圧縮が自動的に選択されます。パフォーマンスを低下させずにディスク容量を節減できるような場合は、自動圧縮が行われます。ディスク容量は、最大 40% 削減されます。

3 番目に、引き続き内部オンディスクデータ構造が最適化されています。プレビュー版をご利用のお客様は、この機能改善により、ディスク容量の使用量を平均して 7% 削減しました。この機能はビルド 1.0.1271 から提供されています。

最後に、ディスク容量の削減量を推定するための ANALYZE COMPRESSION コマンドが強化されました。これまで以上にデータを圧縮してパフォーマンスを向上させる機会が増えました。データは、バックグラウンドでサンプリングされて、最も効果的な圧縮が推奨されます。お客様の判断で、推奨された暗号化を使用するか、別の適切な暗号化を指定できます。

「最近追加されたすべての圧縮機能を利用するまでは、当社の最大のテーブルは 7 TB を超えていました。それが今は 4.85 TB までになり、ディスク容量は 30.7% も節減されました。これにより、ディスク容量は合計で 4 分の 1 に削減でき、非圧縮データに基づく有効原価は 250 USD/TB/年未満になります。Amazon Redshift で分析できるデータ量が増え、これまで以上にクエリのパフォーマンスが向上しました」Chuong Do (Coursera 社の Director of Analytics)

無論、実際にクラスターに適用した場合の効果は、ワークロードとデータに応じて異なります。以上の強化機能を組み合わせた場合、データの圧縮は、従来の通常の 3 分の 1 に対して、最大 4 分の 1 になると思われます。

Amazon Redshift データウェアハウスのコストはわずか 1,000 USD/テラバイト/年であるとお聞きになったことがあるかもしれません。これは圧縮後のデータに基づくコストである点にご注意ください。AWS では、データは圧縮されて保存されます。AWS 以外のベンダーではそうでない場合があります。多くのベンダーはデータを圧縮しますが、コストは非圧縮データのテラバイトに基づいています。嘆かわしいことです。データを圧縮しても非圧縮データとして課金するのは法外と言わざるを得ません。

-Maor Kleider

新規 – AWS Application Load Balancer に対するホストベースのルーティングのサポート

昨年、新しい AWS Application Load Balancer (Elastic Load Balancing の重要な一部) をご紹介し、リクエストの URL のパス要素に基づいて受信 HTTP および HTTPS トラフィックをルーティングするための設定方法について説明しました。このパスベースのルーティングにより、たとえば /api へのリクエストをサーバーのセット (ターゲットグループとも呼ばれます) にルーティングし、/mobile へのリクエストを別のセットにルーティングすることができます。このようにトラフィックをセグメント化することで、リクエストのカテゴリ別に処理環境を制御できます。たとえば、最適な処理環境として、/api リクエストにはコンピューティング最適化インスタンスを指定し、/mobile リクエストにはメモリ最適化インスタンスを指定できます。

ホストベースのルーティングと追加のルール
この度、別のルーティングオプションが利用可能になりました。Host ヘッダーに指定したドメイン名に基づいて受信トラフィックをルーティングする Application Load Balancer ルールを作成できるようになりました。api.example.com へのリクエストは 1 つのターゲットグループに送信し、mobile.example.com へのリクエストは別のターゲットグループに送信して、他のすべてのリクエストは (デフォルトルールで) 3 番目のターゲットグループに送信することができます。ホストベースのルーティングとパスベースのルーティングを組み合わせたルールを作成することもできます。これにより、api.example.com/production へのリクエストと api.example.com/sandbox へのリクエストを別々のターゲットグループにルーティングできます。これまでは、一部のお客様はプロキシサーバー群を設定して実行し、ホストベースのルーティングに使用していました。今回のリリースにより、ルーティングは Application Load Balancer によって行われるため、プロキシサーバー群は必要なくなりました。この処理レイヤーの省略により、アーキテクチャが簡素化され、運用のオーバーヘッドが削減されます。Application Load Balancer は、ポートマッピング、ヘルスチェック、サービス検出などのコンテナベースのアプリケーションをサポートする複数の機能を既に提供しています。ホストとパスの両方でルーティングできるようになると、複数のマイクロサービスをそれぞれ異なる Amazon EC2 Container Service コンテナで実行するアプリケーションを構築し、効率的にスケールすることができます。ホストベースのルーティングを使用すると、サービス名とコンテナ名を合致させることで、これまで以上にサービス検出機構を簡素化できます。今回のリリースでは、Application Load Balancer あたりの最大ルール数が 10 から 75 に増え、新しいルールエディタも導入されます。例として、以下のターゲットグループを使用してみましょう。

ロードバランシングコンソールに、Application Load Balancer に関連付けられているリスナーが表示されます。ここで、[View/edit rules] をクリックして新しいルールエディタにアクセスします。

すべてのリクエストを web-target-production ターゲットに転送するデフォルトルールが既に設定されています。

挿入アイコン ([+] 記号) をクリックして、場所を選択します。ルールは、表示されている順に処理されます。

[Insert Rule] をクリックして新しいルールを定義します。ルールは、ホスト、パス、または両方を参照できます。ホストのみを使うことにします。

ホストベースのルーティング用に 2 つのルールを追加します。エディタは次のようになります。

プロダクションおよびサンドボックスのトラフィックを別々のターゲットにルーティングする場合は、パスを参照する新しいルールを作成できます。最初のルールは次のとおりです。

数回クリックして少し入力するだけで、強力なルール群を作成できます。

Host ヘッダーと一致するルールには、最大 3 つの “*” (0 個以上の文字と一致) または “?” (1 文字と一致) ワイルドカードを含めることができます。大規模なお客様のそれぞれに、追跡目的で、独自のホスト名を付けることにします。ホスト名の最後の部分にかかわらず、すべてのリクエストを同じターゲットグループにルーティングするルールを記述できます。シンプルな例は次のとおりです。

ルールエディタの鉛筆アイコンを使用すると、ルールの順番を変更できます。ルールを選択して、別の場所に移動し、新しい順番を保存します。

既存のルールの編集や、不要なルールの削除を行うこともできます。

今すぐ利用可能
この機能は、本日からすべてのパブリック AWS リージョン (15 か所) で利用できます。各ロードバランサーで評価される最初の 10 個のルール (ホストベース、パスベース、または両方) は無料です。その後は、ルールの評価数に基づいて課金されます (これは前回の投稿で説明したロードバランサーのキャパシティーユニット (LCU) に新しく追加されたディメンションです)。各 LCU は最大 1000 ルールの評価をサポートします。LCU の 4 つすべてのディメンションが測定されますが、課金されるのは特定の時間内で最も使用量が多いディメンションのみです。設定されていても処理されないルールは課金対象外です。

Jeff;

SAP on AWSにおけるVPCサブネットのゾーニングパターン

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。

企業のファイアウォール内に存在する必要があるSAPランドスケープの設計は比較的簡単ですが、内部からも外部からも接続する必要があるSAPアプリケーションの場合はそうではありません。これらのシナリオでは、必要なコンポーネントとその配置場所について悩むことがよくあります。

この一連のブログ記事では、SAPアプリケーションにおけるAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンを紹介し、例を用いてその使用方法を説明します。セキュリティグループルートテーブルおよびネットワークアクセスコントロールリスト(ACL)の構成と合わせて、よくあるお客様シナリオに基づいた詳細な図で補足しながら、接続経路ごとにいくつかのアーキテクチャ設計パターンを説明します。

アプリケーションを配置するサブネットを正しく見極めるには、アプリケーションへの接続方法を理解することが必要です。SAPアプリケーションに接続する方法をいくつか見てみましょう。

  • 内部専用接続: これらのアプリケーションは内部的にのみ接続します。SAPサポートチームを除き、外部からの接続は許可されていません。この場合、ユーザーまたはアプリケーションは、専用線または仮想プライベートネットワーク(VPN)を介して接続された企業ネットワーク内に存在する必要があります。SAP Enterprise Resource Planning(ERP)、SAP S/4HANA、SAP Business Warehouse(BW)およびSAP BW/4HANAはほとんどの組織で内部専用接続が必要なアプリケーションです。
  • 内部および管理された外部接続: これらのアプリケーションは内部的に接続しますが、既知の外部の関係者に限定した接続も提供します。例えば、内部プロセスからSAP PI(Process Integration)やSAP PO(Process Process Orchestration)を使用することができますし、既知の外部の関係者もホワイトリストに登録されたIPアドレスからソフトウェアのインターフェースに接続することができます。さらに、SAP SuccessFactors、SAP Cloud Platform、SAP AribaなどのSaaS(Software as a Service)ソリューションとの統合は、AWS上で実行されるSAPソリューションに機能を追加する場合にも望まれます。
  • 内部および管理されていない外部接続: SAP hybrisや社外に公開するSAP Enterprise Portalなどのアプリケーションがこのカテゴリーに分類されます。これらのアプリケーションには一般に外部接続が可能ですが、管理、構成および他の内部アプリケーションとの統合のためのコンポーネントなど、内部接続用のコンポーネントがあります。
  • 外部専用接続: ほとんどのコンポーネントが外部から接続可能であっても、アプリケーションにはバックアップ、接続制御、インターフェースなどの基本的な管理タスクのために内部から接続できる必要があるため、稀なシナリオです。このシナリオは滅多にないため、この一連のブログ記事では説明しません。

このブログ記事では、最初のカテゴリーのアプリケーション(内部でのみ接続可能なアプリケーション)で取り得るアーキテクチャパターンについて説明します。今後の記事で、残りの2つのシナリオについて説明します。3つすべてのシナリオにおいて、パッチ、更新プログラムの適用およびその他の関連するシナリオに対処するために、ネットワークアドレス変換(NAT)デバイス(IPv4の場合)Egress-Onlyインターネットゲートウェイ(IPv6の場合)を使用して、AWSリソースからインターネットに接続すると仮定します。さらに、この接続は、インバウンド(インターネットからAWSクラウドへの)接続要求を制限または排除する方法で管理します。

内部専用接続におけるアーキテクチャ設計パターン

このカテゴリーのSAPアプリケーションについて、データベースとアプリケーションサーバーを同じプライベートサブネットまたは分離したプライベートサブネットに配置する2つの設計パターンを見ていきます。

単一のプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には3つのサブネットがあります。

  • パブリックサブネット: SAProuterとNATゲートウェイまたはNATインスタンスをこのサブネットに配置します。SAPから指定されたパブリックIPアドレスのみがSAProuterに接続できます。詳細は、SAPノート28976 – リモート接続データシートを参照してください。(SAPノートの閲覧にはSAPサポートポータルへの接続が必要です)。
  • 管理用のプライベートサブネット: Microsoft System Center Configuration Manager(SCCM)などの管理ツール、管理者または踏み台ホストをこのサブネットに配置します。このサブネット内のアプリケーションは、エンドユーザーが直接接続するのではなく、エンドユーザーをサポートするために必要です。このサブネット内のアプリケーションは、パブリックサブネットに配置されたNATゲートウェイまたはNATインスタンスを介してインターネットに接続できます。
  • アプリケーションとデータベース用のプライベートサブネット: データベースとアプリケーションをこのサブネットに配置します。SAPアプリケーションは、SAP GUI経由またはSAP Webディスパッチャを介したHTTP/S経由でエンドユーザーから接続できます。エンドユーザーはデータベースに直接接続することはできません。

異なるプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には4つのサブネットがあります。パブリックサブネットと管理用のプライベートサブネットは以前のシナリオと同じ機能を持ちますが、3つ目のサブネット(データベースとアプリケーション用のプライベートサブネット)が2つに分割されています。データベース用のプライベートサブネットには、ユーザー環境からアクセスできません。

これらの2つのアプローチの間に大きな違いはないことが分かります。ただし、2つ目の方法では、データベース用のサブネットを別のルートテーブルとネットワークACLで保護することで、データベースをより安全に保護します。これにより、データベース層への接続をより効果的に制御、管理できます。

私たちの知識を活用

実装例を検討することで、詳細に落とし込んでみましょう。

シナリオ例

お客様は、SAP S/4HANA、SAP FioriおよびSAP BW on HANA(ABAPとJava)を導入する必要があります。これらのアプリケーションは、企業ネットワークからのみ接続可能である必要があります。SAML(Security Assertion Markup Language)によるシングルサインオン(SSO)のために、Active Directory(AD)またはActive Directory フェデレーション サービス(ADFS)との統合も必要です。SAP BWはレガシーアプリケーションとのファイルベースの統合も行い、この目的でSSHファイル転送プロトコル(SFTP)サーバーと通信します。SAP社はサポートのためにこれらのシステムに接続できる必要があります。SAP Solution ManagerのデータベースにはSAP ASEを採用し、SAPアプリケーションの集中監視および変更管理に使用します。すべてのアプリケーションは、SUSE Linux Enterprise Server(SLES)上で稼働していると仮定します。

AWS上のソリューション

この例では、ソリューション要素あたり1つのEC2インスタンスしか想定していません。ワークロードが水平方向にスケールする場合、または高可用性が必要な場合は、機能的に類似した複数のEC2インスタンスを同じセキュリティグループに含めることができます。この場合、セキュリティグループにルールを追加する必要があります。企業ネットワークとVPC間の接続には、IPsecベースのVPNを使用します。Red Hat Enterprise Linux(RHEL)またはMicrosoft Windows Serverを使用している場合は、セキュリティグループ、ルートテーブル、およびネットワークACLに設定変更が必要な場合があります。詳細については、オペレーティングシステムの製品マニュアル、またはAmazon Elastic Compute Cloud(EC2)のセキュリティグループのルールのリファレンスなど、その他の情報源を参照してください。プライマリーのADまたはADFSサーバー、レガシーSFTPサーバーなどの特定のシステムはオンプレミスに残ります。

ソリューションのアーキテクチャ図は以下です。

このアーキテクチャ図の設定例は以下を想定しています。

以下の表は、セキュリティグループの構成例です。セキュリティグループで定義されるルールの概要を示しています。正確なポート番号または範囲については、SAP製品のマニュアルを参照してください。

ネットワークトラフィックのフローは、以下のようなルートテーブルによって管理されています。

*AWS Data Providerは、Amazon CloudWatch、Amazon S3およびAmazon EC2のAWS APIに接続できる必要があります。詳細は、「AWS Data Provider for SAP Installation and Operations Guide」を参照してください。

インスタンスに追加の層のセキュリティが必要な場合、以下の表に示すようなネットワークACLを使用できます。ネットワークACLは高速かつ効率的で、前述の表に示すセキュリティグループに加えて、別の制御層を提供します。セキュリティの推奨事項については、「AWS Security Best Practices」を参照してください。

ある特定の時に(OSパッチ適用など)、EC2インスタンスから追加のインターネット接続が必要な場合があります。ルートテーブル、ネットワークACLおよびセキュリティグループは、この接続を一時的に許可するように調整できます。

ここまでの概要と今後の予定

このブログ記事では、内部専用接続が必要なアプリケーションにおけるサブネットのゾーニングパターンを例に説明してきました。他のサブネットのゾーニングパターンについては、このシリーズの次の記事を参照してください。

AWS上でSAPアプリケーション用のVPCを設定した皆様の経験についてもお聞きしたいと思います。この記事に関するご質問やご提案がありましたら、お気軽にお問い合わせください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。

AWS Organizationsを利用したアカウント作成の自動化

こんにちは、ソリューションアーキテクトの千葉です。

本日はAWS Organizationsを利用したAWSアカウントの作成・管理の自動化方法についてご紹介します。

AWS Organizationsは、組織内のAWSアカウントを統合管理し、セキュリティを高めることができるサービスです。サービスコントロールポリシー (SCP)を利用することで、組織内のAWSアカウントに実行を許可するサービスとアクションを一元的に管理することができます。
AWS Organizationsのもう一つの特徴は、APIを通じて組織配下に新しいAWSアカウントを作成することができることです。これまでは、AWSアカウントを新たに作るにあたって、AWSアカウント作成、連絡先情報入力、お支払情報入力、(必要に応じて)一括請求設定といった手順をマニュアルで実施する必要がありましたが、AWS Organizationsを利用すればこれらの操作はCreateAccountというたった一つのAPIに置換えられます。

AWS Organizationsで作成されたメンバーアカウントには、マスターアカウントのユーザーからアクセス可能なIAMロールが自動作成されます。AWS Security Token Service (STS)を利用してこのIAMロールにアクセスする一時的なセキュリティ認証情報を取得し、AWS Command Line Interface (CLI)AWS SDKsを使って作成したメンバーアカウントに対して共通設定を施したり、定期的な環境チェックを実行したりすることができます。

それでは、アカウント作成およびSTSを利用したアカウント環境設定の手順を説明していきます。

 

メンバーアカウントの作成

まずは組織配下にメンバーアカウントを作成します。操作を実行するIAMユーザーまたはIAMロールには、以下のようにOrganizationsを操作する権限を与えておきます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                 "organizations:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

CreateAccountのパラメーターには、アカウント名およびEmailアドレスを指定する必要があります。IamUserAccessToBillingパラメーターはメンバーアカウントのIAMユーザーにBilling情報へのアクセスを許可するかどうかの設定で、デフォルトでALLOWになっています。RoleNameパラメーターはメンバーアカウントに作成されるIAMロールの名前で、何も指定しなければOrganizationAccountAccessRoleという名前が割り当てられます。

import boto3
orgs = boto3.client('organizations',region_name='us-east-1')
createAccountRequest = orgs.create_account(
    "AccountName": "string",
    "Email": "string",
    "IamUserAccessToBilling": "string",
    "RoleName": "string"
    )

メンバーアカウントの作成は非同期でおこなわれるため、CreateAccountAPIのレスポンスに含まれるリクエストIDを指定してDescribeCreateAccountStatusを実行し、アカウント作成のステータスをトラッキングします。

createAccountRequestId = createAccountRequest["CreateAccountStatus"]["Id"]
while orgs.describe_create_account_status(CreateAccountRequestId=createAccountRequestId)["CreateAccountStatus"]["State"] != 'SUCCEEDED':
        time.sleep(5)

ステータスが”SUCCEEDEDになればメンバーアカウントの作成は完了です。DescribeCreateAccountStatusのレスポンスは以下のとおりです。AccoutIdは後の手順で利用します。

{
   "CreateAccountStatus": { 
      "AccountId": "string",
      "AccountName": "string",
      "CompletedTimestamp": number,
      "FailureReason": "string",
      "Id": "string",
      "RequestedTimestamp": number,
      "State": "string"
   }
}

 

STSを利用したメンバーアカウントの操作

STSは、AWS リソースへアクセスする一時的な認証情報を提供する機能です。STSの利用方法の詳細はこちらのドキュメントを参照してください。一時認証情報取得にはSTSのAssumeRoleアクションを実行する必要があるので、以下の操作を実行するマスターアカウントのIAMユーザー/IAMロールには以下のIAMポリシーを付与しておいてください。<MemberAccountId>には前手順で取得したメンバーアカウントのAWSアカウントIDを指定します。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<MemberAccountId>:role/OrganizationAccountAccessRole"
  }]
}

STSのAssumeRoleアクションを実行し、一時的な認証情報を取得します。

import boto3
from boto3.session import Session

sts = boto3.client('sts')
assumeRoleResult = sts.assume_role(
        RoleArn = 'arn:aws:iam::<MemberAccountId>:role/OrganizationAccountAccessRole',
        RoleSessionName = 'OrgMasterRoleSession'
        )

accessKeyId = assumeRoleResult["Credentials"]["AccessKeyId"]
secretAccessKey = assumeRoleResult["Credentials"]["SecretAccessKey"]
sessionToken = assumeRoleResult["Credentials"]["SessionToken"]

続いて、取得した一時認証情報でメンバーアカウントを操作するセッションを生成します。regionパラメーターはこの後実行する操作に合わせて指定してください。

session = Session(
        aws_access_key_id=accessKeyId,
        aws_secret_access_key=secretAccessKey,
        aws_session_token=sessionToken,
        region_name='us-east-1'
        )

あとはこのセッションを利用してメンバーアカウントに対して操作をおこなうだけです。OrganizationAccountAccessRoleにはAdministratorAccessポリシーがアタッチされているため、STSをサポートしているアクションであればすべて実行可能です。

試しに作成したメンバーアカウントに対してBillingアラートを設定してみましょう。

sns = session.client('sns')
cloudwatch = session.client('cloudwatch')
    
#create sns topic
snsTopicArn = sns.create_topic(Name='DefaultBillingAlertTopic')["TopicArn"]
sns.subscribe(
    TopicArn=snsTopicArn,
    Protocol='email',
    Endpoint=<YourEmailAddress>
    )

#create billing alert
alertName = 'DefaultBillingAlart'
cloudwatch.put_metric_alarm(
    AlarmName=alertName,
    AlarmDescription=alertName,
    ActionsEnabled=True,
    AlarmActions=[snsTopicArn],
    MetricName='EstimatedCharges',
    Namespace='AWS/Billing',
    Statistic='Maximum',
    Dimensions=[
        {
           'Name': 'Currency',
           'Value': 'USD'
        },
        ],
   Period=21600,
   EvaluationPeriods=1,
   Threshold=100,
   ComparisonOperator='GreaterThanOrEqualToThreshold'
   )

まとめ

リソースをプログラマブルに管理できることは、AWSを利用する大きな利点のひとつです。AWS Organizationsを利用することで、AWSアカウントについてもプラグラマブルに管理することが可能です。今回はBillingアラートを設定する例をご紹介しましたが、AWS CloudTrailAWS Configなどの有効化、AWS CloudFormationを利用した標準構成のデプロイなど、お客様がAWSアカウントを作成時に実行している操作を自動化することができます。ぜひOrganizationsを活用したアカウント管理をお試しください!

 

注1:SCPの権限制御は、アタッチされたアカウントのrootユーザーを含む、すべてのユーザーに影響を与える可能性がある強力な機能です。既存のアカウントに対してOrganizationsを適用する場合、SCPの動作を事前に検証し、実行する操作が既存環境に影響が出ないことを確認した上で有効化してください。

注2:Organizationsで作成したメンバーアカウントは削除することができませんのでご注意ください。