Infrastructure security controls
Aptible enforces security and compliance controls at the infrastructure layer so the teams deploying on it inherit them by default. This page documents what each control does and what it replaces if you were to do it yourself.
Secured by Aptible
What Aptible Provides
Vulnerability Management
Aptible scans Docker images for known security vulnerabilities as part of the deployment pipeline and surfaces results in the dashboard. Teams get visibility into OS-level package vulnerabilities without setting up or maintaining their own scanning toolchain.
Docker Image Security Scanning
Aptible runs each container image through Clair, an open-source vulnerability scanner maintained by the container security community. Scans check OS packages installed via standard package managers against publicly maintained vulnerability databases.
Supported distributions: Ubuntu, Debian, RHEL, Oracle, Alpine, Amazon Linux.
Why this matters: Unpatched OS packages in container images are one of the most common attack surfaces in production environments. Most vulnerability disclosures in the CVE database affect system-level packages before they ever reach your application dependencies. Knowing what's in your images before deployment gives you the chance to remediate before a known vulnerability becomes an exploitable condition in production.
Supported distributions: Ubuntu, Debian, RHEL, Oracle, Alpine, Amazon Linux.
Scope note: Scans cover packages installed via system package managers (apt, yum, apk). Application dependencies (npm, pip, bundler) are not in scope.
Guide: handle vulnerabilities
OS Package Patching
Aptible rebuilds and redeploys your containers when critical OS-level patches are available, keeping the host environment current without requiring your team to manually trigger updates or manage base image versions.
Why this matters: Container images are often pulled once and reused across many deployments. Without a patching process, the OS packages inside your running containers drift further out of date over time. When a high-severity CVE drops for a common package, teams running stale images are exposed immediately and often don't know it until a scanner flags it.
What this replaces: Teams managing their own infrastructure have to monitor CVE feeds, update base images, rebuild containers, and coordinate deployments without breaking running services. This is usually manual, often delayed, and frequently skipped unless an incident forces it.
Docs: sECURITY SCANS
Network Protection
Aptible's network architecture limits direct internet exposure for infrastructure components by default and gives teams tools to restrict access at the endpoint level. Most stack components are not publicly reachable. Only endpoints you explicitly expose are accessible from outside the VPC.
Endpoint IP Filtering (Apps)
For app endpoints, Aptible allows you to restrict incoming traffic to a set of allowlisted IP addresses or CIDR blocks. All traffic from addresses outside the allowlist is dropped before it reaches your application.
Why this matters: Applications that serve internal users, handle sensitive APIs, or expose administrative interfaces have no business being publicly reachable. IP allowlisting is one of the simplest and most reliable ways to enforce that, and it's commonly required or expected in enterprise security reviews and SOC 2 audits.
What this replaces: On AWS, network-layer access restriction involves security groups (stateful, instance-level) and network ACLs (stateless, subnet-level), and the two interact in ways that are easy to misread. Security groups don't log denied traffic by default; you need VPC Flow Logs configured and a separate query layer to audit what's actually being blocked or allowed. AWS Network Access Analyzer can identify unintended network exposure, but running it is an additional operational step teams rarely do proactively. Aptible makes IP filtering a single setting per endpoint with no security group or NACL management required.
Scope note: IP filtering applies to app endpoints only. SSH sessions, log access, and other platform-level operations are governed by Aptible's RBAC system, not IP filtering.
Docs: outbound ips
Database Endpoint Filtering
For databases with an external endpoint, Aptible allows you to restrict access to a set of allowlisted IP addresses or networks and block all other incoming traffic.
Why this matters: Exposing a database to the internet, even with strong credentials, is an unnecessary risk surface. IP-level filtering at the database endpoint provides an additional boundary that is independent of application code and credential management. If credentials are ever compromised, the attacker still has to come from an allowlisted network.
What this replaces: Database-level network restriction on AWS typically involves security group rules, VPC access controls, and sometimes database-native connection filtering. These layers interact in ways that are easy to misconfigure, and review requires understanding multiple AWS components simultaneously. Aptible consolidates this to a single setting per endpoint.
Docs: IP filtering
DDoS Protection
Aptible's infrastructure architecture significantly limits the attack surface for denial-of-service attacks. Most stack components (databases, internal services, container hosts) are not publicly routable. Internet-facing endpoints sit behind AWS Elastic Load Balancers that reject malformed and non-TCP traffic before it reaches your application.
Why this matters: DDoS attacks targeting application layers are a persistent risk for any internet-facing service. At the infrastructure level, the most effective defense is minimizing what's exposed and filtering malformed traffic before it reaches resources that can be exhausted.
What this replaces: On AWS, DDoS mitigation at this level requires configuring VPC topology correctly, using ELBs appropriately, and optionally subscribing to AWS Shield Advanced. Getting the VPC architecture wrong can expose components that should be internal-only. Aptible's architecture handles this by default.
Docs: ddOS Protection & pid limits
VPC Peering
VPC Peering lets you connect your AWS VPC (or another Aptible Dedicated Stack) to your Aptible stack's private network. Resources within the peered VPC can access internal Aptible endpoints and databases directly without going through the public internet.
Why this matters: Teams with existing AWS infrastructure, data pipelines, or internal tooling often need to route traffic between their own VPC and their Aptible-hosted services. VPC Peering enables that without exposing endpoints publicly or routing sensitive data through the internet.
What this replaces: Setting up VPC peering on raw AWS involves coordinating route tables, security group rules, and CIDR range planning on both sides of the connection. Aptible handles the Aptible-side configuration and walks you through what's needed on your end.
VPN Tunnels
Site-to-site VPN tunnels let you connect an external network (an on-prem environment, a partner network, or a non-AWS cloud) to your Aptible stack using IKEv2.
Why this matters: Healthcare organizations and enterprise customers frequently have infrastructure that can't be migrated to cloud, or partners who need a secure private channel to exchange data. VPN tunnels provide that connectivity without exposing the Aptible stack publicly.
What this replaces: Configuring site-to-site VPN on AWS involves AWS VPN Gateway setup, customer gateway configuration, routing, and ongoing monitoring. Aptible handles the AWS side and coordinates the setup directly with you.
Docs: network integrations
Encryption
Aptible enforces encryption at rest and in transit for all managed databases and app endpoints by default. No configuration is required to get baseline encryption coverage. Teams can layer additional encryption controls on top of the defaults where their use case requires it.
Encryption at Rest
All Aptible managed databases are encrypted at rest using AES-256. This applies to the live database volume, all automated backups, and all manual backups.
Why this matters: Encryption at rest protects data in the event of physical media loss, unauthorized access to underlying storage, or decommissioned hardware. It is a required safeguard under HIPAA's Technical Safeguard rules and an expected baseline for any system that stores PHI or other sensitive data.
What this replaces: On AWS RDS, encryption at rest is opt-in at provisioning time and cannot be retroactively added to an existing instance. The only path would be to create a new encrypted instance and migrate all data, which requires significant downtime coordination. Aptible enforces encryption at rest for every provisioned database with no opt-out, so this is never a gap to discover during a security review.
Docs: database encryption
Encryption in Transit
All connections between your apps and Aptible-managed databases are encrypted in transit. External endpoints use TLS enforced at the load balancer. Database connections within the stack travel over encrypted channels.
Why this matters: Encrypting data in transit protects against interception on the network layer. For regulated workloads, encryption in transit is required across all channels where PHI or other protected data flows, including internal service-to-database connections that are often overlooked.
What this replaces: Ensuring end-to-end encryption in transit on AWS requires configuring TLS at the load balancer, verifying that database drivers are using encrypted connections, and validating that internal service communication is not traveling in plaintext. Each of these is a separate configuration that can be missed or misconfigured independently. Aptible applies encryption at the platform level across all managed paths.
Docs: encryption in transit
Managed TLS Certificates
Aptible provisions and renews TLS certificates for your app endpoints automatically. You provide your domain; Aptible handles the certificate lifecycle using Let's Encrypt.
Why this matters: Expired certificates are one of the most preventable production incidents. A certificate that expires in the middle of the night on a holiday weekend is a support emergency that has nothing to do with your product. Certificate rotation is also a common audit finding when done manually, because the records are often incomplete.
What this replaces: Certificate management on raw infrastructure involves ACM (AWS Certificate Manager) or manual certificate provisioning, renewal tracking, and deployment. Even with ACM, teams have to manage the renewal integration with their load balancers. Manual certificate workflows often rely on calendar reminders and are a recurring operational burden.
Access Control
Aptible provides role-based access control for all infrastructure operations, with support for SSO, MFA enforcement, and SCIM-based provisioning. Access is governed through named roles tied to specific environments and operation types, not shared credentials or blanket permissions.
Role-Based Access Control (RBAC)
Every action on Aptible is associated with a named user account or service token. Access to deploy, operate, inspect, or modify infrastructure is granted through roles that define exactly what a user can do in which environments.
Why this matters: Shared credentials and overly broad permissions are among the most common sources of both accidental damage and unauthorized access in production systems. They also make it nearly impossible to produce an accurate audit trail. RBAC with real identities ensures that every action is attributable to a specific person or service, and that access can be revoked individually without disrupting other users.
What this replaces: IAM on AWS is flexible but creates a management burden. Teams typically start with broad managed policies and never restrict them. By the time you run an access review, effective permissions are spread across multiple policies, groups, and role assumptions that are difficult to audit in aggregate. Aptible's access model has a smaller surface area: roles map to named operational actions, access is scoped to specific environments, and every action is attributed to a specific identity.
Docs: roles & permissions
Single Sign-On (SSO / SAML)
Aptible supports SSO via SAML 2.0, allowing organizations to authenticate users through their existing identity provider (Okta, Azure AD, Google Workspace, and others). SSO can be made mandatory for all users in the organization.
Why this matters: Centralizing authentication through an identity provider means that when someone leaves your organization, you revoke access in one place and it propagates everywhere. Without SSO, offboarding involves manually removing users from every system they touched, and things get missed. SSO is also a standard control expected in enterprise security reviews.
What this replaces: Without SSO, managing access to Aptible requires managing credentials directly, coordinating user removal manually during offboarding, and maintaining a separate access audit trail outside your IdP. SSO connects Aptible access to the same lifecycle as the rest of your tooling.
Docs: single sign-on
Multi-Factor Authentication (MFA)
Aptible supports MFA for user accounts and can display MFA compliance status across your organization in the compliance dashboard.
Why this matters: Stolen credentials are the leading cause of unauthorized access in cloud environments. MFA is a required control in most compliance frameworks and is a standard expectation in enterprise security reviews. Without it, a compromised password is sufficient for full account access.
Docs: password authentication & mfa
SCIM Provisioning
Aptible supports SCIM (System for Cross-domain Identity Management) for automated user provisioning and deprovisioning from your identity provider.
Why this matters: Manual user management is a compliance liability. When someone joins the team, they often wait for access. When someone leaves, access removal depends on someone remembering to do it. SCIM automates both directions: accounts are created when users are added to the relevant group in your IdP, and deprovisioned when they're removed.
Docs: scim provisioning
Audit Logging & Activity
Aptible captures a continuous record of infrastructure operations and access events. Logs are automatically generated as actions occur, retained over time, and accessible for search, export, and compliance reporting without additional configuration.
Activity Logging
Every infrastructure operation on Aptible is logged automatically: deploys, configuration changes, database provisioning, backup operations, endpoint changes, and access control modifications. Logs capture who performed the action, what resource was affected, when it occurred, and whether it succeeded.
Why this matters: Audit logging is required under HIPAA's Technical Safeguard rules (45 CFR 164.312(b)) and is a control item in HITRUST, SOC 2, and most enterprise security frameworks. Without reliable, tamper-evident logs, you cannot reconstruct what happened before an incident, satisfy an auditor's request for evidence, or respond to a security investigation credibly.
What this replaces: On AWS, audit logging requires configuring CloudTrail, CloudWatch Logs, S3, and a query layer separately (and CloudTrail doesn't capture everything by default; data events are disabled by default and billed separately). Coverage gaps are common and often invisible until an auditor asks for evidence that doesn't exist. Aptible captures platform operations automatically in a single view, retroactively queryable, without additional logging infrastructure to set up or maintain.
Docs: activity
Sensitive Access Logging
Aptible can forward application logs, endpoint logs, and operational events to your preferred logging destination: Syslog, HTTPS endpoints, or Elasticsearch. Log drains let you centralize Aptible logs alongside your application-level observability tooling.
Why this matters: HIPAA and most security frameworks require not just that access controls exist, but that access to sensitive data is logged when it occurs. Knowing that someone has permission to view credentials is different from knowing that they actually viewed them at a specific time. The latter is the audit artifact.
Log Drains
Aptible can forward application logs, endpoint logs, and operational events to your preferred logging destination: Syslog, HTTPS endpoints, or Elasticsearch. Log drains let you centralize Aptible logs alongside your application-level observability tooling.
Why this matters: Most compliance frameworks require log retention over defined periods (HIPAA requires 6 years for certain records). Log drains give you control over where logs are stored and for how long, independent of what Aptible retains natively. They also let you integrate Aptible infrastructure logs into your existing SIEM, alerting, or observability stack.
Note: If logs may contain PHI, consider whether your logging destination has a signed BAA with your organization. Aptible's built-in log retention keeps logs within the Aptible environment where PHI controls are already in place.
Docs: Log drains
Backup & Recovery
Aptible automates database backups with daily snapshots, encrypted storage, cross-region redundancy, and configurable retention policies. Backups are created from encrypted volume snapshots and inherit the same encryption as the live database.
Automated Database Backups
All Aptible managed databases receive daily automated backups by default. Backups are compressed, encrypted, and stored across multiple AWS Availability Zones.
Why this matters: Backup creation and retention is a required implementation specification under HIPAA (45 CFR 164.308(a)(7)(ii)(A)). It is also the minimum viable safeguard against data loss from hardware failure, accidental deletion, or application-level data corruption. Most post-incident reviews that involve data loss trace back to backups that weren't configured, weren't running, or weren't tested.
What this replaces: RDS automated backups on AWS are configurable but not enforced. Teams can (and do) provision databases with no backup policy, short retention windows, or backups disabled entirely. Restoring requires navigating the RDS console, selecting the correct snapshot, and managing the restore process. Aptible handles backup configuration as part of database provisioning and provides a straightforward restore path.
Cross-Region Backup Copies
For production databases, Aptible can automatically copy backups to a second AWS region, providing geographic redundancy against a regional failure or disaster.
Why this matters: A backup stored in the same region as the database it protects is not a complete disaster recovery strategy. Regional failures, though rare, do occur on AWS, and regulatory frameworks that require data recovery planning expect that backups survive a regional failure scenario.
Recommended production backup policy: 14-30 daily backups, 12 monthly, 5 yearly, cross-region copying enabled, final backups retained.
Point-in-Time Recovery
For PostgreSQL 13+ databases, Aptible supports point-in-time recovery (PITR), allowing you to restore a database to any specific moment in time rather than just to a snapshot taken at a scheduled interval.
Why this matters: Daily snapshots have a gap. If data corruption or an accidental deletion occurs at 3pm and your last snapshot was taken at 2am, a standard snapshot restore loses 13 hours of data. PITR uses continuous write-ahead log archiving to fill that gap, making recovery far more precise.
Docs: database backups
Intrusion Detection
Aptible runs managed host intrusion detection (HIDS) across its container orchestration infrastructure using OSSEC, an open-source intrusion detection system. The Aptible security team monitors and reviews HIDS events continuously.
Host Intrusion Detection System (HIDS)
Aptible deploys OSSEC on the infrastructure layer underlying your containers and databases. OSSEC monitors for security events at the host level, including file integrity changes, privilege escalation attempts, rootkit indicators, malware, SSH access, and CIS benchmark deviations.
Why this matters: Intrusion detection at the host level monitors for compromise indicators that application-layer security controls can't see: unexpected changes to system files, unauthorized privilege escalation, rootkit installation patterns. For workloads subject to HIPAA, HITRUST, or SOC 2, IDS coverage is an expected control.
What this replaces: Running HIDS on your own infrastructure means deploying and configuring OSSEC or an equivalent system, connecting it to an alerting pipeline, setting up review workflows, and providing dedicated security staff to triage alerts. Teams that attempt this often find the volume of raw events unmanageable without significant tuning. Aptible handles this as an operational function with dedicated security staff.
CIS Benchmark Monitoring
As part of HIDS coverage, Aptible monitors infrastructure hosts against CIS Benchmark compliance baselines. Deviations from expected configurations are flagged for review.
Why this matters: The CIS Benchmarks are widely accepted configuration security standards used in HIPAA, HITRUST, and SOC 2 audits as evidence that infrastructure is configured to industry best-practice baselines. Monitoring for deviation catches configuration drift before it becomes an audit finding or an exploitable misconfiguration.
Docs: hids
Availability & Recovery
Aptible provides automatic container recovery, high-availability deployment options, and health check-based traffic routing to maintain service availability for production workloads.
Automatic Container Recovery
If a container exits unexpectedly, Aptible automatically restarts it from a clean state. Recovery attempts are logged as distinct events in the activity feed.
Why this matters: Transient failures happen in any production system. Without automatic recovery, a container crash requires a human to detect the failure and manually trigger a restart, which means downtime measured in minutes (or longer, if it happens off-hours). Automatic recovery keeps applications available without requiring manual intervention for common failure modes.
What this replaces: Container restart policies on ECS or Kubernetes require task definition or pod spec configuration, and failure handling depends on the orchestrator being correctly tuned for your application's failure patterns. Aptible handles this automatically without requiring container orchestration expertise.
Docs: container recovery
Health Checks & Traffic Management
Aptible supports health check configuration for app endpoints. Traffic is only routed to containers that are passing health checks, preventing unhealthy instances from receiving requests.
Why this matters: Without health checks, a newly deployed container that is failing to start correctly will still receive traffic, causing errors for end users. Health checks ensure that traffic is only routed to containers that have confirmed they're ready to handle requests, which is especially important during deployments when new containers are being started alongside existing ones.
Docs: health checks
What AWS Provides
Aptible runs on AWS. The controls in this section are provided by AWS at the physical and hypervisor layer. Teams deploying on Aptible inherit these protections automatically. AWS Artifact provides access to AWS's third-party audit reports for these controls.
This is the bottom of the shared responsibility stack. AWS covers the physical layer and the hypervisor. Aptible covers the platform layer above that. Your team owns everything at the application layer.
Physical Data Center Security
AWS data centers are independently audited against SOC 1 (Type II), SOC 2 (Type II), SOC 3, ISO 27001, ISO 27017, ISO 27018, and PCI DSS standards. Physical access requires multi-factor authentication, is limited to employees with a documented business justification, is logged, and is reviewed after each entry. Access lists are reviewed frequently and revoked immediately when no longer needed.
Physical entry controls (badge systems, biometric authentication, security personnel)
Video surveillance of data center perimeters and interior access points
Hardware procurement and provisioning under documented procedures
Media sanitization and disposal following DoD 5220.22-M standards (drives are degaussed and physically destroyed before disposal)
Environmental protections: redundant power, UPS systems, generator backup, fire suppression, climate control
Compliance relevance: HIPAA's Physical Safeguard rules (45 CFR 164.310) require facility access controls, workstation security, and device and media controls. Running on AWS satisfies the facility and physical media requirements for the data center layer. AWS's SOC 2 Type II reports are accepted by HIPAA auditors and HITRUST assessors as evidence for these controls.
Hardware and Hypervisor Isolation
AWS manages the physical servers, network hardware, and the hypervisor layer that isolates compute resources. AWS uses the Nitro System, a combination of purpose-built hardware and lightweight hypervisor, which provides hardware-enforced isolation between instances. Customer workloads do not share physical memory, CPU state, or persistent storage across account boundaries.
Hardware lifecycle: procurement, configuration, provisioning, and end-of-life under documented procedures
Hypervisor-level memory and CPU isolation between tenants
Hardware-based root of trust for instance integrity
Firmware security and supply chain controls for server hardware
AWS Global Network Backbone and Shield Standard
AWS operates a private global network backbone that connects its regions and availability zones, separate from the public internet. All cross-AZ and cross-region traffic within AWS travels over this private network. AWS Shield Standard is included for all AWS customers at no additional cost and provides automatic detection and mitigation of the most common network-layer and transport-layer DDoS attacks.
Private network backbone with redundant paths between AWS facilities
AWS Shield Standard: automatic mitigation of volumetric attacks, SYN/UDP floods, reflection attacks, and other Layer 3/4 attack patterns at the AWS network edge
Network hardware lifecycle and firmware security
Availability Zones and Regional Redundancy
AWS Regions contain multiple physically separate Availability Zones. Each AZ has independent power feeds, cooling, physical security, and network connectivity. AZs within a region are connected by low-latency, high-bandwidth private links. A failure in one AZ does not affect others.
Physical separation between AZs: separate facilities, separate power sources, separate network uplinks
No single point of failure at the physical infrastructure layer within a region
Cross-AZ replication infrastructure for services that support it
Key Management Infrastructure
AWS Key Management Service (KMS) provides FIPS 140-2 validated hardware security modules (HSMs) for cryptographic key material. AWS manages the HSM hardware, physical security, and key material storage. Keys used for EBS volume encryption (which underlies Aptible's database encryption at rest) are managed through KMS.
HSM hardware security and physical protection
FIPS 140-2 validation of the cryptographic boundary
Key material storage and access controls at the hardware level
Your Responsibilities
Aptible covers the infrastructure layer. Your team owns the application layer and the organizational safeguards that infrastructure cannot enforce on your behalf.
Application Security
Your application code, the libraries it depends on, and the way it handles data are your responsibility. This includes how PHI flows through your application, how secrets are managed in application code, how user inputs are validated, and how application-level access controls are implemented.
Secure coding practices and code review
Application-level authentication and session management
Management of secrets and credentials used within your application (not Aptible credentials)
Input validation and protection against injection attacks
Application dependency scanning (npm, pip, bundler, and similar package managers; not covered by Aptible's image scanning)
Data Classification and PHI Handling Decisions
Aptible provides infrastructure controls for handling regulated data, but your team decides what data goes into your application, how it's structured, and how it's used. HIPAA's definition of PHI is broad, and determining whether specific data elements in your application constitute PHI, and therefore what controls apply, is your decision.
Identifying what data in your application constitutes PHI under HIPAA
Structuring data models to limit PHI exposure where possible
Defining data retention and deletion policies at the application layer
Ensuring that PHI does not inadvertently flow into log streams, error messages, or analytics tooling
Organizational and Administrative Safeguards
HIPAA requires a full administrative and organizational program alongside technical controls. This is the bucket that no infrastructure vendor covers. Aptible's security controls satisfy the Technical Safeguard requirements; the Administrative and Physical Safeguard requirements outside infrastructure are yours.
For a full breakdown of what that entails, see the HIPAA Compliance Guide for Startups and the stage-based guide on when to invest.
Security risk assessments and risk management plans
Workforce training and security awareness programs
Security policies and procedures (acceptable use, incident response, access management)
Designation of a Security Officer and Privacy Officer
Sanction policies for workforce members who violate policies
Contingency planning and disaster recovery documentation
Business associate agreements with vendors other than Aptible
Third-Party Vendor Management
If your application sends data to third-party services (analytics, error tracking, logging, email, AI providers), those integrations are outside Aptible's coverage. Whether those vendors require a BAA, and whether they're handling PHI, is your responsibility to assess and manage.
Access Management Decisions
Aptible provides the tools for RBAC, SSO, and MFA. Your team decides who gets access, at what permission level, and under what conditions. Access reviews, permission audits, and the decision to grant or revoke access are your operational responsibility.
Deciding which team members need access and at what permission level
Conducting periodic access reviews to identify accounts that should be deprovisioned
Offboarding procedures for departing employees storage and access controls at the hardware level
Managing service account credentials and tokens used for automated processes