A New Hope: A Beginner’s Guide to the Cloud Journey

This is the second article in a two-part series on how to get started with cloud, equipped with the right tools you’ll need for the journey. In our first article (find it here ICYMI), we shared a high-level view of the elements needed for a successful journey – from mindset to technologies. Today, we’ll dive deeper into five key foundational cloud elements that should be in place to facilitate successful cloud initiatives, adding details around each, our suggested acceptance criteria, and how our repeatable epics help provide best practice guard rails and the ability to speed time to value. 

Landing Zone 

The very first element to cover is Build Cloud Foundations (BCF). The core reason for its existence is to create a base, secure landing zone with an AWS account structure. These account structures are designed with cloud best practices and hardened with CIS benchmark controls and an alerting mechanism. Use of cloud-native security tools is built-in with AWS Security Hub, Amazon GuardDuty, and AWS Config to detect guardrail changes and notify InfoSec teams to take corrective actions.  

Like BCF, a best practice landing zone should focus on automation and infrastructure as code (IaC) to allow for repeatability and make it possible to quickly make changes while reducing risk caused by human error. Our acceptance criteria for this element includes:   

• Base accounts and regions within those accounts, are created and AWS Control Tower is setup to automatically harden new AWS accounts so that clients can ensure quick, consistent and compliant account creation. 
  
  
• Security logging is enabled to the audit account so that logs are available for security and compliance teams. Services sending logs include AWS CloudTrail, VPC Flow Logs and AWS Config. 
  
  
• Code is stored in the AWS CodeCommit repository so that the operator can make changes using code to retain highly repeatable deployment. 
  
  
• Standard VPC template is installed following AWS best practices so that network security is consistent and provides network isolation. 
  
  
• AWS Config change logs are provided for infrastructure changes to support traceability and strengthen compliance. 
  
  
• AWS Security Hub and Amazon GuardDuty are deployed so that security teams have full visibility across audit, log archive, sandbox, non-prod, prod and any other accounts. 
  
  
• Amazon Simple Notification Service (Amazon SNS) topics are deployed to detect guardrail changes so that the security team is notified and corrective action can be taken. 
  
  
• Knowledge transfer is provided so that operators can understand Git 101 – AWS CodeCommit, security governance and compliance, network and internal DNS, metrics and monitoring, logging and disaster recovery.

Robust CI/CD framework 

Once a landing zone is built with the foundational services needed to operate in the cloud, a robust continuous integration and continuous delivery (CI/CD) framework should follow. The framework should include automation pipelines for provisioning and updating the infrastructure, and changes should be managed in code and deployed through auto or manual approvals depending on your cloud maturity model. All future deployments will then be managed through the CI/CD tool/framework. Things to look for in a robust CI/CD framework include: 

• A foundation for DevOps automation with Jenkins and a running platform for factories such as account, Amazon Virtual Private Cloud (VPC), Amazon Machine Image (AMI), infrastructure and application. 
  
  
• Factories should be setup so that the ability to improve the management and security of the AWS environment is enabled. 
  
  
• Factories implement a foundation of best practices so that they can be reused for faster time to market. 
  
  
• Knowledge transfer provided so that you can use and add to the Jenkins automated workflow. 

Image: Example sequence of repeatable epics 

Network foundation and VPC factory 

With a tool in place to manage the provisioning of infrastructure, next we need to establish foundational networking in AWS with the deployment of AWS Transit Gateway and routing logic necessary for application workflows. However, there is a cloud complexity twist to this. Every time a new VPC is created we want to ensure that it is joined to the client’s core AWS network environment.  

Here included in the work is the refactored VPC factory that would auto associate a newly built VPC to the existing core network for transitive routing/data flow. Our acceptance criterion include: 

• AWS Transit Gateway deployed as IaC through a self-service portal in AWS Service Catalog so that it is a highly repeatable and user convenient process 
  
  
• VPC factory that is available in the AWS Service Catalog so that teams can deploy a compliant VPC solution and provide network security based on AWS best practices  
  
  
• VPCs that automatically connect to AWS Transit Gateway based on VPC tags so that operation overhead is minimized 

Hybrid networking 

In addition to these steps, it’s critical to have a secure network established between AWS and the company’s offices. This work entails establishing a connection with the company's main offices through what we call hybrid networking, DNS, and Active Directory (AD) forest extensions. This will allow end-user teams working from remote offices to access AWS deployed resources and vice versa for AWS resources reaching back to remote offices, e.g., IoT devices onsite sending their data to AWS workload.  

Our recommended AWS hybrid network acceptance criteria include:  

• AWS site-to-site VPN tunnels between AWS Transit Gateway and on-premise is established so that data can be moved between the two sides through secure and private connections  
  
  
• AWS Direct Connect Gateway is attached to AWS Transit Gateway so that data can be moved between the AWS and on-premise sides through fiber high-speed private connection  
  
  
• AWS Transit Gateway routing is configured so that traffic can reach the on-premise network  
  
  
• VPN tunnel is configured as a backup connection so that connection between AWS and on-premise DC is redundant 
  

Identity store 

The last recommended step in the process is to extend the AD Forest into AWS. The criteria we expect for this step are:  

• AWS Directory Service is in use so that the on-premise AD can be extended 
  
  
• On-premise AD forest is extended to AWS so that users use AD credentials to gain access to AWS environments  
  
  
• DNS is resolved to on-prem AD so that resources have DNS resolution. 
  
  

In addition, the AWS hybrid DNS should ensure that:  

• Amazon Route 53 Resolver is deployed using IaC so that internal DNS resolution service exists in AWS 
  
  
• Resources in AWS should also resolve DNS for AWS and on-premise resources so that client application workloads in AWS can communicate with on-premise resources using domain names 
  
  
• On-premise resources should resolve DNS for resources deployed in AWS so that the on-premise application workloads can communicate with AWS resources using domain names. 
  
  

While these five elements are important to a strong start in the cloud, the cloud journey is comprised of many steps and the work doesn’t stop here. As Pink Floyd says, “And when at last the work is done, Don't sit down, it's time to dig another one”.  There will always be more work involved in creating patterns for workloads, setting up multiple environments for various stages of the application’s life in terms of development, staging, production, and more including igrating workloads from on-premise to the cloud. When you think of all work as an iterative process, you constantly review and inspect to adapt and create a new normal. 

Interested in continuous learning and improvement based on best practice repeatable epics like these? Learn more and reach out to our team today.