Relevance Lab helps Organizations to build & adopt AWS Best Practices. Click here for the full story.
For Large Enterprise and SMBs with multiple AWS accounts, monitoring and managing multi-accounts is a huge challenge as these are managed across multiple teams running too few hundreds in some organizations.
AWS Control Tower helps Organizations set up, manage, monitor, and govern a secured multi-account using AWS best practices.
Benefits of AWS Control Tower:
- Automate the setup of multiple AWS environments in few clicks with AWS best practices
- Enforce governance and compliance using guardrails
- Centralized logging and policy management
- Simplified workflows for standardized account provisioning
- Perform Security Audits using Identity & Access Management
Features of AWS Control Tower:
a) AWS Control Tower automates the setup of a new landing zone which includes,
- Creating a multi-account environment using AWS Organizations
- Identity management using AWS Single Sign-On (SSO) default directory
- Federated access to accounts using AWS SSO Centralized logging from AWS CloudTrail, and AWS Config stored in Amazon S3
- Enable cross-account security audits using AWS IAM and AWS SSO
b) Account Factory
- This helps to automate the provisioning of new accounts in the organization.
- A configurable account template that helps to standardize the provisioning of new accounts with pre-approved account configurations.
- Pre-bundled governance rules for security, operations, and compliance which can be applied to Organization Units or a specific group of accounts.
- Preventive Guardrails – Prevent policy violations through enforcement. Implemented using AWS CloudFormation and Service Control Policies
- Detective Guardrails – Detect policy violations and alert in the dashboard using AWS Config rules
d) 3 types of Guidance (Applied on Guardrails)
- Mandatory Guardrails – Always Enforced. Enabled by default on landing zone creation.
- Strongly recommended Guardrails – Enforce best practices for wel-architected, multi-account environments. Not enabled by default on landing zone creation.
- Elective guardrails – To track actions that are restricted. Not enabled by default on landing zone creation.
- Gives complete visibility of the AWS Environment
- Can view the number of OUs (Organization Units) and accounts provisioned
- Guardrails enabled
- Check the list of non-compliant resources based on guardrails enabled.
Steps to setup AWS CT:
Setting up a Control Tower on a new account is relatively simpler when compared to setting it up on an existing account. Once Control Tower is set up, the landing zone should have the following.
- 2 Organizational Units
- 3 accounts, a master account and isolated accounts for log archive and security audit
- 20 preventive guardrails to enforce policies
- 2 detective guardrails to detect config violations
The next step is to create a new Organizational unit and then create a new account using the account factory and map it to the OU that was created. Once this is done, you can start setting up your resources and any non-compliance starts reflecting in the Noncompliant resources’ dashboard. In addition to this, any deviation to the standard AWS best practices would be reflected in the dashboard.
With many of the organizations opting for and using AWS cloud services, AWS Control Tower with the centralized management service offers the simplest way to set up and govern multiple AWS accounts securely through beneficial features and established best practices. Provisioning new AWS accounts are as simple as clicking a few buttons while agreeing to the organization’s requirements and policies. Relevance Lab can help your organization to build AWS Control Tower and migrate your existing accounts to Control Tower. For a demo of Control Tower usage in your organization click here. For more details please reach out to firstname.lastname@example.org
Using GIT configuration management integration in Application Development to achieve higher velocity and quality when releasing value-added features and products
ServiceNow offers a fantastic platform for developing applications. All infrastructure, security, application management and scaling etc.is taken up by ServiceNow and the application developers can concentrate on their core competencies within their application domain. However, several challenges are faced by companies that are trying to develop applications on ServiceNow and distribute them to multiple customers. In this article, we take a look at some of the challenges and solutions to those challenges.
A typical ServiceNow customization or application is distributed with several of the following elements:
- Update Sets
- Template changes
- Data Migration
- Role creation
- Script changes
Distribution of an application is typically done via an Update Set which captures all the delta changes on top of a wel-known baseline. This base-line could be the base version of a specific ServiceNow release (like Orlando or Madrid) plus a specific patch level for that release. To understand the intricacies of distributing an application we have to first understand the concept of a Global application versus a scoped application.
Typically only applications developed by ServiceNow are in the global scope. However before the Application Scoping feature was released, custom applications also resided in the global scope. This means that other applications can read the application data, make API requests, and change the configuration records.
Scoped applications, which are now the default, are uniquely identified along with their associated artifacts with a namespace identifier. No other application can access the data, configuration records, or the API unless specifically allowed by the application administrator.
While distributing applications, it is easy to do so using update sets if the application has a private scope since there are no challenges with global data dependencies.
The second challenge is with customizations done after distributing an application. There are two possible scenarios.
- An application release has been distributed (let’s call it 1.0).
- Customer-1 needs customization in the application (say a blue button is to be added in Form-1). Now customer 1 has 1.0 + Blue Button change.
- Customer-2 needs different customization (say a red button is to be added in Form-1)
- The application developer has also done some other changes in the application and plans to release the 2.0 version of the application.
Problem-1: If application 2.0 is released and Customer-1 upgrades to that release, they lose the blue-button changes. They have to redo the blue-button change and retest.
Problem-2: If the developer accepts blue button changes into the application and releases 2.0 with blue button changes, when Customer-2 upgrades to 2.0, they have a conflict of their red button change with the blue-button change.
These two problems can be solved by using versioning control using Git. When the application developers want to accept blue button changes into 2.0 release they can use the Git merge feature to merge the commit of Blue button changes from customer-1 repo into their own repo.
When customer-2 needs to upgrade to 2.0 version they use the Stash feature of Git to store their red button changes prior to the upgrade. After the upgrade, they can apply the stashed changes to get the red button changes back into their instance.
The ServiceNow source control integration allows application developers to integrate with a GIT repository to save and manage multiple versions of an application from a non-production instance.
Using the best practices of DevOps and Version Control with Git it is much easier to deliver software applications to multiple customers while dealing with the complexities of customized versions. To know more about ServiceNow application best practices and DevOps feel free to contact: email@example.com