RDS for SQL ServerによってActive Directory上に生成された古いコンピューターオブジェクトを削除してみました
初めに
RDS for SQL ServerはEC2上に構築されたセルフマネージドなActive Directory上のドメインに参加させログインにWindows認証を利用することが可能となっています。
具体的な仕様の部分は非公開の部分も多いのですが、実際の動作を見る限り作成時に指定したサービスアカウントを利用しRDSインスタンスを示すコンピュータオブジェクトやそのDNSの登録を行うようなものと見られます。
このコンピュータオブジェクトですが、基盤となるEC2インスタンスが変わるたびに生成される(?)ようでリストアや一時停止からの起動を行うたびに別のオブジェクトが生成されます。
今回の環境ではコスト削減のために夜間停止を実施しているのですが、一時停止→起動を行った場合では古いコンピュータオブジェクトが削除されずどんどんと新規のオブジェクトが追加されるようでした。
(EC2AMAZ-xxxがRDSによって作成されるオブジェクトです)
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.SettingUp.html
セルフマネージド AD ドメインに参加した RDS for SQL Server DB インスタンスを所有する AWS アカウントに、専用の OU とその OU を対象とするサービス認証情報を作成することをお勧めします。OU とサービス認証情報を専用にすることで、アクセス許可の競合を回避し、最小特権の原則に従うことができます。
推奨設定に従っていれば専用のOUを作成しそこにオブジェクトが生成されるため、他のオブジェクトと混在するということはなく基本的に問題になることはないと思います。ただ、定期的に停止している場合は徐々にオブジェクトが増えていきDBの肥大化に繋がるので管理の都合等で可能であればクリーンアップしておきたいということはあるかもしれません。
(とは言いつつ無限に基盤となるEC2インスタンスがあるわけではないと思うの上限はあるとは思いますが...)
今回は以前に生成された古いコンピュータオブジェクトを探し削除していくようなスクリプトを作成実行してみます。
注意
RDS for SQL ServerとActive Directory周りの処理については公開されている部分があまり多くありません。そのため今回の検証上では問題ないように見えるものの、長期間の運用時の影響が見れておらず内部の仕様変更等によって予期せぬ影響を受ける可能性があります。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Requirements.html
DB インスタンスの作成後に RDS for SQL Server が組織単位に作成したコンピュータオブジェクトを移動しないでください。関連するオブジェクトを移動すると、RDS for SQL Server DB インスタンスが誤って設定される原因となります。Amazon RDS によって作成されたコンピュータオブジェクトを移動する必要がある場合は、ModifyDbInstance RDS API オペレーションを使用して、コンピュータオブジェクトの目的の場所にドメインパラメータを変更します。
削除に関しては言及されていませんが、ブラックボックスな上に移動を禁止するような言及はありますのでオブジェクト数を減らしたいような要望がない限りはそのままにしておいて頂くのが安全とはなります。
実施する場合はある程度そういったリスクがある点を考慮に入れておき、また検証の上ご利用いただければと思います。
環境
以下のような環境で実行しています
- EC2上にWindows Server 2025(ドメインコントローラー)を作成
- Active Directory Domain Serviceをインストールし単一のフォレストを作成
- 専用OU、ユーザの作成は以下の手順に従い実施
- RDS for SQL ServerはSQL Server 2022 Standard Editionを利用
- ドメインコントローラーは上記サーバを指定し専用のOU(
OU=RDSInstance,DC=suzuki,DC=internal)にオブジェクトが作成されるように設定
- ドメインコントローラーは上記サーバを指定し専用のOU(
こちらの環境でRDSを何度か一時停止と起動を繰り返しいくつかコンピューターオブジェクトを生成しておきます。先に載せた画像が実施前の状態となります。
RDSにより生成されるコンピューターオブジェクト
コンピュータオブジェクトの取得はPowerShellではGet-ADComputerで可能です。
RDS側より生成されたオブジェクトを取得して情報を確認したところ以下のようになっていました。
PS C:\Users\Administrator> Get-ADComputer -Filter * -SearchBase "OU=RDSInstance,DC=suzuki,DC=internal" -Properties * | Select-Object -First 1
AccountExpirationDate :
accountExpires : 9223372036854775807
AccountLockoutTime :
AccountNotDelegated : False
AllowReversiblePasswordEncryption : False
AuthenticationPolicy : {}
AuthenticationPolicySilo : {}
BadLogonCount : 0
badPasswordTime : 0
badPwdCount : 0
CannotChangePassword : False
CanonicalName : suzuki.internal/RDSInstance/EC2AMAZ-AV3IR42
Certificates : {}
CN : EC2AMAZ-AV3IR42
codePage : 0
CompoundIdentitySupported : {False}
countryCode : 0
Created : 2025/10/10 3:15:24
createTimeStamp : 2025/10/10 3:15:24
Deleted :
Description :
DisplayName :
DistinguishedName : CN=EC2AMAZ-AV3IR42,OU=RDSInstance,DC=suzuki,DC=internal
DNSHostName : EC2AMAZ-AV3IR42.suzuki.internal
DoesNotRequirePreAuth : False
dSCorePropagationData : {1601/01/01 0:00:00}
Enabled : True
HomedirRequired : False
HomePage :
instanceType : 4
IPv4Address : 192.168.2.190
IPv6Address :
isCriticalSystemObject : False
isDeleted :
KerberosEncryptionType : {RC4, AES128, AES256}
LastBadPasswordAttempt :
LastKnownParent :
lastLogoff : 0
lastLogon : 134045404301063589
LastLogonDate : 2025/10/10 3:15:24
lastLogonTimestamp : 134045397242549914
localPolicyFlags : 0
Location :
LockedOut : False
logonCount : 7
ManagedBy :
MemberOf : {}
MNSLogonAccount : False
Modified : 2025/10/10 3:27:10
modifyTimeStamp : 2025/10/10 3:27:10
msDS-SupportedEncryptionTypes : 28
msDS-User-Account-Control-Computed : 0
Name : EC2AMAZ-AV3IR42
nTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory : CN=Computer,CN=Schema,CN=Configuration,DC=suzuki,DC=internal
ObjectClass : computer
ObjectGUID : 5f06f782-111c-48ad-93b3-4e5e16a7c6d6
objectSid : S-1-5-21-1645915083-3199755865-1780751892-1104
OperatingSystem : Windows Server 2016 Datacenter
OperatingSystemHotfix :
OperatingSystemServicePack :
OperatingSystemVersion : 10.0 (14393)
PasswordExpired : False
PasswordLastSet : 2025/10/10 3:15:24
PasswordNeverExpires : False
PasswordNotRequired : False
PrimaryGroup : CN=Domain Computers,CN=Users,DC=suzuki,DC=internal
primaryGroupID : 515
PrincipalsAllowedToDelegateToAccount : {}
ProtectedFromAccidentalDeletion : False
pwdLastSet : 134045397241065770
SamAccountName : EC2AMAZ-AV3IR42$
sAMAccountType : 805306369
sDRightsEffective : 15
ServiceAccount : {}
servicePrincipalName : {MSSQLSvc/EC2AMAZ-AV3IR42.suzuki.internal:1433, MSSQLSvc/EC2AMAZ-AV3IR42.suzuki.internal, MSServerClus
terMgmtAPI/EC2AMAZ-AV3IR42, MSServerClusterMgmtAPI/EC2AMAZ-AV3IR42.suzuki.internal...}
ServicePrincipalNames : {MSSQLSvc/EC2AMAZ-AV3IR42.suzuki.internal:1433, MSSQLSvc/EC2AMAZ-AV3IR42.suzuki.internal, MSServerClus
terMgmtAPI/EC2AMAZ-AV3IR42, MSServerClusterMgmtAPI/EC2AMAZ-AV3IR42.suzuki.internal...}
SID : S-1-5-21-1645915083-3199755865-1780751892-1104
SIDHistory : {}
TrustedForDelegation : False
TrustedToAuthForDelegation : False
UseDESKeyOnly : False
userAccountControl : 4096
userCertificate : {}
UserPrincipalName :
uSNChanged : 12873
uSNCreated : 12825
whenChanged : 2025/10/10 3:27:10
whenCreated : 2025/10/10 3:15:24
RDS起動のタイミングでオブジェクトが生成され、また一度停止してしまうと別のオブジェクトが生成される(=以前のオブジェクトは使われない？)ためか基本的には作成(Created)と最終ログオン日時(LastLogonDate)はイコールとなるようです。
ModifyとCreatedの時間が異なるため停止時に何か変更が行われているのかな？と思っていたのですが起動中・停止後では特にオブジェクトの情報自体は変わらず、起動処理の最中にservicePrincipalName(s)が変わるようです。
（停止・削除時にEnabledがFalseになることもないようです）
## 起動中(マネコン上バックアップ中など、「利用可能」ではない状態）
servicePrincipalName : {MSSQLSvc/EC2AMAZ-3DEOUDN.suzuki.internal, MSServerClusterMgmtAPI/EC2AMAZ-3DEOUDN, MSServerClusterMgmt
API/EC2AMAZ-3DEOUDN.suzuki.internal, TERMSRV/EC2AMAZ-3DEOUDN...}
ServicePrincipalNames : {MSSQLSvc/EC2AMAZ-3DEOUDN.suzuki.internal, MSServerClusterMgmtAPI/EC2AMAZ-3DEOUDN, MSServerClusterMgmt
API/EC2AMAZ-3DEOUDN.suzuki.internal, TERMSRV/EC2AMAZ-3DEOUDN...}
## 起動後・一時停止後
servicePrincipalName : {MSSQLSvc/EC2AMAZ-3DEOUDN.suzuki.internal:1433, MSSQLSvc/EC2AMAZ-3DEOUDN.suzuki.internal, MSServerClus
terMgmtAPI/EC2AMAZ-3DEOUDN, MSServerClusterMgmtAPI/EC2AMAZ-3DEOUDN.suzuki.internal...}
ServicePrincipalNames : {MSSQLSvc/EC2AMAZ-3DEOUDN.suzuki.internal:1433, MSSQLSvc/EC2AMAZ-3DEOUDN.suzuki.internal, MSServerClus
terMgmtAPI/EC2AMAZ-3DEOUDN, MSServerClusterMgmtAPI/EC2AMAZ-3DEOUDN.suzuki.internal...}
そのためオブジェクト上の情報だけではそのコンピューターオブジェクトが最終的にいつ使われたか？というのは必ずしも特定できるわけではなさそうです。もしかしたらもっと長い時間起動を続けていると変動するかもしれませんが検証のために起動しっぱなしとするにはRDS for SQL Serverは高価でしたので今回は未検証となります。
仮に上記以外で変動しない場合は対象は運用を踏まえて推定する形となりそうです。
例えば週末のみ停止運用であれば作成から1週間以内には停止される=Modifyが1週間経過したものは利用されていないはずのような形で対象を決定していく形となりそうです。
またあくまで今回はどんどん増えていくオブジェクトが単に気になるというだけで、RDS for SQL Serverの仕様としてユーザで削除するような処理は本来必要ではないため、平日の早朝に起動し平日の深夜に停止するようなデイリーでオブジェクトが増えていく環境を想定し、１週間程度経過したらそれより古いオブジェクトを削除するのような形で緩い処理を組んでみます。
(ブラックボックス部分のためあまりに猶予なしで削除すると怖いというのが正直なところです)
対象の特定・削除処理
削除はRemove-ADComputerのExample 2を見る限りGet-ADComputerに渡してしまえば良さそうです。
日付での絞り込みは-Filterを利用すればできますので以下のスクリプトを実行します。
# 対象の日付設定
$DaysOld = 7
$TargetDate = (Get-Date).AddDays(-$DaysOld)
Write-Output "Objects modified before $DaysOld days ($TargetDate) will be deleted."
Write-Output ""
# 対象の取得・出力
$TargetComputers = Get-ADComputer -Filter {Modified -lt $TargetDate} `
-SearchBase "OU=RDSInstance,DC=suzuki,DC=internal" `
-Properties Name, Created, Modified, LastLogonDate, Enabled
$TargetComputers | Format-Table Name, Created, Modified, LastLogonDate -AutoSize
# 削除
# スケジューラ等で自動実行するなら非対話式になるので確認は飛ばす
$TargetComputers | Remove-ADComputer -Confirm:$false
Write-Output "Deletion completed"
OKです！
Objects modified before 7 days (10/14/2025 10:00:00) will be deleted.
Name Created Modified LastLogonDate
---- ------- -------- -------------
EC2AMAZ-AV3IR42 2025/10/10 3:15:24 2025/10/10 3:27:10 2025/10/10 3:15:24
EC2AMAZ-674BARJ 2025/10/10 3:58:48 2025/10/10 4:06:58 2025/10/10 3:58:48
実行前
実行後
定期的に実行させたい場合、従来通りのWindows管理に寄せたいのであればタスクスケジューラを利用し定期的に実行
AWS側に寄せたいのであればEventBridge + Systems Managerを利用して流し込むのが良いでしょう。
終わりに
今回はRDS for SQL Serverにより作成されたActive Directory上の古いコンピューターオブジェクトを削除する処理を組んでみました。
処理としては実装してみましたが前述の通りユーザからしたらブラックボックスの部分かつ、仕組み上必ずしもユーザで管理しないといけない部分ではないため基本的に触らず、オブジェクト数が多くどうしても...のようになりましたら検討するくらいが良いかもしれません。
