Phase 1 — Assessment & Planning

1. Choose target engine
   • Aurora PostgreSQL (recommended for PostgreSQL features & ecosystem).
   • Aurora MySQL if your app is already MySQL-based.
2. Inventory & compatibility assessment
   • Catalog databases, tables, indexes, constraints, stored procedures, triggers, views, jobs, and linked servers.
   • Identify MSSQL-specific items: T-SQL procedures, CLR assemblies, SQL Server Agent jobs, IDENTITY, DATETIME2, MONEY, NVARCHAR(MAX), temp-table patterns, use of WITH (NOLOCK), etc.
3. Select migration tools
   • AWS Schema Conversion Tool (SCT) — converts schema & flags manual work.
   • AWS Database Migration Service (DMS) — full load + change data capture (CDC) for minimal downtime migration.
   • Supplemental: custom scripts, logical replication, or third-party ETL tools for complex transformations.
4. Define success criteria
   • Data correctness (row counts, checksums), application functional tests, latency/throughput targets, and acceptable cutover window.

The post Aurora Postgres versus RDS Postgres appeared first on AWS Security Architect.

Recommended AWS Resource Tagging Strategy

This document provides a comprehensive tagging framework for AWS EC2 and other AWS resources, including S3, RDS,
Lambda, and networking components. Tagging improves visibility, cost allocation, governance, and automation across environments.

Core Identification Tags

Cost Allocation & FinOps Tags

Security & Compliance Tags

Operations & Automation Tags

Cloud Migration & Governance Tags

Networking & Infrastructure Tags

Example Tagging Policy (JSON)

You can enforce tagging consistency via AWS Organizations Tag Policies or AWS Config rules. Example baseline policy:

{
  "tags": {
    "Environment": { "tag_key": "Environment", "tag_value": ["dev", "test", "prod"] },
    "Owner": { "tag_key": "Owner", "tag_value": ".*@company.com" },
    "CostCenter": { "tag_key": "CostCenter", "tag_value": "^[A-Z]{2}[0-9]{4}$" }
  }
}

The post AWS Resource Tag Recommendations appeared first on AWS Security Architect.

SolarWinds vs. Native AWS Incident Management

TL;DR

• SolarWinds: Best for hybrid/multi-cloud and on-prem visibility with mature ITSM workflows (including SolarWinds Service Desk), deep network & server monitoring, and broad device coverage.
• Native AWS (CloudWatch, EventBridge, Systems Manager Incident Manager/OpsCenter, SNS/Chatbot, X-Ray, etc.): Best for AWS-first teams needing tightly integrated detection, runbooks, auto-remediation, and pay-as-you-go operations with minimal agent sprawl.

What We’re Comparing

Incident Management lifecycle: detection → correlation → triage → response/runbooks → comms & post-incident review → continuous improvement.

Feature Comparison

Strengths & Ideal Use Cases

When SolarWinds shines

• Hybrid/On-Prem Heavy: You manage routers/switches, on-prem servers, and multiple clouds.
• Network-First Ops: Deep NPM, NetPath & SNMP insight; classic NOC views.
• ITSM Maturity: Established Service Desk workflows, CMDB, approvals, SLAs across all estates.
• Single Pane for Non-AWS Apps: Uniform monitoring across databases, apps, and devices.

When Native AWS shines

• AWS-First: Most workloads in AWS; want tight coupling to services and IAM.
• Integrated Auto-Remediation: SSM Automation/Lambda/Step Functions drive fast fixes.
• Org-Scale Governance: Multi-account/region with Organizations, centralized alarms, and runbooks.
• Cost & Operational Simplicity: Avoid extra agents/licenses; use managed building blocks.

Architecture Patterns

Pattern A: SolarWinds-Centric with AWS Integration

1. Install SolarWinds collectors (CloudWatch APIs, CloudTrail, logs) to ingest AWS telemetry.
2. SNMP/WMI agents for on-prem; Cloud connectors for other clouds.
3. Create incident rules in SolarWinds Service Desk; sync to JSM/ServiceNow if needed.
4. Optional: EventBridge → webhook into SolarWinds for specific high-severity AWS events.

Pattern B: AWS-Native Incident Hub

1. CloudWatch Alarms (including composite alarms) & EventBridge rules generate incidents in SSM Incident Manager.
2. Define Contacts, On-Call Rotations, Escalation Plans; wire SNS/Chatbot for comms.
3. Attach SSM Automation runbooks to incidents (rollback, failover, cache flush, ASG replace, etc.).
4. Feed Security Hub/GuardDuty/Detective into EventBridge → Incident Manager for security incidents.
5. Export metrics/logs to OpenSearch or external SIEM/APM if deeper analysis needed.

Pattern C: Hybrid “Best of Both”

• Keep SolarWinds as the cross-environment observability & ticketing layer.
• Let AWS handle first-mile detection and auto-remediation; forward incident signals to SolarWinds.
• Maintain a single enterprise incident record while preserving native AWS runbook speed.

Operations, Cost & Governance

• Cost Control (AWS): Right-size metric retention, filter logs, sample traces, use composite alarms; centralize in a “Logging/Observability” account.
• Licensing (SolarWinds): Plan node/feature tiers and HA/DR for the monitoring stack; budget for Service Desk seats.
• Access: In AWS, least-privilege IAM; in SolarWinds, RBAC aligned to teams/environments.
• Compliance: Map incident records to audit controls; ensure data residency for logs/PII.
• Runbook Hygiene: Versioned SSM documents with approvals; test via pre-prod chaos drills.

Pros & Cons

SolarWinds

• Pros: Hybrid breadth, network depth, mature ITSM, single pane across vendors, strong device coverage.
• Cons: Additional platform to operate; cloud-native automation less seamless; licensing vs. AWS pay-go.

Native AWS

• Pros: First-class AWS signals, rapid setup, powerful automation, org-scale, granular cost control.
• Cons: Limited non-AWS/on-prem visibility without extra work; may need integrations for full ITSM/CMDB.

Decision Checklist

1. Where do most incidents originate (AWS services vs. on-prem/network)?
2. Do you need a single incident/ticketing plane across hybrid estate?
3. How critical is auto-remediation and AWS service-aware diagnostics?
4. What’s your team’s current toolchain (SolarWinds admins vs. AWS engineers)?
5. Compliance/data residency requirements for logs & tickets?
6. Cost predictability (subscription) vs. variable (usage-based) preference?

Integration Map (Common Hooks)

• AWS → SolarWinds: EventBridge → HTTPS webhook; CloudWatch Logs subscription → collector; CloudWatch metrics via API.
• SolarWinds → AWS: Webhook/Lambda to start SSM Automation; create OpsItems via API; update Incident Manager via EventBridge partner events.
• ITSM: Either SolarWinds Service Desk as system of record, or route AWS incidents to ServiceNow/JSM using EventBridge/IaC.

Recommended Baseline (AWS-First Teams)

1. CloudWatch Alarms (including composite) for all Tier-1 services; Logs Insights queries for known signatures.
2. SSM Incident Manager with on-call rotations, comms plans (Slack/Chime via Chatbot), and linked runbooks.
3. X-Ray/ServiceLens for tracing; synthetics canaries for critical user journeys.
4. Security Hub + GuardDuty routed into Incident Manager for security incidents.
5. Optional: Forward major incidents to SolarWinds/JSM/ServiceNow for enterprise visibility.

Bottom Line

If your estate is predominantly AWS and you value fast, automated remediation with tight service integration, go AWS-native. If you need a single pane across hybrid/on-prem and multiple vendors with mature Service Desk workflows, lean toward SolarWinds—and optionally let AWS handle first-mile detection/remediation under the hood.

The post AWS Snowball vs. Direct Connect appeared first on AWS Security Architect.

FSx is always deployed inside an Amazon VPC

Amazon FSx—whether FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP, or FSx for OpenZFS—is a VPC-scoped service.
It cannot be deployed outside a VPC.

Does FSx Need Subnets? Yes. And the Requirements Differ by Type

1. FSx for Windows File Server

• Requires two subnets in the same VPC (for Multi-AZ deployments).

• Subnets must be in different Availability Zones.

• Uses ENIs inside these subnets.

• Must be placed in private subnets (recommended for AD connectivity).

Why 2 subnets?
To support Multi-AZ HA with automatic failover.

Examples of Availability Zone (AZ) names within a single AWS region:

• us-east-1a

• us-east-1b

Both belong to the us-east-1 (N. Virginia) region.

The post FSX for Windows on AWS appeared first on AWS Security Architect.

Using AWS Snowball to Move Large (TB) data workloads into an AWS FSX File System

Short answer: Yes — you can use AWS Snowball to move several Terabytes of data into an FSx file system. In most cases the path is Snowball → S3 → FSx, with service-specific nuances described below.

1) When Snowball Makes Sense

AWS Snowball is built for offline, petabyte-scale migrations. It’s ideal when:

• Network bandwidth is limited or expensive
• You need to seed large datasets quickly (weeks of transfer time avoided)
• You want a predictable, shippable transfer workflow

2) FSx Type-Specific Guidance

FSx Type	Can You Use Snowball?	Typical Method	Notes
FSx for Windows File Server	Yes (indirect)	Snowball Edge → S3 → FSx	Load to S3 via Snowball, then copy to FSx using AWS DataSync or Robocopy from an EC2/Windows host.
FSx for Lustre	Yes (optimized)	S3-linked FSx for Lustre	Put data in S3 via Snowball, then link/import with data repository tasks or at file system creation.
FSx for NetApp ONTAP	Yes (indirect)	Snowball → S3 → FSx (NFS/SMB copy)	Copy from S3 to FSx using rsync, robocopy, or leverage SnapMirror if you have a source NetApp.
FSx for OpenZFS	Partially	Snowball → EC2 staging → FSx (NFS)	Stage from S3 onto EC2, then write to OpenZFS over NFS; consider parallelization for throughput.

3) Reference Workflow (Windows or ONTAP)

1. Order an AWS Snowball Edge device sized for your dataset.
2. Copy on-prem data to the Snowball device.
3. Ship the device back; AWS ingests into your target S3 bucket.
4. Provision the FSx file system (Windows, ONTAP, Lustre, or OpenZFS) in the target VPC.
5. Move S3 → FSx using:
   • AWS DataSync (supports SMB/NFS/Lustre) for managed, parallel transfer and verification
   • Or EC2-hosted tools such as robocopy, xcopy, or rsync

Example: Event-Driven Auto-Tagging of New EC2 (optional helper for staging hosts)

Use an EventBridge rule on RunInstances to trigger a Lambda that tags staging copy hosts.

import boto3
ec2 = boto3.client("ec2")

def lambda_handler(event, context):
    instance_id = event["detail"]["instance-id"]
    ec2.create_tags(Resources=[instance_id], Tags=[
        {"Key": "Purpose", "Value": "FSx-seed"},
        {"Key": "AutoTagged", "Value": "true"}
    ])

4) Snowball vs. Online Transfer

5) Practical Tips

• Pre-compress/dedupe to reduce bytes shipped.
• Design a consistent directory layout (S3 → FSx mapping is simpler).
• Use DataSync filtering and incremental jobs for cutover deltas.
• Confirm permissions/ACLs (NTFS for Windows, POSIX/NFS for others) after transfer.
• Plan a final delta sync just before production cutover.

Bottom line: For a 50 TB migration, Snowball is a great fit. The common pattern is Snowball → S3 → FSx, with FSx for Lustre offering the most streamlined S3 integration and DataSync providing managed, parallelized copies for Windows, ONTAP, and OpenZFS.

The post AWS Snowball to move TeraBytes of data into AWS appeared first on AWS Security Architect.

Why You Should Not Replicate All Servers in Parallel

Replicating every source server at once during a cloud migration may seem efficient, but it often causes severe performance, cost, and control issues. Below are the main reasons replication should be staggered in controlled waves.

1. Bandwidth Saturation and Throttling

Replication is a continuous block-level synchronization process. If you start all servers simultaneously, the replication network link (VPN, Direct Connect, or Internet) will hit its bandwidth limits.
This leads to delayed syncs, throttling, and potential replication errors. It can also impact production workloads sharing the same network.

• Slower replication and sync lag.
• Increased latency and packet loss for other systems.
• Potential replication timeouts and restarts.

Best practice: Limit concurrency (e.g., 25–50 servers per wave) to avoid saturation.

2. Resource Contention on Replication Servers

Replication agents consume CPU, RAM, and I/O on source systems. Launching replication for hundreds of servers at once can degrade source-side performance or even impact user-facing applications.

• Increased I/O queue lengths on shared storage clusters.
• Reduced performance for active workloads.
• Risk of replication agent failure due to contention.

Mitigation: Stagger replication start times and monitor performance metrics per host or cluster.

3. Storage and Cost Explosion on Target Side

Each replicated disk consumes target storage capacity (EBS volumes, snapshots, staging disks). Replicating all servers simultaneously causes a sudden spike in storage utilization and costs.
Snapshots accumulate before any cutover is performed, increasing both cost and management overhead.

Tip: Align replication waves with available budget and staging capacity in your target region.

4. Operational Complexity and Change Control

Parallel replication of large numbers of servers increases operational risk. Teams must monitor hundreds of replications, track dependencies, and manage troubleshooting in real time.

• Dependency mapping or network rules may be missed.
• Increased human error during validation or cutover.
• Difficult to isolate root cause if replication fails on multiple systems simultaneously.

Best practice: Run smaller controlled waves that allow early issue detection and faster remediation.

5. Licensing and Resource Quotas

Many replication tools (such as AWS MGN, Azure Migrate, or CloudEndure) have concurrent replication limits or license caps.
Additionally, cloud platforms enforce limits on the number of volumes, snapshots, and network interfaces per region.
Replicating all servers at once can exceed these quotas and halt the process.

Recommendation: Check service quotas and licensing capacity before initiating large-scale replication.

6. Staged Cutover and Validation

By replicating in defined waves, you can validate and test each batch—ensuring successful startup, connectivity, and dependency resolution before moving on to the next wave.

• Validate application dependencies early.
• Perform smoke tests or cutover rehearsals on a subset of systems.
• Reduce rollback scope if issues arise.

Outcome: Controlled, predictable migration progress with clear rollback options.

Summary Table

Conclusion: Avoiding full parallel replication ensures stability, cost control, and operational visibility during cloud migration.
Replicating servers in phased waves aligns with both network capacity and organizational change control, resulting in safer, faster, and more predictable migrations.

The post Staggering Waves during AWS Migration appeared first on AWS Security Architect.

Handling Static IPs When Moving On-Premises Servers to AWS EC2

When you migrate on-prem servers to AWS, you can’t bring your physical static IPs with you, since AWS controls its own IP ranges.
You can, however, achieve the same “static” behavior using AWS features.

1) Public-Facing Servers

Use Elastic IPs (EIPs), which are static public IPv4 addresses you own within your AWS account. You can assign and reassign an EIP to any EC2 instance as needed.

• Use cases: Web servers, VPN concentrators, jump boxes, partner whitelisting.
• Notes: EIPs remain yours until released; can be associated with an EC2 instance, a NAT Gateway, or a Network Load Balancer.

2) Internal / Private Servers

Use static private IPs inside your VPC subnets.

• Specify a private IP at instance launch (e.g., 10.0.1.10), or
• Attach an Elastic Network Interface (ENI) that holds that private IP.

Detaching and reattaching the ENI to a replacement instance preserves the private IP, keeping internal addressing stable.

3) DNS-Based Migrations

Abstract dependencies away from static IPs by using hostnames.

• Use Amazon Route 53 private or public hosted zones.
• Map hostnames (e.g., db.internal.example.com) to EIPs or private IPs.
• When servers change, update DNS records instead of reconfiguring all clients.

4) Load-Balanced Applications

AWS recommends DNS names for load balancers.

• ALB/NLB/Classic ELB expose DNS endpoints (not fixed IPs).
• If you require fixed IPs in front of them, use AWS Global Accelerator (provides two static anycast IPs).

5) Hybrid / VPN Environments

• Ensure non-overlapping VPC CIDRs with on-prem networks (for VPN/Direct Connect).
• Plan a consistent IP addressing scheme across environments.
• For predictable outbound IPs to on-prem or internet, route via a NAT Gateway with an Elastic IP.

6) Typical Migration Steps

1. Catalog current static IPs and dependencies (DNS, firewall, ACLs).
2. Design VPC CIDR ranges (avoid overlap with on-prem).
3. Allocate Elastic IPs for external endpoints.
4. Launch EC2 instances with specific private IPs or attach ENIs.
5. Update DNS (Route 53) to reference new IPs/hostnames.
6. Adjust Security Groups, NACLs, and on-prem firewall rules.
7. Decommission old IPs only after DNS TTLs expire and traffic stabilizes.

7) Best Practices

• Use EIPs sparingly—unused EIPs may incur charges and add complexity.
• Prefer DNS over hard-coded IPs for agility and failover.
• Manage IPs via Infrastructure as Code (CloudFormation/Terraform).
• Maintain an IP mapping between legacy and AWS addresses for audit and rollback.
• Use ENIs to retain private IPs across rebuilds or blue/green swaps.
• For stable outbound IPs to third parties, use NAT Gateways or Global Accelerator.

In short: Use Elastic IPs for public endpoints, static private IPs/ENIs for internal stability, and Route 53 / Global Accelerator for DNS-based resilience and fixed front-door IPs.

The post Static IPs moving to AWS EC2 appeared first on AWS Security Architect.

The post AWS Migration Success Criteria appeared first on AWS Security Architect.

AWS Application Migration Service and Block-Level Replication

When organizations modernize their infrastructure or prepare for disaster recovery, they need to migrate workloads quickly, reliably, and with minimal downtime.
AWS Application Migration Service (MGN) is the go-to solution for lift-and-shift migrations. At its core is a powerful technology: continuous block-level replication.

1. What Is AWS Application Migration Service (MGN)?

AWS Application Migration Service is a fully managed service that simplifies the migration of physical, virtual, or cloud-based servers to AWS.
It enables you to replicate entire applications — including operating systems, databases, and middleware — without re-architecting.

Key benefits of using MGN:

• Agent-based replication — Install a lightweight agent on source servers to initiate replication.
• Continuous data replication — Keeps the target environment in sync with the source, minimizing cutover windows.
• Cost efficiency — Pay only for storage and compute resources used during replication and testing.
• Non-disruptive testing — Launch test instances in AWS without affecting the source.

2. How Block-Level Replication Works

Unlike traditional file-based replication, block-level replication copies changes at the storage block layer of the server.
This means that any change written to the disk — regardless of application or file system — is detected and replicated to AWS in near real time.

Key Steps:

1. Agent Installation: An MGN agent is installed on the source server (on-premises or cloud).
2. Initial Sync: The service performs a full block-level replication to a staging area in your AWS account.
3. Continuous Replication: After the initial sync, only changed blocks are streamed over a secure channel to AWS. This ensures the target copy remains current.
4. Launch Cutover: Once you’re ready, MGN converts the replicated data into a fully bootable EC2 instance, drastically reducing downtime.

The replication uses an encrypted TLS connection and writes data to Amazon EBS volumes attached to lightweight EC2 instances in a staging subnet.
No special network appliances are required.

3. Architecture Overview

Here’s a typical flow:

• Source Server → MGN Agent → Block Changes Captured
• Encrypted Network Path → AWS Staging Area
• Staging EC2 + EBS Volumes → Continuously Updated Replica
• Launch → EC2 Instances with identical configuration and data

This architecture enables near zero-downtime cutovers, because the data is already replicated and up to date before the final switchover.

4. Practical Use Cases

• Data Center Migrations — Move hundreds of VMs or physical servers to AWS with minimal disruption.
• Cloud-to-Cloud Migration — Migrate workloads from another cloud provider into AWS seamlessly.
• Disaster Recovery — Keep a warm standby in AWS, ready to launch in case of on-premises failure.
• Modernization Prep — Lift-and-shift first, then refactor or containerize once workloads are running on AWS.

5. Tips for a Smooth Migration

• Plan network and security groups in advance to avoid post-launch access issues.
• Monitor replication lag via the MGN console to ensure healthy data sync.
• Test often — Launch test instances to validate application behavior before final cutover.
• Leverage automation with AWS CloudFormation or Terraform to standardize target infrastructure.

Conclusion

AWS Application Migration Service, powered by block-level replication, offers a high-performance, low-disruption path to the cloud.
By continuously replicating changes at the storage layer, you can cut over applications in hours instead of days, accelerating your cloud journey while reducing risk.

The post AWS Application Migration Service and Block-Level Replication appeared first on AWS Security Architect.

Security Issues When Migrating from SQL Server to Amazon Aurora PostgreSQL

Migrating from Microsoft SQL Server to Aurora PostgreSQL involves not only schema and data conversion but also a thorough security posture review. Differences in authentication models, network architectures, and feature sets can introduce new risks if not addressed carefully.

1) Authentication and Identity Management Gaps

• SQL Server Authentication vs. PostgreSQL Roles: SQL Server uses both Windows Authentication and SQL logins, while PostgreSQL uses roles and password-based auth. A direct migration may weaken security if:
  • Legacy SQL logins with weak passwords are migrated without rotation.
  • Windows-integrated security is replaced with basic password auth.
• Lack of IAM Integration: Aurora PostgreSQL supports IAM authentication. Failing to integrate with AWS IAM can lead to unmanaged static credentials.

2) Network Exposure and Access Controls

• Public vs. Private Endpoints: Aurora clusters can be accidentally deployed with public accessibility enabled, unlike on-prem SQL Servers typically behind firewalls.
• Security Groups & NACLs: Inadequate security group rules may allow broad ingress (e.g., 0.0.0.0/0 on port 5432).
• VPN / Direct Connect Gaps: If the migration uses a hybrid model, misconfigured routing can leave the database reachable over the public Internet.

3) Encryption and Key Management Differences

• At-Rest Encryption: SQL Server TDE vs. Aurora encryption using AWS KMS. Forgetting to enable cluster-level encryption in Aurora exposes data at rest.
• In-Transit Encryption: Aurora supports SSL/TLS, but clients must be configured to enforce it. Default configurations may allow unencrypted connections.
• Key Rotation: Aurora depends on AWS KMS policies; neglecting key rotation can weaken long-term security.

4) Privilege Model Mismatch

• SQL Server’s granular permissions and roles don’t map 1:1 to PostgreSQL’s role system.
• “db_owner” equivalents may be over-provisioned, granting unnecessary superuser privileges in Aurora.
• Failing to audit migrated roles can result in privilege escalation risks.

5) Application Connection String Security

• Application connection strings often contain embedded credentials. During migration, these may move to new config files or Lambda functions without proper secret management.
• Not migrating to AWS Secrets Manager or Parameter Store securely can leave passwords exposed in plaintext or code repos.

6) Audit Logging and Monitoring Differences

• SQL Server has integrated auditing and extended events. Aurora requires enabling PostgreSQL logging parameters or CloudWatch Logs.
• Failing to enable log_statement, log_connections, and related parameters means losing audit trails post-migration.
• Lack of GuardDuty or Security Hub integration reduces visibility into anomalous DB access.

7) Stored Procedures and Dynamic SQL Risks

• Migration tools may convert T-SQL stored procedures into PL/pgSQL. Differences in privilege context can accidentally allow injection vulnerabilities.
• Dynamic SQL behavior differs: PostgreSQL’s EXECUTE in functions may require stricter input sanitization than in SQL Server.

8) Replication and Backup Security

• Backup strategies change from SQL Server native backups to Aurora snapshots and PITR. Not enforcing snapshot encryption and retention policies can leak data.
• Cross-region replication may expose snapshots to unintended accounts if sharing policies are misconfigured.

9) Migration Tooling Itself

• Using AWS DMS or third-party tools with broad permissions can be a risk if IAM roles are not scoped properly.
• Staging S3 buckets used by DMS may store unencrypted or world-readable migration files if not secured.

Summary Table

Best Practices to Mitigate These Issues

• Integrate Aurora PostgreSQL with IAM and enforce SSL connections.
• Deploy Aurora into private subnets with strict security groups.
• Use AWS Secrets Manager for connection credentials.
• Enable CloudWatch logging, GuardDuty, and Security Hub integrations.
• Apply principle of least privilege to roles, migration tooling, and snapshot sharing.
• Validate stored procedures and privilege mappings during conversion.

The post SQL Server to Aurora Postgres Migration – Security Concerns appeared first on AWS Security Architect.