Our mission is to help you succeed today in AWS using our proven, turnkey AWS blueprints for terraform. It's like buying a prefab house; you'll know exactly what you're getting and can customize it because you own it. Why start from scratch when you can have it today?
Cloud Posse is a DevOps Accelerator. We help you implement our blueprints leveraging our AWS reference architecture for terraform. Your team will move faster with less risk and more predictability when you follow our process. Our AWS blueprints for terraform are ready-to-go templates for the most common architecture patterns. We can customize any delivery with professional services or build and implement custom architectures as part of our Enterprise DevOps Accelerator track.
Everything we deliver leverages our Open Source (aka free) terraform modules, so no ongoing license fees or strings are attached.
We build only what customers need and do it in a way developers love. That's why we've spent the better part of the past 8 years building our AWS reference architecture for terraform to support countless use cases working exclusively with some of the hottest venture-backed startups that have collectively raised nearly 3 billion dollars. You could say this has given us a type of clairvoyance and the ability to anticipate customers' needs based on their pains.
Our solutions are implemented as part of our service offerings
Our Jumpstart track is our fastest implementation.
We create and deploy all configurations using our recommended defaults for the Cloud Posse Reference Architecture for AWS with terraform. It's entirely up and running within 2-4 weeks. Includes access to our documentation, shared workshops for customers, and support via Slack. You can add a support retainer or use professional services to customize the solution as much as you need.
If you have a competent team but need something done quickly for you and have fewer opinions on every design decision that goes into building your AWS infrastructure, then our Jumpstart track is ideal for you.
Our Bootcamp track is our most affordable solution.
We hand you all the configs with our recommended defaults. It is entirely based on our AWS Reference Architecture for terraform. You deploy it with your team. Work at your own pace. Includes access to our documentation. Ask for help during our shared workshops for customers or via Slack.
If your team has the time and is highly knowledgeable on Terraform and AWS, then the Bootcamp track may offer the highest value.
The Enterprise track is our most customizable solution.
We build and deploy your infrastructure using our AWS Reference Architecture for terraform together with your team from the ground up—with weekly check-ins and updates. You team will be assigned Homework assignments and have access to Company Workshops to train with our engineers through pairing sessions. We handle all technical project management and follow our proven, repeatable project plan to ensure successful delivery everytime. As part of this engagement, we revisit every design decision of well-architected infrastructure. If you're subject compliance requirements, we'll deploy the Foundational Security & Compliance pillar and remediate any findings. We'll assist with migration of any workloads and customize anything as needed.
If you want to level up your team or are very interested in reviewing every design decision of well-built infrastructure, plus you have some unique or complex requirements then our Enterprise track is probably best.
Our Professional Services are offered to existing customers to help them customize, extend, or support their infrastructures. No matter which Bootcamp, Jumpstart, or Enterprise track you participate in, we can help you. Our services are offered on a Time & Materials basis on a conventional retainer model.
For existing and past customers, we offer high-touch professional services.
- Customize anything you need.
- Build any Terraform modules you want.
- Write any documentation that is missing.
- Implement new systems and services
- Wire up new integrations (E.g. with Okta)
- Upgrade your infrastructure from top-to-bottom
- Fill in when you're short of hands
- Answer any questions you need via Slack or Zoom
- Perform remote-hands work or pairing sessions via Zoom
- Workload migrations and migration planning
- Adopting legacy accounts and workloads into the framework
Turnkey AWS Blueprints
Our reference architecture consists of all the structural terraform components required to build AWS infrastructure. Using this architecture, we've developed blueprints that consist of all the pre-existing materials from our reference architecture that customers need and how they go together.
A well-defined blueprint aligns business goals and outcomes to the technical strategies, patterns, best practices, and technology stacks to maximize the value for the enterprise.
Here are some of the ready-to-go blueprints we've developed for our customers.
AWS Benchmark Compliance
Companies that handle health data are automatically subject to HIPAA regulations. Attempting to build the technical controls on top of the existing infrastructure is frequently more complicated than a lift-and-shift into a new AWS organization built with compliance in mind. Companies need to architect their infrastructure to meet these standards from the ground up.
To achieve HIPAA compliance on AWS, you will need to follow these steps:
- Review the AWS HIPAA Compliance[1]https://aws.amazon.com/compliance/hipaa-compliance/ page to understand the AWS shared responsibility model and the specific AWS services covered by HIPAA.
- Sign a Business Associate Agreement (BAA) with AWS. This contract outlines the responsibilities of both AWS and the customer concerning HIPAA compliance.
- Follow the AWS HIPAA Implementation Guide [2]https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html to configure your AWS environment in a way that is compliant with HIPAA requirements. This includes setting up appropriate access controls, data encryption, and other security measures.
- Conduct regular audits to ensure your AWS environment complies with HIPAA requirements.
- If you are storing or processing electronically protected health information (ePHI) on AWS, you must follow additional requirements, such as implementing access controls and conducting risk assessments.
- Finally, carefully review and follow all applicable laws and regulations related to HIPAA compliance. This includes federal and state laws that may apply to your organization.
HIPAA is not prescriptive on how the technical controls are implemented. Instead, HIPAA defines a set of high-level expectations, but it’s up to the responsible party (e.g. Customer) to assert what controls are in place for each safeguard.
Our AWS reference architecture for terraform has a Foundational Security & Compliance pillar that addresses the implementation of the technical controls for HIPAA compliance. Choose one of our Jumpstart or Enterprise tracks to implement it.
For further details on our implementation, see AWS HIPAA Compliance for Healthcare Companies (Healthtech).
Organizations that store client information in the cloud (e.g. cloud service providers, SaaS providers) benefit from a SOC 2 report that proves a client’s data is protected and kept private from unauthorized users. No particular industry requires these reports, but businesses often require them in financial services, including banking, investment, insurance, and security. If you are a technical service provider, a Publicly traded company, a startup setting its sights on IPO/SPAC, or a company working with other enterprises, then there is a good chance that either a client or business partner will require a SOC audit. Companies need to architect their infrastructure to meet these standards from the ground up.
SOC2 Considerations
What makes SOC2 unique is that it doesn't prescribe what technical controls are required. Instead, SOC2 defines a set of high-level expectations, but it’s up to the responsible party (e.g. Customer) to assert what controls are in place for each pillar.
- Logical and physical access controls
- System operations
- Change management
- Risk mitigation
The typical approach to addressing these controls is using a combination of one or more of the compliance standards such as CIS, HITRUST, NIST, ISO27001, etc. Organizationally, this is a decision that has both technical and procedural impacts.
The Technical Benchmark Framework should satisfy the vast majority of requirements for SOC2, which means most likely selecting more than one framework.
Cloud Posse’s strategy is to deploy AWS SecurityHub and enable the AWS Config Conformance Packs containing the security controls to meet the operational best practices of a given compliance framework, then remediate all the findings. A conformance pack is a collection of AWS Config rules and remediation actions that can be easily deployed across an AWS organization. With AWS Config we can evaluate whether your AWS resources comply with standard best practices of a given technical benchmark. Cloud Posse has all the Terraform modules to accelerate this implementation.
Since Security Hub, GuardDuty, and AWS Config are regional AWS services, we must deploy them to all enabled regions. Security Hub and GuardDuty Administrator accounts will need to be deployed first. On top of that, the region designated as the Global Collector Region needs to be deployed afterward.
The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard created by a consortium of major card brands including American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc.
PCI DSS applies to companies that store, process, or transmit cardholder data (CHD), such as merchants, processors, acquirers, issuers, and service providers. The PCI DSS is mandated by the card brands and administered by the Payment Card Industry (PCI) Security Standards Council (SSC).
Attempting to build the technical controls on top of the existing infrastructure is frequently more complicated than a lift-and-shift into a new AWS organization built with compliance in mind. Companies need to architect their infrastructure to meet these standards from the ground up. While PCI/DSS is prescriptive on what technical controls are needed and provides Cloud Computing
Guidelines[1]https://listings.pcisecuritystandards.org/pdfs/PCI_SSC_Cloud_Guidelines_v3.pdf, but not on how they are implemented. It is up to the responsible party (e.g. SaaS Company) must assert what controls are in place for each safeguard.
PCI DSS v.3.2.1[2]https://listings.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf consists of 12 requirements spread across six objectives.
| PCI DSS Objective | PCI DSS Requirement | Description |
|---|---|---|
| Objective 1 | Build and Protect a Secure Network | |
| Requirement 1 | Install and maintain a firewall to protect your cardholder data | |
| Requirement 2 | Do not use the vendor's default values for device passwords and other security parameters | |
| Objective 2 | Protect Cardholder Data | |
| Requirement 3 | Protect stored cardholder data | |
| Requirement 4 | Encrypt the cardholder data transmission over public networks | |
| Objective 3 | Create a Vulnerability Management Program | |
| Requirement 5 | Use and update anti-virus software regularly | |
| Requirement 6 | Build and maintain secure applications and systems | |
| Objective 4 | Apply Strong Access Control Measures | |
| Requirement 7 | Limit access to cardholder data according to specified requirements | |
| Requirement 8 | Assign a unique identity to anyone with computer access | |
| Requirement 9 | Restrict physical access to cardholder data | |
| Objective 5 | Regularly Monitor and Test Networks | |
| Requirement 10 | Monitor and track all access to network and cardholder data | |
| Requirement 11 | Test security systems and processes regularly | |
| Objective 6 | Create a Policy Regarding Information Security | |
| Requirement 12 | Establish an information security policy for employees and contractors |
Our blueprint deploys AWS SecurityHub, then enables Security Hub’s PCI DSS v3.2.1 standard[3]https://aws.amazon.com/blogs/security/how-to-use-the-aws-security-hub-pci-dss-v3-2-1-standard/ and the conformance packs required to meet PCI/DSS operational best practices [4]https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-pci-dss.html. Together, these provide a helpful framework to meet PCI/DSS requirements, given its broad scope of security controls. A conformance pack is a collection of AWS Config rules and remediation actions that can be easily deployed across an AWS organization. With AWS Config we can evaluate whether your AWS resources comply with the standard best practices of a given technical benchmark. Cloud Posse has all the pre-existing Terraform modules to accelerate this implementation.
Our AWS reference architecture for terraform has a Foundational Security & Compliance pillar that addresses the implementation of the technical controls for PCI/DSS compliance. Choose one of our Jumpstart or Enterprise tracks to implement it.
References
AWS Migrations
Our reference architecture is ideally suited for businesses seeking to migrate from Aptible to AWS but needs some help.
Aptible is a platform that helps organizations deploy and manage applications on the cloud in a secure and compliant manner. It provides tools and services for building, testing, and deploying cloud-native applications and monitoring and securing those applications. Aptible is focused on helping organizations meet regulatory requirements, such as HIPAA and GDPR, and provides a range of compliance-related features, such as audit logs and secure infrastructure. Aptible is often used by organizations in regulated industries, such as healthcare and finance, to help them achieve and maintain compliance with various regulations.
Reasons to Migrate to AWS
There are several reasons why companies might outgrow Aptible or want to migrate from Aptible to Amazon Web Services (AWS):
- Cost: Aptible is a cloud platform, so you pay for the resources you use. As your company grows and your usage increases, the cost of using Aptible can become more expensive than other options, such as running your applications directly on AWS.
- Feature set: Aptible is a specialized platform focused on compliance and security. If your company's needs go beyond these areas, you may consider a more comprehensive platform like AWS that offers a broader range of features and services.
- Customizations: Aptible provides tools and services for building, deploying, and managing applications on the cloud. If you want more control over your infrastructure and the ability to customize it to meet your specific needs, you may consider running your applications directly on AWS.
- Integrations: If you are using other AWS services or want to take advantage of AWS's integrations with other platforms and tools, you may find it easier to run your applications directly on AWS.
The decision to migrate from Aptible to AWS (or any other platform) will depend on your specific business needs and priorities. It's important to carefully evaluate your options and consider factors like cost, feature set, customization, and integration before deciding.
How to Migrate to AWS
Since you're already operating on Aptible, your applications are easy to migrate because they follow the 12-Factor App pattern. But where you'll need the most help is ensuring your infrastructure remains compliant with the security benchmarks (e.g. SOC2, HIPAA, HITRUST, PCI/DSS, etc). We support the full suite of AWS security-oriented compliance tools like AuditManager, SecurityHub, GuardDuty, Macie, Inspector, Firewall Manager, and more.
You may also need help with the CI/CD and observability areas. These need considerable attention when moving to AWS. We've got you covered.
We support migrations from Aptible to AWS via our Enterprise DevOps Accelerator service. Our Foundational Platform pillar will deliver a platform of either ECS Fargate or EKS (Kubernetes), and when coupled with our Foundational Release Engineering will provide a solid process for CI/CD including build/test, preview environments (aka Review Apps), and release promotion to development, staging, and production environments with approval gates. Our Foundational Site Reliability Engineering (SRE) pillar established the essential observability tier. Our Foundational Security and Compliance pillar will lay the foundation to achieve benchmark compliance (e.g. HIPAA, HITRUST, PCI/DSS, SOC2 Type II, etc).
AWS modernization migrations involve moving existing applications or workloads to the cloud. Companies already operating on Amazon Web Services (AWS), can re-platform to take better advantage of the scalability, reliability, and cost-effectiveness of the AWS cloud.
Replatforming on AWS using Kubernetes or ECS can help you modernize your application by taking advantage of the scalability, reliability, and cost-effectiveness of the AWS cloud. It can also make it easier to manage and operate your application, as both Kubernetes and ECS provide features like self-healing, horizontal scaling, and automated rollouts and rollbacks.
AWS EKS (Kubernetes) is based on an open-source container orchestration system that allows you to deploy and manage containerized applications at scale. It provides out-of-the-box self-healing, horizontal scaling, and automated rollouts and rollbacks. Amazon Elastic Container Service for Kubernetes (EKS) is a managed Kubernetes service that makes it easy to deploy and run Kubernetes on AWS.
ECS is a fully managed container orchestration service that makes it easy to run, scale, and secure containerized applications on AWS. It is designed to be used with Docker containers and allows you to run applications on a scalable, high-performance infrastructure. If you want a simple and cost-effective way to run containers and don't need advanced features or customization options of EKS, ECS might be a better fit than EKS.
Engine Yard is a cloud platform that helps developers build, deploy, and manage applications on the cloud. It provides a range of tools and services for building and running applications, including a platform-as-a-service (PaaS) offering and support for popular open-source frameworks and languages like Ruby on Rails, Node.js, and Python. Engine Yard is focused on helping developers build and run applications quickly and efficiently. It provides automatic scaling, rolling deployments, and integrated monitoring and logging to make this easier. Engine Yard is often used by developers who want to build and deploy applications on the cloud but don't want to spend much time on infrastructure management.
Reasons to Migrate to AWS
There are several reasons why companies might want to migrate from Engine Yard to Amazon Web Services (AWS):
Costs: Engine Yard is a managed cloud platform, so you pay a premium for the resources you consume. As your company grows and your usage increases, using Engine Yard can become more expensive than other options, such as running your applications directly on AWS EKS or ECS.
Feature sets: AWS offers a wide range of products and services that can be used to build and run applications on the cloud. If you need more features or flexibility than what Engine Yard provides, you may want to consider moving to AWS.
Customizations: Engine Yard provides tools and services for building and running applications on the cloud. If you want more control over your underlying infrastructure and the ability to customize it to meet your specific needs, you may consider running your applications directly on AWS.
Integrations: If you are using other AWS services or want to take advantage of AWS's integrations with other platforms and tools, you may find it easier to run your applications directly on AWS.
The decision to migrate from Engine Yard to AWS will depend on your specific business needs and priorities. It's important to carefully evaluate your options and consider factors like cost, feature set, customization, and integration before deciding.
How to Migrate to AWS
Since you're currently operating on Engine Yard, your applications are easy to migrate because they follow the 12-Factor App pattern. But where you'll need the most help is ensuring your infrastructure continues to serve your developers with the ease of use of Engine Yard.
You may also need help with the CI/CD and observability areas. These need considerable attention when moving to AWS. We've got you covered.
We support migrations from Engine Yard to AWS via our Enterprise DevOps Accelerator service. Our Foundational Platform pillar will deliver a platform of either ECS Fargate or EKS (Kubernetes), and when coupled with our Foundational Release Engineering, will provide a solid process for CI/CD including build/test, preview environments (aka Review Apps), and release promotion to development, staging, and production environments with approval gates. Our Foundational Site Reliability Engineering (SRE) pillar established the essential observability tier. For companies with compliance needs (e.g. HIPAA, HITRUST, PCI/DSS, SOC2 Type II, etc), our Foundational Security and Compliance pillar will lay the foundation to achieve benchmark compliance.