Work with the Amazon organization.
In this article, we will try to consider how the approach to working with the organization has changed and how to understand which service should be used correctly and at what level. This is definitely important, because as we know from the previous article, by migrating “as is” we can create more problems, due to a lack of understanding at which level of abstraction, which challenges should be solved.
The approach to working with Amazon was not easy anyway. We already know that historically Amazon made services, and with this service as a brick, you could build your system of any complexity. And at some point, there were more than 200 of these bricks.
Therefore, Amazon is fully aware of its weakest point, namely the high entry threshold. Amazon tried to simplify it by using all kinds of wizards, free webinars, open access to knowledge bases and promotion of best practices, and templates for the use and deployment of the project without thinking about the meaning and function of each service. It certainly made life easier for modern businesses. And as a result, describing infrastructure in Terraform templates has become almost the main tool for deploying infrastructure.
As a result, Amazon has significantly increased the number of customers, which is a profit for the business. But at the same time, they significantly lowered the average awareness quotient and the understanding of what people generally do. It’s like a Cyber Monday sale when everyone buys apps, and the proportion of people who buys the product increases. But do they use them? — we know the answer)
In the same way, a business that easily started on Amazon mistakenly thinks that it can be transformed just as easily, without the need to change something and implement processes at all levels of abstraction of the organization. Such a business makes critical mistakes. As a result, they blame the cloud providers they use. Thus, they go just as easily to other cloud providers that promise to do everything for them and go from the IaaS model to the conditional SaaS. Here you can make a transparent hint by comparing Azure Cosmos DB as a mega convenient silver bullet for business and the huge number of risks and security problems resulting from the popularity of this service. And it’s not over. The issues of security, planning, and architecture have to be decided by someone. However, if you transfer this responsibility to the vendor, the result, most likely, will not be as good as if you did everything yourself.
Returning to Amazon, we see what the provider is trying to do to offer new services that allow you to holistically control security issues for your organization.
That’s what we’ll talk about next.
But classic services are still there. Well, there is no computing at the organization level. All what the organization level services can offer is control.
Amazon understands the user’s demand for infrastructure provisioning simplification. This request arises on project level. To meet it, LightSail service was introduced. Working within an organization, we can use this service on a project level without need to address dedicated experts to deploy infrastructure.
But this is different from the approach that the enterprise should pay attention to. The enterprise needs to go out and position itself precisely at the level of the organization, giving the right to choose services for purchase to specific projects.
The right services to solve the right demand.
The trick in choosing services for the end user is that you should not choose from the available services, considering all the possibilities and connections of the services. Instead, you should clearly define what exactly you want to achieve, and ground your services selection on that. The best way to do this is decomposing your projects into the same layers of abstraction where the main services provided by any cloud should be distinguished.
Let’s get back to the classic cloud scheme again.
Here we see such basic services that allow us to understand any cloud from the basic service model point of view, according to the definition.
Dashboard. In fact, at this level, we choose a convenient provider based on the interaction interface convenience. Therefore, this issue does not affect the choice of services, and most cloud providers at the enterprise level are used at the level of IaC and Cloud API interaction.
Computing (Virtual). We are talking about any computing load here. Accordingly, everything from IaaS, CaaS, and FaaS.
We should carefully choose types, architectures, and other details, after we decide on the type of load to build the architecture of the entire application.
Networking. This identifies the way we will build interconnection, what tools we have, and what will be the basic service to ensure the isolation of resources at the network level.
AWS VPC is the basis of Amazon’s architecture, and features of interservice interaction will be built from the features of this service in the future.
Shared File System. A file system that can be used simultaneously on several virtual machines.
Block Storage. A file storage service where you get the possibility of non-competitive mounting of a disk to a virtual machine. In effect, allowing it to be used as a bootable volume.
Image Storage. The read-only file system that is necessary for the accelerated creation of virtual machines by copying the content to the block device of the newly created instance.
I have a more detailed article with the features of this service and working with it
Object Storage. The files are available via the link. Allows to work with objects and their life cycle. Under certain restrictions, it is possible to work with a full-fledged FUSE file system.
Orchestration. A system of automated provisioning and management of the cloud resources life cycle.
Here we should recall the definition of orchestration, as “the management of automation to obtain different values”.
Telemetry. Collecting data about resources and working with events and deliveries.
Identity. Manage and delimit access of resource and account level policies.
As you can see, for the basic planning of infrastructure transformation, we no longer need 200+ services, but it is enough to limit ourselves to 15. And this is with a margin because the first issue of migration that engineers will need to solve is architectural and network transformation, which is why so many services are provided. And yes, each service has many features and related services. But there is already a complete picture of what we are building and what should be used.
Data security control
Classical account security, VPC, is the area of responsibility of an engineer who is directly responsible for the deployment process and infrastructure support. When CI/CD and IaC arise, the need to separate SRE and DevOps first arises. Here, the size of the project team is important. That is, it can easily be only one person responsible for both aspects. Still, the tasks of the security champion or SecOps, in general, should be solved by a layer of abstraction above, that is, at the level of the organization.
What does Amazon give us for this? Of course, at the first stage, Amazon allowed you to enable a certain layer of security for each service due to perimeter control (which is why the VPC service is the basis of modern security), and an authorization and authentication control layer (IAM). Then it is already atomic for each service to enable encryption for data at rest or transit. Next, we talk about services for working with keys (KMS), secrets (SSM), parameters (Parameter store), certificates (ACM), and so on. Gradually climbing up the layers of abstraction above. The last step in this security concept is the System Manager.
That is, we see a full range of services for data provisioning of the final project at the level of the same project. More over, the project itself is in fact split by the mentioned purpose-based layers: the infrastructure to be deployed, CI/CD and IaC, security control.
There is no need to try to solve these issues at the level of the organization because “a separate layer is mainly considered as a single self-sufficient whole.”
User security control Access control Transformation of the organization’s work using Amazon Technologies
Which transformations and controls are left for implementation at the organizational level?
All the questions are the same, but Amazon allows us to solve them at the very abstraction layer where it is necessary.
Manage your AWS accounts. We can create, manage, and apply configuration templates to accounts.
Define and manage your organization. We can manage and configure access policies to any service APIs atomically and hierarchically for the entire organization.
Secure and monitor your accounts. Most audit and behavior control services receive centralized management. New services allow us to organize and analyse the data that we will receive in this way. This approach, in turn, makes it possible to simplify the configuration requirements at the account level, but one should remember that the responsibility remains within the projects. In such a way, we solve problems of another, higher level of abstraction.
Control access and permissions. According to the needs of organizations, AWS SSO-level services have been transformed to a level where this service can be perceived as a certain replacement for a full-fledged provider identity.
Share resources across accounts. The same applies to permissions and access to resources; the identifier of the organization, organizational unit, which can be used to control access, has appeared.
Audit your environment for compliance. CloudTrail is configured in a centralized way, AWS Backup is allowed to collect and make backup copies of the entire configuration and data at the level of the organization by accounts. AWS Config can now transparently change the configuration and offer optimizations for the accounts in the organization.
Centrally manage billing and costs. The organization’s tasks, accordingly, entail solving the issue of centralized billing, optimizations, and analysis of usage.
If the organization is a set of tools for managing organization-level services, then the automation of organization-level service management has resulted into the AWS Control Tower service. Now, it allows us to solve DevOps and SecOps tasks for all accounts.
The AWS Control Tower operates the following features:
Landing Zone. Although it used to be an account-focused service, now it is a service feature operation on the organization level. It allows to propagate changes across all accounts within an organization.
Account Factory. Enables automatic creation and configuration of accounts according to predefined configurations and templates
Preventive and Detective Guardrails. A set of rules for all security services available within the organization. For automatic deployment and configuration.
Mandatory and Optional Guardrails. Account and resource security management at the organization level
Dashboard. A centralized access point for security management and auditing. A wizard enabling easy access to each service.
Solutions for AWS Control Tower in AWS Marketplace is a central feature because Amazon understands that they are only a business partner, and they do not decide how you should conduct and build your architecture.
Therefore, most of the security and compliance services presented in the AWS Marketplace have a direct integration with the organization. We can see them as another service on our dashboard.
Having considered the controls at the organizational level, we have a clear vision of which controls we have covered and which are delegated to the project level. And here the main thing is not to take too much, because in the future it can become a blocker for business in general. In the next article, we will consider examples and solving problems at the organization level, which controls are delegated from the project level and what it makes sense to work with centrally.
