Einführung
Wenn Unternehmen wachsen, wird die Notwendigkeit, Umgebungen für Sicherheit, Verwaltung und Arbeitslasten zu trennen und zu isolieren, immer wichtiger. AWS Organizations bietet einen Rahmen, um dies zu erreichen, aber es bringt auch neue Herausforderungen mit sich - vor allem, wenn es um die konsistente Verwaltung der Infrastruktur über mehrere Konten und Regionen hinweg geht.
Wenn Sie Infrastructure as Code einsetzen, nimmt diese Komplexität noch zu. Oft müssen Sie dieselben Ressourcen für viele Konten bereitstellen, und dies manuell zu tun, ist sowohl fehleranfällig als auch ineffizient. An dieser Stelle kommen CloudFormation StackSets ins Spiel. Mit StackSets können Sie CloudFormation-Vorlagen für mehrere Konten und Regionen auf einmal bereitstellen und sogar sicherstellen, dass neue Konten automatisch dieselbe Infrastruktur erhalten.
In diesem Blog-Beitrag werden zunächst die Grundlagen von AWS Organizations behandelt, um die Struktur und die wichtigsten Konzepte zu verstehen, und dann wird erläutert, wie CloudFormation StackSets in einer Umgebung mit mehreren Konten effektiv eingesetzt werden können.
Struktur der AWS-Organisationen
Bevor wir in die Infrastrukturverwaltung mit CloudFormation Stacksets eintauchen, sollten wir uns einige Schlüsselkonzepte der AWS-Organisation ansehen.
Eine Organisation ist eine Sammlung von AWS-Konten, die zentral verwaltet werden und in einer hierarchischen, baumartigen Struktur mit einem Stamm an der Spitze organisiert sind. Unter der Wurzel können Sie Konten oder Organisationseinheiten haben. Jede Organisation besteht aus einem Verwaltungskonto, null oder mehr Mitgliedskonten, null oder mehr Organisationseinheiten (OUs) und null oder mehr Richtlinien.
Das administrative Stammverzeichnis wird automatisch erstellt, wenn Sie eine Organisation in AWS erstellen, und ist der Ausgangspunkt für die Organisation der AWS-Konten. Unter dem Stamm können Sie Organisationseinheiten (OUs) erstellen und organisieren. Wenn Sie eine Verwaltungsrichtlinie auf das Stammverzeichnis anwenden, gilt sie für alle Konten und OUs, einschließlich des Verwaltungskontos. Wenn Sie jedoch eine Autorisierungsrichtlinie (z. B. eine Servicekontrollrichtlinie) auf das Stammverzeichnis anwenden, gilt sie für alle Konten und OUs mit Ausnahme des Verwaltungskontos.
Eine Organisationseinheit (OU) ist eine Gruppe von AWS-Konten und/oder anderen OUs. OUs sind nützlich, wenn Sie die gleichen Kontrollen auf eine Untergruppe von Konten in Ihrer Organisation anwenden müssen.
Das Verwaltungskonto ist das AWS-Konto, das Sie zum Erstellen der Organisation verwenden. Einmal festgelegt, können Sie kein anderes Konto als Verwaltungskonto wählen. Von diesem Konto aus können Sie andere Konten erstellen, bereits vorhandene Konten zur Teilnahme an der Organisation einladen und Konten aus der Organisation entfernen. Alle Services, die organisationsweit funktionieren, können über das Management-Konto bereitgestellt werden. Wenn Sie jedoch eine Aufgabentrennung wünschen und das Management-Konto entlasten möchten, können Sie delegierte Administratorkonten für die verschiedenen AWS-Services festlegen. Über das Verwaltungskonto können Sie auch Richtlinien entweder dem Stamm, einem einzelnen Konto oder einer OU innerhalb der Organisation zuordnen.
Ein Mitgliedskonto ist ein AWS-Konto, das nicht dem Verwaltungskonto angehört, sondern Teil einer Organisation ist. Ein Mitgliedskonto kann jeweils nur zu einer Organisation gehören. Sie können Mitgliedskonten als delegierte Administratorkonten festlegen.
Ein delegierter Administrator ist ein Mitgliedskonto, das vom Managementkonto als Administrator für einen oder mehrere AWS-Services oder für AWS-Organisationen bestimmt wurde.
- Delegierter Administrator für einen AWS-Service: Über diese Konten können Sie AWS-Services verwalten, die organisationsweit funktionieren. Diese Konten verfügen über administrative Berechtigungen für einen bestimmten Service sowie über Berechtigungen für AWS-Organisationen mit Lesezugriff.
- Delegierter Administrator für AWS-Organisationen: Über diese Konten können Sie Organisationsrichtlinien verwalten und sie dem Stamm, den OUs oder den Konten innerhalb der Organisation zuordnen. Das Verwaltungskonto kann Delegierungsberechtigungen auf granularen Ebenen steuern.
Es wird dringend empfohlen, die AWS-Services in Mitgliedskonten und nicht im Verwaltungskonto bereitzustellen, da die Sicherheitsfunktionen wie die Servicekontrollrichtlinien der Organisation (SCPs) keine Benutzer oder Rollen im Verwaltungskonto einschränken.
AWS-Services, die in AWS-Organisationen integriert sind
Hier finden Sie eine Liste aller AWS-Services, die mit AWS Organizations zusammenarbeiten müssen:
AWS-Services, die Sie mit AWS Organizations nutzen können
Wenn Sie einen dieser Dienste nutzen möchten, empfiehlt es sich, ihnen über das Verwaltungskonto vertrauenswürdigen Zugriff zu gewähren. Auf diese Weise ermöglichen Sie dem angegebenen AWS-Service, in Ihrem Namen über mehrere Konten in der Organisation hinweg Aktionen durchzuführen. Wenn ein Service vertrauenswürdig wird, kann er in jedem Konto in Ihrer Organisation eine IAM-Rolle erstellen, die als " service-linked role" bezeichnet wird, wenn diese Rolle benötigt wird.
Diese Rolle ermöglicht es dem vertrauenswürdigen Dienst, seine Aufgabe zu erfüllen. Der vertrauenswürdige Dienst erstellt nur dann dienstverknüpfte Rollen, wenn er Verwaltungsaktionen für Konten durchführen muss, und nicht unbedingt für alle Konten der Organisation. Wenn Sie den Dienst nutzen möchten, ohne ihm vertrauenswürdigen Zugriff zu gewähren, müssen Sie alle erforderlichen Initialisierungen und die Erstellung von IAM-Rollen verwalten.
Wenn Sie beispielsweise AWS Backup verwenden möchten, um eine organisationsweite Sicherungsrichtlinie zu erstellen, die Sie nur einer der OUs in der Organisation zuordnen möchten, müssen Sie Backup vertrauenswürdigen Zugriff gewähren. Dadurch wird eine mit dem Dienst verknüpfte Rolle im Verwaltungskonto erstellt. Wenn Sie die Richtlinie auf die angegebenen Konten anwenden, wird dieselbe Service-verknüpfte IAM-Rolle automatisch nur in diesen Konten erstellt. Dadurch kann AWS Backup auch in diesen Konten arbeiten.
Sie können den vertrauenswürdigen Zugriff direkt in der AWS Organizations-Konsole im Verwaltungskonto aktivieren/deaktivieren, aber es wird dringend empfohlen, dies in der Konsole des zu verwendenden Dienstes oder mit den entsprechenden AWS CLI- oder API-Vorgängen zu tun. Auf diese Weise kann der vertrauenswürdige Service bei der Aktivierung des vertrauenswürdigen Zugriffs alle erforderlichen Initialisierungen durchführen, wie z. B. die Erstellung aller erforderlichen Ressourcen und die Bereinigung von Ressourcen bei der Deaktivierung des vertrauenswürdigen Zugriffs.
Beauftragter Administrator für AWS-Services
Standardmäßig können alle Services, die unternehmensweit genutzt werden können, nur im Verwaltungskonto bereitgestellt werden. Wie bereits erwähnt, empfiehlt es sich jedoch, die Verwaltung der AWS-Services nicht über das Verwaltungskonto laufen zu lassen. Dazu müssen Sie für jeden Service Administratorkonten delegieren. Sie sollten in der AWS-Dokumentation nachsehen, wie viele Konten als Administratoren für die einzelnen Services zugewiesen werden können.
Indem Sie ein Mitgliedskonto als delegierten Administrator für einen AWS-Service registrieren, geben Sie diesem Konto einige administrative Berechtigungen für diesen Service sowie Berechtigungen für schreibgeschützte Aktionen von AWS Organizations. Außerdem müssen Sie zunächst den vertrauenswürdigen Zugriff für den Service aktivieren, für den Sie einen delegierten Administrator erstellen möchten.
Um das Beispiel mit AWS Backup zu verwenden: Wenn Sie den vertrauenswürdigen Zugriff aktivieren, können Sie eine Sicherungsrichtlinie im Verwaltungskonto bereitstellen, das in der Lage ist, Sicherungen in Mitgliedskonten zu erstellen. Wenn Sie jedoch ein anderes Konto als delegierten Administrator für AWS Backup aktivieren, können Sie die Sicherungsrichtlinie in diesem Konto bereitstellen und sie von dort aus verwalten.
Ressourcenbasierte Delegationspolitik
Manchmal müssen einige der Services, die mit AWS Organizations arbeiten, AWS Organizations API-Aktionen ausführen (z. B. organizations: AttachPolicy, organizations: ListAccounts). Zum Beispiel benötigt der AWS Backup Service Berechtigungen wie organizations: CreatePolicy und organizations: AttachPolicy. Um diese Berechtigungen zu erteilen, müssen Sie eine ressourcenbasierte Delegierungsrichtlinie im Management-Konto in den Einstellungen des AWS Organization Service erstellen. Dort müssen Sie den Abschnitt Delegierter Administrator für AWS-Organisationen bearbeiten und eine JSON-basierte Richtlinie hinzufügen, die es dem delegierten Administrator erlaubt, diese Aktionen durchzuführen.
CloudFormation Stack-Sets
Wenn Sie AWS Organizations verwenden, wird schnell deutlich, dass Sie Ressourcen für mehr als ein Konto und mehr als eine Region bereitstellen müssen. Wenn Sie viele Konten haben oder einige verschiedene Regionen verwenden (entweder aus Gründen der Compliance oder der Hochverfügbarkeit), kann dies zu einer entmutigenden Aufgabe werden. Wenn Sie CloudFormation bereits als Infrastructure-as-Code-Lösung nutzen, werden Sie es nützlich finden, mit der Verwendung von CloudFormation Stack Sets zu beginnen.
AWS CloudFormation StackSets erweitert die Möglichkeiten von Stacks, da Sie mit einem einzigen Vorgang Stacks für mehrere Konten und AWS-Regionen erstellen/aktualisieren/löschen können. Von einem Administratorkonto aus müssen Sie eine CloudFormation-Vorlage definieren und sie als Grundlage für die Bereitstellung von Stacks in ausgewählten Zielkonten in bestimmten AWS-Regionen verwenden.
CloudFormation StackSets ist ein separater Service, der in der Liste AWS-Services, die mit AWS-Organisationen integriert werden können.
Als solches benötigt es einen vertrauenswürdigen Zugriff, und Sie können ihm einen delegierten Administrator zuweisen. So können Sie Stacksets von Mitgliedskonten in Ihrer Organisation aus bereitstellen.
Wenn Sie den vertrauenswürdigen Zugriff für StackSets aktivieren, können Sie Stack-Instances für Mitgliedskonten in Ihrer Organisation bereitstellen. Sie müssen die erforderlichen AWS Identity and Access Management-Rollen nicht erstellen; StackSets erstellt die IAM-Rolle in jedem Mitgliedskonto in Ihrem Namen.
Sie können bis zu 5 delegierte Administratoren für StackSets zuweisen.
Schlüsselkonzepte von StackSets
Ein Administratorkonto ist das AWS-Konto, in dem Sie StackSets erstellen. Sie können ein StackSet über das AWS-Administratorkonto verwalten, über das Sie das StackSet erstellt haben.
Ein Zielkonto ist das Konto, in dem Sie einen oder mehrere Stapel in Ihrem StackSet erstellen, aktualisieren oder löschen.
Ein StackSet dient als Container für mehrere Stacks, die über bestimmte AWS-Konten und -Regionen bereitgestellt werden. Jeder Stack basiert auf derselben CloudFormation-Vorlage, aber Sie können einzelne Stacks mithilfe von Parametern anpassen.
Eine Stack-Instanz ist ein Verweis auf einen Stack in einem Zielkonto innerhalb einer Region. Eine Stack-Instanz kann auch ohne einen Stack existieren. Wenn der Stack beispielsweise aus irgendeinem Grund nicht erstellt werden konnte, zeigt die Stack-Instanz den Grund für den Fehler bei der Stack-Erstellung an. Eine Stack-Instanz ist nur mit einem StackSet verbunden.
StackSet-Vorgänge
Die folgende Abbildung veranschaulicht die möglichen Stackset-Vorgänge.
Sie erstellen Stacks, indem Sie einen CloudFormation-Vorlagenkörper (welcher Stack in jeder Stack-Instanz bereitgestellt werden soll), die Zielkonten oder -OUs und die Regionen angeben, in denen Sie den Stack bereitstellen möchten.
Sie aktualisieren Stapel, indem Sie die Einstellungen im Vorlagenkörper ändern, Zielkonten hinzufügen/löschen und weitere Regionen hinzufügen/löschen.
Sie können Stapel löschen, indem Sie Zielkonten und Regionen entfernen. Wenn Sie die Option Stapel beibehalten wählen, können Sie einen Stapel aus Ihrem Stapelsatz entfernen und separat verwalten.
Sie können Ihr StackSet nur löschen, wenn es keine Stack-Instanzen mehr enthält.
Jede Stack-Instanz hat einen Statuscode. Sie können die Bedeutung der einzelnen Statuscodes hier überprüfen: Statuscodes für Stack-Instanzen.
Der Statuscode für eine Stack-Instanz wird in der StackSets-Konsole angezeigt > Wählen Sie Ihr Stackset > Registerkarte Stack-Instanzen. Wenn sich eine Stack-Instanz beispielsweise im Status INOPERABLE befindet, müssen Sie unter Umständen die Ursache ermitteln und die Instanz manuell löschen, um Ihr StackSet weiter zu aktualisieren.
Berechtigungsmodelle für StackSets
Es gibt zwei Genehmigungsmodelle für Stacksets - dienstverwaltet und selbstverwaltet. Jedes dieser Modelle bringt seine eigenen Einschränkungen und Überlegungen mit sich und ist in verschiedenen Anwendungsfällen nützlich. Wir werden auf jedes dieser Modelle gesondert eingehen.
Service-verwaltete Stack-Sets
Mit Service-verwalteten Berechtigungen können Sie Stack-Instances für Konten bereitstellen, die von AWS-Organisationen verwaltet werden. Mit diesem Berechtigungsmodell müssen Sie die erforderlichen IAM-Rollen nicht erstellen; StackSets erstellt die IAM-Rollen in Ihrem Namen. Mit diesem Modell können Sie auch automatische Bereitstellungen für Konten aktivieren, die Sie in Zukunft zu Ihrer Organisation hinzufügen.
Bevor Sie ein serviceverwaltetes Stackset einrichten, müssen Sie sich über einige Aspekte im Klaren sein. Einige der wichtigsten davon sind:
- Stapelsätze mit diesem Berechtigungsmodell werden im Verwaltungskonto erstellt, auch wenn sie von den delegierten Administratoren erstellt werden.
- CloudFormation stellt keine Stacks für das Verwaltungskonto der Organisation bereit, selbst wenn sich das Verwaltungskonto in Ihrer Organisation oder in einer OU in Ihrer Organisation befindet.
- Bei dienstverwalteten Stacksets müssen Sie eine OU oder die gesamte Organisation anvisieren. Sie können sowohl Konten als auch OUs anvisieren, indem Sie die Eigenschaft AccountFilterType verwenden. Sie hat die folgenden Werte:
- INTERSECTION: StackSet wird auf den in der Eigenschaft Accounts angegebenen Konten bereitgestellt.
- UNTERSCHIED: StackSet wird in der OU eingesetzt, wobei die in der Eigenschaft Accounts angegebenen Konten ausgeschlossen werden.
- UNION: StackSet wird für die OU und die in der Eigenschaft Accounts angegebenen Konten bereitgestellt.
UNION wird jedoch nicht für Erstellungsvorgänge unterstützt, wenn StackSet als Ressource oder die CreateStackInstances-API verwendet wird. Wenn dies der Fall ist und Sie einige Ressourcen in allen Konten, einschließlich des Verwaltungskontos, bereitstellen möchten, ist es unmöglich, dies mit einem nur vom Dienst verwalteten Stackset zu erreichen. Sie müssen dann ein selbst verwaltetes Stackset verwenden, das wir später in diesem Beitrag behandeln.
Hier ist ein Beispiel für eine CloudFormation-Vorlage, die einen serviceverwalteten Stackset erstellt, der AWS Config Recorder und Delivery Channel in allen Mitgliedskonten in den folgenden Regionen bereitstellt: eu-central-1 und eu-west-1.
Resources:
ConfigStackSet:
Type: AWS::CloudFormation::StackSet
Properties:
StackSetName: ConfigStackSet
Description: StackSet to deploy AWS Config recorder and delivery channel in each acc
ount in each region.
PermissionMode: SERVICE_MANAGED
Parameters:
- ParameterKey: ConfigBucketName
ParameterValue: <configBucketName>
AutoDeployment:
Enabled: true
RetainStacksOnAccountRemoval: false
ManagedExecution:
Active: true
StackInstancesGroup:
- DeploymentTargets:
OrganizationalUnitIds:
- <RootID>
Regions:
- eu-central-1
- eu-west-1
CallAs: DELEGATED_ADMIN
TemplateBody: |
Parameters:
ConfigBucketName:
Type: String
Description: The S3 bucket for AWS Config.
Resources:
ConfigDeliveryChannel:
Type: AWS::Config::DeliveryChannel
Properties:
Name: ConfigDeliveryChannel
S3BucketName: !Ref ConfigBucketName
ConfigRecorder:
Type: AWS::Config::ConfigurationRecorder
Properties:
Name: ConfigRecorder
RoleARN:
Fn::Sub:
"arn:${AWS::Partition}:iam::${AWS::AccountId}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig"In diesem Beispiel eines als Service verwalteten Stapelsatzes wird AWS Config in allen Konten (außer dem Verwaltungskonto) in den angegebenen Regionen bereitgestellt.
Einige wichtige Hinweise:
- Wenn Sie einen Stackset über den delegierten Administrator für StackSets erstellen, sollten Sie diese Eigenschaft verwenden: CallAs: DELEGATED_ADMIN .
- Die Eigenschaft AutoDeployment kann nur verwendet werden, wenn das Berechtigungsmodell SERVICE_MANAGED lautet. Sie können angeben, ob für neu hinzugefügte Mitgliedskonten automatisch eine Stack-Instanz erstellt werden soll und ob Stacks beim Entfernen von Konten beibehalten werden sollen.
- Beim Erstellen eines dienstverwalteten Stapelsets müssen Sie die Eigenschaft OrganizationalUnitIds angeben.
Selbstverwaltete Stack-Sets
Mit dienstverwalteten Stapelsätzen können Sie nicht immer auf bestimmte Konten abzielen, sondern nur auf OUs und die gesamte Organisation. Wenn Sie ein bestimmtes Konto anvisieren möchten und keine dienstverwalteten Stacksets verwenden können, sind selbstverwaltete Stacksets sehr nützlich. Selbstverwaltete Stacksets sind jedoch mit einer Reihe neuer Einschränkungen verbunden. Während dienstverwaltete Stacksets alle erforderlichen IAM-Rollen erstellen, müssen Sie sich bei selbstverwalteten Stacksets selbst darum kümmern.
Ausführungs- und Verwaltungsrollen
Um ein selbstverwaltetes Stackset bereitzustellen, benötigen Sie zwei Arten von IAM-Rollen: Ausführungs- und Verwaltungsrollen.
Im Administratorkonto müssen Sie eine IAM-Rolle namens AWSCloudFormationStackSetAdministrationRole erstellen. Sie können die Rolle verwenden, die die Amazon-Dokumentation bereitstellt:
Resources:
AdministrationRole:
Type: AWS::IAM::Role
Properties:
RoleName: !Ref AdministrationRoleName
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service: cloudformation.amazonaws.com
Action:
- sts:AssumeRole
Path: /
Policies:
- PolicyName: AssumeRole-AWSCloudFormationStackSetExecutionRole
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- sts:AssumeRole
Resource:
- !Sub 'arn:*:iam::*:role/${ExecutionRoleName}'Diese Rolle wird von CloudFormation im Administratorkonto übernommen, und es ist erlaubt, die Ausführungsrolle in jedem Zielkonto zu übernehmen. Die Ausführungsrolle ist diejenige, die über die tatsächlichen Berechtigungen zum Erstellen/Aktualisieren/Löschen von AWS-Ressourcen im Zielkonto verfügt.
In jedem Zielkonto müssen Sie eine Dienstrolle namens AWSCloudFormationStackSetExecutionRole erstellen, die dem Administratorkonto vertraut. Die Rolle muss genau diesen Namen haben.
In der Amazon-Dokumentation wird die folgende Rolle beschrieben:
Resources:
ExecutionRole:
Type: AWS::IAM::Role
Properties:
RoleName: !Ref ExecutionRoleName
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
AWS:
- !Ref AdministratorAccountId
Action:
- sts:AssumeRole
Path: /
ManagedPolicyArns:
- !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccessDie Service-Rolle des Zielkontos erfordert die Berechtigung zur Durchführung aller Vorgänge, die in Ihrer CloudFormation-Vorlage angegeben sind. Ihr Zielkonto benötigt immer die vollständigen CloudFormation-Berechtigungen, einschließlich der Berechtigungen zum Erstellen, Aktualisieren, Löschen und Beschreiben von Stacks.
Beachten Sie, dass diese Vorlage Administratorzugriff gewährt. Nachdem Sie die Vorlage verwendet haben, um eine Ausführungsrolle für ein Zielkonto zu erstellen, müssen Sie die Berechtigungen in der Richtlinienanweisung auf die Ressourcentypen ausdehnen, die Sie mithilfe von StackSets erstellen.
Da wir nun wissen, welche IAM-Rollen wir benötigen, sehen wir uns ein Beispiel für eine selbstverwaltete Stackset-Vorlage an, die SNS-Themen in nur einem Konto, aber in verschiedenen Regionen bereitstellt. (SNS-Themen können kontoübergreifend, aber nicht regionenübergreifend eingesetzt werden.)
In dieser Vorlage haben wir DependsOn: StackSetAdministrationRole hinzugefügt, da selbstverwalteten Stacksets Ausführungs- und Verwaltungsrollen zugewiesen werden müssen.
Resources:
SNSStackSet:
Type: AWS::CloudFormation::StackSet
DependsOn: StackSetAdministrationRole
Properties:
StackSetName: SNSStackSet
Description: StackSet to deploy SNS Topics in different regions.
PermissionModel: SELF_MANAGED
AdministrationRoleARN: <stacksetAdminRoleArn>
ExecutionRoleName: <stacksetExecRoleName>
Parameters:
- ParameterKey: SnsKmsKeyArn
ParameterValue: <snsKmsKeyArn>
ManagedExecution:
Active: true
StackInstancesGroup:
- DeploymentTargets:
Accounts:
- <target account ID>
Regions:
- eu-central-1
- eu-west-1
TemplateBody: |
Parameters:
SnsKmsKeyArn:
Type: String
Description: The KMS key for encrypting the SNS topic.
Resources:
SNSTopic:
Type: AWS::SNS::Topic
Properties:
TopicName: !Sub "Notifications-${AWS::Region}"
KmsMasterKeyId: !Ref SnsKmsKeyArnIm Gegensatz zu dienstverwalteten Stacksets, bei denen Sie die Eigenschaft OrganizationalUnitIds verwenden müssen, müssen Sie bei selbstverwalteten Stacksets entweder die Eigenschaft Accounts oder AccountsUrl angeben, aber nicht beide.
Da selbstverwaltete Stacksets auf bestimmte Konten ausgerichtet sind, ist die Eigenschaft AutoDeployment hier nicht anwendbar und wird daher nicht verwendet.
Es gibt zwei Eigenschaften der StackSet-Ressource, die wir in diesen Beispielen noch nicht gesehen haben. Eine davon ist die Eigenschaft Capabilities. Sie kann die folgenden Werte annehmen: CAPABILITY_IAM oder CAPABILITY_NAMED_IAM. Wenn Ihre Vorlage IAM-Ressourcen enthält, können Sie beide Fähigkeiten angeben. Wenn Ihre Vorlage benutzerdefinierte Namen für IAM-Ressourcen enthält, müssen Sie CAPABILITY_NAMED_IAM angeben.
Die andere ist die Eigenschaft OperationPreferences. Mit ihr können Sie Ihre Präferenzen für die folgenden Optionen angeben, wie CloudFormation einen StackSet-Vorgang durchführen soll:
- GleichzeitigkeitModus
- FailureToleranceCount
- FehlerToleranzProzentsatz
- MaxConcurrentCount
- MaxConcurrentPercentag
- RegionConcurrencyType
- RegionOrder
Schlussfolgerung
CloudFormation StackSets ist ein leistungsstarker Service für die Bereitstellung einer einheitlichen Infrastruktur über mehrere AWS-Konten und -Regionen hinweg. Wie viele AWS-Tools hat es seine eigenen Besonderheiten - und die Wahl zwischen serviceverwalteten und selbstverwalteten StackSets hängt von Ihrem Anwendungsfall ab.
- Mit serviceverwalteten StackSets können Sie OUs oder die gesamte Organisation anvisieren, automatisch neue Konten einbeziehen und die IAM-Rollenverwaltung von AWS übernehmen lassen - aber sie können nicht für das Managementkonto bereitgestellt werden.
- Bei selbstverwalteten StackSets müssen Sie Konten explizit anvisieren und IAM-Rollen selbst einrichten, aber sie bieten mehr Flexibilität, einschließlich der Möglichkeit, für das Verwaltungskonto bereitzustellen.
Wenn Sie diese Unterschiede verstehen und sie mit Ihrer Organisationsstruktur abstimmen, können Sie das richtige Gleichgewicht zwischen Automatisierung und Kontrolle finden. Zusammen mit AWS Organizations bieten Ihnen StackSets die Skalierbarkeit und Konsistenz, die Sie für die Verwaltung der Infrastruktur in einer großen AWS-Umgebung mit mehreren Konten benötigen, um den manuellen Aufwand zu reduzieren und gleichzeitig die Sicherheit und Governance zu verbessern.
Weitere Informationen zu CloudFormation finden Sie in unserem Blog: Infrastructure as Code auf AWS: Eine Einführung in CloudFormation.