About six years ago when I talked with my senior manager at a prior company about the idea of using public cloud services to expand our technology infrastructure, he quickly expressed doubt about the value of the approach.
There were several reasons for his reaction, which he revealed in the following questions:
- How secure is the public cloud?
- Who among our competitors is using public cloud successfully?
- What is the cost to convert existing applications to move them to the public cloud?
At the time there were no clear or convincing answers to these questions, but in the last few years they have been answered loud and clear:
- A typical public cloud deployment can be more secure than a typical on-premise system.
- From the CIA to giant financial firms, all types of companies are using public cloud technologies in some fashion.
- Many positive TCO/ROI benefits have been achieved and reported.
The typical journey to the public cloud proceeds as follows:
- Perform a TCO/ROI analysis for the current deployment vs. a public cloud deployment
- Perform an application assessment for the public cloud migration
- Perform security assessments for your on-premise or trial public cloud deployments
- Build a public cloud infrastructure for deploying your applications and databases
- Migrate your assets to the new public cloud infrastructure
This article talks about that fourth step in your public cloud journey: how to build your public cloud infrastructure. To do this, we take a Minimum Viable Cloud (MVC) approach, working collaboratively with our customer engineers, to build an efficient and secure infrastructure foundation. This joint effort works to decide how and on what to build a cloud infrastructure that meets your specific needs. In these efforts, the MVC approach asks questions, such as:
- What IAM policies and roles will be used to provide access permissions in the cloud?
- How many and what size IP CIDR blocks will be used to build your VPCs?
- What central logging and alerting platform will consolidate your cloud log data?
- How will you connect your on premise systems to the VPCs in the cloud?
- How will you extend your AD/LDAP systems to the cloud with federation support?
- How will you deploy applications that can be mitigated during DDoS attacks?
- How will you secure all your data in-transit and at-rest?
- How will you protect and audit your privileged account access?
This article highlights the key components of a cloud infrastructure, following CTP’s best practices. Our MVC methodology is an agile approach to developing cloud infrastructure, ensuring that components are built iteratively as needed, accelerating time to value. Although this article uses AWS services and terminology, the concept is also applicable to Azure, GCP and other major public cloud service providers.
MVC Use Cases
The cloud environment we create using our MVC methodology allows any enterprise to build a fully functional and scalable public cloud environment, ready to support any enterprise grade application. Migration of applications to the cloud is a complex process. The decision on what will be moved is typically handled by the application assessment process. The result of this exercise gives you a picture of the “first-movers,” for example:
- Modern web services with recently updated OS or web server levels are good candidates for a rehost and technology refresh to the cloud environment. This allows you to now securely deploy modern web applications inside a scalable High Availability and Disaster Recovery (HA-DR) MVC.
- Modern enterprise RDBMS systems can be migrated to AWS RDS or EC2-based databases running in the MVC, with proper access control and monitoring.
- High-cost on-premise big data systems can be re-engineered for deployment in the cloud environment, meeting performance and security requirements, with a huge cost saving.
- On-premise storage systems, such as NFS files, iSCSI volumes or tapes, can be migrated to AWS storage systems, such as S3, EBS snapshots or Glacier archive models. Access to your AWS storage systems is audited and controlled with IAM policy and CloudTrail logs.
AWS Account Structure
Starting the build-out of your AWS infrastructure with the creation of an AWS account can be as easy as using an email address and a credit card for payment. Any enterprise that plans to use AWS services at large scale should enter into an enterprise agreement with AWS for other discounts and payment methods.
Your AWS account controls all your resources, from billing activity to the data you store on the cloud. This account is considered the root account, but it is much more important than a typical root account you may be using in the on-premise world, such as a root user for a Linux server. This root account is often the target for hacker attacks, and, if compromised, can put your applications and data in significant danger. Therefore, our best practices recommend the implementation of multiple AWS accounts for different business purposes. There are several benefits to this approach:
- It reduces the blast radius, i.e., a hijacked account is the one you must pay the most attention to, so multiple accounts reduce your scope.
- Isolating business purposes by account allows more flexibility in your ongoing operations. For example:
- Audit Account: only stores log data for auditing purposes
- Shared Services Account: for shared services deployment, such as Active Directory domain controller, Transit VPC setup, security scanner, etc.
- Business Unit Account: individual account for each line of business
- Billing Account: to link all your AWS accounts to a single account, to ease the billing process and leverage AWS volume discounts
AWS Virtual Private Cloud (VPC) is your private networking environment in the cloud. A VPC can be designed to be closed or open for direct Internet access, depending on your business requirements.
In the case of a closed VPC, your AWS resources in the VPC can only be accessed from your data centers via private VPN or Direct Connect links. If there is a requirement to expose your VPC services to the Internet, you can backhaul the Internet traffic through your existing on-premise network, with existing controls in place.
In the case of an open VPC, you will allow your AWS resources to access the Internet directly. This is typically the case when your VPC environment is fully hardened with proper security controls in place.
We work with you to decide which option you would prefer to build your VPC.
Day One Footprint with HA-DR Capability
High Availability and Disaster Recovery (HA-DR) is an important requirement for critical enterprise applications which must survive from the loss of a single server, a local data center or a cross-region data center. The strength of the cloud is that, with proper design and implementation, you can leverage HA-DR capability out of the gate.
Your cloud infrastructure is designed to take full advantage of the available AWS regions and multiple availability zones (AZs) to support your HA-DR requirements from day one. We build your AWS infrastructure with vertical and horizontal networking layers from multiple AZs within a region, and a duplicate footprint in a separate region of your choice. For example, we can build your primary AWS infrastructure in the northern Virginia region, and give you the option to pick the Ohio, northern California or Oregon region as a secondary DR deployment.
Multiple Dimensional Networking Layers
Within an AWS region, your network topology will leverage at least two or more AZs. Each AZ is comprised of one or more data centers. This footprint will allow you to deploy applications or AWS services that require multi-AZ setup to meet high availability requirements.
Within each AZ, sub-level networking (subnet) layers are further divided into individualized layers for resource deployments. For example, web, application and database are deployed to their corresponding web-subnet, app-subnet and db-subnet layers accordingly. This subnet layering technique ensures that your components follow the separation of duty principle, a common practice for cybersecurity control.
CIDR Block Allocation
Your VPC can be built with one or more CIDR blocks (up to five at the time of this writing). CIDR block allocation breaks a single block of private IP addresses into multiple sub blocks to create subnets within a VPC. This is an important exercise during cloud infrastructure creation. Improper IP ranges allocated with the CIDR block can introduce IP address clashing problems, which will prevent you from connecting your VPCs together using the VPC Peering service. Without the CIDR block allocation, a new cloud customer tends to use default VPC addresses, e.g., the 172.31.0.0/16 CIDR. This is not a good practice, as the default VPC also comes with an open Internet gateway, a default security group which denies all inbound and allows all outbound traffic. This is something that you may not want to apply to all your applications. In fact, during cloud infrastructure creation, we will provide code to delete the default VPCs in all regions under your AWS account, to meet industry best practices.
Your cloud infrastructure will come with a standard NAT Gateway setup to allow your resources to have egress Internet connectivity to obtain patches from vendors. Note that the NAT only allows traffic initiated from your resources. It will not allow traffic initiated from the Internet. NAT is widely used and deployed for on-premise and cloud solutions. However, the NAT Gateway takes it to the next level in terms of flexibility and scalability. The NAT Gateway is typically used to obtain patches for services deployed in your VPC.
Private Service Endpoints
Some AWS resources, such as S3, DynamoDB, KMS, SSM, etc., provide access through the Internet. Traversing the Internet can be an inefficient way for private VPC resources to to access these AWS services. To address this issue, AWS provides private endpoints for frequently used resources. Your cloud infrastructure comes with a standard set of S3, KMS private endpoints. Additional links can be added per your request or application requirements.
Private Connections for the AWS Cloud
We typically recommend that our clients create Direct Connect circuits to the AWS cloud to maintain bandwidth consistency and cost efficiency. Note that there are networking charges for the data you move out of AWS resources, such as cross AZs or cross regions transfers. Direct Connect allows you to connect your data centers with dedicated circuits for both private (access only to your VPC) and public (access to Internet resources) links. Direct Connect also provides tiers of bandwidth from 1Gbps to 10Gbps. And there are other smaller bandwidth options which can be obtained from AWS partner services. While there is a cost to creating a Direct Connect circuit, you frequently save over the long term if you often transfer data back and forth between your VPC and on-premise systems. In addition to the cost savings, you will also have a predictable connection and enough bandwidth for your application workloads.
While Direct Connect will be the main connection pipe, it is typical to have additional VPN links act as your fallback circuits when the main Direct Connect circuit is down. VPNs enable you to quickly establish secure connections to the AWS cloud from your data center. This only takes hours or, at most, days to create VPN connections, while it takes weeks or months to build Direct Connect circuits with vendors such as AT&T or Verizon. Note that there is a bandwidth limit of 1.25Gbps for IPsec VPN channels that you can connect to your VPC virtual private gateway.
VPC Peering, PrivateLink or Transit VPC
Your cloud infrastructure includes VPC Peering to connect your line of business VPC accounts to your Shared Services VPC, which allows your VPCs’ resources to communicate with each other via private IPs.
Other options to connect your VPCs from different accounts to networks are:
- Transit VPC: a new network connecting technology, which uses third-party VPN solutions to connect your network. The Transit VPC can act as a hub to connect your spoke VPCs with on-premise systems.
- PrivateLink: this service allows an application deployed in one VPC to share privately with other VPCs using an internal network path.
We work with you on your requirements to come up with the best target network design.
AWS Identity and Access Management
Identity and Access Management (IAM) is the cloud version of your user identity credential system. This service allows you to choose a range of options such as:
- Connect your existing Active Directory (AD) system to AWS via the AD Connector
- Deploy additional AD domain controllers on the AWS side to extend your enterprise AD/LDAP system to AWS
- Federate your existing AD/LDAP to AWS with STS integration
- Build your new IAM system on the cloud
Our architects work with you to determine the best option for your environment.
IAM Role and Policy
We work with your security team to create a standard set of IAM roles and policies (access permissions) that we customize to further tighten the access for each user role. For example, we implement the following best practices:
- A policy to restrict resource access outside your target regions, such as northern Virginia or Ohio. Any attempt by an employee trying to launch AWS resources outside these regions will be denied.
- An IAM policy to stop privilege escalation. For example, an IAM administrator cannot escalate himself or herself into a full all-resources administrator.
- An S3 bucket policy to prevent bucket data write without encryption.
- A policy to control shared resources across your accounts
Security groups are AWS access control lists for your cloud resources. We provide standard templates to create security groups for your web, application and database layers. These templates can be used to tailor your application requirements, such as additional open network ports.
Multi-factor authentication is turned on for your critical IAM accounts, such as root accounts, IAM administrator, full-access administrator, etc. This is a common best practice to protect your account. We configure the AWS Config service to watch for privileged accounts without MFAs configured, so you can monitor them accordingly.
Encryption is the most critical area we must pay attention to when we move applications and data onto the cloud. The good news is that AWS is very mature in this space, and its technologies are adopted by international institutions. The bad news is that encryption technologies can be a double-edged sword. Improper use and management can potentially lock up your data for life. We provide you with best practices on how to use encryption properly.
KMS is the AWS Key Management Service, which manages encryption keys and provides encryption and decryption functions for your data. Your cloud infrastructure resources will be encrypted with your own managed KMS keys. We recommend KMS, as it is an effective service to quickly protect your data on the cloud. KMS also allows you to import your own managed key from external HSM devices if you wish to do so.
Data In-Transit and At-Rest Encryption
When you are ready to deploy an application along with your newly built cloud infrastructure, we make sure that your application communication links use HTTPS or IPsec to encrypt your data in-transit. All your data storage created in the cloud environment, such as S3 or EBS, will also be encrypted. The same encryption method can be expanded to the entire S3 family, such as S3 Reduced Redundancy, Glacier storage or snapshots for EBS volumes.
Centralized Logging and Monitoring
Your cloud infrastructure is built with a centralized logging approach. All your log files are stored in a single location, with versioning enabled and access control via IAM policy. This is a common requirement from audit or compliance teams, who want to have full records of your cloud activity during an audit time or a compliance check. The log files in the central location will be either inspected manually or fed to an SIEM security monitoring system.
Your cloud applications cannot deploy to production if their activity cannot be monitored. This is the area where we work with your operations team to integrate the cloud data with the existing SIEM and APM tools. We also introduce your operations team to cloud-native AWS built-in monitoring capabilities, such as CloudWatch and its customized dashboards. We also provide many alerts from CloudWatch alarms, such as access to your root account, deletion of your S3 bucket, changes to your VPC settings, etc. All these provisions ensure that your operations team is engaged from day one with the cloud infrastructure build-out work.
Backup and Restore
We enable automated backup features where provided by the AWS services. For your cloud infrastructure, we start out with S3 versioning and S3 cross-region replication for critical data buckets. We also provide backup and restore procedures for the AWS services you would like to use during cloud infrastructure creation.
CI/CD stands for Continuous Integration/Continuous Deployment. This is a common modern practice in software development and cloud automation. Without CI/CD, your cloud resources will not be as flexible, and will be difficult to manage at large scale. So your cloud infrastructure is built with fundamental CI/CD pipelines to create and maintain your cloud resources with automation code. For OS and application deployment, we work with you to build a CI/CD pipeline using common cloud automation and deployment tools.
We automate the creation for infrastructure resources, such as VPCs, subnets, security groups, VPC peering, IAM roles and policies, etc. We use either CloudFormation or Terraform technology to provide a blueprint for the infrastructure. This blueprint can be executed as either a complete automation, or with some manual intervention, depending on your choice or workload situation.
Building secure, scalable public cloud environments requires a comprehensive approach. MVC is an ideal methodology to create a secure and fully functional environment. We at CTP have perfected this process over the last eight years, and can get your enterprise to the public cloud in a matter of weeks. The results of the MVC approach are not just some piece of automation code, or a design technical specification you can use to automate or manually rebuild your cloud infrastructure environments. We work together with many key groups in your IT organization, e.g., cyber security, networking, operations, devops, development and management, etc. The joint effort among the teams delivers two important benefits:
- Your teams can work and learn together as we build the new cloud infrastructure.
- Your teams can have the opportunity to customize your cloud infrastructure the way it fits your organization best.