AWS fsx を作った後にやること
AWS fsxを作成した後、AWSコンソールから以外ですべき設定作業があります。
それがこちら。 docs.aws.amazon.com
概要をざっとまとめるとこちらです。
Best Practices
項目 | 機能概要 | 関連リンク |
---|---|---|
Data Deduplication | データの重複を極力削減してくれる機能 | link |
quota | データ要領の利用制限をADグループ等に対し設定できる機能 | link |
shadow copy | メリット:ファイル/フォルダ単位でのリストアが簡単に可能 デメリット:FSXの一部の要領をshadow copy用に利用する |
link link2 |
Encryption in Transit | クライアントから接続の際、暗号化通信を設定する | link |
上記はAWSが言うところのベストプラクティスです。 ただ、上記以外にもやっておいた方が良さげなことがあります。
おすすめ
項目 | 機能概要 | 関連リンク |
---|---|---|
DNS Alias | fsxに別のfqdnを付与できます リストアとかした時に便利です Deployment typeがSingle-AZ 1の時のみ利用可能なので注意です |
link |
Shared Folders tool | 接続ユーザの一覧や、ファイルがロックされてしまった場合に解除できる。設定ではないが一回触っておいた方が良い | link |
cloudwatch Alarm | 残りの容量が少ない場合通知設定をする | link |
設定してみる
では、上記を設定してみます。
まず環境変数を設定します。
全ての作業の前で、下記を実行してください。
環境変数設定
下記を「Windows Remote PowerShell Endpoint」の部分に置き換えて実行します。
#poweshell endpointを設定する $FSxWindowsRemotePowerShellEndpoint="amznfsxxxxxxxxxx.fsx-test.local"
Data Deduplication(データ重複削減)
機能概要
この機能が有効化されていると、
定期的にバックグラウンドで、データ重複を検知し、
ディスクの要領を削減してくれます。
設定方法
# depulicationを有効化 Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Enable-FsxDedup }
有効化するとデフォルトで良い感じにスケジュール実行してくれるそうです。
スケジュールを明確に指定する方法もあるようです。
docs.aws.amazon.com
Quota
機能概要
fsx本来要領に対しquota(制限)を設定できる機能です。
具体的には、ADの特定グループと、制限値を設定できるため、
ファイルサーバ的に利用している場合に、
特定のグループの人はxxGBまで、と要領制限を付けたい場合に利用すると良いと思います。
設定方法
## 記録のみしたい場合(Trackモード) $QuotaLimit = 100000000 $QuotaWarningLimit = 100000 Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Enable-FSxUserQuotas -Track -DefaultLimit $Using:QuotaLimit -DefaultWarningLimit $Using:QuotaWarningLimit }
## 要領を超えた場合に、強制的に書き込みを禁止したい場合(Enforceモード) $QuotaLimit = 100000000 $QuotaWarningLimit = 100000 Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Enable-FSxUserQuotas -Enforce -DefaultLimit $Using:QuotaLimit -DefaultWarningLimit $Using:QuotaWarningLimit }
## 現在のモードを確認する(enforceかtrackか) Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Get-FSxUserQuotaSettings }
## 特定のADのグループに制限を紐付けたい場合(例.グループ名:fsxservice) Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Set-FSxUserQuotas -Domain "fsx-test.local" -Name "fsxservice" -Limit 10 -WarningLimit 5 }
shadow copy
機能概要
fsx内のデータを特定時点に復元したいとき、
バックアップからリストアが必要となります。
ただ、間違えてファイル上書きしてしまって、
特定のファイルだけ戻したいみたいなケースは良くあると思います。
そんな時、shadow copyを有効化しておくと、
特定のファイルだけ復元が可能です。
復元時の操作イメージは下記が分かりやすいと思います。
docs.aws.amazon.com
設定方法
#shadow copyを有効化 Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Set-FsxShadowStorage -Default } #shadow copyのスケジュールを作成 $trigger1 = new-scheduledTaskTrigger -weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -at 06:00 $trigger2 = new-scheduledTaskTrigger -weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -at 18:00 invoke-command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -scriptblock { set-fsxshadowcopyschedule -scheduledtasktriggers $Using:trigger1,$Using:trigger2 -Confirm:$false } # スケジュール確認 Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Get-FsxShadowCopySchedule }
Encryption in Transit
クライアントから接続の際、
通信を暗号化通信を強制します。
設定方法
#Enforcing Encryption in Transit Invoke-Command -ComputerName $FSxWindowsRemotePowerShellEndpoint -ConfigurationName FSxRemoteAdmin -ScriptBlock { Set-FsxSmbServerConfiguration -EncryptData $True -RejectUnencryptedAccess $True -Confirm:$False}
DNS Alias
機能概要
通常、fsxが作成されるとID的に1つのFQDN(amznxxxxx.<ドメイン名>)が割り当てられます。
ただ、FQDNをリストアした場合や、 移行等の場合では、
固有のFQDNだと、設定変更が発生して面倒かと思います。
DNS Aliasを利用すると別のDNS名をつけることが可能です。
設定方法
まず、AWSコンソールで「DNS Alias」から指定したいエイリアス名を入力します。
その後、ドメイン参加のサーバからpowershell側で設定を追加します。
ドキュメントのサンプルは何回も環境変数をsetして
面倒だったため、まとめています。
$ALIAS = "fsx.fsx-test.local" $FileSystemDnsName = "amznfsxjlrqzujy.fsx-test.local" Install-WindowsFeature RSAT-AD-PowerShell ## Find SPNs for original file system's AD computer object SetSPN /Q ("HOST/" + $ALIAS) SetSPN /Q ("HOST/" + $ALIAS.Split(".")[0]) ## Delete SPNs for original file system's AD computer object $Alias = $ALIAS $FileSystemHost = (Resolve-DnsName ${FileSystemDnsName} | Where Type -eq 'A')[0].Name.Split(".")[0] $FSxAdComputer = (Get-AdComputer -Identity ${FileSystemHost}) SetSPN /D ("HOST/" + ${Alias}) ${FSxAdComputer}.Name SetSPN /D ("HOST/" + ${Alias}.Split(".")[0]) ${FSxAdComputer}.Name ## Set SPNs for FSx file system AD computer object $FSxDnsName = $FileSystemDnsName $FileSystemHost = (Resolve-DnsName $FSxDnsName | Where Type -eq 'A')[0].Name.Split(".")[0] $FSxAdComputer = (Get-AdComputer -Identity $FileSystemHost) Set-AdComputer -Identity $FSxAdComputer -Add @{"msDS-AdditionalDnsHostname"="$Alias"} SetSpn /S ("HOST/" + $Alias.Split('.')[0]) $FSxAdComputer.Name SetSpn /S ("HOST/" + $Alias) $FSxAdComputer.Name ## Verify SPNs on FSx file system AD computer object $FileSystemHost = (Resolve-DnsName ${FSxDnsName} | Where Type -eq 'A')[0].Name.Split(".")[0] $FSxAdComputer = (Get-AdComputer -Identity ${FileSystemHost}) SetSpn /L ${FSxAdComputer}.Name
続いてDNS設定です。
こちらはADが動いているサーバで実行しました。
ドキュメント内のコマンドでうまくいかない点が
あったため一部修正しています。
Alias,FSxDnsNameを上記の部分に置き換えて実行します。
$Alias = "fsx.fsx-test.local" $FSxDnsName = "amznfsxjlrqzujy.fsx-test.local" Install-WindowsFeature RSAT-DNS-Server $AliasHost=$Alias.Split('.')[0] $ZoneName=((Get-WmiObject Win32_ComputerSystem).Domain) $DnsServerComputerName = (Resolve-DnsName $ZoneName -Type NS | Where Type -eq 'A' | Select -ExpandProperty Name) Add-DnsServerResourceRecordCName -Name $AliasHost -ComputerName $DnsServerComputerName -HostNameAlias $FSxDnsName -ZoneName $ZoneName
GPOを設定する
意味的にはNTLMを利用せずKerberos認証を強制するよう
グループポリシーを設することのようです。
強制したくない場合もあると思いますので、
一部の例外も併せて設定できます。
gpmc.mscを開きます
対象のOUでグループポリシーを作成しEditします。
Localポリシー内の下記を選択します
Restrict NTLM: Outgoing NTLM traffic to remote servers
続いてLocalポリシー内の下記を選択します
Restrict NTLM: Add remote server exceptions for NTLM authentication
例外を指定したい場合はここで入力します。
上記が完了したら、エイリアス名で正しく名前解決ができることを確認します。
PS C:\Users\Administrator> nslookup fsx.fsx-test.local Server: localhost Address: ::1 Name: amznfsxjlrqzujy.fsx-test.local Address: 172.30.5.102 Aliases: fsx.fsx-test.local
その後、fsxに接続し、成功すれば完了です
net use z: \\fsx.fsx-test.local\share
Shared Folders tool
機能概要
下記のようなケースで管理者が使うツールです。
こちらは設定しておくものでなく、
管理者が利用するケースがあると思いますので、
構築したタイミングで動作を試してみると良いと思います。
- FSXへの接続セッションを強制で切る
- ファイルが競合してうまく開かない等あったら解決できる
利用方法
fsmgmt.msc
fsxのdns名を入力
その後、セッションを終了させる、
ファイル競合を解決する操作は下記が分かりやすいです。
docs.aws.amazon.com
cloudwatch Alarm
下記参考にFreeStorageCapacity(空き容量)の通知ぐらいは
しておいた方が良いかと思いました。
docs.aws.amazon.com
下記をまとめて作成するcloudformaitonを下記ました。
自己所有のADを参照するFsx用の記述のため
MicrosoftADをご利用の場合は、その部分を書き換えが必要です。
あと、各種パラメータは読み替えてください。
- fsx
- security-group
- SNS
- cloudwatch
AWSTemplateFormatVersion: "2010-09-09" Description: A templete for fsx for windows Parameters: EnvPrefix: Type: String Default: "test" # KmsKeyId: # Type: String StorageCapacity: Type: Number Default : 32 VPCId: Type: AWS::EC2::VPC::Id Default: vpc-xxxxxxxxx SubnetIds: Type: List<AWS::EC2::Subnet::Id> Default: subnet-xxxxxxxxxx # ActiveDirectoryId: # Type: String # Default: d-96671b8248 DailyAutomaticBackupStartTime: Type: String Default: "16:00" DeploymentType: Type: String Default: SINGLE_AZ_2 # Default: MULTI_AZ_1 ThroughputCapacity: Type: Number Default : 8 WeeklyMaintenanceStartTime: Type: String Default: "6:17:00" OnpreDNS: Type: CommaDelimitedList Default: xxx.xxx.xxx.xxx OnpreDomainName: Type: String Default: fsx-test.local FileSystemAdministratorsGroup: Type: String Default: FSXAdmins UserName: Type: String Default: fsxservice Password: Type: String Default: xxxxxxxxxxxxxxxxxxxxxxxxxx NoEcho: True OrganizationalUnitDistinguishedName: Type: String Default: "OU=FileSystems,DC=fsx-test,DC=local" FSXAllowedRange: Type: String Default: 172.30.0.0/16 ThresholdFreeStorageCapacity: Type: Number Default: 3221225472 endpointEmail: Type: String Default: 'xxxxxxxxxxxxxx@xxxxxx.com' Resources : fsx: Type: AWS::FSx::FileSystem Properties: # KmsKeyId: kms FileSystemType: WINDOWS SecurityGroupIds: - !Ref sg StorageCapacity: !Ref StorageCapacity StorageType: SSD # StorageType: HDD SubnetIds: !Ref SubnetIds WindowsConfiguration: # ActiveDirectoryId: !Ref ActiveDirectoryId AutomaticBackupRetentionDays: 7 CopyTagsToBackups: true DailyAutomaticBackupStartTime: !Ref DailyAutomaticBackupStartTime DeploymentType: !Ref DeploymentType # PreferredSubnetId: String SelfManagedActiveDirectoryConfiguration: DnsIps: !Ref OnpreDNS DomainName: !Ref OnpreDomainName FileSystemAdministratorsGroup: !Ref FileSystemAdministratorsGroup OrganizationalUnitDistinguishedName: !Ref OrganizationalUnitDistinguishedName Password: !Ref Password UserName: !Ref UserName ThroughputCapacity: !Ref ThroughputCapacity WeeklyMaintenanceStartTime: !Ref WeeklyMaintenanceStartTime sg: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: !Sub ${EnvPrefix}-sg GroupName: !Sub ${EnvPrefix}-sg VpcId: !Ref VPCId SecurityGroupIngress: - CidrIp: !Ref FSXAllowedRange FromPort: 445 ToPort: 445 IpProtocol: tcp - CidrIp: !Ref FSXAllowedRange FromPort: 5985 ToPort: 5985 IpProtocol: tcp Tags: - Key: Name Value: FSX CloudWatchAlarmFreeStorageCapacity: Type: AWS::CloudWatch::Alarm Properties: ActionsEnabled: 'true' ComparisonOperator: LessThanOrEqualToThreshold EvaluationPeriods: '1' MetricName: FreeStorageCapacity Namespace: AWS/FSx AlarmName: !Sub ${EnvPrefix}FreeStorageCapacity Period: '300' Statistic: Average Threshold: !Ref ThresholdFreeStorageCapacity AlarmActions: - !Ref SNSNotif Dimensions: - Name: FileSystemId Value: !Ref fsx SNSNotif: Type: AWS::SNS::Topic Properties: DisplayName: !Sub ${EnvPrefix}Topic Subscription: - Endpoint: !Ref endpointEmail Protocol: email TopicName: !Sub ${EnvPrefix}TopicTicket
AWS fsx for windows (自己所有AD)の事前のAD設定メモ
FSXを自己所有のADで作成する際、AD側で何をすれば良いのかが AWSのドキュメントを見ても、いまいち分かりにくかったです。 docs.aws.amazon.com aws.amazon.com 上記を見ながら作業をしてみたところ正常動作でき、 作業をより分かりやすく残しておきたいと思い、 備忘メモとしてブログ化します。
ADの事前設定
ADでOU、グループ、ユーザを作成
まず、AD側の手順として、下記を作成します。
設定項目 | 設定値 |
---|---|
OU | FileSystems |
UserName | fsxservice |
FileSystemAdministratorsGroup | FSXAdmins |
Password | 適当 |
「dsa.msc」を開く OUを「FileSystems」で作成します。
FileSystemsの中にユーザ、グループを作成します
その後、上記で作成したOUに権限を移譲します。
作成したOUで右クリックDelegate Controlを選択
「FSXAdmins」を指定
「Create a custom task to delegate」を選択します。
「Only the following objects in the folder」を選択し
「Computer objects」を選択します。
下記2つを選択します。
「Create selected objects in this folder」
「Delete selected objects in this folder」
さらに次の画面で下記を選択します。
- Reset Password
- Read and write Account Restriction
- Validated write to DNS host name
- Validated write to service principal name
以上でAD側の作業は完了です。
fsxを作成する
上記が作成できましたら、fsxを作成します。 cloudformationを作りました。
AWSTemplateFormatVersion: "2010-09-09" Description: A templete for fsx for windows Parameters: EnvPrefix: Type: String Default: "test" # KmsKeyId: # Type: String StorageCapacity: Type: Number Default : 32 VPCId: Type: AWS::EC2::VPC::Id Default: vpc-xxxxxxxxxxx SubnetIds: Type: List<AWS::EC2::Subnet::Id> Default: subnet-xxxxxxxxxxx DailyAutomaticBackupStartTime: Type: String Default: "16:00" DeploymentType: Type: String Default: SINGLE_AZ_2 # Default: MULTI_AZ_1 ThroughputCapacity: Type: Number Default : 8 WeeklyMaintenanceStartTime: Type: String Default: "6:17:00" OnpreDNS: Type: CommaDelimitedList Default: xxx.xxx.xxx.xxx OnpreDomainName: Type: String Default: fsx-test.local FileSystemAdministratorsGroup: Type: String Default: FSXAdmins UserName: Type: String Default: fsxservice #本当はパラメータストア等を参照するのが良いです Password: Type: String Default: xxxxxxxxxxxxxx NoEcho: True OrganizationalUnitDistinguishedName: Type: String Default: "OU=FileSystems,DC=fsx-test,DC=local" FSXAllowedRange: Type: String Default: xx.xx.xx.xx/xx Resources : fsx: Type: AWS::FSx::FileSystem Properties: # BackupId: String # KmsKeyId: kms # LustreConfiguration: # LustreConfiguration FileSystemType: WINDOWS SecurityGroupIds: - !Ref sg StorageCapacity: !Ref StorageCapacity StorageType: SSD # StorageType: HDD # The StorageCapacity specified is not supported. Storage capacity for HDD must be no less than 2000 SubnetIds: !Ref SubnetIds WindowsConfiguration: # ActiveDirectoryId: !Ref ActiveDirectoryId AutomaticBackupRetentionDays: 7 CopyTagsToBackups: true DailyAutomaticBackupStartTime: !Ref DailyAutomaticBackupStartTime DeploymentType: !Ref DeploymentType # PreferredSubnetId: String SelfManagedActiveDirectoryConfiguration: DnsIps: !Ref OnpreDNS DomainName: !Ref OnpreDomainName FileSystemAdministratorsGroup: !Ref FileSystemAdministratorsGroup OrganizationalUnitDistinguishedName: !Ref OrganizationalUnitDistinguishedName Password: !Ref Password UserName: !Ref UserName ThroughputCapacity: !Ref ThroughputCapacity WeeklyMaintenanceStartTime: !Ref WeeklyMaintenanceStartTime sg: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: !Sub ${EnvPrefix}-sg GroupName: !Sub ${EnvPrefix}-sg VpcId: !Ref VPCId SecurityGroupIngress: - CidrIp: !Ref FSXAllowedRange FromPort: 445 ToPort: 445 IpProtocol: tcp - CidrIp: !Ref FSXAllowedRange FromPort: 5985 ToPort: 5985 IpProtocol: tcp Tags: - Key: Name Value: FSX
AWS StepFunctions Lambdaを利用する時のTips
Japan APN Ambassador Advent Calendarqiita.com
2020 8 日目のエントリです。
先日、会社でStepFunctionsの利用方法や、
Tipsを説明することがありました。
良い機会なので記事に書いてみようと思いました。
Stepfunctions概要
docs.aws.amazon.com
サーバレスのサービスを組合せて利用する際の
オーケストレーションのサービスです。
具体例をみると分かりやすいかもしれません。
下記の図の各NodeがLambda、SQS等、 各種AWSのサービスを表しており、
それらの処理を組み合わせて定義することが可能です。
Tips
利用し始めるとStepFunctionsならではの
機能や制限があることに後から気付き、
処理を作り直すことが良くありました。
事前に知っておきたかったことを
会社の後輩に伝えたところ割と喜んでくれたので書いていきます。
例外処理、再実行レベルを考慮する
上述のようにStepFunctionsでは
複数のLambdaを組み合わせることができます。
StepfunctionsでもLambda実行時のエラー考慮が必要になります。
Lambdaにはデッドレターキューというエラーの処理方法がありますが、
StepFunctionsのときは、代わりにStepFunctions独自のエラーハンドリングを利用すると便利です。
外部環境により発生した例外の場合
Lambdaでは(コードが正しくても)稀に実行が失敗することがあります。
レート制限エラーや、ネットワーク等の影響による一時的なエラーです。
このような場合は、数秒おいて再実行すれ成功する可能性が高いため
StepfunctionsのRetry機能を利用するのが良いと思います。
docs.aws.amazon.com
具体的には、下記のように特定のLambdaの処理に下記のように
Retryを設定することで、StepfunctionsがLambdaを再実行してくれます。
"Retry": [ { "ErrorEquals": [ "States.Timeout" ], #このエラーのときに "IntervalSeconds": 3, #インターバル3秒で "MaxAttempts": 2, #最大2回再試行 "BackoffRate": 1.5 #再実行の実行回数が増える毎にインターバルの秒数を増やす設定値 } ]
その他の例外の場合
上記以外ですと、
StepFunctionsのcatch機能を利用するのが良いと思います。
例外の内容により、次に実行する処理(Lambda)を制御できます。
docs.aws.amazon.com
具体的には、下記のように特定のLambdaの処理に下記のように
Catchを設定することで、StepfunctionsがLambdaがエラーだったときの
ハンドリングをしてくれます。
"Catch": [ { "ErrorEquals": ["States.Timeout"], #このエラーのときは "Next": "fallback" #次にfallbackの処理を実行する } ],
上記機能を利用し、
Lambda内はエラー処理をごちゃごちゃ書かず
シンプルな状態を保つとメンテナンスしやすいです。
Lambda単位で冪等性を持つように作る
上述のように各Lambdaの再実行設定が容易なため、
Lambda単位で冪等性(何回実行しても同じ結果になる)を
持つようにしておくと
StepFunctionsで利用しやすいです。
Mapやループ処理の際、StepFunctionsを分割する
バッチ処理をStepFunctionsで組む場合、 大量のデータをループ処理または並列処理したいことがあります。
StepFunctionsでは、下記のようにループ処理を書くことや
下記のような並列処理(MAP)の記載が可能です。
ただし、StepFunctionsでは状態間の
データの受け渡し容量が262,144bytesと制限されています。
大量のデータをやりとりする場合は、この制限を超えてしまいます。
StepFunctionsではデータが制限を超える場合、S3等を利用し、
一時的にデータを別場所に保管することが推奨されています。
ただし、S3を利用しデータを受渡すると、
上記のような、ループや並列処理の記述ができません。
そこで、私の場合はStepFunctionsを2つに分けました。
3つ目の処理の中で、大量データを取得し、
データ毎に別のStepFunctionsを実行することで
並列処理が可能でした。
将来的にデータ量が拡張し、制限を超える場合は、
このような記述も良いと思います。
StepFunctionsの実行時の引数を活用する
Stepfunctionsのフロー図を作成すると、
極力それを使いまわしたいと思います。
例えば特定条件のリソースを停止する処理を作成するとします。
毎月末に対象を通知し、毎月初に停止処理を実行する場合
停止をするかしないか以外は、ほぼ同じ処理になります。
そんなとき、StepFunctionsの実行時の引数で処理を分岐すると便利でした。
具体的にはStepFunctions実行時の引数として変数を渡し
その変数によって処理を分岐するイメージです。
さいごに
Japan APN Ambassador Advent Calendarの
記事を書かせて頂き大変光栄でした!
会社を超えて、日々前向きな方達と交流が持てるのは
本当にありがたいです。
コロナ影響が早くなくなって、
もっとリアルでもお会いできるのを楽しみにしています。
AWS ClientVPNの構成図 7パターン
AWSのClientVPNには認証方式が複数あります。
認証方式により、構成やUXが微妙に変わり、その質問をいただくことが多いため、
ユーザ視点でどんな感じになるのかを、7パターンで整理してみたいと思います。
これ以外にも構成パターンはあると思いますが、それらは応用編で、
もし機会があればブログ化してみたいと思います。
構成は、認証方式に依存する形となります。
紹介するパターンは下記です。
- ADオンプレで認証
- AD(AWS managed)で認証
- SAML(Okta)で認証
- ADオンプレ+証明書で認証
- AD(AWS managed)+証明書で認証
- SAML(Okta)+証明書で認証
- 証明書のみで認証
(1)ADオンプレで認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。 クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります(RouteTableとSGの設定を忘れずに)
- オンプレのサーバと疎通が可能となります(サーバ側の疎通許可設定を忘れずに)
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
ユーザ名、パスワードを入力します
認証に通ると接続されます。
運用考慮点
ADとclientVPNの接続許可設定を連動させることができます 。
(例:特定のOUの人が、xx.xx.xx.xx/xxへの疎通が可能)
その設定を変更する際は、ADとClientVPNの設定を変更する必要があります
(2)AD(AWS managed)で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります(RouteTableとSGの設定を忘れずに)
- オンプレのサーバと疎通が可能となります(サーバ側の疎通許可設定を忘れずに)
運用考慮点
(1)のパターンと同様です。
利用イメージ
(1)のパターンと同様です。
(3)SAML(Okta)で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい(ADと紐付け不要、ADの管理したくない場合)
- 認証はID管理サービスのログインでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス(Okta)のユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります(RouteTableとSGの設定を忘れずに)
- オンプレのサーバと疎通が可能となります(サーバ側の疎通許可設定を忘れずに)
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
Oktaでの認証を求められるためid/passでログインします。
Oktaの認証に通るとclientVPNに接続可能となります。
利用イメージ(ユーザ管理)
Oktaでのユーザ管理は下記イメージです。
私も初めてOktaを利用したのですが、特に迷うことなく直感的に操作できました。
ユーザ管理画面です。
ユーザ登録画面です。
(4)ADオンプレ+証明書で認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります(RouteTableとSGの設定を忘れずに)
- オンプレのサーバと疎通が可能となります(サーバ側の疎通許可設定を忘れずに)
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(5)AD(AWS managed)+証明書で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります(RouteTableとSGの設定を忘れずに)
- オンプレのサーバと疎通が可能となります(サーバ側の疎通許可設定を忘れずに)
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(6)SAML(Okta)+証明書で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい(ADと紐付け不要)
- 認証はID管理サービスのユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス(Okta)のユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります(RouteTableとSGの設定を忘れずに)
- オンプレのサーバと疎通が可能となります(サーバ側の疎通許可設定を忘れずに)
運用考慮点
(3)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(3)のパターンと同様です。
(7)証明書のみで認証
概要
こんな方向けです。
- 認証はクライアント証明書のみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります(RouteTableとSGの設定を忘れずに)
- オンプレのサーバと疎通が可能となります(サーバ側の疎通許可設定を忘れずに)
運用考慮点
証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
特にユーザ/パスワードを入力することなく接続が可能です
どのパターンが良いのか
まず最初に認証がユーザ/パスワードのみで良いかを考えると良いかと思います。
ユーザ/パスワードのみの認証で十分な場合には(1)(2)(3)が候補です。
(1)(2)(3)は既存でADを利用しているかどうかで決めると良いと思います。
Enterpriseでセキュリティが厳しい場合は、
ユーザ/パスワードと証明書による認証で(4)(5)(6)が候補です。
(4)(5)(6)は既存でADを利用しているかどうかで決めると良いと思います。
(7)は現実的に利用する方は少ないと思います。
上記をまとめるにあたり、初めてOktaを利用してみたのですが、
個人的にはOktaがかなり使いやすく、Oktaおすすめです。
小規模の会社で、試しにClientVPNを利用してみるぐらいでしたら
パターン(3)が良いのではと思います。
証明書は、セキュリティ強度は上がると思うのですが、
人件費等の作業コストがかかることを考えると
Oktaのようなサービス利用料の方が
トータルで安くなるのかと思います。
AWS SSOでGsuiteと連携した
会社でGsuiteを利用しており、AWSとSSO連携させてみました。
微妙にdocumentが分かりにくかったので、作業内容をブログ化してみました。
Gsuite側
まずは、Gsuite側の作業から入ります。
Gsuiteの管理者コンソールにログインする必要がありますので、
事前に管理者権限を割り当ててもらう必要があります。
ここでは、管理者コンソールにログインした前提で進めます。
IDPメタデータをダウンロードしておきます。
AWS側
今度は、AWS SSO側で作業します。
こちらで、先ほどGsuiteでダウンロードしたファイルをアップロードします。
ここで3つのURLを控えておきます。
Gsuite側
上記で控えたURL3つをGsuite側の設定に書き込みます。
AWS側
上記を終えたらまたAWS側に戻ります。
ここで、ユーザ名はgoogleのメールアドレスである必要があります。
(そうでないと後々エラーとなる。私はそれでハマりました)
ここで、SSOでログインした際に所有させたい権限を選択します。 良くあるものはawsが定義してくれており、 カスタマイズが必要な場合は自作もできます。
Gsuite側
最後にGsuite側で、ログイン可能とすべく、権限を特定ユーザor全員に開放します。
ログインイメージ
SSOのログイン画面にアクセスすると、下記のような画面が開きます ここで、上記で設定した権限の一覧が出てくるので、ログインしたい権限で Management consoleをクリックすると画面遷移できます。
また、クレデンシャルも払い出してくれます。
Tips
上記を試すまで下記が気になっていたので、試してみました。
Q:SSOでログイン後に、さらにスイッチロールは可能か?
A:可能でした
Q:Organization外のAWSアカウントにSSOから直接遷移することは可能か?
A:可能です。ただし受け側で下記作業が必要です。
static.global.sso.amazonaws.com
Q:cloudtrailにユーザ名はどのように残るのか
A:ユーザ名(メールアドレス)で残ります
オンプレからAWS RDSへの移行方法まとめ
オンプレからAWS(RDS)への移行方法をまとめてみました。
AWS Database Specialityの勉強をする過程で、
何かとまとめておくと、後々便利と思い自分のメモにしていたのですが、きれいにしたので公開してみます。
RDSの種類 * 移行方式の数があるのでかなりの量がありますね。
AWS AuroraのレプリカAutoscalingを時間指定で増減させる
Auroraのリードレプリカ数をAutoscalingできます。
時間指定でもできるのか試してみました。
結論を言うとできます。
AWS コンソールではCPU使用率、または接続数でスケールする設定しか
できないようなのですが、基本はなんでもできそうです。
autoscaling設定をした後に
CLIでcron形式で試してみたら普通にできました。
aws application-autoscaling put-scheduled-action \ --service-namespace rds \ --schedule "cron(50 * * * ? *)" \ --scheduled-action-name 'achaction' \ --resource-id 'cluster:test-xxxx-aurora-cluster' \ --scalable-dimension rds:cluster:ReadReplicaCount \ --scalable-target-action 'MinCapacity=1,MaxCapacity=1'
スケジュール削除もCLIで簡単にできます
aws application-autoscaling delete-scheduled-action \ --service-namespace rds \ --scheduled-action-name achaction \ --scalable-dimension rds:cluster:ReadReplicaCount \ --resource-id cluster:test-xxxx-aurora-cluster