Modernizing and Refactoring an E-Commerce Platform
December 4, 2019
TABLE OF CONTENTS
The client is a health and wellness brand that provides healthcare providers and their patients with products, education, and technology. Recently, the client wished to re-factor and modernize their existing e-commerce platform by migrating its systems and processes to an AWS cloud environment.
The client began this modernization initiative with internal teams. Before Levvel was brought on, the client’s existing 30-person e-commerce development team already had extensive .NET Core experience and was confident in its microservices enablement plan. However, the company required detailed technical expertise to ensure HIPAA compliance, business continuity, and disaster recovery strategies.
Levvel was engaged to help the client securely and efficiently operate in a highly regulated SaaS environment. The client wished to migrate from collocated data centers into the Amazon Web Services (AWS) public cloud platform. Additionally, the client sought infrastructure automation to provision and manage the AWS environment, as well as business continuity and disaster recovery strategies. The client also wanted to enable its development team with AWS Security best practices and by streamlining HIPAA compliance within AWS. Levvel’s approach included API development, containerization, and use of a microservices-based architecture.
Levvel resources engaged with the client’s cloud and technology teams to develop business continuity and disaster recovery strategies, assess compliance and define remediation actions, and implement approved approaches. Levvel provided an AWS Certified Solutions Architect (Professional) and a certified SCRUM Master to assess and remediate the company’s public cloud environment.
Levvel’s limited extent of engagement with the client meant it had to focus on the culture and procedures that landed them in gridlock on AWS. While they had made significant progress in migrating some development to AWS and learning cloud practices quickly, meeting their regulatory, continuity, and DR requirements for production posed a considerable challenge. Network definitions, security groups, VPC peering connections, and hefty EC2 instances were in place and performing as expected, but they were all built by hand over several months by multiple people, many of whom were no longer at the organization. Sensitive data was exposed in a number of places throughout config files. Employees had created IAM users and roles with no meaningful control over access to resources or services. Because this occurred in the early stages of the client’s development, many resources were greatly over-provisioned by well-intentioned employees who wanted to guarantee performance.
Levvel spent two weeks assessing these cloud environments. By the time they began implementation, the client was all-in on IaC with CloudFormation from top to bottom. They made the decision themselves to continue developing in their existing accounts while Levvel helped them stand up parallel AWS accounts using CloudFormation Infrastructure-as-Code (IaC).
The client’s early attempts at adopting AWS failed to realize their goals in both security and automation. Levvel’s first priority was to consolidate the point of login to the AWS console for all accounts to an AWS SSO endpoint. Previously, they relied on highly privileged users to login via the console, with no cross-account role assumption to centralize access to the accounts. Leavers and joiners were carefully managed via an on-premises Active Directory, but those same users used different credentials to access AWS. Incorporating this AD allowed Levvel to delete many superfluous IAM entities with expansive permissions.
Once access to the environments were established, Levvel created a multi-account strategy comprised of separate accounts for all stages of the SDLC, a logging account, and a shared services account. SSO permission sets could be defined and assigned to specific employees for each account, extending the control the AD administrator had on premises to AWS.
Addressing the resource bloat and expense of giving free reign to cloud resources was next. The client encouraged experimentation and learning among their employees, but in so doing, many resources were left unattended and generating unnecessary expenses. By establishing and enforcing a culture of proper tagging, users could identify what resources were likely sitting dormant and which were critical.
Finally, a centralized logging account collected all critical logs from all accounts and VPCs. This enabled internal and external auditors the ability to interrogate CloudTrail, CloudWatch, and VPC FlowLogs for events and unwanted traffic. AWS ElasticSearch was used in conjunction with Lambdas and Kinesis to deliver real-time logs that drove dashboards in Kibana.
The timeline of the project did not allow for Levvel to migrate all of the client’s applications and infrastructure to the AWS cloud, but they were able to provide a very strong footing for future growth in a controlled manner. By modularizing the network design, security group rules, and configuration settings, and then executing that CloudFormation IaC in separate accounts, the client could be guaranteed identical environments at all stages of their SDLC. Those users with the know-how and authority to visually inspect the environments could do so via the console, but Levvel helped establish a standard that prohibits clicking around in the console to quickly fix an issue.
You're doing big things, and big things come with big challenges. We're here to help.