AWS Foundational Architecture

When building a house, the most important thing to get right is the foundations. With out a good foundation everything that is built on top will have issues and, worse case, completely fail. Building IT solutions is no different. We have to ensure the basic foundations are in place in order to build good solutions for the business we are working for.

Often I see organizations trying to implement the foundations once they have built the first few systems or they realize that "this cloud craze is real". Many times it is after a proof of concept has suddenly become a production system. What ever the reason for the delay it always causes rework, at a cost to the business, and can cause friction or resentment from engineers who implemented the first solutions.

What are the foundations?

For me there are three core areas to consider when planning your AWS estate. Security, Process and Standards. Together these determine how you will manage your AWS estate from both account and solution perspectives.

Decisions made in each area have an affect on the other so can not be taken in isolation. There will never be a single solution that fits all organizations but the following guidance should give enough for you to think about and start you on the right journey.

Security

One of the most important thing to consider is the security of your AWS landscapes. This includes the management of the accounts as well as the solutions deployed. Some of the items to consider when planning your accounts are:

• Account/Organization Structure;
  • Central Accounts such as Logging and Security Services
  • Production vs Non-Production
  • Business Domains
• Regions to be used;
• Services to be used.
• Network Security;
  • Central ingress / egress
  • Proxies
  • On-Premise Networking

When thinking about security it is important that whilst maintaining organizational standards any practices or solutions which are not suitable for the cloud are modified or replaced. In addition, whilst ensuring compliance and governance is in place, security need to adapt and flex to changes in the cloud. As features such as scaling or automation become easier it is critical that security is maintained while not restricting the benefits of the cloud.

Process

A lot of engineers like to think that moving to the cloud and an agile mindset means that processes don't matter. In my view this is the wrong assumption to make. Although things can be done faster does not mean that processes can be ignored. Often the issue is that engineers and developer see processes written for traditional infrastructure as irrelevant or to cumbersome so ignore them.

As part of a migration to the cloud organizations need to review processes and their relevance to new technology and project methodologies. By ensuring processes are fit for purpose they are more likely to be adhered to.

It is also important to call out that there may be a need for new processes as you move to the cloud. As an example, in the past items such as hardware and software purchases often had to be completed in a central procurement system. With the ability for people to purchase software and hardware commitments directly with AWS new processes will have to be created to determine who and how these components are purchased.

Standards

Creating good standards and reference architectures at the start of a cloud implementation will help in multiple areas and drastically improve quality and speed to delivery.

Often with cloud deployments it becomes a bit like the wild-west with different engineers and developers implementing different designs for the same solution. By standardizing these it makes it easier for new joiners to understand, quicker to deploy using pre-agreed templates, and simpler to support with common runbooks and automations.

The basic items to consider in cloud standards are things such as: technology stack (OS, Code Language, DevOps Tooling), whether self hosted or platform as a service (PaaS) is preferred, network topology and connectivity. By agreeing and designing these up front a lot of the authority can then be delegated to teams to use these standards to design their solutions.