If you’re planning a large-scale AWS deployment, you’re probably wondering how to orchestrate multiple applications and teams on AWS. How do you make sure that every team can access AWS without your accounts turning into sprawling, ungoverned chaos?

Many companies find that a multi-account structure can help meet the unique needs of each application team or business group. But with so many tools and services available in AWS, it can be tough to keep track of everything – especially when you need to enforce security and billing configurations across multiple accounts.

Major control tower features given below:

Landing Zone
AWS Control Tower automates the setup of a new landing zone using best-practices blueprints for identity, federated access, and account structure. Examples of blueprints that are automatically implemented in your landing zone include:
Create a multi-account environment using AWS Organizations
Provide identity management using AWS Single Sign-On (AWS SSO) default directory
Provide federated access to accounts using AWS SSO
Centralize logging from AWS CloudTrail, and AWS Config stored in Amazon Simple Storage Service (Amazon S3)
Enable cross-account security audits using AWS Identity and Access Management (IAM) and AWS SSO
The landing zone set up by AWS Control Tower is managed using a set of mandatory and strongly recommended guardrails, which you select through a self-service console to ensure that accounts and configurations comply with your policies.

Account Factory
The account factory automates provisioning of new accounts in your organization. As a configurable account template, it helps you standardize provisioning of new accounts with pre-approved account configurations. You can configure your account factory with pre-approved network configuration and Region selections, and enable self-service for your builders to configure and provision new accounts using AWS Service Catalog. Additionally, you can take advantage of Control Tower Solutions like Account Factory for Terraform to automate the provisioning and customization of a Control Tower-managed account that meets your business and security policies, before delivering it to end users.

Preventive and Detective Guardrails
Guardrails are pre-packaged governance rules for security, operations, and compliance that you can select and apply enterprise-wide or to specific groups of accounts. A guardrail is expressed in plain English, and enforces a specific governance policy for your AWS environment that can be enabled within an AWS Organizations organizational unit (OU). Each guardrail has two dimensions: it can be either preventive or detective, and it can be either mandatory or optional. Preventive guardrails establish intent and prevent deployment of resources that don’t conform to your policies (for example, ‘Enable AWS CloudTrail in all accounts’). Detective guardrails (for example, ‘Detect whether public read access to Amazon S3 buckets is allowed’) continuously monitor deployed resources for nonconformance. AWS Control Tower automatically translates guardrails into granular AWS policies by:
Establishing a configuration baseline using AWS CloudFormation
Preventing configuration changes of the underlying implementation using service control policies (for preventive guardrails)
Continuously detecting configuration changes through AWS Config rules (for detective guardrails)
Updating guardrail status on the AWS Control Tower dashboard

Mandatory and Optional Guardrails
AWS Control Tower offers a curated set of guardrails based on AWS best practices and common customer policies for governance. You can automatically leverage mandatory guardrails as part of your landing zone setup. Some examples of mandatory guardrails include:
Disallow changes to AWS IAM roles set up by AWS Control Tower and AWS CloudFormation
Detect public read access setting for log archive
Disallow changes to bucket policy for AWS Control Tower created Amazon S3 buckets in log archive
Disallow cross-Region networking
You can also choose to enable optional guardrails at any time. All accounts provisioned under OUs where optional guardrails are enabled will automatically inherit those guardrails. Examples of optional guardrails include:
Detect whether public write access to Amazon S3 buckets is allowed
Detect whether MFA for the root user is enabled
Detect whether encryption is enabled for Amazon EBS volumes attached to Amazon EC2 instances

Dashboard
The AWS Control Tower dashboard gives you continuous visibility into your AWS environment. You can view the number of OUs and accounts provisioned and the number of guardrails enabled, and check the status of your OUs and accounts against those guardrails. You can also see a list of noncompliant resources with respect to enabled guardrails.

Solutions for AWS Control Tower in AWS Marketplace
AWS Marketplace now offers integrated third-party software solutions for AWS Control Tower. Built by independent software vendors, these solutions help solve infrastructure and operational use cases including security for a multi-account environment, centralized networking, operational intelligence, and Security and Information Event Management (SIEM).

AWS SSO can play a very important role for an organization to have a central access, authentication and authorization capacity. Different companies use different authentications for their users. Today I will be sharing about the AWS SSO with Azure Active Directory for Office365. This whole process was initiated by Brain Station 23 system admin team (specially Abdur Rahim) which can be helpful for others.

AWS Single Sign-On (SSO) with Azure Active Directory (AD)

SSO (single sign-on) is an authentication process that allows users to sign into multiple applications with a single set of usernames and passwords.

AWS SSO now provides a directory that you can use to create users, organize them into groups, and set permissions across those groups. You can also grant the users that you create in AWS SSO permissions to applications such as Office 365 and Azure AD.

AWS SSO also helps us manage access and permissions to commonly used third-party software. AWS SSO-integrated applications as well as custom applications that support Security Assertion Markup Language (SAML) 2.0. AWS SSO includes a user portal where your end-users can find and access all their assigned AWS accounts, cloud applications, and custom applications in one place.

Today, we will configure AWS SSO with Azure Active Directory and test our users together. Let’s start!

• Go to AWS Console and select AWS SSO from the console. Select “Enable AWS SSO”.

• Select “Choose your identity source.”

• Choose the external identity provider for your Azure AD. We need to download “AWS SAML metadata” from here. We need it in another step.

• On the Azure Cloud side, we need to create a new app from the Azure AD → Enterprise application→ New application →Create your own Application. When we create an application, we need to select “Integrate any other application you don’t find in the gallery (Non-gallery)”.
  

• After the application creation, it looks like this:

• In our Azure AD application, we need to select “Single sign-on” and set up Single Sign-on with SAML. We should upload the metadata files that we download before from the AWS SSO side.

• After uploading SAML file, identifier and reply URL should be set from the SAML file. If the reply URL is not set, you cannot continue because it is a required field. You can get it from AWS SSO → Settings →Authentication →View details. AWS SSO ACS URL is your reply URL. Save all details here.

• We need to download SAML SSO XML metadata from the Azure side to upload AWS SSO.

• Accept your changes.

• After all these steps, we need to enable automatic provisioning. AWS SSO supports automatic provisioning (synchronization) of user and group information from your identity provider (IdP) into AWS SSO using the System for Cross-domain Identity Management (SCIM) v2.0 protocol. To enable it, we need to select the settings → provisioning part. Copy the SCIM endpoint and access token.

• Paste these credentials to Azure AD and test your connection.

• Now create Group and Add your users to the Group that we have created.

• Start provisioning. You can see the current cycle status. Your Azure AD users should be seen on the AWS SSO side.

• We need to set our access control mechanism for AWS Management Console and AWS CLI side. To do this, we need to assign users to AWS accounts.

• Create a new permission set. We’re using an existing job function policy.

• For example, let’s assume our test user is a developer for AWS. We need to Power User Access.

• After all these, we can use the user portal URL and SSO with your Azure AD credentials (e-mail and password).

• After successful login, we can see AWS console successfully!