APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

Amazon ConnectをAWS CloudFormationで管理する

こんにちは、クラウド事業部の山路です。

今回は表題の通り、Amazon ConnectをAWS CloudFormationで管理する例を紹介いたします。

なお、Amazon Connectについては以前弊社ブログでも紹介されていますので、そちらをご覧ください。

techblog.ap-com.co.jp

背景

Amazon ConnectのAWS CloudFormationへの対応は少しずつアップデートされており、2023年7月にはルーティングプロファイル・キュー、9月にはセキュリティプロファイルの作成がサポートされました。

aws.amazon.com

aws.amazon.com

上記アップデートにより、Amazon Connectの利用を開始するうえで必要な最低限のリソースは一通りCloudFormationで管理できるようになりました。

今回は、Amazon Connectを検証用に用意するためのCloudFormationテンプレートを作成しました。ちょっとした検証などにご利用いただければと思います。

検証

今回用意したテンプレートは以下になります。

CloudFormationテンプレート

AWSTemplateFormatVersion: '2010-09-09'
Description: Amazon Connect Instance
Parameters:
  PJPrefix:
    Type: String
  Password:
    Type: String
  PhoneNumber:
    Type: String
  Username:
    Type: String
Resources:
  Instance:
    Type: AWS::Connect::Instance
    Properties:
      Attributes:
        ContactflowLogs: true
        InboundCalls: true
        OutboundCalls: true
      IdentityManagementType: CONNECT_MANAGED
      InstanceAlias: !Ref PJPrefix
  S3BucketForCallRecording:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${PJPrefix}-bucket
  InstanceStorageConfig:
    Type: AWS::Connect::InstanceStorageConfig
    Properties:
      InstanceArn: !GetAtt Instance.Arn
      ResourceType: CALL_RECORDINGS
      S3Config:
        BucketName: !Ref S3BucketForCallRecording
        BucketPrefix: CallRecordings
      StorageType: S3
  HoursOfOperation:
    Type: AWS::Connect::HoursOfOperation
    Properties:
      Config:
        - Day: SUNDAY
          EndTime:
            Hours: 12
            Minutes: 0
          StartTime:
            Hours: 12
            Minutes: 0
        - Day: MONDAY
          EndTime:
            Hours: 12
            Minutes: 0
          StartTime:
            Hours: 12
            Minutes: 0
        - Day: TUESDAY
          EndTime:
            Hours: 12
            Minutes: 0
          StartTime:
            Hours: 12
            Minutes: 0
        - Day: WEDNESDAY
          EndTime:
            Hours: 12
            Minutes: 0
          StartTime:
            Hours: 12
            Minutes: 0
        - Day: THURSDAY
          EndTime:
            Hours: 12
            Minutes: 0
          StartTime:
            Hours: 12
            Minutes: 0
        - Day: FRIDAY
          EndTime:
            Hours: 12
            Minutes: 0
          StartTime:
            Hours: 12
            Minutes: 0
        - Day: SATURDAY
          EndTime:
            Hours: 12
            Minutes: 0
          StartTime:
            Hours: 12
            Minutes: 0
      InstanceArn: !GetAtt Instance.Arn
      Name: !Sub ${PJPrefix}-hours-of-operation
      TimeZone: Asia/Tokyo
  Queue:
    Type: AWS::Connect::Queue
    Properties:
      HoursOfOperationArn: !GetAtt HoursOfOperation.HoursOfOperationArn
      InstanceArn: !GetAtt Instance.Arn
      Name: !Sub ${PJPrefix}-queue
  RoutingProfile:
    Type: AWS::Connect::RoutingProfile
    Properties:
      DefaultOutboundQueueArn: !GetAtt Queue.QueueArn
      Description: initial routing profile for User creation by CFn
      InstanceArn: !GetAtt Instance.Arn
      MediaConcurrencies:
        - Channel: CHAT
          Concurrency: 1
        - Channel: TASK
          Concurrency: 1
        - Channel: VOICE
          Concurrency: 1
      QueueConfigs:
        - Delay: 0
          Priority: 1
          QueueReference:
            Channel: VOICE
            QueueArn: !GetAtt Queue.QueueArn
      Name: !Sub ${PJPrefix}-routing-profile
  SecurityProfile:
    Type: AWS::Connect::SecurityProfile
    Properties:
      InstanceArn: !GetAtt Instance.Arn
      SecurityProfileName: !Sub ${PJPrefix}-security-profile
      Permissions:
        - AccessMetrics
        - AccessMetrics.AgentActivityAudit.Access
        - AccessMetrics.HistoricalMetrics.Access
        - AccessMetrics.RealTimeMetrics.Access
        - AgentGrouping.Create
        - AgentGrouping.Edit
        - AgentGrouping.EnableAndDisable
        - AgentGrouping.View
        - AgentStates.Create
        - AgentStates.Edit
        - AgentStates.EnableAndDisable
        - AgentStates.View
        - AgentTimeCard.View
        - AudioDeviceSettings.Access
        - BasicAgentAccess
        - ChatTestMode
        - ConfigureContactAttributes.View
        - ContactAttributes.View
        - ContactFlowModules.Create
        - ContactFlowModules.Delete
        - ContactFlowModules.Edit
        - ContactFlowModules.Publish
        - ContactFlowModules.View
        - ContactFlows.Create
        - ContactFlows.Delete
        - ContactFlows.Edit
        - ContactFlows.Publish
        - ContactFlows.View
        - ContactLensCustomVocabulary.Edit
        - ContactLensCustomVocabulary.View
        - ContactSearch.View
        - ContactSearchWithCharacteristics.Access
        - ContactSearchWithCharacteristics.View
        - ContactSearchWithKeywords.Access
        - ContactSearchWithKeywords.View
        - ContentManagement.Create
        - ContentManagement.Delete
        - ContentManagement.Edit
        - ContentManagement.View
        - CustomViews.Access
        - CustomerProfiles.Create
        - CustomerProfiles.Edit
        - CustomerProfiles.View
        - DeleteCallRecordings
        - DownloadCallRecordings
        - Evaluation.Create
        - Evaluation.Delete
        - Evaluation.Edit
        - Evaluation.View
        - EvaluationForms.Create
        - EvaluationForms.Delete
        - EvaluationForms.Edit
        - EvaluationForms.View
        - ForecastScheduleInterval.Edit
        - ForecastScheduleInterval.View
        - GraphTrends.View
        - HistoricalChanges.View
        - HoursOfOperation.Create
        - HoursOfOperation.Delete
        - HoursOfOperation.Edit
        - HoursOfOperation.View
        - ListenCallRecordings
        - ManagerBargeIn
        - ManagerListenIn
        - MetricsReports.Create
        - MetricsReports.Delete
        - MetricsReports.Edit
        - MetricsReports.Publish
        - MetricsReports.Schedule
        - MetricsReports.Share
        - MetricsReports.View
        - MyContacts.View
        - OutboundCallAccess
        - PhoneNumbers.Claim
        - PhoneNumbers.Edit
        - PhoneNumbers.Release
        - PhoneNumbers.View
        - Prompts.Create
        - Prompts.Delete
        - Prompts.Edit
        - Prompts.View
        - Queues.Create
        - Queues.Edit
        - Queues.EnableAndDisable
        - Queues.Purge
        - Queues.View
        - RealtimeContactLens.View
        - RedactedData.View
        - ReportSchedules.Create
        - ReportSchedules.Delete
        - ReportSchedules.Edit
        - ReportSchedules.View
        - ReportsAdmin.Access
        - ReportsAdmin.Delete
        - ReportsAdmin.Publish
        - ReportsAdmin.Schedule
        - ReportsAdmin.View
        - RoutingPolicies.Create
        - RoutingPolicies.Edit
        - RoutingPolicies.View
        - Rules.Create
        - Rules.Delete
        - Rules.Edit
        - Rules.View
        - ScreenRecording.Access
        - ScreenRecording.Delete
        - ScreenRecording.Download
        - SecurityProfiles.Create
        - SecurityProfiles.Delete
        - SecurityProfiles.Edit
        - SecurityProfiles.View
        - StopContact.Enabled
        - TaskTemplates.Create
        - TaskTemplates.Delete
        - TaskTemplates.Edit
        - TaskTemplates.View
        - Transcript.View
        - TransferContact.Enabled
        - TransferDestinations.Create
        - TransferDestinations.Delete
        - TransferDestinations.Edit
        - TransferDestinations.View
        - UnredactedData.View
        - UpdateContactSchedule.Enabled
        - Users.Create
        - Users.Delete
        - Users.Edit
        - Users.EditPermission
        - Users.EnableAndDisable
        - Users.View
        - Views.View
        - VoiceId.Access
        - VoiceIdAttributesAndSearch.View
        - Wisdom.View
  User:
    Type: AWS::Connect::User
    Properties:
      IdentityInfo:
        FirstName: firstname
        LastName: lastname
        Email: example@email.com
      InstanceArn: !GetAtt Instance.Arn
      Password: !Ref Password
      PhoneConfig:
        DeskPhoneNumber: !Ref PhoneNumber
        PhoneType: SOFT_PHONE
      RoutingProfileArn: !GetAtt RoutingProfile.RoutingProfileArn
      SecurityProfileArns:
        - !GetAtt SecurityProfile.SecurityProfileArn
      Username: !Ref Username

今回作成するリソースとCloudFormationの公式ページは以下の通りです。

リソース間の関係をApplication Composerで表したのが以下の図になります。

こちらのテンプレートを使用してAmazon Connectを作成します。今回パラメータは以下のように設定しました。

  • PJPrefix: connect-test-20231220
  • Password: Passw0rd
  • PhoneNumber: +12345678902
  • Username: test-user

作成完了後、Amazon ConnectのURLにアクセスし、作成したユーザーの名称とパスワードを使用してログインできるのを確認します。

あとは電話番号の取得や問い合わせフローの作成など、必要に応じて検証を進めていきます。検証が完了したらCloudFormationスタックを削除すれば、リソースの削除も簡単に完了します。

最後に

今回はAmazon ConnectをCloudFormationで作成する例を紹介しました。今回は主に検証での利用を想定していますが、実際の案件でも、例えばリージョン規模の障害発生時、CloudFormationテンプレートを使って、別リージョンに同じ環境を作成する、などの使い方もアリかと思います。

弊社はAWSアドバンスドティアサービスパートナー認定を受けております。また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp

API Gatewayでスタブを作るPart 1! Mockってこんなに簡単に作れるんですね,,,

はじめに

こんにちは!

クラウド事業部の升谷です。

もう12月か、、とか言っていたらもう最終営業日になってしいました。

本当に一年早い、、T-T

そんな12月、私はとても簡単にスタブを作る術を学んだので、

今回は、API Gatewayにてスタブを作る手順の紹介です!

この前は、AppSyncについて紹介しました。

techblog.ap-com.co.jp

聞いたことあるけど使ったことない、そんな距離感のAWSサービスが山ほどありますが、

今回はAPI Gatewayさんと仲良くなることができました。

API Gatewayで簡単にMockを作ろう

私は単体試験用のMockAPIを作成する用途でスタブを作成しました。

早速作っていきましょう。REST APIで構築。

新しいAPIを選択し、名前を決める。

次にリソースを作成します。

ここが、APIのURLのパスになってきますよ。

パスの階層ごとにリソースを作ってあげましょう。

APIのURLを最後まで作成したら、いよいよメソッドを作ります。

今回はGetメソッドの統合タイプはMockを選択。

ここまで来たらもうそれっぽくなってきました。

統合レスポンスのタブにて編集をクリック。

APIが200 OKの場合、どんな応答を返すかをここで定義します。

(私は猫派でシンバという猫を飼っています。

12月なのでホットカーペットで伸びています。それだけで癒される。。。)

ここまで来たらもうお店に並ぶ前のパン同然です。

一応、応答の確認を行いましょう。

テストタブに移動しテストをクリック!

ステータス、レスポンスに問題ないことを確認します。

さあ、最後に出荷しましょう。ということでデプロイします。

ステージ名はつけてもつけなくてもいいです。

つける場合、APIのURLの一部になるので注意しましょう。

デプロイ済みのAPIは左のステージをクリックすることで確認できます。

ここで、先ほど作ったGETが出てくるまでを押していきましょう。

下記の矢印のURLこそが今回の成果物になります!

一つ前の画像のURLにアクセスしてもエラーになるだけなので注意です。

このURLをブラウザに入力したり、curl {URL}とコマンド打ったりすることで、

APIの応答が確認できるはずです!

今のままだとAPIがセキュアではないので、次はAPIキーを付与する方法を紹介します!

おわりに

今回はスタブを作る方法を紹介しましたー!

とても簡単だったとおもいます!

AWS初心者でもAPI Gatewayを使いこなしていきましょう!

それではー!

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: <升谷>
AWSをメインにインフラ系のご支援を担当しています。

AWS 認定の12資格を全部取ったので所感を綴る

はじめに

こんにちは、クラウド事業部の坂口です。

長く人生を過ごしていると、ふとAWS認定資格を全部取ろう!と感じる瞬間があると思います。

例に漏れずそのような情念に駆られた私ですが、珍しく本懐を遂げることができたので所感を書いていきます。

要は全冠したので頑張ったアピールです。

2023/12 時点で公開されている認定資格の中で、
ベータ版の AWS Certified Data Engineer - Associate (DEA-C01) を除いた12資格を対象としています

Credly での AWS Badges


自身について

私自身の略歴なんかはこんな感じです。

  • 他業界のエンジニアから IT のエンジニアに転身
  • サーバエンジニアとして運用・保守/設計・開発なんかを経験
  • 2022年からAWSを扱う業務に携わる (なので、お仕事としての AWS は経験 2年目)


その他、パーソナルな性質として

  • 多分、勉強は嫌いでない
  • 計画性は乏しい


また、他の人から言われたことは特にないですが、

  • 品行方正
  • 清廉潔白
  • 質実剛健
  • 豪放磊落

を定期的に自称しています。


取得のスケジュール

振り返ってみると、以下の流れで AWS 認定資格を取得していました。

とはいえ先述した通り計画性に乏しいため、取得時期や順番は雰囲気で決めていた気がします。


合格日 認定試験名 スコア 自記事
2019-08-05 AWS Certified Solutions Architect - Associate (SAA-C01) 881 -
2022-07-31 AWS Certified Solutions Architect - Professional (SAP-C01) 777 -
2023-04-16 AWS Certified Database - Specialty (DBS-C01) 838 DAS
2023-06-27 AWS Certified Security - Specialty (SCS-C01) 854 SCS
2023-07-15 AWS Certified Data Analytics - Specialty (DAS-C01) 834 DAS
2023-08-12 AWS Certified SysOps Administrator - Associate (SOA-C02) 832 SOA
2023-08-28 AWS Certified Machine Learning - Specialty (MLS-C01) 804 MLS
2023-09-09 AWS Certified Developer - Associate (DVA-C02) 835 DVA
2023-11-19 AWS Certified Advanced Networking - Specialty (ANS-C01) 811 ANS
2023-11-28 AWS Certified: SAP on AWS - Specialty (PAS-C01) 932 PAS
2023-12-11 AWS Certified DevOps Engineer - Professional (DOP-C02) 891 DOP
2023-12-11 AWS Certified Cloud Practitioner (CLF-C02) 838 CLF

※ 表は同じく全冠達成された原田さん記事での形式を流用しています

資格それぞれについて

最初の SAA は弊社の社内研修で AWS に触れる機会があり、その流れで取得しました。

当時は AWS を特に業務で扱っていなかったこと、またいかんせん数年前であることから、記憶は大分薄れていますね...。

SAP は、昨年 (2022年) に AWS を扱う業務に携わり始めたことや会社としての後押しもあって取得に至っています。

正直今でも私は SAP が一番難しかったと感じていますが、こちらは苦労が大きかったことで美化されている部分はありそうです。

(ぶっちゃけ AWS の習熟度が低かったことによる勉強や試験での苦労が、難しかったという感覚につながっているとは思います)


残りの10資格 については、今年に入ってから昨年よりも強めの後押しが弊社内であったことがきっかけであるものの、当初はマイペースに取得を進めていました。

しかし取り組んでいるうちになんだか全冠が見えてきたのでスパートをかけた、という形になっています。

直近の4資格は1ヶ月間で頑張っているようなので、キリ良く年内で達成したかったのでしょう。


学習について

教材

私が学習を進める中で使用した教材はおおよそ以下の通りです。

それぞれから良さそうなものがあれば使ってみる感じでした。

  • AWS Skill Builder
    • 公式ということもあり、なんだかんだ一番好きかもしれない
    • 簡易的な問題集だけでなく、(認定試験とは直接関係ないものの) 分野ごとの基礎的な学習コンテンツがあったりして助かりました
    • 無料の範囲でも色々あるため、とりあえずの第一歩で教材を探してみても良いと思います
  • 書籍
    • 主に認定試験の参考書
    • 特に Specialty 試験では『要点整理から攻略する』シリーズにはお世話になりました
  • Udemy
    • 動画の講座は受動的な学習を行えること、認定試験を前提としているので要点を絞って解説してくれることがメリット
    • 日本語で解説されている講座はもちろん、英語での解説講座もありがたかったです
  • Web 問題集
    • 主に Teck Stock (CloudLicense) を利用
    • 短期間で取得するなら、やはり使いやすいと思いました

勉強方法

勉強方法としては特別なことはしていないと思います。

なので細かくは書かないのですが、いわゆる "難しい" とされているような認定試験については

Web 問題集以外の教材を積極的に利用していました。(私の場合は SAP, DOP, ANS あたり)

体系的にまとめられている教材はやはり学習がしやすく、結果的に理解につながりやすいと思います。

個人的には、そうした教材は認定試験が関係ない場合にもサービスの振り返りで使えたりするので好みだったりします。


12資格を全部取ってみて

各分野の認定資格取得のために勉強することで、当然ながら AWS に関係する内容に触れる時間が多くなり、

自身の中でより広く深く AWS の理解を促進することができたと思います。

私は勉強するにしても目標がある方が取り組みやすいので、認定資格取得という分かりやすいゴールはうってつけでした。


ただ、認定試験で問われることが知識や概念であるため、実際に業務で求められる成果や品質の向上に

大きくつながっているかというと、それはまだまだだと思っています。

(むしろ期待が上がっちゃいそうで心配)

全冠であることは強烈なアピールになるとは思いますが、よりエンジニアとしての価値が問われているような感覚も否めません。


とはいえ総合的に見て、AWS への理解が進んだことや自信が深まったこと、成果として分かりやすい証明になることなど

メリットも充分大きいものであったと感じました。

今後とも、張り子の虎にならないようより一層精進していきたいものです。

これから AWS 認定資格の全冠を目指される、もしくは目指している方にとって、それがより良い経験になりますように。


それではご機嫌なAWSライフを!


おわりに

APCはAWSセレクトティアサービスパートナー認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: さかぐち
AWSをメインにインフラ系のご支援を担当しています。最近 AWS 全冠しました。

AWS Certified Cloud Practitioner (CLF-C02) に合格したので所感を綴る

はじめに

こんにちは、クラウド事業部の坂口です。

先日 AWS Certified Cloud Practitioner に合格したので、とりあえずで所感を書いていきます。

なお こちら の記事で取り上げた DOP の試験後に、そのまま同じテストセンターで受験しました。

点数

838

勉強期間

同日で先に受験した DOP の方に集中したかったため、本試験は勉強せずに臨みました。

最後のAWS資格試験だったということもあり、半ば勢いだったことは否めません。

教材

先述の通り本試験のために特別勉強はしていないので、 ないです

試験の感想

基礎的な試験ということもあり、Professional と比べると問われることが非常に簡潔で、試験も緊張することなく取り組めたと思います。

サービス名を答えるのみの問題は疲れた体に沁みました。

それでも、問われる内容が難しいわけではなかったのですが、一部馴染みのなかったサービスや要素についての出題があり、

(勉強しなかったせいで) 意外と気が抜けない面もあったように感じます。

  • ex.) AWS Wavelength やら、AWS Cloud Adoption Framework パースペクティブの中身やら


ちなみにテストセンターでは DOP と連続する時間で試験を予約していたのですが、そういった受験の仕方があまり無いことなのか

受付で若干混乱させてしまってなんとなく申し訳ない気持ちになりました。

ともあれ、私としてはこれですべてのAWS資格を取得することができたので良かったです。


それではご機嫌なAWSライフを!

おわりに

APCはAWSセレクトティアサービスパートナー認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: さかぐち
AWSをメインにインフラ系のご支援を担当しています。

AWS Certified DevOps Engineer - Professional (DOP-C02) に合格したので所感を綴る

はじめに

こんにちは、クラウド事業部の坂口です。

先日 AWS Certified DevOps Engineer - Professional に合格したので、もう年の瀬ではありますが所感を書いていきます。

点数

891

勉強期間

勉強を始めたのは試験の1週間前程度、時間にして 20~ h くらいかと思います。

年内には取らなば、ということで短期集中して勉強をする形になりましたが、もっと時間をかけて計画的に取り組んだ方が良かったのは言わずもがなです。

とはいえ、モチベーションはそこそこあったようで、あまりダレることなく勉強を進められました。

教材

勉強に使用した教材は次の通りです。

ボリュームがある試験ということもあり (加えて勉強期間が短いということもあり)、少ない教材に絞って学習しました。

1. Udemy - AWS Certified DevOps Engineer Professional 2023 - DOP-C02

www.udemy.com

  • 全編英語のため、動画を日本語字幕付きで学習
    • 試験で扱われるサービスについて要点を踏まえて解説してくれる
    • 動画は取り扱われる内容で細かく分けられているため、自分に必要な個所を集中的に取り組めるのがありがたい
    • 一部サービスは講師の方のハンズオンも見られるので、特に馴染みがないサービスの理解の助けになった


2. Cloud License - AWS Certified: SAP on AWS - Specialty

DOP | CloudLicense | AWS WEB問題集で学習しよう

  • おなじみ。旧問題を除く、以下のナンバーについて学習
    • #38-79

試験の感想

やはり Professional ということもあり問題数や問題ごとの文章量が多く、読み解くことに苦労しました。

選択肢も細かいニュアンスの違いで正誤が分かれたりするため、集中力も必要で他の試験に比べると体力的/精神的に疲労度が大きかった印象です。

とはいえ取り扱われている概念やサービスが (個人的に) 面白いものだったおかげで、何とか勉強を継続でき試験に臨むことができたと思います。

ちなみに AWS OpsWorks はサポート終了が決まっているものの、試験本番では選択肢に名前だけ登場してちょっと興奮しました。

ただ終わってみれば Solutions Architect - Professional に比べるとやはり簡単なような気はしますが、なんにせよ無事合格できてなによりです。

これから受験に臨まれる方にも、いい結果がありますように。


それではご機嫌なAWSライフを!

おわりに

APCはAWSセレクトティアサービスパートナー認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: さかぐち
AWSをメインにインフラ系のご支援を担当しています。

自宅受験で AWS Certified Solutions Architect – Professional に合格しました

はじめに

こんにちは、クラウド事業部の葛城です。

自宅でAWS Certified Solutions Architect – Professional を受けて合格することができましたので、自分の学習方法や試験の感想を共有したいと思います。

勉強期間は2ヶ月とちょっとで、他のGCPやAzureは仕事で触っていて、AWS SAAは取得済みでAWSを実際の環境はそこまで触っていない状態から勉強を始めました。

目次

勉強時間と試験結果

  • 勉強期間: 2ヶ月と少し
  • スコア: 860

毎日の勉強時間は、1時間から2時間(調子良くて3時間)
土日は、6~8時間ぐらい勉強しました。

総じて資格勉強が苦手なのと長時間集中できないため、気がそれている時間もかなりあったかと

利用した教材

自宅受験の感想

自宅受験において、一番気をつけたいことが事前の体調管理だと感じました。
Professional試験ということで、試験時間が3時間と長く、テストセンタと異なり自宅受験のため途中でトイレに行くことができず、トイレを我慢して試験を解くことになりました。

試験前に何度かトイレは済ませていたものの、エナドリでカフェインを摂取していたためか、尿意を感じながらでかなりツラい試験になりました。

当初、ピアソンVUEのオンライン試験の試験スケジュールの申し込みから、試験官を日本語対応できる方で申請していた。
事前にシステムのチェックを済ませてすべてクリアしたが、 おそらく中国の方の試験官でお互いのネットワークの相性が悪かったためか、 マウスカーソルが終始ぐるぐるしていて、試験開始したはいいが進まず1問も解けずに試験中止になりました。

その後の対応は、キャンセル扱いですぐに返金対応をしてくださいました。

再スケジュールでは、試験官を英語対応の方に変更し、試験自体の言語は日本語で予約しました。
英語対応のほうが、日本語対応よりも利用可能なスケジュール時間の朝から午後まで幅広く選択できるのと、予約可能枠も多く、今後も英語対応の試験官で予約しようと思いました。

本番では、試験官チャットでのやり取りをチャットで想定していたんですが、 いきなり音声通話で話しかけて来て、自分が英語そこまで得意でないのと、音質も悪いし試験官の喋るスピードと発音も分かりづらく、何を求められているか分からず、焦ってしましました。

実際の試験官とのやり取りは、 両手を見せること、PCを持ち上げて部屋の周りを一周確認する、 机周りを重点的に見せる、Wellcomeページが確認できたかぐらいで、焦りながらもクリアできました。

試験の感想

CloudLicenseの問題よりも、実際の試験のほうが問題も短めで選択肢も優しめな印象を受けた。

前半はいいペースで解けていたが、後半から集中力が切れたこともありかなり解くペースが落ちました。

もともと急がず解いていたのと、答えが分かっても一応隅まで問題を読んでいたこともあり、全問解き終えたときには10数分余すくらいで試験時間ギリギリでした。

オンラインでも、ホワイトボード機能でメモ可能だったり、後で解くなどしおりをつけることもできたが、そんなに利用しなかった。

勉強方法

書籍

試験対策の知識だけでなく、体系的にAWSのベースの知識も身に着けたかったので、資格試験のテキストを1周メモ取るなどしながら読みました。

Web問題

CloudLicenseのWeb問題を旧問題をスキップして17~83までコースがあるので、少なくても一日2コースぐらい解いてみて、調子が良いときはたくさん解いてました。

解いたあとの解説をしっかりと読んで、正解の選択肢と誤った選択肢のそれぞれの理由までも理解することは大事だと思う。

よく知らないサービスや、解説の内容がよく分からないときは、書籍やYouTubeでAWSサービスの解説動画やChatGPTに質問するなどしていた。
Web問題だけだと飽きるので、イラスト付きの動画や実際のデモ動画などを挟むのも自分的に良かった。

全部やるとなると、Web問題もかなりボリュームがあるため、 とりあえず1周終えて、その後は間違えた問題のみ再挑戦してすべてクリアできるまで繰り返し練習しました。

模擬試験

書籍の模擬試験を1回とCloudLicenseの模擬試験を2回実施した。
書籍の問題は実際の問題より、難しめに感じ 6割くらいしか解けなかった。
CloudLicenseは、問題集を1周していることもあり合格ラインより少し上くらいの点数でした。

間違えた問題から、苦手なサービスや問題が見えてくるので、時間があれば模擬試験で実力確認しても良いかもくらいな感じ

試験のアドバイス

CloudLicenseのWeb問題は有料サービスということもあり、かなり合格の役にたった印象。

どのような問題が出てくるかの指針になるので、1周は全部の問題を解いておくと、試験で類似の問題が出たときは、かなりスムーズに答えを選択できるかと。

1周目終えたあとも、間違えた問題中心に解いたり、クリアしたコースを再度やるなど、 直前の数日間に覚えた内容が試験に出たところもそこそこあったので、できれば繰り返しやっておくと良いと感じました

おわりに

APC は AWS セレクトティアサービスパートナー認定を受けております。

その中で私達クラウド事業部は AWS などのクラウド技術を活用した SI/SES のご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: 葛城
AWSを活用したインフラ系のご支援を担当しています。

AWS全冠(≒All Certifications Engineer)になりました。

はじめに

こんにちは、あるいはこんばんは、クラウド事業部の原田です。
今回はAWSほぼ未経験の状態から、無事AWS全冠を達成できましたので、
全冠に至るまでの振り返り、達成して思ったこと、感じたことを共有させていただこうと思います。
※タイトルにAll Certifications Engineersと記載していますが、
記事公開時点では2024 Japan AWS All Certifications Engineers の応募クライテリアを満たしただけで、
来年 2024 All Certifications Engineer に選出される予定です。

自身の経歴(パブクラ歴)

30代からエンジニア。元々はネットワークエンジニア(5年程)、IDaaSのサポート(3年)を経て現在はAzureをメインに扱ってます。

期間 概要
2020/01~2020/09 Azure設計構築(Web3層+FrontDoor+ExpressRoute)
2020/10~2022/03 オンプレ環境構築
※この期間に前案件の経験活かしてAzure資格いくつか
2022/04~現在 Azure案件(設計構築以外の検証多め)
BIとかデータ分析とかMachineLearningとか
2022/09~2022/10 AWS案件お手伝い
SGやGuard Dutyのネットワーク・セキュリティ回り設定チェック

Azureは色々と2年半程触ってますが、AWSは全冠達成した今でも合計100hも触っていません。

勉強時間、取得した順番

全冠達成できましたが、AWSの資格を取りだした当初は全冠について全く考えていませんでした。

最初のSAA取得~全冠達成までに期間は1年9ヵ月(勉強期間は2022/04~2023/12)程かかっていますが、
間にAzure系の認定資格4つ と PaloAltoのPCNSEとってたり単に勉強サボってたりしたので、
AWS認定にかけた期間は実質9ヵ月程になります。
勉強時間は1認定試験あたり平均30h*12回の360h程度でした。

ANS(7月)からは一応全冠意識して集中しはじめ、MLS(10月)あたりで年内の全冠達成を目指してペース上げてます。
会社への申請(1カ月前に申請上げる必要がある)上、後半は2件予約状態になっていたので
落ちれない(落ちるとスケジュール組みなおしメンドイ)プレッシャーがかかったのも良かったかも。

一個合格したらその場のノリで次の挑戦決めていたので計画性もありませんが、
行き当たりばったりでも達成できた一例として。

合格日 資格名 スコア 自記事
2022-05-08 Solutions Architect - Associate(SAA-C02) 760 -
2022-10-08 Solutions Architect - Professional(SAP-C01) 803 -
2023-04-15 Security - Specialty(SCS-C01) 829 SCS
2023-07-29 Advanced Networking - Specialty(ANS-C01) 796 ANS
2023-08-14 SysOps Administrator - Associate(SOA-C02) 816 SOA
2023-09-09 Database - Specialty(DBS-C01) 810 DBS
2023-10-08 Data Analytics - Specialty(DAS-C01) 826 DAS
2023-10-28 Machine Learning - Specialty(MLS-C01) 859 MLS
2023-11-04 Cloud Practitioner(CLF-C02) 883 -
2023-11-19 Developer - Associate(DVA-C02) 791 DVA
2023-12-03 DevOps Engineer - Professional(DOP-C02) 870 DOP
2023-12-09 SAP on AWS - Specialty(PAS-C01) 895 PAS

表だとペースがわかりにくいので線で表すとこんな感じです。
| = 試験、-が1week
----|---------------------|--------------------------|--------------|--|---|----|---|-|--|--|-|
└       ここまで1年     ┘   └  この間半年  ┘

取得の動機・モチベーション

結果的に全冠達成できましたが、AWSの資格を取りだした当初は全冠について全く考えていませんでした。

希望が通ってパブリッククラウド案件を扱っているチームにアサインさせてもらったのですが、
当時パブクラチーム内のAzureチームは自分ひとりで、周囲は皆AWSの案件を遂行されている方ばかり。
各チームの定例報告をする場で飛び交っている用語にさっぱりついていけない危機感から、まずはSAAを取得しようと思い立ちました。

SAAは無事GWを代償に取得できたのですが、勉強の過程で上述のAWSの用語がどんどん理解できるようになり、
別チームの報告を聞いて、「あぁ、こんなことを業務でやられているんだな」というのがイメージできるようになったのが
最初に面白いと思った所ですね。
Configが~とかInspectorが~ とか聞いて、
before:設定がどした?捜査官?誰? だったのが
after:リソースの構成とか変になってないか確認してくれるヤツ。 脆弱性とか検知するヤツ。 ぐらいになって、
そこからなんとなく業務内容をイメージできるようになった感じです。
ホント最初はそんなもんでした。特にAWSのサービス名はE(Elastic)xx多すぎてわかりにくい印象が強すぎて...
Azureの方がサービス名は素直だと思います。(例外はありますが)

その後も各分野の試験をクリアしていく度にAWSの話が分かるようになってきて、
知識の幅が広がるとそれだけ「面白い、面白そう」と思える話も多くなるのが実感でき、
それがモチベーションの維持にも繋がっていきました。

また、環境面として試験合格時は会社が受験料を負担してくれるのも大きかったです。感謝。
ProfessionalやSpecialtyは一回¥33,000かかりますし。全試験で半額特典利用しても約¥180,000…
途中まではさらに追加でSpecialty(かProfessional)に報奨金もかかっていたので、それも一因としてありました。
報奨金売り切れてからペースあがってるあたりやっぱり計画性ないなぁ...

でも一番のモチベーション維持に繋がったのは同じ目標に向かう仲間が同時に挑戦してくれていたからですね。
特に同じPJ、同じチームのはイベントにも参加(登壇込み)されながらも
自分より一歩先に行っていたので、離されないよう背中を追いかける日々でした。
特にPASを2日で取得されてた際は「え?」ってなりました

勉強方法

※ある程度のパブクラ知識(CLFぐらい)はある前提です。 AWS認定試験に集中していた間は、以下の勉強方法を行っていました。 ①AWS Skill Builderで各試験の概要を押さえる
 主にExam Readiness。個人的には動画系(日本語実写版)が好みでしたが、ものによっては使い難いのも...(動画スピード弄れなかったり)
➁問題集を1周する
 今回はCloudLicenseを利用していました。7問1セットなので途中で止めやすく、
 集中力続かない日は途中で一旦辞めて小分けにしたりと融通が利きやすい点が使いやすかったです。
 あと3ヵ月毎更新なので締め切り効果も狙えます。
③足りない知識を補完する
 主に利用したのは↑の問題集の解説や、Black belt/Whitepaperになります。
 ぶっちゃけ量多すぎて見きれないので、簡単な用語解説等は他の合格者さんのブログ漁ったりもしていました。
 弊社ブログ内にも合格体験記いくつかあるのでおススメです!
④ ➁~③を2~3周繰り返す。
 とりあえず8割ぐらいを目標に。
 注意点として、ちゃんと仕組みを理解すること。
 ただ問題の答えを覚えるのではなく、何故その解答になるのか自分で説明できるようになるのを目指します。
 今回使っていたCloudLicenseの場合、単発で8割超えたら模擬試験モード→間違ったところだけお気に入りに登録して復習
⑤試験前日:SkillBuilderのPracticeTest受ける
 最終確認。ここでミスった部分でどこを理解していないか再確認、復習。

全冠達成してみて

正直DAS、MLS、PASについてはその分野の知識を修めても活用できるかは正直携わる業務に依る部分が大きいと思います。
※PASはSAP(製品の方)に限らず、アプリーションの移行や設計にも活かせそうですが

私は実業務でETLやMachineLearningに触る機会が(Azureでだけど)あったので知見増やす為に勉強しましたが、
時期がズレていたらDBSまで取得した時点でそれ以降取っていなかったかもしれません。

ただ、逆に言えばその他の試験は業務でAWSを利用するなら活かせる部分があると思います。
CFnとか業務で使ってないからDVAやDOPいらない?もったいないから先に勉強して導入できるように動きましょう!

私の場合業務ではAzureをメインに扱っているのですが、どちらも修めることでそれぞれのプラットフォームの知識だけでなく、
パブリッククラウドのサービスに対しての理解度がより明確になったと思います。(上述のML等)
AWSを扱っていない方や、メインが違うプラットフォームの方にも、パブリッククラウドという業界のアンテナ広げる為にAWSの知識はあって損はないと実感できました。
ユーザーが一番多いAWSの記事が情報としては一番多いので、そこから情報を得れるのは大きいです。

1つの認定試験だけでも労力使いますが、その分全冠はただの知識・技能Lvの証明だけでなく、
継続的に勉強を続けられることや、その向上心についてもアピールできる実績になると思います。

振り返ってみれば、知識の習得はもちろん、視野の広がりや勉強の習慣化等、
「やって良かった」と思える体験でした。

来年は追加されるDEA取って2025もAWS全冠と言えるようにしつつ、Azureも全冠目指します!

おわりに

この記事が皆さんのスキル向上のきっかけの一つとなれば嬉しいです。
私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: e_harada
普段はAzureをメインにインフラ系のご支援やPythonでコード書いたりを担当しています。AWS全冠。Azure10冠。
Credly

AWS Certified: SAP on AWS - Specialty (PAS-C01)合格記

こんにちは、クラウド事業部の松尾です。 2023年12月16日にPAS-C01を受験、無事合格出来たので学習方法など共有したいと思います。 関連知識ゼロから合格までの内容が皆さんの学習の参考になれば幸いです。

受験前の知識レベル

  • さっぷ?
  • AWSは業務経験あり。

学習期間

  • 約2週間
  • 平日1~2時間

学習内容

1~4を一通り実施後に5,6の問題が90%程度正答出来るまで繰り返しました。解説にも目を通します。

学習順 教材 コメント
1 試験ガイド 対象範囲を理解すること。範囲外のサービス名も記載されているので認識しておく。
2 試験問題サンプル(10問) 試験の雰囲気と難易度の感触をつかむ。問題数10。
3 YouTube 試験の観点でSAPを説明されている動画。ドキュメントを見ていくよりは分かりやすい。
4 Skill Builder問題 全問題を正答率90%になるまで解く。(問題数315問)
5 CloudLicense 全問題を正答率90%になるまで解く。
6 Whizlabs CloudLicenseが91問と少なかったので練習問題を増やす目的で実施。時間が無ければやらなくても良いかも。

試験当日

70分程度で問題を解き終わり、見直しも10分程度で終了。 今回はなぜか(?)回答終了ボタンと同時に合否が表示されました。

振り返ってみて

試験問題の日本語訳がいまいちで、英語に切り替えての読解が数回。

SAP on AWS試験は他のAWS専門レベルの試験と比較すると簡単な方。

試験学習を通してSAPの概要は理解出来た。

SAP用語の理解が最初のハードル。 用語を把握出来れば、あとはSAA、SAPの知識があれば回答出来る。

AWS Certified: SAP on AWS - Specialtyの試験コードは、PAS-C01。

AWS Certified Solutions Architect - Professionalの試験コードは、SAP-C01。 ややこしい。

SAP向けEC2インスタンスのメモリは最大24TiB。ストレージではないですよ。メモリです。1時間当たり約$70。。さくっと検証はしにくいですね

SAP HANA on AWS内の参考見積より抜粋。

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

AWS活用支援サービス

また、一緒に働いていただける仲間も募集中です! 今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

採用情報

【合格体験記】AWS Certified SysOps Administrator - Associate (SOA-C02) に合格しました。

はじめに

こんにちは!クラウド事業部の早房です。
先日 AWS Certified SysOps Administrator - Associate (SOA-C02) を受験し、無事に合格いたしました。
今回は試験を受けてみての感想、および学習方法等について記事を書きます。

AWS Certified SysOps Administrator - Associate (SOA-C02) について

AWS Certified SysOps Administrator - Associate は、AWS上でのワークロードのデプロイ、管理、運用に関する経験を証明できる資格です。
なお、本来はラボ試験が含まれる試験ですが、現在は他の試験と同様に選択問題のみとなっています。

aws.amazon.com

出題範囲と割合は以下のようにリソースの監視からネットワークやセキュリティ、コストのチューニングまでかなり幅広くなっています。

分野 1: 監視、ロギング、および解決 20%
分野 2: 信頼性および事業継続性 16%
分野 3: 展開、プロビジョニング、および自動化 18%
分野 4: セキュリティおよびコンプライアンス 16%
分野 5: ネットワーキングおよびコンテンツ配信 18%
分野 6: コストおよびパフォーマンスの最適化 12%
https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sysops-associate/AWS-Certified-SysOps-Administrator-Associate_Exam-Guide.pdf

勉強方法

学習時間

30時間程度
毎日2時間程度の学習を2週間つづけました。

使用した教材

勉強方法

  1. Cloud Lisence の問題を 1 周解く
  2. 1.で間違えた問題を 1 周解く
  3. ここまでで理解できていない部分は公式ドキュメントやブログ記事を参考に調査
  4. Cloud Lisence の模擬試験、公式のサンプル問題の練習問題集を解く

あまり腹落ちしない部分は Black Belt なども参考にしてみました。

結果

合格 (813点)

感想

試験範囲が多岐に渡っているので、想像以上に難しかったです。
同じくアソシエイトレベルの SAA より少し難易度が高めの印象。
なんとな~くで理解してそのまま放置している部分があると足元をすくわれる感じでした。 今回合格できたのは良かったものの、セキュリティ分野の正答率が悪かったのが反省点です。。。

おわりに

今年 7 月からAWS認定資格の取得を始めて、現在4つ取得することができました。(SAA,SAP,SCS,SOA)
まだまだ道のりは長いですが、全冠達成できるようこのままの勢いで学習していきたいです。

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: hybs_yuuuu
AWSをメインにインフラ系のご支援を担当しています。 https://www.credly.com/users/hybs_yuuuu/badges

問題集ベースで勉強して AWS Certified Solutions Architect / DevOps Engineer - Professional に合格しました

はじめに

こんにちは。クラウド事業部の野本です。

AWS の中身をほとんど知らない状態から3ヶ月頑張り、どうにかプロフェッショナル資格2種類 (SAP-C02, DOP-C02) に合格できました。

今回はほぼ Web 問題集だけで勉強するという方法をとりましたので、その過程と結果を書き残します。何かしら参考になれば。

要点(感想)

  • 試験時間3時間でも厳しいほど問題が多くて長いので、速く解けるようになる練習は重要でした。
  • 選択肢内の間違いを指摘できるようになるまで学習すると、速さや正確性の向上に役立ちました。
  • 問題文を下手に記憶して慣れてしまうと、初見の問題への対応力が落ちて試験で苦労しました。問題集を何周もするより、1周目に本気で解くほうが大事に感じました。
  • 問題集の解説をメモに蓄積・整理していくことで、体系的な参考書なしでもある程度はサービス内容を掴めました。学習効率はともかく、ジグソーパズルのようで楽しかったです。

勉強期間と試験結果

各資格の勉強期間および試験成績は以下のとおりです。

資格 勉強期間 スコア
Solutions Architect - Professional
(SAP-C02)
8週間 881
DevOps Engineer - Professional
(DOP-C02)
3週間 905

日々の勉強時間は平均して2〜3時間でした。 DOP は無理矢理3週間に収めただけで、本当はもう1週間ほしかったです。

勉強前のスキル

  • 業務はサーバーサイドアプリケーションの開発が中心です(プログラミング大好き)。関連して CI/CD やコンテナ技術なども扱っています。
  • AWS は頻出サービスの名前なら知っている程度です。コンソールにサインインしても次に何をすればいいかわからない有様です。
  • 他のクラウドサービスの利用経験はそこそこあります。 Google Cloud Platform では過去に Professional Cloud Architect (PCA) の資格を取得しました。

→ PCA に合格していたことから、 Associate を飛ばして SAP を直接狙うことにしました。

勉強過程の詳細

参考書を使わず、問題集で大量の問題に触れて馴染んでいくという縛りプレイ勉強方式で進めました。

問題集は Web の Cloud License を初めて利用しました。 SAP / DOP ともに600問近くあり(※ DOP は半分ほど旧問題)、7問1組のため学習ペースを作りやすく感じました。また有料プランが90日間というのも、一定期間に集中して頑張ることに繋がりました。

SAP

EBS と言われても何のことかわからない」といった状態からのスタートです。

  • 問題集 1周目(2週間)
    • とにかく語句に慣れることを目指しました。サービス名や機能名などを文章から収集して雰囲気を感じ取り、また横文字が苦手なので英単語で意味のわからないものを辞書で調べました。
    • 問題文を理解できないなりに、考えて解くことはしました。可用性くらいなら他クラウドの知識も役立ちますし、オンプレからの移行や災害復旧(DR)戦略など典型的な出題パターンがあるものは自然と覚えられました。
  • 問題集 2周目(6週間)
    • 語句には慣れたので、サービスについての学習を本格的に始めました。
    • 解説をもとに、サービスの性質についてメモを積み重ねて理解していきました。
      出題分野はシャッフルされているため最初は情報が断片的なものの、メモ量が増えるに連れて内容が繋がっていきました。
    • また、解説には選択肢の間違いの理由もいくつか書いてあるため、 AWS でできないこと・非効率なことも情報収集しました。
  • 模擬試験
    • 2時間程度で解けて、正答率は約9割でした。
    • 短期間に解きすぎたためか、「ある〇〇会社」のような特徴的な文章から正答を思い出せてしまう問題点が浮き上がりました。

文章から正答を思い出せてしまうと、もう問題を解き直しても大して考えなくなり、あまり勉強にならなくなってしまいました。メモを纏めてあったのが救いで、試験まではそれを見返して記憶の整理をしました。

試験本番では初見の問題への対応に苦労して試験時間ギリギリまでかかり、合否の確率が五分五分に感じるくらいの出来でした。試験結果のスコアはなぜか高かったですが、実感が全然ありません。

DOP

何にせよ目標だった SAP は合格し、問題集の有料プランの期間が1ヶ月余ったため、現業に近いことなどを考えて DOP にも挑戦することにしました。

  • 模擬試験
    • 今回は語句の心配は無いため、最初に現在の実力を確認しました。
    • 結果は6割とまあまあ良く、頑張れば合格できそうな感触でした。
  • 問題集(3週間)
    • SAP のときと同様に、解説をもとにメモを積み重ねて理解していきました。
      • 分野は狭いものの深く問われるため、設定による動作の違いなどは追加で公式ドキュメントやブログ記事を調べました。
      • 旧問題の範囲については、古い情報とわかったものはその旨もメモしました。
    • 本番で初見の問題に対応できるよう、1周目なうちに速さも意識して解く練習をしました。
      • 素早く読んで2分以内に回答を決める → 文章を隅々まで読んで熟考する → 解答・解説を確認する、ということを繰り返しました。
      • 選択肢を除外できるポイントがわかってきてからはだいぶ楽になりました。
    • 「 SAP よりは簡単」との噂を聞いていたのですが、私にとっては新しく覚えることが多く、同じくらい辛かったです。
  • 模擬試験 2回目
    • 2時間程度で解けて、正答率は約9割でした。
    • 問題文を過剰に覚えてしまっている感じはありませんでした。(印象的な問題自体が SAP より少ないのかもしれません)

試験本番では、 SAP の教訓で対策したことが活きて時間に余裕を持って回答でき、合格ラインを確実に越えているという手応えがありました。

まとめ

AWS をほとんど知らない状態から始めて、問題集を活用してどうにか SAP / DOP 合格までこぎつけました。問題を解けるように練習したというのはもちろんですが、問題に触れて慣れていくという勉強方法が性に合っていてやる気を維持できたという面もあったと思います。

問題集ベースで覚えたことはあくまで試験に対応するための知識なので、まだ業務では「他チームの人が AWS について話していることが頭に入るようになった」程度です(その進歩はとても嬉しいですが)。今後は実際にサービスを触り、知識の穴を埋め、業務で AWS を活用できるよう引き続き頑張ります。

AWS Certified: SAP on AWS - Specialty(PAS-C01)に合格できました。

はじめに

こんにちは、あるいはこんばんは、クラウド事業部の原田です。
今回はAWS Certified: SAP on AWS - Specialtyに合格しましたので所感等を共有させていただこうと思います。

点数

895/1000

勉強時間

約7.5時間
日曜日(DOP試験後)に2h+平日1h*5、土曜日AMの試験前に30分

試験の感想

Specialty試験の割には問題文、選択肢ともに文章量は控えめ。
ただ、さかぐちさんの記事でも言及ありましたが、日本語がちょっと怪しいと思う部分が見受けられました。
いつも通りの65問制限時間170分ですが、先述の通り文章量が控えめなこともあり試験自体は30分程度で1周。
軽く見直ししましたが合格ラインは越えてそうだったのでさっくり終了。
MLSも文章量控えめでしたが、あちらと比べて選択肢悩む問題がより少ない印象で、
他Specialty試験よりも時間的な余裕はさらにあると思います。

教材

1. AWS SkillBuilder
SAP on AWS (Technical) (Japanese) (Sub) 日本語字幕版
いつもはExam Readiness視聴しますが今回はこちら。
テキストベースで関連サービスについて解説&確認テストになっています。
前半はSAP以外(リージョンとは?AZとは?から)なのでスルーして、
末尾の確認テストで不明点がどこか抽出し、該当箇所の説明読みなおしました。

AWS Certified: SAP on AWS - Specialty Official Practice Question Set (PAS-C01 - Japanese)
いつもの。初見で6割ぐらい。

2. Tech Stock -Web問題集 -PAS
有名どころWeb問題集。
1セクション7問という量が隙間時間にちょっとやるのに良かったので引き続き利用。
SAPは試験日時点で#13まで(=91問)とボリュームが少な目。
量がすくないので4週程周回し、テストセンター向かう電車の中(25分程)だけで1周終わるぐらいに。

**3. SAP取得者のブログ SAP関連の用語については公式ドキュメントも良いのですが、
先達の方がまとめられてくれているのがすごい参考になります。
特に↓の2つの勉強ノート/SAP関連用語 はどんなものか理解する上で相当時短になりました。
https://qiita.com/aminosan000/items/5d0abe5815a927406c62#%E5%8B%89%E5%BC%B7%E3%83%8E%E3%83%BC%E3%83%88
https://tech.nri-net.com/entry/aws_certified_sap_on_aws_specialty

社内の先達記事参考にさせていただきました。

まとめ

SAPについての知識、用語を抑える必要はもちろんありますが、
逆にそれ以外の部分はSolution Architect Associate取得で通じるぐらいの難易度だと思います。
また、これは受け売りですが、SAP以外のアプリケーションの設計・移行等にも流用・参考にできる部分があると思います。

とはいえ個人的な感想で言えば業務でSAP使わない限り優先度は低く、 全冠って言いたいから取ってみた。になる方が多そう。
Solution Architect Professionalや他Specialty(一番関連しそうなのはANS)取得している場合、Specialtyの中では難易度低い印象でした。

おまけ

無事AWS全冠(2023/12時点で12冠)取得できました!
来年にはDEAがリリースされるのでそちらも引き続き取得狙おうと思います。
その前に溜まってるAzureの資格更新が...
全冠についてはまた別記事として書こうと思います。

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: e_harada
普段はAzureをメインにインフラ系のご支援やPythonでコード書いたりを担当しています。AWS全冠。Azure10冠。
Credly

【AWS re:Invent 2023】海外に行くのも初めての人間がAWS re:Invent 2023に参加して驚いたこと

こんにちは、クラウド事業部の山路です。

今年初めてAWS re:Inventに参加させていただいたので、その感想を共有させていただきます。タイトルの通り海外に行くのも初めてだったのですが、似たような立場の方が来年以降参加する時の参考になれば幸いです。

よかったこと

まず大事なことですが、AWS re:Inventというイベントはとても楽しく、参加して本当に良かったと思います。

色々理由はありますが、個人的な感想をいくつか書きます。

イベントの規模感に圧倒される

AWS re:Inventは複数のホテルや施設にまたがって開催され、一つ一つの広さも桁違いです。それだけの空間に世界中からAWS好きな方々が集まります (去年は5万人ほど、今年はもっと多くの人数が集まってるっぽい?) 。その様子をみると、「AWSが世界中で使われている」という当たり前のことに気づかされます。

またKeynoteの演出やEXPO会場に集まる企業の数、会場の飾りつけなどを見ていると、なんだか現実離れした感覚に襲われます。たぶん仕事で行ったとしても、初参加時は仕事を忘れて夢中になってしまうんじゃないでしょうか。

生の臨場感

今回はKeynote中心に参加したのですが、目の前でAWSの中の人がプレゼンしたり、協力する企業からゲストを読んで話したり、それに応答する会場の熱気だったり。オンラインでは決してわからなかったであろう雰囲気を味わえます。

また、目の前で新サービスが発表される様子は、特に興奮しました。

※Keynoteの様子はこちらでも書いてます。

techblog.ap-com.co.jp

techblog.ap-com.co.jp

techblog.ap-com.co.jp

AWSが好きになる

AWS re:Inventに出てみて一番感じたのは、このイベントは単なるITイベントというより、むしろ音楽フェスとかに近いものじゃないか、ということでした。

Keynoteでのプレゼンの内容だったり、イベントそのものへの力の入れ方を見ると、re:Inventに参加したひとにAWSのことをもっと好きになってもらう、もっと使ってもらうことを狙っているように感じました。あとはre:Playもありますし。

なお、re:Inventのイベントの様子などは本ブログでもいくつか公開していますので、良ければそちらもご覧ください。

techblog.ap-com.co.jp

驚いたこと、苦労したこと

ここからは、初参加してみて驚いたこと、特に次回以降に生かすための反省点を紹介させていただきます。いま振り返るとそんなの当たり前だろ!ということもたくさんあるのですが、やはり実際に体験しなければなかなか学ぶこともできないということで、ご容赦いただければと思います。

時差ボケはきつい

初海外ということで時差ボケも初体験だったのですが、想像以上に過酷でした。今回は羽田からロサンゼルスを経由してラスベガスに向かったのですが、ロサンゼルスまでの飛行機の時点でほとんど寝れず、ラスベガス到着した直後から睡眠不足に苦しめられました。

またその後も体が時差になじまず、ベッドに横になっても2~3時間の浅い睡眠を繰り返すばかりで、熟睡できた感触がありませんでした。

なお、Keynoteは早いと午前8時から始まります。大体1時間前には並び始めないといい席で見れないですし、朝ごはんも食べないと、となると、起きる時間は5時とか5時半になります。あとはイベントへの高揚感などもあり、普段よりも睡眠時間を取りにくい環境ではあると思います。

食べ物は癖が強い

ラスベガスではファーストフードやメキシカン料理を多くいただきました。日本だと野菜や米などを食べることが多かったので、食べ物の普段とのギャップに苦労しました。

またラスベガスは基本的に量が多めです。ハンバーガーなどは特に記載がなくとも大量のフライドポテトがついてきたり、メキシカン料理も一緒にトルティーヤチップスがついてきます。日本で暮らしていると、出された食べ物を残すのが申し訳なくなり、少し無理してでも全部いただこうとするのですが、ラスベガスでそれをやると本当に苦しかったです。

なお、アメリカの食べ物が合わなくてつらい、と感じている方は、re:Inventの会場の一つであるWynnホテルのご飯がおすすめです。今回ランチで2回ほどご飯を頂いたいのですが、どれも優しいお味でおいしいです。3日目くらいでめげそうになっていたところを助けていただきました。

ラスベガスは乾燥が激しい

ラスベガスは砂漠の中にある都市です。そのため乾燥が激しく、日中と夜間の寒暖差も激しいです。日本の冬も乾燥がきつかったりしますが、それとはまた違う厳しさがあります。

乾燥がきついのでこまめに水をとりたいのですが、ラスベガスの水は日本のものと少し違って飲みにくさを感じるところもあり、水分を取りにくい状況でした。また物価が高いので水の値段も高く (ホテルだと1リットルで7ドルちょっと) 、まずます水分が遠ざかってしまいました。

体調を崩しました

さて、上記3点を食らった私は、ラスベガスで見事に体調を崩し、最終的に風邪をひいてしまいました。日本からいくらか持ってきた薬を飲みながら参加していましたが、イベントとラスベガスを楽しむためにも、やはり体調は万全でありたいところでした。。

準備不足でした

今回の反省点を一言でいうと「準備不足」だったと思います。

荷物を例にしても、私は日本から持っていく荷物もかなり少なく、機内持ち込み以外は着替えくらいしか持って行ってませんでした。

余談ですが、今回50Lのスーツケースに半分くらいの荷物とリュック1つで臨んだのですが、空港で預けたスーツケースを見た空港職員の方から「アメリカに行くにしてはずいぶんと荷物が少ないですね」と言われました。たしかにアメリカ現地の人並みに荷物が少なかったです。

その他

その他、驚いたことをいくつか書いておきます。

  • 入国審査: アメリカへの入国審査で指紋をスキャンされるのを知らず、いきなり「4 finger ナントカカントカ」と言われて慌てました。
  • 音量: 街全体の音量が大きいです。話し声や音楽、車の音までなんだか大きく感じます。
  • チップ: チップという概念が出てきます。私は最後までいついくらぐらい渡せばよいかわかりませんでした。
  • フレンドリー: 街中で急に声を掛けられます。キャッチもありますが、エレベーターの中とかでも「Hi.」とか話しかけられてびっくりします。
  • シャワー: 水圧が弱いです。ちょろちょろとしか水が出てきません。
  • お手洗い: ウォシュレットはありません。がんばりましょう。

その他にも期間中は初めての出来事だらけでした。よく言えば刺激的な毎日ですが、慣れない環境でなかなか落ち着く時間もとれず、疲れやすい環境ではあるかと思います。それもあってか、帰国してから体調を崩された方も何名かいらっしゃるようでした。

次回に向けての改善点

ここからは今年の反省を踏まえ、どうすればよかったかの考えを書いていきます。

快適に寝るための準備をする

まずは時差ボケ対策ですが、とにかく快適に寝れるよう準備をしたほうが良かったです。アイマスクやネックピロー、場合によっては睡眠改善薬などを持っていくのが良いと思います。

また、ラスベガスは夜寒いので、寝るときも多少厚めの服を着たほうがよかったです。re:Inventではパーカーなども配られるのでそれを着るのもアリだと思います。

私はこのパーカーのおかげで少し快適に寝れました。ありがたい。

のどを守ろう

ラスベガスの乾燥から身を守るために、ぬれマスクはあったほうがよいです。寝るときにつけておくとよいです。またのど飴を持って行ったのですが、これにはかなり助けられました。

また肌や手も乾燥するので、必要ならスキンケア製品もあったほうが良いと思います。

薬は多めに持っていく

私は今回のre:Inventで、風邪薬と胃薬、酔い止めを1箱ずつ持っていきました。ただ、約6日間という滞在期間を考えると、もう1箱ずつ持って行ったほうが安心できるかもしれません。

体力をつけておく

ラスベガスという慣れない環境、イベント中はラスベガス中を歩き回ることを考えると、イベントに向けて体力をつけておくのが良かったかもしれません。

参加される方の中にはre:Inventのことをブログとしてアウトプットするのが参加条件になっている方もいらっしゃるかと思いますが、イベント期間中にブログを書くのはかなり大変でした。私も当初は10本くらい書けるんじゃないか、と思っていたのですが、いざやってみると3本が限界でした。。。

さいごに

ということでAWS re:Inventの感想でした。色々大変でしたがとにかくイベントは最高なので、行くチャンスがある方はぜひ参加したほうが良いと思います。

【AWS re:Invent 2023】AWS infrastructure as code: A year in review セッションレポート

こんにちは、クラウド事業部の山路です。

AWS re:Invent 2023に参加し、いくつかのセッションを見て回ったのですが、特に行ってみたかったセッションについて紹介します。

このセッションは同じタイトルのものを去年も実施していたのですが、個人的にIaCに関心が強いこともあり、興味深く視聴していました。今年も同じタイトルで発表があることを知り、せっかく現地に行けるのだから聞いてみたい!ということで参加してまいりました。

ただし、私の英語力が足りず当日の発表内容を十分理解できたわけではないため、今回はYoutubeの動画内容+現地の雰囲気をちょっとだけお伝えする形とします。

動画はこちら。

www.youtube.com

講演開始

当日はいちおうReservationで行ったのですが、人数的には多少余裕がある感じでした。とはいっても8割くらい?は席は埋まっていた印象です。

発表者はTatiana Cookeさん / James Hoodさん。

冒頭に参加者向けにアンケートなどもしていましたが、さすがに日頃IaCを扱う人が多く参加していたのか、会場の半分くらいは挙手していた印象でした。

さて、今回の発表は大きく3つのテーマからなります。

  • AWSのIaCを振り返る: CloudFormationやCloud Control APIの話
  • IaCを組織内にスケールするためにどうするか
  • AWSにおけるIaCの今後について

1. AWSのIaCを振り返る

まずは1つ目のテーマ。ただしこちらは昨年とほぼ同じような内容に見えたので、一部割愛します。

まずは全体像から。ご存じの通りAWSにはAWS CloudFormationというIaCサービスがあり、それを支えるレイヤーとしてCloudFOrmation resource registryがあります。CloudFormationを抽象化したレイヤーとしてAWS CDK / SAM / Copilot / Application Composerが、さらにその上位にAWS Service Catalog / AWS Amplifyなどが位置します (去年はここにAWS Protonも書いてありました)。

CloudFormationと同じ位置にAWS Cloud Control APIがありますが、これは2年前に公開された、全てのリソースで共通のAPIから操作することを実現する新しいAPIです。Terraform / Pulumiなどのサードパーティ製品もこの恩恵を受けます。

ここで登場したCloudFormation Resource Registryとはリソースを提供するレイヤー (Resource Provider Layer) とも言い換えられますが、このレイヤーはCloudFormationの定義ファイルに書かれた情報をAPIコールの形に変換します。

CloudFormationが出た当初、Resource Registryは存在しませんでした。しかし、サードパーティへの利用、AWSリソースに対するCloudFormationのカバー率の向上、リソース共通で利用することでのAWS内部でのリリース効率向上?などにより、Resource Registryを利用するほうへ移行が始まりました。

2023年末までには、全てのリソースがResource Registryを使用するモデルに変更が完了する予定。

ただし移行はそこまで簡単な話ではありません。後方互換性も気にしながら複数の自動テストを用意したり、部分的な障害を想定したカオスエンジニアリング的なテストを実施したり。

話は変わってCloud Control API。すべてのユーザーがCloudFormationを使ってるわけではないと理解しており、IaCの共通の問題を解決するためにCloud Control APIをローンチした。

例えばTerraformはCloud Control Providerを所有しており、2024年にはこれを公開する予定。

www.hashicorp.com

ここから、IaCを利用するうえでどんな道をたどるかの紹介。

IaCを実践する際はいくつかのステップを踏むことになります。コードを書く、テストする、デプロイする、などなど。

IaCにまつわる多くのアップデートがありましたが、ここからは特に注目の機能を各ステップごとに紹介。

まずはIaCを始める段階。

1つ目はApplication Composerのビジュアルエディターの紹介。当初はサーバーレスのみが対象でしたが、その後のユーザーからの声を受け、全てのCloudFormationリソースのサポートを開始しました。これにより新しいアーキテクチャを考えたり、既存のAWSサービスの構成を把握することが、プロジェクトの新規参入者でもやりやすくなります。

aws.amazon.com

次は実際にIaCコードを書く段階。

ここではAmazon CodeWhispererが役に立ちます。つい先日IaCにも対応したため、コードの補完や生成機能を使いながらIaCコードを書くことができます。

aws.amazon.com

次はテストの段階。

ここではAWS Integrated Application Test Kit (IATK) の紹介をしています。AWS Lambdaなどはこのテストライブラリを使うことで自動テストが書きやすくなるとのこと。

aws.amazon.com

※IaCのテストについては、以前私の書いたこちらの記事などもご覧ください。

techstep.hatenablog.com

続いてはデプロイの話。

1つ目は、ChangeSet作成時に既存のカスタムリソースをStackにImportしてくれる機能。

aws.amazon.com

2つ目は、特に大規模Stack向けに、エラー発生時の根本原因を表示してくれる機能の紹介。

docs.aws.amazon.com

次はスケールアップの話。

CloudFormationではStackSetを使うことでリージョンやアカウントに共通のStackを展開することができます。こちらもConcurrencyModeの発表、Suspendedなアカウントをスキップするなどの機能が公開されています。

aws.amazon.com

aws.amazon.com

2. IaCを組織内にスケールするためにどうするか

IaCを採用する組織とIaCの利用方法のパターンは様々あります。最近だとPlatform Engineeringが普及し始めていますが、それも1つのパターンに含まれます。

今はIaCを組織にスケールするのを始めやすい時期だと考えている。Iacを始めやすく、より高速にビルドし、より安全にデプロイする方法がそろっているからです。

これまで開発者がIaCを開発する際、AWSマネジメントコンソールの画面とIaCファイルを行き来しながら行うことが多かった。

既存のリソースのCloudFormationテンプレートを生成する機能が近い将来利用可能になります。これによりCloudFormationで管理されていないリソースが分かるようになり、管理されていないものを選択するとCloudFormationテンプレートが生成されます。

CDKでも同様の機能はサポートされ、既存のリソースをCDKに移行するのがはるかにやりやすくなるとのこと。VSCodeで生成したL1 CDKコードを見ることも可能。

続いては、IaCをチーム内に普及するうえで直面する課題の紹介。

1つ目は、リソースのプロビジョニング時間が異なる可能性があること。例えばコンソールからIAMロールを作成したときは即座に完了するのに、IaCから作成するともっと長い時間がかかるように見えることがあります。

AWSリソースを作成するとき、実際には大きく2つのステップに分けて実行されます。基本的にはConfiguration Completeが完了した時点で、例えばリソースの状態をAPIから取得すると、変更内容が反映された結果を返します。しかし実際は内部的な処理がその後走り、Ready for useの状態になるまで少し時間がかかります。

多くのIaCツールはConfiguration Completeの状態になると作成完了の返り値を返しますが、CloudFormationの場合はReady for useになってから完了とする、保守的なアプローチをとっています。どちらのアプローチがよいかは一長一短です。

2つ目は、コンソールから操作することが多いチームの習慣を変える必要があること。IaCで管理するようにしたのちもコンソールから設定変更を行えばドリフトが発生するため、新しい習慣を身に付ける必要があります。

ただし、これまでと大きく異なる手段をとらなければならない場合、新しい習慣に慣れるまで時間もかかります。例えばCloudFormation Stackを管理するためにS3バケットにテンプレートをアップロードしてから操作する必要がありますが、こういった操作がチームになじみにくい一面もあるでしょう。

そこでGitHub / GitLabを中心としたGit ワークフローをベースに、GitOpsのアプローチをとれるようアップデートしました。

aws.amazon.com

3つ目は、適切なツールを使ってより高速にビルドすること。そのためには抽象化により高レベルでリソースを管理することが助けになります。

SAMのアップデートやCDKの紹介など。

CDKによる事例の紹介。PGAツアーで使われるアプリケーションはCDKをベースにしたマイクロサービスアーキテクチャを採用しており、ツアーが進行中も並行してトーナメント用のサイトを用意したり、古いスタックの削除やアップデート頻度の大幅な向上を達成しています。

IaCの開発者はよりプロアクティブに動くことで、開発・テストのループを短くしたり、より早い段階でバグを検出したり、多くのメリットがあります。

ここでCloudFormation Hookの機能の紹介。何かしら問題があればそれを検知し処理を停止します。このあとGoDaddyでの具体例も紹介されていました。

今年期待しているHookの機能の紹介。ターゲットタイプによるフィルタリングなど。

3. AWSにおけるIaCの今後について

これまでIaCと聞くと、Yaml / Jsonなどのファイルを作成することを考えてきましたが、SAM/CDKなど抽象化する手段が出たり、Application Composerによる作成もできるようになりました。そして2023年には生成AIによるIaCの構築も登場。

今後は、これら複数のインターフェイスをシームレスに行き来できるようになるでしょう。

今後は生成AIを利用しつつ、複数のインターフェイスからIaCを扱うことになるでしょう。例えばApplication Composerで視覚的に見た後、実際のコードを確認し、さらにCodeWhispererで自然言語による入力も可能です。

ここまでの発表で、シームレスに扱うための多くの機能を紹介できたと考えています。

未来を考えるうえでヒントとなる例の紹介。2012年のジェフ・ベゾスの言葉より、「10年後に変わるものが何かよく聞かれるが、10年後に『変わらないもの』はなにか、聞かれることはほとんどない」とのこと。

ではIaCにおいて変わらないものは何か。AWSでは引き続き、IaCによるリソースのカバー範囲と品質を追求します (Consistency) 。またIaCは組織などでクラウドリソースの利用を拡張する手段であると考えており、大規模に実行できるサービスの向上も重要です (Scalability) 。さらにIaCコードの作成方法が多岐にわたるにつれ、それらを安全にデプロイする仕組みも重要になるでしょう (Safety) 。ロールバックやHookなどは注力分野となります。

最後はユーザーの声を待っていますというアナウンスで終了。

さいごに

AWSのIaCの基本から今年のアップデート情報、今後どう変わっていくかの話などなど、内容盛りだくさんのセッションでした。個人的にはCloudFormationがほかのIaCツールと比べてより保守的な作るにしている、という部分がとても興味深く、今後IaCツールを選定する時にも役立ちそうな情報だなと感じました。

また、CloudFormationの内部の話や事例紹介などが興味深いのはもちろんですが、なによりIaC好きな方は興味深く聞けるセッションなのではないかと思います。IaC好きな方はぜひ一度聞いてみてください。

明日以降もAWS re:Invent2023の内容を共有していこうと思います。

【AWS re:Invent 2023】KEY005 | Dr. Werner Vogels NOT現地レポート

こんにちは、クラウド事業部の山路です。

これまでAWS re:Invent 2023のKeynoteについて現地から紹介していましたが、3日目午後以降のKeynoteを現地で見ることができませんでした。

ですがせっかくなので、Youtube動画を見ての感想ですが、残りのKeynoteについても紹介します。

今回はAWS re:Invent 2023のKeynote (Day4) を共有します。

なお、本記事中に出てくる画像は、すべてYoutube動画から引用したものです。

動画はこちらから。

www.youtube.com

講演開始

発表者はDr. Werner Vogels。

冒頭のムービーにも出てきた "Frugal Architect" (倹約的アーキテクト) が最初のキーワード。コストやサステナビリティを意識してアーキテクチャを構築する。

thefrugalarchitect.com

AWSなどのクラウドを活用することで、オンプレミスに存在した物理的な制約は取り払われました。

一方で考えなければならないことも出てきます。クラウドの利用コストはその一つです。

PBS (アメリカの公共放送サービス) ではオンプレからクラウドに切り替えたのち、CloudFront / S3 / ECSなどのサービスを駆使し、結果的にストリーミングのコストを80%削減することに成功しました。

クラウドの利用コストは、そのままクラウドの計算資源の利用量につながります。コストを下げることは計算資源の節約、つまりサステナビリティにも影響します。

WeTransferの例。アーキテクチャを見直し、二酸化炭素排出量の推測と削減につなげました。

ここからはFrugal Architectの話。デザイン/計測/最適化の3つのカテゴリに分かれます。

デザインの1つ目、コストは非機能要求である。

非機能要求と言えばセキュリティや可用性などが思い浮かびますが、

コストとサステナビリティもそこに加えるべきです。

Amazon S3サービスの開発時、当初はデータ転送量とストレージ利用量のみをコストに計上することを想定していましたが、実際に顧客に提供したところ、リクエスト数という別の指標を追加すべきことに気づきました。特に新しいサービスを開発する際は、どんなコスト体系が適切か事前に知ることは困難です。

ここで重要なのは、デザインのあらゆるステップでコストを意識すること。

デザインの2つ目、ビジネスコストに見合ったシステム。

ビジネスをサポートするのがシステムです。そのシステムがビジネスによる収益を圧迫するほどコストがかかるものでは意味がありません。

インフラストラクチャの場合、多くは規模の経済が働き、スケールするほど収益は増加するはずです。

一方でサービスの設計がうまくない場合、想定以上の利用量が発生し、コストが一気に増加する場合もあります。

ビジネス上の決定とテクノロジー上の決定が調和がとれていることを常に確認してください。

AWS Lambdaを開発しているとき、セキュリティ・分離・コストの3つを満たす方法がなかったため、コストをある程度犠牲にすることを決定しました。

その後、Firecrackerの開発により、より効率的にリソースを利用できるようになりました。

アーキテクチャは時間によって変化するため、進化可能なアーキテクチャを構築する必要があります。上記Lambdaの例のように。

もしもコストを度外視する形でシステムが構築されている場合、いつかはその負債を支払わなければなりません。

デザインの3つ目、アーキテクチャは常に一連のトレードオフである。

ここで1人目のゲスト、NubankのCat Swetelさん。

PIXと呼ばれる新たな送金アルゴリズムを提供した結果、想定以上の速度で利用量が増加し、コストと安定性のバランスをとるための決断を迫られました。

これを解決するため、いたずらにリソースを追加するのでなく、システムそのものを安定したものにすることで解決しました。その一つは長期間停止するマイクロサービスに対し、Z Garbage Collectorと呼ばれるガベージコレクションを適用することでした。

さらにデータベースとキャッシュの戦略も見直しました。

結果として、システムの効率向上とコスト削減の両方を達成しました。この成果に会場からも拍手。

ビジネスと協力して優先度を調整することが大事。

デザインのパートはこれで終了し、次は計測。

システムに観測されていない場所があれば、未知のコストが生まれます。

話は登壇者の故郷へ。まったく同じつくりの2つの家でエネルギー使用量が異なるものがあり、その理由は利用メーターが目につくところにあるかどうかでした。

Amazon.com でどのようにコストを計測しているかの話。マイクロサービスアーキテクチャを採用する同企業では、ある1つの機能を呼び出すことで数十のマイクロサービスが呼び出される可能性があります。それらがどのようにコストがかかるか、計測する必要があります。

こちらがAmazon.comのマイクロサービスの全プロットしたものだそう。

コストを理解することが大事。ただそれが困難な場合もあります。これを解決するため、

新サービス、AWS Management Console myApplicationsの発表!

aws.amazon.com

続いてAmazon CloudWatch Application Signalsの発表!EKSに関するあらゆるメトリクスを1つのダッシュボードから確認できるようになります。

aws.amazon.com

メーターを定義することで、それを継続的に監視した結果、システムとコストがどのように変化するかわかるようになります。

計測の2つ目、コストを意識したアーキテクチャにはコストの管理が必要です。

システムの一部にアクセスなどによって負荷が集中したとき、その一部を切り離して調整できるようにする必要があります。

アプリケーションを分解し、どの部分がより重要か、ティアを分けることが重要

ティアを決定し、常に稼働し続けなければならない部分がどこにあたるかを考えることが大事。

最後に最適化の話。

コスト最適化は漸進的です。

まずは不要なサービスを止める、サイズを変更する、削減するなどのことから始めます。

プロファイリングの話。Amazon CodeGuru Profilerを使うと言語ごとの?プロファイルが可能です。

プロファイルにより、コストのかかるポイントが明らかになり(ここではネットワーク)、これを解消するためにコードを修正することができます。

最適化は継続的に行う必要があります。

最適化の2つ目は、トライすること。

いつも同じやり方を続けることは危険です。

例えば、開発言語によって利用するエネルギー量が異なるという研究結果も出ています。Rustのようにエネルギー使用量が少ない言語に切り替えることもコスト減につながります。

エゴを横に置くことも重要です。

これでFrugal Architectのパートは終了。

2本目のムービー。1本目もそうでしたが、映画マトリックスのオマージュシーンがたくさん。

未来を予測するには現在をよく見ることも重要、とはじめてから、コンピュータに関する歴史の紹介。

歴史の積み重ねから、AIが生まれました。

ただし、必ずしも最新の生成AIをすべてのシーンで使わなければならないわけではありません。古き良きAIの例を紹介。画像認識による分類などで課題を解決。

2人目のゲストはThornのDr. Rebecca Portnoff。

虐待を受ける子供をより素早く見つけるため、動画データから該当するものを高速で見つける機械学習システムを開発。

AWS Marketplaceでも利用可能。

良いデータが良いAIにつながる。この辺りは今までのKeynoteでも出てきた話。

AIモデルの作成方法。扱うデータによってはKaggleにデータセットがあり、用意されたモデルにデータを与え学習し、出来上がったモデルはAPIを通じてアプリケーションから呼び出せます。

登壇者が実際に開発したモデルはGitHubから利用可能です。「私ができたんだから、あなただってできるはず」。

生成AIとともに開発する。例えばCodeWhispererと共同で作業をするなど。

ここでAmazon Sagemaker Studio Code Editorの発表。

aws.amazon.com

Amazon Qの話。CodeCatalystやIDEでも使えるようです。

AWS Application Composer in VSCodeの発表。

aws.amazon.com

builderになるのに、今ほど良いタイミングはありません、と繰り返し強調。Now Go Build。

re:Playの案内。今年はMajor Lazerが登場しました。

最後のムービー。「CI/CDからコンテナイメージをスキャンしたいけどできなかった」→「いや、今ならできると思うよ」

からの新サービス発表でクロージング。

aws.amazon.com

さいごに

コストを意識すること、そしてbuilderであることの重要性を紹介するKeynoteとなりました。特に後者のパートではポジティブなメッセージも多く、これはほかのKeynoteとも共通しているように見えました。

また普段インフラエンジニアとして業務をする身として、コストの話は業務として、builderの話はエンジニアとしての将来に向けて、どちらも響く内容でした。ポジティブなメッセージも相まって、何かをやるにはちょうど良いタイミングになりそうです。

さて、Keynoteの紹介は今回で終了となりますが、明日以降もAWS re:Invent2023の内容を共有していこうと思います。

【AWS】マネジメントコンソールに突如現れた「Amazon Q」(プレビュー版) を触ってみる

はじめに

こんにちは!クラウド事業部の早房です。
今回は、先日ラスベガスで開催された AWS re:Invent 2023 内で発表のあった新サービス「Amazon Q」 についてご紹介します。

Amazon Q について

Amazon Q とは?

以下公式ドキュメントより抜粋です。

Amazon Q は、AI を活用した新しいタイプの生成アシスタントです。これは特に仕事向けであり、企業の情報リポジトリ、コード ベース、エンタープライズ システムにあるデータと専門知識を使用して、会話、問題解決、コンテンツの生成、アクションの実行を行うために、お客様のビジネスに合わせて調整できます。
Amazon Q は、タスクを合理化し、意思決定と問題解決を迅速化し、職場での創造性とイノベーションを促進するのに役立つ、関連性の高い実用的な情報とアドバイスを迅速に提供します。
aws.amazon.com

ちなみに Amazon Q の「Q」の由来は Question のほか、「007」シリーズ内キャラクターや「スター・トレック」シリーズのキャラクターもモチーフにされているようです。
www.itmedia.co.jp

料金とプラン

Amazon Q Business と Amazon Q Builder の 2 プランが用意されており、それぞれユーザーごとに 20 ドル/月、 25 ドル/月 となっています。

それぞれのプランがサポートする機能については以下公式サイトに記載があります。
aws.amazon.com

なお、プレビュー期間中は無料で使用できます。

早速使ってみた

起動方法

マネジメントコンソールにログインしたところ、画面右に見慣れないアイコンがありました。
クリックしてみるとチャットボットのような画面が起動。

使用例①

試しに 「EC2 を Auto Scale して且つロードバランシングしたい」と聞いてみました。
現段階では英語のみしか使用できないようなので、英語で入力。

返答がきました。
具体的な手順だけではなく、ソースとなる公式ドキュメントまで表示してくれました。
ドキュメントを漁る手間が省けそうなのでかなり便利!

使用例②

続いて、トラブルシュート系の質問も投げてみました。
EC2 に SSH 接続出来ない理由を聞いてみます。
該当の EC2 の 22 番ポートを閉じたので、「セキュリティグループのインバウンドルールがおかしい」的な回答を期待。 質問を投げると瞬時に回答してくれます。

回答を和訳すると・・・

ネットワーク接続の問題についてサポートが必要のようです。Amazon Q は VPC Reachability Analyzer と連携して、ネットワーク接続の問題をトラブルシューティングするためのインタラクティブな生成 AI エクスペリエンスを提供します。ここでプレビュー エクスペリエンスを試すことができます(米国東部、バージニア北部地域で利用可能)。

とのことなので、preview experience here をクリックしてみると、
AWS Q for Reachability Analyzer の画面に遷移し、セキュリティグループのインバウンドルールが不足しているという期待通りの回答!

このように、AWS 内のサービスと連携してユーザーに情報を提供することもできます。
とても便利。

まとめ

試しに使ってみましたが、公開情報を漁る手間が省けたり、トラブルシュートを行うこともできちゃうのでかなり重宝されるサービスだなと感じました。
今まではサポートに問い合わせていた内容も、Amazon Q に聞くことで解決するケースも増えそうです。
AWS Q for Reachability Analyzer の他にも、Amazon Connect と連携した Amazon Q in Connect などもあり、Amazon Q の登場で既存のサービスが更にパワーアップしそうな予感です。
aws.amazon.com

現在はプレビュー段階ですが、GA が非常に楽しみなサービスの一つになりました!

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: hybs_yuuuu
AWSをメインにインフラ系のご支援を担当しています。 https://www.credly.com/users/hybs_yuuuu/badges