Published on · Updated on
Rewrote the guide with current AWS guidance on shared responsibility, hybrid identity and network encryption, audit scope, monitoring, and incident response.
A secure hybrid environment depends on consistent controls across AWS accounts, on-premises systems, and the connections between them. Start with the application and data flows you must protect, assign an owner to each control, and verify what each AWS service actually covers. AWS tools can help inspect configured AWS resources; they do not automatically secure or monitor every host and network in your data center.
For each application, document its AWS accounts and Regions, on-premises sites, workloads, sensitive data, network paths, and identities. Mark where data is created, stored, and transmitted, then identify who operates each system and keeps its evidence. This inventory gives security, infrastructure, and compliance teams a shared scope for control design and incident response.
AWS and the customer share security responsibilities. AWS protects the infrastructure that runs its services; the customer's work depends on the services selected. For example, customers manage data, permissions, application settings, and guest operating systems on Amazon EC2, while AWS operates the underlying infrastructure. Managed services shift some operational work to AWS, but customers still configure access, data protection, and service-specific options.
On-premises systems remain under the organization's control. Use the AWS shared responsibility model to map each control to its operator instead of treating “AWS” as one security boundary.
Use a central workforce identity provider and federated access for people who need AWS accounts. AWS IAM Identity Center can manage account access or connect to an external identity provider. Give people role-based permissions and short-lived sessions; avoid issuing each employee long-term IAM access keys. Require multifactor authentication for privileged access, review who can assume administrative roles, and keep any emergency access path narrow, monitored, and tested. See AWS IAM security best practices.
Separate human access from application credentials. Use an IAM role for a workload running on AWS. For a server or application running outside AWS that calls AWS APIs, IAM Roles Anywhere can exchange a certificate from your public key infrastructure for temporary role credentials. Set a distinct role and least-privilege policy for each workload; protect and rotate the certificates that establish trust. Avoid shared static access keys embedded in source code, images, or configuration files.
Grant only the actions and resources each identity needs. Add policy conditions when the source network or other context is stable and meaningful, then test the resulting access. Use IAM Access Analyzer to review external access and policy findings; it is one input to access reviews, not a substitute for validating intended permissions.
Use VPCs, subnets, routes, and firewalls to separate workloads that have different trust levels or exposure. A VPC and subnet provide network structure; they do not decide which users or applications are authorized. In AWS, security groups are stateful controls attached to network interfaces, while network ACLs are stateless subnet controls. Keep inbound and outbound rules specific to required sources, destinations, and ports, and account for return traffic in stateless rules. Review routes as well as firewall rules so that a permitted path cannot bypass the intended inspection point. For VPC components and network design, see our AWS VPC configuration guide.
Apply equivalent segmentation and filtering in the data center. Document allowed flows between on-premises zones and VPCs, remove unused routes and broad rules, and review them when an application or trust boundary changes. Use application authentication and authorization in addition to network reachability; an IP address or private connection does not prove a caller's identity.
AWS Site-to-Site VPN uses encrypted IPsec tunnels. AWS Direct Connect provides dedicated network connectivity, but Direct Connect does not encrypt traffic in transit by default. If traffic over Direct Connect needs encryption, options include running Site-to-Site VPN over the connection or using MACsec on a supported Direct Connect link. MACsec protects its point-to-point Ethernet link; it is not end-to-end encryption across other network segments.
Use TLS for application connections where the data needs protection between the actual endpoints, including when it crosses internal networks. Validate routing, tunnel redundancy, key or certificate ownership, and failover behavior against the application's availability needs. See the AWS documentation for Site-to-Site VPN data protection and MACsec in Direct Connect.
Limit operating-system and database administration to named, authorized operators. Use separate administrative identities, strong authentication, and logged access paths; do not expose management ports broadly to the internet or to unrelated network segments. Restrict access to production workloads by role and environment.
Maintain a supported baseline for operating systems, packages, container images, and applications. Track patch and vulnerability status for both AWS-hosted and on-premises assets, prioritize fixes based on exposure and impact, and record approved exceptions with an owner and review date. Remove unused software and services, protect backups, and test restoration rather than assuming a successful backup job proves recoverability.
Amazon Inspector discovers and scans supported AWS resources such as EC2 instances, container images in Amazon ECR, and Lambda functions. Amazon GuardDuty analyzes AWS signals and selected service data for threats. These services complement operating-system, endpoint, and network controls; do not treat them as a universal vulnerability scanner or as endpoint detection for arbitrary on-premises hosts.
Manage corporate laptops and other endpoints with the organization's endpoint protection, encryption, patching, and device access controls. Include the devices administrators use to reach AWS and on-premises systems in the same security inventory and response plan.
Use version-controlled infrastructure definitions and peer review for changes to AWS infrastructure and security policies. Record who approved a change, what it affects, and how to reverse it. For supported AWS resources, AWS Config can record configuration history and evaluate rules when recording and rule coverage are configured; it does not inventory every on-premises asset.
Use TLS for application and service connections, configure clients to validate server certificates, and use mutual TLS when both sides must authenticate with certificates. Treat link encryption, VPN encryption, and application-layer encryption as different protections with different boundaries. See the network section for Direct Connect and VPN limits.
Check the encryption options for each AWS storage or database service and for each on-premises data store. Encryption defaults and key choices differ by service, so confirm which data is covered, whether encryption is enabled for copies and backups, and which identities can decrypt it. The AWS KMS documentation describes the key choices for supported service integrations.
Encrypting data before it reaches a service can be appropriate when the application must retain control of plaintext or when a specific design requires it. It adds key distribution, rotation, recovery, and application complexity, so make the choice from the data and threat requirements rather than enabling it indiscriminately.
AWS KMS customer managed keys offer control over key policies and lifecycle for supported integrations. Other services may use AWS managed or AWS owned keys, with different visibility and control. Confirm the specific service's behavior, restrict key administration separately from data access where appropriate, and plan key disablement, rotation, recovery, and deletion. The AWS KMS key documentation explains these key types and their trade-offs.
Check that the selected services, Regions, and backup paths have the required encryption settings and that key policies allow only intended use. Keep the result with the control owner and evidence for the relevant system boundary.
Determine which contractual, legal, regulatory, and internal requirements apply to the specific data and system boundary. Applicability depends on the organization, service, data, and operating context; a list of well-known frameworks is not a substitute for that assessment. Map each requirement to a control, its owner, the systems in scope, and evidence that can demonstrate operation.
Review threats, exposed paths, identity dependencies, vendors, recovery needs, and the consequences of an outage or data disclosure. Include AWS and on-premises components in the same risk assessment, while recording which team operates each control and where evidence is stored.
AWS Artifact provides AWS security and compliance documents that can support evaluation of AWS-operated controls.
For eligible existing deployments, AWS Audit Manager can collect and organize evidence relevant to an assessment, but it does not assess compliance itself and its evidence may be incomplete for an audit. Since April 30, 2026, new accounts cannot set it up, and existing deployments cannot add Regions. Existing single-account deployments can continue in that account and Region; an organization deployment already set up in its management account can add member accounts to assessments in its existing Regions.
AWS Config sample conformance packs are starting points for detective checks and do not guarantee compliance with a standard. Validate evidence against your own requirements, include customer-operated and on-premises controls, and have the responsible compliance or legal professionals determine whether the evidence is sufficient.
Document who approves access, network, key, and logging changes; who reviews exceptions; and how quickly a control gap must be addressed. Give every exception a business reason, compensating control, accountable owner, and review date. Apply policies to the whole in-scope system, including the facilities and services that exchange its data.
Configure CloudTrail for the AWS accounts and Regions in scope, and consider a multi-Region organization trail when you need consistent collection across AWS Organizations. CloudTrail trails log management events by default, but data events are not logged by default. Explicitly select the resource types and objects whose data activity matters, such as access to sensitive S3 objects, and account for the additional charges.
A CloudTrail trail records AWS activity; it does not replace on-premises operating-system, identity-provider, firewall, or application logs.
Restrict who can change or delete the destination logs and set retention to match investigation and audit requirements. Enabling CloudTrail log file integrity validation makes CloudTrail deliver signed digest files; it does not run the integrity check. Schedule or manually run the documented validate-logs command (or a custom validator) to check the delivered files. Test that alerts and investigation roles can reach the logs without granting broad write access.
Enable AWS Config in each required account and Region, choose the supported AWS resource types to record, and verify that recording is working. Config rules and conformance packs can flag selected configuration conditions; their results only cover the resources and rules actually evaluated. For details on recording scope, history, and rule limits, see our AWS Config inventory and change-tracking guide.
Collect relevant AWS and on-premises signals in the monitoring systems your responders use. Define alerts for meaningful events such as unexpected privileged access, changes to critical logging or network controls, and access to sensitive data. Set an owner, severity, and response path for each alert, and confirm that time synchronization and retention allow investigators to correlate events across environments.
Periodically verify that expected accounts, Regions, data events, endpoints, and on-premises log sources remain covered. A quiet dashboard can mean no findings, missing telemetry, an unrecorded resource type, or a disabled detector; use coverage checks and test events to tell the difference.
GuardDuty analyzes AWS data sources and enabled protection plans, which can include CloudTrail events, VPC Flow Logs, DNS logs, and service-specific signals. Enable the protections and Regions that match your workload, then review current coverage. It is AWS threat detection, not a complete monitor for all activity in an on-premises environment. See the GuardDuty data-source and feature documentation.
AWS Security Hub Cloud Security Posture Management (Security Hub CSPM) runs checks against supported AWS resource controls and consolidates findings from integrated AWS services and supported third-party products. Enable it in the accounts and Regions you need, configure AWS Config recording for the resources its controls evaluate, and track gaps in service coverage. It does not attest that an organization complies with a regulation or automatically assess arbitrary on-premises hosts. See the Security Hub CSPM scope and setup guidance.
Use Access Analyzer findings to review certain external access and IAM policy risks in AWS. Assign a person to evaluate each finding against intended access; an automated finding neither decides business authorization nor covers the full identity system outside AWS.
Use the organization's endpoint detection, vulnerability management, network monitoring, directory audit, and application logging for on-premises systems. If a supported third-party product can send findings to Security Hub CSPM, verify the integration and resource coverage before relying on it. Keep the owner and response procedure for each source explicit.
Define how responders identify an event, determine its scope, contain it, remove the cause, and restore a known safe state. Name decision-makers for AWS accounts, on-premises infrastructure, identity systems, legal or privacy review, and communications. Include contacts, escalation routes, evidence sources, and recovery dependencies. The exact containment action depends on the incident and its operational impact.
Ensure responders can reach CloudTrail, network and endpoint logs, backups, and affected systems during an outage or credential compromise. Document how to revoke sessions or credentials, isolate a workload, block a network path, preserve evidence, and restore service. Automate only well-understood actions with scoped permissions and a tested rollback path.
Run tabletop exercises that involve both AWS and on-premises teams. Use scenarios such as compromised administrator credentials, a misrouted connection, or data access outside the expected pattern. Record decisions, missing telemetry, and recovery steps, then assign owners and due dates for the resulting fixes. AWS Well-Architected describes incident response as detection, analysis, containment, eradication, and recovery, with actions adapted to the event.
Identify who can change AWS IAM, network routes, encryption keys, logging, and on-premises controls. Check whether people know how to report suspected incidents and where to find the response plan.
Tailor exercises and training to each role. For example, an on-call operator should be able to preserve logs and escalate a suspicious event, while an administrator should know the review and approval path for privileged changes.
Make it clear how employees can report mistakes, suspicious activity, and control gaps promptly. Use exercise results and incident reviews to improve training rather than relying on a one-time awareness session.
Name the team responsible for each control, evidence source, and exception. Give cross-environment controls a coordinating owner so that AWS and on-premises changes do not leave an unowned gap.
Review configuration findings, identity and access reviews, vulnerability status, log-source coverage, incidents, and exercise results on a schedule that fits the system's risk. Compare the evidence with the control's intent and actual scope, not just a tool's status label.
Prioritize findings by exposure and impact, assign a due date and owner, and verify that the corrective change closed the gap across every affected environment. Update the inventory, procedures, and response plan when the system boundary or a control changes.
Hybrid security works when identity, network paths, workloads, data protection, monitoring, and response cover the same documented system boundary. Use AWS services for the AWS resources and signals they support, operate corresponding controls for on-premises systems, and verify the coverage and evidence before making a compliance claim.